このページは Cloud Translation API によって翻訳されました。

高可用性アプリケーションでのロードバランシングの使用

このチュートリアルでは、リージョンマネージドインスタンスグループとロードバランシングを使用して、ビジーまたは使用不能でない VM インスタンスにトラフィックをリダイレクトし、ゾーンが停止しても高可用性を確保する方法を説明します。

リージョンマネージドインスタンスグループは、複数のゾーンにまたがる複数のインスタンスにアプリケーションを分散します。グローバルロードバランサは、単一の IP アドレスを介して複数のリージョンにトラフィックを配信します。これらのサービスの両方を使用してアプリケーションを複数のゾーンに分散することにより、ゾーンの障害のような極端なケースでも、アプリケーションの可用性を確保できます。

ロードバランサは、さまざまな種類のトラフィックの配信に使用できます。このチュートリアルでは、外部 HTTP トラフィックを配信するグローバルロードバランサの作成方法について説明しますが、このチュートリアルの内容の大部分は他の種類のロードバランサにも該当します。ロードバランサで配信できる他の種類のトラフィックについては、Cloud Load Balancing の種類をご覧ください。

このチュートリアルでは、リージョンマネージドインスタンスグループでウェブアプリケーションを起動して、ネットワークアクセスを構成します。つづいて、トラフィックをウェブアプリケーションに配信するロードバランサを作成し、ゾーンの停止をシミュレートしてロードバランサを観察する詳細な手順を示します。これらの機能の使用経験にもよりますが、このチュートリアルを完了するには約 45 分かかります。

アプリケーションアーキテクチャ

アプリケーションには、次の Compute Engine コンポーネントが含まれています。

VPC ネットワーク: Google Cloud 内の仮想ネットワーク。独自のルートとファイアウォールルールを使用してグローバル接続を提供します。
ファイアウォールルール: Google Cloudファイアウォールにより、インスタンスへのトラフィックを許可または拒否できます。
インスタンステンプレート: マネージドインスタンスグループに個々の VM インスタンスを作成するために使用されるテンプレート。
リージョンマネージドインスタンスグループ: 複数のゾーンで同じアプリケーションを実行する VM インスタンスのグループ。
グローバル静的外部 IP アドレス: 外部ネットワークでアクセス可能な、グローバルリソースに接続できる静的 IP アドレス。
グローバルロードバランサ: バックエンドインスタンスを複数のリージョンに分配できるようにするロードバランサ。ユーザーが同じアプリケーションやコンテンツにアクセスする必要がある状況で、1 つのエニーキャスト IP アドレスでアクセス権を付与する場合は、グローバルロードバランサを使用します。
ヘルスチェック: 個々の VM インスタンス上のアプリケーションの応答性を評価するためにロードバランサが使用するポリシー。

ウェブアプリケーションを起動する

このチュートリアルでは、GitHub に保存されているウェブアプリケーションを使用します。アプリケーションの実装方法の詳細については、GoogleCloudPlatform/python-docs-samples GitHub リポジトリをご覧ください。

インスタンステンプレートに起動スクリプトを含めることで、インスタンスグループ内のすべての VM でウェブアプリケーションを起動します。さらに、このチュートリアルのファイアウォールルールがプロジェクトで実行されている既存のリソースに影響するのを避けるため、専用の VPC ネットワークでインスタンスグループを実行します。

VPC ネットワークの作成

VPC ネットワークを使用すると、プロジェクト内の既存のリソースが、このチュートリアル用に作成するリソースの影響を受けないように保護されます。VPC ネットワークは、ロードバランサを経由するように着信トラフィックを制限するためにも必要です。

VPC ネットワークを作成して、デモウェブアプリケーション用のファイアウォールルールをカプセル化するには、次の操作を行います。

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
[名前] に「web-app-vpc」と入力します。
[サブネット作成モード] を [カスタム] に設定します。
次の手順で新しいサブネットを作成します。
1. [サブネット] セクションで、[名前] フィールドに「web-app-vpc-subnet」と入力します。
2. [リージョン] プルダウンで、[us-central1] を選択します。
3. [IP スタックタイプ] オプションが [IPv4] に設定されていることを確認します。
4. [プライマリ IPv4 範囲] セクションに、IPv4 範囲「10.2.0.0/24」を入力します。
ページの下部にある [作成] をクリックします。

VPC ネットワークが作成されるまで待ってから続行します。

ファイアウォールルールを作成する

VPC ネットワークの作成が完了したら、VPC ネットワークへの HTTP トラフィックを許可するファイアウォールルールを設定します。

Google Cloud コンソールで、[ファイアウォール] ページに移動します。

[ファイアウォール] に移動
[ファイアウォールルールを作成] をクリックします。
[名前] フィールドに「allow-web-app-http」と入力します。
[ネットワーク] を web-app-vpc に設定します。
次のオプションが以下のように設定されていることを確認します。
- [トラフィックの方向] オプションが [上り（内向き）] に設定されている。
- [一致したときのアクション] オプションが [許可] に設定されている。
[ターゲット] プルダウンで、[ネットワーク上のすべてのインスタンス] を選択します。
[送信元フィルタ] を IPv4 ranges に設定します。
[送信元 IP 範囲] フィールドに「130.211.0.0/22, 35.191.0.0/16」と入力して、ロードバランサのヘルスチェックを許可します。

注: ロードバランサのヘルスチェックプローブは、130.211.0.0/22～35.191.0.0/16 の範囲のアドレスから発信されます。このチュートリアルでは、ヘルスチェックで HTTP プロトコルを使用しているため、ファイアウォールルールでポート 80 への接続を許可する必要があります。ヘルスチェックのファイアウォールルールの詳細については、プローブ IP 範囲とファイアウォールルールをご覧ください。
[プロトコルとポート] で、次の操作を行います。
1. 指定したプロトコルとポートを選択します。
2. [TCP] を選択します。
3. [ポート] フィールドに「80」と入力して、HTTP トラフィックのアクセスを許可します。
[作成] をクリックします。

インスタンステンプレートを作成する

VM インスタンスのグループの作成に使用するテンプレートを作成します。テンプレートから作成された各インスタンスは、起動スクリプトを使用してデモ用ウェブアプリケーションを起動します。

Google Cloud コンソールで、[インスタンステンプレート] ページに移動します。

[インスタンステンプレート] に移動
[インスタンステンプレートを作成] をクリックします。
[名前] に「load-balancing-web-app-template」と入力します。
[マシンの構成] で、[マシンタイプ] を e2-medium に設定します。
[詳細オプション] セクションをクリックして開きます。
[ネットワーキング] セクションをクリックして、次の操作を行います。
1. [ネットワークインターフェース] セクションで、既存のネットワークインターフェースの横にあるアイコンをクリックして、既存のネットワークインターフェースを削除します。
2. [ネットワークインターフェースを追加] をクリックしてから、web-app-vpc ネットワークを選択します。これで、このテンプレートで作成された各インスタンスが、前のステップで作成したネットワークで必ず実行されるようになります。
3. [サブネットワーク] プルダウンで、web-app-vpc-subnet を選択します。
4. [完了] をクリックします。

[管理] セクションをクリックして、次の操作を行います。

[自動化] セクションで、次の起動スクリプトを入力します。

apt-get update
apt-get -y install git python3-pip python3-venv
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
python3 -m venv venv
./venv/bin/pip3 install -Ur ./python-docs-samples/compute/managed-instances/demo/requirements.txt
./venv/bin/pip3 install gunicorn
./venv/bin/gunicorn --bind 0.0.0.0:80 app:app --daemon --chdir ./python-docs-samples/compute/managed-instances/demo

このスクリプトは、VM インスタンスの起動時にウェブアプリケーションを取得し、インストールして起動します。

他のオプションはデフォルト値をそのまま使用します。
[作成] をクリックします。

テンプレートが作成されるまで待ってから続行します。

リージョンマネージドインスタンスグループを作成する

インスタンステンプレートを使用してリージョンマネージドインスタンスグループを作成し、ウェブアプリケーションを実行します。

Google Cloud コンソールで、[インスタンスグループ] ページに移動します。

[インスタンスグループ] に移動
[インスタンスグループを作成] をクリックします。
[名前] に「load-balancing-web-app-group」と入力します。
[インスタンステンプレート] で [load-balancing-web-app-template] を選択します。
[インスタンス数] を「6」に設定します。このフィールドが無効になっている場合は、まず自動スケーリングをオフにします。

自動スケーリングをオフにするには、[自動スケーリング] セクションに移動します。[自動スケーリングモード] プルダウンで、[オフ: 自動スケーリングを行いません] を選択します。

上級者向けのヒント: リージョンマネージドインスタンスグループを作成する際に、Compute Engine で十分な数のインスタンスをプロビジョニングすることで、あるゾーンのすべてのインスタンスが使用できなくなっても、残りのインスタンスが必要最小限のインスタンス数を満たすようにすることをおすすめします。ただし、必要以上にインスタンスをプロビジョニングすると、余分な費用が発生する可能性があります。詳細については、オーバープロビジョニングで可用性を向上させる方法をご覧ください。
[ロケーション] で [マルチゾーン] を選択します。

ヒント: ゾーンの停止などの極端なケースでもアプリケーションの可用性を確保するため、Compute Engine のアプリケーションを複数のゾーンに分散することをおすすめします。
[リージョン] で、[us-central1] を選択します。
[ゾーン] で、プルダウンリストから次のゾーンを選択します。
- us-central1-b
- us-central1-c
- us-central1-f
他のオプションはデフォルト値をそのまま使用します。
[作成] をクリックします。[インスタンスグループ] ページにリダイレクトされます。

グループ内のすべてのインスタンスが実行されるまで、数分かかることがあります。

ロードバランサを構成する

ロードバランサを使用してトラフィックをウェブアプリケーションに配信するには、すべての着信トラフィックを受信するために外部 IP アドレスを予約する必要があります。次に、その IP アドレスからのトラフィックを受け入れてインスタンスグループにリダイレクトするロードバランサを作成します。

静的 IP アドレスを予約する

グローバル静的外部 IP アドレスを使用して、すべてのユーザートラフィックを受信する単一のエントリポイントをロードバランサのために用意します。関連付けられた Google Cloud リソースを変更、削除しても、Compute Engine は静的 IP アドレスを保持します。したがって、ウェブアプリケーションの他の部分が変更されても、ウェブアプリケーションは常に同じエントリポイントを持つことができます。

Google Cloud コンソールで、[IP アドレス] ページに移動します。

[IP アドレス] に移動
[静的外部 IP アドレスを予約] をクリックします。
[名前] フィールドに「web-app-ipv4」と入力します。
[IP バージョン] を IPv4 に設定します。
[タイプ] を [グローバル] に設定します。
[予約] をクリックします。

ロードバランサを作成する

このセクションでは、HTTP トラフィックを配信するグローバルロードバランサを作成するために必要な手順について説明します。

このロードバランサは、フロントエンドを使用して着信トラフィックを受信し、バックエンドを使用してこのトラフィックを正常なインスタンスに分散します。ロードバランサは複数のコンポーネントで構成されるため、ロードバランサを作成するタスクは以下の 5 つのステップに分かれます。

ロードバランサの種類を選択する
ロードバランサの名前を付ける
フロントエンドを構成する
バックエンドを構成する
確認して完了する

ロードバランサを作成するには、上記のステップをすべて完了します。

ロードバランサの種類を選択する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
[ロードバランサの種類] で [アプリケーションロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
[インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
[グローバルまたはシングルリージョンのデプロイ] で [グローバルワークロードに最適] を選択し、[次へ] をクリックします。
[ロードバランサの世代] で [グローバル外部アプリケーションロードバランサ] を選択し、[次へ] をクリックします。
[構成] をクリックします。

ロードバランサの名前を付ける

左側のパネルの [ロードバランサの名前] に「web-app-load-balancer」と入力します。

フロントエンドを構成する

[フロントエンドの構成] ページで、[名前] に「web-app-ipv4-frontend」と入力します。
[プロトコル] を HTTP に設定します。
[IP バージョン] を IPv4 に設定します。
[IP アドレス] を web-app-ipv4 に設定します。
[ポート] を 80 に設定します。
[完了] をクリックすると、フロントエンドが作成されます。

バックエンドを構成する

左側のパネルで、[バックエンドの構成] をクリックします。
[バックエンドサービスとバックエンドバケット] プルダウンをクリックしてメニューを開いてから、[バックエンドサービスを作成] をクリックします。
新しいウィンドウで、バックエンドサービスの [名前] に「web-app-backend」と入力します。
[バックエンド] セクションで、次の操作を行います。
1. [インスタンスグループ] を load-balancing-web-app-group に設定します。
2. [ポート番号] を 80 に設定します。これにより、ロードバランサとインスタンスグループ間の HTTP トラフィックを許可することができます。
3. [分散モード] で、[使用率] を選択します。
4. [完了] をクリックします。
ロードバランサのバックエンドのヘルスチェックを次のように作成します。
上級者向けのヒント: ヘルスチェックはロードバランシングと自動修復の両方で使用されますが、目的は異なります。
- ロードバランシングのヘルスチェックは、応答しないインスタンスを検出してトラフィックの配信先から除外するために使用されます。
- 自動修復のヘルスチェックは、失敗したインスタンスの検出と再作成に使用されます。
ロードバランシングと自動修復には、別々のヘルスチェックを使用します。これらのサービスに同じヘルスチェックを使用すると、応答しないインスタンスと失敗したインスタンスが区別できなくなり、ユーザーに余計なレイテンシや使用不能といった不便を強いることになります。詳細については、ヘルスチェックのコンセプトをご覧ください。
1. [ヘルスチェック] プルダウンをクリックしてから、[ヘルスチェックを作成] をクリックします。新しいウィンドウが開きます。
2. 新しいウィンドウで、[名前] に「web-app-load-balancer-check」と入力します。
3. [プロトコル] を HTTP に設定します。
4. [ポート] に「80」と入力します。
5. このチュートリアルでは、[リクエストパス] を /health に設定します。これは、デモウェブアプリケーションが応答するように設定されているパスです。
6. ヘルス条件を次のように設定します。
  1. [チェック間隔] を 3 秒に設定します。これは、プローブを開始してから次のブローブを開始するまでの時間です。
  2. [タイムアウト] を 3 秒に設定します。これは、 Google Cloud でプローブに対するレスポンスを待ち受ける時間です。この値は、チェック間隔で設定した数値以下にする必要があります。
  3. [正常しきい値] を [2 回連続して成功] に設定します。これは、プローブが連続で成功するとインスタンスが正常であると判断される回数です。
  4. [異常しきい値] を [2 回連続して失敗] に設定します。これは、プローブが連続で失敗するとインスタンスに異常があると判断される回数です。
  上級者向けのヒント: アプリケーションのチェック間隔とタイムアウトの値の調整方法については、ヘルスチェックの仕組みをご覧ください。レイテンシの最適化と測定の詳細については、ロードバランシングによるアプリケーションレイテンシの最適化をご覧ください。
7. [作成] をクリックしてヘルスチェックを作成します。
他のオプションはデフォルト値をそのまま使用します。
[作成] をクリックすると、バックエンドサービスが作成されます。

確認して完了する

ロードバランサを作成する前に、負荷分散設定を確認します。

[グローバル外部アプリケーションロードバランサを作成] ページの左パネルで、[確認と完了] をクリックします。
[確認と完了] ページで、[フロントエンド] が使用する IP アドレスの [プロトコル] が HTTP になっていることを確認します。
同じページで、[バックエンド] が次のように設定されていることを確認します。
- [バックエンドサービス] が web-app-backend。
- [エンドポイントプロトコル] が HTTP。
- [ヘルスチェック] が web-app-load-balancer-check。
- [インスタンスグループ] が load-balancing-web-app-group。
[作成] をクリックして、ロードバランサの作成を完了します。

ロードバランサの作成が完了するまで数分かかることがあります。

ロードバランサをテストする

次の手順で、ロードバランサを使用してウェブアプリケーションに接続できることを確認します。

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[名前] 列で web-app-load-balancer をクリックし、作成したロードバランサを開きます。
外部静的 IP アドレスを使用してウェブアプリに接続するには、次の操作を行います。
1. [フロントエンド] セクションで、[IP:ポート] 列に表示されている IP アドレスをコピーします。
2. 新しいブラウザタブを開き、IP アドレスをアドレスバーに貼り付けます。次のように、デモ用ウェブアプリケーションが表示されます。
ページを更新するたびに、ロードバランサが異なるゾーンの異なるインスタンスに接続することに注意してください。これは、インスタンスに直接接続していないためです。接続しているのはロードバランサであり、ロードバランサによってリダイレクト先のインスタンスが選択されます。

確認が終わったら、デモ用ウェブアプリケーションのブラウザタブを閉じます。

ゾーンの停止をシミュレートする

ゾーンの停止による広範囲の使用不能状態をシミュレートすることにより、ロードバランサの機能を観察できます。このシミュレーションを実行するには、指定したゾーンに存在するすべてのインスタンスに、/health リクエストパスの異常ステータスを強制的に報告させます。これらのインスタンスが異常ステータスを報告すると、ロードバランシングのヘルスチェックが失敗し、ロードバランサはそれらのインスタンスへのトラフィックの配信を停止するよう促されます。

ロードバランサがトラフィックを配信しているゾーンをモニタリングします。
1. Google Cloud コンソールで [Cloud Shell] に移動します。
  
  Cloud Shell を開く
  
  Google Cloud コンソールのペインで Cloud Shell が開きます。セッションの初期化に数秒かかることがあります。
  
  上級者向けのヒント: [ Cloud Shell をアクティブにする] ボタンを使用すると、 Google Cloud コンソールのどのページからでも Cloud Shell を開くことができます。
2. ロードバランサの静的外部 IP アドレスを次の手順で保存します。
  1. ターミナルで次のコマンドを入力して、ロードバランサのフロントエンド転送ルールから外部 IP アドレスを取得します。
```
gcloud compute forwarding-rules describe web-app-ipv4-frontend --global
```
    出力は次のようになります。出力から EXTERNAl_IP_ADDRESS をコピーします。
```
IPAddress: EXTERNAl_IP_ADDRESS
...
```
  2. ローカル bash 変数を作成します。
```
export LOAD_BALANCER_IP=EXTERNAl_IP_ADDRESS
```
    EXTERNAl_IP_ADDRESS は、コピーした外部 IP アドレスに置き換えます。
3. ロードバランサがトラフィックを配信しているゾーンをモニタリングするには、次の bash スクリプトを実行します。
```
while true
do
    BODY=$(curl -s "$LOAD_BALANCER_IP")
    NAME=$(echo -n "$BODY" | grep "load-balancing-web-app-group" | perl -pe 's/.+?load-balancing-web-app-group-(.+?)<.+/\1/')
    ZONE=$(echo -n "$BODY" | grep "us-" | perl -pe 's/.+?(us-.+?)<.+/\1/')
    echo $ZONE
    sleep 2 # Wait for 2 seconds
done
```
  このスクリプトは、ロードバランサのフロントエンドの IP アドレスを使用してウェブアプリケーションへの接続を継続的に試行し、接続ごとにウェブアプリケーションが実行されているゾーンを出力します。
  
  結果の出力には、us-central1-b、us-central1-c、us-central1-f のゾーンが含まれます。
```
us-central1-f
us-central1-b
us-central1-c
us-central1-f
us-central1-f
us-central1-c
us-central1-f
us-central1-c
us-central1-c
```
  このターミナルは開いたままにしておきます。
  
  注: このモニタリングは継続的に実行されます。ただし、ターミナルで Control+C を押せば、いつでも停止できます。
モニタリングの実行中に、ゾーン停止のシミュレーションを開始します。
1. Cloud Shell で、 [追加] ボタンをクリックして、2 番目のターミナルセッションを開きます。
2. プロジェクト ID のローカル bash 変数を作成します。
```
export PROJECT_ID=PROJECT_ID
```
  ここで、PROJECT_ID は、現在のプロジェクトのプロジェクト ID です。この値は Cloud Shell のすべての新しい行に表示されます。
```
user@cloudshell:~ (PROJECT_ID)$
```
3. 無効にするゾーンのローカル bash 変数を作成します。ゾーン us-central1-f の障害をシミュレートするには、次のコマンドを使用します。
```
export DISABLE_ZONE=us-central1-f
```
  次に、以下の bash スクリプトを実行します。このスクリプトにより、使用不能になったゾーンのデモウェブアプリケーションインスタンスは、ロードバランサのヘルスチェックに対して異常レスポンスを出力します。異常レスポンスにより、ロードバランサはこれらのインスタンスへのトラフィックの配信を停止します。
```
export MACHINES=$(gcloud --project=$PROJECT_ID compute instances list --filter="zone:($DISABLE_ZONE)" --format="csv(name,networkInterfaces[0].accessConfigs[0].natIP)" | grep "load-balancing-web-app-group")
for i in $MACHINES;
do
  NAME=$(echo "$i" | cut -f1 -d,)
  IP=$(echo "$i" | cut -f2 -d,)
  echo "Simulating zonal failure for zone $DISABLE_ZONE, instance $NAME"
  curl -q -s "http://$IP/makeUnhealthy" >/dev/null --retry 2
done
```
  その少し後で、ロードバランサは異常が発生したゾーンへのトラフィックの配信を停止します。そのため、最初のターミナルウィンドウでは、ゾーン us-central1-f が出力リストに表示されなくなります。
```
us-central1-c
us-central1-c
us-central1-c
us-central1-b
us-central1-b
us-central1-c
us-central1-b
us-central1-c
us-central1-c
```
  これは、ロードバランサが、正常でかつ応答しているインスタンスにのみトラフィックを配信していることを示します。
  注: この手順を繰り返せば、ゾーン us-central1-b と us-central1-c の障害もシミュレートできます。
  
  両方のターミナルを開いたままにしておきます。
4. 第 2 のターミナルで、復元するゾーンのローカル bash 変数を作成します。ゾーン us-central1-f へのトラフィックを復元するには、次のコマンドを使用します。
```
export ENABLE_ZONE=us-central1-f
```
  次に、以下の bash スクリプトを実行します。このスクリプトにより、使用可能になったゾーンのデモウェブアプリケーションインスタンスは、ロードバランサのヘルスチェックに対して正常レスポンスを出力します。正常レスポンスにより、ロードバランサはこれらのインスタンスへのトラフィックの配信を再開します。
```
export MACHINES=$(gcloud --project=$PROJECT_ID compute instances list --filter="zone:($ENABLE_ZONE)" --format="csv(name,networkInterfaces[0].accessConfigs[0].natIP)" | grep "load-balancing-web-app-group")
for i in $MACHINES;
do
  NAME=$(echo "$i" | cut -f1 -d,)
  IP=$(echo "$i" | cut -f2 -d,)
  echo "Simulating zonal restoration for zone $ENABLE_ZONE, instance $NAME"
  curl -q -s "http://$IP/makeHealthy" >/dev/null --retry 2
done
```
  数分で、1 つ目のターミナルウィンドウの出力リストにゾーン us-central1-f が表示される回数が徐々に増えていきます。
```
us-central1-b
us-central1-b
us-central1-c
us-central1-f
us-central1-c
us-central1-c
us-central1-b
us-central1-c
us-central1-f
```
  これは、ロードバランサが、元のように、すべてのゾーンに着信トラフィックを配信していることを示します。
  注: ゾーン us-central1-b やゾーン us-central1-c も使用不能にした場合は、この手順を繰り返してトラフィックの配信を元に戻すことができます。
  
  確認が終わったら、両方のターミナルを閉じます。