学習パス: スケーラブルなアプリケーション - 障害をシミュレートする

このチュートリアルは、Google Kubernetes Engine（GKE）Enterprise エディションで実行される最新のアプリケーション環境をデプロイ、実行、管理することを目的とする IT 管理者とオペレーターを対象としています。このチュートリアルでは、Cymbal Bank サンプル マイクロサービス アプリケーションを使用して、モニタリングとアラートの構成、ワークロードのスケーリング、障害のシミュレーションの方法を学習します。

  1. クラスタを作成してサンプル アプリケーションをデプロイする
  2. Google Cloud Managed Service for Prometheus でモニタリングする
  3. ワークロードのスケーリング
  4. 障害をシミュレートする（このチュートリアル）

概要と目的

アプリケーションは、停止や障害を許容できる必要があります。この機能により、問題が発生してもユーザーは引き続きアプリにアクセスできます。Cymbal Bank サンプル アプリケーションは、障害を処理して実行を継続するように設計されています。トラブルシューティングや修正を行う必要はありません。この回復力を実現するために、GKE リージョン クラスタはコンピューティング ノードをゾーン全体に分散し、Kubernetes コントローラはクラスタ内のサービス問題に自動的に応答します。

このチュートリアルでは、Google Cloud で障害をシミュレートし、Google Kubernetes Engine（GKE）Enterprise エディション クラスタ内のアプリケーション サービスがどのように応答するかを確認します。次のタスクを完了する方法を学習します。

  • ノードとサービスの分布を確認します。
  • ノードまたはゾーンの障害をシミュレートします。
  • 残りのノードでもサービスが引き続き実行されていることを確認します。

費用

このチュートリアル シリーズで GKE Enterprise を有効にして Cymbal Bank サンプル アプリケーションをデプロイすると、GKE Enterprise を無効にするか、プロジェクトを削除するまで、料金ページに記載されているように、Google Cloud の GKE Enterprise に対してクラスタごとの料金が発生します。

また、Compute Engine VM の費用など、Cymbal Bank サンプル アプリケーションの実行中に発生した他の Google Cloud の費用もお客様の負担となります。

始める前に

障害をシミュレートする方法については、最初のチュートリアルを完了して、Autopilot を使用する GKE クラスタを作成し、Cymbal Bank のサンプル マイクロサービス ベースのアプリケーションをデプロイする必要があります。

Cymbal Bank のチュートリアルは順番に完了することをおすすめします。チュートリアルを進めていくと、新しいスキルを習得し、追加の Google Cloud プロダクトとサービスを使用できるようになります。

ノードとサービスの分布を確認する

Google Cloud では、リージョンはリソースをホストできる特定の地理的な場所を意味します。リージョンには 3 つ以上のゾーンがあります。たとえば、us-central1 リージョンは、us-central1-a、us-central1-b、us-central1-c などの複数のゾーンを含む米国中西部のリージョンを示します。ゾーンは、帯域幅が広くレイテンシが低いネットワークで同じリージョンの他のゾーンと接続されています。

高可用性のフォールト トレラントなアプリケーションをデプロイするには、複数のゾーンと複数のリージョンにアプリケーションをデプロイすることをおすすめします。この方法により、ゾーンまたはリージョンまでの規模で、予期しないコンポーネント障害の影響を受けにくくなります。

最初のチュートリアルで GKE Enterprise クラスタを作成したとき、いくつかのデフォルト設定値が使用されました。デフォルトでは、Autopilot を使用する GKE Enterprise クラスタは、指定したリージョンのゾーンにまたがるノードを作成して実行します。このアプローチでは、Cymbal Bank サンプル アプリケーションが複数のゾーンにすでにデプロイされているため、予期しない障害から保護されます。

  1. GKE Enterprise クラスタ全体のノードの分布を確認します。

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'

    結果は次の出力例のようになります。この例では、ノードがリージョン内の 3 つのゾーンに分散されています。

    NAME                         ZONE            INT_IP
scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
scalable-apps-pool-2-node4   us-central1-b   10.148.0.4

  2. GKE Enterprise クラスタノード全体での Cymbal Bank サンプル アプリケーション サービスの分散を確認します。

    kubectl get pods -o wide

    次の出力例は、サービスがクラスタ内のノードに分散されていることを示しています。前述のノード分散の確認手順から、この出力は、サービスがリージョン内のゾーン全体で実行されていることを示しています。

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1

停止のシミュレーションを行う

Google では、電力、冷却機能、ネットワーキングなどの物理インフラストラクチャの停止によって引き起こされる、連動障害のリスクを最小限に抑えるようにゾーンを設計しています。ただし、予期しない問題が発生する可能性があります。ノードまたはゾーンが使用できなくなった場合、サービスは他のノードまたは同じリージョンのゾーンで引き続き実行されます。

Kubernetes コントローラは、クラスタ内のノード、Service、Deployment のステータスをモニタリングします。予期しない停止が発生した場合、コントローラは影響を受けたリソースを再起動し、トラフィックを動作しているノードにルーティングします。

このチュートリアルでは、障害をシミュレートするために、ゾーンのいずれかでノードを閉鎖してドレインします。この方法では、ノードで障害が発生した場合や、ゾーン全体で問題が発生した場合に何が起こるかをシミュレートします。Kubernetes コントローラは、一部のサービスが使用できなくなり、他のゾーンのノードで再起動する必要があることを確認する必要があります。

  • ゾーンのいずれかでノードを閉鎖してドレインします。次の例では、us-central1-a の 2 つのノードをターゲットとしています。

    kubectl drain scalable-apps-pool-2-node1 \
    --delete-emptydir-data --ignore-daemonsets

kubectl drain scalable-apps-pool-2-node2 \
    --delete-emptydir-data --ignore-daemonsets

    このコマンドは、ノードがスケジュール不可としてマークするため、Pod がこれらのノードで実行されないようにします。Kubernetes は、機能するゾーンの他のノードに Pod を再スケジュールします。

シミュレートされた失敗のレスポンスを確認する

このシリーズの以前のチュートリアルでは、GKE Enterprise クラスタのマネージド Prometheus インスタンスを設定して一部のサービスをモニタリングし、問題が発生した場合にアラートを生成する方法を学習しました。障害をシミュレートしたゾーンのノードで Pod が実行されていた場合、Prometheus によって生成されたアラートから Slack の通知メッセージを受け取ります。この動作は、デプロイの健全性をモニタリングし、問題が発生した場合にアラートを送信し、負荷の変化や障害を自動的に調整する最新のアプリケーション環境を構築する方法を示しています。

GKE Enterprise クラスタは、シミュレートされた停止に自動的に応答します。影響を受けるノードのサービスは、残りのノードで再起動されます。

  1. GKE Enterprise クラスタ全体のノードの分布をもう一度確認します。

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'

    結果は次の出力例のようになります。この例では、ノードがリージョン内の 2 つのゾーンに分散されています。

    NAME                         ZONE            INT_IP
scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
scalable-apps-pool-2-node4   us-central1-b   10.148.0.4

  2. Kubernetes コントローラは、2 つのノードが使用できなくなったことを認識し、使用可能なノードにサービスを再分配します。すべてのサービスは引き続き実行されます。

    GKE Enterprise クラスタノード全体での Cymbal Bank サンプル アプリケーション サービスの分散を確認します。

    kubectl get pods -o wide

    次の出力例は、Service がクラスタ内の残りのノードに分散されていることを示しています。前のステップでノードの分散を確認した結果、この出力では、サービスがリージョン内の 2 つのゾーンでのみ実行されていることが示されています。

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1

  3. サービスの AGE を確認します。上記の出力例では、Cymbal Bank サンプル アプリケーションで、一部のサービスが他のサービスよりも若い年齢になっています。これらの新しいサービスは、以前に障害をシミュレートしたノード上で実行されていました。Kubernetes コントローラが、使用可能なノードでこれらのサービスを再起動しました。

実際のシナリオでは、問題のトラブルシューティングを行うか、根本的なメンテナンスの問題が解決するのを待つ必要があります。アラートに基づいて Slack メッセージを送信するように Prometheus を設定した場合、これらの通知が表示されます。必要に応じて、前回のチュートリアルのリソースをスケーリングする手順から繰り返して、リージョンで使用可能なゾーンが 2 つしかない場合に、GKE Enterprise クラスタが負荷の増加にどのように対応するかを確認することもできます。クラスタは、残りの 2 つのゾーンで利用可能な状態でスケールアップする必要があります。

クリーンアップ

このチュートリアルで使用したリソースに対して Google Cloud アカウントに課金されないようにするには、作成したプロジェクトを削除します。

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

このチュートリアルで学習したクラスタ環境に似た独自の GKE Enterprise クラスタ環境の作成を開始する前に、本番環境に関する考慮事項を確認してください。