IBM Cloud Docs
共有 VPC 環境および専用 VPC 環境でのワークロードのスケーリング

共有 VPC 環境および専用 VPC 環境でのワークロードのスケーリング

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

このチュートリアルでは、共有 (マルチテナント) 環境と専用 (シングル・テナント) 環境における、分離されたワークロードのセットアップについての手順を、段階的に説明します。 複数のアベイラビ複数のアベイラビリティー・ゾーン (AZ) にまたがるサブネットと複数の仮想サーバー・インスタンス (VSI) を持つ、IBM Cloud® Virtual Private Cloud (VPC) をプロビジョンします。VSI はお客様の要件に応じてスケーリングでき、アプリケーションの高可用性を確保します。 さらに、ロード・バランサーを構成して、1 つのリージョン内の複数のゾーン間における高可用性を提供します。 IBM Cloud 上のサービスへのプライベート・ルートを提供する、VPC 用の仮想プライベート・エンドポイント (VPE) を構成します。

ワークロードの分離は、専用ホストのプロビジョニング、暗号化データ・ボリュームの VSI へのアタッチ、アタッチしたデータ・ボリュームの拡張、およびファクト後の VSI のサイズ変更によって行います。

これらのすべてのサービスと VPC リソースを、IBM Cloud Schematics を使用してプロビジョニングします。IBM Cloud Schematics には Terraform-as-a-Service 機能が用意されています。 Terraform テンプレートは、作成、更新、または削除する IBM Cloud リソースを定義します。

目標

  • インスタンスの自動スケーリングを使用してマルチゾーン VPC をセットアップする方法を学ぶ。
  • パブリックおよびプライベートのロード・バランシングの概念を理解する。
  • インスタンスを動的または定期的にスケーリングする方法を学ぶ。
  • 専用ホストの使用法を学ぶ。

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

  1. VSI にデプロイされたフロントエンド・アプリは、プライベート・ロード・バランサーを介してバックエンド・アプリと通信します。
  2. バックエンド・アプリは、仮想プライベート・エンドポイント (VPE) を介してクラウド・サービスと安全に通信します。
  3. アプリケーションの負荷が増えると、VPC のスケーリングが有効になり、CPU、RAM などのメトリックに基づいて、またはスケジュールされたスケーリングによって、VSI が動的に追加または削除されます。
  4. スコープが拡大するにつれ、専用ホストは隔離され、データに対して集中的な計算が実行されます。 お客様の要件に基づいてプロファイルを更新することで、専用ホスト上のインスタンスのサイズを変更します。 また、ブロック・ストレージ・ボリュームの容量を拡張します。
  5. すべてのインスタンスは、仮想プライベート・エンドポイント (VPE) を使用して、プライベート・バックボーンを介して IBM Cloud サービスと通信します。 詳細については、仮想プライベート・エンドポイント・ゲートウェイについてのトピックを参照してください。

開始前に

このチュートリアルでは、以下が必要です。

ロギングとモニタリングの有効化

  1. IBM Cloud LogsインスタンスをIBM Cloud Logs Routingのターゲットとして設定する。 IBM® Cloud Logs Routingで始める を参照
  2. プラットフォーム・メトリクスを収集するためにMonitoringインスタンスを構成します。 プラットフォーム・メトリクスの有効化」を参照

必須クラウド・サービスのプロビジョン

このセクションでは、IBM Cloud Schematics を使用して、アプリケーションに必要なクラウド・サービスである IBM Cloud Databases for PostgreSQL および IBM Cloud Object Storage を作成します。

  1. Schematicsワークスペース にナビゲートし、「ワークスペースの作成」 をクリックします。
    1. 「テンプレートの指定 (Specify Template)」 セクションの下で、GitHub または GitLab のリポジトリー URL として https://github.com/IBM-Cloud/vpc-scaling-dedicated-host を指定します。
    2. Terraformのバージョンとして terraform_v1.5 を選択し、Next をクリックします。
  2. 「ワークスペースの詳細」 の下で、以下のようにします。
    1. Provide a workspace name : vpc-scaling-workspace.
    2. Resource GroupとLocationを選択します。
    3. 「次へ」 をクリックします。
  3. 詳細を確認して、「作成」 をクリックします。
  4. 変数下にある「step1_create_services」を「真の」に設定し、「デフォルトを使用するチェックを外し、「Override Value ドロップダウンから「真の選び、「セーブ」をクリックする。
  5. オーバーライドする変数が他にもある場合は、それも設定します。最も一般的なものは、region と resource_group_name です。
  6. ページの上部までスクロールして、「プランの生成」 をクリックします。 これは terraform plan コマンドと同じです。
  7. 「詳細表示」 をクリックして、プロビジョンするリソースを確認します。
  8. 階層リンク・メニューを使用してワークスペース・ページにナビゲートし、「プランの適用」 をクリックします。 ログを確認して、作成したサービスの状況を調べます。

リソース・リストにナビゲートします。 ここで、リソースを作成するのに使用したbasename ( vpc-scaling ) でフィルター処理を行うと、指定したリソース・グループにプロビジョンされた、このチュートリアルで必要なクラウド・サービスを表示できます。 これらのサービスで格納されるデータはすべて、IBM Key Protect for IBM Cloud で生成、格納された鍵を使用して暗号化されます。

マルチゾーン仮想プライベート・クラウドのセットアップ

このセクションでは、以下を実行します。

  • IBM Cloud® Virtual Private Cloudをプロビジョニングします。(VPC)を2つのゾーンにまたがるサブネットでプロビジョニングします。 フロントエンド・アプリとバックエンド・アプリの高可用性を確保するために、これらのゾーンに複数の VSI を作成します。
  • フロントエンド・アプリ用にパブリック・ロード・バランサー、バックエンド・アプリ用にプライベート・ロード・バランサーを構成して、ゾーン間の高可用性を提供します。
  • インスタンス・グループにインスタンスをプロビジョンするために使用するインスタンス・テンプレートを作成します。

スケーリングができるように、インフラストラクチャー・リソースすべてをデプロイするように設計した場合でも、最初からリソースすべてをデプロイする必要はありません。 以下に示すように、1 つまたは数個のインスタンスから開始することができます。

1 つの VSI のデプロイ
1 つの VSI のデプロイ

負荷が増えてくれば、トラフィックにサービスを提供するためにより多くのインスタンスが必要になります。 着信要求をインスタンス全体に等分に分散させるために、フロントエンド・アプリ用にパブリック・ロードバランサー、バックエンド・アプリ用にプライベート・ロード・バランサーを構成できます。 ロード・バランサーを使用すると、インスタンスに関連付けられたプール・メンバーに対して特定のヘルス・チェックを構成できます。

複数の VSI のデプロイ
複数の VSI のデプロイ

自動スケーリングのためにインスタンス・グループを作成するには、インスタンス・テンプレートが必要です。 インスタンス・テンプレートは、 インスタンス・グループのために作成される仮想サーバー・インスタンスの詳細を定義します。 例えば、イメージ・テンプレートのプロファイル (vCPU および メモリー)、イメージ、接続されるボリューム、およびネットワーク・インターフェースを指定します。 さらに、フロントエンドとバックエンドそれぞれのアプリケーションに必要な 初期化スクリプトを自動的に実行するために、'user data が指定されている。 インスタンス・グループのために作成されるすべての VSI は、インスタンス・グループで定義されているインスタンス・テンプレートを使用します。 スクリプトはインスタンス・テンプレートとインスタンス・グループ (フロントエンドとバックエンドに 1 つずつ) をプロビジョンしますが、このときはまだ自動スケーリング・ポリシーが定義されていません。 この例ではデータ・ボリュームを必要としないため、modules/create_vpc/autoscale/main.tf ibm_is_instance_group リソースでコメント化されます。

VPC はクラウド初期設定テクノロジーを使用して、仮想サーバー・インスタンスを構成します。 VPC ページの新規仮想サーバー上の user dataフィールドで、ユーザーはクラウド初期設定を使用してカスタム構成オプションを加えることができます。

インスタンス・グループの使用
インスタンス・グループの使用

リソースのプロビジョン

VSI に後で直接アクセスする場合は、オプションで SSH 鍵の作成 を使用し、ssh_keyname を VPC SSH 鍵の名前に設定することができます。

  1. Schematics ワークスペースの 「設定」 タブに移動し、step2_create_vpc のアクション・メニューをクリックし、「デフォルトを使用する」 チェック・マークを外し、オーバーライド値を true に変更してから設定を 「保存」 します。

  2. 「プランの適用」 をクリックして、VPC リソースをプロビジョンします。

    VPC リソースのプロビジョニングには、複数の Terraform モジュールが関与します。 よりよく理解するために、main.tfファイルをチェックしよう。

  3. 「詳細表示」 をクリックして、状況ログを確認します。 適用が成功すると、以下のリソースがプロビジョニングされたことが確認できるはずです：

    • 1 つの VPC

    • 2 つのサブネット (各ゾーンに 1 つずつ)

    • トラフィックをフロントエンド・アプリケーションに送り込む、セキュリティー・グループを備えたパブリック・ロード・バランサー

    • フロントエンドからバックエンドへ要求を送り込む、セキュリティー・グループを備えたプライベート・ロード・バランサー

    • インスタンスをプロビジョニングし、スケーリングするための、インスタンス・テンプレートとインスタンス・グループ

    • 最初は、2 つの VSI (フロントエンド・インスタンスとバックエンド・インスタンスがそれぞれ 1 つずつ) にそれぞれセキュリティー・グループが接続しています。

      フロントエンド・インスタンスは Nginx サーバーを実行することで、バックエンドと通信してデータを格納、取得する PHP Web アプリケーションにサービスを提供します。 バックエンド・インスタンスは、 IBM Cloud Databases for PostgreSQL および IBM Cloud Object Storage用の GraphQL API ラッパーを使用して Node.js アプリケーションを実行します。

  4. ログ出力からパブリック・ロード・バランサーのホスト名を コピー し、http:// と接頭語を付けてブラウザーにホスト名を貼り付け、フロントエンド・アプリケーションを調べます。 以下の図に示すように、バランス (10 など) を入力し、「送信」 をクリックして、要求を処理する VSI の詳細を調べます。

    アプリケーションの表示
    アプリケーションの表示

    プロビジョンした VPC リソースを確認するには、VPC UI を使用するか、または Cloud Shell で ibmcloud is コマンドを使用します。

次のセクションで、スケーリング・メソッド (静的または動的) を選択し、スケーリング・ポリシーを作成します。

インスタンス上の負荷を増やしてスケーリングを確認する

このセクションでは、最初に 「静的」 に指定したスケーリング・メソッドを使用して、インスタンスのスケーリングを開始します。 次に、インスタンス・マネージャーとインスタンス・グループ・マネージャー・ポリシーをセットアップして、動的 スケーリングによるインスタンスのスケーリングに移行します。 定義するターゲット使用率メトリックに基づいて、指定されたインスタンスの可用性を実現するために、インスタンス・グループではインスタンスが動的に追加または削除されます。

手動スケーリング

  1. 静的 スケーリング・メソッドを確認するには、Schematics ワークスペースの 「設定」 タブに移動して、step3_is_dynamic 変数が false に設定されていることを確認します。
  2. step3_instance_count 変数を'2 に更新し、設定を保存する。
  3. プランを適用して、追加の 2 つのインスタンス (フロントエンド VSI とバックエンド VSI がそれぞれ 1 つ) がプロビジョンされていることを確認します。
  4. フロントエンドインスタンスグループ の Memberships タブに、'2 インスタンスが表示されているはずです。
  5. フロントエンド・アプリを表示しているブラウザーにナビゲートし、「最新表示」 ボタンをクリックするか、新しいバランスを複数回 「送信」 して、要求を処理するフロントエンド VSI とバックエンド VSI の詳細を調べます。 4 つの VSI のうち 2 つが、要求を処理していることがわかります。
  6. 次のステップに進む前に、 step3_instance_count 変数を 2 から 1 に更新し、設定を 「保存」 します。

このチュートリアルでは、後で、ログを確認し、ロード・バランサーのモニタリングを行うことができます。

自動スケーリング

  1. 動的 スケーリング・メソッドに切り替えるには、step3_is_dynamic 変数を true に設定し、設定を 「保存」 してからプランを 「適用」 します。 この設定により、インスタンス・グループ・マネージャーとインスタンス・グループ・マネージャー・ポリシーが既存のインスタンス・グループに追加されます。これにより、インスタンス・グループ・スケーリング方式が static から dynamic に切り替わります。

    「スケール・インスタンス」
    「スケール・インスタンス」

  2. オートスケーリング機能をチェックするには、アプリケーションに対してロードジェネレーターを使用することができます。 以下のシェル・スクリプトは、並行して最大 300 個の 90000 要求の基本ロードをシミュレートします。

    1. ローカル端末を開きます。

    2. 上記のステップで、/v1/controller/balance.php を付加したパブリックロードバランサーのURLのシェル変数を作成します。

      export APPURL=http://<load-balancer>/v1/controller/balance.php

    3. 以下のスクリプトを実行して、何らかの負荷を生成します。 これを繰り返して、より多くのトラフィックを作成することができます。 [1-1000] 各curl呼び出しに、その数だけGETするよう求める。 --retry、seq コマンドの各番号をキャプチャする。

      seq 1 1000 | xargs -n1 -P100  curl -s $APPURL/"[1-1000]" -o /dev/null --retry

  3. インスタンス グループの [Memberships] タブに、新しいインスタンスがプロビジョニングされているのが表示されているはずです。

    最大メンバーシップ数が 5 に設定されているため、最大 5 個のインスタンスがロードされます。 インスタンス・グループの Overview タブで、インスタンス・グループの最小サイズと最大サイズを確認できます。

  4. フロントエンド・アプリを表示しているブラウザーにナビゲートし、バランスを複数回 「送信」 して、要求を処理するフロントエンド VSI とバックエンド VSI の詳細を調べます。

    インスタンスのスケーリングが完了するのを待ちます。集約期間は 90 seconds、クールダウン期間は 120 seconds に設定されています。

  5. インスタンスが 1 にスケーリングされるのを待ってから、次のステップに進んでください。

スケジュールされたアクション (オプション)

このセクションでは、VPC に対してスケジュールされたスケーリングを使用して、日常の需要、一時的な需要、または季節的な需要に基づいて、インスタンス・グループの容量を自動的に追加または削除するアクションをスケジュールします。 容量を月ごと、週ごと、日ごと、1 時間ごと、または設定された分数ごとにスケーリングする、複数のスケジュールされたアクションを作成できます。 このセクションはオプションであり、このチュートリアルの残りの部分を完了するために必須ではありません。

  1. 1 回限りのスケジュールされたアクションを作成するには、step3_is_scheduled 変数を true に設定し、設定を 「保存」 してからプランを 「適用」 します。
  2. スケジュールされたアクションの状況は、インスタンス・グループの 「スケジュール済みアクション (scheduled actions)」 タブで確認します。 Terraform テンプレートは、プランを適用した時点から 5 分間アクションをスケジュールします。 アクションの状況がcompletedに変わったら、インスタンス・グループは最小サイズが 2 インスタンス、最大サイズが 5 インスタンスに設定されます。 インスタンス・グループの2「メンバーシップ」 タブには、 つのインスタンスが表示されているはずです。
  3. 「負荷の生成 (Generate load)」 を 2、3 回クリックして、より多くのトラフィックを生成し、インスタンスが最大数の 5 にスケーリングされることを確認します。

VPC のロード・バランサーのメトリックのモニタリング

ロード・バランサーがメトリックを計算し、モニター・インスタンスにそれらのメトリックを送信すると、モニター・インスタンスで、さまざまなタイプの使用状況とトラフィックが表示されます。 メトリックの視覚化と分析は、IBM Cloud Monitoring ダッシュボードから行うことができます。

  1. ロード・バランサーのモニタリングは、「VPC のロード・バランサー (Load balancers for VPC)」ページから実行できます。次の手順を実行します。
    1. ロード・バランサーの 名前 をクリックします。
    2. ロード・バランサーのMonitoring previewタイルで、「モニタリングの起動」 をクリックします。
  2. または、「プログラム識別情報」ページにナビゲートして左側の 「モニタリング」 をクリックして、ロード・バランサーをモニターすることもできます。
    1. インスタンスをクリック
    2. のマークが付いたインスタンスの横の 「ダッシュボードを開く」Platform metricsをクリックします。
    3. 左サイドバーのダッシュボードをクリックして、IBMLoad Balancer for VPC Monitoring Metrics ダッシュボードを開きます。
    4. ダッシュボードのテンプレートで、IBM> Load Balancer for VPC Monitoring Metrics を展開します。 デフォルトのダッシュボードは編集できません。
  3. アプリケーションに対して負荷を生成することを忘れないでください。

ログの確認

VPC サービスにより、これらのサービスが使用可能なリージョンと同じリージョンにプラットフォーム・ログが生成されます。 プラットフォーム・ログは、IBM Cloud のロギング対応サービスとプラットフォームから公開されるログです。 詳細については、IBM Cloudプラットフォームログ の構成 を参照してください

  1. Observability ページに移動し、左ペインの Logging > Instanesをcクリックします。
  2. ペイン上部の Cloud Logs をクリックします
  3. 先ほどログをキャプチャするように設定したインスタンスの横にある「Open dashboard」をクリックする。
  4. 左側のツールセレクタで「Explore logs（ログを調べる）」 > 「Logs（ログ）」をクリックします。
  5. 検索バーにロードバランサーのCRNをペーストしてログを見る。

他の VPC リソースのログを確認する方法については、『VPC ロギング』を参照してください。

専用ホストをセットアップし、暗号化されたデータ・ボリュームを持つ VSI をプロビジョンする

専用ホストをプロビジョニングするには、費用が発生します。 コスト見積もりツールを使用して、予測使用量に基づいてコスト見積もりを生成します。

このセクションでは、グループ内に専用ホストを作成し、暗号化されたデータ・ボリュームを持つインスタンスをプロビジョンします。

専用ホストを作成する理由は、シングル・テナントのコンピュート・ノードを確立し、組織外のユーザーからの接続を回避するためです。 その専用スペース内で、 必要に応じて、仮想サーバー・インスタンスを作成できます。 また、特定の目的のために、専用ホストを含む専用ホスト・グループを作成することもできます。 専用ホストはシングル・テナント・スペースであるため、アカウント内の必要な許可を持つユーザーのみが ホストにインスタンスを作成できます。

  1. Schematics ワークスペースの 「設定」 タブにナビゲートし、step4_create_dedicated 変数を true に更新してから設定を 「保存」 します。

  2. 「プランを適用 (Apply the plan)」 をクリックして、次のリソースをプロビジョンします。

    • 専用ホスト・グループ
    • 専用ホスト
    • 暗号化データ・ボリューム (IBM Key Protect for IBM Cloud を使用した暗号化) を備え、セキュリティー・グループが接続された VSI。

    専用ホストの追加
    専用ホストの追加

  3. ログ出力から、インスタンス IP アドレスを コピー し、Cloud Shell を起動して、プレースホルダー <IP_ADDRESS> をインスタンス IP アドレスに置き換えて以下のコマンドを実行します。

    export INSTANCE_IP=<IP_ADDRESS>

    一般的に、インスタンスにはパブリック IP (浮動 IP) を設定しません。 この場合、浮動 IP は、インスタンスにデプロイされたアプリに対して curl を許可するように設定されます。

  4. 以下の curl コマンドを実行して、データベースを照会します。 インスタンスで実行されているアプリケーションは、プライベート・エンドポイントを介して Databases for PostgreSQL からコンテンツを読み取ります。 このデータは、フロントエンド・アプリケーションから入手できるデータと同じです。

    curl \
-s -X POST \
-H "Content-Type: application/json" \
--data '{ "query": "query read_database { read_database { id balance transactiontime } }" }' \
http://$INSTANCE_IP/api/bank

  5. 以下の curl コマンドを実行して COS バケットを照会します。 インスタンスで実行されているアプリケーションは、Object Storage からコンテンツを読み取り、結果を JSON 形式で返します。 COS に保管されているデータは、専用ホスト上のインスタンスから実行されているアプリケーションでのみ使用できます。

    curl \
-s -X POST \
-H "Content-Type: application/json" \
--data '{ "query": "query read_items { read_items { key size modified } }" }' \
http://$INSTANCE_IP/api/bank

  6. 以下の curl コマンドを実行して、データベースと COS バケットを同時に照会します。 インスタンスで実行されているアプリケーションは Databases for PostgreSQL および Object Storage からコンテンツを読み取り、結果を JSON 形式で返します。

    curl \
-s -X POST \
-H "Content-Type: application/json" \
--data '{ "query": "query read_database_and_items { read_database { id balance transactiontime } read_items { key size modified } }" }' \
http://$INSTANCE_IP/api/bank

VSI のサイズを変更し、専用ホスト上でアタッチされたブロック・ストレージ・ボリュームを拡張します。

専用ホストにプロビジョンされたインスタンスのプロファイルを調べると、cx2-2x4 に設定されています。ここで、c は コンピュート ・ファミリー (カテゴリー) を表し、2 つの CPU と 4 GiB の RAM を持っています。 このセクションでは、プロファイルを cx2-8x16 (8 つの vCPU と 16 GiB の RAM) に更新してインスタンスのサイズを変更します。

このセクションでは、VSI にアタッチされたブロック・ストレージ・ボリュームも 100 GB から 250 GB に拡張します。 選択したボリューム・プロファイルでの最大容量について詳しくは、ブロック・ストレージ・ボリュームの容量の拡張を参照してください。

VSI のサイズを変更する

  1. VSI をサイズ変更するには、Schematics ワークスペースの 「設定」 タブにナビゲートし、step5_resize_dedicated_instance 変数を true に更新してから設定を 「保存」 します。

    仮想サーバーは、インスタンスがホストされている専用ホストがサポートするプロファイルにのみ、サイズを変更できます。 例えば、コンピュート型ファミリーのプロファイルを使用してプロビジョンされた仮想サーバーは、コンピュート型ファミリーに属する他のプロファイルにサイズを変更できます。 プロファイルについて詳しくは、インスタンス・プロファイルを参照してください。

  2. 「プランを適用 (Apply the plan)」 してインスタンスのサイズを 2 VCPUs | 4 GiB RAM から 8 VCPUs | 16 GiB RAM に変更します。

  3. インスタンスのプロファイルを確認するには、Cloud Shellを起動し、リージョンを、ibmcloud target -r us-south コマンドを使用して VPC をプロビジョンしたリージョンに変更して ibmcloud is instances コマンドを実行するか、または、VPC の仮想サーバー・インスタンス UI から専用インスタンス名をクリックして確認できます。

ブロック・ストレージ・ボリュームの容量の拡張

  1. 接続されているブロック・ストレージ・ボリュームの容量を展開するには、Schematics ワークスペースの 「設定」 タブにナビゲートし、step5_resize_dedicated_instance_volume 変数を true に更新してから設定を 「保存」 します。
  2. プランを適用して 、ブロック・ストレージ・ボリュームの容量を 100 GB から 250 GB に拡張します。
  3. Data volumeのサイズを VPC の仮想サーバー・インスタンス UI から確認するには、専用インスタンスの名前をクリックします。

次のステップ

SSL 終端、スティッキー・セッション、エンドツーエンドの暗号化を構成して、シナリオを拡張します。 詳細はこちらの ブログ記事を参照。

リソースを削除する

Schematics ワークスペースとそのリソースを削除するには、以下のステップを実行します。

  1. Schematics ワークスペースに移動して、ご使用のワークスペースを選択します。
  2. Actions... ドロップダウンをクリックし、Destroy resources をクリックして、Schematics経由でプロビジョニングされたすべてのリソースをクリーンアップする。
  3. 「アクション...」 ドロップダウンをクリックし、「ワークスペースの削除」 をクリックしてワークスペースを削除します。

リソースによっては、即時に削除されずに保持される場合があります (デフォルトでは 7 日間)。 リソースを完全に削除して再利用することも、保存期間内に復元することもできます。 リソースの再利用を使用する方法については、この資料を参照してください。