Litmusを使ったカオスエンジニアリング：CNCFインキュベートプロジェクト

問題の声明：マイクロサービスベースのeコマースプラットフォームの弾力性を確保する。

システムの弾力性は、ユーザーに優れたパフォーマンスを提供し、サービスを稼働させ続けるために、eコマースプラットフォームにおいてスケーリング操作中に重要な要件となります。私たちは、マイクロサービスアーキテクチャのプラットフォームを開発しましたが、ピーク時のトラフィックイベントに直面する際に断続的なシステム障害に遭遇します。Kubernetesポッドのクラッシュ、リソースの枯渇、ネットワークの障害などが主な原因であり、これらがピークのショッピングシーズン中に起こり、サービス可用性の低下や収益への影響といった問題が生じます。

組織は、CNCFでインキュベートされたプロジェクトLitmusを利用して、プラットフォームの評価と弾力性の向上を行う予定です。Litmusを使用してシミュレートされた障害テストを実施することで、システムの弱点が明確になります。これにより、ポッドの終了イベントやネットワークの遅延、リソース使用量の制限など、実世界の障害状況を引き起こすことができます。これらの実験により、スケーラビリティの自動化システムを検証し、災害復旧手順をテストし、Kubernetesの設定を最適化して、システム全体の信頼性を向上させることができます。

このシステムは、障害状況に耐える堅固な基盤を作り、利用者の体験品質を損なうことなく、忙しいトラフィック期間を安全に分散させることができます。インフラストラクチャに予防的に適用されたカオスエンジニアリングにより、リスクを軽減し、観測性を向上させることができます。これにより、プラットフォームのeコマースの弾力性をあらゆる運用条件に対して向上させる自動回復手法の開発が可能となります。

カオス実験環境を設定する

KubernetesクラスターにLitmusChaosをインストールしてください：

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

インストールを確認:

kubectl get pods -n litmus

注意: クラスターが混乱実験に対して準備ができていることを確認してください。

混乱実験を定義する

Podの削除シナリオをシミュレートするChaosExperiment YAMLファイルを作成する

例（pod-delete.yaml）:

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

ChaosOperatorをインストールしてサービスアカウントを構成する

実験を管理するためにChaosOperatorをデプロイする:

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

注意: 必要な権限を付与するためにServiceAccountを作成してください。

ターゲットアプリケーションに混乱を注入する

混乱を引き起こすためにアプリケーションの名前空間にラベルを付ける

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

実験をトリガーするChaosEngineをデプロイする

例（chaosengine.yaml）:

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

ChaosEngineを適用する

kubectl apply -f chaosengine.yaml

実験をモニタリングする

進捗状況を表示する

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

混乱ポッドのステータスを確認する

kubectl get pods -n <target-namespace>

結果を分析する

実験後、ログとメトリクスを確認してアプリケーションが自動的に回復したか、ストレス下で失敗したかを判断する

モニタリングすべきいくつかのメトリクス:

• アプリケーションの応答時間
• 実験中および後のエラーレート
• ポッドの回復にかかる時間

解決策

原因特定: 高トラフィック時に、デプロイメント内のレプリカ数が不十分であり、適切なリソース制限が不適切だったため、ポッドが失敗しました。

適用された修正:

• デプロイメント内のレプリカ数を増やして、高トラフィックを処理できるようにしました
• ポッド仕様書でCPUとメモリの適切なリソース要求と制限を設定しました
• トラフィックの急増を動的に処理するHorizontal Pod Autoscaler（HPA）を実装しました

結論

LitmusChaosを使用してポッドの障害をシミュレートすることで、eコマースプラットフォームのKubernetesデプロイメントの主要な弱点を特定しました。カオス実験は、スケーリングとリソース割り当ての調整によって耐久性を大幅に向上させることが示されました。カオスエンジニアリングにより、積極的なシステムの強化が可能となり、より良い稼働時間と顧客満足度を実現しました。