ネットワーキング

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

Tue, 21 Apr 2026 01:10:00 +0000

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

既存のアプリケーションロードバランサインフラストラクチャをオンプレミスのハードウェアソリューションから Cloud Load Balancing に移行すると、スケーラビリティと費用効率が大幅に向上し、Google Cloud エコシステム内での緊密な統合が実現します。しかし、多くの場合、「現在のロードバランサ構成はどうなるのか」という根本的な疑問も生じます。

既存のオンプレミスロードバランサの構成には、トラフィック操作のためのビジネスクリティカルなロジックが何年分も蓄積されていることがよくあります。こうした既存の機能は完全に移行できます。加えて、この移行は、トラフィック管理をモダナイズして簡素化する絶好の機会にもなります。

このガイドでは、既存のロードバランサを Google Cloud のアプリケーションロードバランサに移行するための実践的なアプローチを紹介します。このアプローチでは、一般的な機能に対応するために、宣言型構成と革新的なイベントドリブン型 Service Extensions エッジコンピューティング機能の両方を活用します。

シンプルで段階的な移行アプローチ

命令型のスクリプトベースシステムからクラウドネイティブな宣言型ファーストモデルへの移行には、体系的な計画が必要です。そこで、4 つのフェーズからなるシンプルなアプローチをおすすめします。

フェーズ 1: 調査とマッピング

移行を開始する前に、現状を把握する必要があります。現在のロードバランサの構成を分析して分類しましょう。各ルールの意図は何ですか？単純な HTTP から HTTPS へのリダイレクトを行っていますか？HTTP ヘッダーの操作（追加または削除）に関与していますか？それとも、複雑なカスタム認証ロジックを扱っていますか？

ほとんどの構成は、次の 2 つの主なカテゴリに分類されます。

一般的なパターン: リダイレクト、URL の書き換え、基本的なヘッダー操作、IP ベースのアクセス制御リスト（ACL）など、ほとんどのウェブアプリケーションに共通するロジック。
カスタムビジネスロジック: カスタムの独自トークン認証、高度なヘッダーの抽出 / 置換、HTTP 属性に基づく動的なバックエンド選択、HTTP レスポンス本文の操作など、アプリケーションに固有の複雑なロジック。

フェーズ 2: Google Cloud における同等機能の選択

ルールを分類したら、次はそれらを適切な Google Cloud 機能にマッピングします。これは 1 対 1 の置き換えではなく、戦略的な選択となります。

オプション 1: 宣言型の方法（ルールの約 80%）一般的なパターンの大部分については、通常はアプリケーションロードバランサに組み込まれている宣言型機能を活用することが最適なアプローチです。スクリプトの代わりに、構成ファイルで望ましい状態を定義します。これにより、管理、バージョン管理、スケーリングが容易になります。

宣言型機能マッピングの一般的なパターン:

リダイレクト / 書き換え -> アプリケーションロードバランサの URL マップ
ACL / スロットリング -> Google Cloud Armor のセキュリティポリシー
セッションの永続性 -> バックエンドサービス構成

オプション 2: プログラムによる方法（複雑なカスタムルールの場合）複雑なカスタムビジネスロジックを扱う場合、プログラムによる同等の方法として Service Extensions があります。これは、Rust、C++、Go で記述したカスタムコードをロードバランサのデータパスに直接挿入できる強力なエッジコンピューティング機能です。このアプローチにより、最新のマネージド型高パフォーマンスフレームワークで柔軟性を確保できます。

このフローチャートは、各構成に適した Google Cloud の機能を判断するためにお役立てください。

フェーズ 3: テストと検証

構成に適した方法を選択したら、本番環境のセットアップを反映したステージング環境に新しいアプリケーションロードバランサ構成をデプロイする準備が整います。移行対象のロジックに特に注意しながら、アプリケーションのすべての機能を徹底的にテストします。自動テストと手動 QA を組み合わせて、リダイレクトやセキュリティポリシー、そしてカスタムの Service Extensions ロジックが想定どおりに動作することを検証します。

フェーズ 4: 段階的なカットオーバー（カナリアデプロイ）

すべてのトラフィックについて切り替えを一度に行うのではなく、段階的な移行戦略を実施します。最初は、本番環境トラフィックの少ない割合（5～10% など）を新しい Google Cloud ロードバランサにルーティングします。この初期段階では、レイテンシ、エラー率、アプリケーションのパフォーマンスなどの主要な指標を必ずモニタリングしてください。確信が持てたら、アプリケーションロードバランサにルーティングするトラフィックの割合を徐々に増やしていきます。重大な問題が発生した場合に備えて、以前のインフラストラクチャに戻すための明確なロールバック計画も常に用意しておきましょう。

スムーズな移行のためのベストプラクティス

Google の実践経験に基づき、ロードバランサの移行計画を立てる際に役立つ推奨事項を以下にまとめます。

先に分析してから移行する: 既存の構成を徹底的に分析することが最も重要なステップです。不要になったロジックの「リフト＆シフト」を行わないようにします。
宣言型を優先する: デフォルトとして、Google Cloud のマネージド型、宣言型の機能（URL マップ、Cloud Armor）を常に先に使用します。これらの機能は、よりシンプルでスケーラブルであり、メンテナンスも少なくて済みます。
Service Extensions は戦略的に使用する: Service Extensions は、宣言型機能では処理できない複雑なカスタムビジネスロジックのために取っておきます。
すべてをモニタリングする: 移行中は、既存のロードバランサと Google Cloud ロードバランサの両方を継続的にモニタリングします。トラフィック量、レイテンシ、エラー率などの主要な指標を注視して、問題が発生した場合は即座に検出して対処します。
チームのトレーニングを行う: Cloud Load Balancing のコンセプトについて、チームにトレーニングを提供します。これにより、チームは新しいインフラストラクチャを効果的に運用、維持できるようになります。

既存のオンプレミスロードバランサインフラストラクチャからの移行は、単なる技術的なタスクではなく、アプリケーション配信をモダナイズする機会です。現在のロードバランシングの構成と機能を、宣言型のアプリケーションロードバランサ機能またはプログラムによる Service Extensions のいずれかに入念にマッピングすることで、スケーラビリティ、復元力、費用対効果に優れたインフラストラクチャを構築し、将来の需要に対応できます。

移行を始めるには、アプリケーションロードバランサと Service Extensions の特徴や高度な機能を確認して、アプリケーションに適した設計を考案します。詳細なガイダンスや複雑なユースケースについては、Google Cloud チームにお問い合わせください。

- Google Cloud、カスタマーエンジニア、Gopinath Balakrishnan

- Google Cloud、カスタマーエンジニア、Xiaozang Li

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

Fri, 17 Apr 2026 01:30:00 +0000

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

昨今のエージェント型 AI 環境では、ネットワークに新たな責任が課せられています。

従来のアプリケーションスタックでは、ネットワークは主にサービス間でリクエストを移動するものでした。しかし、最近のホワイトペーパー Cloud Infrastructure in the Agent-Native Era で説明されているように、エージェントシステムでは、モデル呼び出し、ツール呼び出し、エージェント間のやり取り、エージェントができることを定義するポリシーの決定の間にネットワークが位置します。多様なフレームワーク上に構築されることが多いエージェントが急速に普及しているため、すべてのエージェントパスにわたってガバナンスとセキュリティを一貫して大規模に適用する必要があります。これを実現するには、適用レイヤがアプリケーションレベルから基盤となるインフラストラクチャに移行する必要があります。つまり、ネットワークはもはや盲目的なトランスポートレイヤとして機能することはできず、より多くのことを理解し、より適切に適用を行い、より迅速に適応する必要があります。この移行において役立つのが Envoy です。

Envoy は、高パフォーマンスの分散プロキシおよびユニバーサルデータプレーンとして、大規模なスケーリングに対応するように構築されています。Google Cloud を含む要求の厳しいエンタープライズ環境で信頼されており、単一サービスのデプロイから、上り（内向き）、下り（外向き）、サイドカーの各パターンを使用した複雑なサービスメッシュまで、あらゆるものをサポートします。Envoy は、優れた拡張性、堅牢なポリシー統合、運用上の成熟度により、プロトコルが急速に変化し、制御が不十分な場合のコストが高くなる時代に特に適しています。エージェント型 AI を構築するチームにとって、Envoy は単なるコンセプトではなく、実用的でプロダクションレディな基盤です。

エージェント型 AI がネットワーキングの問題を変える

エージェントワークロードは依然としてトランスポートとして HTTP を使用することが多いですが、従来の HTTP 仲介役が依存する前提の一部には従いません。Model Context Protocol（MCP）や Agent2agent（A2A）などのプロトコルは、HTTP 上で JSON-RPC または gRPC を使用し、標準の HTTP リクエスト / レスポンスセマンティクスに加えて、クライアントとサーバーがそれぞれの機能を交換する MCP 初期化などのプロトコルレベルのフェーズを追加します。仲介役が適応する必要がある、エージェントシステムの主な側面は次のとおりです。

企業ガバナンスの多様な要件。主な課題は、安全性、セキュリティ、データプライバシー、規制遵守に関する、企業にとって譲れない幅広い要件を満たすことです。これらのニーズは、標準的なネットワークポリシーの枠を超えることが多く、内部システムとの緊密な統合、カスタムロジック、新しい組織ルールや外部規制に迅速に適応する能力が必要になります。そのため、企業が独自のガバナンスモデルを組み込める、拡張性の高いフレームワークが求められます。
ポリシー属性は、ヘッダーではなくメッセージ本文内に存在する。パスやヘッダーなどのポリシー入力に簡単にアクセスできる従来のウェブトラフィックとは異なり、エージェントプロトコルでは、重要な属性（モデル名、ツール呼び出し、リソース ID など）が JSON-RPC または gRPC ペイロードの奥深くに埋もれていることがよくあります。このため、仲介役はメッセージの内容を解析して理解し、コンテキストに応じたポリシーを適用できる必要があります。
多様で進化するプロトコルの特性に対応する。エージェントのプロトコルは一様ではありません。Streamable HTTP を使用する MCP のような一部のプロトコルでは、（Mcp-Session-Id などを使用した）分散プロキシ全体でのセッション管理が必要となるステートフルなインタラクションが導入されることもあります。このような多様な動作をサポートする必要性と、将来のプロトコルのイノベーションにより、本質的に適応性と拡張性に優れたネットワーキング基盤の必要性が高まっています。

これらの要因により、企業は単なる接続性以上のものを必要としています。ネットワークは、前述した重要なガバナンスのニーズを満たす中心的な役割を果たす必要があります。これには、プロトコルとエージェントの動作の急速な進化に対応しながら、一元化されたセキュリティ、包括的な監査可能性、きめ細かいポリシーの適用、動的なガードレールなどの機能を提供することが含まれます。簡単に言えば、エージェント型 AI はネットワークを単なるトランジットパスから重要な制御ポイントに変えます。

Envoy がこの移行に対応できる理由

Envoy は、以下の 3 つの理由から、エージェント型 AI ネットワーキングに最適です。

実証済み。Envoy は、セキュリティが重要な大規模環境で企業がすでに利用しており、新世代のトラフィック管理とポリシー適用を支える信頼できるプラットフォームとなっています。
拡張可能。Envoy は、ネイティブフィルタ、Rust モジュール、WebAssembly（Wasm）モジュール、外部処理パターンを通じて拡張できます。これにより、プラットフォームチームは、エコシステムが変化するたびにネットワーキングレイヤを再構築することなく、新しいプロトコルを採用できるようになります。
今すぐ運用に役立つ。Envoy はすでに、コントロールプレーンのゲートウェイ、適用ポイント、オブザーバビリティレイヤ、統合サーフェスとして機能しています。そのため、標準が定着するのを待たずに今すぐ移行する必要がある組織にとって、実用的な選択肢となります。

Envoy は、以下の中核的な強みを基盤として、エージェントネットワーキングに特有のニーズを満たすアーキテクチャの進歩を遂げています。

1. Envoy はエージェントトラフィックを理解する

エージェントネットワーキングの最初の要件はシンプルです。ゲートウェイはエージェントが実際に何をしようとしているのかを理解する必要があるということです。

ただし、これはそれほど簡単ではありません。MCP、A2A、OpenAI スタイルの API などのプロトコルでは、重要なポリシーシグナルがリクエスト本文内に存在することがあります。従来の HTTP プロキシは、本文を不透明なバイトストリームとして扱うように最適化されています。この設計は効率的ですが、プロキシで適用できることが制限されます。JSON メッセージを使用するプロトコルの場合、プロキシはポリシーの適用に必要な属性値を見つけるために、リクエスト本文全体をバッファリングする必要がある場合があります。特に、それらの属性が JSON メッセージの末尾にある場合はその必要性が高まります。使用されたトークンに基づくレート制限など、生成 AI プロトコルに固有のビジネスロジックでも、サーバーのレスポンスの解析が必要になる場合があります。

これに対処するために、Envoy は、HTTP で伝送されるプロトコルメッセージをデフレーミングし、有用な属性をフィルタチェーンの残りの部分に公開します。生成 AI プロトコルの拡張性モデルは、次の 2 つの目標を指針としています。

RBAC（ロールベースアクセス制御）やトレーサーなど、生成 AI プロトコルにそのまま対応する既存の HTTP 拡張機能を簡単に再利用できる。
デベロッパーが HTTP や JSON エンベロープを処理する必要がなく、生成 AI のビジネスロジックに集中できるように、生成 AI 固有の拡張機能用のデフレーミングされたメッセージに簡単にアクセスできる。

これらの目標に基づき、生成 AI プロトコルの新しい拡張機能は、依然として HTTP 拡張機能として構築され、HTTP フィルタチェーンで構成されます。これにより、OAuth や mTLS 認証などの HTTP ネイティブのビジネスロジックと生成 AI プロトコルのロジックを 1 つのチェーンで混在させる柔軟性が得られます。デフレーミング拡張機能は、HTTP で伝送されるプロトコルメッセージを解析し、抽出された属性、さらには解析されたメッセージ全体を含むアンビエントコンテキストを、既知のフィルタ状態とメタデータ値を介してダウンストリームの拡張機能に提供します。

Envoy では、すべてのポリシーコンポーネントが JSON エンベロープやプロトコル固有のメッセージ形式を独自に解析することを強制するのではなく、これらの属性を構造化されたメタデータとして利用できるようにします。ゲートウェイがプロトコルメッセージをデフレーミングすると、ext_authz や RBAC などの既存の Envoy 拡張機能がプロトコルプロパティを読み取り、MCP のツール名、A2A のメッセージ属性、OpenAI のモデル名などのプロトコル固有の属性を使用してポリシーを評価できます。

アクセスログには、モニタリングと監査を強化するためのメッセージ属性を含めることができます。プロトコル属性は Common Expression Language（CEL）ランタイムでも使用できるため、RBAC や複合拡張機能で複雑なポリシー式を簡単に作成できます。

バッファリングとメモリ管理Envoy は、HTTP リクエストをプロキシする際にできるだけ少ないメモリを使用するように設計されています。しかし、エージェントプロトコルの解析には、特に拡張機能でメッセージ全体をメモリに格納する必要がある場合、変動する量のバッファ領域が必要になることがあります。特に、信頼できないトラフィックが存在する場合は、拡張機能でより大きなバッファを使用できる柔軟性と、メモリ枯渇からの適切な保護のバランスを取る必要があります。

これを実現するために、Envoy ではリクエストごとにバッファサイズを制限できるようになりました。リクエストデータを保持するバッファもオーバーロードマネージャーと統合されているため、アイドルタイムアウトの短縮や、長期間にわたって最も多くのメモリを消費するリクエストのリセットなど、メモリ不足時のあらゆる保護アクションが可能になります。これらの変更により、Envoy はリソース効率を損なうことなく、生成 AI プロトコルのゲートウェイおよびポリシー適用ポイントとして機能できるようになっています。

2. Envoy は重要な事項に関するポリシーを適用する

トラフィックを理解することは、ゲートウェイがそれに基づいて動作できる場合にのみ役立ちます。

エージェントシステムでは、ポリシーはエージェントがアクセスできるサービスだけでなく、エージェントが呼び出せるツール、使用できるモデル、提示する ID、消費できる量、追加の制御が必要な出力の種類も規定するものです。これらは、単純なレイヤ 4 またはパスベースの制御よりも価値の高い決定であり、エージェントが企業に代わって行動することを許可する場合に、企業が重視する種類の制御です。

この点において Envoy は、トランスポートレベルのセキュリティとアプリケーション対応のポリシー適用を組み合わせることができるため、優れています。チームは、mTLS と SPIFFE ID でワークロードを認証し、RBAC、外部認証、外部処理、アクセスロギング、CEL ベースのポリシー式を使用してプロトコル固有のルールを適用できます。

この機能は、プラットフォームチームがエージェントの開発と適用を切り離せるため、非常に重要です。デベロッパーは有用なエージェントの構築に集中でき、オペレーターはツール、モデル、プロトコルが変化し続けても、ネットワークレイヤで一貫したゼロトラスト体制を維持できます。このゼロトラストの分離の好例は、「エージェントの背後にユーザーがいる」重要なシナリオ、つまり AI エージェントが人間のユーザーに代わってタスクを実行する必要がある場合です。従来、ユーザーの認証情報をアプリケーションに直接渡すことは、重大なセキュリティリスクをもたらします。エージェントが侵害されたり、プロンプトインジェクションによって操作されたりした場合、攻撃者は認証情報を抜き取ったり、不正使用したりできるためです。ID 管理を Envoy にオフロードすることで、プロキシはインフラストラクチャレイヤでユーザー委任トークンをアウトバウンドリクエストに自動的に挿入できます。エージェントが機密性の高い認証情報を直接保持することはないため、侵害されたエージェントがトークンを不正使用したり漏洩させたりするリスクは完全に排除され、アクションはユーザーの実際の権限に厳密にバインドされたままになります。

ケーススタディ: エージェントを特定の GitHub MCP ツールに制限するGitHub の問題をトリアージするエージェントを考えてみましょう。

GitHub MCP サーバーは数十のツールを公開している可能性がありますが、エージェントに必要なのは、list_issues、get_issue、get_issue_comments など、ごく一部の読み取り専用のツールのみである場合があります。ほとんどの企業にとって、この違いは重要です。有用なエージェントが、無制限のエージェントに自動的に変わるべきではありません。

MCP サーバーの前に Envoy を配置することで、ゲートウェイは mTLS handshake 中に SPIFFE を使用してエージェントの ID を検証し、デフレーミングフィルタを介して MCP メッセージを解析し、リクエストされたメソッドとツール名を抽出して、その特定のエージェント ID に対して承認されたツール呼び出しのみを許可するポリシーを適用できます。RBAC は、MCP デフレーミングフィルタによって作成されたメタデータを使用して、MCP メッセージ内のメソッドとツール名をチェックします。

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be4755c70>)])]>

この真の価値は、ポリシーがトラフィックに近い場所で、一元的に、エージェントの実際の動作に合った条件で適用されるという点です。

静的ルールの枠を超えて: 外部認証

RBAC ルールを使用して表現できない複雑なコンプライアンスポリシーは、ext_authz プロトコルを使用して外部認証サービスに実装できます。Envoy は、ext_authz RPC のコンテキストで、HTTP ヘッダーとともに MCP メッセージ属性を提供します。また、ピア証明書からエージェントの SPIFFE ID を転送することもできます。

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be47558b0>)])]>

これにより、エージェントや MCP サーバーがポリシーレイヤを認識する必要なく、エージェント ID、MCP メソッド、ツール名、その他のプロトコル属性の完全な組み合わせに基づいて、外部サービスが認証の決定を行うことができます。

プロトコルネイティブのエラーレスポンス

Envoy がリクエストを拒否した場合、返されるエラーは呼び出し元のエージェントにとって意味のあるものである必要があります。MCP トラフィックの場合、Envoy は local_reply_config を使用して、HTTP エラーコードを適切な JSON-RPC エラーレスポンスにマッピングできます。たとえば、403 Forbidden は、isError: true および人間が読めるメッセージを含む JSON-RPC レスポンスにマッピングできます。これにより、エージェントは不透明な HTTP ステータスコードではなく、プロトコルに適した拒否を受け取ることができます。

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

エージェントトラフィックのすべてがステートレスであるわけではありません。MCP の Streamable HTTP など、一部のプロトコルはセッション指向の動作に依存する場合があります。特に、トラフィックが複数のゲートウェイインスタンスを通過してスケーラビリティと復元力を実現する場合、仲介役にとって新たな課題が生じます。MCP セッションは、そのセッションを確立したサーバーにエージェントを効果的にバインドします。すべての仲介役は、受信 MCP 接続を正しいサーバーに転送するために、このことを認識する必要があります。

1 つのバックエンドでセッションが確立された場合、その会話における後のリクエストは正しい宛先に到達する必要があります。単一プロキシのデプロイでは簡単そうに聞こえますが、水平方向にスケールされたシステムでは、複数の Envoy インスタンスが同じエージェントからの異なるリクエストを処理する場合があり、より複雑になります。

パススルーゲートウェイ

よりシンプルなパススルーモードでは、Envoy はダウンストリーム接続ごとに 1 つのアップストリーム接続を確立します。主な用途は、外部 MCP サーバーに対するクライアントの認可、RBAC、レート制限、認証など、一元化されたポリシーの適用です。仲介役の間で転送されるセッション状態には、最初の HTTP 接続でセッションを確立したサーバーのアドレスのみが含まれる必要があります。これにより、セッション関連のすべてのリクエストがそのサーバーに送信されます。

異なる Envoy インスタンス間でのセッション状態の転送は、MCP サーバーから提供された MCP セッション ID に、エンコードされたセッション状態を追加することで実現されます。Envoy は、リクエストを宛先 MCP サーバーに転送する前に、セッション ID からセッション状態の接尾辞を削除します。このセッションの永続性は、Envoy の envoy.http.stateful_session.envelope 拡張機能を構成することで有効になります。

集約ゲートウェイ

集約モードでは、Envoy は複数のバックエンド MCP サーバーの機能、ツール、リソースを集約することで、単一の MCP サーバーとして機能します。これにより、ポリシーが適用されるだけでなく、エージェントの構成が簡素化され、複数の MCP サーバーのポリシー適用が統合されます。

このモードでのセッション管理はより複雑になります。セッション状態に、ツールとリソースから、それらをアドバタイズしたサーバーアドレスとセッション ID へのマッピングも含まれる必要があるためです。Envoy がエージェントに提供するセッション ID は、ツールやリソースが認識される前に作成され、マッピングはその後、Envoy とバックエンド MCP サーバー間の MCP 初期化フェーズが完了した後に確立される必要があります。

現在 Envoy で実装されているアプローチの一つは、ツールやリソースの名前と、その配信元サーバーの識別子およびセッション ID を組み合わせるというものです。通常、正確なツール名やリソース名はエージェントにとって意味がなく、この追加の来歴情報を伝えることができます。変更されていないツール名やリソース名が必要な場合は、マッピングのない Envoy インスタンスを使用し、特定のツールを呼び出す前に tools/list コマンドを発行してマッピングを再作成するというアプローチもあります。このアプローチは、レイテンシと引き換えに、MCP セッションの外部グローバルストアをデプロイする複雑さが伴います。現在、ユーザーからのフィードバックに基づいて計画中です。

これは、Envoy が単純なトラフィック転送にとどまらないことを意味するため重要です。これにより、Envoy は、実際のエージェントワークフロー（複数のリクエスト、ツール、バックエンドにわたるものを含む）の信頼できる仲介役として機能できます。

4. Envoy はエージェントの検出をサポートする

Envoy は、既知の AgentCard エンドポイントを介した A2A プロトコルとエージェントの検出のサポートを追加しています。エージェント機能が記載された JSON ドキュメントである AgentCard は、スキル、認証要件、サービスエンドポイントをアドバタイズすることで、検出とマルチエージェントの調整を可能にします。AgentCard は、直接レスポンス構成を介して静的にプロビジョニングすることも、xDS API または ext_proc API を介して一元化されたエージェントレジストリサーバーから取得することもできます。A2A の実装とエージェントの検出の詳細は、今後のブログ投稿で公開する予定です。

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

Envoy は、要求の厳しいデプロイで MCP プロトコルのポリシー適用が可能になった基盤と同じ基盤を基に、OpenAI と、エージェントプロトコルの RESTful HTTP API へのコード変換のサポートを追加しています。このコード変換機能により、生成 AI エージェントと既存の RESTful アプリケーションの統合が簡素化されます。また、OpenAPI ベースのアプリケーションがすぐにサポートされ、動的モジュールまたは Wasm 拡張機能を通じてカスタムオプションを利用できます。Envoy は、コード変換に加えて、割り当て管理などの高度なポリシー適用、生成 AI システムの OpenTelemetry セマンティック規則に準拠した包括的なテレメトリー、安全なエージェント運用を実現する統合ガードレールなど、本番環境への対応に不可欠な領域で強化されています。

安全なエージェントのためのガードレール

投資対象となる次の重要な分野は、すべてのエージェントトラフィックのガードレールの一元管理と適用です。現在、ポリシー適用ポイントを外部のガードレールと統合するには、特注の実装が必要ですが、この問題領域は標準化の機が熟しています。

コントロールプレーンがこれを運用可能にする

ゲートウェイは、ソリューション全体の一部にすぎません。このポリシー管理とロールアウトを大規模に実現するにあたり、xDS プロトコル（ユニバーサルデータプレーン API とも呼ばれる）を使用してデータプレーンを動的に構成するために別のコントロールプレーンが必要になります。

そこで重要になるのがコントロールプレーンです。Cloud Service Mesh は、Envoy AI Gateway や kube-agentic-networking などのオープンソースプロジェクトとともに、Envoy をデータプレーンとして使用しながら、オペレーターがエージェントワークロードのポリシーをより高いレベルで定義、管理できるようにします。

この組み合わせは強力です。Envoy はトラフィックパスに適用機能と拡張性を提供し、コントロールプレーンはチームがその機能を一貫してデプロイするために必要な運用モデルを提供します。

このソリューションが重要な理由

エージェントシステムや生成 AI プロトコル（MCP、A2A、OpenAI など）への移行に伴い、ネットワーク仲介役の進化が求められています。Envoy が主に対応する複雑な課題は次のとおりです。

プロトコルの詳細な検査。プロトコルデフレーミング拡張機能は、HTTP リクエストの本文からポリシーに関連する属性（ツール名、モデル名、リソースパス）を抽出し、従来のプロキシでは不透明なバイトストリームしか確認できなかった状況で正確なポリシー適用を可能にします。
きめ細かいポリシーの適用。これらの内部属性を公開することで、RBAC や ext_authz などの既存の Envoy 拡張機能は、プロトコル固有の基準に基づいてポリシーを評価できます。これにより、ネットワークオペレーターは、統一されたゼロトラストのセキュリティポスチャーを適用し、エージェントが特定のツールやリソースのアクセスポリシーに準拠するようにできます。
ステートフルなトランスポート管理。Envoy は、MCP で使用される Streamable HTTP トランスポートのセッション状態の管理をサポートしており、仲介役のフリート全体でも、パススルーゲートウェイモードと集約ゲートウェイモードの両方で堅牢なデプロイを可能にします。

エージェント型 AI プロトコルはまだ初期段階にあり、プロトコルの状況は今後も進化し続けます。まさにそのために、ネットワーキングレイヤには適応性が必要なのです。新しいエージェントフレームワーク、トランスポートパターン、ツールプロトコルが普及するたびに、企業がセキュリティとトラフィックのインフラストラクチャを再構築する必要はありません。制御を犠牲にすることなく変化を吸収できる基盤が必要です。

Envoy は、本番環境での実証済みの成熟度、高度な拡張性、エージェントワークロードのプロトコル認識の向上という、一度に持ち合わせることが難しい 3 つの特性を兼ね備えています。Envoy をエージェントゲートウェイとして活用することで、組織はセキュリティとポリシーの適用をエージェント開発コードから切り離すことができます。

これにより、Envoy は AI トラフィックを処理するプロキシ以上の存在になり、エージェント型 AI ネットワーキングの未来を見据えた基盤となります。

^{このブログ記事の共同執筆者である、Google のソフトウェアエンジニア Boteng Yao、Google のソフトウェアエンジニア Tianyu Xia、Google のシニアプロダクトマネージャー Sisira Narayana に感謝します。}

- Google、スタッフソフトウェアエンジニア、Yan Avlasov

- Tetrate、プロダクトおよびプロダクトマーケティングマネージャー、Erica Hughberg 氏

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

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

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

- シニアスタッフソフトウェアエンジニア、Andres Guedez

AI ネイティブなコア: Google Kubernetes Engine を使用した、レジリエンスの高い通信事業者向けアーキテクチャ

Mon, 16 Mar 2026 03:00:00 +0000

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

通信業界は重要な転換点を迎えています。従来のオンプレミス中心のデータセンターモデルは、インフラストラクチャ費用の高騰と、可用性およびコンプライアンス要件による利用率の低さという重圧に苦しんでいます。しかし、AI の時代には、指数関数的なスケールと 99.9999999% を超える信頼性が求められます。通信事業者が考えるべきは、モダナイズするかどうかではなく、どのアーキテクチャパスが最も迅速にモダナイズできるかです。

モダナイゼーションは「完全な置き換え」のイベントではなく、戦略的な選択です。今回は、Google Kubernetes Engine（GKE）が、クラウド中心の進化と戦略的なハイブリッドモダナイゼーションという 2 つの汎用性の高いデプロイ戦略の高性能な基盤としてどのように機能するかをご紹介します。

ネットワークモダナイゼーションの 2 つの方法

すべての通信事業者は、リスク許容度、規制環境、投資基盤がそれぞれ異なります。アジリティを優先する通信事業者もいれば、ローカルな制御の必要性を重視する通信事業者もいます。GKE を使用すれば、両方のアプローチに対応できます。

1. クラウド中心のモダナイゼーション: 大規模なアジリティ

この方法は、クラウドの弾力性を最大限に活用したい通信事業者向けです。独自のコンテナ化されたネットワーク機能（CNF）を移行する場合でも、Ericsson-on-Demand のようなクラウドネイティブサービスを構築する場合でも、目標は同じです。それは、重い処理を Google Cloud に移行することです。

メリット: 音声コアやポリシー制御機能などのミッションクリティカルなワークロードを Google のグローバルファイバーバックボーンで実行することで、ピーク時のイベントに合わせて即座にスケールし、「ゼロヒューマンタッチ」運用に移行できます。
経済性: 多額の初期投資を必要とする CapEx から「成長に応じた支払い」モデルに移行できます。アイドル状態のハードウェアを過剰にプロビジョニングする必要はなく、クラウドが突発的な負荷を吸収してくれます。
製品化までの時間: 固定無線アクセス、IoT、プライベート 5G などの新しいサービスの製品化までの時間を短縮できます。

2. 戦略的なハイブリッドモダナイゼーション: クラウドのアジリティ、ローカルな制御

多くの通信事業者にとって、ハイブリッドアプローチはより優れたバランスを提供します。ハイブリッドアプローチでは、通信事業者は、アジャイルなコントロールプレーンコンポーネントとデータ分析を選択的にクラウドに移行しながら、レイテンシの影響を受けやすいユーザープレーン機能をオンプレミスまたはエッジに保持できます。

メリット: データプレーントラフィックをローカルに保持することで、超低レイテンシの最適化と厳格なデータ主権要件を満たしつつ、クラウドの AI による分析情報とオーケストレーション機能を活用できます。
汎用性: GKE を使用すると、コントロールプレーンのワークロードをクラウドで実行し、データプレーンサービスを独自のデータセンターまたはネットワークエッジで直接実行できます。これにより、環境全体で統一された運用モデルを構築できます。

「通信事業者グレード」の基盤のエンジニアリング

このブログ投稿では、GKE が通信事業者や機器ベンダーパートナーからの大きな勢いに支えられ、コンテナ化されたネットワーク機能（CNF）向けの業界で最も特化したプラットフォームへと進化してきた様子をご紹介します。

さまざまな機能のおかげで、これを実現しています。

接続と分離

標準の Kubernetes は、通信事業者が必要とする複雑なトラフィック分離を想定して設計されていません。GKE は、次の機能でこのギャップを埋めます。

マルチネットワーキング API: Pod ごとに複数のインターフェースを管理するネイティブの Kubernetes の手法。標準のネットワークポリシーをすべてのインターフェースに適用します。
シミュレートされた L2 ネットワーキング: 最新のクラウドネイティブなスタックで実行しながら、従来のアプリケーションがレイヤ 2 の運用モデルを維持できる「移行のスーパーパワー」。
通信事業者向け CNI: 特化型 Ubuntu イメージで Multus、IPvlan、Whereabouts をサポート。これにより、管理プレーン、制御プレーン、ユーザープレーンを外科手術のように正確に分離できます。

永続的なネットワーク到達性

エフェメラルなコンテナの世界では、通信事業者の機能には安定性が求められます。GKE は、以下を通じてこれを実現します。

GKE IP ルート: 等価コストマルチパス（ECMP）のような機能を GKE データプレーンに直接統合しました。ワークロードに障害が発生すると、サービスパスから自動的かつ迅速に削除されるため、複雑な外部ルーター構成なしで高可用性を実現できます。
永続 IP: GKE は、5G コア機能がライフサイクル全体で一貫したネットワーク到達性を確保するために必要な静的 IP サポートを提供します。標準の Kubernetes では利用できない NAT を使用しません。

1 秒未満の収束

通信事業者にとって、ミリ秒単位のダウンタイムは接続の喪失を意味します。HA ポリシーを介した GKE のデータプレーンは、超高速の障害検出と収束により、ほぼゼロのダウンタイムを実現するように最適化されています。通信事業者は、自己管理による復旧と Google による完全管理の障害検出のどちらかを選択できます。

AI で「節約」から「解決」へ

通信事業者にとって、モダナイゼーションの最終的な目標は、自律型ネットワークへの移行です。Vertex AI や BigQuery などの Google Cloud AI およびデータプラットフォームに隣接するプラットフォームでコアネットワーク機能を実行することで、テレメトリーをネットワーク最適化の実用的な変更に変えることができます。モダナイゼーションによって実現するユースケースとメリットには、次のようなものがあります。

予測 AIOps: AI を使用してパフォーマンスの低下を特定し、通話が切断される前に自動修復をトリガーします。スポーツイベントやサービスのリリース時に、クラウドを使用してオンデマンドのバースト容量を確保します。また、GKE でホストされる 5G コアのデータを使用して、AI を活用した自動化を促進し、問題が加入者に影響を与える前に予測します。
インテント主導のプログラマビリティ: 費用のかかる事後対応型の運用から移行し、新しいデプロイのセットアップ時間を数週間から数時間に短縮します。
分析情報の収益化: クラウドネイティブなデータに AI を活用して、ネットワークの適正化に加えて、まったく新しい収益機会を特定して獲得します。

貴社の戦略に合わせた変革を

通信業界の未来は、インテリジェントでレジリエンスに優れ、非常に柔軟なものになるでしょう。ハイブリッドデプロイへの第一歩を踏み出す場合でも、クラウドで完全にホストされるコアを立ち上げる場合でも、Google Cloud は貴社の戦略的パートナーとなります。

MWC にぜひご参加ください。ホール 2 のブース #2H40 では、GKE で動作するモバイルコアのライブデモなど、各種ソリューションの事例をご覧いただけます。

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

- Google Cloud、ソフトウェアエンジニア、Maciej Skrocki

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

Fri, 13 Mar 2026 03:00:00 +0000

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

Google Cloud は柔軟性に優れており、企業が AI ワークロード向けに安全で信頼性の高いアーキテクチャを構築することを可能にします。この投稿では、検索拡張生成（RAG）対応生成 AI アプリケーションのプライベート接続のリファレンスアーキテクチャについて説明します。このアーキテクチャは、システム全体で通信にプライベート IP アドレスを使用する必要があるようなシナリオで、通信がインターネットを通過してはならないような場合に適しています。

RAG の効力

RAG は、大規模言語モデル（LLM）の出力を最適化するために使用されるパワフルな手法であり、LLM の出力を、元のトレーニングデータ以外の特定の信頼できるナレッジベースにグラウンディングできます。アプリケーションから RAG を使って、ドキュメント、データソース、データベースから関連情報をリアルタイムで取得することができます。ここで取得したコンテキストは、ユーザーのクエリとともにモデルに提供されます。これにより、AI の回答を正確で検証可能なものにするとともに、業務内容との関連性を高めます。この仕組みによって、回答の質が向上し、ハルシネーションが減少します。

このアプローチは、生成 AI においてモデルの既存の知識のみに依存することなく、指定された信頼できる情報源を使用できるため、モデル自体を再トレーニングやファインチューニングしなくて済むという点で利便性に優れています。

設計パターンの例

RAG アプリケーションのプライベート接続向けにネットワークを設定するということを念頭におきながら、このようなリージョン設計のパターンを見ていきましょう。

このネットワークは、外部ネットワーク（オンプレミスおよび他のクラウド）と Google Cloud 環境で構成されています。Google Cloud 環境は、ルーティングプロジェクト、RAG 用の共有 VPC ホストプロジェクト、3 つの特化したサービスプロジェクト（データ取り込み、サービング、フロントエンド）で構成されています。

この設計では、次のサービスを使用してエンドツーエンドのソリューションを提供します。

Cloud Interconnect または Cloud VPN: オンプレミスまたは他のクラウドからルーティング VPC ネットワークに安全に接続する
Network Connectivity Center: VPC スポークおよびハイブリッドスポークを介して、ルーティング VPC ネットワークと RAG VPC ネットワーク間の接続を管理するオーケストレーションフレームワーク
Cloud Router: ルーティングプロジェクト内で、外部ネットワークと Google Cloud 間の動的な BGP ルート交換を行う
Private Service Connect: ルーティング VPC ネットワークにプライベートエンドポイントを提供し、パブリックインターネットを経由せずに Cloud Storage バケットにアクセスしてデータを取り込めるようにする
共有 VPC: 複数のサービスプロジェクトで、共通の一元的な VPC ネットワークを使用できるようにするホストプロジェクトアーキテクチャ
Google Cloud Armor とアプリケーション ロードバランサ: フロントエンドサービスプロジェクトに配置され、ユーザーインタラクションに対してセキュリティとトラフィック管理を提供する
VPC Service Controls: すべてのリソースの周囲にマネージドセキュリティ境界を作成し、データ漏洩のリスクを軽減する

トラフィックフロー

RAG の挿入フロー

上の図の緑色の点線が RAG の挿入フロー（データエンジニアからベクトルストレージへとデータが移動する仕組み）を表しています。

外部ネットワークからのデータが、Cloud Interconnect または Cloud VPN 経由で渡されます。
ルーティングプロジェクト内の Private Service Connect エンドポイントを使って Cloud Storage バケットにアクセスします。
データ取り込みサービスプロジェクト内のデータ取り込みサブシステムが Cloud Storage バケットからの元データを処理します。
AI モデルがチャンクからベクトルを作成し、データ取り込みサブシステムに返します。データ取り込みサブシステムはこれを受け、サービングサービスプロジェクトの RAG データストアに書き込みます。

推論フロー

上の図のオレンジ色の点線が推論フロー（お客様またはユーザーのリクエスト）を表しています。

リクエストは、Cloud Interconnect または Cloud VPN 経由でルーティング VPC ネットワークに渡され、その後、VPC スポーク経由で RAG VPC ネットワークに渡されます。
リクエストは、Cloud Armor で保護されたアプリケーションロードバランサ に到達し、許可されるとフロントエンドサブシステムに渡されます。
フロントエンドサブシステムはリクエストをサービングサブシステムに転送します。サービングサブシステムは、RAG データストアのデータでプロンプトを拡張し、AI モデルを介して回答を生成します。
上記によってグラウンディングされた回答が、リクエスト元に同じパスで返されます。

管理とルーティング

上の図の青い点線は、Network Connectivity Center のハイブリッドスポークと VPC スポークが、ルーティングネットワークと RAG VPC ネットワーク間のコントロールプレーンとルートオーケストレーションを管理する様子を表しています。これにより、外部ネットワークから学習したルートが環境全体に適切に伝播されます。

IAM 権限、VPC Service Controls、デプロイに関する考慮事項などについて詳しくは、アーキテクチャドキュメント「RAG 対応生成 AI アプリケーションのプライベート接続」をお読みください。

次のステップ

クロスクラウドネットワークの詳細や、RAG を使用した生成 AI に関する以下のガイドをご覧ください。

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

Firefly: データセンターでナノ秒レベルのクロック同期を実現するソリューション

Thu, 05 Mar 2026 01:00:00 +0000

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

イベントをナノ秒単位の精度で同期する機能は、ウォール街の高頻度取引フロアからクラウドデータセンターのオーケストレーションまで、さまざまな場面で不可欠です。しかし、最新のデータセンターの相互接続された数千台のデバイス全体でこのレベルの時刻精度を実現するには、クロックドリフト、ネットワークジッター、パスの非対称性などの多数の課題に対処しなければなりません。従来、クラウドホスト型のインフラストラクチャでは高レベルの時刻精度を実現することは不可能であったため、特定のクラスのアプリケーションを実行できませんでした。

そこで登場したのが、Google の研究者とエンジニアが開発したクロック同期システム「Firefly」です。Firefly は単なるクロック同期プロトコルではありません。理論的な分析情報と実用的なエンジニアリングを組み合わせ、要求の厳しいデータセンター環境内のコモディティハードウェアで、超高精度かつスケーラブルな、費用対効果の高い時刻同期を実現するソフトウェア主導のアプローチです。

ナノ秒単位の競争: 正確なタイミングが重要である理由

正確なクロック同期は、分散システムの基盤です。金融取引所では、規制要件により協定世界時（UTC）への 100 マイクロ秒未満の外部同期が義務付けられており、公平性を確保するために 10 ナノ秒未満の内部クロック同期が求められているため、妥協は許されません。高頻度取引では、タイミングがわずかに優位であるだけで大きな利益につながる可能性があるため、正確なタイムスタンプは市場の健全性を保つために不可欠です。金融以外の分野でも、データベースの整合性、分散ロギング、仮想マシンの管理、ネットワークテレメトリーなど、多くのデータセンター運用で、イベントを正確な時間順に並べることが重要になっています。データセンターの拡大に応じて、堅牢かつスケーラブルな同期ソリューションの必要性がさらに高まっています。

しかし、動的なデータセンター環境でナノ秒レベルの同期を実現するには困難が伴います。次のようないくつかの要因によって、精度が損なわれます。

クロックドリフト: すべてのクロックの基本となる水晶発振器には、時間の経過に応じて徐々にずれが生じるという特有の欠陥があります。従来は、こうしたずれの影響は小さいと考えられていましたが、10 ナノ秒未満を目指す場合は大きな問題となります。
ジッター: スイッチやネットワークインターフェースカード（NIC）などのネットワークコンポーネントによって、予測不可能な遅延が発生します。ネットワークバッファでのキューイングやパケットの複雑な処理に起因することが多いこれらの遅延は、ジッターとして顕在化し、同期メッセージのタイミングを乱します。
非対称性: 2 台のデバイス間のネットワークパスが対称であることはほとんどありません。ケーブルの長さ、ホップ数、ネットワーク機器の内部動作の違いにより、信号が反対方向に伝わるまでにかかる時間が異なる場合があります。この非対称性が原因で、一方向の遅延とクロックオフセットを推定する際に大きなエラーが生じる可能性があります。
スケーラビリティ: データセンターが数万台のサーバーを収容するほどに拡大した場合、同期ソリューションも、ボトルネックになったり、不釣り合いなリソースを必要としたりすることなく、状況に応じて効率的に拡張できなければなりません。
フォールトトレランス: 分散システムでは、障害は避けられません。全体的な同期の精度が損なわれないよう、同期プロトコルには、個々のノードやネットワークリンクの損失または誤動作に対する復元力が必要です。

Firefly: ソフトウェアと理論の橋渡し

多面的な戦略を使用してこれらの課題に対処する Firefly は、従来の同期プロトコルとは一線を画しています。その主なイノベーションは、アーキテクチャ設計と理論的基盤に見出されます。

1. レイヤー型同期: Firefly は、レイヤー型同期という新技術を採用しています。単一障害点になる可能性や遅延を引き起こす可能性のある中央クロックに依存するのではなく、まずデータセンター内の NIC 間で緊密な内部同期を確立します。ネットワーク内の各 NIC は、常に一連のピアと通信し、時刻を比較して調整します。このデバイスの「群れ」から、グループ全体が合意する、非常に安定した正確なコンセンサスタイムが明らかになります。この内部同期は高速かつ堅牢であるため、外部のタイミングの乱れから効果的に保護されます。同時に、Firefly は「群れ」全体を UTC に同期します。これらの 2 つのプロセスを分離することは非常に重要です。なぜなら、タイムサーバーのジッターやドリフトなどの外部要因が内部同期に直接影響しないようにできるからです。

2. ランダムグラフ上の分散コンセンサス: 脆弱で単一障害点の影響を受けやすい従来の階層型アプローチとは異なり、Firefly は d 正則ランダムグラフ上に構築された分散コンセンサスアルゴリズムを使用します。つまり、各 NIC はランダムに選択された「d」個のピアと通信します。Firefly の研究論文に掲載されている理論分析から、このようなランダムグラフには次のような大きな利点があることが判明しています。

合致の高速化: ランダムグラフを使用することで、ネットワーク全体でのクロック情報のより迅速な伝播を促進し、より高速な同期につなげることができます。
スケーラビリティ: 理論上の限界では、ピアの数（「d」）がノードの総数に対して対数的にスケールする場合、ネットワークのサイズが大きくなってもランダムグラフは同期精度を維持できることが示されています。
非対称性に対する復元力: ランダムグラフに固有の多様なプローブパスにより、パスの非対称性の影響を平均化して軽減できます。

3. ジッターと非対称性を実際に軽減: ランダムグラフの理論上の利点に加えて、Firefly には精度をさらに高めるための実用的な手法が組み込まれています。

RTT フィルタリング: Firefly は、ラウンドトリップ時間（RTT）の測定値を分析することで、キューイングジッターの影響を受けている可能性が高いプローブサンプルを特定して破棄し、遅延推定の精度を向上させます。
パスプロファイリング: Firefly はネットワークパスを積極的にプローブし、非対称性が最小限のパスを特定して優先します。このプロアクティブなアプローチにより、同期に関して最も信頼性の高いパスを選択できます。
ハードウェアの活用: 利用可能な場合、Firefly はネットワークスイッチのトランスペアレントクロック（TC）などの機能を利用して、スイッチ内の遅延を正確に把握し、測定エラーをさらに低減します。

4. 堅牢性とフォールトトレランス: Firefly は分散コンセンサスを平均化メカニズムと組み合わせて使用するため、障害に対する本質的な復元力を備えています。単一のタイムサーバーや固定の階層構造に依存しないことで、個々のノードの損失または誤動作に適切に対処できます。

実環境でのパフォーマンス

Firefly の研究論文に掲載されている結果には説得力があります。

内部同期: Firefly は、Google の最新のデータセンターファブリック技術と組み合わせて使用すると、NIC 間で常に 10 ナノ秒未満の同期を実現します。これを使用して、マシン間のパケット、ログ、リモートプロシージャコール（RPC）などのイベントの順序を決定できます。
外部同期: また、金融取引所の規制要件である 100 マイクロ秒よりもはるかに優れた UTC への同期も可能です。

Firefly 同期ネットワークで 6 ホップ離れた 2 つのクロック間のオフセットを、オシロスコープで 1 秒あたり 1 パルスで測定。

次の動画は、1 秒あたり 1 パルス（1 PPS）で NIC から出力される信号を利用してオシロスコープで定量化された、NIC 間同期の精度を示しています。各行は NIC クロックに対応しており、立ち上がりエッジは NIC クロックが整数の秒数に達した瞬間を示しています。オシロスコープの観測では、測定されたすべての NIC がほぼ同期しており、数ナノ秒以内で合致していることがわかります。

Firefly はコモディティハードウェア上のソフトウェアのみで動作し、高価な専用の同期機器を必要としないことを考慮すると、この結果は特に素晴らしいものです。これにより、幅広いデータセンターアプリケーションが超高精度の時刻同期に対応できるようになります。

未来の可能性の基盤

スケーラブルかつ費用対効果の高い方法でナノ秒レベルの精度を実現した Firefly の成功は、広範囲に影響をもたらします。

高精度のタイミングの民主化: Firefly を使用すると、従来は高価な専用ハードウェアに依存していたクラウドホスト型の金融サービスで、標準的なクラウドインフラストラクチャを使用して必要な精度を実現できるようになります。
新たな用途への対応: データセンターのデバイス全体で同期された正確なクロックを利用できるようになると、きめ細かいネットワークテレメトリーと輻輳制御、時間調整された分散システム、ML ワークロードの確定的ファブリックなどの分野に新たな可能性がもたらされます。
データセンターの運用の変革: Firefly は、緊密に統合された正確なタイミングのコンピューティングエンティティを作成することで、データセンターの全体的な効率、信頼性、パフォーマンスを向上させることができます。

つまり、Firefly はクロック同期の分野における大きな進歩であると言えます。グラフ理論とコンセンサスアルゴリズムに関する理論的な分析情報と、実用的なネットワークエンジニアリング手法を巧みに組み合わせることで、複雑な分散環境でナノ秒レベルの精度を実現するという長年の課題を克服しています。データセンターが進化し続ける中、Firefly のようなシステムは、高性能で信頼性が高く公平な未来のインフラストラクチャを構築するうえで重要な役割を果たすでしょう。

- Google、プロダクトマネージャー、Rohit Dalal

- ソフトウェアエンジニア、Yuliang Li

Google Distributed Cloud、エアギャップ環境でパブリッククラウドのようなネットワーキングを実現

Wed, 18 Feb 2026 03:00:00 +0000

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

規制の厳しい業界の組織では、エアギャップ環境の厳格なセキュリティと、クラウドが持つアジリティや柔軟性に対するニーズとのバランスを取ることに苦労することが少なくありません。これに対処するため、Google Distributed Cloud（GDC）エアギャップ 1.15 では、セキュリティポスチャーを損なうことなくより直接的な制御と可視性を実現する、新しいネットワーキング機能がプレビュー版で導入されました。また、サブネット管理を簡素化する新しい IPAM 機能も一般提供されました。今回プレビュー版で提供される機能は、Cloud NAT、標準クラスタの接続性の強化、ロードバランサでの高度な HTTP および HTTPS ヘルスチェックです。これらを組み合わせて使うことで、複雑なワークロードを安全な環境で簡単に管理できます。

Cloud NAT でアウトバウンドトラフィックを管理する

GDC エアギャップ用の Cloud NAT は、以前の外向きソリューションに代わるもので、インスタンスと他のネットワークとの通信を、パブリッククラウドの機能と同等に制御できます。Cloud NAT には、以下のような利点があります。

構成可能な外向き IP: 外向きトラフィックに複数の外向き IP アドレスを割り当てて管理できるため、通信しているワークロードを正確に特定できます。
カスタマイズ可能なタイムアウト: さまざまな種類のトラフィックのタイムアウトを調整して、接続のライフサイクルを管理できます。
きめ細かな制御: 管理者は、外向き IP 用に特定のサブネットを作成できます。一方、アプリケーションオペレーターは、Pod と VM によるトラフィックのルーティング方法を定義できます。

標準クラスタを組織に直接接続する

安全な環境で、分離によりサイロが分断されることがあってはなりません。最新リリースでは、標準クラスタのネットワーキング機能が更新され、セキュリティ境界を厳格に維持しながら組織全体で通信することが可能となり、環境をより効率的に管理できるようになりました。主な更新内容は以下のとおりです。

Pod の直接通信: 標準クラスタの Pod が、組織のデフォルト VPC 内のワークロードと直接通信できるようになりました。これにより、標準クラスタと共有クラスタの接続が簡素化されます。
柔軟なファイアウォールポリシー: Project Network Policy API と Kubernetes Network Policy API を使用して、Pod やノードを出入りするトラフィックに詳細なルールを設定できます。
マネージドロードバランシング: 標準の Kubernetes Service API を使用して内部ロードバランサと外部ロードバランサを作成できます。一方、基盤となる構成は GDC で管理します。

標準クラスタ内の Pod は、直接または ClusterIP を介して他の Pod に接続できるようになりました。インフラ VPC へのトラフィックは引き続きブロックされますが、共有クラスタワークロードには GDC 内部ロードバランサを介してトラフィックを送信できます。これにより、アプリケーションは必要なサービスに迅速にアクセスできるようになります。

ロードバランサの HTTP および HTTPS ヘルスチェックで信頼性を向上させる

これまでの L4 ロードバランシングのヘルスチェックでは、基本的な TCP 接続のみをモニタリングし、ポートが開いているかどうかのみを確認していました。このたび、GDC エアギャップのロードバランサが HTTP および HTTPS ヘルスチェックに対応したため、アプリケーションが実際に正しく機能しているかどうかを確認できるようになりました。ステータスコードと応答の内容を確認することで、以下のことが可能になります。

アプリケーションの健全性の確認: サーバーの電源が入っていることだけでなく、サービスが正しく応答していることを確認します。
信頼性の向上: 内部エラーが発生しているアプリケーションのトラフィックを自動的に検出して別経路にルーティングします。
可視性の向上: VM ベースのワークロードの健全性に関する、より有益なデータにアクセスし、問題が発生する前にパフォーマンスを管理します。

サブネットグループを使用してサブネット管理を容易にする

従来、子サブネットは 1 つの親サブネットしか参照できませんでした。サブネットグループの導入により、子サブネットは複数の親サブネットを含むサブネットグループを参照できるようになりました。この方法には、以下のような利点があります。

変更できないサブネット CIDR の課題を克服: サブネット CIDR の範囲は変更できませんが、サブネットグループを使用すると、新しいサブネットをサブネットグループに加えることで、IP リソースのスケールアップを簡素化できます。単一の親サブネットではなくサブネットグループを参照すると、簡単にスケールアップできます。
親サブネットを自動的に特定: サブネットグループを、単一のサブネットとしてではなく、親として参照できるようになりました。サブネットグループをこのように使用すると、利用可能な IP リソースを持つ親サブネットを手動で特定する必要がなくなります。その代わりに、利用可能な IP スペースが十分にあるサブネットグループ内のサブネットが、GDC IPAM により親として自動的に検出されます。
より小さな CIDR から始めて計画をより容易に: サブネットグループを使用して IP リソースをスケールするということは、新しい親サブネットを作成する際、より小規模で不連続な CIDR から始められるということでもあります。これにより、IP リソースをより効率的に使用できるようになり、計画プロセスがより容易になります。

使ってみる

これらの機能の詳細については、ドキュメントを参照するか、Google Cloud のアカウント担当者にお問い合わせください。

- プロダクトマネージャー、Michael Yitayew

- プロダクトマネージャー、Philip Bai

Model Context Protocol の gRPC トランスポート

Mon, 19 Jan 2026 03:00:00 +0000

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

AI エージェントはテスト環境から企業業務の中核へと移行していて、複雑なマルチステップの目標を達成するには、外部のツールやシステムと確実にやり取りする必要があります。Model Context Protocol（MCP）は、こうしたエージェントとツールの間の通信を可能にする標準プロトコルです。実際、Google は先月、フルマネージドのリモート MCP サーバーのリリースを発表しました。デベロッパーは、Gemini CLI などの AI エージェントや標準の MCP クライアントを、Google サービスと Google Cloud サービスのグローバルな整合性を備えたエンタープライズ対応エンドポイントに、簡単に接続できるようになりました。

MCP は標準トランスポートとして JSON-RPC を使用しています。これは、行動指向のアプローチと、エージェントが基盤モデルとのコミュニケーションで直接伝達できる自然言語ペイロードを兼ね備えているため、多くのメリットをもたらします。しかし、多くの組織がリモートプロシージャコール（RPC）モデルの高性能なオープンソース実装である gRPC を利用しています。gRPC フレームワークを採用している企業は、MCP で使用される JSON-RPC トランスポートに合わせて自社ツールを調整する必要があります。現在、これらの企業は、JSON-RPC MCP リクエストと既存の gRPC ベースのサービスの間で変換を行うために、コード変換ゲートウェイをデプロイする必要があります。

MCP コード変換の興味深い代替手段として、MCP のネイティブトランスポートとして gRPC を使用する方法があります。多くの gRPC ユーザーが、独自のカスタム MCP サーバーを実装して、この方法を積極的に試しています。Google Cloud は、サービスを有効にしてグローバル規模で API を提供するために gRPC を幅広く使用しており、こうした広範な利用から得られた技術と専門知識の共有に尽力しています。具体的には、本番環境で MCP を導入している gRPC 実務担当者にサポートを提供したり、MCP コミュニティと積極的に協力して、MCP のトランスポートとして gRPC を利用する手段を模索したりしています。MCP の主なメンテナーは、MCP SDK でプラグ可能なトランスポートをサポートすることに合意しており、Google Cloud は、MCP SDK にプラグインできる gRPC トランスポートパッケージを近い将来提供する予定です。コミュニティがサポートするトランスポートパッケージにより、gRPC 実務担当者は、一貫性があり相互運用可能な方法で、gRPC を使用して MCP をデプロイできるようになります。

トランスポートとして gRPC をネイティブに使用すると、コード変換の必要性がなくなり、gRPC を積極的に使用している環境の運用で整合性を維持できます。この投稿の残りの部分では、MCP のネイティブトランスポートとして gRPC を使用するメリットと、Google Cloud がこの移行をどのようにサポートしているかについて説明します。

RPC トランスポートの選択

サービスに gRPC をすでに使用している組織は、gRPC がネイティブにサポートされることで、サービスの変更や、コード変換プロキシの実装をすることなく、既存のツールを引き続き使用して MCP 経由でサービスにアクセスできるようになります。これらの組織は、エージェントがサービスにアクセスする手段として MCP が使用されるようになっても、gRPC のメリットを維持できるように取り組んでいます。

「gRPC はバックエンドの標準プロトコルであるため、社内で gRPC を使用した MCP の試験的なサポートに投資してきました。すでにメリットを実感しています。それは、開発者が使い慣れているため扱いやすいという点や、構造と静的に型付けされた API を使用することで MCP サーバー構築に必要な作業を減らせるという点です。」 - Spotify、シニアスタッフエンジニア兼デベロッパーエクスペリエンス担当テクニカルリード Stefan Särne 氏

gRPC のメリット

ネイティブトランスポートとして gRPC を使用すると、MCP が gRPC ベースの最新分散システムのベストプラクティスに準拠できるようになるため、パフォーマンス、セキュリティ、運用、デベロッパーの生産性が高まります。

パフォーマンスと効率

gRPC のパフォーマンス面でのメリットは、次の特性により効率を大幅に向上させます。

バイナリエンコード（プロトコルバッファ）: gRPC はバイナリエンコードにプロトコルバッファ（Protobuf）を使用しているため、JSON と比較してメッセージサイズを最大 10 分の 1 に縮小できます。つまり、帯域幅の消費が削減され、シリアル化 / シリアル化解除がより高速になります。これにより、ツール呼び出しのレイテンシの短縮、ネットワーク費用の削減、リソースフットプリントの大幅な縮小が実現します。
全二重双方向ストリーミング: gRPC は、クライアント（エージェント）とサーバー（ツール）が、単一の永続的な接続を通して、連続したデータストリームを同時に相互送信することをネイティブにサポートしています。この機能は、エージェントとツールのやり取りを大きく変えるものであり、アプリケーションレベルの接続同期を必要とせずに、真にインタラクティブなリアルタイムのエージェントワークフローを実現できるようになります。
組み込みのフロー制御（バックプレッシャー）: gRPC にはネイティブなフロー制御が含まれているため、送信速度の速いツールがエージェントを圧倒するのを防止できます。

エンタープライズクラスのセキュリティと認証

gRPC ではセキュリティが最重要事項とされているため、エンタープライズクラスの機能がコアに直接組み込まれています。これには以下が含まれます。

相互 TLS（mTLS）: ゼロトラストアーキテクチャに不可欠な mTLS は、クライアントと gRPC を利用したサーバーの両方を認証することで、なりすましを防止し、信頼できるサービスのみが通信できるようにします。
厳格な認証: gRPC は、業界標準のトークンベースの認証（JWT / OAuth）と統合するためのネイティブフックを提供し、すべての AI エージェントに検証可能な ID を提供します。
メソッドレベルの認可: 特定の RPC メソッドまたは MCP ツールに認可ポリシーを直接適用できるため（例: エージェントは ReadFile が認可されるが、DeleteFile は認可されない）、最小権限の原則を厳格に遵守し、「過剰なエージェンシー」に対処できます。

運用の成熟度とデベロッパーの生産性

gRPC は、拡張性と再利用性を通じて、復元力に関する措置の負担を軽減し、デベロッパーの生産性を向上させる、強力な統合ソリューションを提供します。主な機能は次のとおりです。

統合されたオブザーバビリティ: 分散トレース（OpenTelemetry）と構造化されたエラーコードとのネイティブ統合により、すべてのツール呼び出しの完全かつ監査可能な証跡が提供されます。デベロッパーは、単一のユーザープロンプトを、その後に続くすべてのマイクロサービスインタラクションを通じてトレースできます。
堅牢な復元力: 期限、タイムアウト、自動フロー制御などの機能により、たった 1 つの応答しないツールがシステム全体に障害を引き起こすことを防止できます。これらの機能により、クライアントはツール呼び出しのポリシーを指定して、このポリシーを超過したらフレームワークが自動的にキャンセルされるようにすることで、障害の連鎖を回避できます。
多言語開発: gRPC では 11 以上の言語でコードが生成されるため、デベロッパーは厳密に型指定された一貫した取り決めを維持しつつ、作業に最適な言語で MCP サーバーを実装できます。
スキーマベースの入力検証: Protobuf の厳格な型指定により、シリアル化レイヤで不正な形式の入力を拒否することで、インジェクション攻撃が軽減され、開発タスクが簡素化されます。
エラー処理とメタデータ: フレームワークは、標準化された一連のエラーコード（例: UNAVAILABLE、PERMISSION_DENIED）を返して、クライアントが確実に処理できるようにします。また、クライアントは、主なリクエストの内容をシンプルに保ちながら、メタデータで Key-Value ペアとして帯域外情報を送受信できます（例: トレース ID）。

使ってみる

Agentic AI Foundation の初期メンバーであり、MCP 仕様の主要な貢献者である Google Cloud は、コミュニティの他のメンバーとともに、MCP SDK にプラグ可能なトランスポートインターフェースを含めることを提唱してきました。MCP のトランスポートとして gRPC を使用することにご関心がある場合は、ぜひ参加してお知らせください。

MCP トランスポートとして gRPC を有効化することにご関心をお持ちの場合は、Python MCP SDK のプラグ可能なトランスポートインターフェースのアクティブな pull リクエストに貢献してください。
AI のコミュニケーションの未来を形作るコミュニティに参加して、Model Context Protocol の発展にご協力ください。Contributor Communication - Model Context Protocol（貢献者によるコミュニケーション - Model Context Protocol）。
お問い合わせください。Google は、ユーザーの皆様の経験から学び、それぞれの取り組みをサポートしたいと考えています。

- ソリューションプロダクトマネージャー Victor Moreno

- シニアスタッフソフトウェアエンジニア Mark D. Roth

Hackensack Meridian Health は VPC Flow Logs を使用してネットワーク移行のリスクを軽減

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

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

ネットワーク管理者は、ネットワークトラフィックの可視化に VPC Flow Logs を多用しています。昨年、Google は VPC Flow Logs をアップデートして、ネットワークトラフィックの可視性を拡張し、サブネットだけでなく、VLAN アタッチメントと VPN トンネルも可視化できるようにしました。この機能強化により、オンプレミス環境とマルチクラウド環境全体で、ネットワークトラフィックを包括的にモニタリングできます。

VLAN アタッチメントに VPC Flow Logs を使用すると、Cloud Interconnect を経由するネットワークトラフィックの詳細なテレメトリーデータをエクスポートできます。このデータには、送信元と宛先の IP アドレス、ポート、プロトコル、転送されたバイト数 / パケット数、タイムスタンプ、その他の関連メタデータなどの重要な情報が含まれています。このようなログはネットワークトラフィックの分析、トラブルシューティング、キャパシティプランニング、コンプライアンスとセキュリティの確保など、さまざまなユースケースにおいて重要となります。この VPC フローログは Flow Analyzer を使用して簡単に分析でき、複雑な SQL クエリを記述することなく、ネットワークに関する貴重な分析情報を入手できます。

優れた機能であることはおわかりいただけたかと思いますので、次はその用途についてご説明します。Hackensack Meridian Health（HMH）は、ニュージャージー州最大の医療機関病院システムを擁する、大手の非営利医療機関です。病院、緊急医療センター、診療所の医療ネットワークである HMH にとって、システムの信頼性は非常に重要であり、基盤となる価値でもあります。このブログ投稿では、HMH が Google Cloud ネットワークを新しいアーキテクチャ設計に移行する前に、どのように VPC Flow Logs と Flow Analyzer を活用して Cloud Interconnect トラフィックを分析したかについて説明します。

それでは詳しく見ていきましょう。

移行準備に VPC Flow Logs を使用

昨年、HMH は重要な大規模ネットワークを新しい Google Cloud ネットワーク設計に移行する準備を行っていました。このような大規模な移行の前に、HMH はサンキーダイアグラムを使用して、最も重要なハイブリッドトラフィックパターンをしっかりと把握しておきたいと考えていました。この分析は、カットオーバー時にシステム停止を引き起こす可能性のある最大のリスクを正確に特定し、事前に対応策を策定する唯一の方法でした。

「相互接続のトラフィックはこれまでブラックボックスのようなものでした。VPC Flow Logs を有効にして Flow Analyzer にフィードすることにより、"何と何が通信しているか" がわかる、求めていたマップをようやく入手できるようになりました。ルートを変更する前に、このような重要なトラフィックフローを特定することが、移行全体のリスクを軽減するうえでの鍵でした。」- Hackensack Meridian Health、クラウドエンジニアリングマネージャー、Randall Brokaw 氏

必要なデータを収集するために、HMH はすべての VLAN アタッチメントで VPC Flow Logs を有効にし、Flow Analyzer を活用して内向きと外向きのデータを簡単に集計できるようにしました。内向きデータの分析には、次のクエリコンポーネントを使用しました。

Flow Analyzer クエリ

送信元

フィルタ: ゲートウェイの種類 = INTERCONNECT_ATTACHMENT
フロー整理の基準: ゲートウェイのロケーション、ゲートウェイ VPC ネットワーク

宛先

このように設定することにより、VPC フローログを Cloud Interconnect VLAN アタッチメント経由の内向きトラフィックに絞り込んだうえで、Google Cloud リージョンと VPC ネットワークごとに送信元トラフィック量を集計できます。

宛先データは Compute Engine インスタンスプロジェクトごとにグループ化されます。各アプリケーションは専用のサービスプロジェクトにデプロイされるため、宛先アプリケーションを簡単に特定できます。ただ、すべてのトラフィックが Compute Engine VM に送信されるわけではないため、Google サービスのタイプを含めることにより、Google API と Google がホストする VPC サービスへのトラフィックも把握できるようにしています。

お使いの環境でこの分析を実施する際の最適なフローパラメータと宛先のグループ化は、Google Cloud にアプリケーションをデプロイする方法によって異なります。たとえば、IP アドレス、ポート、VPC サブネット、GKE クラスタなど、VPC フローログのメタデータによって収集された使用可能なフィールドごとにグループ化できます。

このようなデータをもとに、HMH は VPC フローログのトラフィック量をサンキーダイアグラムに変換しました。変換するには、各トラフィックフローを {source, destination, weight} の 3 列からなる複数の行にフォーマット化する必要がありました。この分析の場合、重みは Flow Analyzer に表示されるトラフィック量で、送信元と宛先は次の順序でサンキーダイアグラムの各レイヤに対応しています。

データセンターから Google Cloud リージョン
Google Cloud リージョンから VPC ネットワーク
VPC ネットワークからアプリケーション

Flow Analyzer コンソールで [ログ分析のクエリを表示する] を選択すると、トラフィックフローを簡単に Google スプレッドシートにエクスポートして、ダイアグラムに正確に反映できます。そのうえで、HMH は Google Charts を使用してサンキーダイアグラムを作成しました。

code_block: <ListValue: [StructValue([('code', "var data = new google.visualization.DataTable();\r\n\r\ndata.addColumn('string', 'From');\r\ndata.addColumn('string', 'To');\r\ndata.addColumn('number', 'Weight');\r\ndata.addRows([\r\n [ 'On Premises', 'us-central1', 28 ],\r\n [ 'On Premises', 'us-east1', 7 ],\r\n [ 'us-east1', 'Prod Network', 2 ],\r\n [ 'us-east1', 'Shared Network', 9 ],\r\n [ 'us-central1', 'Prod Network', 4 ],\r\n ...\r\n]);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be6d6b490>)])]>

Google Charts のサンキーダイアグラム - Cloud Interconnect トラフィックの分析

HMH のネットワークエンジニアは VPC Flow Logs を使用することにより、移行計画において重要となるカットオーバーのタイミングを特定でき、プロアクティブなモニタリングと準備を通じて移行のリスクを軽減できました。この準備を行ったことにより、移行の問題が 3 分で検出され、わずか 5 分で解消されました。これまでであれば数時間かかっていた可能性がある問題解決プロセスの時間が大幅に短縮しました。この準備こそが移行の成功の基盤となりました。

この実装では Flow Analyzer を使用しており、Flow Analyzer では VPC フローログを Cloud Logging に保存する必要があります。Cloud Logging に保存せずに、VPC フローログを BigQuery に直接転送することもできます。その場合は、Looker などの可視化サービスを利用して、カスタムのダッシュボードを構築し、価値ある分析情報を取得します。

成功へと導く VPC Flow Logs と Flow Analyzer

HMH は VPC Flow Logs と Flow Analyzer を使用して、スムーズにネットワークの移行ができるようにしました。同時に、Cloud Interconnect のトラフィックを細かく可視化できる VPC Flow Logs は、キャパシティプランニングやコストのアトリビューションなど、他のさまざまなユースケースにも対応できます。今すぐ VLAN アタッチメントで VPC Flow Logs を有効にし、Flow Analyzer を利用してトラフィックフローのパターンに関する分析情報を入手しましょう。

詳細については、VPC Flow Logs のドキュメントをご覧ください。または、Flow Analyzer を使用して、追加費用なしでログを分析してみてください。

- GCC ネットワークスペシャリスト Adam Cole

- プロダクトマネージャー Neha Chhabra

VPC フローログと Flow Analyzer でクロスクラウドネットワークトラフィックの分析情報を取得

Fri, 12 Dec 2025 03:00:00 +0000

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

ネットワークトラフィックを可視化することは、特にオンプレミスとクロスクラウドインフラストラクチャの両方を含むハイブリッド環境では非常に重要です。VPC フローログは、Google Cloud サブネットとの間、およびサブネット内のネットワークトラフィックの詳細なレコードを取得するための定番ツールとして長年使用されてきました。しかし、クロスクラウドネットワークによってより複雑なネットワークトポロジが実現されるにつれ、より完全な全体像を把握できるように VPC フローログを拡張する必要があることがわかってきました。

そこで、Cloud VPN トンネルと Cloud Interconnect および Cross-Cloud Interconnect の VLAN アタッチメントで、直接 VPC フローログを有効にできるようにしました。この機能強化により、オンプレミスインフラストラクチャ、クロスクラウドリソース、Google Cloud 間を移動する重要なネットワークトラフィックを包括的にモニタリングできます。この新機能では次のことが可能です。

詳細な分析情報の取得: Cloud Interconnect と Cloud VPN を通過するネットワークフローを、5 タプルの粒度（送信元 IP、宛先 IP、送信元ポート、宛先ポート、プロトコル）でログに記録できます。
パフォーマンスの最適化: 特定の VPN トンネルや VLAN アタッチメントを輻輳させている可能性のある「エレファントフロー」（高帯域幅フロー）を迅速に特定し、容量の計画と管理を改善できます。
共有 VPC の使用状況の監査: 共有 VPC 環境で、ハイブリッド帯域幅を最も消費しているサービスプロジェクトを特定できます。
利用状況をフローにマッピング: 全体レベルの帯域幅グラフを個々のアプリケーションフローにマッピングすることで、ハイブリッド接続の利用状況を正確に把握できます。
接続の問題を診断: オンプレミス / クロスクラウドアプリケーションが Google Cloud リソースに到達できない場合、ログを使用して、トラフィックが Google Cloud ゲートウェイ（VLAN アタッチメントまたは VPN トンネル）に到達しているかどうかを確認できます。
Cloud Interconnect のポリシー設定における Application Awareness を最適化: アプリケーションが DSCP（Differentiated Services Field Codepoint）を正しくマーキングしていることをモニタリングして確認できます。

また、これらのフローにさらにコンテキスト情報を提供するために、VPC フローログに「gateway」アノテーションも追加しました。ゲートウェイは、Google Cloud VPC と外部ネットワークの間を移動するトラフィックの出入り口として機能します。

クロスクラウドネットワークトラフィックのフローログを検査する際に、以下の 2 つの重要な新しいフィールドが表示されようになりました。

reporter: このフィールドは、ゲートウェイを基準としたトラフィックの方向を示します。

SRC_GATEWAY: トラフィックが Cloud Interconnect または Cloud VPN を介して Google Cloud に入ったことが確認された場合（例: オンプレミスから Google Cloud）。
DEST_GATEWAY: トラフィックが Cloud Interconnect または Cloud VPN を介して Google Cloud から出たことが確認された場合（例: Google Cloud からオンプレミス）。

gateway オブジェクト: この JSON ペイロードは、ゲートウェイ自体の完全なコンテキストを提供します。これには、名前、タイプ（VPN_TUNNEL または INTERCONNECT_ATTACHMENT）、project_id、ロケーションが含まれます。

Flow Analyzer でログを分析する

複雑な SQL クエリを記述せずにフローログを分析できるように、新しいゲートウェイアノテーションが Flow Analyzer に直接統合されました。Flow Analyzer は、Cloud Logging に保存された VPC フローログに対して、追加費用なしで詳細なネットワークトラフィック分析を実行できるネイティブツールです。Flow Analyzer を使用すると、次のことが可能になります。

ネットワーク内でトラフィックが特に多い通信元を、5 タプルの粒度で迅速に特定する。
実際の設定に基づいた接続テストを実行して、設定（ファイアウォールポリシーなど）がネットワークを流れるトラフィックに与える影響を把握する。
Gemini Cloud Assist を使用して自然言語クエリを作成する。
現在のネットワークフローを過去のデータ（過去 1 時間、1 日、1 週間など）と比較して分析する。

Cloud Interconnect トラフィックに関する分析情報を提供する Flow Analyzer

クロスクラウドネットワーク全体で不可欠な可視性を実現

クロスクラウドネットワークを実行している場合、VLAN アタッチメントと VPN トンネルで VPC フローログを有効にすると、相互接続されたネットワークの管理、保護、スケーリングに必要不可欠なテレメトリーが提供されます。この機能は、CLI、API、Terraform を使用するか、Google Cloud コンソールから直接、新規および既存の VLAN アタッチメントと VPN トンネルに対して有効にできます。

詳細については、VPC フローログのドキュメントをご覧いただくか、Flow Analyzer をお試しください。

-プロダクトマネージャー、Mary Colley

-プロダクトマネージャー、Neha Chhabra

画期的な AWS とのコラボレーションで Google Cloud のクロスクラウドネットワークを拡大

Fri, 12 Dec 2025 02:00:00 +0000

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

本日 Google は、Amazon Web Services（AWS）との重要なコラボレーションを発表します。両社が協業することで、クロスクラウド接続のための、プライバシーとセキュリティが確保されたマネージド型オンデマンドソリューションを提供いたします。このソリューションは、Google Cloud と AWS の両方の環境にまたがる、エンタープライズグレードのアプリケーションを簡単に構築できるように設計されています。このコラボレーションは、AI の台頭も一因となってマルチクラウドアプリケーションの導入が急速に加速している今、特にタイムリーなものです。Forbes のアンケートでは、回答者の 82% が、AI サービスの登場により、専用アクセラレータリソースの不足とさまざまなベンダーの多様な AI エージェントの利用可能性から、マルチクラウドネットワーキングの需要が増加すると予想していることが強調されています。マルチクラウド導入の急激な増加は、エージェント AI アプリケーションの構築、ワークロードの最適化、最先端のサービスへのアクセス、データ所在地要件の遵守、最新のハイブリッドアプリケーションとマルチクラウドアプリケーションに必要な復元力の確保を目指す組織にとって、戦略的に不可欠なことです。

マルチクラウドの導入によって生じる固有のネットワークインフラストラクチャの課題に対処するため、Google はクロスクラウドネットワークを設計し、Google Cloud と他のプロバイダ間のネットワーキングをシンプルにして最適化しました。マルチクラウド統合へのこの取り組みにより、現在 Fortune 500 の 50% 以上がクロスクラウドネットワークを使用しており、今回のコラボレーションは大きな後押しとなります。重要なのは、AWS と共同で設計されたこの新しいソリューションがオープン仕様で公開されることです。これにより、他のプロバイダがこのソリューションに参加して貢献する機会が増え、自社の環境に実装できるようになるため、それぞれのお客様にさらなるメリットがもたらされます。

AWS 向け Cross-Cloud Interconnect のご紹介

本日、マルチクラウドをシンプルかつ安全にするための大きな一歩を踏み出しました。このたび、お客様の環境とさまざまなクラウドプロバイダの環境との間のプライベートネットワーク接続を根本的に効率化する、業界初のオープン仕様を発表いたします。この画期的な共同仕様は、Cloud Interconnect ポートフォリオを強力に拡張する AWS 用 Partner Cross-Cloud Interconnect のプレビュー版として結実したものです。このイノベーションにより、Google Cloud と AWS VPC 間のオンデマンド接続を数分で構築できるようになり、マルチクラウドネットワーキングが、苦労して構築するものからシンプルなマネージドサービスへと変わります。

これは単なる接続方法に留まらず、マルチクラウドソリューションの導入方法を完全に変えるものです。両社は、共通のお客様に、以下のような大きな価値を提供しています。

シンプルさとスピード: 複雑なネットワーク構築は不要です。これは、フルマネージドのクラウドネイティブなエクスペリエンスであり、クラウド間の接続は 2 つの VPC のピアリングと同じくらい簡単です。エンドツーエンドのセットアップ時間は数日からわずか数分に短縮し、帯域幅は、プレビュー期間中の 1 Gbps から、一般提供時には 100 Gbps まで、オンデマンドで柔軟に拡張できます。
デフォルトで保護: データのセキュリティは非常に重要です。両社のクラウドのエッジルーター間における全接続は MACsec で暗号化され、常時暗号化しながら、回線の最高速度を達成する性能を備えているため、基盤のセキュリティが強化されます。
本質的な復元力: 本質的に復元力のあるアーキテクチャのメリットは、設備、ネットワーク、ソフトウェアの障害に対して各レイヤで対応し、重要なアプリケーションのオンライン接続を維持できることです。
オープンで最適化されている: 基盤は、業界全体でシームレスに採用できるオープン仕様です。また、ベンダーの統合と、必要なときに必要なものだけを利用できるオンデマンドサービスモデルにより、総所有コストを最適化できます。

このサービスは、ノーザンバージニア、オレゴン、ロンドン、フランクフルトの主要拠点でリリースを開始しました。今後、世界中のさらに多くの場所に急速に拡大する予定です。

クラウド間の接続をシンプルに

今回の共同設計ソリューション以前は、複数のクラウド環境にまたがるアプリケーションの構築は大事業となっており、しばしばマルチクラウド導入の障壁となっていました。お客様が直面する複雑で多層的なプロセスは、部門横断型チームの関与と大幅なリードタイムを強いるものでした。

典型的なデプロイでは、次のようないくつかの複雑な手順が必要でした。

調達: 専用接続または共有パートナーサービスを介して物理的な接続を確立し、ネットワークの可用性を確保して障害を分離するために必要なインフラストラクチャを構築、管理する。
論理構成: リンクローカル IP アドレスが重複しないように慎重に調整して割り当て、VLAN を設定することで、基本的な接続を確立する。
ルーティングの設定: BGP セッションを設定し、自律システム（AS）番号を割り当て、所定のパフォーマンスと信頼性の要件を満たす複雑なルーティングポリシーを作成する。
セキュリティの実装: 徹底的なセキュリティレビューを実施し、個別のクラウド環境間のトラフィックを暗号化するカスタムソリューションを実装する。

統合された Partner Cross-Cloud Interconnect サービスでは、この複雑な手順が完全に不要になります。お客様は、手動の手順をすべて省略し、セキュリティと復元力が組み込まれた事前構築済みの物理接続を即座に活用して、Google Cloud VPC と AWS 間のオンデマンド接続を効率的に実現できます。

このたび、この強力なクロスクラウド接続の構築が、非常に簡単になりました。お客様は、Google Cloud で 1 つの「トランスポート」リソースを構成し、AWS でそれを受け入れます。このトランスポートは、基盤となる物理相互接続、VLAN アタッチメント、Cloud Router インスタンスを完全に抽象化してプロビジョニングする、革新的なマネージドサービスです。この大幅なシンプル化により、マルチクラウドのデプロイが、数日かかるエンジニアリングプロジェクトから、シンプルな短時間の構成作業に変わり、エンドツーエンドの接続が数分で完了します。

内部の仕組み: 安全で復元力に優れた基盤

両社は、クロスクラウドアプリケーションのための安全で復元力に優れた基盤を提供するために、エンタープライズ環境の主要な可用性原則を損なうことのない、シンプルな新しいサービスによるソリューションを共同設計しました。

プライバシーとセキュリティ: すべてのピアリング関係はリンクローカルアドレス間で構築されるため、両方の環境にまたがる IPv4 と IPv6 のプライベートアドレス空間同士の接続が容易になります。Google Cloud と AWS のエッジルーター間のすべての基盤となる物理接続は MACsec で暗号化されており、両方のプロバイダともに鍵のローテーションを管理してエンタープライズグレードのセキュリティ要件を満たしています。
四重冗長性: Google Cloud と AWS クラウドリージョン間の接続を可能にするために、四重冗長接続を利用して、施設とエッジルーターの両方の冗長性を確保しています。この設計は、複数の同時障害シナリオから保護し、共同のお客様に高い復元力をもたらします。
マネージドオペレーションは、統合ソリューションを実現するための鍵となります。新たに導入されたソリューションは、お客様に代わって物理的および論理的な構築を効率化するだけでなく、お客様が障害の影響を受ける前に障害を検出して対応する、堅牢なプロアクティブモニタリングシステムを基盤として活用しています。このシステムは、エンドツーエンドのサービスの可用性に影響する可能性のある重複を避けるために、調整されたメンテナンス方式を採用しており、お客様に代わって潜在的な問題に対処するためにサポート業務を効率化しています。

さまざまなマルチクラウドワークロード

Google Cloud と AWS 間の効率化された新しいネットワーク接続により、アプリケーションチームは、さまざまな興味深いアプリケーションのネットワーク構築を自動化できます。次のようなシナリオを考えてみましょう。

アクティブ / アクティブまたはアクティブ / スタンバイの障害復旧戦略をサポートするインフラストラクチャと AI のデプロイ。2 つのピアサービス（エージェント AI アプリケーションやデータベースレプリカなど）間の基本的な接続により、アプリケーションはあたかも同一環境にあるかのようにクラウド境界を越えてステータスを同期し、アプリケーションの最大限の復元力と運用の一貫性を確保します。
AWS のお客様が Google Cloud にインバウンドリクエストを発行し、AWS で実行中のサービスが Google Cloud API に安全かつプライベートにアクセスできるようにします。たとえば、Compute Engine で実行されるカスタムアプリケーションや、セキュリティとパフォーマンスを強化するために公共のインターネットをバイパスする BigQuery でホストされる重要なデータウェアハウスなどがあります。
Google Cloud のお客様が AWS に向けてアウトバウンドリクエストを発行する場合、Google Cloud でオーケストレーションされるデータパイプラインが、S3 や RDS インスタンスなどの AWS データストアから大量のデータセットをプライベートでプルできます

Google Cloud と AWS で今すぐアプリケーションを構築

お客様の組織が、ユースケースにかかわらず、Google Cloud と AWS 環境間のシンプルかつ安全で堅牢なオンデマンド接続によってメリットが得られるとお考えの場合は、複数のクラウドをまたがるアプリケーションの構築を開始し、ネットワーク接続インフラストラクチャの管理は Google にお任せください。

このコラボレーションは、Google Cloud と AWS に限定されるものではありません。他のクラウドプロバイダやサービスプロバイダにも、Google Cloud とのこの効率化されたプライベートピアリング機能を顧客に提供していただくよう呼びかけています。詳しくは、オープン仕様をご確認のうえ、cross-cloud@google.com までお問い合わせください。Google は、両社のお客様の利益のために、このエコシステムを拡大できることを心から楽しみにしています。

-プロダクト管理担当ディレクター、Himanshu Mehra

-シニアプロダクトマネージャー、Judy Issa

AWS と Google Cloud が連携してマルチクラウドネットワーキングを簡素化

Wed, 03 Dec 2025 03:00:00 +0000

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

マルチクラウドアーキテクチャを採用する組織が増えるにつれ、クラウドサービスプロバイダ間の相互運用性への要求はかつてないほど高まっています。しかし、これまで異なるクラウド環境を接続することは困難であり、お客様はグローバルな多層ネットワークを大規模に管理するために、複雑な「自前主義」の方式を余儀なくされていました。

これらの課題に対処し、よりオープンなクラウド環境を推進するために、Amazon Web Services（AWS）と Google Cloud は協業し、クラウドサービスプロバイダ同士がシンプルに接続する方法を変革しました。

このたび、AWS と Google Cloud は、AWS Interconnect - multicloud と Google Cloud Cross-Cloud Interconnect の両方を使用する、共同設計のマルチクラウドネットワーキングソリューションを発表しました。このコラボレーションでは、ネットワークの相互運用性に関する新しいオープン仕様も導入されました。これによりお客様は、Google Cloud と AWS の間でプライベートな高速接続を確立し、高度な自動化とスピードを実現できます。

「Salesforce Data 360 をより広範な IT 環境と統合するには、堅牢でプライベートな接続が必要です。AWS Interconnect - multicloud を使用すると、Google Cloud への非常に重要な連携が、社内の AWS リソースをデプロイするのと同じくらい簡単に確立できます。このとき、事前構築された容量プールと、チームがいつも愛用しているツールを利用できます。プロビジョニングから継続的なサポートまで、このネイティブで合理化されたエクスペリエンスにより、お客様はデータの保存場所に関係なく、信頼できるデータに基づいて AI と分析を構築する能力を加速できます。」- Salesforce、ソフトウェアエンジニアリング担当シニアバイスプレジデント、Jim Ostrognai 氏

以前は、クラウドサービスプロバイダに接続するために、お客様は物理的な接続や機器などの複雑なネットワーキングの構成要素を手動で設定する必要がありました。このアプローチでは、長いリードタイムが必要となり、社内外の複数のチームと連携する必要がありました。この作業には数週間、あるいは数か月かかることもあります。AWS は、この機能をあらゆるクラウドサービスプロバイダが採用できる統一仕様として開発するというビジョンを持っており、Google Cloud と協力して市場に投入しました。

この新しいソリューションは、物理的なインフラ管理を脱却して、マネージドクラウドネイティブエクスペリエンスに移行することで、マルチクラウド接続を再構築します。AWS を Google Cloud のクロスクラウドネットワークアーキテクチャと統合することで、物理接続、ネットワークアドレス指定、ルーティングポリシーの複雑さを意識させずに扱いやすくしています。お客様は回線プロビジョニングに数週間も待つ必要がなくなり、専用帯域幅をオンデマンドでプロビジョニングし、好みのクラウドコンソールまたは API を使用して数分で接続を確立できます。

信頼性とセキュリティは、この連携の基盤です。この連携ソリューションにおいては、物理的に冗長な相互接続設備とルーター全体で 4 重の冗長化を行うことで、高い復元力を実現しています。AWS、Google Cloud の両プロバイダとも、継続的なモニタリングを実施し、問題をプロアクティブに検出して解決します。このソリューションは、Google Cloud と AWS のエッジルーター間の MACsec 暗号化を利用して、信頼基盤のもとに構築されています。

「AWS と Google Cloud のこのコラボレーションは、マルチクラウド接続における根本的な転換を表しています。お客様にとっての物理コンポーネントの複雑さを解消する標準を定義して公開し、高可用性とセキュリティをその標準に融合しました。今後、お客様は必要な接続を構築するための手間のかかる作業を心配する必要がなくなります。マルチクラウド接続が必要な場合は、簡単なクリック操作で数分以内に有効化できます。」- AWS、ネットワークサービス担当バイスプレジデント、Robert Kennedy 氏

「このコラボレーションに非常に期待しています。これによりお客様は、データとアプリケーションをクラウド間で移行する際にグローバルな接続が簡素化され、運用効率が向上します。今回の発表は、オープンで統合されたマルチクラウドエクスペリエンスをお客様に提供することに重点を置いた Google Cloud のクロスクラウドネットワークソリューションをさらに強化するものです。」- Google Cloud、クラウドネットワーキング担当バイスプレジデント兼ゼネラルマネージャー、Rob Enns

AWS と Google Cloud のこのコラボレーションは、単なるマルチクラウドソリューションではありません。よりオープンなクラウド環境に向けた一歩です。このプロダクト向けに開発された API 仕様は、他のプロバイダやパートナーが採用できるよう公開されています。すべてのお客様のグローバルな接続を簡素化することを目指しています。ぜひ、この新機能を今すぐお試しください。マルチクラウド運用を合理化する方法について詳しくは、Google Cloud Cross-Cloud Interconnect のブログと AWS Interconnect - multicloud のウェブサイトをご覧ください。

-Google Cloud、クラウドネットワーキング担当バイスプレジデント兼ゼネラルマネージャー Rob Enns

-Amazon Web Services、ネットワークサービス担当バイスプレジデント Robert Kennedy 氏

IP アドレスの不足を克服: Google Cloud の Private NAT の詳細

Tue, 25 Nov 2025 02:30:00 +0000

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

データセンターとクラウドで AI ワークロードをハイブリッドに実行するには、クラウドとオンプレミスのリソースを統合する高度なグローバルネットワークが必要です。Google の Cloud WAN は、VPC、データセンター、特殊なハードウェアを接続するために必要な統合ネットワークファブリックを提供しますが、この相互接続性こそが、IP アドレスの不足とサブネットの重複という、重要かつ根本的な課題を露呈させるものです。企業がプライベート環境とクラウド環境を統合していく中で、こうした蔓延するアドレスの競合を手動で解決することは、運用上の大きな負担となる可能性があります。

IPv4 アドレスの競合を解決することは、ネットワーキングにおける長年の課題でした。そして現在、IP の負荷が高いワークロードやアプリケーションが増加しており、お客様はデプロイに必要な IP アドレスを十分に確保するにはどうすればよいかという重要な問題に直面しています。

Google Cloud は、プライベート IP アドレスの課題に対処し、ルーティングできないネットワーク間の通信を容易にするために、Private Service Connect（PSC）、IPv6 アドレス指定、ネットワークアドレス変換（NAT）アプライアンスなどのさまざまなソリューションを提供しています。この投稿では、Cloud NAT サービスの機能である Privatr NAT に焦点を当てます。このマネージドサービスはプライベート間の通信を簡素化し、IP 空間が重複するネットワークを、複雑なルーティングや独自の NAT インフラストラクチャの管理なしで接続できるようにします。

Private NAT の概要

Private NAT を使用すると、Google Cloud リソースを他の VPC ネットワークに接続できるほか、重複するサブネットまたはルーティング不可能なサブネットを持つオンプレミスネットワークにも接続できます。仮想マシンやアプライアンスを管理する必要はありません。

Private NAT の主なメリットは次のとおりです。

マネージドサービス: フルマネージドサービスである Private NAT は、独自の NAT ゲートウェイの管理とスケーリングに伴う運用負荷を最小限に抑えます。基盤となるインフラストラクチャは Google Cloud が扱うため、お客様はアプリケーションに集中できます。
管理の簡素化: Private NAT は、ワークロードやトラフィックパス全体にわたるプライベート間の通信を一元的かつ簡単に管理する方法を提供することで、ネットワークアーキテクチャを簡素化します。
高可用性: 分散型サービスである Private NAT は、高可用性、VM 間のラインレートパフォーマンス、復元力を実現します。いずれも、コストのかかる冗長インフラストラクチャを過剰にプロビジョニングする必要はありません。
スケーラビリティ: Private NAT は、ニーズに合わせて自動的にスケールするように設計されているため、多数の NAT IP アドレスと同時接続に対応できます。

Figure: Cloud NAT options

一般的なユースケース

Private NAT は、最も複雑なハイブリッドネットワーキングとマルチ VPC ネットワーキングの課題に対する重要なアドレス変換を提供します。

Network Connectivity Center によるグローバルネットワークの統合

Network Connectivity Center を使用して中央接続ハブを確立する組織に対し、Private NAT は、重複する「ルーティング不可能」な IP アドレス範囲を持つネットワークをリンクするための重要なメカニズムを提供します。このソリューションは、主に次の 2 つのシナリオを実現します。

VPC スポーク間: サブネットが重複する個別の VPC ネットワーク（スポーク）間で、シームレスなプライベート間通信を可能にします。
VPC とハイブリッドスポーク間: Cloud Interconnect または Cloud VPN を介して接続された、クラウド VPC とオンプレミスネットワーク（ハイブリッドスポーク）間の接続を可能にします。詳しくは、こちらをご覧ください。

図: Network Connectivity Center を使用した Private NAT

共有 VPC でのローカルハイブリッド接続の有効化

共有 VPC アーキテクチャを採用している組織は、ルーティング不可能なネットワークサブネットや重複するネットワークサブネットから、ローカルの Cloud Interconnect または Cloud VPN トンネルへの接続を確立できます。1 つの Private NAT ゲートウェイで、VPC 内のすべてのワークロードの宛先ルートを管理できます。

「Private NAT のおかげで、出資提携後も IP アドレスが重複したままの状態で、Orange のオンプレミスデータセンターと Masmovil の GCP 環境を簡単に接続できました。既存の環境を変更せずに通信を可能にできたため、ビジネスの継続性にとって非常に重要なものとなりました。」 – MasOrange、クラウドプラットフォームエンジニアリング責任者 Pedro Sanz Martínez 氏

図: Private NAT を使用したローカルハイブリッド接続の有効化

Cloud Run および GKE ワークロードへの対応

Google Kubernetes Engine（GKE）や Cloud Run などの IP の負荷が高い動的なワークロードは、IPv4 の枯渇を解決するために、クラス E などの RFC 1918 以外の範囲を使用することがよくあります。これらのワークロードでは、オンプレミスネットワークまたはパートナー VPC 内のリソースへのアクセスが必要になることが多いため、オンプレミスネットワークが RFC 1918 以外の範囲に対応できることが非常に重要です。ほとんどの場合、中央のネットワークチームは RFC 1918 以外のアドレス範囲を受け入れません。

この問題は、RFC 1918 以外のサブネットに Private NAT 構成を適用することで解決できます。Private NAT を使用すると、Cloud Run サービスまたは GKE ワークロードからのすべての下り（外向き）トラフィックが変換されるため、ルーティング不可能なサブネット上にある場合でも、宛先ネットワークと安全に通信できます。Private NAT がさまざまなワークロードでどのように機能するかについては、こちらをご覧ください。

構成の活用: 設定例

gcloud コマンドを使用して、これらのユースケースのいずれかに対して Private NAT を構成する方法を見てみましょう。

例: IP が重複するパートナーネットワークへの接続

シナリオ: production-vpc には、アプリケーションサブネット（app-subnet-prod、10.20.0.0/24）が含まれています。Cloud VPN を介してパートナーのネットワークに接続する必要がありますが、アクセスする必要があるリソースに対しても、10.20.0.0/24 の範囲が使用されています。

ソリューション: app-subnet-prod からのトラフィックが VPN トンネルを通過する前に変換されるように Private NAT ゲートウェイを構成します。

1. NAT IP 専用のサブネットを作成する。このサブネットの範囲は変換に使用されるため、送信元または宛先と重複してはなりません。

code_block: <ListValue: [StructValue([('code', 'gcloud compute networks subnets create pnat-subnet-prod \\\r\n --network=production-vpc \\\r\n --range=192.168.1.0/24 \\\r\n --region=us-central1 \\\r\n --purpose=PRIVATE_NAT'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be8550e20>)])]>

2. Cloud Router を作成する。

code_block: <ListValue: [StructValue([('code', 'gcloud compute routers create prod-router \\\r\n --network=production-vpc \\\r\n --region=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be8550850>)])]>

3. Private NAT ゲートウェイを作成する。この構成では、app-subnet-prod からローカルの動的（is_hybrid に一致）宛先へのトラフィックのみが、pnat-subnet-prod サブネットの IP を使用して変換されるように指定します。

code_block: <ListValue: [StructValue([('code', "gcloud compute routers nats create pnat-to-partner \\\r\n --router=prod-router \\\r\n --region=us-central1 \\\r\n --type=PRIVATE --region=us-central1 \\\r\n --nat-custom-subnet-ip-ranges=app-subnet-prod:ALL\r\n\r\ngcloud compute routers nats rules create 1 \\\r\n --router=prod-router --region=us-central1 \\\r\n --nat= pnat-to-partner \\\r\n --match='nexthop.is_hybrid' \\\r\n --source-nat-active-ranges= pnat-subnet-prod"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be94a18b0>)])]>

これで、パートナーの重複するネットワークにトラフィックを送信する app-subnet-prod 内のすべての VM の送信元 IP が 192.168.1.0/24 範囲のアドレスに変換され、競合が解決されます。

Google Cloud の Private NAT は、IP アドレス空間が重複しているネットワークの接続という、よくある複雑な問題を見事に解決します。フルマネージドでスケーラブルかつ高可用性のサービスである Private Nat により、ネットワークアーキテクチャは簡素化され、運用オーバーヘッドは削減されます。また、複雑なハイブリッド環境やマルチクラウド環境を構築して接続することが容易になります。

詳細

Private NAT の利用を開始する準備はできましたか？詳細については、公式の Private NAT ドキュメントとチュートリアルをご覧ください。今すぐ独自のソリューションの構築を始めましょう。

-Google Cloud、プロダクトマネージャー Udit Bhatia

ネットワーキングが Google Cloud での AI ワークロードを強化する 7 つの方法

Tue, 25 Nov 2025 02:10:00 +0000

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

人工知能（AI）について話すとき、私たちはモデル、強力な TPU と GPU、膨大なデータセットに焦点を当てることがよくあります。しかし、その裏には、すべてを可能にする縁の下の力持ち、ネットワーキングがあります。ネットワーキングは抽象化されることが多いですが、AI ワークロードが効率的かつ安全に、大規模に機能できるようにする重要な仲介役です。

この投稿では、公開 API へのアクセスから次世代の AI 主導のネットワーク運用まで、Google Cloud 上の AI ワークロードとネットワークが連携する 7 つの重要な方法について説明します。

#1 - AI API への安全なアクセス

現在利用可能な強力な AI モデルの多く（Vertex AI の Gemini など）は、公開 API を介してアクセスされます。*-aiplatform.googleapis.com などのエンドポイントに呼び出しを行う場合、信頼できるネットワーク接続に依存することになります。これらのエンドポイントにアクセスするには、適切な認証が必要です。これにより、承認されたユーザーとアプリケーションのみがこれらの強力なモデルにアクセスできるようになり、データと AI への投資を保護できます。これらのエンドポイントにはプライベートにアクセスすることもできます。これについては、5 番目のポイントで詳しく説明します。

#2 - 推論用のモデルの公開

モデルのトレーニングまたはチューニングが完了したら、推論に利用できるようにする必要があります。Google Cloud のマネージドサービスに加えて、専用の強力な GPU を備えた VM ファミリーを使用して、お客様が管理するインフラストラクチャにモデルを柔軟にデプロイすることもできます。たとえば、モデルを Google Kubernetes Engine（GKE）にデプロイし、GKE Inference Gateway、Cloud Load Balancing、ClusterIP を使用して、プライベートまたはパブリック推論のために公開できます。これらのネットワーキングコンポーネントは、アプリケーションのエントリポイントとして機能し、アプリケーションがモデルのデプロイとシームレスかつ確実にやり取りできるようにします。

#3 - 高速 GPU 間通信

AI ワークロード、特にトレーニングでは、GPU 間で大量のデータを移動します。CPU コピーオペレーションに依存する従来のネットワーキングでは、ボトルネックが発生する可能性があります。そこで、リモートダイレクトメモリアクセス（RDMA ）などのプロトコルが役立ちます。RDMA は CPU をバイパスし、GPU 間でメモリからメモリへの直接通信を可能にします。

これをサポートするには、基盤となるネットワークがロスレスで高パフォーマンスである必要があります。Google は、データセンターアーキテクチャに非ブロッキングのレール整列型ネットワークトポロジを構築し、RDMA 通信とノードのスケーリングをサポートしています。複数の高パフォーマンス GPU VM ファミリーが RDMA over Converged Ethernet（RoCEv2）をサポートし、要求の厳しい AI ワークロードに必要な速度と効率性を実現しています。

#4 - データの取り込みとストレージの接続

AI モデルの質は、トレーニングに使用したデータの質に必ず比例します。このデータを効率的に保存、アクセス、取得する必要があります。Google Cloud では、Google Cloud Storage、Hyperdisk ML、Managed Lustre など、さまざまなストレージオプションが用意されています。ネットワーキングは、コンピューティングリソースをデータに接続するものです。データに直接アクセスする場合でも、ネットワーク経由でアクセスする場合でも、ストレージへの高スループットで低レイテンシの接続は、AI パイプラインをスムーズに実行するために不可欠です。

#5 - AI ワークロードへのプライベート接続

セキュリティは最重要事項であり、AI ワークロードが公共のインターネットに公開されないようにする必要があることがよくあります。Google Cloud では、マネージド Vertex AI サービスと独自の DIY AI デプロイの両方に対して、プライベート通信を実現する方法がいくつか用意されています。たとえば、次のようなものが挙げられます。

VPC Service Controls: データ漏洩を防ぐサービス境界を作成します。
Private Service Connect: VPC から Google API とマネージドサービスにプライベートにアクセスできます。PSC エンドポイントを使用して、独自のサービスまたは Google サービスに接続できます。
Cloud DNS: プライベート DNS ゾーンを使用して、AI サービスの内部 IP アドレスを解決できます。

#6 - ハイブリッドクラウド接続でギャップを埋める

多くの企業はハイブリッドクラウド戦略を採用しており、機密データはオンプレミスに残っています。クロスクラウドネットワークを使用すると、多対多の接続を提供するようにネットワークを設計できます。分散アプリケーション、グローバルフロントエンド、Cloud WAN をカバーする設計ケースを使用して、オンプレミス、他のクラウド、または他の VPC から AI ワークロードに接続するアーキテクチャを安全に構築できます。このハイブリッド接続により、データを安全に保ちながら、Google Cloud の AI サービスのスケーラビリティを活用できます。

#7 - 未来: AI によるネットワーク運用

AI とネットワーキングの関係は、双方向のものになりつつあります。ネットワークエンジニアは、Gemini for Google Cloud を使用して、自然言語でネットワークアーキテクチャを設計、最適化、トラブルシューティングできるようになりました。これは、自律型 AI エージェントがネットワークの問題をプロアクティブに検出、診断、さらには軽減できる「エージェントネットワーキング」と呼ばれるものに向けた第一歩です。これにより、ネットワークエンジニアリングが事後対応型から予測型、事前対応型へと変革され、ネットワークが AI ワークロード向けに常に最適化されます。

詳細

Google Cloud のネットワーキングと AI について詳しくは、以下をご覧ください。

ドキュメント: AI Hypercomputer
Codelabs: Gemini CLI on GCE with a Private Service Connect endpoint
ホワイトペーパー: Leveling up with Autonomous Network Operations.

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

-デベロッパーリレーションズエンジニア、Ammett Williams

Dhivaru と 2 つの新しい接続ハブのご紹介

Thu, 20 Nov 2025 03:00:00 +0000

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

Google はこのたび、モルディブ、クリスマス島、オマーンを結ぶ新しいインド洋横断海底ケーブルシステム、Dhivaru を発表いたします。この投資は、オーストラリア接続構想を基盤とするもので、インド洋全域のデジタル接続の到達範囲、信頼性、レジリエンスをさらに高めます。

到達範囲、信頼性、レジリエンスは、AI を活用した、ユーザーとお客様向けのサービスの成功に不可欠です。Gemini 2.5 Flash Image（別名 Nano Banana）や Vertex AI などの画期的なサービスが広く普及する中、ユーザーにとってレジリエンスのある接続の重要性がかつてないほど高まっています。AI の導入スピードも誰の予測よりも速く、Google はこの長期的な需要に応えるために投資しています。

「Dhivaru」は、モルディブの伝統的な帆船のメインセールを制御するロープで、海を航海する古来の船乗りのスキル、強さ、経験を意味します。

ケーブルへの投資に加えて、Google はこの地域に 2 つの新しい接続ハブを構築するための投資も行います。モルディブとクリスマス島は、アフリカ、中東、南アジア、オセアニアなどの地域のデジタル接続を改善するのに役立つ接続ハブとして、地理的に適した位置にあります。

「Google がモルディブに投資するという決定は、モルディブが安定したオープンな投資環境にあるという信頼感を明確に示すものであり、多様で包括的かつデジタル化されたモルディブ経済という私たちのビジョンに直接つながるものです。世界がデジタルトランスフォーメーションと AI によって定義される時代に急速に移行する中、モルディブは自身をグローバルな接続性の交差点に位置付けていますが、このプロジェクトにそれがよく表れています。有利な地理的条件を活かして、国民のために新たな経済的機会を創出し、グローバル経済の未来に大いに貢献します。」 - モルディブ共和国大統領、Mohamed Muizzu 閣下

「モルディブに新しい接続ハブを設立するという画期的な取り組みで、Google と提携できることを嬉しく思います。このプロジェクトは、国のデジタルインフラストラクチャを強化し、次なるデジタルトランスフォーメーションの波を可能にするための大きな一歩となります。大手デジタルプロバイダとして、Ooredoo Maldives は全国で世界クラスの接続性とデジタルサービスを拡大し続けています。この進歩により、観光などの業界では、よりスマートな運用、カスタマーエクスペリエンスの向上、グローバルなリーチの拡大など、新たなビジネスチャンスが生まれています。デジタルモルディブの次の段階を推進できることを誇りに思います。」 - Ooredoo Maldives CEO 兼 MD、Khalid Al Hamadi 氏

「Dhiraagu は、モルディブのデジタル接続を推進し、国民、コミュニティ、企業を支援することに尽力しています。長年にわたり、Dhiraagu は堅牢な海底ケーブルシステムの構築に多額の投資を行ってきました。これにより、デジタル環境が変革され、モルディブが世界とつながり、全国で高速ブロードバンドの展開が可能になりました。Google が海底インフラストラクチャを拡張し、モルディブ最南端の都市であるアッドゥ市に新しい接続ハブを設立するにあたり、Google と提携できることを誇りに思います。世界最大級のテクノロジー企業とのこの戦略的コラボレーションは、グローバルな海底インフラストラクチャにおけるこの国のプレゼンスを強化する新たなマイルストーンとなり、デジタルエコシステムの信頼性とレジリエンスをさらに高めます。」- DHIRAAGU、CEO 兼 MD、Ismail Rasheed 氏

インド洋地域の接続ハブ

接続ハブは、ケーブルの切り替え、コンテンツキャッシュ、コロケーションという 3 つのコア機能を通じて、地域の接続を将来にわたって確保し、次世代サービスの提供を加速させることを目的とした戦略的投資です。

ケーブルの切り替え: シームレスなレジリエンスを実現

Google は、データが「経路を切り替えられる」ポイントに到達するまでの距離を最小限に抑えるため、接続ハブの場所を慎重に選択しています.. この機能により、レジリエンスが向上し、この地域全体で堅牢かつ高可用性の接続が確保されます。このハブは、複数のケーブル間のトラフィックを自動的に再ルーティングすることもできます。1 本のケーブルに障害が発生した場合、トラフィックは自動的に次に最適なパスを選択して移動を続行します。これにより、ホスト国だけでなく、地域全体のサービスとユーザーのダウンタイムを最小限に抑え、高い可用性を確保できます。

コンテンツキャッシュ: デジタルサービスを加速

最適なユーザーエクスペリエンスを実現するには、低レイテンシが不可欠です。Google の目標の一つは、ユーザーとお客様のできるだけ近くからコンテンツを提供することです。Google は、最も人気のあるコンテンツのコピーをローカルに保存するキャッシュを使用することで、このコンテンツを取得または表示する際のレイテンシを短縮し、サービスの品質を向上させています。

コロケーション: 地域のエコシステムを育成

接続ハブは多くの場合、サービスや IT ハードウェアを収容する高品質のデータセンターにユーザーがアクセスしにくい場所（島など）にあります。これらの施設は Google のデータセンターと比べるとそれほど大きくありませんが、Google は共有インフラストラクチャのメリットを理解しており、通信事業者や地元企業にラックスペースを提供することに尽力しています。

エネルギー効率

海底ケーブルは非常にエネルギー効率に優れています。その結果、複数のケーブル、コンテンツストレージ、コロケーションをサポートする場合でも、Google の接続ハブは一般的なデータセンターよりもはるかに少ない電力しか必要としません。こうしたハブは主にネットワーキングとローカルストレージに重点を置いており、AI、クラウド、その他のインターネットの重要な構成要素をサポートする大きな需要には対応していません。もちろん、接続ハブに必要な電力は、小規模な拠点にとっては依然として大きな負担となる可能性があります。そのような場合、Google は、再生可能エネルギーソリューションを促進してきた長年の歴史に沿って、電力需要を利用して持続可能なエネルギー発電への地域投資を加速させることを検討しています。

モルディブとクリスマス島の新しい接続ハブは、インド洋地域のインターネットインフラストラクチャのレジリエンスを高めるのに最適な場所に位置しています。これらの施設は、Google のプロダクトを強化し、地域経済を活性化して、世界中の人々と企業に AI のメリットをもたらします。今後も海底ケーブルと接続ハブを発表し、インターネットの到達範囲、信頼性、レジリエンスをさらに高めていく予定です。

-Global Networking and Infrastructure 担当バイスプレジデント、Bikash Koley

一般提供が開始された Cross-Site Interconnect でグローバルネットワーク接続を再構築

Thu, 06 Nov 2025 01:10:00 +0000

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

現代の企業にとって、ネットワーク接続は AI 時代の生命線です。しかし、今日のテクノロジー環境には、従来のネットワーキングモデルを限界まで押し上げる課題があります。

積極的なクラウド移行とコロケーションスペースへの投資: 組織は、複数のベンダーのグローバル環境を相互接続するための複雑で高額な資本支出要件に苦労しています。
ネットワーク容量の需要の変化: AI / ML ワークロードのコンピューティングとデータ転送の要件は、前例のない速度で増加しており、ネットワークアーキテクチャの限界を露呈しています。
制約されるグローバル接続市場: 高帯域幅プロバイダの数が限られているため、多くの組織が複数のプロバイダのサービスを組み合わせる複雑な DIY アプローチ、もしくはレイヤ 3 ピアリングを必要とするクラウドホスト型ソリューションを採用せざるを得なくなっています。レイヤ 3 ピアリングには、IP アドレス指定の課題、帯域幅の制限、管理オーバーヘッドといった独自の課題が伴います。

その結果、企業は、パフォーマンス、シンプルさ、費用の間での難しいトレードオフに直面しています。

Cross-Site Interconnect: クラウドで提供されるマネージドレイヤ 2 接続

2023 年には、クロスクラウドネットワークをリリースしました。これにより、クラウド環境間で安全かつ堅牢なネットワークを構築し、グローバルにコンテンツを配信し、ユーザーがどこにいてもアプリケーションに接続できるようになりました。そのビジョンを Cloud WAN とCross-Site Interconnect で拡大し、データセンターやオンプレミスロケーションを含むグローバルに分散した企業を接続しました。このたび、Cross-Site Interconnect の一般提供が開始されましたので、お知らせいたします。

Google は、接続は、それがサポートするデジタルエコシステムと同じくらい動的で柔軟であるべきであるという前提に基づいて、Cross-Site Interconnect を構築しました。Cross-Site Interconnect は、Google のグローバルインフラストラクチャを活用した、透過的でオンデマンドのレイヤ 2 接続ソリューションです。これにより、WAN 全体で信頼性を簡素化、強化、向上させ、高パフォーマンスと高帯域幅の接続ユースケースを実現できます。それだけではありません。

グローバル企業の接続性を再構築

従来のネットワーク拡張には、多額の資本支出、複雑な調達プロセス、長いデプロイ期間が伴います。Cross-Site Interconnect により、Google Cloud はネットワーク上で透過的なレイヤ 2 接続を提供する最初の主要クラウドプロバイダとなり、現在の接続環境に大きな変化をもたらします。

Cross-Site Interconnect の利点は次のとおりです。

抽象化された復元力: 従来のモデルでは、複数のプロバイダから提供された保護されていないサービスを複数使用する組織は、共有リスクを最小限に抑え、ネットワーク内の単一障害点を回避するために、回線に関する詳細なマップと下位レベルの情報が必要になることがよくあります。また、同時障害、メンテナンスの時間枠の重複、平均修復時間（MTTR）のリスクをモデル化する必要があります。最後に、可用性の目標を達成するために、トポロジにモニタリング、検出、対応のメカニズムを組み込む必要があります。一方、Cross-Site Interconnect では、WAN の復元力のニーズを抽象的に指定すると、Google Cloud が SLA でそれを保証します。
シンプルさと柔軟性: 透明なレイヤ 2 サービスである Cross-Site Interconnect は、現在のネットワークアーキテクチャに簡単に対応できます。運用モデルを変更したり、IP アドレスの重複を心配したりすることなく、トラフィックエンジニアリング機能を構築したり、アクティブ/アクティブパターンやアクティブ/パッシブパターンを採用したり、Cross-Site Interconnect を活用して既存のネットワークアセットを強化したりできます。
必要な分だけ支払う: Cross-Site Interconnect は、クラウドの利用モデルをネットワークアセットに適用するため、インフラストラクチャへの多額の先行投資は不要です。さらに、使用量ベースの料金設定により、設定料金、初期費用、長期契約が不要になります。予想されるビジネスの需要を満たすために過剰にプロビジョニングするのではなく、使用したネットワークリソースに対してのみ料金を支払うことで、費用を最適化できます。
最適化されたインフラストラクチャ: Cross-Site Interconnect を使用すると、ポート速度を WAN 帯域幅から切り離し、ラストワンマイル接続を Google のグローバルバックボーンを介して配信されるミドルマイルから切り離すことができます。また、複数の宛先に到達するために、ラストマイル投資の価値を最大化することもできます。「VLAN モード」を使用すると、中央のロケーションで同じポートを利用して、複数の宛先への接続を確立できます。

また、Cross-Site Interconnect は、Google の広範な陸上ケーブルと海底ケーブル、グローバルに分散されたエッジロケーション、次世代のネットワークイノベーションに基づいて構築されているため、以下が提供されます。

ネットワークの信頼性: 複数の冗長パス、自動フェイルオーバーメカニズム、プロアクティブなモニタリングにより、基盤となるインフラストラクチャは障害に耐えられるように構築されています。Google のネットワークは、320 万キロメートルを超える光ファイバーと 34 本の海底ケーブルで構築されており、数百の Cloud Interconnect PoP でお客様に Cross-Site Interconnect を提供し、ケーブルの切断やメンテナンスなどのイベントを除外しない 99.95% の SLA を保証しています。Cross-Site Interconnect は、この復元力のあるインフラストラクチャを抽象化し、サービスとして利用できるようにします。複雑なフェイルオーバー構成を管理したり、個々のリンクの停止を心配したりする必要はありません。ネットワークが障害を回避してトラフィックをインテリジェントにルーティングし、サイト間の接続を継続します。
強固なセキュリティ: クラウド配信のレイヤ 2 オーバーレイである Cross-Site Interconnect を使用すると、長距離接続を介してレイヤ 2 隣接関係を構築できます。これにより、リモートルーター間で MACsec（またはその他のラインレートのレイヤ 2 暗号化メカニズム）を構成できるようになり、お客様が管理する鍵を使用したエンドツーエンドの暗号化が促進されます。
パフォーマンスの透明性: Cross-Site Interconnect は障害の検出と軽減を抽象化しますが、ネットワークオペレーターが環境のエンドツーエンドの可用性を維持するために必要な主要な指標も公開します。サービスを継続的にモニタリングするプローバーを使用することで、Cross-Site Interconnect は直感的なダッシュボードと API を介してデータを公開します。これにより、レイテンシ、パケットロス、帯域幅使用率などのネットワーク特性をモニタリングできます。
プログラマブルな使用量: Cross-Site Interconnect の使用量モデルは、進化するニーズに対応するように設計されています。必要に応じて帯域幅を動的にスケールアップまたはスケールダウンできるため、ネットワーク管理を自動化し、ネットワーク接続を Infrastructure as Code ワークフローに組み込むことができます。このプログラマビリティにより、アジリティと費用最適化が実現し、必要なときに必要な分だけ料金を支払うことができます。

さまざまなユースケース

ネットワーク容量の増強、信頼性の向上、新しい場所への拡張など、Cross-Site Interconnect は、さまざまな業界の重要な課題を解決する変革的なソリューションです。

たとえば、金融機関では、ネットワークレイテンシの短縮が直接競争上の優位性につながります。一貫した予測可能なパフォーマンスと強化された障害復旧機能により、Cross-Site Interconnect は、金融サービス組織がオンデマンドのネットワーク構築でアジリティを高め、フルマネージドのグローバルネットワーク接続で運用を合理化するのに役立ちます。

「スケーラブルで安定したネットワークは、当社のビジネス運営に不可欠であり、研究と市場対応を促進するデータ転送を可能にします。過去数か月にわたる長距離の Cross-Site Interconnect の試験運用では、安定性と信頼性が非常に高いことが証明されました。Cross-Site Interconnect を使用して、グローバルネットワークフットプリントの安定性をさらに高めることを楽しみにしています。」 - Citadel、クラウドプラットフォームエンジニアリング責任者、Chris Dee 氏

ミッションクリティカルなサービスを提供する他の厳しく規制された業界も、独自の信頼性とセキュリティ機能により、Cross-Site Interconnect を高く評価しています。たとえば、通信プロバイダはこれを使用して新しい地域に拡大できます。モデルビルダーは、ビジネスニーズに対応するために、帯域幅を迅速かつ動的に拡張できます。企業は、コロケーション施設での便利なハンドオフ、動的な帯域幅割り当て、一貫した高帯域幅のデータ転送、業界をリードする信頼性により、信頼性を高めることができます。

グローバル接続の未来がここに

Cross-Site Interconnect は、グローバルデータセンター間の信頼性、柔軟性、透明性の高い接続を求める企業にとって、独自の魅力的なソリューションです。Cross-Site Interconnect は、ネットワーク管理の複雑さを抽象化し、堅牢な保証を提供することで、グローバルな接続が確実に管理されていることを認識しながら、イノベーションと成長に集中できるようにします。

違いを体験するには、Cross-Site Interconnect の環境へのデプロイを開始するか、cross-site-interconnect@google.com までお問い合わせください。Google がお客様のグローバルネットワークインフラストラクチャをどのように強化できるかをご説明いたします。

ーシニアプロダクトマネージャー、Judy Issa

ープロダクトマネージャー、Matt Anderson

NVA とリージョンアフィニティを使用したクロスクラウドネットワーク VPC ネットワークピアリングを設計する

Tue, 04 Nov 2025 02:10:00 +0000

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

ネットワーク設計にセキュリティを組み込むために、ネットワーク仮想アプライアンス（NVA）を使用する必要がある場合があります。これらの構成をサポートするクロスクラウドネットワークの柔軟性により、企業はハイブリッド接続からクラウドに既存のセキュリティ要素を拡張して、一貫したエクスペリエンスを実現できます。このブログ投稿では、単一リージョン内で NVA を使用したハブアンドスポーク通信のリファレンスアーキテクチャをご紹介します。

リージョンアフィニティ

企業によっては、低レイテンシ、データ所在地、リソースの最適化に関する具体的な要件が存在する場合があります。リージョンアフィニティにより、同じリージョン内のサービス間のリソースとネットワークトラフィックが保持されます。ただし、考えられるトレードオフとして、障害が発生した場合にトラフィックが別のリージョンに再ルーティングされるリージョンフェイルオーバーが欠如する点があります。これらの考慮事項は、企業の要件に基づいて設定を設計する際に念頭に置く必要があります。リージョンデプロイの詳細については、Google Cloud リージョンデプロイアーキタイプのドキュメントをご覧ください。

クロスクラウドネットワーク

クロスクラウドネットワークは、多対多の接続を可能にする一連の機能とアーキテクチャを提供します。Google のソフトウェア定義グローバルバックボーンは、分散アプリケーションを接続する優れた機能を提供します。Google は、そのグローバルな規模をサポートするために、マルチシャード、Protective ReRoute（PRR）、自律型ネットワーキングを使用してネットワークを構築しています。

設計パターンの例

リージョン設計で VPC ネットワークピアリングを使用して NVA のネットワークを設定する方法を理解するために、設計パターンを見てみましょう。

このネットワークを構成するのは、外部ネットワーク（オンプレミスと他のクラウド）と Google Cloud ネットワーク（インターネットアクセス VPC、ルーティング VPC、サービスアクセス VPC、マネージドサービス VPC、ワークロード VPC）です。

トラフィックフロー

この設計では、エンドツーエンドのソリューションを提供するために次のサービスを使用します。

Cloud Interconnect（Direct、Partner、Cross-Cloud）- オンプレミスまたは他のクラウドからルーティング VPC に接続する
HA VPN - サービスアクセス VPC からルーティング VPC に接続し、マネージドサービスネットワークからカスタムルートをエクスポートする
内部パススルーネットワークロードバランサ - NVA のフロントエンドとして機能する
ネットワーク仮想アプライアンス - 特殊な機能を実行するコンピューティングリソース
タグなしのポリシーベースのルート - すべてのトラフィックに適用される
ポリシーベースのルートのスキップ - ポリシーベースのルートをスキップして VPC ルーティングを使用する
VPC ネットワークピアリング - ワークロード VPC からルーティング VPC に接続する
プライベートサービスアクセス - サービスアクセス VPC でマネージドサービスにプライベート接続する
Private Service Connect - プロデューサーネットワークでサービスを公開して、そのサービスをサービスアクセス VPC で使用できるようにする
Network Connectivity Center VPC スポーク - 必要に応じてワークロード VPC 間の通信を許可する

次の図は、パケットフローを示しています。

この図で、オレンジ色の線は外部ネットワーク（オンプレミスと他のクラウド）と Google Cloud のサービスアクセス VPC ネットワーク間のフローを示しています。

トラフィックは Interconnect を経由して、ルーティング VPC の外部 Cloud Router から学習したルートに従います。
ルーティング VPC は、タグなしのポリシーベースのルートを直接使用して、トラフィックを内部パススルー NLB に転送します。トラフィックが検査され、NVA は送信トラフィックでポリシーベースのルートのスキップを使用します。
トラフィックは、VPN 接続を介してサービスアクセス VPC へのカスタムルートに従います。
戻りのトラフィックは、同じトラフィックフローをたどり、Cloud Interconnect を介してオンプレミスに戻ります。

この図で、青い線は外部ネットワーク（オンプレミスと他のクラウド）と Google Cloud のワークロード VPC ネットワーク 1 の間のフローを示しています。

トラフィックは Interconnect を経由して、ルーティング VPC の外部 Cloud Router から学習したルートに従います。
ルーティング VPC は、タグなしのポリシーベースのルートを直接使用して、トラフィックを内部パススルー NLB に転送します。トラフィックが検査され、NVA は通過するトラフィックでポリシーベースのルートのスキップを使用します。
トラフィックは、VPC ネットワークピアリング接続を介して、サブネットルートに従ってワークロード VPC ネットワーク 1 に到達します。
戻りのトラフィックは、同じトラフィックフローをたどり、Cloud Interconnect を介してオンプレミスに戻ります。

この図で、ピンクの線は Google Cloud のワークロード VPC ネットワーク 1 と Google Cloud のサービスアクセス VPC ネットワーク間のフローを示しています。

ワークロード VPC ネットワークからのトラフィックは、ルーティング VPC ネットワーク内の NVA の前にある内部パススルーネットワークロードバランサにフローを転送するようにプログラムされたポリシーベースのルートに従います。
トラフィックは検査され、NVA から送信されるトラフィックに割り当てられたポリシーベースルートのスキップを使用して、タグなしのポリシーベースルートをスキップし、VPC ルーティングに従います。
トラフィックは、HA VPN トンネルからサービスアクセス VPC ネットワークへの動的ルートに従います。
戻りのトラフィックは、同じフローをたどり、ルーティング VPC と NVA を経由してワークロード VPC ネットワークに戻ります。

トラフィックフローと考慮事項に関するすべての詳細については、Google Cloud アーキテクチャセンターの VPC ネットワークピアリングクロスクラウドネットワーク（NVA とリージョンアフィニティを使用）ガイドをご覧ください。

次のステップ

クロスクラウドネットワーキングについて詳しく学び、ネットワークセキュリティの統合とクロスクラウドネットワークについてさらに詳しくお読みください。

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

-デベロッパーリレーションズエンジニア、Ammett Williams

必要な AI パフォーマンスを実現: GKE 上の A4X Max 向けマネージド DRANET のご紹介

Fri, 31 Oct 2025 02:00:00 +0000

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

AI/ML モデルの成長に伴い、インフラストラクチャの需要が従来のネットワーキングの限界に達し、重大なパフォーマンスボトルネックが生じています。これは、Kubernetes と Google Kubernetes Engine（GKE）で実行されるモデルに特に当てはまります。

Google は、オープンソースコミュニティと協力して、Kubernetes が特化したハードウェア機能を認識できるように取り組んでいます。たとえば、Google は、特化したハードウェア向けの汎用 API である Kubernetes の動的リソース割り当て（DRA）フレームワークの開発に積極的に取り組んでいます。DRA を基盤として、Google はネットワーキングの動的リソース割り当て（DRANET）を提案しました。これは、パフォーマンスに重点を置いた、ネットワークインターフェースをスケジューリング可能なファーストクラスのリソースとして管理するために DRA API を拡張します。

このたび、Google は Google Kubernetes Engine（GKE）のマネージド DRANET のプレビュー版を発表いたします。まずは、新登場の A4X Max インスタンスでご利用いただけます。今回のリリースにより、Google Cloud はマネージド DRANET を本番環境にデプロイします。まずは A4X Max から開始します。マネージド DRANET は、Kubernetes 上のアクセラレータとともに高性能ネットワークインターフェースをインテリジェントに割り当てるエンタープライズグレードの統合ソリューションを提供し、要求の厳しい AI ワークロードのネットワークパフォーマンスと運用上の複雑さという中核的な課題に対処します。

AI ネットワーキングの隠れたパフォーマンスのボトルネック

GKE 上の DRANET は、特に複数の GPU にわたって実行される AI ワークロード向けに設計されています。新しい A4X Max などの最新のアクセラレータインスタンスは、複数の高スループット RDMA ネットワークインターフェースを使用して、これらの強力な GPU にデータを供給します。しかし、従来の Kubernetes ネットワーキングインターフェースには制限があるため、これらのネットワーキング機能を最大限に活用するのが困難です。

トポロジの盲点: ピークパフォーマンスにはネットワークインターフェースの調整が必要です。レイテンシを短縮するには、GPU とそのネットワークインターフェースを物理的に「近く」に配置する必要があります。理想的には、同じ不均一メモリアクセス（NUMA）ノード上に配置します。デフォルトの Kubernetes スケジューラは、このハードウェアトポロジを認識していません。そのため、最適なペアリングができず、パフォーマンスが大幅に低下する可能性があります。
運用パフォーマンスの低下: NIC と GPU を同時にスケジュールできないと、リソースの使用率が最適化されません。スケジューラが利用可能なアクセラレータを、必要な特定のネットワークインターフェースと効果的に一致させることができないため、クラスタ全体のパフォーマンスと効率に影響します。

DRANET を使用した GKE がパフォーマンスを向上

Google のマネージド DRANET 統合を利用すると、GKE のコントロールプレーンは次の方法でパフォーマンスを向上させます。

インテリジェントなアライメントによるスループットの向上: これがパフォーマンスの向上における最大のメリットです。GKE で、割り当てられた GPU と NUMA アラインメントされたネットワークインターフェースを割り当てられるようになり、レイテンシが短縮され、スループットが向上します。NUMA アライメントは非常に重要です。DRANET に関する調査論文で詳しく説明されているように、一連の内部テストでは、バスの帯域幅が最大 59.6%増加しました。
動的リソース仕様: DRANET を使用すると、ワークロードのネットワーキングニーズを Pod 仕様で直接動的に表現できます。GPU リクエストと同時に、具体的な数の高パフォーマンスネットワークインターフェースをリクエストできます。この場合 GKE は、必要な GPU と具体的なネットワークインターフェースの両方が利用可能なノードにのみ Pod がスケジュールされるようにします。

これらは高度で複雑なプロセスですが、GKE 上のマネージド DRANET を使用すると、この複雑さを気にする必要がありません。成熟したエンタープライズグレードのコンテナオーケストレーションプラットフォームの柔軟性とシンプルさを備えながら、トポロジを認識するクラスタのパフォーマンスを実現します。

DRANET と新しい A4X Max: 完璧な組み合わせ

GKE 向けマネージド DRANET は、NVIDIA GB300 NVL72 ラックスケールシステムをベースとする Google の新しいフラッグシップ AI プラットフォームである Google Cloud A4X Max インスタンスのリリースに合わせて登場しました。これらのインスタンスは、超大規模 AI 向けに構築されており、複数の RDMA インターフェースを備えています。

GKE 上のマネージド DRANET は、このハードウェアのパフォーマンスを最大限に引き出し、各 GPU が必要とする専用で、整合性があり、低レイテンシのネットワークパスを確保します。A4X Max インスタンスの詳細については、リリース時のブログ全文をご覧ください。

GKE で築く AI ネットワーキングの未来

GKE 上のマネージド DRANET のリリースは、Kubernetes がトポロジに依存しないリソース管理からトポロジを認識するリソース管理に移行するマイルストーンです。これが Google Cloud の力です。強力なオープンソースのコンセプトを革新して主導し、シンプルでスケーラブルなマネージドソリューションとして提供してきました。

DRANET の詳細とご利用開始方法:

A4X Max のリリースブログを読む

GKE で DRANET を使ってみる

オープンソースプロジェクトを確認する

詳しくは、DRANET のオープンソースブログをご覧ください

DRANET の研究論文で詳細を確認

-Google Cloud、エンジニアリング担当ゼネラルマネージャー兼バイスプレジデント Rob Enns

-Google Cloud、プロダクトマネージャー Shrikant Kelkar

新しい Google Cloud 学習プログラムで、需要の高いネットワークセキュリティスキルを身につけましょう

Tue, 21 Oct 2025 02:00:00 +0000

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

組織をサイバー脅威から保護することは、スムーズな業務遂行とコンプライアンス要件の遵守に不可欠です。センシティブデータと重要なアプリケーションがクラウドに移行したことで、専門的な防御の必要性が高まっています。セキュリティは境界ファイアウォールだけではなく、動的なクラウドネットワークを保護することが重要です。

Google Cloud は、熟練したクラウドセキュリティプロフェッショナルの需要の高まりを認識し、新しいネットワークセキュリティの学習プログラムを開始します。このプログラムの最終目標は、「Google Cloud でのネットワークセキュリティの設計」上級スキルバッジの取得です。Google のエキスパートが設計したこの包括的なプログラムでは、機密データとアプリケーションの保護、事業継続の確保、成長の促進に必要な、検証済みのスキルを身につけることができます。

「Google Cloud でのネットワークセキュリティの設計」スキルバッジの取得は、キャリアアップの強力な推進力となります。Google Cloud が委託した Ipsos の調査によると、学習者の 70% がクラウド学習は昇進という目標に役立ったと回答し、76% が Google Cloud Learning Services の利用を開始してから収入が増加したと回答しています。

包括的な学習プロセス

この新しい学習プログラムは、単なる 1 つのコースではなく、ネットワーキング、インフラストラクチャ、セキュリティのロールを対象としたソリューションベースの学習に焦点を当てた完全なプログラムです。データを保護し、アプリケーションを保護する安全なネットワークを設計、構築、管理する方法を学び、次世代ファイアウォールポリシーの違反やデータ引き出しなどの実際のシナリオに対処する能力を検証します。このプログラムを修了すると、「Google Cloud でのネットワークセキュリティの設計」スキルバッジを獲得できます。

次の方法を学習します。

安全な VPC ネットワークの構築から Google Kubernetes Engine（GKE）環境のロックダウンまで、安全なネットワークトポロジを設計して実装する。
Google Cloud Next Generation Firewall（NGFW）をマスターして、正確なファイアウォールルールとネットワーキングポリシーを構成し、トラフィックフローを完全に制御する。
Cloud VPN と Cloud Interconnect を使用して、さまざまな環境間で安全な接続を確立する。
Google Cloud Armor を使用して防御を強化し、WAF と DDoS 保護に対する多層防御アプローチを実現する。
ネットワークリソースにきめ細かい Identity and Access Management（IAM）権限を適用する。
これらの原則を拡張して、複雑なハイブリッドクラウドアーキテクチャとマルチクラウドアーキテクチャを保護する。

将来に向けて支援する

この学習プログラムは、サイバーセキュリティスキルのギャップを埋めるための答えとなるでしょう。次世代のネットワークセキュリティに必要なスキルを身につけることができます。

スキルバッジを獲得するには、学習プログラムの最後に、ファイアウォールポリシー違反やデータ流出などの実際のシナリオに対処する能力を検証する、ハンズオンのブレイクフィックスチャレンジラボに取り組みます。

Google Cloud ネットワークセキュリティの学習プログラムに今すぐ登録して、組織のクラウドネットワークを自信を持って保護できるスキルを身につけましょう。

-Google Cloud Learning、マネージングディレクター、Erin Rifkin

ネットワークパフォーマンスの解読: ヘッダー、データ、ビットレートについて

Tue, 07 Oct 2025 04:00:00 +0000

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

Network Performance Decoded ホワイトペーパーシリーズの第 3 弾をお届けします。今回は、クラウドベースのワークロードのトラブルシューティング、デプロイ、スケーリング、アーキテクチャ設計を行う際に頻繁に発生する、ネットワークパフォーマンスとベンチマークのベストプラクティスに関するトピックについて詳しく説明します。このシリーズは、ネットワークを最大限に活用するだけでなく、アプリケーションのパフォーマンスに大きな影響を与える可能性のあるコストのかかるミスを回避するためのヒントを提供するために、昨年開始されました。前回の 2 回の記事では、TCP と UDP のバルクフローのパフォーマンスのチューニングとネットワークパフォーマンスの制限要因について説明しました。

今回は、最近の 3 つのホワイトペーパーの概要を紹介します。1 つ目は TCP 再送信に関するもの、2 つ目はヘッダーと MTU がデータ転送のパフォーマンスに与える影響に関するもの、3 つ目は netperf を使用して 1 秒あたりのパケット数を測定するものです。

1. 迅速な対応: TCP 再送信動作の調整

TCP 再送信動作のチューニングの概要に関するホワイトペーパーでは、2 つの Linux TCP 設定（net.ipv4.tcp_thin_linear_timeouts と net.ipv4.tcp_rto_min_us（または rto_min））を調整して、オンラインアプリケーションの応答性を高める方法について説明しています。これは、アプリケーションの応答時間と、ネットワークに問題が発生した場合のアプリケーションの復旧速度を微調整するようなものです。

詳細については論文をお読みいただく必要がありますが、ここでは論文で取り上げられている内容の概要をご紹介します。

より迅速な復元が可能に: これらの設定、特に rto_min を小さくすることで、ネットワークに短時間の中断が起きた後に、TCP 接続が何もせずに待機する時間を大幅に短縮できます。つまり、アプリの応答が速くなり、ユーザーはよりスムーズな体験を得られます。
新しいカーネルはより便利に: 新しい Linux カーネル（6.11 以降）を実行している場合は、rto_min をさらに低く（5 ミリ秒まで）設定できます。これは、新しいカーネルではよりスマートな方法で処理が行われるため、復元がさらに速くなるからです。
Protective ReRoute で、復元力は次のレベルに: Google Cloud をご利用のお客様は、net.ipv4.tcp_rto_min_us を調整することで、Google Cloud の Protective ReRoute（PRR）メカニズムをより早く起動させ、アプリケーションのネットワーク問題に対する復元力を高めることができます。
一時的な停止以外も対象に: ランダムで個別に発生したパケットロスの場合にも、これらの調整は効果を発揮します。アプリの応答速度の目標がある場合は、これらの設定を使用して、TCP がその期限よりも前にデータを再送信するようにできます。

aside_block: <ListValue: [StructValue([('title', '$300 分のクレジットで Google Cloud のネットワーキングを試用'), ('body', <wagtail.rich_text.RichText object at 0x7f9bd46b7a30>), ('btn_text', ''), ('href', ''), ('image', None)])]>

2. ネットワークのリンク速度を超える

ネットワークパフォーマンスを考えるときは、「リンク速度」だけを考慮するのではなく、Google のホワイトペーパー「ヘッダー、データ、ビットレート」では、データ転送の真の速度がどのように決まるかについて説明しています。

ヘッダー: パケットごとに送信される実際のデータを減らすために必要なパッケージングと考えてください。
最大伝送単位（MTU）: 最大パケットサイズを決定します。MTU が大きいほど、パケットあたりのデータ量が多くなり、データ転送の効率が向上します。

クラウド環境では、VM のアウトバウンドデータの上限（下り上限）は、必ずしも物理ネットワークの速度と同じではありません。クラウド固有の追加ヘッダーは、近い場合でも最終的なスループットに影響を与える可能性があります。MTU 設定を最適化して、クラウドネットワークを最大限に活用しましょう。つまり、宣伝されている速度だけでなく、データがどれだけ効率的に移動するかが重要です。

3. 処理できるトランザクションの数は？

netperf を使用して 1 秒あたりのパケットの集計数を測定するでは、netperf を使用して、ネットワークが 1 秒あたりに処理できるトランザクション（つまりパケット）の数を把握する方法を学びます。これは、巨大なファイルを移動するだけではないシステムにとって非常に便利です。大量の転送を測定するだけでなく、リクエスト/レスポンスアプリケーションのパフォーマンスを制限する可能性がある 1 秒あたりのパケット数を測定する方法を学びます。

主なポイント:

スキューエラーの解消: netperf 一度に多数のテストを実行すると、奇妙な結果になることに気づいたことはありませんか？これは「スキューエラー」と呼ばれます。このホワイトペーパーでは、「デモモード」を使用してこのエラーを修正し、全体的なパフォーマンスの数値をより正確に取得する方法について説明します。
テストの規模を把握する: 信頼できる結果を得るために必要な「ロードジェネレータ」（トラフィックを送信するマシン）の数と同時ストリームの数に関する実用的なヒントを入手できます。基本的には、システムに真に挑戦できるだけのパワーが必要です。
UDP バーストモードが役立つ理由: 「バーストモード UDP/RR」を使用することが、1 秒あたりのパケット数を測定するための秘訣である理由を説明しています。TCP は非常にスマートですが、効率性を追求しすぎるあまり、パケットの真のレートを隠してしまうことがあります。
フルスペクトルのテストと分析: ホワイトペーパーでは、runemomniaggdemo.sh スクリプトで実行できるさまざまなテストタイプについて説明し、テスト対象のインスタンスが 1 秒あたりに処理できるネットワークトランザクション数を効果的に測定する方法を示しています。これにより、このベンチマークに影響を与える、ネットワークの他の部分の側面を推測できる可能性があります。さらに、数値を処理する方法や、結果を可視化するためのグラフを作成する方法も紹介します。

今後の情報にご注目ください

これらのリソースを通じて、ネットワークのベンチマークとトラブルシューティングのためのオープンで協力的なコミュニティを育成することが Google の目標です。例は Google Cloud から引用していますが、その根底にある原則は、ワークロードがどこで動作していても普遍的に適用できます。公開済みおよび今後公開されるすべてのホワイトペーパーは、こちらのウェブページからご覧いただけます。今後もぜひご期待ください。

-シニアプロダクトマネージャー、Sumit Singh

-ネットワークソフトウェアエンジニア、Rick Jones

ネットワーキング

Google Cloud のアプリケーション ロードバランサへの移行: 実践ガイド

シンプルで段階的な移行アプローチ

スムーズな移行のためのベスト プラクティス

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

エージェント型 AI がネットワーキングの問題を変える

Envoy がこの移行に対応できる理由

1. Envoy はエージェント トラフィックを理解する

2. Envoy は重要な事項に関するポリシーを適用する

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

4. Envoy はエージェントの検出をサポートする

5. Envoy はエージェント ネットワーキングの課題に対する包括的なソリューション

コントロール プレーンがこれを運用可能にする

このソリューションが重要な理由

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

AI 推論にマルチクラスタを使用する理由

仕組み

使ってみる

AI ネイティブなコア: Google Kubernetes Engine を使用した、レジリエンスの高い通信事業者向けアーキテクチャ

ネットワーク モダナイゼーションの 2 つの方法

「通信事業者グレード」の基盤のエンジニアリング

AI で「節約」から「解決」へ

貴社の戦略に合わせた変革を

RAG 対応生成 AI アプリケーションのプライベート ネットワーク接続の設計

RAG の効力

設計パターンの例

トラフィック フロー

RAG の挿入フロー

推論フロー

管理とルーティング

次のステップ

Firefly: データセンターでナノ秒レベルのクロック同期を実現するソリューション

ナノ秒単位の競争: 正確なタイミングが重要である理由

Firefly: ソフトウェアと理論の橋渡し

実環境でのパフォーマンス

未来の可能性の基盤

Google Distributed Cloud、エアギャップ環境でパブリック クラウドのようなネットワーキングを実現

Cloud NAT でアウトバウンド トラフィックを管理する

標準クラスタを組織に直接接続する

ロードバランサの HTTP および HTTPS ヘルスチェックで信頼性を向上させる

サブネット グループを使用してサブネット管理を容易にする

使ってみる

Model Context Protocol の gRPC トランスポート

RPC トランスポートの選択

gRPC のメリット

使ってみる

Hackensack Meridian Health は VPC Flow Logs を使用してネットワーク移行のリスクを軽減

移行準備に VPC Flow Logs を使用

成功へと導く VPC Flow Logs と Flow Analyzer

VPC フローログと Flow Analyzer でクロスクラウド ネットワーク トラフィックの分析情報を取得

Flow Analyzer でログを分析する

クロスクラウド ネットワーク全体で不可欠な可視性を実現

画期的な AWS とのコラボレーションで Google Cloud のクロスクラウド ネットワークを拡大

AWS 向け Cross-Cloud Interconnect のご紹介

クラウド間の接続をシンプルに

内部の仕組み: 安全で復元力に優れた基盤

さまざまなマルチクラウド ワークロード

Google Cloud と AWS で今すぐアプリケーションを構築

AWS と Google Cloud が連携してマルチクラウド ネットワーキングを簡素化

AWS と Google Cloud が連携してマルチクラウド ネットワーキングを簡素化

IP アドレスの不足を克服: Google Cloud の Private NAT の詳細

Private NAT の概要

一般的なユースケース

構成の活用: 設定例

詳細

ネットワーキングが Google Cloud での AI ワークロードを強化する 7 つの方法

#1 - AI API への安全なアクセス

#2 - 推論用のモデルの公開

#3 - 高速 GPU 間通信

#4 - データの取り込みとストレージの接続

#5 - AI ワークロードへのプライベート接続

#6 - ハイブリッド クラウド接続でギャップを埋める

#7 - 未来: AI によるネットワーク運用

詳細

AI 時代の Google のグローバル ネットワークを支えるテクノロジーを解説

Dhivaru と 2 つの新しい接続ハブのご紹介

インド洋地域の接続ハブ

エネルギー効率

一般提供が開始された Cross-Site Interconnect でグローバル ネットワーク接続を再構築

Cross-Site Interconnect: クラウドで提供されるマネージド レイヤ 2 接続

Google Cloud のアプリケーションロードバランサへの移行: 実践ガイド

スムーズな移行のためのベストプラクティス

1. Envoy はエージェントトラフィックを理解する

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

コントロールプレーンがこれを運用可能にする

ネットワークモダナイゼーションの 2 つの方法

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

トラフィックフロー

Google Distributed Cloud、エアギャップ環境でパブリッククラウドのようなネットワーキングを実現

Cloud NAT でアウトバウンドトラフィックを管理する

サブネットグループを使用してサブネット管理を容易にする

VPC フローログと Flow Analyzer でクロスクラウドネットワークトラフィックの分析情報を取得

クロスクラウドネットワーク全体で不可欠な可視性を実現

画期的な AWS とのコラボレーションで Google Cloud のクロスクラウドネットワークを拡大

さまざまなマルチクラウドワークロード

AWS と Google Cloud が連携してマルチクラウドネットワーキングを簡素化

AWS と Google Cloud が連携してマルチクラウドネットワーキングを簡素化

#6 - ハイブリッドクラウド接続でギャップを埋める

AI 時代の Google のグローバルネットワークを支えるテクノロジーを解説

一般提供が開始された Cross-Site Interconnect でグローバルネットワーク接続を再構築

Cross-Site Interconnect: クラウドで提供されるマネージドレイヤ 2 接続

NVA とリージョンアフィニティを使用したクロスクラウドネットワーク VPC ネットワークピアリングを設計する

リージョンアフィニティ

クロスクラウドネットワーク

トラフィックフロー

新しい Google Cloud 学習プログラムで、需要の高いネットワークセキュリティスキルを身につけましょう

ネットワークパフォーマンスの解読: ヘッダー、データ、ビットレートについて