【ITニュース解説】Part-73: To Implement a Regional Internal Load balancer with HTTP in GCP Cloud
2025年09月21日に「Dev.to」が公開したITニュース「Part-73: To Implement a Regional Internal Load balancer with HTTP in GCP Cloud」について初心者にもわかりやすく解説しています。
ITニュース概要
GCPでリージョン内部HTTPロードバランサーの構築手順を解説。特定の地域内のVM間で負荷を分散し、アプリケーションの可用性を高める。プロキシ用サブネットやファイアウォール、ヘルスチェック、バックエンド・フロントエンドの設定方法を具体的に示す。内部システム間の効率的な通信と安定稼働を実現する。
ITニュース解説
システムエンジニアを目指す皆さんが、クラウド環境でWebアプリケーションを構築する際に非常に役立つ技術の一つに「ロードバランサー」があります。これは、たくさんのリクエストが集中したときに、サーバーへの負荷を複数のサーバーに分散させることで、Webサイトやサービスが安定して動き続けるようにする仕組みです。今回解説する記事では、Google Cloud Platform(GCP)というクラウドサービスを使って、「リージョン内部アプリケーションロードバランサー」をHTTP通信向けに実装する手順が詳しく紹介されている。
まず、ロードバランサーには大きく分けて二つの種類がある。「外部ロードバランサー」はインターネットからのアクセスをさばくのに対し、「内部ロードバランサー」はクラウド内のプライベートネットワークからアクセスされることを想定している。つまり、企業のシステム内で複数のアプリケーションが連携するような場面や、データベースへのアクセスを効率化したい場合などに利用される。また、「リージョン」というのは、GCPのデータセンターが世界中に分散している「地域」の単位を指す。例えば「us-central1」といった特定の地域内でロードバランサーが機能することを意味し、その地域内での安定性とパフォーマンス向上に貢献する。
このロードバランサーは、「アプリケーションロードバランサー」と呼ばれ、HTTPやHTTPSといったWeb通信に特化している。これにより、Webサーバーの負荷を均等に分散させたり、万が一一部のサーバーに障害が発生した場合でも、他の正常なサーバーに自動的にトラフィックを振り分けたりする役割を担う。
実装の最初のステップとして、ロードバランサーがトラフィックを転送する先のサーバー群、つまり「バックエンド」を準備する必要がある。記事では、あらかじめ作成済みの「インスタンステンプレート」と「マネージドインスタンスグループ(MIG)」を使用している。MIGは、仮想マシン(VM)を自動的に増減させたり、ヘルスチェックに基づいて不調なVMを自動で置き換えたりする機能を持つ、非常に便利なグループである。これにより、常に適切な数のVMが稼働し、安定したサービス提供が可能になる。
次に、ロードバランサーがスムーズに機能するためのネットワーク基盤を整える。「プロキシ専用サブネット」という特別なネットワーク領域を予約する。これは、ロードバランサー自身がユーザーからのリクエストを受け取り、バックエンドのVMへ転送する際に使用する「代理人」のための専用ネットワークである。この分離されたネットワークがあることで、ロードバランサーの処理が効率化され、セキュリティも向上する。
ネットワークを設定したら、今度は「ファイアウォールルール」を設定する。これは、ネットワーク上の通信を許可したり拒否したりする「門番」のような役割を果たす。具体的には、先ほど設定したプロキシ専用サブネットから、バックエンドのVM(MIGに含まれるVM)へのHTTP通信(ポート80や443、8080)を許可するルールを作成する。これにより、ロードバランサーがバックエンドのサーバーに正しくリクエストを届けられるようになる。
サーバーが正常に動作しているかを確認する仕組みも重要である。これが「リージョンヘルスチェック」である。ロードバランサーは定期的にバックエンドのVMに対してHTTPリクエストを送り、応答があるか、正常な応答コードが返ってくるかなどを確認する。もしVMが応答しなかったり、エラーを返したりした場合は、そのVMを一時的にトラフィックの対象から外し、問題が解決するまでリクエストを送らないようにする。これにより、ユーザーは常に正常に動作しているサーバーからの応答を受け取ることができる。
いよいよロードバランサー本体の作成である。GCPの管理画面から「ロードバランシング」サービスを選択し、「アプリケーションロードバランサー(HTTP/S)」を選び、「内部のみ」と「リージョン」という設定を明確に指定する。
ロードバランサーの設定は、大きく「バックエンド構成」「ルーティングルール」「フロントエンド構成」の三つに分かれる。 「バックエンド構成」では、ロードバランサーがトラフィックを転送する先のMIGを指定し、どのポートでWebサービスが動作しているかを定義する。また、先ほど作成したヘルスチェックをここで関連付ける。複数のMIGをバックエンドとして追加することで、より広範囲に負荷分散が可能である。 「ルーティングルール」は、どのようなリクエストをどのバックエンドに送るかを決めるものである。例えば、特定のURLパターンを持つリクエストを別のバックエンドに送るといった複雑な設定も可能だが、ここでは「シンプルなホストとパスルール」として、全てのトラフィックを一つのバックエンドサービスに送る設定が基本となる。 「フロントエンド構成」は、ロードバランサーへのアクセスポイントを設定する部分である。ロードバランサーに割り当てる「内部IPアドレス」を新しく作成し、どのサブネットのどのポートで待ち受けるかを指定する。このIPアドレスが、内部のクライアントVMがロードバランサーにアクセスするための窓口となる。記事では、この内部ロードバランサーに「グローバルアクセス」を有効にする設定も行っている。これにより、ロードバランサーが設置されているリージョンだけでなく、GCP内の他のリージョンにあるVMからもこの内部ロードバランサーにアクセスできるようになり、より柔軟なシステム設計が可能になる。
これらの設定を終えたら、実際にロードバランサーが正しく機能しているかを確認する「検証」ステップに進む。まず、ロードバランサーが完全に稼働するまで数分待つことが重要である。その後、同じリージョン内にあるVMから、ロードバランサーの内部IPアドレス宛にHTTPリクエスト(curlコマンドなど)を送信して、Webアプリケーションが応答するかを確認する。さらに、グローバルアクセスを有効にしている場合は、別のリージョンにテスト用のVMを作成し、そこからもロードバランサーの内部IPアドレスへアクセスを試みる。これにより、異なるリージョンからの接続が期待通りに動作するかを確認できる。
最後に、デモやテストのために作成したリソースは、不要になったら必ず「削除」することが推奨される。ロードバランサーやテスト用のVMなどを削除することで、GCPの利用料金が発生し続けるのを防ぎ、クラウド環境を整理しておくことができる。
このように、GCPのリージョン内部アプリケーションロードバランサーは、内部ネットワークにおけるWebアプリケーションの可用性とスケーラビリティを高めるための強力なツールである。各ステップで必要なネットワークやヘルスチェックなどの要素を適切に設定することで、堅牢で安定したシステムを構築することが可能になる。