読み込んでいます...
一致する結果は見つかりませんでした。

Google Cloud コンソールでスキルを試す

学習の進行状況が失われる可能性があります。進行状況を保存するには、ログインまたは参加してください。
close

02

Google Cloud Compute and Scalability for Azure Professionals

コース · 8時間
< 1%
完了
700 以上のラボとコースにアクセス

アプリケーション ロードバランサを構成して自動スケーリングを行う（Azure）

ラボ 2時間 universal_currency_alt クレジット: 5 show_chart 入門
info このラボでは、学習をサポートする AI ツールが組み込まれている場合があります。
700 以上のラボとコースにアクセス

あなたはネットワーキングのスペシャリストとして、仮想ネットワークで稼働している一連のウェブサーバー用の内部ロードバランサを実装するタスクを任されました。ウェブサーバーは大量のトラフィックを受信するため、トラフィックがサーバー間で均等に分散されるようにする必要があります。あなたはウェブ アプリケーション用にアプリケーション ロードバランサ（HTTP）と自動スケーリングの構成を担当しています。ウェブ アプリケーションでは 1 日のうち特定の時間帯に大量のトラフィックが発生しており、ダウンタイムなしでトラフィックを処理できるようにする必要があります。

Azure で HTTP ロードバランサと自動スケーリングを構成する手順は次のとおりです。

  1. 仮想マシン スケールセット（VMSS）を作成する
  2. 自動スケーリングを構成する: 需要に応じて VMSS 内の VM の数を自動的に増減できるようにします
  3. パブリック IP アドレスを作成する: パブリック IP アドレスからロードバランサにトラフィックをルーティングできるようにします
  4. Azure ロードバランサを作成する: トラフィックを送信する前に VM の正常性を確認するヘルスプローブを使用するようにロードバランサを構成します
  5. Azure ロードバランサと自動スケーリングを構成する: 必要に応じてロードバランサの数を自動的に増減するルールを定義します
  6. DNS レコードを構成する: バックエンド プールのパブリック IP アドレスを指すようにウェブ アプリケーションの DNS レコードを更新します

ネットワーク図 次に、高可用性とスケーラビリティを備えたソリューションの構築に役立つ、Google Cloud 内のさまざまなサービスについて確認します。

概要

アプリケーション ロード バランシング（HTTP/HTTPS）は、世界中の Google のポイント オブ プレゼンス（POP）で Google ネットワークのエッジに実装されています。アプリケーション ロードバランサ（HTTP/HTTPS）に向かうユーザー トラフィックは、ユーザーに最も近い POP に入った後、Google のグローバル ネットワークでロードバランスされて、十分な処理能力がある最も近いバックエンドに送られます。

このラボでは、次の図に示すようにアプリケーション ロードバランサ（HTTP）を構成します。さらに、ロードバランサのストレステストを実施して、グローバル ロード バランシングと自動スケーリングを実証します。

目標

このラボでは、次のタスクの実行方法について学びます。

  • ヘルスチェックのファイアウォール ルールを作成する
  • Cloud Router を使用して NAT 構成を作成する
  • ウェブサーバー用のカスタム イメージを作成する
  • カスタム イメージに基づいてインスタンス テンプレートを作成する
  • マネージド インスタンス グループを 2 つ作成する
  • IPv4 と IPv6 を使用してアプリケーション ロードバランサ（HTTP）を構成する
  • アプリケーション ロードバランサ（HTTP）のストレステストを実施する

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

  1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

    • [Google Cloud コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報（ある場合）

  2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

    ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

    ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

    注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

  3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

    {{{user_0.username | "Username"}}}

    [ラボの詳細] パネルでもユーザー名を確認できます。

  4. [次へ] をクリックします。

  5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

    {{{user_0.password | "Password"}}}

    [ラボの詳細] パネルでもパスワードを確認できます。

  6. [次へ] をクリックします。

    重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

  7. その後次のように進みます。

    • 利用規約に同意してください。
    • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
    • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックします。

タスク 1. ヘルスチェックのファイアウォール ルールを構成する

このタスクでは、インスタンスへのヘルスチェック トラフィックを許可するようにファイアウォール ルールを構成します。

ヘルスチェックでは、アプリケーション ロードバランサ（HTTP）のどのインスタンスが新しい接続を受け取れるかを確認します。ロード バランシング インスタンスへのヘルスチェック プローブは、範囲 130.211.0.0/22 と 35.191.0.0/16 のアドレスから送信されます。ファイアウォール ルールで、この接続を許可する必要があります。

ヘルスチェックのルールを作成する

ヘルスチェックを許可するファイアウォール ルールを作成します。

  1. Cloud コンソールのナビゲーション メニュー（）で、[VPC ネットワーク] > [ファイアウォール] をクリックします。
    ICMP、internal、RDP、SSH のファイアウォール ルールがすでにあります。

    各 Google Cloud プロジェクトには、default ネットワークとこれらのファイアウォール ルールが始めから用意されています。

  2. [ファイアウォール ルールを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 fw-allow-health-checks
    ネットワーク default
    ターゲット 指定されたターゲットタグ
    ターゲットタグ allow-health-checks
    ソースフィルタ IPv4 範囲
    送信元 IPv4 範囲 130.211.0.0/22 と 35.191.0.0/16
    プロトコルとポート 指定したプロトコルとポート
注: 送信元 IP 範囲に「/22」と「/16」が含まれていることを確認してください。
  1. [tcp] を選択し、ポート「80」を指定します。
  2. [作成] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ヘルスチェックのファイアウォール ルールを構成する

タスク 2. Cloud Router を使用して NAT 構成を作成する

このタスクでは、Cloud Router インスタンスを作成し、VM インスタンスのアウトバウンド インターネット接続を有効にするように Cloud NAT ゲートウェイを構成します。

タスク 3 で設定する Google Cloud VM バックエンド インスタンスには、外部 IP アドレスは構成されません。

代わりに Cloud NAT サービスを設定して、これらの VM インスタンスが Cloud NAT からのみ送信トラフィックを送信し、ロードバランサを介して受信トラフィックを受信するようにします。

Cloud Router インスタンスを作成する

  1. Google Cloud コンソールのタイトルバーにある検索フィールドに「ネットワーク サービス」と入力し、[ネットワーク管理ツール] セクションの [ネットワーク サービス] をクリックします。

  2. [ネットワーク サービス] ページで、[ネットワーク サービス] の横にある固定アイコンをクリックします。

  3. [Cloud NAT] をクリックします。

  4. [開始] をクリックして NAT ゲートウェイを構成します。

  5. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    ゲートウェイの名前 nat-config
    ネットワーク default
    リージョン

  6. [Cloud Router] をクリックし、[新しいルーターを作成] を選択します。

  7. [名前] に「nat-router-us1」と入力します。

  8. [作成] をクリックします。

  9. [Cloud NAT ゲートウェイの作成] で、[作成] をクリックします。

注: NAT ゲートウェイの [ステータス] が [実行中] に変わるまで待ってから、次のタスクに進みます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Cloud Router を使用して NAT 構成を作成する

タスク 3. ウェブサーバー用のカスタム イメージを作成する

このタスクでは、ロードバランサのバックエンド用のカスタム ウェブサーバー イメージを作成します。

VM を作成する

  1. Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [VM インスタンス] をクリックします。

  2. [インスタンスを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 webserver
    リージョン
    ゾーン

  4. [OS とストレージ]、[変更] の順にクリックします。

  5. [詳細構成を表示] をクリックします。

  6. [削除ルール] で [ブートディスクを保持] を選択します。

  7. [選択] をクリックします。

  8. [ネットワーキング] をクリックします。

    • [ネットワーク タグ] に「allow-health-checks」と入力します。
    • [ネットワーク インターフェース] で [デフォルト] をクリックします。
    • [外部 IPv4 アドレス] プルダウンで [なし] を選択します。

  9. [完了] をクリックします。

  10. [作成] をクリックします。

VM をカスタマイズする

  1. webserver の [SSH] をクリックし、ターミナルを起動して接続します。
  2. ブラウザでの SSH による VM への接続を許可するよう求めるプロンプトが表示されたら、[承認] をクリックします。
  3. 次のコマンドを実行して Apache2 をインストールします。
sudo apt-get update sudo apt-get install -y apache2
  1. 次のコマンドを実行して、Apache サーバーを起動します。
sudo service apache2 start
  1. 次のコマンドを実行して、Apache2 サーバーのデフォルトのページをテストします。
curl localhost

Apache2 サーバーのデフォルトのページが表示されます。

起動時に開始するよう Apache サービスを設定する

ソフトウェアは正常にインストールされましたが、このイメージを使用して新しい VM を作成しても、新しく起動した VM では Apache ウェブサーバーが実行されていません。起動時に自動的に開始するよう Apache サービスを設定するには、以下のコマンドを使用します。その後、設定が動作することをテストして確認します。

  1. webserver の SSH ターミナルで次のコマンドを実行し、サービスが起動時に開始するように設定します。
sudo update-rc.d apache2 enable

  1. Google Cloud コンソールで、webserver を選択して、その他の操作（）をクリックします。

  2. [リセット] をクリックします。

  3. 確認ダイアログで [リセット] をクリックします。

注: これにより、マシンが停止して再起動します。同じ IP と永続ブートディスクが保持されますが、メモリはワイプされます。そのため、リセット後に Apache サービスが利用可能になっていれば、update-rc コマンドは正常に実行されています。
  1. SSH 経由で VM に接続し、次のコマンドを入力してサーバーを確認します。
sudo service apache2 status 注: [Cloud Identity-Aware Proxy を介した接続に失敗しました] というポップアップが表示された場合は、[再試行] をクリックします。
  1. 「Started The Apache HTTP Server」という結果が表示されます。

カスタム イメージを作成するためのディスクを準備する

インスタンスが削除されても、ブートディスクが削除されないことを確認します。

  1. [VM インスタンス] ページで [webserver] をクリックし、VM インスタンスの詳細を表示します。
  2. [ストレージ] > [ブートディスク] で、[インスタンスを削除したときの動作] が [ディスクを維持] に設定されていることを確認します。
  3. [VM インスタンス] ページに戻り、webserver を選択して、その他の操作（）を選択します。
  4. [削除] をクリックします。
  5. 確認ダイアログで [削除] をクリックします。
  6. 左側のペインで [ディスク] をクリックし、webserver のディスクが存在することを確認します。

カスタム イメージを作成する

  1. 左側のペインで [イメージ] をクリックします。

  2. [イメージを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 mywebserver
    ソース ディスク
    ソースディスク webserver

  4. [作成] をクリックします。

注: カスタム イメージを作成しました。このイメージから同一のウェブサーバーを複数起動できます。この時点で webserver ディスクを削除できます。

次のステップではこのイメージを使用して、マネージド インスタンス グループで使用できるインスタンス テンプレートを定義します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ウェブサーバー用のカスタム イメージを作成する

タスク 4. インスタンス テンプレートを構成し、インスタンス グループを作成する

このタスクでは、インスタンス テンプレートを構成し、ロード バランシング ウェブサーバーのマネージド インスタンス グループを作成します。

マネージド インスタンス グループは、インスタンス テンプレートを使用して同一インスタンスのグループを作成します。これらを使用して、HTTP ロードバランサのバックエンドを作成します。

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

インスタンス テンプレートは、VM インスタンスとマネージド インスタンス グループの作成に使用できる API リソースです。このテンプレートでは、マシンタイプ、ブートディスク イメージ、サブネット、ラベル、その他のインスタンス プロパティを定義します。

  1. Google Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [インスタンス テンプレート] をクリックします。
  2. [インスタンス テンプレートを作成] をクリックします。
  3. [名前] に「mywebserver-template」と入力します。
  4. [ロケーション] で [グローバル] を選択します。
  5. [シリーズ] で [E2] を選択します。
  6. [マシンタイプ] > [共有コア] で、[e2-micro（2 vCPU、1 コア、1 GB のメモリ）] を選択します。
  7. [ブートディスク] で [変更] をクリックします。
  8. [カスタム イメージ] をクリックします。[イメージのソース プロジェクト] で Qwiklabs プロジェクト ID が選択されているようにします。
  9. [イメージ] で [mywebserver] を選択します。
  10. [選択] をクリックします。
  11. [詳細オプション] をクリックします。
  12. [ネットワーキング] をクリックします。
    • [ネットワーク タグ] に「allow-health-checks」と入力します。
    • [ネットワーク インターフェース] で [デフォルト] をクリックします。
    • [外部 IPv4 アドレス] プルダウンで [なし] を選択します。
    • [完了] をクリックします。
  13. [作成] をクリックします。

マネージド インスタンス グループのヘルスチェックを作成する

  1. ナビゲーション メニューで、[Compute Engine] > [ヘルスチェック] の順にクリックします。

  2. [ヘルスチェックを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（指定されたオプションを選択）
    名前 http-health-check
    プロトコル TCP
    ポート 80

  4. [作成] をクリックします。

マネージド インスタンス グループのヘルスチェックでは、異常が発生したインスタンスの削除と再作成を求める通知が先を見越して送信されます。

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

マネージド インスタンス グループを に 1 つ、 に 1 つ作成します。

  1. ナビゲーション メニューで [Compute Engine] > [インスタンス グループ] の順にクリックします。

  2. [インスタンス グループを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 us-1-mig
    インスタンス テンプレート mywebserver-template
    ロケーション マルチゾーン
    リージョン

  4. [自動スケーリング] で、[インスタンスの最小数] に「1」、[インスタンスの最大数] に「2」をそれぞれ入力します。

  5. [自動スケーリング シグナル] で [CPU 使用率] をクリックします。

  6. [シグナルタイプ] で、[HTTP ロード バランシングの使用率] を選択します。

  7. [HTTP ロード バランシング使用率の目標値] に「80」と入力します。

  8. [完了] をクリックします。

  9. [初期化期間] をクリックして、「60」秒に設定します。

注: マネージド インスタンス グループには、負荷の増減に基づいて、マネージド インスタンス グループのインスタンスを自動的に追加または削除できる自動スケーリング機能が備わっています。自動スケーリングによってトラフィックの増加をアプリケーションで適切に処理できるようになり、リソースの必要性が低下した場合には費用を抑えることができます。自動スケーリングのポリシーを定義しておけば、測定された負荷に基づいてオートスケーラーで自動スケーリングが実行されます。

  1. [自動修復] で、[ヘルスチェック] に「http-health-check」と入力します。

  2. [http-health-check (TCP)] を選択します。

  3. [初期遅延] に「60」と入力します。 これは、VM の起動を初期化した後でヘルスチェックを開始するまでに、インスタンス グループが待機する時間です。このラボでは 5 分も待機する必要はないため、1 分に設定します。

  4. [作成] をクリックします。

  5. ダイアログ ウィンドウで [確認] をクリックします。

注: の notus-1-mig で同じ手順を繰り返す前に、インスタンス グループが作成されるまで数分待ってください。ステータスが「変換中」に変わるまで [更新] をクリックします。 注: 作成後に「インスタンス グループにバックエンド サービスが接続されていません」という警告が表示されたり、インスタンス グループの左側に赤い感嘆符が表示されたりした場合は、無視してください。ラボの次のセクションで、バックエンド サービスを使用してロードバランサを構成します。

  1. [インスタンス グループを作成] をクリックします。

  2. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 notus-1-mig
    インスタンス テンプレート mywebserver-template
    ロケーション マルチゾーン
    リージョン
    [自動スケーリング] > [インスタンスの最小数] 1
    [自動スケーリング] > [インスタンスの最大数] 2
    [自動スケーリング シグナル] > [シグナルタイプ] HTTP ロード バランシングの使用率
    HTTP ロード バランシング使用率の目標値 80
    初期化期間 60

  3. [ヘルスチェック] で [http-health-check (TCP)] を選択します。

  4. [初期遅延] に「60」と入力します。

  5. [作成] をクリックします。

  6. ダイアログ ウィンドウで [確定] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インスタンス テンプレートを構成し、インスタンス グループを作成する

バックエンドを確認する

両方のリージョンで VM インスタンスが作成されていることを確認します。

  • ナビゲーション メニューで、[Compute Engine] > [VM インスタンス] の順にクリックします。
    名前が「us-1-mig」で始まるインスタンスと「notus-1-mig」で始まるインスタンスが存在します。これらのインスタンスはマネージド インスタンス グループに含まれています。

タスク 5. HTTP ロードバランサを構成する

このタスクでは、ネットワーク図に示すように、2 つのバックエンド（ の us-1-mig と の notus-1-mig）の間でトラフィックを分散するようにアプリケーション ロードバランサ（HTTP）を構成します。

構成を開始する

  1. ナビゲーション メニューで、[ネットワーク サービス] > [ロード バランシング] の順にクリックします。
  2. [ロードバランサを作成] をクリックします。
  3. [ロードバランサのタイプ] で [アプリケーション ロードバランサ（HTTP / HTTPS）] を選択し、[次へ] をクリックします。
  4. [インターネット接続または内部] で [インターネット接続（外部）] を選択し、[次へ] をクリックします。
  5. [グローバルまたはシングル リージョンのデプロイ] で [グローバル ワークロードに最適] を選択し、[次へ] をクリックします。
  6. [ロードバランサの世代] で [グローバル外部アプリケーション ロードバランサ] を選択し、[次へ] をクリックします。
  7. [ロードバランサを作成] で [構成] をクリックします。
  8. [ロードバランサの名前] に「http-lb」と入力します。

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

ホストとパスのルールで、トラフィックの転送方法を決定します。たとえば、動画のトラフィックと静的トラフィックをそれぞれ異なるバックエンドに転送できます。ただし、このラボではホストとパスのルールは構成しません。

  1. [フロントエンドの構成] をクリックします。

  2. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    プロトコル HTTP
    IP バージョン IPv4
    IP アドレス エフェメラル
    ポート 80

  3. [完了] をクリックします。

  4. [フロントエンドの IP とポートを追加] をクリックします。

  5. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    プロトコル HTTP
    IP バージョン IPv6
    IP アドレス 自動割り当て
    ポート 80

  6. [完了] をクリックします。

アプリケーション ロード バランシング（HTTP/HTTPS）は、クライアント トラフィックの IPv4 アドレスと IPv6 アドレスの両方に対応しています。クライアントの IPv6 リクエストはグローバル ロード バランシング レイヤで終端し、IPv4 経由でバックエンドにプロキシされます。

バックエンドを構成する

バックエンド サービスによって、受信トラフィックが、接続されている 1 つ以上のバックエンドに振り向けられます。各バックエンドは、1 つのインスタンス グループと、処理できる容量に関する追加のメタデータで構成されます。

  1. [バックエンドの構成] をクリックします。

  2. [バックエンド サービスとバックエンド バケット] > [バックエンドサービスを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（指定されたオプションを選択）
    名前 http-backend
    バックエンド タイプ インスタンス グループ
    インスタンス グループ us-1-mig
    ポート番号 80
    分散モード レート
    最大 RPS 50
    容量 100
注: この構成は、ロードバランサが us-1-mig の各インスタンスの 1 秒あたりのリクエスト数（RPS）を 50 以下に維持しようとすることを意味します。

  1. [完了] をクリックします。

  2. [バックエンドを追加] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（指定されたオプションを選択）
    インスタンス グループ notus-1-mig
    ポート番号 80
    分散モード 使用率
    バックエンドの最大使用率 80
    容量 100
注: この構成は、ロードバランサが notus-1-mig の各インスタンスの CPU 使用率を 80% 以下に維持しようとすることを意味します。
  1. [完了] をクリックします。
  2. [ヘルスチェック] で [http-health-check] を選択します。
  3. [ロギングを有効にする] チェックボックスをオンにします。
  4. [サンプルレート] を「1」に指定します。
  5. [作成] をクリックします。
  6. [OK] をクリックします。

HTTP ロードバランサを確認して作成する

  1. [確認と完了] をクリックします。
  2. [バックエンド サービス] と [フロントエンド] を確認します。
  3. [作成] をクリックします。ロードバランサの作成が完了するまで待ちます。
  4. ロードバランサの名前（http-lb）をクリックします。
  5. 次のタスクのために、ロードバランサの IPv4 アドレスと IPv6 アドレスをメモしておきます。これ以降は、これらのアドレスをそれぞれ [LB_IP_v4]、[LB_IP_v6] と呼びます。
注: 16 進数形式のアドレスが IPv6 アドレスです。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アプリケーション ロードバランサ（HTTP）を構成する

タスク 6. アプリケーション ロードバランサ（HTTP）のストレステストを実施する

このタスクでは、アプリケーション ロードバランサ（HTTP）のストレステストを行い、トラフィックがバックエンド サービスに転送されることを確認します。

アプリケーション ロードバランサ（HTTP）にアクセスする

  1. Google Cloud コンソールのタイトルバーで、「Cloud Shell をアクティブにする」アイコン（）をクリックします。
  2. プロンプトが表示されたら、[続行] をクリックします。
  3. 次のコマンドを実行して、ロードバランサのステータスを確認します。[LB_IP_v4] は、ロードバランサの IPv4 アドレスに置き換えます。
LB_IP=[LB_IP_v4] while [ -z "$RESULT" ] ; do echo "Waiting for Load Balancer"; sleep 5; RESULT=$(curl -m1 -s $LB_IP | grep Apache); done 注: ロードバランサの準備が整ったら、コマンドが終了します。
  1. ブラウザで新しいタブを開いて http://[LB_IP_v4] に移動します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。

アプリケーション ロードバランサ（HTTP）のストレステストを実施する

新しい VM を作成して、アプリケーション ロードバランサ（HTTP）に対する負荷をシミュレートします。負荷が高くなるとトラフィックが両方のバックエンドに分散されるかどうかを確認します。

  1. Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [VM インスタンス] をクリックします。

  2. [インスタンスを作成] をクリックします。

  3. 次のように指定し、残りの設定はデフォルトのままにします。

    プロパティ 値（値を入力するか、指定されたオプションを選択）
    名前 stress-test
    リージョン と異なるが近いリージョン
    ゾーン リージョン内のゾーン

  4. [シリーズ] で [E2] を選択します。

  5. [マシンタイプ] で、e2-micro（2 vCPU、1 コア、1 GB のメモリ）を選択します。

注: 米国内のリージョンは notus-1 よりも に近いため、負荷が高すぎる場合を除いてトラフィックは us-1-mig のみに転送されるはずです。
  1. [OS とストレージ]、[変更] の順にクリックします。
  2. [カスタム イメージ] をクリックします。
  3. [カスタム イメージ] をクリックしてから、[イメージのソース プロジェクト] で Qwiklabs プロジェクト ID が選択されているようにします。
  4. [イメージ] で [mywebserver] を選択します。
  5. [選択] をクリックします。
  6. [作成] をクリックします。
  7. stress-test インスタンスが作成されるのを待ちます。
  8. stress-test で [SSH] をクリックし、ターミナルを起動して接続します。
  9. ブラウザでの SSH による VM への接続を許可するよう求めるプロンプトが表示されたら、[承認] をクリックします。
  10. 次のコマンドを実行して、ロードバランサ IP アドレスの環境変数を作成します。
export LB_IP=<ロードバランサの IPv4 アドレスをここに入力>
  1. echo で確認します。
echo $LB_IP
  1. 次のコマンドを実行して、ロードバランサに負荷をかけます。
ab -n 500000 -c 1000 http://$LB_IP/

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アプリケーション ロードバランサ（HTTP）のストレステストを実施する

  1. Google Cloud コンソールのナビゲーション メニュー（）で、[ネットワーク サービス] > [ロード バランシング] をクリックします。
  2. [http-lb] をクリックします。
  3. [モニタリング] をクリックします。
  4. [フロントエンドの場所（合計受信トラフィック）] で、北アメリカと 2 つのバックエンドの間のトラフィックを数分モニタリングします。
注: 最初はトラフィックが us-1-mig のみに転送されていますが、RPS が増加すると notus-1-mig にも転送されるようになります。これで、デフォルトではトラフィックが最も近いバックエンドに転送され、負荷が高くなるとバックエンド間で分散されることを確認できました。
  1. Google Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [インスタンス グループ] をクリックします。
  2. [us-1-mig] をクリックして、インスタンス グループのページを開きます。
  3. [モニタリング] をクリックして、インスタンス数と LB 容量をモニタリングします。
  4. 同じ手順を notus-1-mig インスタンス グループで繰り返します。
注: 負荷の大きさによっては、バックエンドが負荷に対応するようにスケーリングされます。

タスク 7. 確認

このラボでは、 と のバックエンドに接続されるアプリケーション ロードバランサ（HTTP）を構成しました。次に、VM を使用してアプリケーション ロードバランサのストレステストを実施し、グローバル ロードバランシングと自動スケーリングの動作を確認しました。

Azure で内部ロードバランサを実装するには、仮想ネットワークの作成、バックエンド プールの構成、ロードバランサの作成、ヘルスプローブの構成に加え、場合によってはネットワーク アドレス変換（NAT）ルールの構成も必要になります。内部アプリケーション ロードバランサと、Azure でこれに相当する Azure 内部ロードバランサはどちらも、それぞれのクラウド環境内で動作するロード バランシング ソリューションです。ただし、これら 2 つのロードバランサには類似点と相違点があります。類似点は次のとおりです。

  • 内部アプリケーション ロードバランサと Azure 内部ロードバランサはどちらも、内部ネットワーク トラフィック向けのロード バランシング機能を提供します。 どちらも TCP プロトコルと UDP プロトコルに対応し、仮想ネットワーク内の複数の仮想マシン（VM）上で実行されているアプリケーションのトラフィックをロード バランシングできます。
  • どちらのロードバランサも、バックエンド VM のステータスをモニタリングし、正常なインスタンスにトラフィックをルーティングするヘルスプローブを提供します。

相違点:

  • 内部アプリケーション ロードバランサが HTTP/HTTPS トラフィック専用に設計されているのに対し、Azure 内部ロードバランサはプロトコルに依存せず、あらゆる TCP/UDP トラフィックを処理できます。
  • 内部アプリケーション ロードバランサは、外部トラフィック用に Google Cloud のネットワーク ロードバランサを使用する必要があります。一方で、Azure 内部ロードバランサは、Azure 外部ロードバランサと組み合わせて使用する必要があります。
  • 内部アプリケーション ロードバランサがフルマネージド サービスであるのに対し、Azure 内部ロードバランサではオーナーによる手動での構成、管理が必要です。

まとめると、内部アプリケーション ロードバランサと Azure 内部ロードバランサはどちらも内部ネットワーク トラフィック向けのロード バランシング機能を提供しますが、対応しているプロトコル、外部ロード バランシングの統合、管理のアプローチ、利用できるリージョンに違いがあります。

ラボを終了する

ラボでの学習が完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Qwiklabs から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

  • 星 1 つ = 非常に不満
  • 星 2 つ = 不満
  • 星 3 つ = どちらともいえない
  • 星 4 つ = 満足
  • 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバック、ご提案、修正が必要な箇所については、[サポート] タブからお知らせください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。
前へ 次へ

始める前に

  1. ラボでは、Google Cloud プロジェクトとリソースを一定の時間利用します
  2. ラボには時間制限があり、一時停止機能はありません。ラボを終了した場合は、最初からやり直す必要があります。
  3. 画面左上の [ラボを開始] をクリックして開始します

このコンテンツは現在ご利用いただけません

利用可能になりましたら、メールでお知らせいたします

ありがとうございます。

利用可能になりましたら、メールでご連絡いたします

1 回に 1 つのラボ

既存のラボをすべて終了して、このラボを開始することを確認してください

シークレット ブラウジングを使用してラボを実行する

このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウントの競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。
プレビュー