この記事は約13分で読めます。
- ● 本番環境を想定した、Google Cloudでのスケーラブルなインフラ設計の基本がわかります
- ● マネージドインスタンスグループ（MIG）を用いたオートスケールの設定手順が把握できます
- ● Cloud Load Balancingを利用したグローバルな負荷分散の構築プロセスを実際の画面を交えて解説します
- ● インフラ運用におけるコスト最適化やセキュリティ強化、つまずきやすいエラーの解消方法がわかります
エンタープライズ規模のWebサービスやミッションクリティカルなシステムにおいて、単一障害点（SPOF）を排除した高可用性アーキテクチャの構築は、インフラエンジニアやシステム開発者にとって必須のスキルです。
Google Cloudにおいてこの要件を満たす強力なコンポーネントが、「Cloud Load Balancing」と「マネージドインスタンスグループ（MIG）」の組み合わせです。本記事では、開発者・インフラ担当者向けに、トラフィックの増減に自動で追従するスケーラブルなWebサーバー基盤の構築手順を、実際のシステム画面を交えながら実践的に解説します。
なぜGoogle CloudのLoad Balancingなのか？
他社クラウド（AWSのALBやAzureのLoad Balancerなど）と比較した際、Google Cloudの「Cloud Load Balancing」には、アーキテクチャの根幹に関わる大きな優位性が存在します。
エニーキャストIPによるグローバルな負荷分散
Google Cloudの外部HTTP(S)ロードバランサーは、特定のリージョン（地域）に依存しないグローバルなリソースとして機能します。単一の「エニーキャストIPアドレス」を世界中のユーザーに提供し、ユーザーのリクエストは最寄りのGoogleエッジノードで受け付けられます。そこからGoogle独自の高速なプレミアムネットワーク網（Premium Tier）を経由して、最も応答の早いバックエンドのインスタンスへルーティングされるため、極めて低遅延な通信が実現します。
ウォームアップ（プレウォーミング）が不要
従来のクラウドロードバランサーでは、突発的なスパイクアクセス（急激なトラフィック増）が予想される場合、事前にベンダーへ申請してロードバランサー自体をスケールアップさせる「プレウォーミング」が必要なケースがありました。 しかし、Google Cloud Load Balancingは「Andromeda」と呼ばれるソフトウェア定義ネットワーク（SDN）上で稼働しており、数百万リクエスト/秒の急激なスパイクに対しても、事前のウォームアップなしで即座にトラフィックをさばくことが可能です。
マネージドインスタンスグループ（MIG）の強み
ロードバランサーの背後で実稼働するサーバー群を管理するのがMIGです。単なるサーバーの集合体ではなく、以下のような高度な管理機能を備えています。
- ● オートスケーリング： CPU使用率、HTTPロードランシングの処理能力、あるいはCloud Monitoringのカスタム指標（Pub/Subのキュー長など）に基づいて、インスタンス数を自動で増減させます。
- ● 自動修復（オートヒーリング）： アプリケーションがフリーズした際、ロードバランサーのヘルスチェックとは独立してMIG自体が異常を検知し、問題のあるインスタンスを自動的に再作成します。
- ● マルチゾーン展開： 単一のMIGを複数のゾーン（例：asia-northeast1-a, b, c）にまたがって展開できるため、データセンター単位の障害に対する耐障害性を簡単に高めることができます。
構成図と前提条件
本チュートリアルでは、以下の構成で高可用性インフラを構築します。
- ● フロントエンド： 外部HTTP(S)ロードバランサー（ポート80でリクエストを待ち受け）
- ● バックエンド： 東京リージョン（asia-northeast1）の複数のゾーンにまたがるMIG
- ● オートスケール条件： CPU使用率が60%を超えた場合に自動でスケールアウト
※前提として、Google Cloudプロジェクトが作成済みであり、課金とCompute Engine APIが有効化されている状態で進めます。
【実践手順】GCEインスタンスグループとロードバランサーの構築
1. ヘルスチェック用ファイアウォールルールの作成
ロードバランサーがバックエンドの正常性を確認（ヘルスチェック）できるように、Googleのプローバー（監視サーバー）からの通信を許可する必要があります。
ナビゲーションメニューから [VPC ネットワーク] > [ファイアウォール] へ移動し、[ファイアウォール ルールを作成]をクリックします。
以下の設定を入力します。
- ● 名前：
allow-lb-healthcheck - ● ターゲットタグ：
http-server（後でインスタンスに付与します） - ● 送信元IPv4範囲：
130.211.0.0/22および35.191.0.0/16（※これはGoogle Cloudのロードバランサーが使用する固定のIP範囲です） - ● プロトコルとポート：
tcp: 80
最後に最下部の[作成]をクリックします。
この「特定のIP帯からの許可」を正確に行うことは、セキュリティと可用性を両立させるための重要なポイントです。
2. インスタンステンプレートの作成
オートスケールで自動生成される仮想マシンの「設計図」を作成します。
[Compute Engine] > [インスタンステンプレート] へ移動し、[インスタンステンプレートを作成]をクリックします。
場所：asia-northeast1 (東京)を選択します。
マシン構成： 検証用として汎用的な e2-micro または e2-medium を選択します。
ブートディスク： Debian Linuxを選択します。
ネットワークタグ： 画面下部の[詳細オプション]を開き、先ほど作成したファイアウォールルールを適用するため、[http-server]と入力します。
詳細オプション（起動スクリプト）： [管理]タブを開き、[起動スクリプト] に以下のシェルスクリプトを入力します。
#!/bin/bash
apt-get update
apt-get install -y apache2
systemctl start apache2
systemctl enable apache2
echo "<h1>Hello from Google Cloud!</h1><p>Hostname: $(hostname)</p>" > /var/www/html/index.html
設定が完了したら[作成]ボタンを押して保存します。
3. マネージドインスタンスグループ（MIG）の構成
設計図をもとに、実稼働するサーバーのグループを作成します。
[Compute Engine] > [インスタンスグループ] から[インスタンスグループを作成]をクリックします。
名前： グループ名（例：web-mig）を入力します。
ロケーション：[マルチゾーン（推奨）]を選択し、リージョンを [asia-northeast1（東京）]に設定します。
インスタンステンプレート： 先ほど作成したインスタンステンプレートを選択します。
自動スケーリング：[自動スケーリングを構成]をクリックします。
オートスケーリングの設定：最小インスタンス数 2
最大インスタンス数 5
[Undefined parameter – Summary （デフォルト）]をクリックします。
[CPU使用率]を選択し、ターゲットを 60% に設定し、右下の完了をクリックします。
自動修復（ヘルスチェック）： [ヘルスチェック]をクリックします。
[ヘルスチェックを作成]をクリック
以下を入力し、画面右下の保存をクリックします。
名前：web-hc （など、適当な名前を入力）
プロトコル： HTTP
ポート： 80
設定後、[作成]をクリックすると、最小構成である2台のインスタンスが別々のゾーンに自動的に立ち上がります。
4. Cloud Load Balancingのセットアップ
最後に、ユーザーからのアクセスを受け付けるロードバランサーを構築します。
画面上部の検索窓に[ロードバランシング]と入力します。
[ロードバランシング] をクリックします。
[ロードバランサーを作成]をクリックします。
[アプリケーション ロードバランサ（HTTP/HTTPS）]を選択します。
[インターネット接続（外部）]のグローバルロードバランサを選択します。
[グローバル ワークロードに最適]を選択します。
[グローバル外部アプリケーション ロードバランサ]を選択します。
[構成]をクリックします。
以下を入力します。
ロードバランサの名前：web-lb
下記を設定して、[完了]をクリック
名前：web-fe
プロトコル：HTTP（※本番環境ではGoogleマネージドSSL証明書を発行し、HTTPSとするのが標準です）
ポート：80
[バックエンドの構成]をクリックします。
バックエンドの構成：[バックエンド サービスとバックエンドパケット]をクリックします。
[バックエンドサービスを作成]をクリックします。
以下の設定を入力します。
名前：web-backend
バックエンドタイプ：インスタンスグループ
ヘルスチェック：web-hc
下記を入力して画面右下[作成]をクリック
新しいバックエンド：インスタンスグループ web-mig
番号を移行する 80
数分待機してロードバランサーのプロビジョニングが完了するのを待ちます。
画面中部の[フロントエンド]に記載されている住所(IPアドレス)をコピーして、新しいタブのURLバーへ貼付します。
フロントエンドIPアドレス（例：34.120.xxx.xxx）が発行されたら、ブラウザでアクセスします。 表示された Hostname がリロードのたびに切り替われば、正常にトラフィックが分散されています。
セキュリティ強化と運用時のコスト最適化
エンタープライズの運用では、構築して終わりではなく、セキュリティとコストの最適化が求められます。
Cloud Armor（WAF）によるDDoS対策
外部公開されたロードバランサーは、常に攻撃の脅威にさらされます。Google Cloudでは、ロードバランサーのバックエンド設定画面からワンクリックで「Cloud Armor」のセキュリティポリシーを適用できます。これにより、SQLインジェクションやクロスサイトスクリプティング（XSS）、大規模なL7 DDoS攻撃からWebアプリケーションを強固に保護することが可能です。
確約利用割引（CUD）とCloud CDNの活用
ベースラインとして常に稼働し続けるインスタンス（今回の例では最小2台）に対しては、1年間または3年間の「確約利用割引（CUD）」を適用することでコンピュートコストを大幅に削減できます。 また、画像やCSSなどの静的アセットが多い場合、ロードバランサーの設定で「Cloud CDN」を有効化すると、Googleのエッジサーバーからキャッシュが配信されます。これにより、オリジンサーバー（MIG）の負荷が下がるだけでなく、高額になりがちな下りネットワーク転送料金も劇的に削減できます。
よくあるつまずきポイントと解決策
実運用に向けた検証時によく発生するエラーとその対処法を紹介します。
1. ロードバランサーにアクセスすると「502 Bad Gateway」になる
構築直後にもっとも多いエラーです。ロードバランサーがバックエンドを「Healthy（正常）」と認識するまでには数分かかります。コンソール上で緑色のチェックマークが付くまで待機してください。 それでも解決しない場合、ステップ1で設定した「ヘルスチェック用ファイアウォールルール（130.211.0.0/22 等）」が正しくインスタンスに適用されていない（ネットワークタグの指定漏れなど）可能性が高いです。
2. 古いコンテンツが表示され続ける（CDN有効時）
Cloud CDNを有効にしている場合、MIG内のファイルを更新しても、エッジにキャッシュが残っているため即座には反映されません。即時更新が必要な場合は、コンソールからCloud CDNの「キャッシュ無効化（Invalidation）」を実行し、対象パスのキャッシュを手動でパージする必要があります。
まとめ
本記事では、Google CloudのCompute EngineとCloud Load Balancingを活用した、高可用性かつスケーラブルなインフラの構築手順を解説しました。
- ● Cloud Load Balancingによる、事前ウォームアップ不要のグローバル負荷分散。
- ● マネージドインスタンスグループ（MIG）による、トラフィックに応じた柔軟なオートスケールと自己回復。
- ● Cloud ArmorやCDNとのシームレスな統合によるセキュリティとコストの最適化。
これらのコンポーネントを組み合わせることで、エンタープライズの厳しいSLAを満たす堅牢なバックエンドを、クラウドならではのスピード感で構築できます。オンプレミス環境からの移行や、大規模Webサービスの立ち上げを検討されている方は、ぜひ本記事の手順を参考にPoC（概念実証）を進めてみてください。
クラウド環境のアーキテクチャ設計や、より高度なインフラ構築・運用をご検討の際は、豊富な実績を持つ株式会社ジードへお気軽にお問い合わせください。
お客様が運営するクラウドの監視・保守・運用業務を、ジードが代行いたします。
お客様のご要望に沿って、適切なクラウド選定から設計・構築までを行います。
Azure上で、AI ＋ 機械学習、分析、ブロックチェーン、IoTを開発します。