Cloud Run のボリューム マウントのご紹介: アプリを Cloud Storage や NFS に接続
Google Cloud Japan Team
※この投稿は米国時間 2024 年 3 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。
Google は、デベロッパーの負担を軽減し、クラウドネイティブ アプリケーションの構築を容易にするために、Google のスケーラブルなインフラストラクチャ上に直接、フルマネージドのコンテナ プラットフォームである Cloud Run を構築しました。
現在、Cloud Run の各インスタンスは、自身のローカル ファイル システムにはアクセスできます。しかし、既存のアプリケーションがローカル ファイル システムに保存された共有データにアクセスする必要がある場合はどうでしょうか。これまで、ファイル サーバーや Cloud Storage バケットのようなストレージ システムを簡単にマウントする方法がなかったため、デベロッパーは、複雑なソリューションを利用するか、他のサービスに頼らざるを得ませんでした。そこで、Google はこのたび、プレビュー版の新機能、ボリューム マウントをリリースいたしました。
ボリューム マウントを使えば、Cloud Run のサービスやジョブにボリュームをマウントする作業が単一のコマンドで可能になります。Cloud Filestore インスタンスのように、Cloud Storage バケットや NFS 共有をマウントできます。これによりコンテナは、ストレージ バケットやファイル サーバーのコンテンツに、ローカル ファイルであるかのように、シームレスにアクセスできるようになり、ファイル システム セマンティクスを利用して、使い慣れた操作感を提供します。
以下のコマンドで Cloud Run サービスを更新することで、Cloud Storage バケットをマウントすることができます（詳細と手順は以下の「試してみる」のセクションにあります）。
ボリューム マウントはさまざまな場面で役に立ちます。
1. ストアアプリの構成
サービスに構成ファイルを追加するシナリオを考えてみましょう。アプリケーションはリリースされると、多くの場合、環境に関する情報を収集し、動作を決定するための初期設定を読み込む必要があります。
過去には、この情報を保存してマウントするために Secret Manager を使用するユーザーもいましたが、秘密にしておく必要のない構成データならば、Cloud Storage の方がソリューションとしては、より簡単です。すべての設定を好みの形式でファイルにまとめ、ファイルを Cloud Storage バケットにアップロードし、Cloud Run サービスやジョブで特定のパスにバケットをマウントするだけです。
Cloud Run では、Docker Hub から公開コンテナ イメージを直接 pull できるため、独自の構成ファイルをマウントして、公式イメージ（Grafana や Nginx など）をカスタマイズするのに非常に便利です。独自のコンテナ イメージをビルドして、構成ファイルを追加し、ホストする必要はありません。Docker Hub から公式のコンテナ イメージを直接デプロイし、Cloud Storage バケットに構成ファイルを保存して、必要な場所にマウントするだけです。
2. イベント ドリブン Cloud Storage ハンドラ
多くのアプリケーションは、イベント ドリブンの設計パターンを使って構築されます。一般的なユースケースは、Cloud Storage バケットにアップロードされる新しいファイルに基づいて、カスタムコードを実行することです。EventArc は、このようなイベントをリッスンし、Cloud Run サービスを直接トリガーするための優れたツールです。EventArc は、ファイル名と場所を含むすべての関連するイベント メタデータを転送しますが、ファイル自体は転送しません。これまでは、ファイルを取得して処理するには、Cloud Storage のクライアント SDK を使用して、明示的に取得する必要がありました。
ボリューム マウントを使えば、関連するバケットを直接マウントできます。これにより、ファイル システム経由で直接ファイルにアクセスできるようになり、ファイルを取得するためのカスタムコードが不要になります。
3. ベクトル データベース ファイルの読み込み
Langchain アプリケーションを Cloud Run 上にデプロイしている場合、ChromaDB のようなベクトル データベースが必要になるかもしれません。インデックス化されたドキュメントは常に変化しているため、サービスをステートレスに保ち、コンテナから ChromaDB コレクションを外部化するには、NFS ストレージのマウントが最適です。同時に、サービスの外部に新しいドキュメントのための専用の取り込みパイプラインを持つこともできます。
永続化された ChromaDB コレクションは、すぐに大きくなる可能性がありますが、Cloud Filestore なら Cloud Run アプリケーションのすべてのインスタンスから、これらに迅速にアクセスできます。
4. 静的なウェブサイトの提供
公開ファイル ホスティングの場合は、Cloud Storage の静的ウェブサイト ホスティング機能を直接使用できます。しかし、プライベート ネットワーキングの機能や Identity-Aware Proxy（IAP）を介したシンプルなログイン エクスペリエンスが必要な場合には、Cloud Run が最適です。
以前は、すべての静的ファイルをコンテナ イメージにコピーしてホストし、そこからファイルを提供する必要がありました。しかし、そのためには静的コンテンツを変更するたびにイメージを再構築し、サービスを再デプロイしなければなりませんでした。
ボリューム マウントを使用すると、標準の NGINX ウェブサーバーを使用して、マウントされた Cloud Storage バケットからファイルを提供できます。Cloud Run は、標準のファイル システム セマンティクスを使用してファイルにアクセスするため、DockerHub で一般公開されている公式の NGINX コンテナ イメージを直接使用できます。必要に応じて静的アセットを編集したり、新しいアセットを追加したりすることができ、すべての変更はダウンタイムなしで迅速に Cloud Run サービスに反映されます。
この設定により、ファイルを Cloud Storage バケットに保存する柔軟性を維持しながら、IAP を含むすべての Ingress の便利な機能にアクセスできます。
Cloud Storage バケットからファイルを提供するシンプルなウェブサーバーを実行するには、Docker Hub から公式の NGINX イメージをデプロイし、NGINX が静的コンテンツを探すディレクトリに、バケットをマウントします: '/usr/share/nginx/html'.単一のコマンドでこれを実行できます。
最後のステップとして、NGINX のコンテンツ キャッシュや Cloud CDN を使用して、コンテンツのキャッシュ保存を必ず設定してください。キャッシュ保存をしなければ、各リクエストが Cloud Storage GET リクエストをトリガーし、コストの増加や不要なレイテンシにつながります。
試してみる
Cloud Storage バケットや NFS ファイル共有をマウントするには、gcloud コマンドを使用して、Cloud Run YAML リソース定義を更新するか、Terraform を介してデプロイします。たとえば、新しい Cloud Run ジョブにソースベースのデプロイを実行し、次のコマンドで Cloud Storage バケットをマウントします。
同様に、NFS ファイル共有を Cloud Run にボリュームとしてマウントできます。NFS サーバーをまだお持ちでない場合は、Google Cloud が提供するフルマネージド NFS である Cloud Filestore の使用をおすすめします。
詳細と利用開始の方法については、Google のドキュメントをご覧ください。
Cloud Run のボリューム マウントにより、データへのアクセス、既存アプリケーションの移行、事前構築済みのコンテナ イメージの構成が驚くほど容易になります。ぜひプレビュー版でこの機能をお試しください。
ー 戦略的クラウド エンジニア Christoph Stanger
ー プロダクト マネージャー Karolína Netolická
