カオスエンジニアリング導入の試み

はじめに

こんにちは、Lernaチームの山田です。

私たちは分散システムの実際に起こりうる障害時の挙動を明らかにして耐障害性を高める機会を作り出すために、カオスエンジニアリングの導入を考えています。

この記事ではカオスエンジニアリング導入のために私たちがおこなったツール選定や環境構築について紹介したいと思います。

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

カオスエンジニアリングとはNetflixから発祥したもので、その定義はPRINCIPLES OF CHAOS ENGINEERINGにまとめられています。

カオスエンジニアリングの大まかな流れは以下のようなものになります。

1. 実験対象のシステムの定常状態（システムの正常な状態を示す測定可能な指標）を定義
2. 実際におこりうるイベント（ハードウェアの故障やネットワーク障害など）が発生した際にシステムが定常状態を維持し続けるという仮説を立てる
3. 実際にイベントを発生させて仮説検証

カオスエンジニアリングツールの選定

カオスエンジニアリングを実現するツールとしてSaaS形式のGremlin、AWSやAzureなどのクラウドに付随したサービスのAWS FISやAzure Chaos StudioとKubernetesネイティブなツールのChaos MeshやLitmusなどがあります。代表的なツールに関する簡単な説明と比較はGremlinが公開しているChaos Engineering tools comparisonが参考になります。

それらのツールの中から私たちはChaos Toolkitを選択しました。Chaos Toolkitの特徴は以下の表に示したものなどがあります。

ツールを選択する際に、いくつかの評価観点の中から私たちがもっとも重視した観点は以下の2つです。

• 対応環境
• コスト

対応環境

私が勤めている会社ではオンプレやクラウド（おもにAWS）などさまざまなプラットフォームでシステムが構築されており、それらの環境に汎用的にカオスエンジニアリングを導入できるツールを選択する必要があります。そのため、各クラウドに付随するサービス（AWS FISやAzure Chaos Studioなど）やKubernetesネイティブなツール（Chaos MeshやLitmusなど）など特定の環境にのみ対応したツールは候補から除外しました。

Chaos Toolkitはその他のツールと異なり障害注入の機能などがあらかじめ用意されていませんが、既存の拡張を利用するか独自の拡張を作成することであらゆる環境に対応することが可能です。既存の拡張としてはAWSなどの各種プラットフォームに対応するものやGrafanaなどの可視化ツールと連携するものなどがあります。くわしくはChaos Toolkitのドキュメントを参照してください。

コスト

Chaos Toolkit以外で多様な環境に対応可能なツールとしてGremlinがあげられます。Gremlinは多様な環境で動作が確認されており、基本的な障害注入方法もサポートされています。しかし、Gremlinは有償ツールなので、導入するプロジェクトによってはコストがネックになり採用できないということがありえるため候補から除外しました。

Chaos ToolkitはOSSとして公開されているのでコストがネックになることはありません。

UIによる操作容易性、学習コストや企業のサポートなどを重視するのであればGremlinを導入するほうが良いかもしれません。

カオスエンジニアリング環境の構築

Chaos Toolkitは実験シナリオの大枠を記述し実行することが可能ですが、シナリオ内で注入する障害の実装や実験中のシステムの観測はChaos Toolkitの拡張や外部ツールとの連携で対応する必要があります。

以下にChaos Toolkitを利用する際のカオスエンジニアリング環境全体の構成例と利用する各ツールの役割などについて示します。この構成は本番環境よりも前の環境（開発環境など）で利用して、測定可能な定常状態としてThe Four Golden Signalsのメトリクスを取得することを想定しています。

本番環境か開発環境か

カオスエンジニアリングの原則では、システムのふるまいは環境とトラフィックパターンに依存するため実際の本番環境で実験をおこなうことを強く推奨しています。しかし、カオスエンジニアリングに慣れていない人たちがいきなり本番環境に実験環境を構築して実験をおこなうのはリスクが大きいため、私たちはまずは開発環境にカオスエンジニアリングを導入することを考えています。

開発環境でのカオスエンジニアリングを価値あるものにするためには、できる限り開発環境を本番環境に近づける必要があります。

定常状態の確認

この構成では汎用的な定常状態としてGolden Signalsを測定します。Golden SignalsはRed Method（レイテンシ、トラフィック、エラー）とサチュレーションの4つのメトリクスを指します。この構成例ではRED MethodをJMeterとInfluxDBで計測しサチュレーションをNode exporterとPrometheusで計測できます。Golden Signalsを観測することでカオス実験中のシステムの状態を監視することができ、実験中の挙動が想定内のものかどうか判断することに利用できます。

当初は上記以外の定常状態としてデータの整合性を検証する方法を汎用化して提供できないか模索していました。しかし、異なるシステムの異なる要件の整合性の検証を汎用的におこなうことは困難なため、ツールで汎用的な機能を提供するのではなく利用者ごとに実装やオペレーションを用意するしかないという結論に至りました。

苦労した点

Grafana、Grafana LokiやInfluxDBなどデータ収集に利用するツールに関しては公式のDocker imageがあり、基本的には設定ファイルを用意するだけで動作させることができるため、ツールを起動したり連携したりする点においてはそれほど苦労しませんでした。

環境構築において苦労したのは主に以下の2点です。

• 障害注入機能の実装
• InfluxDBでのメトリクス算出

障害注入機能の実装

Chaos Toolkitは基本的にはカオス実験のシナリオを記述するための機能のみ提供しているため、Gremlinなどのツールが提供しているCPU負荷やネットワーク障害のシミュレーションをおこなうには独自の実装を行う必要があります。

私は今回の環境構築を行うに際してGremlinで提供している障害注入機能と同等な機能を提供するChaos Toolkitの拡張を実装しています。独自の拡張では、障害注入対象のシステムにSSHで接続してstress-ngやtc、iptablesなどのLinuxコマンドを利用してCPU負荷やネットワーク障害をシミュレーションします。

障害注入機能の中でもネットワーク遅延やパケットロスを発生させるための実装には苦労しましたが、ネットワーク障害をシミュレーションするOSSを参考にしてtcコマンドとiptablesコマンドを利用した実装のイメージを固めることができました。

InfluxDBでのメトリクス算出

InfluxDBのデータを分析するために利用するクエリ言語のFluxは柔軟にデータ解析を行うことができますが、初見の私にとっては難しく、JMeterの実行結果から任意の時間幅でレイテンシやエラー率を計算するクエリを作成するのに苦労しました。

まとめ

Chaos ToolkitとGrafanaやJMeterなどを組み合わせることでカオスエンジニアリング実行環境を構築することができました。拡張性の高いChaos Toolkitで幅広いシステムに対応可能で、Golden Signalsを定常状態としてすぐに利用できます。

今後は社内の実際のプロジェクトの開発環境への導入を目指しています。