IBM Cloud Docs
複数の場所およびゾーンにわたる分離されたワークロードのデプロイ

複数の場所およびゾーンにわたる分離されたワークロードのデプロイ

このチュートリアルでは、費用が発生する場合があります。 コスト見積もりツールを使用して、予測使用量に基づいてコスト見積もりを生成します。

このチュートリアルでは、IBM Cloud® Virtual Private Cloud(VPC) をプロビジョンすることによって、可用性が高く分離されたワークロードをセットアップする手順について説明します。 アプリケーションの高可用性を確保するために、1 つの地域内の複数のゾーンに仮想サーバー・インスタンス (VSI) を作成します。 第2のリージョンに追加のVSIを作成し、グローバルロードバランサー（GLB）を構成して、リージョン間の高可用性を提供し、異なる地域のユーザーのネットワーク待ち時間を短縮します。

すべての着信 HTTPS 要求の Transport Layer Security (TLS) 証明書を管理するために、カタログから IBM Cloud Internet Services (CIS) サービスを GLB としてプロビジョンし、カタログから IBM Cloud Secrets Manager サービスをプロビジョンします。

目標

  • 仮想プライベート・クラウドで使用可能なインフラストラクチャー・オブジェクトを使用したワークロードの分離について理解する。
  • リージョン内のゾーン間でロード・バランサーを使用して、仮想サーバー間でトラフィックを分散する。
  • リージョン間でグローバル・ロード・バランサーを使用して、高可用性を実現し、耐障害性の向上および待ち時間の短縮を図る。

" caption-side="bottom"}*の{: caption="図

  1. 管理者 (DevOps) は、リージョン 1 の VPC 内の 2 つの異なるゾーンにあるサブネットに VSI をプロビジョンし、リージョン 2 で作成された VPC で同じ手順を繰り返します。
  2. 管理者は、リージョン 1 の異なるゾーン内にあるサーバーのバックエンド・プールとフロントエンド・リスナーを使用してロード・バランサーを作成します。 リージョン 2 で同じ手順を繰り返します。
  3. 管理者は、関連するカスタム・ドメインを持つ IBM Cloud Internet Services インスタンスをプロビジョンし、2 つの異なる VPC に作成されたロード・バランサーを指すグローバル・ロード・バランサーを作成します。
  4. 管理者は、ドメインの SSL 証明書を Secrets Manager サービスに追加することによって HTTPS 暗号化を有効にします。
  5. ユーザーが HTTP/HTTPS 要求を行い、グローバル・ロード・バランサーがその要求を処理します。
  6. 要求は、グローバル・レベルとローカル・レベルの両方のロード・バランサーにルーティングされます。 その後、その要求は使用可能なサーバー・インスタンスによって実行されます。

開始前に

  • ユーザー許可があるか確認してください。 VPC リソースを作成および管理するための十分な許可がユーザー・アカウントに付与されていることを確認してください。 VPC のための必要な許可のリストを参照してください。
  • 仮想サーバーに接続するには、SSH 鍵が必要です。 SSH 鍵がない場合は、VPC 用の鍵の作成についての指示を参照してください。

仮想プライベート・クラウド、サブネット、および仮想サーバー・インスタンスの作成

このセクションでは、地域 1 に独自の VPC を作成します。その際、地域 1 の 2 つの異なるゾーンにサブネットを作成し、その後に VSI をプロビジョンします。

仮想プライベート・クラウドの作成

  1. Virtual Private Cloud ページに移動し、Create をクリックする。
  2. 「ロケーション」 セクションで、 「地域」 と 「地域」 を選択します (例えば、 Europe と London)。
  3. VPCの名前に vpc-region1 を入力し、リソースグループを選択し、オプションでリソースを整理するためのタグを追加します。
  4. デフォルトのセキュリティー・グループ の 「SSH を許可」 と 「ping を許可」 のチェック・マークを外します。 SSH アクセスは、後で保守セキュリティー・グループに追加されます。 要塞サーバーからの SSH アクセスを許可するために、保守セキュリティー・グループがインスタンスに追加されます。 このチュートリアルでは、ping アクセスは必要ありません。
  5. 「クラシック・リソースへのアクセスを有効にする (Enable access to classic resources)」 のチェック・マークを外したままにし、 「ゾーンごとにデフォルト接頭部を作成します」
  6. 「サブネット」 で、ゾーン 1 のサブネットの名前を変更します。 鉛筆アイコンをクリックしてください。
    • サブネットの固有の名前として vpc-region1-zone1-subnet を入力します。
    • VPC リソース・グループと同じ リソース・グループ を選択します。
    • その他の値はデフォルトのままにします。
    • 保存 をクリックします。
  7. 「サブネット」 で、ゾーン 2 のサブネットの名前を変更します。 鉛筆アイコンをクリックしてください。
    • サブネットの固有の名前として vpc-region1-zone2-subnet を入力します。
    • VPC リソース・グループと同じ リソース・グループ を選択します。
    • その他の値はデフォルトのままにします。
    • 保存 をクリックします。
  8. 「サブネット」 で、ゾーン 3 のサブネットを削除します。 マイナス・アイコンをクリックしてください。
  9. 「仮想プライベート・クラウドの作成 (Create virtual private cloud)」 をクリックして、インスタンスをプロビジョンします。

アプリケーションへのインバウンド・トラフィックを許可するセキュリティー・グループの作成

セキュリティー・グループにルールを定義することにより、アプリケーションへの HTTP (80) ポートおよび HTTPS (443) ポートのインバウンド・ルールを有効にします。 後のステップで、VSI をセキュリティー・グループに追加します。

  1. 「セキュリティー・グループ」 ページにナビゲートし、 「作成」 をクリックします。

  2. 名前に vpc-region1-sg を入力し、VPC リソース・グループと同じ 「リソース・グループ」 を選択します。

  3. 以前に作成した vpc-region1 仮想プライベート・クラウドを選択します。

  4. 以下の表にあるものと同じ インバウンド・ルール を追加し、 「セキュリティー・グループの作成」 をクリックします。

    インバウンド・ルール
    プロトコル ソース・タイプ ソース 値
    TCP 任意 0.0.0.0/0 ポート 80-80
    TCP 任意 0.0.0.0/0 ポート 443-443

仮想サーバー・インスタンスをプロビジョンします

  1. 「サブネット」 ページにナビゲートします。
  2. すべてのサブネットの状況が Available であることを確認します。
  3. vpc-region1-zone1-subnet をクリックし、続いて Attached resources をクリックし、Attached instances の下にある Create をクリックする。
    1. 仮想サーバーの固有の名前として vpc-region1-zone1-vsi を入力します。
    2. 「仮想プライベート・クラウド」、 「リソース・グループ」、 「ロケーション」 、および 「ゾーン」 の各フィールドを確認または設定します。
  4. 「イメージとプロファイル (Image and profile)」 セクションで、 「イメージの変更 (Change image)」 をクリックします。
  5. 「項目の検索」 フィールドに Ubuntu と入力し、イメージの任意のバージョンを選択して、 「保存」 をクリックします。
  6. 「プロファイル」 セクションで、 「プロファイルの変更」 をクリックします。
  7. プロファイルとして 2 vCPUs および 4 GB RAM を指定して 「コンピュート」 を選択し、 「保存」 をクリックします。
  8. 「SSH 鍵」 を、先ほど作成した SSH 鍵に設定します。
  9. 「仮想ネットワーク・インターフェースを使用したネットワーク接続 (Network attachments with Virtual network interface)」 の下で、 eth0 インターフェースの行にある鉛筆アイコンをクリックします。
    • 「次へ」 をクリックします。
    • vpc-region1-sg にチェック・マークを付け、 VPC のデフォルトの セキュリティー・グループのチェック・マークを外します。
    • 「次へ」 を数回クリックしてから、 「保存」 をクリックします。
  10. 仮想サーバーの作成］をクリックします。
  11. 上記のステップを繰り返して、 vpc-region1-zone2-vsi 仮想サーバーを vpc-region1-zone2-subnet サブネットにプロビジョンします。

別の場所にリソースを作成

ステップ 1 の上記のステップを繰り返して、別のリージョン (例えば、 フランクフルト) にサブネットと仮想サーバー・インスタンスを持つ新規 VPC をプロビジョンします。 上記と同じ命名規則に従い、region2 を region1 に置き換える。

仮想サーバー・インスタンスへの Web サーバーのインストールと構成

サーバーの保護された保守については、要塞ホストを使用してリモート・インスタンスに安全にアクセスする に記載されている手順に従ってください。 以前にプロビジョンされた VSI に対して jump サーバーおよび保守セキュリティー・グループとして機能する要塞ホストを使用します。 VPC ごとに 1 つの要塞ホストが必要です。

地域 1 の ゾーン 1 のサブネットにプロビジョンされたサーバーに正常に SSHed が追加されると、

  1. プロンプトで、以下のコマンドを実行して、Nginx を Web サーバーとしてインストールします。
    sudo apt-get update
sudo apt-get install nginx
  2. 次のコマンドを使用して、Nginx サービスの状況を確認します。
    sudo systemctl status nginx
    出力に、Nginx サービスが アクティブ かつ稼働中であることが示されます。
  3. 任意で、Nginx が予想どおりに動作することを確認します。curl localhost。 デフォルトの Nginx ウェルカム・ページが表示されるはずです。
  4. リージョンとゾーンの詳細で HTML ページを更新するには、次のコマンドを実行します。
    nano /var/www/html/index.nginx-debian.html
    地域とゾーンを h1 タグの引用符 Welcome to nginx! に追加して、 Welcome to nginx! server running in **zone 1 of region 1** を読み、変更を保存します。
  5. curl localhost コマンドを実行して、変更を検証します。
  6. 上記の手順を繰り返して、すべてのゾーンのサブネットのVSIにウェブサーバをインストールし、設定し、それぞれのリージョンとゾーン情報を含むようにhtmlを更新することを忘れないでください。

ロード・バランサーを使用してゾーン間でトラフィックを分散する

このセクションでは、2 つのロード・バランサーを作成します。 それぞれのリージョンにロード・バランサーを 1 つ作成し、異なるゾーン内の各サブネットにある複数のサーバー・インスタンス間でトラフィックを分散します。

ロード・バランサーを介したインバウンド・トラフィックとアウトバウンド・トラフィックを許可するセキュリティー・グループを作成します。

アプリケーションへのトラフィックを許可するには、HTTP (80) ポートと HTTPS (443) ポートのインバウンド・ルールとアウトバウンド・ルールを有効にする必要があります。 後のステップで、ロード・バランサーを作成するときに、これらのルールを定義したセキュリティー・グループにそれらのロード・バランサーを追加します。

  1. 「セキュリティー・グループ」 ページにナビゲートし、 「作成」 をクリックします。

  2. 以前に作成した vpc-region1 仮想プライベート・クラウドを選択します。

  3. 名前に vpc-lb-sg を入力し、VPC リソース・グループと同じ 「リソース・グループ」 を選択します。

  4. 以下の表にあるものと同じ インバウンド・ルール を追加します。

    インバウンド・ルール
    プロトコル ソース・タイプ ソース 値
    TCP 任意 0.0.0.0/0 ポート 80-80
    TCP 任意 0.0.0.0/0 ポート 443-443

  5. 以下の表にあるものと同じ アウトバウンド・ルール を追加し、 「セキュリティー・グループの作成」 をクリックします。

    アウトバウンド・ルール
    プロトコル ソース・タイプ ソース 値
    TCP 任意 0.0.0.0/0 ポート 80-80
    TCP 任意 0.0.0.0/0 ポート 443-443

  6. 上記のステップを 地域 2 で繰り返します。

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

  1. 「ロード・バランサー」 ページにナビゲートし、 「作成」 をクリックします。
  2. ロード・バランサーのタイプとして 「アプリケーション・ロード・バランサー (ALB)」 を選択します。
  3. 「ロケーション」 セクションで、前に作成した vpc-region1 仮想プライベート・クラウドに使用したものと同じ 「地域」 および 「地域」 を選択します。
  4. 名前に vpc-lb-region1 を入力し、VPC リソース・グループと同じ 「リソース・グループ」 を選択します。
  5. 以前に作成した vpc-region1 仮想プライベート・クラウドを選択します。
  6. vpc-region1-zone1-subnet と vpc-region1-zone2-subnet の サブネットを選択する。
  7. 「プールの作成」 をクリックして、プールにルーティングされたトラフィックを共有する同等のピアとして機能する VSI の新しいバックエンド・プールを作成します。 パラメータを以下の値で設定し、完了したら「作成」をクリックします。
    • 名前: region1-pool
    • プロトコル: HTTP
    • セッション維持率: None
    • プロキシー・プロトコル: Disabled
    • 方法: Round robin
    • ヘルス・チェック・パス: /
    • ヘルス・プロトコル: HTTP
    • ヘルス・ポート: 強制ブランク
    • 間隔 (秒): 15
    • タイムアウト (秒): 5
    • 最大再試行回数: 2
    • 「作成」 をクリックします。
  8. サーバーの接続 をクリックして、サーバー・インスタンスをプールに追加します。
    • 「サブネット」 ドロップダウンから、 vpc-region1-zone1-subnet および vpc-region1-zone2-subnet を選択します。
    • 作成したインスタンスを選択し、 ポートとして 80 を設定します。
    • 「接続」 をクリックして、バックエンド・プールの作成を完了します。
  9. 「リスナーの作成」 をクリックして、新規フロントエンド・リスナーを作成します。リスナーとは、接続要求をチェックするプロセスです。
    • バックエンド・プール: region1-pool
    • プロトコル: HTTP
    • プロキシー・プロトコル (Proxy protocol): チェックなし
    • ポート: 80
    • 最大接続数: 空のままにして、作成 をクリックします。
  10. 「セキュリティー・グループ」 で、 vpc-lb-sg にチェック・マークを付け、デフォルトのセキュリティー・グループのチェック・マークを外します。
  11. ロードバランサーの作成をクリックして、ロードバランサーのプロビジョニングを行います。
  12. リージョン 2 で上記の手順を繰り返します。今回は、ロード・バランサー vpc-lb-region2 とバックエンド・プール region2-pool の名前を指定します。

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

  1. ロード・バランサーの状況が 「アクティブ」 に変わるまで待ちます。
  2. Web ブラウザーで 「ホスト名」 を開きます。
  3. ページを何度かリフレッシュして、リフレッシュするたびにロードバランサーが異なるゾーンや仮想サーバーインスタンスから結果を返すことに気づく。
  4. 今後参照するために、アドレスを保存します。

要求が暗号化されておらず、HTTP のみをサポートしていることに気付いた可能性があります。 次のセクションで SSL 証明書を構成して HTTPS を有効にします。

複数のロケーションのロード・バランシングを構成する

あなたのアプリケーションは現在2つのリージョンで動いていますが、ユーザーが1つのエントリーポイントから透過的にアクセスするためのコンポーネントが1つ足りません。

このセクションでは、2 つの地域間で負荷を分散するように IBM Cloud Internet Services (CIS) を構成します。CIS は、クラウド・アプリケーションの信頼性とパフォーマンスを確保しながらアプリケーションを保護するために、グローバル・ロード・バランサー (GLB)、キャッシング、Web アプリケーション・ファイアウォール (WAF) 、および ページ・ルール を提供しています。

グローバル・ロード・バランサーを構成するには、以下を行う必要があります。

  • カスタム・ドメインに CIS ネーム・サーバーを参照させる
  • VPC ロード・バランサーの IP アドレスまたはホスト名を取得する
  • アプリケーションの使用可否を検証するヘルス・チェックを構成する
  • VPC ロード・バランサーを指すオリジン・プールを定義する

IBM Cloud Internet Services へのカスタム・ドメインの追加

最初の手順は、CIS のインスタンスを作成し、カスタム・ドメインに CIS ネーム・サーバーを参照させることです。

  1. ドメインを所有していない場合は、レジストラから購入することができます。

  2. IBM Cloud カタログ内の IBM Cloud Internet Services にナビゲートします。

  3. プランを選択し、サービス名とリソース・グループを設定し、 「作成」 をクリックしてサービスのインスタンスを作成します。

  4. サービス・インスタンスがプロビジョンされたら、「ドメインの追加」 をクリックします。

  5. ドメイン名を入力し、「次へ」 をクリックします。

  6. DNS レコードのセットアップはオプションのステップであり、このチュートリアルではスキップできます。「次へ」 をクリックします。

  7. ネーム・サーバーが割り当てられたら、そのリストされたネーム・サーバーを使用するようにレジストラーまたはドメイン・ネーム・プロバイダーを構成します。

  8. この時点で、「取り消し」 をクリックしてメインページに戻ることができます。レジストラーまたは DNS プロバイダーを構成してから、その変更が反映されるまでに最大で 24 時間かかる場合があります。

    「概要」ページのドメインの状況が_「保留中」から「アクティブ」_に変わったら、dig <your_domain_name> ns コマンドを使用して、新しいネーム・サーバーが有効になったことを確認できます。

グローバル・ロード・バランサーのヘルス・チェックを構成する

ヘルス・チェックを使用すると、プールが使用可能かどうかを調べて、正常なプールにトラフィックを転送できます。 これらのチェックは、定期的に HTTP/HTTPS 要求を送信して応答をモニターします。

  1. IBM Cloud Internet Services ダッシュボードで、信頼性 > グローバル・ロード・バランサー にナビゲートします。

  2. 「ヘルス・チェック」 を選択し、「作成」 をクリックします。

  3. 名前を nginx に設定する。

  4. 「モニター・タイプ」 に 「HTTP」 を選択します。

  5. Port を 80 に設定する。

  6. パスを / に設定する。

  7. 「作成」 をクリックします。

    独自のアプリケーションを構築する場合、アプリケーションの状態を報告する_/health_のような専用のヘルスエンドポイントを定義することができる。

オリジン・プールを定義する

プールは、グローバルロードバランサーに接続されたときにトラフィックがインテリジェントにルーティングされるオリジンVSIまたはロードバランサーのグループです。 2 つのリージョンに VPC ロード・バランサーがあるので、ロケーション・ベースのプールを定義し、ユーザー要求の地理的位置に基づいて最も近い VPC ロード・バランサーにユーザーをリダイレクトするように CIS を構成できます。

VPC ロード・バランサーの起点プール

  1. 「オリジン・プール (Origin pools)」 を選択し、「作成」 をクリックします。
  2. 「プールの名前」region-1-pool を入力します。
  3. 「起点名」 を region-1 に設定します。
  4. 「起点アドレス」 を地域 1 の VPC ロード・バランサーのホスト名に設定します。VPC ロード・バランサーの 概要ページ を参照してください。
  5. 「既存のヘルス・チェック」 を選択し、前に作成したヘルス・チェックを選択します。
  6. ロケーション・リージョン 1 の近くにある 「ヘルス・チェック・リージョン」 を選択します。
  7. 保存 をクリックします。
  8. 地域 2 について、上記の手順を繰り返します。

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

オリジン・プールを定義したら、ロード・バランサーの構成を実行できます。

  1. 「ロード・バランサー」 を選択し、「作成」 をクリックします。

  2. デフォルトのまま、「有効化」 は On、「プロキシー」 は Off にします。

  3. グローバルロードバランサーの名前 lb を入力します。この名前はアプリケーションにアクセスするサブドメインの最初の文字になります。http://lb``<your_domain_name>)。

  4. 「経路の追加」 をクリックします。

  5. 地域: Defaultを選択します。

  6. 先ほど作成したオリジンプール（region-1-pool と region-2-pool）を選択する。

  7. 追加 をクリックします。

  8. 「地理的経路 (Geo routes)」 のセクションを展開すると、起点地域に基づいてトラフィックを分散できます。

    必要に応じて、地域に基づいてさらに経路を追加し、最も近いプールにトラフィックを送信することができます。 Add route をクリックし、グローバルロードバランサーのリージョン（例えば、西ヨーロッパ）を選択し、プール（例えば、region-2-pool）を選択し、Add をクリックします。 定義された経路のいずれにも一致しない要求は、 デフォルトの起点プール にリダイレクトされます。定義したグローバル・ロード・バランサー領域内のユーザーは、最も近いロード・バランサー /VSI に転送されます。

  9. 「作成」 をクリックします。

HTTPS を使用して保護する

HTTPS暗号化には、CISグローバルロードバランサーとVPCロードバランサーの両方からアクセスできる署名付き証明書が必要です。 IBM Cloud Secrets Managerを使用して、ドメインの証明書を注文またはインポートし、管理します。 その後、必要なサービスから証明書への読み取りアクセスを許可するように、Identity and Access Management (IAM) サービス許可が構成されます。

Secrets Manager インスタンスの作成と許可

  1. 既存の Secrets Manager インスタンスがある場合は、このチュートリアルで使用することも、必要に応じて Secrets Manager サービス・インスタンスの作成で概説されているステップに従って新しいインスタンスを作成することもできます。

  2. VPC ロード・バランサー・サービスを、SSL 証明書が含まれている Secrets Manager インスタンスにアクセスできるようにする許可を作成します。

    • ID およびアクセス許可にナビゲートします。
    • 作成 をクリックし、ソース・サービスとして VPC インフラストラクチャー・サービス を選択します。
    • 「特定のリソース」、 「リソース・タイプ」 、 「VPC ロード・バランサー」 の順に選択します。
    • 対象サービスとして Secrets Manager
    • 「ライター」 のサービス・アクセス役割を割り当てます。
    • 対象となるサービスインスタンスは、Allリソースでもよいし、必要に応じて特定のSecrets Managerインスタンスでもよい。 ここでは、 「すべてのリソース」 が選択されています。
    • 「許可」 をクリックします。

  3. 引き続き Manage authorizations ページで、Secrets Managerに CISへのアクセス権を与える権限を作成する：

    • 作成 をクリックし、ソース・サービスとして Secrets Manager を選択します。
    • すべてのリソース]を選択するか、先ほど作成したSecrets Managerだけを選択します。
    • ターゲット・サービスとしての インターネット・サービス 。
    • すべてのリソース」 または、先に作成したCISだけを選択します。
    • 「管理者」 のサービス・アクセス役割を割り当てます。
    • 「許可」 をクリックします。

    CIS インスタンスが複数のドメインをサポートしている場合は、読者 ロールを CIS インスタンスに割り当て、責任者 をソリューションに使用している特定のドメインに割り当てることもできます。 特定のドメインへのサービス・アクセス権限の付与トピックを参照してください。

IBM CIS は、グローバル・ロード・バランサーのプロキシー処理をサポートします。 ロード・バランサーがプロキシー処理されると、そのトラフィックは CIS を介して直接実行されます。 ロード・バランサーは、DNS のみのプロキシー・モードと HTTP プロキシー・モードの両方をサポートします。トラフィック・ルーティングの動作が以下のように異なるため、先に進む前に、以下の 2 つの選択肢のうち、どちらがユース・ケースに最も適合するかを考慮してください。

  • 代替方法 1: プロキシー処理されたトラフィックがCISを通過します。
  • 代替方法 2: 非プロキシー (DNS 専用モード) のトラフィックは、クライアントから起点に直接送信されます。 DNSのみのモードでは、CISのセキュリティ、パフォーマンス、信頼性機能は一切適用されない。

「トラフィック・フロー」
「トラフィック・フロー」

詳しくは、DNS レコードとグローバル・ロード・バランサーのプロキシー処理のトピックを参照してください。

代替方法 1: プロキシー、CIS を経由するトラフィック・フロー

この最初の選択肢は、カスタムドメイン用のワイルドカード証明書を作成し、それをIBM Cloud Internet ServicesCIS)でプロキシすることで、業界をリードするセキュリティ、保護、およびパフォーマンス機能を利用できるようにします。 以下の手順で、 example.com をカスタム・ドメイン・ネームに置き換えます。

現在、Let's Encrypt を使用して証明書を注文しています。更新については、サポートされる認証局 のトピックに従ってください。 Let's Encrypt を使用するには、ACME アカウントが必要です。 サード・パーティー認証局の接続 のトピックで概説されている手順に従って、アカウントを作成または登録します。 さらに、DNS プロバイダーの接続トピックの手順に従って DNS プロバイダーを追加する必要があります。 このチュートリアルでは、DNS プロバイダーとして CIS を追加する必要があります。

最初は、ユーザーから Secrets Manager のみに HTTPS が構成されます。

  1. Secrets Manager での証明書の注文
    • Secrets Manager サービスを開き、左側の シークレット を選択します。
    • 追加 をクリックします。
    • 新しい Secrets Manager インスタンスを使用している場合は、証明書を注文する前にそれを構成する必要があります。 「 公開証明書を注文するための準備」で概説されている手順に従ってください。
    • 「パブリック証明書」 をクリックし、 「次へ」 をクリックします。
    • 次のフォームに入力します。
      • 名前 - 覚えておくことができる名前を入力します。
      • 説明 - 任意の説明を入力します。
      • 「次へ」 をクリックします。
      • 認証局 の下で、構成済みの Let's Encrypt 認証局エンジンを選択します。
      • 鍵アルゴリズム の下で、任意のアルゴリズムを選択します。
      • バンドル証明書 - オフのままにします。
      • 自動証明書ローテーション - オフのままにします。
      • DNS プロバイダー で、構成済みの DNS プロバイダー・インスタンスを選択します。
      • ドメインの選択 をクリックし、ワイルドカードで選択 をオンにし、ドメイン自体のチェックを外したままにして、完了 をクリックします。
    • 次へ をクリックします。
    • 選択内容を確認して、 「追加」 をクリックします。
    • 次のステップを実行するためにアクティベーションが完了するまで待つ必要はありませんが、成功を検証する前に完了するまで待つ必要があります。
  2. クライアント Web ブラウザーから CIS エンドポイントへの https を構成します。 CIS で、TLS セキュリティーを構成します。
    • 「セキュリティー」 パネルを開き、「TLS」 を選択します。
    • 「モード」 では、「クライアントからエッジ (Client-to-edge)」 を選択します。 こうすると、グローバル・ロード・バランサーで https 接続が終端処理され、VPC ロード・バランサーへの http 接続に切り替わります。
  3. CIS で、TLS を使用するようにグローバル・ロード・バランサーを構成します。
    • 信頼性 パネルを開き、グローバル・ロード・バランサー を選択します。
    • 前に作成したグローバル・ロード・バランサーを見つけて、プロキシーをオンにします。
  4. ブラウザで https://lb.example.com を開き、成功を確認する。

次に、CIS から VPC ロード・バランサーへの HTTPS を構成します。

VPC ロード・バランサーに HTTPS リスナーを追加します。

  1. VPC 、ロード・バランサー の順にナビゲートし、vpc-lb-region1 をクリックします。

  2. フロントエンド・リスナー を選択します。

  3. リスナーの作成 をクリックします。

  4. デフォルトのバックエンド・プール: region1-pool または region2-poolを選択します。

  5. HTTPS を選択し、Port に 443 を入力する。

  6. 前に作成した Secrets Manager インスタンスを選択します。「SSL 証明書」ドロップダウンには、以前に Let 's Encrypt から Secrets Manager インスタンスを使用して注文した証明書 名前 が表示されます。 「作成」 をクリックします。

    SSL証明書のドロップダウンに example.com がない場合、VPCロードバランサーにSecrets Managerサービスへのアクセスを与える、上記の認証ステップを見逃している可能性があります。 Secrets Managerサービスが example.com の証明書を持っていることを確認する。

  7. vpc-lb-region2 ロード・バランサーについて、上記のステップを繰り返します。

作成されたワイルドカード証明書は、vpc-lb-region1. example.com のようなドメイン・ネームへのアクセスを許可します。 VPC ロード・バランサー vpc-lb-region1 の 「概要 (Overview)」 タブを開き、「ホスト名」 が xxxxxxx-REGION.lb.appdomain.cloud であることに注目します。 ワイルドカード証明書は機能しません。 別名を作成してから構成を更新して、この問題を解決します。

  1. クライアントがvpc-lb-region1 .example.com を検索し、xxxxxxx-REGION.lb.appdomain.cloudを解決できるように、DNS CNAMEレコードを作成できる。

    • CISで、「信頼性」 パネルを開き、「DNS」 を選択します。
    • DNS レコードまでスクロールダウンし、タイプ CNAME (名前) 、名前: vpc-lb-region1 、TTL: 自動 、別名ドメイン・ネーム: VPC ロード・バランサーのホスト名 のレコードを作成します。
    • vpc-lb-region2 の DNS CNAME レコードを追加します。

  2. 次に、新しい CNAME レコードを使用するようにグローバル・ロード・バランサーを調整します。

    • 信頼性 パネルを開き、グローバル・ロード・バランサー を選択します。
    • Find and edit the オリジン・プール to change the 起源 住所 to vpc-lb-region1.example.com.
    • vpc-lb-region2.example.com に対して上記の手順を繰り返す。

  3. エンドツーエンド・セキュリティーをオンにします。

    • 「セキュリティー」 パネルを開き、「TLS」 を選択します。
    • 「モード」 には、「エンドツーエンド - CA 署名 (End-to-end CA signed)」 を選択します。 これは、グローバルロードバランサーのHTTPS接続とVPCロードバランサーのHTTPS接続を使用します。

ブラウザで https://lb.example.com を開き、成功を確認する

選択肢 2: DNS 専用モード、クライアントから VPC ロード・バランサーへの直接トラフィック・フロー

この代替方法では、Let's Encrypt から Secrets Manager を介して lb.example.com 用の SSL 証明書を注文し、グローバル・ロード・バランサーを構成します。

現在、CIS グローバル・ロード・バランサーに関する証明書を直接注文することはできませんが、CNAME レコードに関する証明書を注文することはできます。 そのため、証明書を注文するための CNAME を作成します。

  1. 以前に作成した CIS サービスを開きます。このサービスは「リソース・リスト」内にあります。

  2. 「信頼性」 の下の 「グローバル・ロード・バランサー」 に移動して、「DNS」 をクリックします。

  3. 「DNS レコード」セクションまでスクロールダウンして、新規レコードを作成します。

    • タイプ: CNAME
    • 名前: lb
    • TTL の場合: default (Automatic)
    • 別名ドメイン名: zzz.example.com
    • 「レコードの追加」 をクリックします

  4. Secrets Manager での証明書の注文

    • Secrets Manager サービスを開き、左側の シークレット を選択します。
    • 「追加」 をクリックし、 「パブリック証明書」 をクリックします。 「次へ」 をクリックします。
    • 次のフォームに入力します。
      • 名前 - lb-alias.
      • 説明 - 任意の説明を入力します。
      • 「次へ」 をクリックします。
      • 認証局 の下で、構成済みの Let's Encrypt 認証局エンジンを選択します。
      • 鍵アルゴリズム 下で RSA4096 を選択します。
      • バンドル証明書 - オフのままにします。
      • 自動証明書ローテーション - オフのままにします。
      • DNS プロバイダー で、構成済みの DNS プロバイダー・インスタンスを選択します。
      • ドメインの選択 をクリックします。
      • 表示されているドメインを展開してサブドメインのリストを表示し、lb.example.comの横にあるチェックボックスを選択して、Done をクリックします。
    • 次へ をクリックします。
    • 選択内容を確認して、 「追加」 をクリックします。

HTTPS リスナーを作成します。

  1. VPC の 「ロード・バランサー」 ページに移動します。

  2. vpc-lb-region1 を選択します。

  3. 「フロントエンド・リスナー」 で、「作成」 をクリックします。

    • プロトコル: HTTPS
    • ポート: 443
    • バックエンド・プール: 同一リージョン内のプール
    • SSL リージョンとして現在のリージョンを選択します
    • lb.example.com 用に作成したSSL証明書の注文名を選択します

  4. 「保存」 をクリックして、HTTPS リスナーを構成します。

地域 2 のロード・バランサーで上記のステップを繰り返します。

ブラウザで lb.example.com を開き、成功を確認する

フェイルオーバー・テスト

これまでは、ほとんどの場合、地域 1 内のサーバーにアクセスしています。これは、地域 2 内のサーバーよりも高い重みが割り当てられているためです。 ここで、リージョン 1 の起点プールにヘルス・チェックの失敗が発生したとします。

  1. 「仮想サーバー・インスタンス」 のリストに移動します。

  2. リージョン 1 の ゾーン 1 で実行されているサーバーの横の 3 つのドット (...) をクリックして、「停止」 をクリックします。

  3. 地域 1 の ゾーン 2 で実行されているサーバーについても同じ手順を繰り返します。

  4. CIS サービスの下の GLB に戻り、正常性の状況が 「重大」 に変わるまで待ちます。

  5. これで、ドメインの URL を最新表示すると、常に リージョン 2 のサーバーにアクセスするはずです。

    リージョン 1 のゾーン 1 とゾーン 2 のサーバーを必ず 始動 してください。

リソースを削除する

  • CIS サービスの下のグローバル・ロード・バランサー、起点プール、およびヘルス・チェックを削除します。
  • Secrets Manager サービスの証明書を削除します。
  • ロード・バランサー、VSI、サブネット、および VPC を削除します。
  • リソース・リストで、このチュートリアルで使用したサービスを削除します。