サーバーレス

Identity-Aware Proxy（IAP）で Cloud Run のセキュリティを簡素化する

Tue, 24 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Run は、アプリケーションのデプロイに適した、強力かつスケーラブルなプラットフォームです。このたび、Cloud Run のセキュリティに関する 2 つの主要な機能強化の一般提供を開始いたしました。Identity-Aware Proxy（IAP）の直接統合と、ドメインで制限された共有（DRS）に対応した Cloud Run サービスへの公開アクセスを許可する方法です。

Cloud Run への IAP の直接導入

IAP を使用すると、Google Cloud で実行されているアプリケーションへのユーザーアクセスを簡単に制御できるようになります。これまで、IAP を Cloud Run と統合するには、アプリケーションロードバランサやその他の複雑なネットワーク設定を手動で構成する必要がありました。この運用上のオーバーヘッドの増加は、サーバーレスのシンプルさという Cloud Run の中心的なメリットを損なうものでした。

今日からそれが変わります。Cloud Run で IAP を直接有効にできるようになりました。ワンクリックで実行できてロードバランサは不要、追加費用もかかりません。Google Cloud では、IAP は課金されません（一部例外あり）。また、ロードバランサの使用料金も発生しません。

Cloud Run サービスで IAP 認証を直接有効にする

メリット:

有効化の簡素化: UI で IAP を有効にするか、gcloud で単一のフラグ（--iap）を使用して有効にすることで、デプロイが大幅に簡素化され、貴重な時間と労力を節約できます。
すべてのウェブアプリに対するエンタープライズグレードのセキュリティ: ユーザーまたはグループの ID に基づく IAP の認証および認可ポリシーと、コンテキストに応じた要素（IP アドレス、位置情報、デバイスのセキュリティ状況など）を使用します。
Workforce Identity 連携のサポート: 既存の ID プロバイダを使用して、従業員やパートナーのアクセスを簡単に管理できます。
クロスオリジンリソースシェアリング（CORS）の簡素化: Cloud Run で IAP を直接構成し、CORS リクエストに対する未認証の HTTP OPTIONS を許可します。これにより、他のすべてのリクエストで確実に認証を行いながら、ブラウザのプリフライトチェックの条件を満たすことができます。

すでに、L’Oreal など、Cloud Run ワークロードを保護するために IAP を導入する組織が急増しています。

「L'Oréal は、Google Cloud の Identity-Aware Proxy（IAP）を重要なセキュリティレイヤとして利用し、Google Cloud でホストするすべてのウェブアプリケーションへのアクセスを、細心の注意を払ってフィルタおよび制御しています。IAP の魅力は、そのシンプルさと効果にあります。IAP は、無料であるだけでなく、多様なアプリケーション環境全体に非常に簡単に実装できるセルフマネージドソリューションです。このデプロイの容易さと、独自に構築したソリューションでは実現できなかったセキュリティポスチャーにより、IAP はデジタルアセットを保護するために欠かせないツールとなっています。」 - L'Oréal、グループデータおよび AI アーキテクト、Antoine Castex 氏

DRS 使用時に公開アクセスを許可する

簡素化された、Cloud Run の新しい認証 UI

Cloud Run 上の社内向けビジネスアプリケーションにおいては IAP が推奨される認証メカニズムですが、サービス間通信を管理するには Cloud IAM が依然として不可欠です。

従来、Cloud Run のデフォルトの動作では、HTTPS エンドポイントへのリクエストごとに IAM チェック（run.invoker ロール）が実行されていました。これは強力なセキュリティベースラインとなりましたが、ドメインで制限された共有ポリシーも適用されている場合は特に、一般公開アプリを作成しようとしたときにボトルネックとなる可能性がありました。

アプリケーションの [公開アクセスを許可する] をオンにすると、この IAM の「起動元」チェックを無効にできます。

この設定により、組織のポリシー、ネットワークレベルの制御、サービスのカスタム認証 / 認可といった他のセキュリティレイヤを柔軟に活用できます。また、より幅広いユースケースにも対応できます。

公開ウェブサイト: 店舗検索サイトを Cloud Run でホストし、組織のポリシーで共有が制限されている（DRS が有効である）場合でも、誰でもアクセスできるようにします。これを行うには、[公開アクセスを許可する] をオンにし、内向きを [すべて] に設定します。
プライベートマイクロサービス: ネットワークレベルのセキュリティで十分な、内部からの内向きアクセスしか行われないサービスの場合、[公開アクセスを許可する] をオンにすると IAM チェックをバイパスできます。

「Bilt Rewards では、マルチリージョントポロジにデプロイされた複数のミッションクリティカルな Cloud Run サービスに対し、「IAM の無効化」機能を利用しています。これらのインスタンスで IAM を無効にすることにより、エッジから直接、制約のないパスを確立しながら、グローバルロードバランサ上で Cloud Armor を使用してセキュリティを維持しています。この簡素化されたアプローチにより、インフラストラクチャの複雑さが軽減され、組織のポリシーを通じて組織全体のセキュリティポスチャーを保持しながら、よりパフォーマンスの高いソリューションを提供しています。」 - Bilt Rewards、最高技術責任者、Kosta Krauth 氏

ご利用にあたって

ご関心をお持ちの場合は、簡単に Cloud Run で IAP を直接有効にすることができます。

詳細:

- プロダクトマネージャー、Ruchika Goel

- Google Cloud、シニアプロダクトマネージャー、Muthuraj Thangavel

NVIDIA RTX PRO 6000 により、Cloud Run 上で高性能推論とサーバーレスコンピューティングが融合

Mon, 09 Feb 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 2 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

大規模な推論モデルの実行には、クラスタ管理や VM の手動メンテナンスなど、運用面で大きな負担が伴うことが少なくありません。こうした負担を軽減する方法の一つが、基盤となるインフラストラクチャを意識せずに利用できるサーバーレスのコンピューティングプラットフォームを活用することです。Google はこのたび、Cloud Run で NVIDIA RTX PRO™ 6000 Blackwell Server Edition GPU に対応するハイエンド推論においてサーバーレスの提供を開始いたしました。現在はプレビュー版が提供されており、Gemma 3 27B や Llama 3.1 70B といった大規模モデルも、Cloud Run でおなじみの「デプロイしたらあとは任せる」感覚でデプロイできます。予約は不要。クラスタ管理も不要。必要なのはコードだけです。

強力な GPU プラットフォーム

NVIDIA RTX PRO 6000 Blackwell GPU は、NVIDIA L4 GPU と比べて大幅な性能向上を実現しており、96 GB の vGPU メモリ、1.6 TB/秒の帯域幅に加え、FP4 および FP6 をサポートしています。これにより、基盤となるインフラストラクチャを自ら管理することなく、70B 超のパラメータを持つ大規模モデルを提供できます。Cloud Run では、NVIDIA RTX PRO 6000 Blackwell GPU を Cloud Run サービス、ジョブ、またはワーカープールに、予約不要でオンデマンドにアタッチできます。以下は、NVIDIA RTX PRO 6000 Blackwell GPU を活用してビジネスを加速できる主な活用例です。

生成 AI と推論: FP4 精度をサポートする NVIDIA RTX PRO 6000 Blackwell GPU の高効率な演算性能により、LLM のファインチューニングや推論を高速化できます。これにより、マルチモーダルモデルやテキストから画像を生成するモデルなど、リアルタイム性が求められる生成 AI アプリケーションを構築できます。さらに、Cloud Run サービス上でモデルを実行することで、迅速な起動とスケーリングのメリットも享受できます。インスタンス数が 0 の状態から、GPU ドライバがインストールされた GPU 環境を 5 秒未満で起動可能です。トラフィックが減少してリクエストがなくなると、Cloud Run は GPU インスタンスを自動的に 0 までスケールダウンします。
ファインチューニングとオフライン推論: NVIDIA RTX PRO 6000 Blackwell GPU は、Cloud Run ジョブと組み合わせることで、モデルのファインチューニングに活用できます。第 5 世代 NVIDIA Tensor コアは AI モデルと連携し、レンダリングパイプラインの高速化やコンテンツ制作の効率向上に貢献します。
特定のワークロードに最適化されたスケーリング: GPU 対応のワーカープールを使用することで、GPU ワーカーをきめ細かく制御できます。外部のカスタム指標に基づく動的スケーリングや、複雑でステートフルな処理に対応するための「常時稼働」インスタンスの手動プロビジョニングなど、用途に応じた柔軟なスケーリングを実現できます。

Cloud Run は、プロダクションレディな GPU アクセラレーテッドタスクを、最もシンプルに実行できるよう設計されています。Cloud Run の主な特長は次のとおりです。

柔軟なコンピューティングを備えたマネージド GPU: Cloud Run では、必要な NVIDIA ドライバがあらかじめインストールされているため、インフラストラクチャの準備に煩わされることなく、コードの実装に集中できます。NVIDIA RTX PRO 6000 Blackwell GPU を使用する Cloud Run インスタンスでは、最大 44 vCPU と 176 GB の RAM を構成できます。
本番環境レベルの信頼性: Cloud Run はデフォルトでゾーン冗長性を提供しており、ゾーン停止に耐えるために十分な容量をサービスに確保できます。これは、Cloud Run で GPU を使用した場合にも適用されます。また、ゾーン冗長性をオフにして、ゾーン停止が発生した場合に GPU ワークロードのベストエフォートフェイルオーバーを行うことにすれば、料金を低く抑えられるメリットがあります。
緊密な統合: Cloud Run は、Google Cloud の他のサービスとネイティブに連携します。Cloud Storage バケットをローカルボリュームとしてマウントすることで大規模なモデルの重みを読み込んだり、Identity-Aware Proxy（IAP）を使用して Cloud Run サービス宛てのトラフィックを安全に保護したりすることができます。

使ってみる

NVIDIA RTX PRO 6000 Blackwell GPU は、現在プレビュー版としてオンデマンドで利用可能です。対応リージョンは us-central1 および europe-west4 で、asia-south2 と asia-southeast1 では限定的に提供されています。オープンモデルを実行する最も簡単な方法の一つである Ollama を使用すれば、NVIDIA RTX PRO 6000 GPU を有効化した Cloud Run 上に、次のコマンドで最初のサービスをデプロイできます。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy my-service \\\r\n--image ollama/ollama --port 11434 \\\r\n--cpu 20 --memory 80Gi \\\r\n--gpu-type nvidia-rtx-pro-6000 \\\r\n--no-gpu-zonal-redundancy \\\r\n--region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6279702af0>)])]>

詳しくは、最新の Cloud Run ドキュメントおよび AI 推論のベストプラクティスをご覧ください。

-シニアプロダクトマネージャー、James Ma

-シニアエンジニアリングマネージャー、Oded Shahar

Firestore の新しい高度なクエリエンジンでアプリケーションを強化

Mon, 26 Jan 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 1 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

価値あるデータベースの特徴は、格納されているデータを簡単にクエリできることです。これにより、デベロッパーはカスタマイズされた複雑なユーザーエクスペリエンスをアプリケーション内で構築できます。先週、Google Cloud のエンタープライズクラスのスケーラブルなドキュメントデータベースである Firestore が大きく進化しました。高度なクエリエンジンが導入され、より洗練されたアプリケーションを構築できるようになりました。

Firestore ネイティブモードの一部として利用できるこの強力なエンジンは、パイプラインオペレーションと呼ばれる新しいクエリ機能を 100 個以上備えています。これらの機能はプレビュー版として公開されており、複雑なクエリをデータベース内で直接効率化します。これに加えて、インデックス作成の厳密な制御のリリースや、Query Explain や Query Insights などのオブザーバビリティツールの更新により、パフォーマンスのきめ細かい制御が可能になりました。これらの優れた機能はすべて、Firestore Enterprise エディションで利用できます。このエディションは料金モデルの透明性が高く、費用削減を図ることも可能です。これらの点すべてが、運用のオーバーヘッドを削減しながら、多くの次元にわたってデータをクエリ、変換、フィルタできる、表現豊かな高パフォーマンスアプリケーションの構築に役立ちます。同時に、Firestore 独自のサーバーレス基盤、マルチリージョンレプリケーション、事実上無制限のスケーラビリティのメリットを享受できるため、データベース管理の複雑さから解放され、イノベーションに専念できます。

Firestore は、60 万人を超える活気あるデベロッパーコミュニティを持ち、そのシンプルさが長年にわたり高く評価されてきました。2019 年には、ネイティブモードの Firestore Standard エディションが、自動生成されたインデックスを使用して高パフォーマンスを保証するシンプルなクエリインターフェースによってコラボレーションアプリケーションの開発を効率化しました。しかし、この簡素化されたクエリエンジンは、クエリの実行においてインデックス作成に大きく依存し、多くの場合、アプリケーションのライフサイクル全体で事前計画を必要とします。Enterprise エディションに高度なクエリエンジンが導入されたことで、デベロッパーはインデックスが明示的に存在するかどうかに関係なく、表現豊かなアプリケーションを構築できるようになりました。これは特に、e コマース、インタラクティブゲーム、コンテンツ管理、高度なユーザーパーソナライズなどの要求の厳しいソリューションに適しています。改良されたクエリエンジンにより、パイプラインオペレーションの作成が容易になります。複雑な集計、配列に対する直接的なクエリ、高度な文字列照合機能、詳細なフィルタリングオプションのサポートなど、洗練された新しいステージと式が用意されています。

新しいクエリエンジンとパイプラインオペレーションのエクスペリエンス

これを実現するため、Google は Firestore の既存の SDK を更新し、パイプラインオペレーションのサポートを拡大しました。現在は、集計、グループ化、フィルタリングなどの重要なタスクのために、多数のステージをスムーズに連結できるようになりました。クエリの実行にインデックスが必須とならないため、パフォーマンスを最適化するためにインデックスを作成するタイミングを自由に決められます。パイプラインオペレーションの例を見てみましょう。

注: この例は、Firestore のデータモデルと既存のクエリ方法について理解していることを前提としています。

ユーザーがレシピにハッシュタグを追加できる既存の料理レシピアプリケーションで、人気のあるハッシュタグを特定するとします。レシピ本文のような重要なデータについては、レシピをいくつかのフィールドを持つドキュメントとして表せます。ハッシュタグは文字列のみで表せるため、レシピドキュメントに文字列の配列として直接追加できます。

code_block: <ListValue: [StructValue([('code', '{\r\n title: "My recipe",\r\n instructions: "Cook the ingredients",\r\n authorId: "SomeAuthorID",\r\n hashtags: ["easy", "high protein", "low carb"],\r\n ...\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6276ba2e20>)])]>

Firestore ユーザーは、既存のコアオペレーションを使用して、レシピ内で特定のハッシュタグをクエリできます。しかし、クエリ中にドキュメント内から配列データを抽出して集計する直接的な方法は、パイプラインオペレーション以前にはありませんでした。

パイプラインオペレーションを使用すると、配列を直接「ネスト解除」できます。これにより、人気のあるハッシュタグを簡単に特定してユーザーに提案できます。JavaScript を使用してこれを実装する方法の例を以下に示します。

code_block: <ListValue: [StructValue([('code', '// ハッシュタグを人気順で 10 個取得する。\r\nconst snapshot = await db.pipeline()\r\n\u200b\r\n // レシピドキュメントのコレクションから始める。\r\n .collection("recipes")\r\n\u200b\r\n // ドキュメントを `hashtags` フィールドのみに制限する。\r\n .select("hashtags")\r\n\u200b\r\n // `hashtags` 配列内の各タグをネスト解除して独自のドキュメントにする。\r\n .unnest(field("hashtags").as("tagName"))\r\n\u200b\r\n // 複数のレシピにわたり各タグのインスタンス数をカウントし、\r\n // tagName ごとに、tagName を共有するドキュメントを 1 つのドキュメントに\r\n // 統合する。\r\n .aggregate({\r\n accumulators: [countAll().as("tagCount")],\r\n groups: ["tagName"]\r\n })\r\n\u200b\r\n // 結果のハッシュタグをカウントで並べ替える。\r\n .sort(field("tagCount").descending())\r\n\u200b\r\n // クエリ結果を上位 10 個のハッシュタグに制限する。\r\n .limit(10)\r\n\u200b\r\n .execute()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6276aaf250>)])]>

また、Firestore Enterprise エディションでは、より幅広いインデックスタイプ（単一フィールド、複合、スパース、非スパース、一意のインデックスなど）がサポートされており、クエリのパフォーマンスをさらに最大化できます。さらに、インデックスを作成するタイミングを制御できるため、Standard エディションの自動単一フィールドインデックスと比較して、全体的な書き込みパフォーマンスとストレージ使用率が向上します。これにより、書き込みオペレーション中のインデックスファンアウトを軽減できます。

インデックス作成は完全にカスタマイズ可能であるため、Enterprise エディションには、Query Explain と Query Insights という高度なオブザーバビリティツールも用意されています。これらのツールは、デベロッパーがインデックス不足を特定して、クエリを確認、最適化できるように特別に構築されています。Query Explain を使用すると、デベロッパーはクエリをプロファイリングして、クエリプランナーの詳細を包括的に把握するとともに、実行の統計情報を確認できます。これには、課金情報などの重要なデータや、クエリの実行パスに関するシステムレベルの詳細な可視性が含まれます。

Query Explain でプロファイリングすることで、クエリでインデックスが使用されているかどうかを確認し、その合計実行指標を分析する。

これに加えて、Query Insights では、レイテンシが高いクエリや頻繁に実行されているクエリがないかどうかを継続的にモニタリングし、調整が必要かどうかを検討できます。Query Insights ダッシュボードを利用することで、インデックスを導入すればパフォーマンスの向上が可能なクエリを特定できます。

Query Insights を活用して、データベースで特にレイテンシが高いクエリや、特に頻繁に実行されているクエリを特定し、スキャンされているインデックスエントリの数に基づいてインデックスの作成が必要かどうかを評価する。

ご利用中の Firestore の移行

Firestore を初めてご利用の場合、Firestore Enterprise エディションのデータベースを作成するだけで簡単に始めることができます。Firestore をすでにご利用中のデベロッパーが Firestore パイプラインオペレーションに移行するのも簡単です。統合されたインポート / エクスポートサービスを使用して、Firestore Standard エディションのデータベースから、新たにプロビジョニングされた Enterprise エディションのデータベースにデータを移行するだけです。重要な点として、Enterprise エディションでは下位互換性が維持されているため、Firestore コアオペレーションの既存のアプリケーションコードを保持できます。高度な機能を活用する適切なタイミングが来たら、次の方法でコアオペレーションのコードをパイプラインオペレーションに変換できます。

code_block: <ListValue: [StructValue([('code', 'const query = db.collection("recipes").where("authorId", "==", user.id);\r\n\u200b\r\n// クエリをパイプラインに変換する\r\nconst pipeline = db.pipeline.createFrom(query);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6276aafee0>)])]>

その後、新しいパイプライン機能をすぐに使い始めることができます。

code_block: <ListValue: [StructValue([('code', '// 最後のスニペットから\r\nconst pipeline = db.pipeline.createFrom(query);\r\n\u200b\r\nconst snapshot = pipeline\r\n .where(field("rating").greaterThan(4))\r\n .execute();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6276aaf040>)])]>

予測可能な料金と最適化された費用

Firestore Enterprise エディションでは、改善された透明性の高い料金モデルで費用を管理できます。データベースに対して実行されるすべての読み取りオペレーションと書き込みオペレーションについて、ドキュメントと関連インデックスエントリのサイズに基づいて課金されます。この新しいアプローチにより、4 キビバイト未満のドキュメントに対する読み取りオペレーションの実行時に、費用を最大 86% 削減できる可能性があります。

リアルタイムリッスンクエリの更新は、発生した時点で個別に測定、課金されます。さらに、初期費用は不要で、データベースクラスタの容量計画の誤りやデータベースシャーディングの非効率性から生じる潜在的な費用もありません。ストレージ使用量については、高可用性のための複製コピーも含め、実際に使用した容量に対してのみ課金されます。Firestore を初めてお試しになる場合は、Enterprise エディションに十分な無料枠が含まれているため、簡単に始めることができます。

Firestore パイプラインオペレーションを使ってみる

Enterprise エディションにおいて、柔軟なデベロッパーエクスペリエンスを実現する高度なクエリエンジンは、Firestore ネイティブモードと Firestore MongoDB 互換モードのどちらからでもアクセスできます。このため、デベロッパーは Firestore と MongoDB の両方のデベロッパーコミュニティから、既存のライブラリやツールを最大限に活用できます。新しい Firestore Enterprise エディションのネイティブモードで新規データベースを作成することで、Firestore パイプラインオペレーションのプレビュー版を今すぐご利用いただけます。パイプラインオペレーションの開始方法の詳細については、ドキュメントをご覧ください。

Enterprise エディションは、初期費用が不要で、十分な無料枠を用意しています。ぜひご利用ください。詳細については、https://cloud.google.com/products/firestore をご覧ください。

- Google Cloud、グループプロダクトマネージャー Minh Nguyen

- Google Cloud、スタッフソフトウェアエンジニア Joseph (JD) Batchik

金融機関のデジタルトランスフォーメーションを加速する、金融リファレンスアーキテクチャ

Thu, 23 Oct 2025 02:00:00 +0000

金融業界では、デジタルトランスフォーメーション (DX) の波が加速し、顧客体験の向上や新たなサービス創出に向けた取り組みが活発化しています。その一方で、金融機関には、極めて高度なセキュリティ、コンプライアンス、そしてシステムの安定稼働が求められます。この「攻め」と「守り」の両立という難しい課題に、クラウドはどのように貢献できるのでしょうか。

この度、Google Cloud は、日本の金融機関の皆様が直面するこれらの課題に対する一つの答えとして、「金融リファレンスアーキテクチャ」を公開しました。

こちらからダウンロードしてください。

https://cloud.google.com/resources/content/intl/ja-jp/financial-reference-architecture

近年、金融機関の重要システムにおける Google Cloud の採用は飛躍的に増え、IaaS 中心の構成に留まらない、クラウドの特性を活かしたアーキテクチャも多く見られるようになりました。本リファレンスアーキテクチャは、こうした状況を踏まえ、金融機関で求められるセキュリティやコンプライアンスのニーズに対応しつつ、IaaS / PaaS / SaaS を適材適所で組み合わせる際の指針となることを目指しています。Google Cloud はこれまでも『Well-Architected Framework』や『エンタープライズ基盤ブループリント』といったガイドを提供してきましたが、本アーキテクチャは特に日本の金融業界にフォーカスし、FISC 安全対策基準での要求事項も踏まえた、具体的で実践的な内容となっています。

「お客様からのアクセスに余裕をもったキャパシティで対応できる、リージョンレベルの障害があっても止まらない、障害時でもデータの不整合が発生しない、セキュリティ上の堅牢性を持つ。これらはどれも、金融機関の重要システムにとって欠かせない要件です。このような要件をクリアするアーキテクチャの具体例が、東西両現用やマルチクラウド・コアバンキングです。Google Cloud であれば、このようなオンプレミスであっても実現に極めて繊細な考慮が必要だったシステム構成を、シンプルな構成要素の組み合わせで実現することが可能です。」と Google Cloud プリンシパルアーキテクト猪原茂和は話します。

東西両現用のアーキテクチャ (金融リファレンスアーキテクチャ本編より)

「マルチリージョン構成の高可用リレーショナル・データベースである Spanner と、複数リージョンに負荷分散が可能な Google Cloud のロードバランサーは、東西両現用をシンプルに実現するための要です。」(Google Cloud カスタマーエンジニア渡邊誠)。

また、今回公開したリファレンスアーキテクチャに関して、株式会社三菱 UFJ 銀行よりエンドースメントをいただいています。

本リファレンスアーキテクチャは、金融機関がクラウドを活用する上で直面する、セキュリティ、コンプライアンス、そして信頼性といった重要な課題に対し、具体的かつ実践的な指針を与えてくれるものです。MUFG のデジタルバンクの勘定系を Google Cloud 上で実現する上で押さえるべき設計上の要点をコンパクトかつ網羅的に整理してあるため、自分たちの設計の点検をする際に大変役に立ちました。
-株式会社三菱UFJ銀行山下邦裕 (執行役員リテール・デジタル企画部長)

アーキテクチャの主要テーマ

本リファレンスアーキテクチャは、単なるサービスの紹介に留まりません。現代の金融システムに求められる主要なテーマを網羅し、それぞれに対する Google Cloud のアプローチを深く掘り下げています。

1. ゼロトラストと多層防御による堅牢なセキュリティ

「決して信頼せず、常に検証する」というゼロトラストの原則に基づき、ID 管理、データ保護、ネットワークセキュリティの各レイヤで多層的な防御を実装する方法を解説します。Identity-Aware Proxy (IAP) によるコンテキストに応じたアクセス制御や、VPC Service Controls によるデータ漏洩防止、Cloud Armor による Web 攻撃対策など、具体的なサービスを組み合わせた構成例を示します。「VPC Service Controls は、IaaS のみならず PaaS や SaaS も包含したセキュリティ防御を実現する、Google Cloud の特徴的な防御機構です。」(Google Cloud カスタマーエンジニア中村完)。

2. サーバレスと GKE によるモダンなアプリケーション開発

ビジネスの変化に迅速に対応するため、アプリケーション開発の俊敏性は不可欠です。本アーキテクチャでは、インフラ管理から解放されるサーバレスなコンテナ実行環境である Cloud Run や、コンテナ技術の標準である Kubernetes のマネージドサービス Google Kubernetes Engine (GKE) を活用した、モダンなアプリケーション基盤の構築方法を詳述します。特に、GKE の運用負荷を大幅に削減する Autopilot モードの活用は、開発者がビジネス価値の創出に集中できる環境を実現します。「Google Cloud 上で堅牢かつスケーラブル、そして保守性の高いアプリケーションを構築しようとするアーキテクトおよび開発者に向けて、サーバーレス中心の設計思想を意識してください。」(Google Cloud カスタマーエンジニア北田純弥)。

3. マルチリージョン、マルチクラウドによる事業継続性の確保

大規模災害やクラウドの広域障害は、もはや無視できないビジネスリスクです。本アーキテクチャでは、東京・大阪リージョンを活用した Active-Active のマルチリージョン構成 を、グローバル分散データベース Spanner を用いて実現する方法を解説します。これにより、RPO（目標復旧時点）ゼロ、RTO （目標復旧時間）ゼロを目指す、高いレベルの事業継続性を確保します。さらに、ベンダロックインを回避し、IT ガバナンスを強化するためのマルチクラウド戦略についても、具体的な構成例を交えて紹介します。

4. 生成 AI の安全な活用

生成 AI は、金融業界に大きな変革をもたらす可能性を秘めています。本アーキテクチャでは、情報の正確性、セキュリティ、プライバシーといった金融機関ならではの厳しい要件を満たしながら、生成 AI 、特に Google の AI、Gemini や Google Cloud の統合 AI 開発プラットフォーム、Vertex AI を安全に活用するためのガバナンスと技術的な対策を解説します。プロンプトインジェクションからモデルを保護する Model Armor や、信頼できる情報源に基づいて回答を生成する Vertex AI Search など、Google Cloud の先進的な AI、セキュリティについて解説します。

おわりに

本リファレンスアーキテクチャは、アクセンチュア株式会社、伊藤忠テクノソリューションズ株式会社、SCSK株式会社、株式会社NTTデータ、日本アイ・ビー・エム株式会社、株式会社野村総合研究所、リンクス株式会社をはじめとする、金融業界に深い知見を持つ多くのパートナー企業の皆様にご賛同頂き、また、完成へのご協力を頂いております。この場を借りて、ご賛同いただいたすべての関係者の皆様に心より感謝申し上げます。

Google Cloud は、これからも金融機関の皆様の信頼できるパートナーとして、オープンなエコシステムを通じて、皆様のデジタルトランスフォーメーションを安全に、そして力強く推進するための一助となれるよう、尽力してまいります。

著者
Google Cloud Japan フィナンシャルサービス事業本部カスタマーエンジニアリング技術本部
カスタマーエンジニア渡邊誠
カスタマーエンジニア中村完
カスタマーエンジニア北田純弥
プリンシパルアーキテクト猪原茂和

Google Cloud のコンピューティング費用を今すぐ削減する 11 の方法

Mon, 20 Oct 2025 01:05:00 +0000

※この投稿は米国時間 2025 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

「節約は美徳」という言葉がありますが、クラウドインフラストラクチャに関してはまさにこれが当てはまります。競争の激しい今日のビジネス環境では、ビジネスニーズを満たすためにパフォーマンスを維持する必要があります。幸いなことに、Google Cloud の Compute Engine とブロックストレージサービスは、特に移行とモダナイゼーションの取り組みにおいて、パフォーマンスを犠牲にすることなく費用を削減する多くの機会を提供します。

この記事では、Google Cloud でインフラストラクチャの費用を最適化するための 11 の重要な方法をご紹介します。簡単な調整から、長期的に大幅な費用削減につながる戦略的な意思決定まで、さまざまな方法があります。

1. 適切な VM インスタンスを選択する

Compute Engine のコストを削減する最も効果的な方法の一つは、移行とモダナイゼーションの取り組みに対して、そのワークロードに適した仮想マシン（VM）を適切に選択し、適切なサイズに設定することです。Google Cloud を初めて使用する場合でも、すでに Compute Engine を使用している場合でも、N4、C4、C4D、C4A などの最新世代の VM を採用することで、大幅な費用削減と費用対効果の向上を実現できます。

Google Cloud の Titanium アーキテクチャを搭載した最新世代の VM は、前世代よりも高速な CPU、より大きいメモリ帯域幅、より効率的な仮想化を実現するため、より少ないリソースで同じワークロードを処理できます。既存のお客様は、古い世代の VM から最新の VM に移行することで、総費用を大幅に削減できるだけでなく、現在のパフォーマンスレベルを上回ることもできます。切り替えを行った組織は、クラウドコンピューティング費用を大幅に削減しながら、パフォーマンスが 20 ～ 40% 向上したと報告しています。たとえば、Elastic は、Google Cloud の Arm ベースの Axion CPU をベースにした汎用 C4A マシンシリーズを活用して、ワークロードの効率とパフォーマンスを大幅に向上させました。

汎用 VM に加えて、お客様固有の要件に対応する特殊なマシンタイプも提供しています。H4D などのコンピューティング最適化 HPC VM は、ハイパフォーマンスコンピューティングとデータ分析向けに設計されており、要求の厳しいワークロードに優れたパフォーマンスを提供します。M4 インスタンスと X4 インスタンスはメモリ使用量の多いアプリケーションに対応し、Z3 インスタンスはストレージ使用量の多いワークロードに最適です。さらに、ハードウェア環境を完全に制御し、パフォーマンスを最大限に分離する必要がある場合は、ベアメタルインスタンスをご利用いただけます。

これらのオプションにより、最も特殊でパフォーマンスが重要なワークロードでも、Compute Engine ポートフォリオ内で最適で費用対効果の高い環境を見つけることができます。

2. ブロックストレージの選択を最適化する

ワークロードの動作を確保しながらブロックストレージの TCO を削減する最善の方法は、リソース効率を高めることです。Hyperdisk を使用すると高性能と高効率の実現が容易になり、これはブロックストレージをワークロードに合わせた最適化と、ストレージプールの活用によって行います。これらの各機能と、それらを使用してブロックストレージの TCO を削減する方法について、以下で説明します。

ワークロードの最適化: Hyperdisk を使用すると、容量とパフォーマンスのそれぞれを個別に調整して、ブロックストレージのリソースをワークロードに最適化できます。Hyperdisk では、ボリュームレベルでパフォーマンスと容量を個別にプロビジョニングできます。この機能を利用すると、容量とパフォーマンスを必要なだけ過不足なく購入できます。また、Hyperdisk Balanced の「ベースライン」パフォーマンス（すべてのボリュームに無料で含まれるパフォーマンス）を利用すれば、追加のパフォーマンスを購入しなくても、ほとんどの VM に対応できます。

ストレージプール: Hyperdisk は、シンプロビジョニングされたパフォーマンスと容量を提供する唯一のハイパースケールクラウドブロックストレージです。Hyperdisk ストレージプールを使用すると、ワークロードに必要な集約されたパフォーマンスと容量をプロビジョニングしながら、ワークロードが必要とするボリュームレベルの容量パフォーマンス（シンプロビジョニングとも呼ばれる）をプロビジョニングできます。これにより、プロビジョニングしたボリュームの総量ではなく、必要なリソースに対して料金を支払うことができます。その結果、ブロックストレージの全体的な TCO を最大で 50% も削減できます。

ワークロードに適したブロックストレージの選び方や、Hyperdisk からどのようなメリットが得られるかについて詳しくは、こちらのブログをご覧ください。

3. カスタムコンピューティングクラスを検討する

最新世代の VM を最大限に活用するために、Google Kubernetes Engine（GKE）のカスタムコンピューティングクラス（CCC）は、コンピューティングの選択を最適化し、高可用性を実現する高度な方法を提供します。ワークロードに単一のマシンタイプを使用するのではなく、VM インスタンスタイプの優先順位付きリストを定義できます。これにより、最新世代の VM を含む、最新で最も費用対効果の高い VM を最優先に設定できます。GKE カスタムコンピューティングクラスは、指定した優先順位リストに基づいてインスタンスを自動的に、かつシームレスにスピンアップする機能を提供します。この機能は、最も費用対効果の高いオプションを目指しながら、コンピューティング容量の可用性を最大化するのに役立ちます。これにより、ワークロードは手作業を経ずに確実にスケーリングできます。

カスタムコンピューティングクラスが費用の最適化にどのように役立つか、具体的なユースケースをいくつかご紹介します。

費用対効果の高いフォールバックの自動スケーリング: 需要がピークに達すると、高可用性ではあるものの費用対効果の低い VM タイプを使用して自動スケーリングしたくなるかもしれません。CCC では、段階的なアプローチを採用できます。費用対効果の高いフォールバックの代替案を複数設定することによって、需要が増加した場合に GKE はまず最も費用対効果の高いオプションを使用しようとし、需要を満たすための必要に応じて、リスト内の他の選択肢に徐々に移行します。
AI/ML 推論: AI/ML 推論ワークロードの実行には、多くの場合、相当なコンピューティングリソースが必要です。CCC を使用すると、オフピーク時にアイドル状態になる可能性のある大規模な静的予約を維持する代わりに、最小限のベース予約をプロビジョニングし、Spot VM などの費用対効果の高い容量タイプを活用して、ピーク時の推論需要を処理できます。これらはすべて、CCC 構成を通じてオーケストレーションされます。
新しい VM 世代の導入: GKE カスタムコンピューティングクラスの機能とコンピューティングフレキシブル確約利用割引（Flex CUD）を組み合わせて、N4 や C4 などの費用対効果の高い新しい VM シリーズの導入に伴うリスクを軽減します。CCC では、フォールバックオプションを定義してワークロードの復元力を確保できます。一方、フレキシブル CUD では、使用する具体的な VM シリーズに関係なく、対象となるコンピューティングの総費用に割引が適用されるため、財務上の適応性が得られます。この二重のアプローチは、中断することなく最新のハードウェアを活用するための安全で費用対効果の高い戦略です。詳細については、こちらのブログをご覧ください。
柔軟な Spot VM の使用: Spot VM は大幅なコスト削減を実現しますが、プリエンプトされる可能性があります。単一の Spot VM の構成に限定すると、容量が利用できなくなるリスクが高まります。CCC では、複数のフォールバック Spot VM タイプを定義できます。この「スポットサーフィン」機能により、アプリケーションは費用対効果の高いスポット容量を維持できます。プライマリの選択肢が利用できない場合は、代替のスポットインスタンスタイプに自動的にピボットします。

つまり、GKE CCC を活用することで、オンデマンド、スポット、DWS FlexStart、CUD でカバーされるインスタンスなど、さまざまな VM タイプと使用量モデルを巧みに組み合わせて、ワークロードの固有のニーズとパターンに適応する、復元力が高く、費用対効果に優れたインフラストラクチャを構築できます。

4. カスタムマシンタイプ（CMT）を活用する

カスタムマシンタイプは N4 VM で利用でき、仮想マシンをぴったりと仕様に合わせて構成できます。過剰な容量が含まれている可能性のある事前定義されたマシンタイプから選択するのではなく、ワークロードに合わせて CPU とメモリの比率を調整できるため、実際に使用したリソースに対してのみ料金を支払うことができます。この的を絞ったアプローチにより、無駄を最小限に抑え、クラウド支出を大幅に削減できます。特に、オンプレミスから Google Cloud に移行する場合や、他のクラウドプロバイダから移行する場合に効果的です。

この柔軟性は、アプリケーションに標準のサービスとあまり一致しない独自のリソースプロファイルがある場合に特に役立ちます。カスタムマシンタイプを使用すると、ニーズに最適な環境を構築できます。特定のコンピューティングリソースを過剰にプロビジョニングして他のリソースを制約するような妥協を避けることで、Compute Engine デプロイメント全体でパフォーマンスの向上と費用の効率化の両方を実現できます。

たとえば、16 個の vCPU と 70 GB のメモリで最適に動作するメモリ集約型のワークロードがあるとします。通常、標準シェイプでは 128 GB のメモリを搭載した VM を選択する必要があるか、他のクラウドコンテキストでは、プロビジョニングされたリソースが余分になるため、ワークロードの実行コストが高くなります。カスタムマシンタイプを使用すると、16 個の vCPU と 70 GB のメモリを搭載した VM を簡単に起動でき、標準の N4-highmem-16 VM と比較して 18% の費用削減を実現できます。

5. 確約利用割引を最大限に活用する

CUD は、コンピューティングのニーズが安定していて予測可能な組織にとって、費用を削減する戦略的な機会となります。1 年間または 3 年間のリソース使用量を確約することで、オンデマンド料金と比較してクラウド費用を最大 70% 削減できます。このアプローチは、予算を予測可能なもにするだけでなく、固定インフラストラクチャの支出を財務上の利点に変えるため、コアビジネス機能をサポートする安定したワークロードに最適です。

Google Cloud は、さまざまな運用モデルに対応できるよう、柔軟な CUD 構造を提供しています。リソースベースのコミットメントは特定のマシンタイプとリージョンを対象とし、フレキシブルコミットメントはプロジェクト、リージョン、マシンシリーズ全体に割引を適用します。これは動的な環境に最適です。過去の使用状況を分析し、将来のニーズを予測することで、これらの割引に適したワークロードを特定し、節約した費用をイノベーションやスケーリングの取り組みに再投資できます。

6. 未使用のディスク容量を管理する

実際に使用した量に関係なく、プロビジョニングされたディスク容量の合計に対して料金が発生します。多くの組織は「念のため」にストレージを過剰にプロビジョニングする傾向があり、その結果、不要で高額な無駄が発生することがよくあります。たとえば、100 GB のディスクをプロビジョニングしても、実際に使用するのは 20 GB のみの場合、100 GB 全体の料金を支払うことになります。ストレージの割り当てを一般的なサイズに切り上げるのではなく、意図的で正確に行うことで、大幅な費用削減につながります。

費用を最適化するには、いくつかのベストプラクティスを採用することが重要です。Ops エージェントを使用して、インフラストラクチャ全体のディスク使用量を定期的に監査し、非効率な部分を特定して排除します。実際の使用量に合わせてディスクのサイズを変更し、成長のための合理的なバッファを確保します。Google Cloud で自動アラートを実装する Cloud Monitoring を使用して、使用率の低いディスクを検出して是正措置を講じる。ステートレスアプリケーションの場合は、より小さいブートディスクイメージを使用してオーバーヘッドを最小限に抑え、費用をさらに削減することを検討してください。

さらに、費用を削減して効率を向上させるために、次の最適化戦略を検討してください。

Google Cloud のモニタリングツールを使用して、CPU、メモリ、ディスクの使用状況を時系列で追跡する。
定期的なレビューサイクルを確立して、過剰にプロビジョニングされたリソースを特定し、適切なサイズに調整する。
さまざまな VM 構成でワークロードをテストし、費用とパフォーマンスの最適なバランスを見つけます。

7. Spot VM を使用する

Spot VM は、標準の仮想マシンと同じマシンタイプと構成オプションを提供しますが、費用は大幅に削減されます。通常は 60% ～ 91% の割引が適用されます。費用対効果が高い一方で、短時間でプリエンプションされる可能性があるため、フォールトトレラントで、予期しない中断から迅速に復旧できるワークロードに最適です。Spot VM は、未使用のコンピューティング容量を活用するように設計されており、高性能リソースへのアクセスを損なうことなくクラウド費用を最適化できます。

Spot VM が有望なユースケースには、バッチ処理ジョブ、ビッグデータと分析のワークロード、継続的インテグレーションとデプロイ（CI/CD）パイプライン、自動スケーリンググループで実行されるステートレスウェブサーバー、コンピューティング負荷の高いタスクなどがあります。中断に対処するように適切に設計されている場合（たとえば、ジョブのチェックポイント、ロードバランシング、タスクキューを使用するか、GKE カスタムコンピューティングクラスを使用する場合（詳細は上記を参照））、Spot VM は、高い可用性とシステム復元力を維持しながらインフラストラクチャの費用を最小限に抑えるうえで重要な役割を果たすことができます。このようなシナリオで Spot VM を活用すると、特にコンピューティング需要が変動する場合や、時間に柔軟性がある場合に、費用対効果の高いスケーリングが可能になります。

8. 最適化案を適用する

Google Cloud の Recommender は、クラウドリソースを効率的に最適化できるように設計された強力なツールです。Google Cloud コンソールを閲覧していると、特定のリソースの横に電球アイコンが表示されることがあります。これは、Google の推奨エンジンによって特定された改善の可能性を示しています。Recommender は、リアルタイムの使用パターンと現在のリソース構成を分析することで、各ユーザーの固有の環境に合わせた、実用的な情報を提供します。このインテリジェントシステムは、費用の削減だけでなく、セキュリティ、パフォーマンス、信頼性、管理効率、環境サステナビリティの向上につながる機会に注意を促してくれます。

たとえば、過去 1 ～ 14 日間に使用されていない VM インスタンスを特定するのに役立つアイドル状態の VM の推奨事項があります。一般的な推奨事項としては、より適切なマシンタイプへの切り替え、使用率の低いコンピューティングインスタンスの適正サイズ設定、費用対効果の高いストレージソリューションの採用などがあります。このツールを使用すると、これらの変更の多くを直接適用できるため、最適化プロセスを効率化できます。ワークロードを継続的に評価し、データドリブンな自動提案を行うことで、おすすめハブは、組織がクラウドのパフォーマンスを維持しながら、より効果的に費用を管理するお役に立ちます。

9. 自動スケーリングとスケジューリングを活用する

コンピューティングリソースを実際の需要パターンに合わせることは、クラウドの無駄を削減し、全体的な費用対効果を高める最も効果的な方法の一つです。多くの組織は、ピーク時のワークロードに対応するためにリソースを過剰にプロビジョニングしており、オフピーク時にはマシンが十分に活用されていません。コンピューティング容量を、営業時間や季節のトレンドなど、リアルタイムまたは予測可能な使用パターンに緊密に合わせることで、パフォーマンスを犠牲にすることなく、不要な支出を大幅に削減できます。

この効率性を実現する鍵となるのが自動スケーリングです。実際、Google Compute Engine の仮想マシンの自動スケーリングを活用しているお客様は、インフラストラクチャの費用を平均 40% 以上削減しています。

自動スケーリング戦略を実装して、CPU 使用率、ロードバランシング容量、またはカスタムアプリケーション指標に基づいてリソースを動的に調整できます。これにより、ワークロードは必要なときに必要なコンピューティング能力を受け取ることができ、需要が低い期間は自動的にスケールダウンされます。

営業時間や季節のイベントの予定に合わせて変動するワークロードなど、パターンが予測可能なワークロードの場合、スケジュールベースのスケーリングは特に強力なツールです。このアプローチでは、需要の増加を見越してリソースを事前に増やし、需要が落ち着いたときにスケールダウンできるため、常にオーバープロビジョニングすることなく必要なパフォーマンスを確保できます。

自動スケーリングに加えて、いくつかの実用的な実装手法を使用することで、リソースの使用をさらに最適化できます。インスタンススケジュールを設定すると、営業時間に応じて開発環境とテスト環境を自動的に起動および停止できます。これは、シンプルながら非常に効果的なアプローチであり、最大 70% の費用削減につながります。また、メンテナンスの時間枠を利用して、使用量が少ない期間にアップデートとシステム変更を集中させることで、中断とリソース消費を削減できます。これらの戦術を組み合わせることで、インフラストラクチャの費用を抑えながら、高可用性とパフォーマンスを維持できます。

10. 詳細な請求金額の分析で費用を把握する

Google Cloud で費用削減戦略を実装する前に、現在の支出を詳細に把握することが不可欠です。Google Cloud の請求パネルでは、個々の SKU ごとの費用など、費用の詳細な可視性が提供されます。このレベルの透明性により、費用の流れを追跡し、潜在的な非効率性を特定できます。まず、請求ダッシュボードを定期的に確認して、使用量の傾向をモニタリングし、異常を検出します。リソースにラベルとタグを適用すると、特に複数のプロジェクトや部門がある複雑な環境で、費用を正確に分類して割り当てることができます。

さらに、予算アラートを設定すると、費用が事前定義されたしきい値に近づいた場合や超えた場合に通知されるため、費用超過を未然に防ぐことができます。また、アクティブに使用されなくなった仮想マシンや永続ディスクなど、未使用またはアイドル状態のリソースを特定して排除することも重要です。これらはシャットダウンまたは削除することで、費用をすぐに削減できます。費用構造を徹底的に分析することで、「低く垂れ下がった果実」である価値がほとんど、あるいはまったくないリソースを特定し、データドリブンな意思決定を行ってクラウドの使用を効率的に最適化できます。

11. サーバーレスの代替手段を検討する

最後に、Google Cloud のサーバーレスコンピューティングサービスは、従来の仮想マシンに代わる魅力的な選択肢であり、費用対効果の向上、運用の簡素化、スケーラビリティの向上を実現できます。インフラストラクチャ管理を抽象化することで、サーバーレスプラットフォームでは、チームがサーバーのプロビジョニング、スケーリング、メンテナンスを心配することなく、コードの作成とデプロイに集中できます。この移行により、運用オーバーヘッドを削減できるだけでなく、コンピューティング費用をアプリケーションの使用量に直接合わせることで費用を削減できます。

さまざまなサーバーレスオプションが用意されており、それぞれが異なるワークロードに合うように作られています。

Cloud Run は、迅速なスケーリングと柔軟なデプロイが必要なコンテナ化されたアプリケーションを実行するために設計されています。Cloud Run Functions は、マイクロサービスや自動化タスク向けの軽量なイベントドリブンコード実行をサポートします。GKE（Autopilot モード）は、ノードの管理とスケーリングを自動化することで Kubernetes の運用を簡素化し、基盤となるインフラストラクチャを処理することなく Kubernetes ワークロードを実行できるようにします。これらのオプションはすべて、割り当てではなく使用量に基づいて課金されるため、アイドル状態のリソースやオーバープロビジョニングに関連する費用を大幅に削減できます。そのため、変動するワークロードや予測不可能なワークロードに特に役立ちます。Cloud Run と GKE はどちらも GPU をサポートしており、両者間の移行も柔軟に行えます。Cloud Run から始めて GKE に移行することも、その逆も可能です。一部のお客様は、ワークロードに両方のサービスを利用されています。Kubernetes API にアクセスする必要がある場合は、GKE から始めるのが良いでしょう。それ以外の場合は、Cloud Run から始めます。

今すぐ費用削減を始めましょう

Google Cloud に移行して、自社のワークロードに必要なものを妥協することなく、インフラストラクチャの費用を最適化できます。Google Cloud を初めて使用する場合は、まず移行評価から始めます。Google Cloud の Migration Center を使用すると、Google Cloud への移行によって得られる潜在的な費用削減額を明確に把握できます。また、ワークロードの推奨パスの詳細や TCO レポートも確認できます。この記事の戦略を適用して、大幅なコスト削減を実現しましょう。

-グループプロダクトマネージャー、Alex Bestavros

-Google Cloud、プロダクト管理担当、Sai Gopalan

新しい Gemini CLI 拡張機能でアプリのデプロイとセキュリティ分析を自動化

Wed, 01 Oct 2025 01:10:00 +0000

※この投稿は米国時間 2025 年 9 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

セキュリティの脆弱性を検出して修正します。アプリをクラウドにデプロイします。コマンドラインを離れる必要はありません。

このたび、2 つの新しい拡張機能（セキュリティ拡張機能と Cloud Run 拡張機能）を通じて提供する Gemini CLI の未来像を、初めてご紹介します。これによって、お客様のターミナルとクラウドの間にあるギャップを取り払います。これらの拡張機能は、ワークフローの重要な部分をシンプルで直感的なコマンドで処理するように設計されています。

1）/security:analyze は、ローカルリポジトリで包括的なスキャンを実行します。GitHub プルリクエストのサポートも近日中に提供予定です。これにより、セキュリティが開発サイクルの自然な一部になります。

2）/deploy は、フルマネージドのサーバーレスプラットフォームである Cloud Run にアプリケーションを数分でデプロイします。

これらのコマンドは、Gemini CLI の新しい拡張性フレームワークの最初の表現です。Gemini CLI 拡張機能の全容については近日中に詳しくご紹介しますが、これらの機能をいち早く皆様にお届けしたく、今後の展開を少しだけご紹介します。

セキュリティ拡張機能: /security:analyze でセキュリティ分析を自動化

チームが開発ライフサイクルの早い段階でソフトウェアの脆弱性に対処できるよう、Google は Gemini CLI Security 拡張機能をリリースします。この新しいオープンソースツールはセキュリティ分析を自動化し、ターミナルで /security:analyze コマンドを使用するか、近日中にリリースされる GitHub Actions 統合を通じて、問題をプロアクティブに検出して修正できるようにします。

ローカル開発ワークフローと CI/CD パイプラインに直接統合されたこの拡張機能は、

コード変更の分析: 拡張機能がトリガーされると、ローカルの変更または pull リクエストの git diff が自動的に取得されます。
脆弱性を特定: 専用のプロンプトとツールを使用して、Gemini CLI は、ハードコードされたシークレット、インジェクションの脆弱性、アクセス制御の不備、安全でないデータ処理など、幅広い潜在的な脆弱性について変更を分析します。
実用的なフィードバックを提供: Gemini は、詳細でわかりやすいレポートをターミナルに直接、またはプルリクエストのコメントとして返します。このレポートは、問題を指摘するだけでなく、潜在的なリスクを説明し、具体的な修復の提案を行うことで、問題を迅速に修正し、その過程で学習できるようにします。

レポートの生成後、Gemini CLI にレポートをディスクに保存するよう指示したり、各問題の修正を実装するよう指示したりすることもできます。

/security:analyze の使用を開始する

セキュリティ分析をワークフローに統合するのは簡単です。まず、Gemini CLI をダウンロードし、拡張機能をインストールします（Gemini CLI v0.4.0 以降が必要）:

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/google-gemini/gemini-cli-security'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62760f6820>)])]>

最初のスキャンを実行します。

ローカル: ローカルで変更を加えたら、Gemini CLI で /security:analyze を実行するだけです。
CI/CD（近日提供予定）: セキュリティ分析を CI/CD ワークフローに直接組み込みます。まもなく、GitHub アクションを構成して、pull リクエストが開かれたときに自動的にレビューできるようになります。

これはほんの始まりにすぎません。チームは拡張機能の機能をさらに強化するために積極的に取り組んでおり、コミュニティにも、バグの報告、機能の提案、セキュリティプラクティスの継続的な改善、コードの改善の提出を通じて、このオープンソースプロジェクトに貢献していただくよう呼びかけています。

完全なドキュメントと投稿については、公式 GitHub リポジトリをご覧ください。

Cloud Run 拡張機能: /deploy でデプロイを自動化

Gemini CLI の /deploy コマンドは、ウェブアプリケーションのデプロイパイプライン全体を自動化します。ローカルワークスペースから直接プロジェクトをデプロイできるようになりました。コマンドを発行すると、Gemini はライブアプリケーションの公開 URL を返します。

/deploy コマンドは、Cloud Run MCP サーバーを使用して、コマンドラインからウェブアプリケーションとクラウドサービスをデプロイする完全な CI/CD パイプラインを自動化します。以前は、ビルド、コンテナ化、プッシュ、構成という複数のステップが必要でしたが、現在は Gemini CLI 内から直感的な単一のコマンドで実行できます。

この機能は、ターミナルの Gemini CLI、Gemini Code Assist エージェントモードを介した VS Code、Cloud Shell の Gemini CLI の 3 つの異なるサーフェスからアクセスできます。

ターミナルで Gemini CLI の /deploy コマンドを使用して、アプリケーションを Cloud Run にデプロイする

/deploy を使ってみる:

Google Cloud の既存ユーザーは、ターミナルの Gemini CLI で /deploy を簡単に使い始めることができます。

前提条件: マシンに gcloud CLI がインストールされ、構成されていること。既存のアプリがあるか、Gemini CLI を使用してアプリを作成すること。

ステップ 1: Cloud Run 拡張機能をインストールする/deploy コマンドは、Cloud Run 拡張機能に含まれている Model Context Protocol（MCP）サーバーを介して有効になります。Cloud Run 拡張機能をインストールするには（Gemini CLI v0.4.0 以降が必要）、次のコマンドを実行します。

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/GoogleCloudPlatform/cloud-run-mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62760f6310>)])]>

ステップ 2: Google Cloud で認証する次のコマンドを実行して、ローカル環境が Google Cloud アカウントに対して認証されていることを確認します。

code_block: <ListValue: [StructValue([('code', 'gcloud auth login\r\ngcloud auth application-default login'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62760f62b0>)])]>

ステップ 3: アプリをデプロイするターミナルでアプリケーションのルートディレクトリに移動し、「gemini」と入力して Gemini CLI を起動します。チャットに入ったら、「/deploy」と入力してアプリを Cloud Run にデプロイします。

これで、しばらくすると、Gemini CLI から、新しくデプロイしたアプリケーションにアクセスできる公開 URL が返されます。Google Cloud コンソールにアクセスして、Cloud Run で実行されている新しいサービスを確認することもできます。

この機能は、ターミナルの Gemini CLI のほか、Gemini CLI を利用した Gemini Code Assist のエージェントモード、Cloud Shell の Gemini CLI でも利用できます。Cloud Shell の Gemini CLI では、認証手順が自動的に処理されます。

/deploy コマンドを使用して、Gemini Code Assist エージェントモードで VS Code の Cloud Run にアプリケーションをデプロイする。

堅牢な拡張機能エコシステムの構築

セキュリティ拡張機能と Cloud Run 拡張機能は、Gemini CLI のための豊富でオープンなエコシステムを構築するために設計された新しいフレームワーク上に構築された、Google の最初の拡張機能の 2 つです。Google は、あらゆるデベロッパーが CLI の機能を拡張およびカスタマイズできるプラットフォームを構築しています。これは、プラットフォームの可能性を垣間見ることができる初期プレビューにすぎません。拡張機能プラットフォームのより包括的な概要と、独自の拡張機能の構築と共有を開始する方法については、近日中にご紹介します。

今すぐ Gemini CLI をお試しください。GitHub はこちらからアクセスできます。

ーグループプロダクトマネージャー、Prithpal Bhogill

ープロダクトマネージャー Evan Otero

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

Thu, 17 Jul 2025 03:00:00 +0000

※この投稿は米国時間 2025 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、次世代の AI アプリケーションとエージェントアプリケーションをできるだけシームレスに構築、デプロイできるように取り組んでいます。このたび、Google はDocker とのコラボレーションにより、デプロイワークフローを大幅に簡素化し、高度な AI アプリケーションをローカル開発から Cloud Run に簡単に移行できます。

compose.yaml を Cloud Run に直接デプロイ

以前は、開発環境と Cloud Run などのマネージドプラットフォームのギャップを埋めるには、インフラストラクチャを手動で変換して構成する必要がありました。MCP サーバーと自己ホスト型モデルを使用するエージェントアプリケーションは、さらに複雑さを増しました。

オープンソースの Compose Specification は、開発者がローカル環境で複雑なアプリケーションをイテレーションする最も一般的な方法の一つであり、Docker Compose の基盤となっています。そして、gcloud run compose up によって、Docker Compose のシンプルさが Cloud Run にもたらされ、このプロセス全体が自動化されます。現在限定公開プレビュー版のこの機能を使用すると、既存の compose.yaml ファイルを単一のコマンドで Cloud Run にデプロイできます。これには、ソースからのコンテナのビルドや、データ永続化のための Cloud Run のボリュームマウントの活用も含まれます。

Cloud Run で Compose Specification をサポートすることで、ローカルとクラウドのデプロイを簡単に移行できます。同じ構成形式を維持できるため、一貫性が確保され、開発サイクルが加速します。

「Docker Compose は最近、エージェントアプリケーションをサポートするように進化しました。GPU を利用した実行をサポートする Google Cloud Run にもそのイノベーションが広がったことを嬉しく思います。Docker と Cloud Run を使用することで、開発者はローカルでイテレーションを行い、1 つのコマンドでインテリジェントエージェントを本番環境に大規模にデプロイできるようになりました。これは、AI ネイティブな開発をアクセス可能で構成可能なものにするための大きな一歩です。Google Cloud との緊密なコラボレーションを継続し、開発者が次世代のインテリジェントアプリケーションを構築、実行する方法を簡素化できることを楽しみにしています」- Docker、エンジニアリングおよびプロダクト担当エグゼクティブバイスプレジデント Tushar Jain 氏

AI アプリケーションのホーム、Cloud Run

Cloud Run には、Compose Specification のサポート以外にも、AI に適したイノベーションが備わっています。Google は最近、Cloud Run GPU の一般提供を発表しました。これにより、AI ワークロードに GPU を利用したい開発者にとって、導入の大きな障壁が取り除かれました。Cloud Run は、秒単位の課金、ゼロへのスケーリング、迅速なスケーリング（gemma3:4b モデルの場合、最初のトークンまでの時間は約 19 秒）を備えており、LLM のデプロイとサービングに最適なホスティングソリューションです。

また、Cloud Run は Docker が最近発表した OSS MCP Gateway と Model Runner の強力なソリューションでもあり、開発者は AI アプリケーションをローカルからクラウドのプロダクションにシームレスに移行できます。Docker が最近オープンな Compose Specification に「モデル」を追加したことをサポートすることで、これらの複雑なソリューションを 1 つのコマンドでクラウドにデプロイできます。

まとめ

上記のデモの compose ファイルを確認しましょう。これは、ソースから構築され、ストレージボリューム（volumes で定義）を利用するマルチコンテナアプリケーション（services で定義）で構成されています。また、新しい models 属性を使用して、AI モデルと、使用するランタイムイメージを定義する Cloud Run 拡張機能を定義します。

code_block: <ListValue: [StructValue([('code', 'name: agent\r\nservices:\r\n webapp:\r\n build: .\r\n ports:\r\n - "8080:8080"\r\n volumes:\r\n - web_images:/assets/images\r\n depends_on:\r\n - adk\r\n\r\n adk:\r\n image: us-central1-docker.pkg.dev/jmahood-demo/adk:latest\r\n ports:\r\n - "3000:3000"\r\n models:\r\n - ai-model\r\n\r\nmodels:\r\n ai-model:\r\n model: ai/gemma3-qat:4B-Q4_K_M\r\n x-google-cloudrun:\r\n inference-endpoint: docker/model-runner:latest-cuda12.2.2\r\n\r\nvolumes:\r\n web_images:'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62782b6220>)])]>

AI の未来を築く

Google は、オープンスタンダードを採用し、さまざまなエージェントフレームワークをサポートすることで、デベロッパーに最大限の柔軟性と選択肢を提供することに尽力しています。 Cloud Run と Docker に関する今回のコラボレーションは、デベロッパーがインテリジェントアプリケーションを構築、デプロイするプロセスを簡素化するという Google の目標を達成するためのもう一つの例です。

Compose Specification のサポートは、信頼できるユーザー様にご利用いただけます。限定公開プレビュー版にこちらからご登録ください。

-Cloud Run 担当プロダクトマネージャー、Justin Mahood

-Google Cloud、エンジニアリング担当ディレクター、Yunong Xiao

Cloud Run ワーカープールで Kafka ワークロードのスケーリングを簡単に

Tue, 08 Jul 2025 02:20:00 +0000

※この投稿は米国時間 2025 年 6 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

Apache Kafka は、多くのイベントドリブンアーキテクチャとストリーミングデータパイプラインに不可欠です。しかし、Kafka トピックからのデータを処理するアプリケーションである Kafka コンシューマーを効果的にスケールするのは容易ではありません。

今回は、Cloud Run で Kafka コンシューマーワークロードを自動スケールする際の効率と費用対効果を高める 2 つの機能、Cloud Run ワーカープール（公開プレビュー版）とオープンソースの Cloud Run Kafka オートスケーラーについてご紹介します。この 2 つの機能は、Google Cloud Next ’25 で発表されました。

課題: pull ベースのワークロードのスケーリング

Kafka コンシューマーは「pull」モデルで動作し、Kafka ブローカーからデータを能動的に取得します。このアーキテクチャは、データをコンシューマーに送信する「push」システムとは根本的に異なります。そのため、CPU 使用率や受信 HTTP リクエストのスループットなどの指標は、処理需要の判断材料としては不十分です。Kafka コンシューマーのワークロードの真の指標となるのは「オフセットラグ」です。これは、トピックパーティションで利用可能な最新メッセージのオフセットと、そのパーティションのコンシューマーグループによってコミットされた最後のオフセットの差です。

オフセットラグ（Kafka ブローカーに存在）などのキュー対応の指標を自動スケーリングの入力として組み込むことで、メッセージのバックログを最小限に抑え、リソース使用率を最適化できます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f627734c040>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

pull ベースのワークロード向けの Cloud Run ワーカープール

スケーリングの課題を解決するには、まず、これらの pull ベースのワークロードを効率的に実行するように設計された環境が必要です。そこで役立つのが Cloud Run ワーカープールです。これは、Cloud Run ではこれまで困難だった Kafka コンシューマーやその他のバックグラウンドプロセッサの実行のための専用の基盤を提供します。

Cloud Run の 3 つの主なリソースタイプ

Cloud Run サービスはリクエストドリブン型の HTTP ワークロード向けに、Cloud Run ジョブは完了まで実行されるバッチタスク向けに調整されていますが、ワーカープールは、HTTP 以外の継続的な pull ベースのバックグラウンド処理に最適な、独自のリソースタイプです。ワーカープールは、Kafka コンシューマーに最適な固有の機能を提供します。

バックグラウンド処理向けに設計: サービスとは異なり、ワーカープールはパブリック HTTP エンドポイントを必要としません。ヘルスチェックのポートを管理する必要がなくなるため、ネットワークの攻撃対象領域が縮小され、アプリケーションコードが簡素化されます。
インスタンス分割による段階的なデプロイ: ワーカープールでは、pull ベースのワークロードに合わせて調整されたデプロイ戦略が使用されます。これらのワークロードは HTTP トラフィックを処理しないため、トラフィックを分割するのではなく、リビジョン間でインスタンスを分割することでロールアウトを管理します。たとえば、4 つのインスタンスを持つワーカープールの場合、25%（1 つのインスタンス）を新しいカナリアリビジョンに、75%（3 つのインスタンス）を現在の安定したリビジョンに割り当てることができます。
大幅な費用削減: ワーカープールでは、インスタンス課金の Cloud Run サービスと比較して、CPU とメモリの料金が最大 40% 削減されます。

ワーカープールは、Google Cloud CLI（gcloud beta run worker-pools）で、公式の Terraform リソースとして、または再編成された Google Cloud コンソールインターフェースで利用できます。

新しいワーカープールリソースが表示された Cloud Run ユーザーインターフェース

Kafka オートスケーラーを使用したキュー対応の自動スケーリング

ワーカープールは適切な環境を提供しますが、それでもオフセットラグに基づいてスケールするメカニズムは必要です。オープンソースの Cloud Run Kafka オートスケーラーは、お客様がデプロイするツールで、ワーカープール（またはインスタンス課金サービス）と連携して、リアルタイムの需要に基づいてコンシューマーインスタンスを動的に調整します。

これは Google Cloud Platform のマネージド機能ではなく、お客様がご自身のプロジェクトで制御、デプロイするオープンソースツールであることにご注意ください。

主な利点:

実際の Kafka 指標に基づくスケーリング: オートスケーラーは Kafka クラスタに直接接続して、コンシューマーグループのパーティション全体の合計オフセットラグをモニタリングします。また、コンシューマーの CPU 使用率を考慮に入れることもできます。
コンシューマーを自動的にゼロにスケールダウン: これにより、アイドル期間中は費用がからなくなります。
費用対効果: リクエスト課金型の Cloud Run サービスとしてデプロイされるため、オートスケーラー自体は非常に安価に実行できます（月額 1 ドル未満）。これは、スケーリングチェック中の短い期間のみアクティブになるためです。
スケーリング動作をきめ細かく構成可能: オートスケーラーは、Kubernetes HorizontalPodAutoscaler（HPA）と同様に、スケーリングポリシーをきめ細かく制御できるため、具体的な費用やパフォーマンスの目標に合わせてスケーリング動作を調整できます。次のような構成可能な手段がいくつか用意されています。

目標ラグと CPU 使用率のしきい値
インスタンス数の急激な変動を防ぐ安定化ウィンドウ
1 回のスケーリングアクションでどの程度のインスタンスを追加または削除するかを制御するスケーリング増減制限

構成オプションの完全なリストについては、プロジェクトのドキュメントをご覧ください。

Cloud Run Kafka オートスケーラーのアーキテクチャ図

仕組みは次のとおりです。

自動スケーリングのチェックの実行: Cloud Scheduler がオートスケーラーを定期的にトリガーして、スケーリング評価を開始します。
Kafka オフセットラグの読み取り: オートスケーラーは、トリガーされると Kafka クラスタに接続してオフセットラグを読み取り、（必要に応じて）Cloud Monitoring に接続してコンシューマーの CPU 使用率を読み取ります。
スケーリングの決定と実行: オートスケーラーは、収集された指標とユーザー定義のスケーリングポリシーに基づいて、最適なコンシューマーインスタンス数を計算し、Cloud Run の手動スケーリング API を使用して、新しいデプロイなしでインスタンス数を動的に調整します。

パターンの一般化

Kafka オートスケーラーのコアアーキテクチャパターンはシンプルです。Cloud Run サービスが定期的にトリガーされ、カスタム指標を読み取ってインスタンス数を調整します。この柔軟なモデルは、pull ベースのあらゆるワークロードに適応でき、アプリケーションにとって最も重要な指標に基づいて Cloud Run ワーカープールをスケールできます。

アプリケーションがワーカープールを別のメッセージキューから使用する場合や、ビジネス指標に基づいてスケールする必要がある場合は、同様の専用オートスケーラーを構築できます。いくつか例を挙げましょう。

セルフホスト型 GitHub ランナーの自動スケーリング: CI / CD キュー内の保留中のジョブ数に基づいて、セルフホスト型ランナーのプールを動的にスケールします。これにより、ランナーがアイドル状態のときにスケールダウン（ゼロまで）することでコストを最小限に抑えながら、ビルドを遅延なく実行できます。
カスタムの Prometheus 指標に基づくスケーリング: 処理キュー内のアイテム数やアクティブなユーザーセッション数など、Prometheus で公開済みのカスタムのビジネス指標に基づいてワーカープールをスケールします。これにより、インフラストラクチャの費用をリアルタイムのアプリケーション需要に直接結び付けることができます。
Pub/Sub バックログの処理: Pub/Sub サブスクリプションの未配信メッセージ数に基づいてワーカー数を調整します。これにより、トラフィックの急増時でもメッセージをタイムリーに処理でき、トラフィックが少ない期間は費用を節約できます。

Cloud Run ワーカープールと Kafka オートスケーラーにより、Kafka の実行に新たなレベルの柔軟性と使いやすさがもたらされます。お客様がこれらをどのように活用されるか、今から楽しみです。詳細とご利用開始方法は次のとおりです。

オープンソースの Cloud Run Kafka オートスケーラーを試す:

https://github.com/GoogleCloudPlatform/cloud-run-kafka-scaler（Terraform モジュール）

Cloud Run ワーカープールの詳細（ドキュメント）
オートスケーラーに関するフィードバックやご質問は、run-oss-autoscaler-feedback@google.com までお寄せください。

Apache Kafka のマネージドサービスをお探しの場合は、Google Cloud が提供する Managed Service for Apache Kafka もご検討ください。このサービスは、自動化されたクラスタ管理、Kafka Connect、スキーマレジストリ（プレビュー版）を備えており、Google Cloud のモニタリング、ロギング、IAM が組み込まれているため、運用が簡素化されます。

^{このブログ投稿に協力してくれた Google Cloud チームメンバー、Andrew Manalo（サーバーレススケーリング担当ソフトウェアエンジニア）、Sagar Randive（サーバーレス担当プロダクトマネージャー）、Matt Larkin（サーバーレス担当プロダクトマネージャー）に感謝します。}

ーエンジニアリングマネージャー、Aniruddh Chaturvedi

ーシニアエンジニアリングマネージャー、Adam Kane

Cloud Run で GPU の一般提供を開始: AI ワークロードの実行が誰にとっても簡単に

Fri, 06 Jun 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 6 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のサーバーレスランタイムである Cloud Run は、そのシンプルさ、柔軟性、スケーラビリティから、デベロッパーに人気を博しています。このたび、Cloud Run での NVIDIA GPU のサポートが一般提供となり、さまざまなユースケースに対応するパワフルなランタイムを非常にコスト効率の高い形で提供できることになりました。

今後は、GPU と CPU の両方で次のメリットを享受できます。

秒単位の課金: 使用した GPU リソースに対してのみ、秒単位で課金されます。
ゼロへのスケーリング: Cloud Run は、リクエストが届かない間は GPU インスタンスを自動的にゼロにスケールダウンすることで、アイドル状態の費用を排除します。散発的または予測不可能なワークロードには朗報です。
迅速な起動とスケーリング: GPU とドライバをインストールしたインスタンスが 5 秒以内にゼロから起動するため、アプリケーションは非常に迅速に需要に対応できます。たとえば、ゼロからスケール（コールドスタート）した場合、最初のトークンまでの時間が gemma3:4b モデルで約 19 秒という驚異的な数値を達成しました（これには、起動時間、モデルの読み込み時間、推論の実行時間が含まれます）。
完全なストリーミングのサポート: HTTP と WebSocket ストリーミングのサポートがすぐに使える状態で組み込まれているため、真にインタラクティブなアプリケーションを構築して、LLM の回答が生成されたらすぐにユーザーに提供できます。

Cloud Run での GPU のサポートは重要なマイルストーンであり、GPU で高速化されたアプリケーションをこれまで以上にシンプル、高速、費用対効果の高いものにする取り組みにおける Google のリーダー的地位を実証しています。

「サーバーレス GPU アクセラレーションは、最先端の AI コンピューティングをより利用しやすくするための大きな進歩です。NVIDIA L4 GPU へのシームレスなアクセスにより、デベロッパーはこれまで以上に費用対効果の高い方法で迅速に AI アプリケーションを本番環境に展開できるようになりました。」- NVIDIA、アクセラレーテッドコンピューティングプロダクト担当ディレクター Dave Salvator 氏

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f62776ae460>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

誰もが利用できる AI 推論

この一般提供版リリースで最も注目すべき点は、Cloud Run の GPU として NVIDIA L4 GPU が誰でも利用できるようになったことです。割り当てリクエストは不要であるため、導入への大きなハードルが解消され、Cloud Run サービスで GPU アクセラレーションをすぐに活用できます。Cloud Run コマンドラインから --gpu 1 を使用するか、コンソールで [GPU] チェックボックスをオンにするだけで、割り当てをリクエストする必要はありません。

プロダクションレディ

一般提供が開始されたことにより、Cloud Run での GPU のサポートは、Cloud Run のサービスレベル契約（SLA）の対象となり、信頼性と稼働時間が保証されるようになりました。Cloud Run はデフォルトでゾーン冗長性を提供しており、ゾーン停止に耐えるために十分な容量をサービスに確保できます。これは、Cloud Run で GPU を使用した場合にも適用されます。また、ゾーン冗長性をオフにして、ゾーン停止が発生した場合に GPU ワークロードのベストエフォートフェイルオーバーを行うことにすれば、料金を低く抑えられるメリットがあります。

マルチリージョン GPU

グローバルなアプリケーションをサポートするため、Cloud Run の GPU は 5 つの Google Cloud リージョン（us-central1（米国アイオワ）、europe-west1（ベルギー）、europe-west4（オランダ）、asia-southeast1（シンガポール）、asia-south1（インド、ムンバイ））で利用可能で、今後さらに拡大する予定です。

また、Cloud Run は複数のリージョンにわたるサービスのデプロイを簡素化しています。たとえば、1 つのコマンドで米国、ヨーロッパ、アジアにサービスをデプロイし、低レイテンシと高い可用性をグローバルユーザーに提供できます。例として、オープンモデルを実行する最も簡単な方法の一つである Ollama を、3 つのリージョンにわたって Cloud Run にデプロイする方法を以下に示します。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy my-global-service \\\r\n --image ollama/ollama --port 11434 \\\r\n --gpu 1 \\\r\n --regions us-central1,europe-west1,asia-southeast1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6247335040>)])]>

実際の動作を確認する: 4 分で NVIDIA GPU を 0 個から 100 個へ

GPU を使用した Cloud Run の驚異的なスケーラビリティを、Google Cloud Next 25 のこちらのライブデモで実際に確認できます。わずか 4 分で GPU を 0 個から 100 個までスケールする様子を紹介しています。

Cloud Run の GPU で実行されている Stable Diffusion サービスの負荷テスト。4 分間で GPU インスタンス 100 個に到達している。

Cloud Run ジョブで NVIDIA GPU を使用して新たなユースケースを実現

Cloud Run での GPU の使用がメリットとなるのは、リクエストドリブン型の Cloud Run サービスを使用するリアルタイム推論だけではありません。Cloud Run ジョブでも GPU が利用可能になったため、特にバッチ処理や非同期タスクの新しいユースケースが実現します。

モデルのファインチューニング: 基盤となるインフラストラクチャを管理することなく、事前トレーニング済みモデルを特定のデータセットで簡単にファインチューニングできます。GPU を活用したジョブをスピンアップし、データを処理し、完了したらゼロまでスケールダウンできます。
AI 推論のバッチ処理: 大規模なバッチ推論タスクを効率的に実行できます。画像の分析、自然言語の処理、推奨事項の生成など、GPU を使用した Cloud Run ジョブは、さまざまな負荷に対応できます。
メディアのバッチ処理: 動画のコード変換、サムネイルの生成、複雑な画像操作を大規模に行うことができます。

Cloud Run ジョブの GPU の限定公開プレビュー版にご登録ください。

Cloud Run のお客様の声

Google の説明だけでなく、Cloud Run の GPU を早期に導入したお客様の声もご紹介します。

「Cloud Run は、vivo が AI アプリケーションのイテレーションを迅速に行うのに役立ち、運用とメンテナンスの費用を大幅に削減します。自動スケーリングが可能な GPU サービスは、AI の海外展開の効率も大幅に向上させます。」- vivo、AI アーキテクト Guangchao Li 氏

「L4 GPU は、リーズナブルな費用で非常に優れたパフォーマンスを提供します。高速な自動スケーリングと組み合わせることで、費用を最適化し、85% の費用削減を実現できました。Cloud Run で GPU が利用できるようになったことを非常に嬉しく思っています。」- Wayfair、シニアソフトウェアエンジニア John Gill 氏（Next '25 にて）

「Midjourney では、Cloud Run の GPU が当社の画像処理タスクに非常に有用であることがわかりました。Cloud Run は開発者エクスペリエンスがシンプルであるため、インフラストラクチャの管理に時間を取られることなく、イノベーションに集中できます。また、Cloud Run の GPU のスケーラビリティにより、数百万もの画像を簡単に分析、処理できます。」- Midjourney、データチームリーダー Sam Schickler 氏

使ってみる

Cloud Run の GPU は、次世代のアプリケーションを強化する準備が整っています。ドキュメント、クイックスタート、モデル読み込みの最適化に関するベストプラクティスをご覧ください。皆様が構築されるアプリケーションを楽しみにしております。

-プロダクトマネジメント担当ディレクター、Steren Giannini

-エンジニアリング担当ディレクター、Yunong Xiao

フリップアウト: クラウド接続でクラシックなピンボールマシンをモダナイズ

Tue, 19 Nov 2024 02:10:00 +0000

※この投稿は米国時間 2024 年 11 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウドが中心となっている今日の世界では、アプリケーションをありとあらゆる強力なクラウドサービスと簡単に統合できるのが当然のことのように思われています。しかし、統合が容易ではないレガシーシステムやその他の制約のある環境が依然として数多く存在しています。

私たちは、Backlogged Pinball を開発する際に、この課題に真正面から立ち向かいました。Backlogged Pinball はクラウドサービスを一般的ではない環境で統合するためのデモとして構築したカスタムピンボールゲームです。Backlogged Pinball は、クラウドに接続してさまざまなサービス（現在のゲームや完了したゲームに関するデータの追跡、リーダーボードの更新など）を利用できる物理的なピンボールマシンです。ゲームコードとクラウドへの統合に集中するため、このマシンの構築には市販のプログラム可能なピンボールマシンをベースとして使用しました。しかし、このマシンのソフトウェア環境には制限があり、17 年前に初めてリリースされた .NET Framework 3.5 のサンドボックスバージョンで実行されていました。これは、C# で利用できる最新の Google Cloud SDK を使用できず、gcloud のようなクラウドとの通信をサポートするツールもインストールできないことを意味しました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f62760f6d30>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

問題点

私たちは、データベース（ハイスコアやゲームの統計情報）、ロギング（ゲームイベントと結果）、カスタムサービス（ゲームエクスペリエンスの迅速な変更）にクラウドを活用したいと考えていました。しかし、このような制約のある環境向けのソフトウェア開発には、次のようなさまざまな課題がありました。読者の皆様にはおなじみの課題かもしれません。

最小限のライブラリ サポート: スタックを完全に制御できる場合は、クラウドサービスへ接続するための優れたライブラリが不足することはありません。しかし、ソフトウェアの実行場所を選べない場合もあります。私たちのピンボールマシンでは、必要なクラウドサービスと統合できる互換性のあるライブラリを見つけるのが困難でした。たとえば、ゲーム内で起こっていることをすべてリアルタイムで可視化するために、Firestore データベースにレコードを挿入したいと考えていました。Firestore には優れた SDK がありますが、.NET Framework 4.6.2（8 年前のバージョン）以前のものはサポートされていませんでした。TCP 接続を使用して従来のリレーショナルデータベースに接続することもできたかもしれませんが、使用できるクラウドツールやサービスが限られるのは避けたいと考えていました。データをブラウザにリアルタイムで push するようにゼロから設計された Firestore ではなく、MySQL を使用してリアルタイムウェブアプリケーションを構築するのは、言うまでもなくはるかに非実用的です。

困難なデプロイ プロセス: 新しい機能やクラウド統合を追加したいけれど、デバイス上でのソフトウェア更新を困難にする他の制限がある場合もあります。サードパーティデベロッパーとして、開発中は USB メモリを使用してゲームの各バージョンを手動でインストールする必要がありました。このような制限のせいで、コードの新バージョンをテスト、デプロイ、出荷するスピードが遅くなります。これは決して良いことではありません。最新の柔軟なクラウド環境では、新しい機能を追加するのがはるかに簡単です。

基本的に、不確実な従来の環境で最新のクラウドサービスを使用することは困難であることがわかりました。

スクリプトをフリップ

一見したところ、必要なすべてのサービスをピンボールマシンで実行されるコードに統合する実用的な方法はありませんでした。しかし、もし別の方法があるとしたら？ピンボールマシン自体をサービスに変えて、最小限の統合を一つだけ施したらどうなるでしょうか？そしてゲーム内で何かが起こるたびにメッセージを送信し、最新のクラウド環境で結果を整理できるようにするのです。

私たちは、この目標を達成するには Pub/Sub が最適な方法であると判断しました。Pub/Sub は複雑さを最小限に抑えながら、単一のインターフェースでクラウドに情報を送受信するものです。任意のメッセージ形式の基本的な HTTP POST として送信できます。

これを実現するために、カスタム Pub/Sub メッセージングシステムを設計しました。私たちは、ピンボールマシン用に独自の軽量 Pub/Sub ライブラリを作成し、REST API を介した認証とメッセージ送信を処理できるようにしました。これにより、プレーヤーがボールを弾き出したり、的に命中させたり、フリッパーボタンを押したりするたび、非常に簡単にイベントをポストできるようになりました。GitHub でそのコードの簡易版を確認できます。

クラウド側では、複数の Cloud Run サブスクライバーを使用してこれらのイベントをリアルタイムで処理しました。また、データの保存と可視化を行うために Firestore を使用しました。

大成功！クラウドの利点

統合の複雑な処理をクラウドで行うことで多くの利点が得られました。

単一のインターフェース: 独自の Pub/Sub クライアントを作成するのは簡単な作業ではありませんでした（認証に関してだけでもブログ投稿が 1 本書けてしまうほどです）。しかし、いったん済ませてしまえばもうそれで終わりです！一度動作し始めると、必要な最新のクライアントライブラリとツールを使用したクラウド内のすべてのイベント処理に集中できるようになりました。

リアルタイム更新: Google Cloud Next では、ユーザーが独自の Cloud Run サービスを作成し、ピンボールイベントを受信および処理して、メッセージをマシンに送り返せるよう支援しました。これらのサービスの構築とデプロイには 1 分もかかりませんでした。つまり、友人がゲームをプレイしている間にゲームを変更することも可能ということです。

豊富なデータ分析情報: ゲーム内で発生したすべての出来事の詳細なログを手に入れることができました。この情報は、開発中の問題のトラブルシューティングや、テストプレイに基づくスコアのファインチューニングに非常に有効でした。

もっと先へ

私たちは、当初は考慮していなかった機能を備えた Backlogged Pinball の次のイテレーションをすでに計画しています。たとえば、AI を活用したゲーム分析やプレーヤーのスタイルに基づいたアドバイスを追加する予定です。この柔軟なクラウドベースのアーキテクチャにより、レガシーシステムで依存関係と格闘するのではなく、ほぼすべての作業を最新のクラウド環境で行えるようになります。そして、このプロジェクトから学んだ教訓は、あらゆる制約のある環境に広く応用できるものです。組み込みシステム、IoT デバイス、レガシーソフトウェアを実行する古いサーバーなど、どのような環境であっても、Pub/Sub メッセージングを活用し、クラウドファーストの考え方を採用することで、環境の制限から解放されてクラウドの可能性を最大限に引き出せるようになります。

2024 年 11 月に開催される KubeCon North America で、最新の Backlogged Pinball を披露する予定です。ご参加の際はぜひお立ち寄りください！

^{今回のプロジェクトと本ブログ投稿の執筆に協力してくれた Google Cloud アドボケイト、Mofi Rahman にこの場を借りて感謝の意を表します。}

ーデベロッパー アドボケイト Drew Brown

ーデベロッパー アドボケイト Max Saltonstall

NVIDIA GPU を使用した Cloud Run での AI 推論アプリケーションの実行

Thu, 29 Aug 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 8 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Run は、そのシンプルさ、高速な自動スケーリング、ゼロへのスケーリング機能、従量課金の料金設定という特長から、デベロッパーに人気を博しています。これらのメリットは、オープンな生成 AI モデルをサービングするリアルタイムの推論アプリにも活かすことができます。そのため、Google はこのたび NVIDIA L4 GPU のプレビュー版サポートを Cloud Run に追加しました。

これにより、Cloud Run のデベロッパーは、次のような数多くの新しいユースケースに取り組めるようになります。

Google の Gemma（2B / 7B）や Meta の Llama 3（8B）などの軽量なオープンモデルを使用してリアルタイムで推論を実行し、カスタム chat bot を構築したりドキュメントの要約を即座に作成したりする一方で、ユーザートラフィックの急増にスケーリングで対処する。
企業ブランドに合わせて画像生成などを行う、ファインチューニングされたカスタム生成 AI モデルをサービングし、誰も使用していないときはスケールダウンして費用を最適化する。
オンデマンドの画像認識、動画のコード変換とストリーミング、3D レンダリングなど、多くのコンピューティング処理を必要とする Cloud Run サービスを高速化する。

フルマネージドプラットフォームである Cloud Run を使用すると、Google のスケーラブルなインフラストラクチャ上で直接コードを実行でき、コンテナの柔軟性とサーバーレスのシンプルさを組み合わせて生産性を向上させることができます。Cloud Run では、フロントエンドサービスとバックエンドサービスの実行、ジョブのバッチ処理、ウェブサイトとアプリケーションのデプロイ、キュー処理ワークロードへの対応が可能です。しかも、基盤となるインフラストラクチャを管理する必要は一切ありません。

同時に、AI 推論を実行する多くのワークロード、特にリアルタイムの処理を要求するアプリケーションは、ユーザーが即座に応答を得られるようにするために GPU アクセラレーションを必要とします。NVIDIA GPU のサポートにより、任意の LLM を使用してオンデマンドかつオンラインの AI 推論を数秒で実行できるようになります。24 GB の vRAM の場合、Llama 3.1（8B）、Mistral（7B）、Gemma 2（9B）など、最大 90 億個のパラメータを含むモデルのトークン処理を高速化できます。アプリが使用されていないときは、サービスが自動的にゼロまでスケールダウンするため、料金は発生しません。

「NVIDIA L4 Tensor GPU と NVIDIA NIM のサポートが追加されたことで、Cloud Run ユーザーは、高速スケーリング可能なリアルタイムの AI 推論プラットフォームを手に入れ、顧客による AI プロジェクトの推進を支援するとともにソリューションの市場投入スピードをアップできます。しかも、インフラストラクチャ管理のオーバーヘッドを最小限に抑えることができます。」- NVIDIA、プロダクトマーケティング担当シニアディレクター Anne Hecht 氏

以前から Google Cloud のソリューションをご利用のお客様は、Cloud Run と NVIDIA GPU の組み合わせに大きな関心を寄せています。

「Cloud Run での GPU のサポートによって、当社のリアルタイム推論アプリケーションの状況は大きく変わりました。コールドスタート時のレイテンシの短さは驚くべきもので、ほぼ即座に予測をサービングできます。これは、時間が鍵となるカスタマーエクスペリエンスに不可欠です。また、Cloud Run の GPU では、負荷が異なってもサービング時のレイテンシが一貫して最小限になるため、生成 AI アプリケーションの応答性と信頼性を高く保つことができます。さらに、アクティビティのない期間には簡単にゼロまでスケールダウンできます。総合的に言って、Cloud Run での GPU のサポートにより、エンドユーザーに結果を迅速、正確、効率的に提供する能力が大幅に向上しました。」- L’Oreal、グローバルビューティテック、AI 担当責任者 Thomas MENARD 氏

「Cloud Run の GPU が、Google Cloud で GPU コンピューティングを利用するための最適な方法であることは間違いありません。私が気に入っているのは、オープンソースの標準（Knative）を使用する場合の高度な制御性とカスタマイズ性に加えて、そのまま使える優れたオブザーバビリティツールが提供される点、さらにゼロへのスケーリングが可能なフルマネージドインフラストラクチャである点です。また、Knative プリミティブを使用して簡単に GKE に移行できるため、高度な複雑性とメンテナンスを受け入れて制御性をさらに高めるという選択肢も常にあります。当社のユースケースの場合、GPU の割り当てと起動にかかる時間も、他のほとんどの競合サービスより少なく済みました。」- Chaptr、イノベーション担当ディレクター Alex Bielski 氏

Cloud Run で NVIDIA GPU を使用する

現在、Cloud Run インスタンスあたり 1 個の NVIDIA L4 GPU のアタッチがサポートされています。また、事前に GPU を予約する必要はありません。Cloud Run での GPU は現在、us-central1（アイオワ）で利用可能で、今年末までに europe-west4（オランダ）と asia-southeast1（シンガポール）でも利用可能になる予定です。

NVIDIA GPU を使用して Cloud Run サービスをデプロイするには、コマンドラインで --gpu=1 フラグを追加して GPU の数を指定し、--gpu-type=nvidia-l4 フラグを追加して GPU のタイプを指定します。または、次のように Google Cloud コンソールで同じ処理を行うこともできます。

また、最近発表された Cloud Run functions を使用すると、GPU を関数にアタッチしてイベントドリブンな AI 推論を簡単に実行できます。

「新たにリリースされた GPU 対応の Cloud Run functions により、Python デベロッパーは、インフラストラクチャ、GPU ドライバ、コンテナなどを気にせずに Hugging Face モデルを使用できます。Cloud Run のゼロへのスケーリングと高速起動の機能は、AI 開発をこれから始めようとしているデベロッパーに最適で、わずか数行のサーバーレスコードで HuggingFace モデルを使用できます。」- Hugging Face、最高技術責任者 Julien Chaumond 氏

パフォーマンス

Cloud Run と NVIDIA GPU を組み合わせると、シンプルなオペレーションだけでなく、高パフォーマンスというメリットも得られます。モデルのサービング時に最高のパフォーマンスを実現できるよう、インフラストラクチャのレイテンシを最小限に抑えることができます。

L4 GPU がアタッチされドライバがプリインストールされた Cloud Run インスタンスは約 5 秒で起動し、コンテナで実行されているプロセスはその時点ですぐに GPU を使用できるようになります。その後、数秒間でフレームワークとモデルが読み込まれ、初期化されます。次の表に、Ollama フレームワークを使用した Gemma 2b、Gemma2 9b、Llama2 7b / 13b、Llama3.1 8b モデルのコールドスタート時間を示します。全体が 11 秒～35 秒の範囲にあります。インスタンスを 0 から起動し、GPU にモデルを読み込み、LLM が最初の単語を返すまでの時間を計測しました。

モデル	モデルの規模	コールドスタート時間
gemma:2b	1.7 GB	11～17 秒
gemma2:9b	5.1 GB	25～30 秒
llama2:7b	3.8 GB	14～21 秒
llama2:13b	7.4 GB	23～35 秒
llama3.1:8b	4.7 GB	15～21 秒

コールドスタート時間: 最初のサービス URL 呼び出しが行われ、Cloud Run インスタンスが 0 から 1 に移行し、応答として最初の単語を提供するまでにかかった時間。モデル: 前述した各モデルの 4 ビット量子化バージョンを使用。これらのモデルのデプロイには Ollama フレームワークを使用。これらの数値は管理されたラボ環境で観測されたものであり、実際のパフォーマンスの数値は多数の要因に左右される点にご注意ください。

Ollama を使用してサンプルアプリをデプロイする

以下に、Cloud Run と NVIDIA GPU を使用して Ollama で Google の Gemma2 9b モデルをデプロイする方法を示します。Gemma は軽量な最先端のオープンモデルのファミリーであり、Gemini モデルの作成に使用されたものと同じ研究とテクノロジーに基づいて構築されています。Ollama は、大規模言語モデルを管理するためのシンプルな API を提供するフレームワークです。

まず、Ollama でコンテナイメージを作成し、この Dockerfile でモデルを作成します。

code_block: <ListValue: [StructValue([('code', 'FROM ollama/ollama\r\nENV HOME /root\r\nWORKDIR /\r\nRUN ollama serve & sleep 10 && ollama pull gemma2\r\nENTRYPOINT ["ollama","serve"]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6277357460>)])]>

続けて、次のコマンドを使用してデプロイします。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy --source . --port 11434 --no-cpu-throttling --cpu 8 --memory 32Gi --gpu 1 --gpu-type=nvidia-l4'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62773576a0>)])]>

これで完了です。デプロイすると、Ollama API を使用して Gemma 2 との会話を開始できます。

「Ollama を使用した Cloud Run への大規模言語モデルのデプロイは、最新の GPU サポートのおかげで、非常にシンプルです。いくつかのコマンドを実行するだけで、Ollama のアプリへのシームレスな統合と Cloud Run のサーバーレスインフラストラクチャを利用して、LLM のデプロイと管理を簡単に行うことができます。Cloud Run の高速なコールドスタートと迅速なスケーリングにより、信頼性の高い方法でアプリケーションを拡張できます。インフラストラクチャや ML に関する深い知識は必要ありません。自分のアプリケーションに集中していれば、後はツールがすべて処理してくれます。」- Ollama、創設者 Jeffrey Morgan 氏

さらに、Google Cloud Marketplace で提供されている NVIDIA AI Enterprise ソフトウェアスイートに含まれる、NVIDIA NIM 推論マイクロサービスも利用できます。これにより、Cloud Run 上の NVIDIA L4 GPU のパフォーマンスの最大化と高速化を実現し、高パフォーマンスな AI モデル推論を安全かつ確実にデプロイできます。導入について詳しくは、NVIDIA のブログをご覧ください。

使ってみる

Cloud Run は、ウェブアプリケーションのホスティングを驚くほど簡単にします。そして、GPU がサポートされるようになったことで、サーバーレス、シンプルさ、スケーラビリティというメリットが、AI 推論アプリケーションにも広がりました。Cloud Run での NVIDIA GPU の使用を開始するには、g.co/cloudrun/gpu でプレビュープログラムにご登録ください。追って、ウェルカムメールをお送りします。

Cloud Run での GPU の使用について詳しく知りたい方は、NVIDIA と Ollama も参加するライブ配信（2024 年 8 月 21 日開催）をぜひご視聴ください。Cloud Run の新機能をご紹介し、さまざまなシナリオでの Cloud Run の使用方法のデモを実施します。

-Google Cloud サーバーレス担当プロダクトマネージャー Sagar Randive
-Google Cloud サーバーレス担当シニアスタッフソフトウェアエンジニア Wenlei (Frank) He

Cloud Functions は Cloud Run 関数に - イベントドリブンプログラミングを 1 つの統合サーバーレスプラットフォームで実現

Thu, 29 Aug 2024 02:00:00 +0000

※この投稿は米国時間 2024 年 8 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

Cloud Functions とそのおなじみのイベントドリブンプログラミングモデルが Cloud Run 関数となり、開発者がサーバーレスプラットフォームに求めるきめ細かい制御とスケーラビリティが提供されるようになりました。Cloud Run 関数になったことで、すべてのワークロードに対応する統合サーバーレスプラットフォームが構築されました。そのため、2 つのどちらかを選択する必要はありません。

これは単なる名前の変更だけではありません。Cloud Functions のインフラストラクチャが Cloud Run と統合され、Cloud Functions（第 2 世代）の開発者は、NVIDIA GPU を含むすべての新しい Cloud Run 機能にすぐにアクセスできるようになりました。

Cloud Functions が Cloud Run 関数になったことで、Cloud Run で直接関数を作成してデプロイできるようになり、基盤となるサービス構成の完全な制御が可能になりました。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy hello-function \\\r\n --source . \\\r\n --function hello_get \\\r\n --base-image nodejs20'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6274448ee0>)])]>

Cloud Run の新しいデプロイ方法: 関数

さらに、Google Cloud Functions（第 2 世代）で作成されたすべての関数は、次のような Cloud Run の機能すべてにアクセスできます。

マルチイベントトリガーの管理
高パフォーマンスのダイレクト VPC 下り（外向き）
Cloud Storage ボリュームをマウントする機能
Google が管理する言語ランタイム、ベースイメージでのセキュリティの自動更新を含む
トラフィック分割とリビジョン管理
サイドカーコンテナを含むマネージド Prometheus と OpenTelemetry のサポート
NVIDIA GPU による推論機能

新たにリリースされた GPU 対応の Cloud Run 関数により、Python 開発者は、インフラストラクチャ、GPU ドライバ、コンテナなどを気にせずに Hugging Face モデルを使用できます。Cloud Run のゼロへのスケーリングと高速起動の機能は、わずか数行のサーバーレスコードだけで HuggingFace モデルを使用して AI 開発を開始しようとしている開発者に最適です。」- Hugging Face、最高技術責任者 Julien Chaumond 氏

既存のAPI、gcloud コマンド、terraform モジュールの継続的なサポート

Cloud Functions 第 2 世代の関数は、Cloud Run 関数に自動的に変換されます。Cloud Run 関数により、Google は、既存の関数 API、gcloud コマンド、Terraform モジュール（第 2 世代）の継続的なサポートに取り組んでいます。これにより、デプロイの自動化をリファクタリングすることなく、関数で Cloud Run 機能を有効にできます。

第 1 世代の関数は、Cloud Run 関数（第 1 世代）として引き続き使用できます。基盤となる Cloud Run 機能に完全にアクセスできるようにするには、第 1 世代関数を Cloud Run 関数にアップグレードする必要があります。Cloud Run 関数（第 1 世代）のAPI、gcloud コマンド、Terraform モジュール（第 1 世代）は引き続きサポートされます。

関数を使用してプラットフォームを接続する

Cloud Run 関数を使用すると、プラットフォームの接続がシンプルになり、簡単に保守できるようになります。気にかける必要があるのはコードだけで、あとは自動で処理されます。コーディングの知識があるメンバーがチームにいれば、コードをパッケージ化することなくソリューションを作成できます。また、7 つの一般的な言語から選択することもできます。たとえば、データサイエンティストなら、インフラストラクチャの知識があまりなくても、Python スクリプトをクラウドで実行できます。

新しいインラインエディタで関数を編集

Cloud Run 関数は、各関数を独立したコンポーネントにすることで、生産性を高く保ち、運用コストを低く抑え、他のワークロードに直接影響を与えないようにします。1 つの関数を変更したり更新したりしても、別の関数に影響する可能性はほとんどありません。

この関数は一般的に、オブジェクトが Cloud Storage バケットに追加されたときの応答に使用されます。この関数により、画像のサムネイルを生成したり、テキストファイルの感情分析を実行したりできます。お客様が Cloud Functions を選択する例は他にも多くあります。

データを変換して BigQuery に読み込む
サードパーティ（GitHub など）によって呼び出される Webhook を作成する
ML API を使用して、データベースまたはストレージバケットに追加されたデータを分析する

Cloud Run 関数を使ってみる

サーバーレスを初めて使用される方でも、経験豊富な方でも、Cloud Run 関数を使用すると、イベントドリブンアプリケーションの構築と管理がこれまで以上に簡単になります。

Cloud Functions エクスペリエンスの改善に関する詳細を見る
HTTP 関数を Cloud Run にデプロイする
イベントドリブン関数を Cloud Run にデプロイする
NVIDIA GPU を使用した Cloud Run での推論アプリケーションの実行に関する詳細を見る

Cloud Run 関数と Cloud Run の詳細については、こちらのライブウェブセミナーをご覧ください。

-シニアプロダクトマネージャー James Ma

フレキシブル確約利用割引がさらに柔軟に

Mon, 22 Jul 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 7 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、Google Compute Engine での低レベル VM、Google Kubernetes Engine（GKE）でのコンテナオーケストレーション（フルマネージドの Autopilot モードを含む）、Cloud Run など、ワークロードを実行するための優れた方法が数多く提供されています。これまで、費用を最適化するには、これらの異なるプロダクトをそれぞれカバーする確約利用割引（CUD）を複数購入する必要がありました。たとえば、GKE の Standard モードで実行されるワークロードを含む VM の費用には Compute Engine フレキシブル CUD を、Cloud Run の常時稼働インスタンスには Cloud Run CUD を、GKE Autopilot で実行されるワークロードには Autopilot CUD を購入する必要がありました。

新たな Compute フレキシブル CUD

このたび、Compute Engine フレキシブル CUD は、新名称の Compute フレキシブル CUD となり、Cloud Run オンデマンドリソース、ほとんどの GKE Autopilot Pod、プレミアムの Autopilot Performance コンピューティングクラスおよび Autopilot Accelerator コンピューティングクラスに対応するよう拡充されたことを発表します。対象となるプロダクトなど、詳細については、ドキュメントと SKU のリストをご覧ください。

1 回の CUD 購入で、Compute Engine、GKE、Cloud Run の 3 つのプロダクトすべてで対象となる費用をカバーできます。3 年間のコミットメントでは 46%、1 年間のコミットメントでは 28% の割引が適用されます。この単一の CUD への統合により、1 つのコミットメントでこれらすべてのプロダクトを使用できるようになり、柔軟性が最大限に高まります。さらに、これらのコミットメントはリージョンに依存しないため、どのリージョンのリソースでも対象のプロダクトを使用できます。

Autopilot CUD の提供終了

拡充された新しい Compute フレキシブル CUD は、GKE Autopilot CUD よりも割引率が高く、全体的な柔軟性も高いため、GKE Autopilot CUD の提供を終了します。以前の GKE Autopilot CUD は、10 月 15 日までご購入いただけますが、それ以降はご購入いただけなくなります。既存の CUD は、いつ購入したかにかかわらず、対象期間中は引き続きご利用になれますが、現在および将来のニーズを見据えて、柔軟性と割引率が高い、新しい Compute フレキシブル CUD を検討することをおすすめします。

ご利用方法

すでに Compute Engine フレキシブル CUD を使用している場合は、対象となる Cloud Run および GKE Autopilot の使用量に対して自動的に割引が適用されます（以前の GKE Autopilot CUD のようなプロダクト固有の CUD がある場合は、そちらが先に適用されます）。Compute フレキシブル CUD を初めて使用する場合でも、始めるのは簡単です。対象となる SKU 全体で 1 時間あたりの使用量を見積もり、利用期間（1 年または 3 年）に予想される継続的な使用量に見合ったコミットメントを購入することで費用を削減できます。使用量の増加に応じて CUD を追加することも可能です。

Google Cloud でのワークロードプラットフォームの構築に、この高い柔軟性がお役に立てば幸いです。

次のステップ

-Google Kubernetes Engine、グループプロダクトマネージャー William Denniss
-Google Compute Engine、シニアプロダクトマネージャー Yasmin Mowafy

Artifact Registry アセットをサーバーレスで組織やプロジェクト間にわたりリリースする

Wed, 05 Jun 2024 02:00:00 +0000

※この投稿は米国時間 2024 年 5 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

Artifact Registry や Container Registry の画像を、さまざまなプロジェクトや組織の間で自動的にコピーする方法があればいいと考えたことはありませんか。この記事では、Google Cloud のサーバーレスコンポーネントを使用してこの操作を行うための専用プロセスと、Infrastructure as Code（IaC）へのデプロイ方法について説明します。

この記事では、Python のコーディングの知識と、ターミナルでコマンドを実行する方法についての基本的な理解、および Hashicorp Configuration Language（HCL）すなわち Terraform for IaC の知識を前提としています。

このユースケースでは、最低 1 つのコンテナイメージが Artifact Registry リポジトリに存在し、頻繁に更新され、組織間で更新を外部の Artifact Registry リポジトリに伝播する必要があります。イメージは外部の組織にリリースされますが、依然としてプライベートで、公共からの使用はできないようにします。

この方法がどのように動作するかを明確に示すため、最初にアーキテクチャの個別のコンポーネントを取り上げてから、互いに結び付けることにしましょう。

以前に解説したように、該当する Artifact Registry（AR）リポジトリは 2 つあります。わかりやすくするため、以下ではこれらを「ソース AR」（イメージが定期的にビルドされ更新される AR で、信用できる情報源）と、「ターゲット AR」（別の組織やプロジェクトにあり、イメージが使用され、定期的に伝搬される必要がある AR）と呼ぶことにしましょう。アーキテクチャの次のコンポーネントは Cloud Pub/Sub です。ソースプロジェクトには、ソース AR に加えられた更新を自動的にキャプチャしてくれる Artifact Registry Pub/Sub トピックが必要です。Artifact Registry API が有効なとき、Artifact Registry はこの Pub/Sub トピックを自動的に作成します。このトピックは「gcr」と呼ばれ、Artifact Registry と Google Container Registry（使用されている場合）との間で共有されます。Artifact Registry は、トピックへの次の変更についてメッセージをパブリッシュします。

イメージがアップロードされた
新しいタグがイメージに追加された
イメージが削除された

トピックは自動的に作成されますが、そのトピックのメッセージを使用するには、Pub/Sub サブスクリプションを作成する必要があります。このためには、アーキテクチャの次のコンポーネントである Cloud Run が必要です。Cloud Run のデプロイを作成します。これは、次の動作を行います。

Pub/Sub メッセージの全体を解析する
メッセージの内容を比較し、ソース AR の変更からターゲット AR の更新が必要になるかどうかを検証する
検証の条件が満たされたら、Cloud Run サービスが最新の Docker イメージをターゲット AR に移動する

次に、Cloud Run が Pub/Sub AR トピックとどのように統合されるかを掘り下げましょう。Cloud Run が Pub/Sub メッセージを読み取れるようにするため、EventArc トリガーと Pub/Sub サブスクリプションという 2 つの追加コンポーネントがあります。EventArc トリガーは Cloud Run サービスをトリガーするもので、ワークフローにとって非常に重要です。

上述のコンポーネントに加えて、フローの全体が正しく動作するには以下の前提条件が満たされている必要があります。

Cloud SDK がユーザーのターミナルにインストールされており、gcloud コマンドを実行できる必要があります。
プロジェクトのサービスアカウント（SA）には、ソース AR の「読み取り」権限が必要です。
プロジェクトの SA には、ターゲット AR の「書き込み」権限が必要です。
VPC-SC 要件（有効な場合）

ジョブを実行している SA からターゲットリポジトリへの外向きアクセス許可
「make」コマンドを実行するアカウントの内向きアクセス許可（以下で説明します）と、Artifact Registry または Container Registry の「書き込み」権限
ソースリポジトリの Pub/Sub GCR トピックを読み取る内向きアクセス許可
[project-name]-sa@[project-name].iam.gserviceaccount.com に、Artifact Registry メソッドの VPC-SC 内向きアクセスを許可する
[project-name]-sa@[project-name].iam.gserviceaccount.com に、CloudRun メソッドの VPC-SC 内向きアクセスを許可する
var.gcp_project
Var.service_account

以下では、この方式を自分で実装するため必要な Python コード、Dockerfile、Terraform コードについて解説します。以下のセクションを読むとき、このソリューションのオープンソースコードがすべて含まれている GitHub リポジトリを開くことをおすすめします。リンクはこちらです。https://github.com/GoogleCloudPlatform/devrel-demos/tree/main/devops/inter-org-artifacts-release

Cloud Run にデプロイするのは、カスタムの Docker コンテナです。これは、次に示すファイルで構成されます。

App.py: このファイルには、ソースおよびターゲットコンテナの変数に加えて、Pub/Sub メッセージに基づいて実行がトリガーされる実行コードと、次の Python コードが含まれています。
Copy_image.py: このファイルには、イメージをソース AR からターゲット AR にコピーするため必要な gcrane コマンドを実行するために app.py が利用する copy コマンドが含まれています。
Dockerfile: このファイルには、gcrane をパッケージ化するため必要な手順と、Cloud Run イメージをビルドするために必要な要件が記載されています。

このアーキテクチャと関連付けられている個別のコンポーネントすべてについて説明したので、これらのコンポーネントを互いに結び付けるフローについて説明します。

エンジニアリングチームが、Docker イメージの新しいバージョンである「Image X」をリリーススケジュールに従いビルドしてリリースし、「latest」タグを追加したと想定します。この新しいバージョンはソース AR の中にあり、新しいバージョンが作成されるとき、AR Pub/Sub トピックは、「Image X」の新しいバージョンがソース AR に追加されたことを反映するようメッセージを更新します。これにより、EventArc トリガーが Cloud Run サービスを自動的に poke し、Pub/Sub サブスクリプションからメッセージをスクレイピングします。

Google の Cloud Run サービスは、App.py イメージに書き込まれているロジックを使用して、ソース AR で起きたアクションが指定された基準（Image X で「latest」タグがある）と一致しているかどうかをチェックします。アクションが一致し、ダウンストリームのアクションが必要なら、Cloud Run は Copy_image.py をトリガーして gcrane コマンドを実行し、ソース AR からターゲット AR へイメージ名とタグをコピーします。

イメージやタグが App.py で指定された基準と一致しない場合（たとえば、イメージ Y のタグが latest である）、Cloud Run のプロセスから HTTP 200 の応答と、「The source AR updates were not made to the [Image X]. No image will be updated.」というメッセージが返され、アクションが行われなかったことを確認します。

注: ソース AR には複数のイメージが含まれている可能性がありますが、ここで重要なのはターゲット AR 内の特定のイメージの更新だけなので、出力応答は Cloud Run サービスに統合して、トラブルシューティングや問題の診断の目的で Google Cloud ログ内で表示できるようにしています。これにより、目的のイメージに属さないイメージが意図せずにパブリッシュされることも防がれます。

別の方式を使用しない理由

汎用性: ソースとターゲットの AR が別の組織に存在していた
互換性: アーティファクトが Cloud Build のようなソリューションと互換性がある Code / Git リポジトリに存在していなかった
セキュリティ: クラウドネイティブのサーバーレスオプションを使用するときに活用できるツールが VPC-SC 境界によって制限されている
不変性: Infrastructure as Code とともに完全にデプロイ可能なソリューションにするため
スケーラビリティとポータビリティ: 複数の組織に存在するいくつもの Artifact Registry を同時に更新できるようにするため
効率性と自動化: リソースが移動されないときは時間ベースの pull メソッドを避ける。整合性を保証するため人手の介入を回避します。
クラウド ネイティブ: CI / CD パイプラインや Google Cloud 環境の外部のリポジトリなど、サードパーティ製のツールやソリューションへの依存を軽減する

すべての場所からのイメージが送られてくるアップストリームのプロジェクトが同じ Google Cloud リージョンまたはマルチリージョンに存在する場合、仮想リポジトリが問題解決に向けた優れた代替選択肢です。

IaC でデプロイする方法

この問題を解決するために使用した Terraform コードを用意しました。
コードでは次の変数が使用されます。これらの変数は置き換えるか、.tfvars ファイル内で宣言し、プロジェクトごとに固有の値を割り当てる必要があります。

var.gcp_project
Var.service_account

結論として、組織間にわたってアーティファクトをリリースするプロセスをブートストラップする方法はいくつかあります。どの方法にも長所と短所があるため、自分のユースケースを評価して最適な方法を決定してください。ここで考慮すべきことは、アーティファクトを Git リポジトリ内に置くことができるか、ターゲットリポジトリが同じ組織と子組織のどちらに存在するのか、CI / CD ツールが望まれるかどうかです。

ここまで読み進めてきたなら、このソリューションに適切なユースケースがあると思います。このパターンは、他の同様なユースケースにも使用できます。最初に参照すべきいくつかの例を紹介します。

他のタイプのアーティファクトを、Kubeflow Pipeline Templates（KFP）などの AR リポジトリからコピーする
VPC-SC の背後のバケットオブジェクトをプロジェクトや組織の間でコピーする

その他のリソース

ソリューションコードは以下のリンク先をご覧ください。https://github.com/GoogleCloudPlatform/devrel-demos/tree/main/devops/inter-org-artifacts-release
GCrane: https://github.com/google/go-containerregistry/blob/main/cmd/gcrane/README.md
Pub/Sub GCR 通知の構成: https://cloud.google.com/artifact-registry/docs/configure-notifications

認証コンテキストを含む、Firestore の Eventarc との統合が一般提供に

Fri, 24 May 2024 01:10:00 +0000

※この投稿は米国時間 2024 年 5 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Eventarc と Firestore を組み合わせて使用してイベントドリブンアーキテクチャを構築することは、ますます人気のパターンとなっています。最近、Firestore の Eventarc との統合が一般提供となり、新たな機能が追加されました。信頼性を高めるために、マルチリージョンの Firestore データベースに対し異なるリージョンにある複数の Cloud Functions を登録できるようになりました。また、CloudEvents の認証コンテキスト拡張機能など、新しいイベントタイプが追加されました。

ユーザー、サービスアカウント、システム、サードパーティなど、Firestore ドキュメントの変更者を変更イベントで判断できるようにすることは、長い間特にご要望の多かった機能でした。認証コンテキスト拡張機能を備えた新しい Firestore イベントタイプにより、オープンかつポータブルな CloudEvents 形式で、ドキュメントの変更をトリガーしたプリンシパルに関するメタデータがイベントで埋め込まれるようになりました。

サンプルのチュートリアル

たとえば、認証コンテキスト（未認証またはシステム）ごとに、宛先のイベントを処理するロジックを変えたいとします。トリガーを設定するには、Google Cloud コンソールの [Eventarc] セクションに移動します。そこでは、認証情報を含む関連イベントタイプを使用して、Firestore に新しいトリガーを作成する必要があります。これらのイベントタイプの末尾は、サフィックス *.withAuthContext です。新たに書き込まれたエンティティをキャプチャするために、google.cloud.firestore.document.v1.written.withAuthContext イベントを選択します。

追加のフィルタを指定できます。これにより、指定のデータベースやコレクションから取得した、目的のイベントのみが配信されるようになります。ここでは、(default) データベースとコレクション Ops のドキュメントのイベントをフィルタで抽出します。

同じ画面で、宛先も指定する必要があります。トリガーイベントを配信する宛先は、サポートされている Eventarc の宛先であればいくつでも指定できます。たとえば、Cloud Run、Cloud Functions（第 2 世代）、Google Kubernetes Engine を指定できます。ここでは、イベントを受信するために HTTP エンドポイントを公開する demo という名前の Cloud Run サービスがあるとしましょう。トリガーは次のように構成できます。

これで完了です。(default) データベースにコレクション Ops の書き込みオペレーションが適用されると、構成した Cloud Run サービス demo に認証コンテキストを備えた CloudEvent がほぼ即座に配信されます。認証コンテキスト拡張機能で定義されている authtype 属性を調べることで、https://cloud.google.com/firestore/docs/extend-with-functions-2nd-gen#event_attributes に示されているように、未認証タイプやシステムタイプを特定できます。

次のステップ

Firestore トリガーの作成と構成の方法について詳しくは、ドキュメントをご覧ください。

このブログ投稿の執筆に際し、Firestore のシニアプロダクトマネージャーリードである Minh Nguyen とシニアテクニカルライターの Juan Lara の協力に感謝します。

-Firestore、ソフトウェアエンジニア Josué Urbina

-Firestore、ソフトウェアエンジニア Hansi Mou

Cloud Run のダイレクト VPC 下り（外向き）の一般提供を開始

Wed, 08 May 2024 01:40:00 +0000

※この投稿は米国時間 2024 年 4 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Cloud Run のダイレクト VPC 下り（外向き）の一般提供（GA）が開始されました。この機能を使用すると、Cloud Run リソースで、サーバーレス VPC アクセスコネクタ経由でプロキシを行わなくても、VPC ネットワークに直接トラフィックを送信できます。これにより、より少ない費用で、簡単かつ迅速なセットアップが可能になります。

実際、ダイレクト VPC 下り（外向き）は、VPC コネクタとデフォルトの Cloud Run インターネット下り（外向き）パスの両方との比較で、インスタンスあたり毎秒最大 1 GB という約 2 倍のスループットを実現しています。トラフィックの送信先が VPC 上の宛先、Cloud Storage のような他の Google Cloud サービス、パブリックインターネット上の他の宛先のいずれであっても、ダイレクト VPC 下り（外向き）は、パフォーマンス重視のアプリに高いスループットと低いレイテンシを提供します。

プレビュー版の新機能

注目すべき改善点と新機能:

Cloud Run を利用できるすべてのリージョンで、ダイレクト VPC 下り（外向き）が有効になりました。
ダイレクト VPC を使用した Cloud Run サービスのリビジョンごとに、割り当てで制御できるインスタンスを 100 個以上にスケールできるようになりました。さらにスケールする必要がある場合は、標準の割り当て増加リクエストプロセスを使用できます。
Cloud NAT に対応し、ダイレクト VPC 下り（外向き）トラフィックが VPC フローログとファイアウォールルールロギングに含まれるようになりました。

これらのアップデートは、プレビュー版のお客様、中でも高度なスケーラビリティ、ネットワーキング、セキュリティの要件を持つ大規模なお客様から報告された主要な問題に対処しています。

お客様からのフィードバック

昨年より、DZ BANK を含む多くのお客様にダイレクト VPC 下り（外向き）のプレビュー版をお試しいただいており、素晴らしいフィードバックが寄せられています。

「Cloud Run のダイレクト VPC 下り（外向き）により、サーバーレス VPC アクセスコネクタとそれに関連付けられた専用の /28 サブネットを維持する必要がなくなったため、プラットフォームチームは新しい Cloud Run ワークロードをより簡単にオンボーディングできるようになりました。新しい Cloud Run サービスが定期的に作成される当社の動的な環境で、このシンプルなネットワーキング アーキテクチャにより、手作業を要する時間が週あたり 4～6 時間短縮されました。また、30 以上の VPC コネクタをデプロビジョニングし、それらの稼働にかかっていた追加のコンピューティング費用を節約しました。」- DZ BANK、シニアクラウドエンジニア Tim Harpe 氏

ダイレクト VPC 下り（外向き）を有効にしてすべての下り（外向き）トラフィックが VPC に送信されるようにすると、Cloud Run、GKE、VM からのすべてのトラフィックに対して同じツールと機能を使用できます。

次のステップ

ダイレクト VPC 下り（外向き）は、本番環境ワークロードに対応しています。今すぐお試しいただき、より少ない費用でより優れたパフォーマンスをお楽しみください。

ダイレクト VPC 下り（外向き）の仕組みの基礎については、プレビュー版に関するブログ投稿と、ブログ投稿に掲載されている解説動画をご覧ください。

ーデベロッパーリレーションズ エンジニア Wietse Venema

ーサーバーレス ネットワーキングおよびセキュリティ担当プロダクト マネージャー Xiaowen Xin

Cloud Run のボリュームマウントのご紹介: アプリを Cloud Storage や NFS に接続

Wed, 03 Apr 2024 01:30:00 +0000

※この投稿は米国時間 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 バケットをマウントすることができます（詳細と手順は以下の「試してみる」のセクションにあります）。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run services update [SERVICE_NAME] \\\r\n--execution-environment gen2 \\ \r\n--add-volume=name=v_mount,type=cloud-storage,bucket=[YOUR_BUCKET_NAME] \\\r\n--add-volume-mount=volume=v_mount,mount-path=[MOUNT_PATH]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6277b63340>)])]>

ボリュームマウントはさまざまな場面で役に立ちます。

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'.単一のコマンドでこれを実行できます。

code_block: <ListValue: [StructValue([('code', "gcloud beta run deploy --image nginx [SERVICE_NAME] \\\r\n--execution-environment gen2 --port 80 \\\r\n--add-volume=name=html-volume,type=cloud-storage,bucket=[YOUR_BUCKET_NAME],readonly=true \\\r\n--add-volume-mount=volume=html-volume,mount-path='/usr/share/nginx/html'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6277b636a0>)])]>

最後のステップとして、NGINX のコンテンツキャッシュや Cloud CDN を使用して、コンテンツのキャッシュ保存を必ず設定してください。キャッシュ保存をしなければ、各リクエストが Cloud Storage GET リクエストをトリガーし、コストの増加や不要なレイテンシにつながります。

試してみる

Cloud Storage バケットや NFS ファイル共有をマウントするには、gcloud コマンドを使用して、Cloud Run YAML リソース定義を更新するか、Terraform を介してデプロイします。たとえば、新しい Cloud Run ジョブにソースベースのデプロイを実行し、次のコマンドで Cloud Storage バケットをマウントします。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run jobs deploy [SERVICE_NAME] --source \\\r\n--execution-environment gen2 \\\r\n--add-volume=name=[VOLUME_NAME],type=cloud-storage,bucket=[BUCKET_NAME] \\ \r\n--add-volume-mount=volume=[VOLUME_NAME],mount-path=[MOUNT_PATH]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6277b63dc0>)])]>

同様に、NFS ファイル共有を Cloud Run にボリュームとしてマウントできます。NFS サーバーをまだお持ちでない場合は、Google Cloud が提供するフルマネージド NFS である Cloud Filestore の使用をおすすめします。

詳細と利用開始の方法については、Google のドキュメントをご覧ください。

Cloud Storage バケットをサービスやジョブにマウントする
NFS ボリュームをサービスやジョブにマウントする

Cloud Run のボリュームマウントにより、データへのアクセス、既存アプリケーションの移行、事前構築済みのコンテナイメージの構成が驚くほど容易になります。ぜひプレビュー版でこの機能をお試しください。

ー戦略的クラウドエンジニア Christoph Stanger

ープロダクトマネージャー Karolína Netolická

Firestore Multiple Databases の一般提供を開始

Tue, 13 Feb 2024 01:50:00 +0000

※この投稿は米国時間 2024 年 2 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Firestore Multiple Databases が一般提供となりましたのでお知らせいたします。この機能により複数の Firestore データベースを 1 つの Google Cloud プロジェクトで管理できるようになり、データ分離、セキュリティ、リソース管理、費用追跡が強化されます。このマイルストーンで、複数のデータベースが Google Cloud コンソール、Terraform リソース、Firestore のすべての SDK で完全にサポートされるようになりました。

それぞれの Firestore データベースは独立分離された状態で動作するため、堅牢なデータの分離とパフォーマンスが確保されます。たとえば、1 つのデータベースでトラフィック負荷がホットスポット化しても、プロジェクト内のその他のデータベースのパフォーマンスに悪影響が及ぶことはありません。

Firestore データベースを作成してみる

コンソールを使って、数回クリックするだけで Firestore データベースを作成する方法は、次のとおりです。

Firestore サービスに移動します。
[データベースを作成] ボタンをクリックします。
データベースの識別子であるデータベース ID を選択します。
必要なデータベース構成設定（データベースモード、ロケーション、セキュリティルール構成など）を選択します。

注: データベース ID とロケーションは作成後に変更できないため、慎重に選択してください。

Firestore の作成と管理をさらに自由に行いたい場合は、gcloud、Firebase CLI および Terraform を使用して、Firestore データベースを作成および管理できます。こうしたオプションの詳細なガイドについては、Firestore ドキュメントの「データベースの作成」セクションをご覧ください。

データベースのセキュリティを構成する

Firestore なら、IAM 条件を使用して、個々のデータベースにきめ細かいセキュリティ構成を適用できます。この機能により、さまざまなデータベースに個別のセキュリティポリシーを適用することで、正確かつ詳細な管理が可能です。たとえば、特定のユーザーグループだけに指定されたデータベースへのアクセス権を付与することで、堅牢なセキュリティとデータ分離が実現します。

条件エディタツールを使って特定のデータベースに条件を設定する方法は、次のとおりです。

resource.type として "firestore.googleapis.com" を選択します。
resource.name にデータベースリソース名を指定します（形式は "projects/<project-id>/databases/<database-id>" とします）。

セキュリティポリシーを構成する際に知っておくべきことが、いくつかあります。

条件が指定されていない場合、権限が付与されているすべての IAM プリンシパルは本質的に、プロジェクト内のあらゆる Firestore データベースにアクセスできます。
Firestore はタグにより統合されます。これによりタグが関連付けされ、データベースの指定されたグループへのアクセスを許可または拒否できます。詳細については、タグと条件付きアクセスのドキュメントをご覧ください。
Firestore は類似の機能を Firebase セキュリティルールにも適用するため、Firebase プロジェクト内のデータベースアクセスのきめ細かい管理が可能です。Firestore 向けの詳細な Firebase のセキュリティルールについて詳しくは、「Firestore セキュリティルールを設定する」セクションをご覧ください。

データベースの使用量と費用を請求内訳で確認する

Firestore では、データベースごとに詳しい請求額と使用量の内訳が提供されます。こうした費用データにアクセスするには、BigQuery を使用します。たとえば、以下のクエリは 2023 年 10 月 18 日（UTC）のデータ使用料を、Firestore データベース ID ごとに分類して取得する方法を示しています。

Cloud Billing データを BigQuery にエクスポートするためのシームレスなワークフローを確立するには、Cloud Billing のドキュメントで詳細ガイドをご確認ください。また、タグを使用して、複数の Firestore データベースにまたがる詳細な費用内訳を利用することもできます。結果データの構造とスキーマに関して詳しくは、「詳細なデータエクスポートの構造」のドキュメントをご参照ください。

データベースを削除する

Firestore データベースが目的を達成したため必要なくなった場合、数回クリックするだけで、直接コンソールから簡単に削除できます。

データベースを削除する際に知っておくべきことが、いくつかあります。

削除 - データベースを削除すると、Firestore がユーザーに変わってデータの削除を行います。
費用 - 削除操作の実行に関連する費用は一切かかりません。Firestore は、削除操作を行った 1 日後からストレージ費用の請求を停止します。
バックアップ - Firestore のバックアップは、独立したリソースのライフサイクルごとに行われます。Firestore データベースを削除しても、ソースデータベースに関連するバックアップの自動削除は行われません。

ベストプラクティス

Firestore を初めて使用する場合は、リソース名「(default)」の新しいデータベースで開始することをおすすめします。(default) データベースなら無料枠のサポートを利用でき、即座の費用を負担することなく Firestore のさまざまな機能を試すことができます。さらに、以前の App Engine ランタイムのサポートも、デフォルトのデータベース限定でご利用いただけます。
重要なデータベースでは、常に削除保護を有効にしてください。この安全対策により、データが誤って削除されるのを防ぎ、本番環境でデータの整合性を確保できます。
データベースを作成する際、データベースのリソース名とロケーションは慎重に選んでください。こうした属性は、作成後に変更できません。ただし、既存のデータベースを削除した後に、異なるロケーションで同じリソース名の新しいデータベースを作成することは可能です。こうすることで、ロケーションを変更し、元のリソース名を保持できます。新しいロケーションでデータを復元する場合は、必ず事前にバックアップを行ってください。

次のステップ

近日中に、Firebase コンソールが複数の Firestore データベースの管理に対応するようになる予定です。今後の情報にご注目ください。

ー Firestore、ソフトウェア エンジニア Sichen Liu

ー Firestore、シニア プロダクト マネージャー リード Minh Nguyen

すべてのランタイムをモニタリング: Managed Service for Prometheus が Cloud Run に対応

Mon, 29 Jan 2024 01:40:00 +0000

※この投稿は米国時間 2024 年 1 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションを仮想マシン、Kubernetes、サーバーレスランタイムのいずれで実行していようと、重要なビジネス指標とアプリケーション指標をモニタリングできる必要があります。近年、Prometheus はモニタリングや指標の選択肢としてよく使われるようになってきましたが、大規模に実行することは困難です。Google Cloud の Managed Service for Prometheus は、Google Kubernetes Engine（GKE）、Compute Engine、オンプレミス、さらにその他のクラウドで実行されるアプリケーションに対応しており、複数の環境にわたって Prometheus を大規模に実行する際の苦労を排除するものですが、このたび、Managed Service for Prometheus が Cloud Run にも対応したことをお知らせします。Cloud Run は Google Cloud のサーバーレスランタイムです。

Cloud Run でアプリケーションをデプロイすることに関心を持ちながらも、Prometheus と Prometheus コミュニティの堅牢な指標やオブザーバビリティのベストプラクティスをあきらめられないお客様が、両方の長所を利用できるようになりました。ネイティブの時系列データとユーザー定義の指標を Cloud Run からエクスポートする、公式にサポートされた方法が確立されたことにより、組織は Cloud Run のシンプルさと使いやすさのメリットを享受しながら Prometheus エコシステムを使い続けることができます。しかも、OpenTelemetry エコシステムを好む企業のために、このリリースは Cloud Run からの OTLP 指標のエクスポートにも対応しています。

あらゆるデプロイメントとランタイム向けの Prometheus 指標

この機能のリリースにより、一度 Prometheus または OTLP 指標でアプリケーションを計測すると、Compute Engine、GKE、Cloud Run にデプロイし、Cloud Monitoring または Grafana のいずれかで 1 行の PromQL を使ってデータのクエリやアラートをまとめて実行できるようになります。また、マネージドコレクションや OpenTelemetry を使って Google Cloud の外部から指標を収集するように Managed Service for Prometheus を構成すれば、オンプレミスや他のクラウドを含む複数の環境全体で Prometheus の指標データをクエリすることもできます。

Managed Service for Prometheus を使用すると、クロス環境、クロスランタイム、クロスクラウドのモニタリングが容易になります。

Cloud Run サイドカーの機能と柔軟性を Managed Service for Prometheus のシンプルさと組み合わせることで、コレクションを複雑に構成しなくても Cloud Run から指標を取り込むことができます。コレクタサイドカーのイメージを Cloud Run サービスに追加すれば、後は Google Cloud が処理します。GKE または Compute Engine で同じ Prometheus 指標を収集したら、その指標をすべての環境にわたって簡単かつ直感的にクエリできます。

Cloud Monitoring UI で 1 行の PromQL を使って、ランタイム全体で同じ指標をクエリする際の画面。

サーバーレス環境におけるオブザーバビリティの向上

Cloud Run をご利用のお客様の多くは、Cloud Monitoring の Cloud Run 指標をそのまま使用しています。ただし、これらの指標はサービスのパフォーマンスについて有効な情報を提供しますが、アプリケーション内部の情報については提供しません。また、エンドユーザーがカスタマイズすることもできません。Cloud Run で Managed Service for Prometheus がサポートされたことにより、ビジネス指標、ランタイム指標、または時系列として提供されるその他のデータについて、Cloud Run デプロイメント内からモニタリングし、アラートを送信できるようになりました。

Cloud Run で Prometheus 指標がサポートされたことにより、Kubernetes から Cloud Run への移行も容易になりました。Prometheus は Kubernetes をモニタリングするための事実上の標準となり、クラウドネイティブコミュニティの 86% で使用されています。このリリースにより、ユーザーは指標を書き換えたり、オープンソースコミュニティで作成された豊富なリソースの活用をあきらめたり、モニタリング、クエリ、アラートの方法を変更したりすることなく、好みや設定に応じて同じアプリケーションを Cloud Run または GKE のいずれかにデプロイできます。また、使用するランタイム環境に関係なく、すでに導入しているものと同じ指標パッケージ、チャート、ダッシュボード、リアルタイムアラートを使用できます。

このリリースは、Prometheus の規則と（サーバーがスクレイピングする）「pull」指標をサポートしています。また、OpenTelemetry の規則や（サーバーに直接エクスポートされる）「push」指標を使いたいお客様のために、Cloud Run は OpenTelemetry サイドカーを使用した OTLP 指標の作成もサポートしています。

使ってみる

この機能はすべての Cloud Run デプロイメントですぐに使用できます。詳細と手順については、Managed Service for Prometheus ドキュメントの「Cloud Run 用の Prometheus サイドカーを使用する」セクションをご確認ください。

さらに詳しく知りたい方は、2024 年 3 月 5 日に開催されるウェブセミナー Instrumenting Cloud Run with Prometheus or OpenTelemetry metrics にぜひご参加ください。

ーシニア プロダクト マネージャー Lee Yanco

ー Google Cloud サーバーレス担当プロダクト マネージャー Sagar Randive

遅延が発生していた Cloud Run サービスを修正した方法のご紹介

Fri, 01 Dec 2023 03:00:00 +0000

※この投稿は米国時間 2023 年 11 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

ストレステスト中に、アプリに遅延が発生して応答にかかる時間が長くなり、ほとんど応答しない状態になったとします。その理由を考えてみましょう。

私は、Nexuzhealth を支援し、Cloud Run 上の Go アプリのパフォーマンスの問題をデバッグしました。Nexuzhealth は、あらゆる人が医療記録の管理をより適切に、より効率良く行えるようにしているベルギーのヘルスケア IT 企業です。これは、複数の医療機関を受診する患者にとって非常に役に立ちます。

事前にストレステストを実施したのは実に効果的でした。おかげで本番環境に入る前に異常を検出して、修正することができました。根本原因が明らかではなかったので、私は Nexuzhealth とともに調査を開始しました。Google Cloud のサーバーレスサービスを活用してお客様が成功できるよう喜んでお手伝いさせていただきました。

問題は簡単に再現でき、数百件のリクエストで負荷テストを開始すると、そのたびに応答時間の低下が観察されました。アプリは自動スケーリングを使用しており、新しいサーバーインスタンスが起動するたびサービスが低速になり、数十秒間応答しなくなりました。リクエストの処理に、予想よりもはるかに長い時間がかかっていました。いったい何が起きていたのでしょうか？

パフォーマンスの問題を調査するために、サーバーのログと指標、アプリケーションのソースコードが必要でした。サーバーログには、タイムスタンプ付きのすべてのリクエストと、各リクエストにつき適切なデータベースへの接続に関する情報が含まれていました。そこから、アプリがさまざまなデータベースへの接続を確立するのに多くの時間を費やしていることがわかりました。マルチテナントであるため、データベースインスタンスはリクエストごとに異なる可能性があります。

医療研究所や薬局などの多くのテナントも、データへのアクセスに同じ Nexuzhealth アプリを使用しています。次に示すように、各テナントのデータは、独自のデータベース内で他のテナントから厳密に分離されています。

マルチテナントアプリケーション

Cloud Run は、オンデマンドでコンテナを起動して受信トラフィックを処理するフルマネージドプラットフォームです。アプリインスタンスは、数多くのデータベースインスタンスに接続する必要があります。

そこで、リクエストハンドラーが新しいデータベース接続を確立するか、ローカルインスタンスの状態に保存されている既存の接続を再利用するかを決定する領域のソースコードを確認してみました。

ユーザーリクエストごとに、コードは現在のアプリインスタンスが適切なテナントデータベースにすでに接続されているかどうかを確認します。そうでない場合は、新しい接続が作成されます。これは遅延初期化と呼ばれます。

アプリケーションは起動時に、すぐにデータベースに接続するか（積極的な初期化）、最初に受信するユーザーリクエストを待つか（遅延初期化）という選択に直面します。アプリが Cloud Run または Google Kubernetes Engine（GKE）で自動スケーリングを使用する場合、新しいインスタンスが頻繁に起動されるため、この問題は重要です。

応答性が向上するため、私は通常は積極的な初期化を好んで使用します。最初のリクエストが処理されるとき、データベースがすでに接続された状態になっているため、最初のリクエストの応答時間が数百ミリ秒節約されます。

マルチテナントを使用する Nexuzhealth の場合は、遅延初期化の方が適しています。サーバーをオンデマンドでデータベースに接続し、自動スケーリングの速度に大きく影響する起動の待ち時間を節約することは理にかなっています。

各テナントデータベースへの接続がすべてのアプリインスタンスを通じて 1 回だけ作成され、同じテナントに対する後続のリクエストに再利用されることを私たちは期待していました。ログにはエラーや異常なメッセージは見られませんでした。

このアルゴリズムを使用すると、アプリは正しく動作しますが、新しいインスタンスが開始されるたびにパフォーマンスが大きく低下します。どうなっているのでしょうか？コードスニペットをもう一度詳しく見てみましょう。

dbmap データ構造は、リクエストを処理する多くのスレッドによって共有されます。多くのリクエストを同時に処理するアプリインスタンスで共有状態を扱うときは、データ競合を避けるために同期が適切に行われるようにする必要があります。このコードは RW ロックを使用しますが、上記の疑似コードには 2 つの問題があります。

まず、最も遅いオペレーションは createConnection() で、200 ミリ秒以上かかる場合があります。このオペレーションは、書き込みモードで RW ロックを保持したまま実行されます。つまり、サーバーによって同時に作成できるデータベース接続は 1 つだけです。これは最適ではないかもしれませんが、パフォーマンスの問題の根本的な原因ではありませんでした。

次に、より重要なことですが、上記のコードには TOCTOU の問題があります。マップを読み取って接続を作成する間に、接続が別のリクエストによってすでに作成されている可能性があります。これは競合状態です。

競合状態の発生はまれである可能性があり、再現が困難です。今回のケースでは、不運にも次のようなイベントが続いたため、問題が毎回発生していました。

アプリケーションがラフィックを処理している。
より多くのトラフィックが到着し、サーバーインスタンスの負荷が増加している。
オートスケーラーが、新しいインスタンスの作成をトリガーする。
インスタンスが HTTP リクエストを処理できる状態になると、すぐに多くのリクエストが新しいインスタンスにルーティングされる。まるで thundering herd 問題のようです。
いくつかのリクエストは空のマップを読み取り、データベース接続を作成する。
書き込みモードでロックを取得できるのは 1 つのリクエストだけであり、データベース接続を作成して再びロックを解放するまでに約 200 ミリ秒かかる。
その間、他のすべてのリクエストはブロックされ、ロックの取得を待機する。
2 番目（後続）のリクエストが書き込みモードでロックを取得するとき、マップが変更されたことは認識されず（マップが空であることはすでにチェックされている）、独自の新しい冗長接続を作成する。

すべてのリクエストは長いオペレーションを実行しており、実質的に相互に待機している状態となることが、高いレイテンシが確認された原因となっていました。最悪の場合、アプリが非常に多くの接続を開いているため、データベースサーバーが接続を拒否し始める可能性があります。

解決策

考えられる解決策は、書き込みモードでロックを取得した直後にマップを再度チェックすることであり、これはダブルチェックロックの方法として使えます。

この小さな変更（コードを 2 行追加するのみ）により、同じテナントに対する 2 つのリクエストによってテナントのデータベース接続が上書きされなくなります。ダブルチェックパターンを試してみると、パフォーマンスが劇的に向上しました。

また、複数のテナントの接続を同時に作成して、新しく開始したインスタンスのパフォーマンスをさらに向上させる、より高度なパターンを考えることもできます。Go で書かれたこちらのシミュレーションをご覧ください。

Cloud Run におけるアプリのパフォーマンスの最適化について詳しくは、デベロッパーガイドのパフォーマンスの最適化セクションをご確認ください。

-デベロッパーアドボケイト Valentin Deleplace

サーバーレス

Identity-Aware Proxy（IAP）で Cloud Run のセキュリティを簡素化する

Cloud Run への IAP の直接導入

DRS 使用時に公開アクセスを許可する

ご利用にあたって

NVIDIA RTX PRO 6000 により、Cloud Run 上で高性能推論とサーバーレス コンピューティングが融合

強力な GPU プラットフォーム

使ってみる

Firestore の新しい高度なクエリエンジンでアプリケーションを強化

新しいクエリエンジンとパイプライン オペレーションのエクスペリエンス

ご利用中の Firestore の移行

予測可能な料金と最適化された費用

Firestore パイプライン オペレーションを使ってみる

金融機関のデジタルトランスフォーメーションを加速する、金融リファレンスアーキテクチャ

アーキテクチャの主要テーマ

1. ゼロトラストと多層防御による堅牢なセキュリティ

2. サーバレスと GKE によるモダンなアプリケーション開発

3. マルチリージョン、マルチクラウドによる事業継続性の確保

4. 生成 AI の安全な活用

おわりに

Google Cloud のコンピューティング費用を今すぐ削減する 11 の方法

1. 適切な VM インスタンスを選択する

2. ブロック ストレージの選択を最適化する

3. カスタム コンピューティング クラスを検討する

4. カスタム マシンタイプ（CMT）を活用する

5. 確約利用割引を最大限に活用する

6. 未使用のディスク容量を管理する

7. Spot VM を使用する

8. 最適化案を適用する

9. 自動スケーリングとスケジューリングを活用する

10. 詳細な請求金額の分析で費用を把握する

11. サーバーレスの代替手段を検討する

今すぐ費用削減を始めましょう

新しい Gemini CLI 拡張機能でアプリのデプロイとセキュリティ分析を自動化

ローカルホストからリリースまで: Cloud Run と Docker Compose で AI アプリのデプロイを簡素化

Cloud Run ワーカープールで Kafka ワークロードのスケーリングを簡単に

Cloud Run で GPU の一般提供を開始: AI ワークロードの実行が誰にとっても簡単に

フリップアウト: クラウド接続でクラシックなピンボール マシンをモダナイズ

問題点

スクリプトをフリップ

大成功！クラウドの利点

もっと先へ

NVIDIA GPU を使用した Cloud Run での AI 推論アプリケーションの実行

Cloud Run で NVIDIA GPU を使用する

パフォーマンス

Ollama を使用してサンプルアプリをデプロイする

使ってみる

-Google Cloud サーバーレス担当プロダクト マネージャー Sagar Randive-Google Cloud サーバーレス担当シニアスタッフ ソフトウェア エンジニア Wenlei (Frank) He

Cloud Functions は Cloud Run 関数に - イベント ドリブン プログラミングを 1 つの統合サーバーレス プラットフォームで実現

既存のAPI、gcloud コマンド、terraform モジュールの継続的なサポート

関数を使用してプラットフォームを接続する

Cloud Run 関数を使ってみる

-シニア プロダクト マネージャー James Ma

フレキシブル確約利用割引がさらに柔軟に

新たな Compute フレキシブル CUD

Autopilot CUD の提供終了

ご利用方法

次のステップ

-Google Kubernetes Engine、グループ プロダクト マネージャー William Denniss-Google Compute Engine、シニア プロダクト マネージャー Yasmin Mowafy

Artifact Registry アセットをサーバーレスで組織やプロジェクト間にわたりリリースする

別の方式を使用しない理由

IaC でデプロイする方法

その他のリソース

認証コンテキストを含む、Firestore の Eventarc との統合が一般提供に

サンプルのチュートリアル

次のステップ

-Firestore、ソフトウェア エンジニア Josué Urbina

-Firestore、ソフトウェア エンジニア Hansi Mou

Firestore トリガーが Eventarc と統合し、3 つのトリガー先が追加

Cloud Run のダイレクト VPC 下り（外向き）の一般提供を開始

プレビュー版の新機能

お客様からのフィードバック

次のステップ

Cloud Run のボリューム マウントのご紹介: アプリを Cloud Storage や NFS に接続

1. ストアアプリの構成

2. イベント ドリブン Cloud Storage ハンドラ

3. ベクトル データベース ファイルの読み込み

4. 静的なウェブサイトの提供

試してみる

Firestore Multiple Databases の一般提供を開始

NVIDIA RTX PRO 6000 により、Cloud Run 上で高性能推論とサーバーレスコンピューティングが融合

新しいクエリエンジンとパイプラインオペレーションのエクスペリエンス

Firestore パイプラインオペレーションを使ってみる

2. ブロックストレージの選択を最適化する

3. カスタムコンピューティングクラスを検討する

4. カスタムマシンタイプ（CMT）を活用する

フリップアウト: クラウド接続でクラシックなピンボールマシンをモダナイズ

-Google Cloud サーバーレス担当プロダクトマネージャー Sagar Randive
-Google Cloud サーバーレス担当シニアスタッフソフトウェアエンジニア Wenlei (Frank) He

Cloud Functions は Cloud Run 関数に - イベントドリブンプログラミングを 1 つの統合サーバーレスプラットフォームで実現

-シニアプロダクトマネージャー James Ma

-Google Kubernetes Engine、グループプロダクトマネージャー William Denniss
-Google Compute Engine、シニアプロダクトマネージャー Yasmin Mowafy

-Firestore、ソフトウェアエンジニア Josué Urbina

-Firestore、ソフトウェアエンジニア Hansi Mou

Cloud Run のボリュームマウントのご紹介: アプリを Cloud Storage や NFS に接続

2. イベントドリブン Cloud Storage ハンドラ

3. ベクトルデータベースファイルの読み込み

ベストプラクティス