【ITニュース解説】Part-74: Implement a Regional External Network Load balancer with TCP Proxy in GCP Cloud

システムエンジニアを目指す初心者の皆さんが、Google Cloud Platform（GCP）で外部からの大量のアクセスを複数のサーバーに効率良く分散させるための重要な技術、「リージョナル外部ネットワークロードバランサー（TCPプロキシ）」について解説する。この技術は、特定の地域（リージョン）内で動くアプリケーションの安定性とスケーラビリティを高める役割を果たす。

まず、ロードバランサーとは、インターネットからのリクエストを複数のサーバー（バックエンド）に振り分け、特定のサーバーに負荷が集中するのを防ぐ仕組みだ。これにより、アプリケーションは安定して動作し、急なアクセス増加にも対応できるようになる。今回の解説の中心となるのは「ネットワークロードバランサー」であり、特に「TCPプロキシ」という方式を用いる。これは、データの送受信を行うための基本的な通信規約であるTCPレベルで通信を処理し、クライアントからの接続をロードバランサーが一旦受け止め、新たなTCP接続をバックエンドサーバーに確立し直すことで、より柔軟な負荷分散とセキュリティの向上を実現する。

このロードバランサーを構築するには、いくつかの準備が必要となる。まず、アプリケーションサーバーのグループである「マネージドインスタンスグループ（MIGs）」と、その設計図となる「インスタンステンプレート」が事前に作成されていることが前提となる。MIGsは、同じ設定の仮想マシンインスタンスを複数管理し、自動スケーリングや自動修復といった機能を提供する。ロードバランサーは、このMIGsに属するインスタンス群に対してトラフィックを分散する。

次に、ロードバランサーのプロキシ機能が動作するための特別なネットワーク領域、「プロキシ専用サブネット」を確保する。GCPのVPCネットワーク（仮想プライベートクラウド）内で、特定のリージョン（例: us-central1）に「lb-subnet-proxyonly-us-central1」という名前でサブネットを作成する。このサブネットは、ロードバランサーがクライアントからの接続を受け取った後、バックエンドサーバーに接続するための「中継地点」として機能する。この専用サブネットに割り当てるIPアドレス範囲（例: 10.129.0.0/23）は、他のネットワークリソースと重複しないように慎重に選ぶ必要がある。

プロキシ専用サブネットを設けた後は、バックエンドサーバーへの通信を許可する「ファイアウォールルール」を設定する。ファイアウォールは、ネットワークにおける交通整理役のようなもので、特定の通信だけを許可したりブロックしたりする。ここでは「vpc3-custom-allow-proxy-only-subnet」というルールを作成し、先ほど定義したプロキシ専用サブネットからの通信（送信元IPアドレス範囲10.129.0.0/23）が、バックエンドサーバーが利用するポート（TCPの80, 443, 8080など）に到達することを許可する。これにより、ロードバランサーのプロキシは問題なくバックエンドサーバーと通信できるようになる。

アプリケーションが正常に動作しているかを確認するための「リージョナルヘルスチェック」も不可欠だ。ヘルスチェックは、ロードバランサーがトラフィックを振り分ける前に、バックエンドサーバーが正常に稼働しているかを定期的に確認する仕組みである。もしサーバーが故障したり、応答がなくなったりした場合、ヘルスチェックはそのサーバーを「異常」と判断し、ロードバランサーはそのサーバーに新たなトラフィックを送るのを一時的に停止する。今回の場合は「regional-tcp-health-check」というTCPヘルスチェックを作成し、バックエンドサーバーのポート80へのTCP接続が成功するかどうかで健全性を判断する。これにより、ユーザーに常に正常なサーバーが提供されることが保証される。

これらの準備が整ったら、いよいよ「リージョナルロードバランサー」本体を作成する。GCPのロードバランシング設定画面で、インターネットからのアクセスをVMに分散させる「ネットワークロードバランサー（TCP/SSL）」を選択し、「プロキシ」タイプのロードバランサーとして「regional-lb-external-tcp-proxy」という名前で構築する。このロードバランサーも、特定のリージョンとVPCネットワークに紐付ける。

ロードバランサーの構成は大きく「バックエンド構成」と「フロントエンド構成」に分けられる。 まず「バックエンド構成」では、ロードバランサーがトラフィックを転送する先のサーバー群を定義する「バックエンドサービス」を作成する。ここでは「regional-lb-external-tcp-proxy」という名前でバックエンドサービスを設定し、タイプを「インスタンスグループ」とする。先ほど作成したMIGs（例: mig1-us-central1）をこのバックエンドサービスのメンバーとして追加し、アプリケーションが動作しているポート80を指定する。プロトコルはTCPとし、タイムアウトなどの詳細設定も行う。そして、先に作成した「regional-tcp-health-check」をこのバックエンドサービスに適用することで、バックエンドサーバーの健全性が常に監視されるようにする。

次に「フロントエンド構成」では、ユーザーがロードバランサーにアクセスするための外部インターフェースを定義する。ここでは「frontend-tcp」という名前でフロントエンドを設定し、プロトコルをTCP、ポートを80とする。重要なのは、ユーザーが固定のIPアドレスでサービスにアクセスできるよう、「regional-lb-ip1」という新しい外部静的IPアドレスを作成して割り当てることだ。これにより、ロードバランサーのIPアドレスは常に一定となり、DNSレコードなどでサービスを公開しやすくなる。ネットワークサービスティアは、より高品質なネットワーク経路を提供する「Premium」を選択することが多い。

すべての設定を確認し、ロードバランサーを作成すると、GCPは必要なリソースを自動的にプロビジョニングする。ロードバランサーが完全に機能するまでには、通常3～5分程度の時間がかかる。この待機時間の後、作成されたロードバランサーの外部IPアドレス（LB-IP）をWebブラウザに入力することで、設定したアプリケーションにアクセスできるか検証する。複数のバックエンドサーバーがある場合、リロードするたびに異なるサーバーからの応答が見られることで、負荷分散が正しく機能していることを確認できる。

検証が終わった後、不要なコスト発生を防ぐため、作成したロードバランサーは削除することが推奨される。ただし、ヘルスチェックなどの共有リソースは、他のロードバランサーで再利用する可能性があるため、削除せずに残す場合もある。このように、GCPのリージョナル外部ネットワークロードバランサー（TCPプロキシ）は、アプリケーションの信頼性とパフォーマンスを向上させるために、ネットワーク、セキュリティ、ヘルスチェック、インスタンス管理といった複数の要素を組み合わせて構築される重要なインフラストラクチャ技術なのである。