TL;DR
本記事では、Google Cloud上で社内限定公開のStreamlit cloud相当のサーバレスプラットフォームを独自実装した試みをご紹介します。単に、Streamlitをサーバレスにデプロイするだけでなく、データサイエンティスト向けにCI/CD・専用IDE環境まで提供し、 エンタープライズ内でのデータサイエンスの生産性を向上させることを目指した取り組みです。
自己紹介
NTTドコモ データプラットフォーム部（以下DP部）藤平です。 DXの一環として、ビッグデータ・AI・ML技術の活用が叫ばれる世の中ですが、依然としてデータそれ自体をビジネス価値につなげるためには 様々なハードルがあり、データ活用に悩まれている方は多いのではないかと思っています。 我々もその悩みを抱えており、このようなハードルを解消していくことがデータ活用の鍵だと認識しています。
そのような問題意識から、DP部では今年も様々な取り組みを行ってきましたが、そのうちの一つが、本記事でご紹介するStreamlitの活用です。
StreamlitはデータサイエンティストがReact等のフロントエンドのフレームワークを使わずに、PythonコードのみでWebアプリケーションを作成できるという特徴を持っており、近年データサイエンティスト界隈で爆発的に広まっているPythonライブラリです。それをGoogle Cloud上にサーバレスにデプロイすることで、 StreamlitのSaaSサービスであるStreamlit cloud相当のプラットフォームを独自に実装しました。
本記事で紹介する取り組みについては、NTTデータの支援メンバーである辰己さんをはじめとしたメンバーによって、アーキテクチャの設計と実装を行っていただきました。以下、辰己さんに本取り組みの内容をご紹介していただきます。
Streamlitとは
改めて、Streamlitについてご紹介します。
以下の公式サイトの動画キャプチャがStreamlitの特徴をよく表しているのですが StreamlitはPythonベースでコードを書くことでインタラクティブなWebアプリケーションを作成できるという特徴があり、データ抽出・可視化・MLモデルの評価等、データサイエンティストが日常的に行う作業をアプリケーションとして作成できます。
Streamlitの公式サイト内の動画(40秒程度)が非常にわかりやすいので、こちらを見ていただくと容易にイメージをつかんでいただけるかと思います。
Streamlit公式サイト
Streamlitはここ数年で爆発的に広まりを見せました。OSSとしての広がりもすごいのですが、SaaSとしてStreamlit Cloudというサービスも展開されており、最近ではSnowflakeにStreamlit自体が買収されたこともあり、Snowflake上でもStreamlitが（現状多くの機能制がはあり、かつ現時点ではパブリックプレビューとしてのリリースですが）利用可能になっています。
出典：Data dashboarding tools | Streamlit v.s. Dash v.s. Shiny vs. Voila vs. Flask vs. Jupyter
Streamlit in Google Cloud
我々がStreamlitに注目した頃は、未だStreamlit in Snowflakeのようにエンタープライズ向けのStreamlitのマネージドソリューションは世の中的には存在していなかったこと、また、Streamlit cloudのようなSaaSはコンプライアンスの観点で今回用途での利用が不可であったこともあり、Google Cloud上で自前でStreamlitのためのプラットフォームを構築することにしました。
本プラットフォームのGoogle Cloud上での構成は以下のイメージです。
今回このプラットフォームへのアクセスは社内に限る必要があるため、Identity Aware Proxy（以下、IAP)というGoogle Cloudのマネージドな認証プロキシを利用することで社内ユーザーのみアクセス可能にしています。また、Streamlit自体はCloud Runというサーバレスなコンテナ実行環境（googleマネージドなknative)を使うことで、ノードの管理を一切することなく、ユーザーが利用していないときは一切コストがかからないゼロスケールの環境を実現しています。
本プラットフォームでは、データサイエンティストがアプリケーションを開発したいときは、Google Cloud上でのセキュアなIDE環境、及び、IDEからgitベースでCI/CDのパイプラインを実行することで、実行しているインフラストラクチャーについて意識することなくStreamlitアプリケーションを開発することができる一式の環境を提供しています。
本アーキテクチャにおける技術的なポイント
本アーキテクチャ自体は、構成図では一般的なサーバレスアーキテクチャに見えると思いますが、 実際にはプラットフォームとしての提供をするために、いくつかの工夫を行っています。
1. Streamlit自体の独自カスタマイズ
本プラットフォーム上では、デプロイしたStreamlitアプリケーションがユーザーにどのように利用されているのか、どれくらいのユーザーがどの機能を利用しているのかなど、アプリケーション自体の利用状況を定量的に把握して改善につなげるために、StreamlitにGoogle Analyticsを導入しています。Streamlit自体は公式にGoogle Analyticsの導入方法を提供していないため、我々はStreamlit内の静的コンテンツにGoogle Analytics用の追加の書き込みを行い、Google Analyticsによるトラッキングを実現しています。
2. URLマスクを用いた、StreamlitアプリケーションのURLの制御
本プラットフォームでは現時点でも数十のアプリケーションが存在し、将来的にさらに増加が見込まれています。アプリケーションの追加の度に、URLを追加するのは運用負荷が高いため、Google Cloudが提供するURLマスクという機能を用いて、アプリケーションが追加されても自動で新しいアプリケーションに対してURLが割当たるようにしています。
下記のGoogle Cloud公式の図がわかりやすいのですが、自プロジェクトでLoginとSearchというCloud Runサービスをホストしているとき、URLマスクを用いることで、それぞれのサービスに対して、https://{domain}/login, https://{domain}/search というURLが割当られるようになります。
出典：https://cloud.google.com/load-balancing/docs/negs/serverless-neg-concepts?hl=ja
3. Cloud WorkStationsを用いた、VPC内のセキュアなIDE環境の提供
上述の構成図を見ていただくとわかるのですが、本プラットフォームではStreamlitから接続するデータソースとしてVPCから接続しているSnowflakeを利用しています。そのため、開発者がコーディング時にStreamlitの動作確認を行うためには、IDEの実行環境それ自体がVPC内にある必要があります。そのため本プラットフォームでは、Google Cloudが提供するCloud WorkStationsというマネージドなIDEサービスを利用して、VPC内にIDE環境を提供しています。
Cloud WorkStationsも、Cloud Runと同様にノードの管理が不要なサービスであり、IDE用のコンテナイメージさえ用意してあげれば、必要な分だけIDE環境を動的に払い出すことが可能です。また、Cloud WorkStationsでは、ローカルのVSCodeからIAM認証をしたうえでセキュアに接続することもサポートされているため、開発者はGitHub CopilotやVSCodeの拡張機能を利用しながら、生産性の高い開発を行うことを可能です。
4. 共通ライブラリの提供
本プラットフォーム上で開発するのは、主には一般的なWEBアプリケーションの開発者よりは、データサイエンティストのほうが多いこと、また、Google Cloud上のリソースやSnowflakeへの接続の際に開発者が各々独自に実装すると、セキュリティ・運用性・保守性の観点で問題があることから、本プラットフォームでは、共通ライブラリを提供することで、開発者がそれらの問題について意識することなく、アプリケーションの開発に集中できるようにしています。
またライブラリの提供に当たっては、開発者が簡単にその仕様の理解ができるようドキュメントの整備及び、ドキュメントをもとにLLMを利用したChatbotにslackから質問できる仕組みも併せて提供することで、少人数ながら運営できるプラットフォームを実現しています。
5. Cloud Run × IAP構成における制約の回避
IAPはマネージドな認証プロキシとして非常に便利なサービスなのですが、既知のバグとしてIAPと併用して利用した際に、HTTP/2を有効化できないという制約があります。結果、streamlit経由でファイルの授受ができるファイル上限がHTTP/1.1でサポートされる32MBまでに制限されてしまいます。
参考：https://cloud.google.com/iap/docs/enabling-cloud-run?hl=ja
本制約を回避するために、上記の共通ライブラリを通じてファイルの授受の際はGCSに対する署名付きURLを発行することで、ファイルサイズの制限を回避するとともに、GCS上のファイル授受について最適なスループットが提供されるように工夫しています。
今後の展望/最後に
このプラットフォームは、当初自組織だけでの利用想定でしたが、昨月11月には約千人の方が利用する一大基盤となりました。社内で直近ではデータサイエンティストの方に限らず幅広くエンジニアの方にも利用していただいていること、また開発者のリテラシーも以前よりもバラつきがあることから、今まで以上にプラットフォームレイヤーの適切な抽象化・自動化によるトイル削減・セキュリティの強化をしていかなければならないと考えています。
特に、セキュリティについてはサーバレスサービスの恩恵を受けて保護すべきレイヤーが狭まったとしても、コンテナイメージ自体の脆弱性の対応や、DevSecOpsを実現したCI/CDパイプラインの構築など、やるべきことはまだまだ多いと考えています。
実際には、プラットフォームとしてこのような基盤を提供する上で行っている工夫は、未だ多くありますが、本記事としてはここまでとさせていただきます。 ただ、本記事の中でご紹介させていただいた内容のうち、Cloud Workstationsや、CI/CDパイプラインにおける工夫点については、明日以降のアドベントカレンダーで自チームのメンバーが執筆してくれる予定ですので、興味を持っていただいた方は是非明日以降もご覧いただければと思います。
また、LLMを利用したChatbotについては既に別記事にて、その運用を含めてご紹介させていただいておりますので併せてご参照いただければと思います。
関連記事
Prompt Flowで評価Flowを自作してRAGのイケてるLLMOpsを実現してみた
100人が使う（予定の）Google Workstationsでセキュアにスケールするデータサイエンティスト向けアプリ開発環境の運用ノウハウ（明日12/12 AM9時頃公開予定）
訳あってCI/CDをCloud BuildからGitHub Actionsに変えてみた （明後日12/13 AM9時頃公開予定）
