【Google Cloud入門】Google Cloudネットワークの負荷分散

Last updated at 2025-12-13Posted at 2025-12-13

皆様、こんにちは！
アイレット株式会社 DX開発事業部の楊林と申します。

前回の投稿では、Google Cloud のネットワークに接続する方法や、VPC を共有する仕組みについてまとめました。

今回は、アプリケーションの性能にも関わる「Google Cloud のロードバランシング」について、できるだけ分かりやすく整理して紹介していきます。

HTTP(S)負荷分散

まず代表的なのが HTTP(S) 負荷分散です。これはOSIモデルのレイヤ7、つまりアプリケーション層で動作するロードバランサで、リクエスト内容を見ながら、URL に基づいて最適なバックエンドに振り分けてくれます。

特徴としては、単一のエニーキャストIPアドレスでグローバル負荷分散ができ、ユーザーは常にもっとも近くて容量に余裕のあるリージョンに誘導されます。HTTP は 80/8080、HTTPS は 443 ポートで処理され、IPv4/IPv6 両方のクライアントにも対応しています。スケーラブルで、事前のプレウォーミングも必要ありません。

リクエストの流れとしては、最初にグローバル転送ルールがターゲット HTTP プロキシにリクエストを渡し、そこから URL マップに基づいて適切なバックエンドサービスにルーティングされます。バックエンドサービス側では、各インスタンスの正常性や容量、ゾーンなどを踏まえて最適なバックエンドに転送されます。

バックエンドサービスでは、ヘルスチェックでインスタンスの状態を監視し、必要であればセッションアフィニティを設定して同じクライアントを同じインスタンスに割り当てたり、30 秒（デフォルト）のタイムアウトを調整したりできます。また、バックエンドとしてマネージド / 非マネージドのインスタンスグループを使い、CPU 使用率やリクエスト数に基づいてスケーリングすることもできます。

NEG

ネットワークエンドポイントグループ(NEG)はより細かいレベルでバックエンドを指定するための構成オブジェクトです。特にコンテナやサーバーレス環境でよく利用されます。

NEGは一部のロードバランサのバックエンドとして使用でき、Traffic Directorとの併用も可能です。

NEGに四種類があります。

ゾーンNEG：1つ以上のエンドポイントが含まれます。エンドポイントにはCompute Engine VMか、VM上で実行されるサービスを指定できます。各エンドポイントは IPアドレス、または「IP:ポート」の組み合わせで指定します。
インターネットNEG：Google Cloudの外部でホストされる単一のエンドポイントが含まれます。エンドポイントはホスト名「FQDN:ポート」、または「IP:ポート」で指定します。
ハイブリッド接続NEG：Google Cloudの外部で実行されているTraffic Directorサービスを指します。
サーバーレスNEG：NEGと同じリージョンにあるGoogle Cloudサービスを指します。

Cloud CDN

Cloud CDN は Google の世界中のエッジポイントにコンテンツをキャッシュして、ユーザーに近い場所から高速に返してくれるサービスです。

Cloud CDNを使うと、ネットワークレイテンシの低減、コンテンツ配信元の負荷の軽減、コスト削減を実現できます。HTTP(S)ロードバランサのバックエンドサービスを設定するときに、チェックボックスで簡単に有効化できます。

キャッシュモードを使用するとCloud CDNがコンテンツをキャッシュに保存するかどうかを決定する要素を制御できます。Cloud CDNには3つのキャッシュモードがあり、レスポンスがキャッシュに保存される方法、送信元から送信されたキャッシュディレクティブに準拠するかどうか、キャッシュTTLの適用方法を定義します。

USE_ORIGIN_HEADERS：有効なキャッシュディレクティブと有効なキャッシュヘッダーを設定するために、送信元レスポンスが必要です。
CACHE_ALL_STATIC：no-store、private、no-cacheのいずれかのディレクティブが設定されていない静的コンテンツが自動的にキャッシュに保存されます。有効なキャッシュディレクティブを設定した送信元レスポンスもキャッシュに保存されます。
FORCE_CACHE_ALL：レスポンスを無条件にキャッシュに保存し、送信元で設定されたすべてのキャッシュディレクティブをオーバーライドします。このモードが設定された共有バックエンドを使用する場合は、動的HTMLやAPIレスポンスなどのユーザー単位の非公開コンテンツをキャッシュに保存しないようにします。

SSLプロキシ負荷分散

SSL プロキシ負荷分散は、暗号化された非 HTTP トラフィックを対象にしたグローバル負荷分散です。

SSLプロキシ負荷分散はロードバランシングレイヤでユーザーのSSLセッションを終止し、SSLプロトコルまたはTCPプロトコルを使用して、接続をインスタンス間で分散させます。インスタンスは複数のリージョンに配置できます。ロードバランサは十分な容量がある最も近いリージョンにトラフィックを自動的に送信します。

複数リージョンにまたがって構成でき、容量に応じて最適なリージョンへ自動的にルーティングされます。証明書の一元管理や SSL ポリシーによるセキュリティ管理もできるため、セキュリティ面での運用負荷を大きく下げられます。

TCPプロキシ負荷分散

TCPプロキシ負荷分散は暗号化されていない TCP トラフィック向けのグローバルロードバランシングサービスです。

TCPプロキシ負荷分散はロードバランシングレイヤでユーザーのTCPセッションを終止し、SSLプロトコルまたはTCPプロトコルを使用して、接続をインスタンス間で分散させます。インスタンスは複数のリージョンに配置できます。ロードバランサは十分な容量がある最も近いリージョンにトラフィックを自動的に送信します。

TCPプロキシ負荷分散はIPv4アドレスとIPv6アドレスのクライアントトラフィックをサポートし、SSLプロキシ負荷分散と同じく、インテリジェントルーティングとセキュリティパッチを備えています。

ネットワーク負荷分散

ネットワーク負荷分散はプロキシを使用しない、リージョンロードバランシングサービスです。すべてのトラフィックがプロキシを使用せずに、ロードバランサを介して渡されます。グローバルロードバランシングと異なり、同じリージョンに存在するVMインスタンスの間でのみ、トラフィックを分散できます。

ネットワーク負荷分散は転送ルールを使用し、アドレス、ポート、プロトコルタイプなどの受信IPプロトコルデータに基づいてシステムの負荷を分散させます。

内部負荷分散

内部 TCP/UDP 負荷分散は、VPC 内部で完結するプライベートなロードバランサです。外部に公開したくないサービスをスケーラブルに提供したいときに使います。Google の仮想化基盤 Andromeda 上で動作しており、クライアントからバックエンドインスタンスへ直接トラフィックを流す分散型アーキテクチャになっています。

また、内部 HTTP(S) 負荷分散というレイヤ7のプライベートロードバランサもあり、こちらは Envoy プロキシをベースにしたマネージドサービスです。内部向けにも HTTP/HTTPS/HTTP2 の制御ができるのが特徴です。

最後に

今回は、Google Cloud ロードバランシングについて整理して紹介しました。
アプリケーションの構成によって選ぶロードバランサは変わるので、特性を理解して適切に使い分けると、より安定したサービス運用につながります。

次回は Google Cloud のオブジェクトストレージサービス、Cloud Storage について紹介していきます。
ぜひ続けて読んでいただけると嬉しいです！

以前の投稿

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up