Stremalitで作っていた社内アプリをStreamlit Cloudから自社GCP環境に移行した
はじめに
当社では、データサイエンティストのチームでStreamlit Community Cloud上で社内向けのStreamlitアプリを運用していました。当初はお試し感覚で運用していたのですが、次第に基幹システムとして機能するようになってきたので、Cloud Runに移行しました。
1. Streamlit Community Cloudでの運用背景
アプリケーションの機能と利用シーン
メニューの組み合わせを最適化する社内向けツールを作っています。BigQueryからメニューデータを抽出して、様々な制約条件を満たす組み合わせを表示してくれるといったものです。
データサイエンティストが作るといった背景から、手軽にアプリケーションを構築できるStreamlitというPythonのフレームワークを用いており、その流れでStreamlit Community Cloudを用いてデプロイしていました。
メリット
-
手軽にデプロイできる
GitHubリポジトリと連携すれば、GUI操作でアプリ公開が簡単。 -
無料枠がある
個人や小規模なプロトタイプ用途ではコストを抑えられる。 -
セットアップが容易
Pythonスクリプトだけで動くため、インフラ構築などの手間が不要。
デメリット
-
複数環境の運用が難しい
無料枠で作成できるPrivateアプリが1つだけのため、ステージング・本番といった環境を増やしにくい。また、別の社内アプリを作ろうと思った時に、結局これ以外の方法を使う必要がある。 -
外部サービス依存リスク
基幹システムとしては「無料サービスの仕様変更・停止」にリスクがある。
メリットに対し、デメリットが目立ち始めたので、自前でインフラを用意することを決めました。
2. Cloud Runへの移行方針
GCP上のアプリ構成
Cloud Run上でアプリを稼働させ、データはBigQuery、シークレットはSecret Managerで一元管理します。
-
Cloud Run
Dockerイメージをサーバーレスでデプロイ。 -
BigQuery
集計用データを格納し、アプリ起動時などに参照。 -
Secret Manager
OAuthクライアントシークレットなど機密情報を安全に保管。
デプロイフロー
- GitHubにソースコードをプッシュ。
- GitHub ActionsでDockerイメージをビルドし、Artifact Registryへプッシュ。
- Cloud RunがArtifact Registryからイメージをpullして起動。
認証フローの仕組み
- ユーザーがアクセスすると、ログイン画面が表示される。
ログインボタンを押すと、StreamlitがGoogle OAuth認証ページへリダイレクトする。 - 特定のGoogle Groupに所属しているユーザーかどうかをチェックする。
- 問題なければJWTトークンを発行し、Cookieに付与する。
- 該当者のみアプリを利用可能とする。
具体的な認証の実装は以下の@coding-otterさんの記事を参考にしてください。
工夫点としては、特定のGoogle Groupに属している人にだけ閲覧権限を許可したいので、Google Workspace側と連携して、認証機能を実装しました。
これにより、権限付与の時にコードをいじらずに、Google Groupに追加するだけで閲覧権限をつけれるようになりました。
以下を参考にしました。
3. 運用時の考慮点
-
大量アクセス時のスケール制御
今回はアクセス時点での制御を行っていないので、Cloud Runではmax-instancesやconcurrencyを調整し、過負荷を防いでます。
4. 移行してみての所感
- Streamlit Community Cloudではしばらく使わないとアプリがスリープし、起動時間がかかる問題がありましたが、今回の移行で起動時間がかなり短縮されました。
- Cloud Run移行により、複数環境を立ててテストしやすくなり、本番リリース前のUATが円滑になりました。
5. まとめ
-
得られた知見
StreamlitアプリでもCloud Runであれば社内要件に合わせて自由にカスタマイズできる。
Google Oauthを使うことで、認証周りが低コストで構築しやすい。 -
今後のアップデート
IAPなどGCP標準の認証機構への切り替えを検討。
監視/アラートを強化し、さらなる安定運用を目指したい。
Discussion