インフラエンジニアのための、データ活用基盤検討ガイドライン（後編）

本稿は、インフラエンジニアのための、データ活用基盤検討ガイドライン（前編）の続編となります。

サンプルアーキテクチャ

例1: Google Cloud のみ・最もシンプル

以下は最もシンプルなデータパイプライン構成の例です。

データ生成元のシステムからスクリプト等で BigQueryにデータをロードします。

BigQuery の Scheduled Query という機能を使って SQL を定期的に実行することで、BigQuery にロードされたデータを変換 (ELT) して分析に適した形にします。

この構成の利点は、図中にあるように非常に安価で、簡単に実装できることです。

ただし前後関係・依存関係のある複雑なジョブは組めないことや、何らかの理由で処理が失敗した場合のリトライや分岐処理などが弱いため、ごく小規模で単純なデータパイプラインの実装にだけ用いるべきでしょう。

例2: Google Cloud のみ・Data Fusion を利用

以下は先ほどの例に Cloud Data Fusion を組み合わせた例です。Data Fusion では GUI で ETL ジョブを作成・管理できます。

Data Fusion は先ほどの例よりも複雑なパイプラインを実装可能で、失敗通知や後続アクションの設定も可能です。

以下は Data Fusion のジョブ編集画面です。

この構成の課題は、さらにパイプラインが大規模・複雑になった際に現れます。

パイプラインの規模が大きくなるに連れ、GUIでのワークフロー管理だと、バージョン管理、差分確認、テスト、切り戻しなどに不便さを感じるようになるはずです。

そのような際は、 ETL (ELT) プログラムをプログラミング言語やSQLで記述し、 Git等によるコード管理をし、開発環境を整える必要性が出てくるでしょう。

例3: AWS + Google Cloudの例

以下は、 AWS にデータ生成元システムがあり、 Google Cloud に分析基盤を配置する例です。

ワークフロー管理ツールからジョブを実行し、 Amazon S3に溜めたデータをBigQueryにロードしています。

この図では Cloud Composerとなっています。もちろん自社で既にJP1などのワークフロー管理ツールが導入済みであれば利用すればよいですし、先ほどのCloud Data Fusionも利用できます。

パイプラインが複雑で大規模になる場合、何らかの方法でのワークフロー管理は必須になります。

保守・運用

データ活用基盤は、作るだけでなく保守や運用が必要です。以下は代表的なタスクを例示したものです。

保守

●バージョンアップ対応・パッチ適用
●トラブル対応 (ジョブの失敗、サーバのエラー、プログラムの例外、データの欠損...)
●スケーリング（コンピューティング・ストレージリソースの増減...)

運用

●レポートの修正・新規作成
●それに伴う ETL 処理等、パイプラインの修正
●データ生成元の変化への対応 (システムの増減、データのスキーマの変化)

保守の部分は、サーバにインストールするタイプの製品が最も負荷が高く、反対にAWSや Google Cloud のマネージドサービスやサードパーティのSaaSでは負荷が小さくなります。

運用の部分は、ビジネス部門にどのくらいレポート作成等の役割を分譲するか、また再利用性の高いジョブ設計できるか、などによって負荷が変わってきます。

内製化 or アウトソース

データに関する3つのスキルセット

企業や官公庁において、限られた予算の中で IT によるデータ活用推進を考える際、内製化するべきかアウトソースするべきかは重要な論点になると思います。

内製化とアウトソースのバランスを論じる前に、データ活用に関わるスキルセットとはどのようなものか、ということについて確認します。

以下は、近年よく見かけるようになった、データ活用に関する 3 つのスキルセットとその役割を示したものです。

データエンジニアリング

当記事をお読みの IT 関連部署の方、もしくは IT エンジニアの方の多くは「データエンジニアリング」のスキルに一致している、もしくはその方向の学習をされようとしている方が多いかと思います。

データエンジニアのニーズは急速に高まっており、採用も困難です。その状況はどの企業も同じと考えられます。

しかしながら、同じく貴重なデータサイエンティストに、データ活用基盤の設計や構築・運用をさせることは、畑違いのタスクが多いこともありコストパフォーマンスが悪いと言えます。

そのような背景から、企業のインフラエンジニアがデータエンジニアリングを学ぶ必要性が増しているのではないでしょうか。

インフラエンジニアがデータエンジニアリングを学ぶには、以下のような事項を学習する必要があります。

●データに関する基礎知識 (正規化、インデックス、SQL、トランザクション、ACID、など)
●データモデリングに関する知識 (テーブル論理/物理設計, ER図...)
●データベースに関する知識 (RDBMS, NoSQL, MPP...)
●データ活用基盤に関する知識 (データの収集、変換、保管)
●可視化に関する知識 (BIツール等)

まずは IPA(独立行政法人情報処理推進機構) の監督する情報処理技術者試験であるデータベーススペシャリスト試験の学習などを通じてデータに関する基礎知識を得てから (高度試験であることからハードルが高いようにも思えますが、基礎的な知識からカバーしているので心配はありません。また必ずしも試験合格までする必要はありません。データの基礎知識を得るのが学習の目的です) 。その後に市販のビッグデータ関連書籍や AWS 、Google Cloud のデータ活用基盤系サービスに関する書籍を読んで学習を進めるのがスムーズです。

このとき、データサイエンスとデータエンジニアリングの区別をしっかり付けて、限られた時間を有効活用して学習することが重要です。学生時代に統計学などを学んでいて素養のある方であれば話は別ですが、そうではないインフラエンジニアが、統計学や機械学習、Rを使った分析などの学習に時間をかけることには、慎重になるべきだと言えます。

最低限、データエンジニアリングとその周辺知識を IT部門メンバーが持っていれば、データ活用基盤の検討に際してリーダーシップを発揮することができるはずです。

企画・要求定義・要件定義などの上流工程をIT部門で行うことができれば、工数が大きくかかる後工程はITベンダーに依頼することも可能になります。

データサイエンス・ビジネススキル

一方で、データサイエンスは統計学や機械学習など、アカデミックな背景がないと理解が難しい分野でもあります。あまりに専門性が高いこのスキルセットは、金銭コストを多少かけてでもアウトソースするほうが効率的な場合が多いでしょう。

ビジネススキルについては、経営層やユーザー部門にしっかり学んでもらうことが重要ですが、必要に応じてデータ活用コンサルタントの支援を仰いでも良いでしょう。

データエンジニアにとっては、前述の通りこれら2つのスキルの深堀りまではしなくてよいとはいえ、概要の把握程度は必要でしょう。最初の図で示したように、3つのスキルセットには重なる部分があり、相互に連関しているからです。

内製化か、アウトソースか

2022年現在、デジタルトランスフォーメーション (DX) を謳うニュースや論評では、内製化の必要性を説く風潮が強いといえます。

しかしながら、全てのシステム開発を内製化する必要はない (することはできない) という点に注意が必要です。

日本の雇用関連法制度と低い雇用流動性の下では、プロジェクトベースでエンジニアを雇い、終わったら解雇する、といったエンジニアの流動的な確保とリリースが困難です。

そのため、どこを内製化し、どこをアウトソースするかの判断が非常に重要になります。この判断 (ジャッジ) だけは、必ず社内の人間で行う必要があります。

以下は、内製化寄りにすることが望ましいです。

●ビジネスのコアとなる部分
●他社との差別化に繋がる部分
●特にスピード感が求められる部分

反対に、以下はアウトソース寄りにすることが望ましいと言えます。

●専門性や難易度が高すぎる部分
●ビジネス差別化に繋がらない部分
●労働集約的になりがちで社内リソースを投入するには "もったいない" 部分

将来的に内製化を目指すが、現在は社内に知見がない部分については、プロである外部ベンダーの内製化支援サービスや技術支援を受けながら、最初はアウトソースの割合を高めにし、徐々に内製化の割合を高めていくような段階的移行の選択肢があります。

なお当社 G-genは当記事でご紹介したようなデータ活用基盤導入のご支援 (設計・構築の委託、もしくは貴社の内製化に対する技術支援) が可能です。データ活用基盤のみならず、クラウドインフラ全般に知見があります。またエンジニアリングを依頼しないまでも、当社の請求代行サービスを利用いただくことで Google Cloudを5%オフの割引価格で利用する事が可能です。お問い合わせフォームからお気軽にご連絡ください。

このように、内製化とアウトソースのバランスを決断することが、企業・官公庁の情報システム部門に求められる必須のタスクです。