Google CloudにおけるカオスエンジニアリングBest Practiceを考える - ツール選定編
メディア統括本部 サービスリライアビリティグループ（SRG）の小原です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、Google Cloudでカオスエンジニアリングを実施するためのいくつかのツールについて紹介します。
はじめに
現在、SRGでは社内プロダクトへのカオスエンジニアリングソリューション開発・導入ミッションを進めていています。
タイトルについて、なぜGoogle Cloudに限定しているかというとAWSにはFault Injection Service、AzureにはChaos Studioといったマネージドなカオスエンジニアリングサービスがありますが、Google Cloudには現時点ではそういったサービスが存在していないからです。
Google Cloud上ではどのようなツールの選択肢があるか、それぞれのツールの機能についてまとめます。
想定される障害とカオスエンジニアリングツール選定の観点
具体的なツールの比較に入る前に、まず自分たちのプロダクトでどのような障害を想定し、どのコンポーネントを実験の対象とするかを整理します。
例えば、以下のようなシナリオが考えられます。
- LB障害
- VMやGKEクラスタ内のPodの障害
- ネットワーク遅延やロス
- Pod異常終了
- CPU, メモリリソース枯渇
- Disk異常
- 特定のリージョン、ゾーン障害
- マネージドサービス障害
- DB障害
- スロークエリ
- Disk異常
- ネットワーク異常（レプリケーション遅延やエラーなど）
- フェイルオーバー
単体障害に関してざっくりまとめるとこれくらいあるかと思います。複数の障害を組み合わせたシナリオも考えられますが、まずは小さく始めるために複雑なことは考慮しません。
次に、ツールに対する要件を整理します。
担当プロダクトごとにシステム構成など異なるので、環境に合わせて考えましょう。
- サポートするコンポーネント
- GKE、GCE、LB、DBなど対象としたい環境をサポートしているか。
- 障害注入シナリオの管理方法
- YAML/JSONファイル、Web UIなど、チームが運用しやすい方法で実験を定義できるか。
- 運用性
- 実行や導入、管理のしやすさ、学習コストはどの程度か。
これらを踏まえ、３つのツールを候補としました。
- Chaos Toolkit
- Chaos Mesh
- LitmusChaos
それぞれ以下に説明します。
Chaos Toolkit
Chaos Toolkitは、CLIで実行します。実験対象の環境に追加のリソースは不要です。
実験内容はJSON形式のファイルで宣言的に定義します。
各種クラウドサービスの拡張機能があり、豊富な障害注入が可能です。事前定義されたアクションはロールバック機能があるため、設定の戻し忘れも無しです。kubernetesネイティブなカオスエンジニアリングツールにはない、LBやCloud SQL、GCSへの障害注入といった広い範囲のコンポーネントをサポートしています。
実験ファイル内に独自のPython・シェルスクリプト、その他実行可能なコードを定義でき、柔軟に実験内容を管理できます。例えば、実験ファイルに動的に値を取得する処理を定義して実行できるので、JSONでも変数化してテンプレートのように管理できます。
Web UIは提供されていないため、実験の管理や結果の可視化には工夫が必要になります。
注意事項として、kubernetesの障害注入のための拡張機能もありますが、Chaos Meshの導入が必要になります。
Chaos Mesh
Chaos MeshはKubernetesネイティブなカオスエンジニアリングの管理基盤として非常に有名です。
Kubernetes上での利用を前提としており、Podの停止、ネットワークの遅延・切断、I/Oの遅延など、コンテナ環境の障害を簡単にシミュレートできます。
Operatorインストール用のHelmを利用して簡単に導入でき、実験タイプごとのカスタムリソースを定義・適用できます。実験用yamlをテンプレート管理するにはHelmやKustomizeを利用することを検討します。
Chaos Dashboardでは、直感的な操作でカオス実験の作成、実行、監視、管理が可能です。
手軽かつ強力にGKE環境へのカオスエンジニアリングを始めたい場合に最適な選択肢です。シンプル is 正義。
また、前述のChaos Toolkitでk8sへの障害注入を管理する場合の選択肢となります。
LitmusChaos
LitmusChaosも同様に、Kubernetesネイティブなカオスエンジニアリングの管理基盤です。
基本的なkubernetesへの障害注入機能は、Chaos Meshと同等のものが用意されています。加えて、ChaosHubという公開リポジトリ上にコミュニティによって作成された多種多様なカオス実験のテンプレートが登録されています。これらを活用してすぐに実験を開始できます。
LitmusChaosもHelmによる導入手段がありますが、Chaos Meshと比べると管理コンポーネントが多く、複雑になっています。
Controll Plane, Execution Planeの2種が存在し、１つのControll Planeでテスト対象のクラスタを複数管理できるようになっています。Controll Planeではワークフロー（複数の実験タイプを組み合わせたシナリオ）定義を管理するためのWebUI、履歴やターゲットクラスタ管理といった機能を提供しています。Execution Planeは実際にカオス実験を行うクラスタにインストールされ、障害注入処理を担います。
実験はArgo Workflowとして定義できます。実験を順次・並列実行したり、argo submitを利用して外部からパラメータを指定してテンプレート管理も可能です。さらに、Controll Planeのデプロイは必須ではなく、Execution Planeのみでのworkflow実行が可能であるため、小さく始めることができます。
GitOpsサポートもしていて、Kubernetesネイティブな開発スタイルを採用しているチームには馴染みやすいと思います。
どのツールを選ぶか
3つの候補のうち、Chaos ToolkitとLitmusChaosを利用することに決めました。
各ツールに対する所感をまとめると以下のようになります。
| ツール名 | 採用 | 理由 | 適した環境・ユースケース |
|---|---|---|---|
| Chaos Toolkit | 🆗 | LBへの障害注入が可能 | VM・Kubernetes以外の環境も対象に含めたい場合。 |
| Chaos Mesh | 🆖 | daemon setデプロイによるスケール時のコスト増 | GKE環境が中心で、シンプル・直感的な操作で多様な実験を行いたい場合。 |
| LitmusChaos | 🆗 | 小規模に始めることもでき、大規模管理まで可能 機能が豊富 | GKE環境が中心で、複数のクラスタ管理や複雑な実験を行いたい場合。 |
なお、障害シナリオに挙げていたマネージドサービスやDB障害について、ツールでの直接的な障害注入テストは難しいことがわかりました。そこでkubernetes上のアプリケーションPodからのネットワーク疎通不可やレイテンシー悪化といった実験で代用することを決めました。
まとめ
最適なツールは、対象システムのアーキテクチャやカオスエンジニアリングを通じて何を達成したいかによって異なります。
まずは小規模な実験から始め、自分たちのプロダクトに最適なツールと運用方法を見つけていくのが良いでしょう。
終わりに
Google Cloudでカオスエンジニアリングを導入するためのツールについて紹介しました。
次回は実際にツールを使ったカオステストのやり方や、遭遇したツールの問題について書こうと思います。
SRGにご興味ありましたらぜひこちらからご連絡ください。