本稿の後編は、インフラエンジニアのための、データ活用基盤検討ガイドライン（後編）となります。
はじめに
G-genの杉村です。この記事では、データ活用基盤について、導入の検討の進め方や参考アーキテクチャをご紹介します。
当記事の想定読者は、これまでデータの扱いに深く関わったことのないインフラエンジニアの方や、事業会社の情報システム部の方です。
記事後半の「スキルセット」の項でも触れますが "データエンジニアリング" のスキルを持った人材は日本全体で不足しています。「これからデータ活用基盤の導入検討をしなければならない。しかし社内にデータサイエンティストやデータエンジニアはいないし、採用の見込みも立たない」というケースは、今やごく一般的です。
そのようなとき、既に社内にいる人材... インフラエンジニアが検討を主導する場面も多くなるはずです。当記事は、そのような方々に参照していただけることを意識して書いています。
データ活用基盤とはそもそも何か
要素の一般化
当記事はデータ活用基盤の導入方法についてご紹介する記事ですが、そもそも「データ活用基盤」とは何を指すかについて明確化しておきます。 以下は、当記事で言う「データ活用基盤」の構成要素を一般化したものです。
このように、データを収集して活用するまでの一通りの流れをデータパイプラインと呼ぶこともあります。これらの仕組みの中を、データが左から右へ形を変えながら移送されていくイメージです。最もシンプルなデータパイプライン (データの移送) は手作業により実現されることもあります。しかし、本投稿で扱うデータ活用基盤は、定常的・自動的に処理が行われるデータパイプラインを想定しています。このようなものを指し、当記事では「データ活用基盤」と呼びたいと思います。
データ活用基盤の目的
このようなデータ活用基盤 (データパイプライン) はなんのためにあり、どのような問題を解決してくれるのでしょうか。以下のようなことが言えます。
●スピードアップ (データの可視化、活用までにかかるリードタイムの短縮)
●品質向上 (基準が揃った共通指標を用意することで適切なデータ活用が可能)
●工数削減 (データの移送・変換の自動化)
部署ごとに Excel 作業で売上関連データを集計・可視化しているような状況だと、「可視化までが遅い」「部署ごとに違うデータをもとに違う方法で集計しているので、違う数字を見ている」「まとめるのに作業時間がかかる」などの課題があるはずです。データ活用基盤はこれに対して、自動化と中央集約により解決策となります。
実現方法
パブリッククラウドによる実現
データ活用基盤はどのようなプラットフォームでも実現できます。極論、プログラムが動けばパソコン上でも実現できますし、オフィスやデータセンターに置いたサーバーでも実現できます。しかしながら、今日では以下の理由でパブリッククラウドがそのプラットフォームとして選択されることが大半です。
●セキュリティレベルが高い
●耐久性が高い
●スモールスタートして後から拡張できる
●インフラ運用の工数が小さくて済む
●拡張・縮小が容易
当記事では代表的なパブリッククラウドとして Amazon Web Services (以下、 AWS) と Google Cloud の2つを取り上げたいと思います。
Amazon Web Services (AWS)
AWS の提供するサービスでは、各要素に以下のようなものが該当します。
なおこれは例示であり、他にも当てはめることのできるサービスはあります。
Google Cloud
もう一例として Google Cloud の提供するサービスだと、以下のようなものがあります。
こちらも例示であり、他にも当てはめることのできるサービスはあります。
3rd Party 製品の活用
AWSやGoogle Cloud などパブリッククラウドのネイティブサービスを利用することは 「安価な利用料金」「クラウドサービスとの親和性」「マネージドサービスによる基盤運用負荷の低下」 などメリットがあります。 ただし (あくまで一般論ですが) 「海外で生まれた製品であるため UI やマニュアルが翻訳文的で分かりづらい」「テンプレートファイルの記述やコーディングが必要な場合があり学習コスト・運用難易度が高い」などのデメリットもしばしば見られます。
国内産の3rd Partyなどを活用することで、豊富な機能や、分かりやすいUIや日本語ネイティブなドキュメントやサポートなどが期待できます。
検討と導入のプロセス
正攻法
データ活用基盤の検討・導入の正攻法は、上記表のプロセスを左から右に向けて進みます。赤色の文字にした最上流検討の成果物としては、以下のような例が挙げられます。
アウトプットデータについて
●必要となるレポート / ダッシュボードのリスト
●リードタイム
・リアルタイムか、ニアリアルタイムか、バッチか
・データ (レポート) はどのようなタイミングで必要とされるのか。週次の会議なのか、日次で確認したいのか等
●保存期間
●同時接続数 (利用者数)
インプットデータについて
●ソースデータのリスト
・フォーマット (ex:RDB, ファイル, API...)
・所在 (ex:データセンター、店舗、オフィス...)
・性質 (ex:POS, ECサイト, 個人情報有無...)
・制約 (ex:インターネット接続なし, メインフレーム, API無し...)
・ボリューム (ex: xx TB, xx GB...)
変換処理について
●変換処理の数
●処理の性質 (リアルタイムか、ニアリアルタイムか、バッチか)
これらが決定すると、次にソリューションや基盤の議論に移り、AWSにするか、 GCPにするか、どの製品を使うか等の検討ができます。
もう一つの選択肢 - スモールスタート
以上のような正攻法での整理の難易度は高いといえます。
実際に始めてみないことには分からない事項も多いからです。
最初から大規模なデータ分析を目指すと、上流の難易度や工数は非常に高いものになり、前に進まない状況が生まれてしまうおそれもあります。
そのため、まずはゴールを小さく絞ってスモールスタートするという道も検討対象になります。そのようにしてデータ活用の効果を実感し、ノウハウを溜めていき、徐々に範囲を拡大していくという手法です。
スモールスタートは、データ活用基盤に限らず、企業へのクラウド導入における定石でもあります。
次項にていくつかの参考アーキテクチャを紹介しますが、いずれも小〜中規模なデータ活用基盤のアーキテクチャを示しています。
例えば、後述の例2 Cloud Data Fusion はグラフィカルにジョブネットを作成できる他、データ変換処理もGUIで作成できます。
インスタンスが起動している間は従量課金で料金が発生しますが、その分、インスタンスを削除することで環境を棄てることも容易です。
将来的に大規模になる可能性がある場合は、初めから対応すべき検討事項がある点にも注意が必要ですが、まずはデータ分析の効果測定やPoCをこれから紹介するアーキテクチャによって行うことで、実績 (足がかり) とすることもできるでしょう。
※本記事はG-genから提供を受けております。著作権は同社に帰属します。
[PR]提供：G-gen
