1. はじめに
当記事は株式会社G-gen様とライオン株式会社の技術ブログ相互寄稿企画で執筆されたものです。
ライオン側からは、 G-gen様のご協力のもと、Google Cloud環境に構築を進めているデータ基盤に関連した以下3つの記事をシリーズでお届けします。
- ライオンのデータ基盤構築とSAPデータ活用体制
- ライオンのデータマネジメント
- ライオンのデータ基盤における分析環境 👈★当記事
G-gen Tech Blog の記事一覧 LION Digital Inside の記事一覧
2. 当記事について
ライオン株式会社にてデータ基盤まわりを担当しているフクヤマです。
当記事では、部署横断での安全なデータ共有とデータドリブン文化の定着を目的として、データマート（DM）層に部門単位の Google Cloud プロジェクトを用意し、Vertex AI Workbench を中核としたセキュアな分析環境を構築した事例を紹介します。
事例紹介の中で、VPC Service Controls 配下で外部 IP アドレスを持たずに BigQuery などへアクセスする設定や、Notebook をバッチ実行するための構成について解説します。
3. 目的と位置づけ、ユースケース
3-1. なぜ分析環境が必要なのか？
データ基盤に集約されたデータを迅速かつセキュアに活用するためには、ユーザ専用の分析環境が必要です。この環境を構築することにより、以下のようなメリットを期待しています。
部署横断的な活用の促進
異なる部門間でデータを共有し、共通の基盤のもとで意思決定を行うことで、組織全体の生産性向上に寄与
データドリブンな文化の醸成
ユーザが主体的にデータ活用できる環境を整備することによる、組織全体へのデータドリブンな文化の浸透、および現場レベルでの改善活動の一層の促進
セキュアな環境での実験と開発
VPC Service Controls などのセキュリティ技術を活用し、安心して分析や機械学習の実験が行える環境を提供
3-2. データ基盤における分析環境の位置づけ
当社のデータ基盤では、レイヤー構造で環境を分離しており、役割と管轄を明確化しています（詳細は当社1つ目の記事を参照）。この構成に従い、分析環境は DM 層に整備することになります（Figure 1）。ここでいう環境は、1つの Google Cloud プロジェクトを指しており、部門ごとあるいは業務プロジェクトごとに作成することを想定しています。
Figure 1: データ基盤における分析環境の位置づけ
分析環境においては、データ基盤に存在するデータ、具体的にはデータレイク（DL）層またはデータウェアハウス（DWH）層に位置するプロジェクトのデータに対しては参照のみを許可しています。分析者はこれらのデータを主に Notebook から参照のうえ、必要な処理・分析を実施します。処理済みのデータは必要に応じて分析環境上のテーブルとして保管され、活用されます（e.g. BIツールによる可視化）。
3-3. 分析環境のユースケース
当社ではデータサイエンティストから分析専門職以外の一般ユーザにまで、分析環境を提供することを想定しています。それぞれの環境のユースケースとしては、おおまかに以下を想定しています（Table 1）。
Table 1: ユーザごとの分析環境のユースケース
| No | ユーザ | ユースケース | 主な利用サービス |
|---|---|---|---|
| 1 | データサイエンティスト | ・notebook環境でPythonを使った次の処理 - adhoc分析 - 機械学習モデル構築 - バッチ処理（スケジュール実行） ・コード管理 |
・BigQuery ・Vertex AI ・Artifact Registory ・Cloud Run ・Cloud Storage |
| 2 | データアナリスト | ・SQLを活用したダッシュボード・レポーティングの作成 ・データ探索によるインサイト抽出 |
・BigQuery ・Looker |
| 3 | 一般ユーザ | ・ダッシュボード・定型レポートの閲覧 ・業務指標のモニタリング （・SQL活用） |
・BigQuery ・Looker |
当記事では上記のうち、データサイエンティストの分析環境について紹介します。
4. Notebook環境のアーキテクチャ
4-1. Vertex AI Workbench の利用
データサイエンティストが試行錯誤しながらデータ分析をしたり、機械学習モデルを開発する環境としては、Notebook（Jupyter 環境）が必要です。Notebook の利用にあたり、当社では大きく以下の2つの要件があり、これらを満たすため、Vertex AI Workbench を利用することに決めました（Figure 2）。
- 要件1. ユーザーが日常的に Python でデータ探索・分析を行うこと
- 要件2. ユーザ管理の VPC 内に環境を配置したうえで、VPC Service Controls（以降、VPC SC）を利用して企業データのセキュリティレベルを確保すること
Notebook 環境を利用できるサービスとしては、Colab Enterprise や Cloud Dataproc もありますが、要件を満たさなかったため候補から外れました。Colab Enterprise は要件2を満たさず、Cloud Dataproc は大規模分散処理や Spark 利用が前提であれば有力な選択肢となるが要件1の観点でオーバースペックだったためです。
Figure 2: データサイエンティスト向け分析・モデル開発環境
設計上のポイントは、VPC SC のサービス境界（Service Perimeter）により、Vertex AI をはじめ、本環境で利用するサービスの全てが保護されることです。この保護機能によりデータの漏洩防止対策が充実する一方で、設計で考慮すべきことがいくつか出てきます。
4-2. Google Cloudサービスへのプライベートアクセス
Vertex AI Workbench インスタンス（以降、Workbench インスタンス）からは、様々な理由で他の Google Cloud サービスにアクセスする必要があります。代表的なケースは、分析対象のデータを参照するために、BigQuery や Cloud Storage にアクセスするといったものです。
当社の場合、Workbench インスタンスには外部 IP アドレスを持たせていないため、別の Google Cloud サービスにアクセスする際にはインターネットを経由せずにアクセスする必要がありました。この場合、アクセス対象が VPC SC にサポートされている Google Cloud API に限定されていれば、限定公開の Google アクセス（Private Google Access）と restricted.googleapis.com VIP を組み合わせたプライベートアクセス方式を採用することでセキュアにアクセスできることがわかり、この方式を採用しました。
設定方法の詳細は、以下の記事が参考になりました。Cloud DNS については、デフォルトドメイン（*.googleapis.com）を restricted.googleapis.com に向ける設定にしています。
4-3. JupyterLab のための追加設定
VPC SC のサービス境界によって保護されている Workbench インスタンスについて、前述のように外部 IP アドレスを持たない、かつ Google Cloud API へのパブリックアクセスを許可していない場合は、JupyterLab をブラウザ上で起動するために追加の設定が必要となります。
なぜなら、そのような Workbench インスタンスは VPC ネットワークの外部にあるサービスエンドポイントにアクセスする必要があるからです。具体的には、restricted.googleapis.com VIP を利用するサービスエンドポイントとして、DNS に以下のドメインを追加で設定する必要があります。
notebooks.googleapis.com*.notebooks.cloud.google.com*.notebooks.googleusercontent.com
詳細は以下の公式ドキュメントをご覧ください。
4-4. 外部サービスへのアクセス設定
本記事のメインテーマではありませんが、ソースコード管理ツールなどの外部サービス（Github、PyPI、Docker など）へのアクセスについて補足です。
今回はインスタンスに外部 IP アドレスを持たせないため、Cloud NAT でアウトバウンド通信をさせています。また、通信制御は Cloud NGFW の FQDN オブジェクトを利用して、対象サービスの FQDN に対してのみアウトバウンド通信を許可することで、不要な外部通信を排除しています。
5. バッチ処理のためのアーキテクチャ
当社のデータ分析基盤では、分析やデータ活用のため、バッチ処理を定期実行（スケジュール実行）させる要件があります。データサイエンティストから、Notebook に記述したプログラムをそのままバッチ処理として実行したいというニーズが挙がったため、スクリプトを新しく記述してワークフロー化することは見送り、Notebook 上のプログラムをバッチ処理として実行する方法を検討しました。
調査したところ、Vertex AI Workbench には Notebook のスケジュール実行（エグゼキュータ）機能が備わっていることを発見し、これで一件落着！・・・と思いきや、調査を進めたところ、エグキュータ機能は VPC SC 下ではサポートされていないことが判明しました。試行錯誤するなかでドキュメントを読み漁ったところ、公式ドキュメントに、以下の記載を見つけました。
In instances that use VPC Service Controls, use of the executor isn't supported.
すなわち、エグゼキュータは VPC SC 環境下では利用できないことが判明しました。気を取り直して代替手段を調査したところ、VPC SC 配下でバッチ処理をスケジュール実行する際のベストプラクティスとして、Cloud Scheduler、Cloud Run services、Cloud Run jobs を組み合わせた方法を発見しました。
上記のドキュメントを参考に、Notebook ファイルをバッチ実行するための OSS である papermill を組み込んだ Docker コンテナを Cloud Run jobs として登録することで、ひとまず目的としたジョブのバッチ処理が実現できました。
6. まとめ
当記事では、ライオンのデータ基盤における分析環境について、主にデータサイエンティスト向け環境の概要をご紹介しました。
今後はより広範な業務ユーザや非エンジニアの分析ニーズに応えるため、Google Cloud の提供する生成 AI 機能のを積極的に導入するなどして、専門知識のないユーザでも自然言語で問い合わせてデータの取得やレポート作成などが行える環境を整備し、データ分析への参入障壁の軽減にも挑戦したいです。
ライオン株式会社のデジタル部門「LDX」が発信するテックブログ「LION Digital Inside」は、ハミガキ、ハブラシ、洗剤などを開発・製造する中で培った“製造業としての強み”と、Webサービス開発の最前線が交差する場所。LDXが最新技術と革新の舞台裏を余すところなくお届けします。
Discussion