カオスエンジニアリングのOSS、LitmusChaosの概要を解説するCNCFのウェビナーを紹介

Cloud Native Computing Foundation（CNCF）のウェビナーから、LitmusChaosを使ったカオスエンジニアリングを解説する動画を紹介する。セッションを行ったのはInfraCloud TechnologiesのシニアSRE、Ruturaj Kadikar氏で、セッションのタイトルは「Testing Resiliency - chaos engineering with LitmusChaos」だ。

セッションは48分という長いものだが、前半の15分はコンピュータシステム、特にインフラストラクチャー領域で発生するさまざまな障害について概観するもので、LitmusChaosによるソリューションを知りたいのであれば最初の15分間はスキップすることをお勧めする。途中で音声が切れる不具合も発生しており、音声の品質が良くないことも合わせて閲覧する場合は字幕をONにすることを推奨する。

●動画：Testing resiliency: Chaos Engineering with LitmusChaos

セッションを行うKadikar氏

障害の概要を終えた後にカオスエンジニアリングについての解説が始まる。

カオスエンジニアリングとは？

ここではカオスエンジニアリングの実施に必要なポイントとして、以下の4つ挙げている。

• システムの状態が安定していると仮定すること
• どこで障害を起こすのかを認識すること
• 実験すること
• 被害が及ぶ領域を限定すること

カオスエンジニアリングの4つのポイント

その上で現在、利用可能なツールを紹介した。ここではLitmusChaosの他にGremlin、ChaosMonkey、Chaos Mesh、そしてAWSのFIS（Fault Injection Simulator）が紹介されている。

カオスエンジニアリングのためのツールを紹介

そして今回利用するツールとなったLitmusChaosを改めて紹介した。LitmusChaosを選択した理由は、オープンソースであること、分散型による実装も集中型でも利用可能であること、柔軟であること、そしてAWSのSSM（Systems Manager）と連携できることを挙げている。特にSSMとの連携は、AWSユーザーであればその意味は大きいということだろう。そのことは最後のデモで紹介されている。

LitmusChaosを選択した理由。AWSとの連携が意外と重要なようだ

そしてカオスエンジニアリングによるレジリエンシーフレームワークを使って仮定を立て、その上で障害を起こし、状態を復帰、影響を計測して判定するという一連の流れを説明した。ここでは単に障害を起こすだけではなく元の状態に復帰する機能が提示されていることに注目したい。以前、インフラストラクチャーのエンジニアのコメントとして、「カオスエンジニアリングという名前が登場する前から障害対応のひとつとして障害を起こす演習は行われてきたが、元の状態に復帰するのが面倒なので次第にやらなくなった、最近のシステムは複雑なのでさらに難しくなっていると思う」という意見を聞いたことがあるが、意図的に障害を起こし、それを復帰するまでが機能として備わっているのであれば、前述したような認識も変わるのではないだろうか。

レジリエンシーフレームワークの解説。復帰させることが含まれていることに注目

そしてここからはAWSのコンソール、LitmusChaosのコンソールを使って実際にデモを見せて解説するフェーズに移った。

AWSのインスタンス上にKubernetesのクラスターを実装

そしてLitmusChaosについてはローカルのノートブックからダッシュボードを実行してデモを行った。

ChaosCenterというコンソールを使って不具合を実行

ここでは新しいカオスシナリオが作られるようすをデモで見せている。メモリーが不足する状況を作り出して、システムがどのように対応するのかを観測するのが目的だ。

カオスシナリオで実験を作成。メモリー不足になる状況を起こす

システムの観測にはKubernetesでは標準であるPrometheus、可視化にはGrafanaを使ってデモを実行する。

Grafanaでシステムの状態を可視化

カオスシナリオはワークフローとして定義され、実行がモニタリングできる。最後のプロセスに変更を元に戻すプロセスがあるのがわかる。

カオスシナリオの実行状態をモニタリング

この後はPodのアクセス権限を変更してPingが到達しないというシナリオを実行してみせたが、AWSのSSM（Systems Manager）から出力されたYAMLファイルを使って設定変更のシナリオに使うところを見せ、AWSユーザーにとっては使い勝手の良いツールであることを示した。

AWS SSMとの連携もデモで実施

ここまででLitmusChaosを使ったカオスエンジニアリングの解説とデモは終了したが、あくまでもツールの機能紹介で終わっているのが残念だ。これからカオスエンジニアリングを試してみたいユーザーは、カオスシナリオを適用して問題がなかったという成功体験が見たいのではない。問題があった時に何をするべきかの知見、カオスエンジニアリングに適したもしくは適さない使い方や領域はどこか、復旧が失敗した時にはどこから手を付けるべきなのか、どの程度の周期で実施するべきなのか、カオスエンジニアリングのツールやオブザーバービリティのツールが問題を起こした時はどうするべきなのか…… こういった知見こそが求められているのではないだろうか。カオスエンジニアリングのユーザーが拡がり、成功事例や失敗談が充実してくることを期待したい。

●参考：LitmusChaos公式ページ：https://litmuschaos.io/
●LitmusChaosのGitHubページ：https://github.com/litmuschaos/litmus