マイクロサービスのカオステスト

世界は生まれながらにしてカオスである。このカオスを扱えるよう、私たちは自らのシステムを計画し、テストしなくてはならない。Rachel Reese氏は最近のQCon Londonにおいて、2015年7月に立ち上げたイーコマース会社Jetが、どのようにマイクロサービスとカオスエンジニアリング（Chaos Engineering）を扱っているのか説明した。

環境におけるインタラクションをテストすることが極めて重要である、Reese氏は力説する。たとえ全てのコンポーネントがテスト済みであっても、コンポーネント間のインタラクションが堅牢だと言うことを意味してはいないし、プロダクション環境で組み合わせて使えることを意味してはいない。これらは全てテストされなくてはならない。彼女はJetを「正しい仕事のための正しいツール」の会社だと述べた。彼女にとって、カオステストは正しいツールのひとつだ。

Reese氏はマイクロサービスを、サービスレベルにおける単一責任原則（SRP: Single Responsibility Principle）の適用として定義する。入力を受けて出力を生成するという、マイクロサービスの機能の捉え方のためだ。彼女がマイクロサービスを使ってわかったメリットには、簡単にスケールできること、独立にリリースできること、複雑さをさらに分散させることがある。Jetは10から15のチームに分散した、400から1,000程度のマイクロサービスで動いており、主にF#（関数ファーストなプログラミング言語）で書かれている。

Reese氏は、カオスエンジニアリングは面白半分にコードをめちゃくちゃにすることではない、と述べて、代わりにこう定義した。

システムの避けられない障害に対する耐性に自信を持つ手助けをする、分散システム上のコントロールされた実験

「Principles of Chaos Engineering」を引き合いにして、Reese氏はカオスエンジニアリングの4つのステップを定義した。

1. 「ノーマル」（システムの正常状態）を定義する。
2. 対照群と実験群の両方で「ノーマル」が継続すると仮定する。
3. カオスを取り込む。サーバーのクラッシュ、ハードドライブの異常、ネットワーク切断など。
4. 対照群と実験群における振る舞いの違いを調べる。

さらに具体的に言うと、これは次のことを意味している。

• 正常動作およびスループット・レイテンシーなどのシステム状態を定義し、仮説を立てる。
• 実世界の事象を変化させる。トラフィックの急増や、その他何かをカオスにすること。
• プロダクション環境で実験を行い、テストの信頼性を保証する。
• 実験を自動化して、継続的に実施する。

Reese氏は、カオスエンジニアリングには次のようなメリットがあることに気づいた。

• 午前3時に問題を修正するのではなく、日中のテストによって機能停止する。
• エンジニアは障害に合わせて設計するようになる。
• 後になって機能停止するのを防ぐことで、システムがより健全になる。

彼らは経験から判断して、まだプロダクション環境でテストしていないという。スタートアップ企業として、彼らの一番の目的は、サービスをローンチして、すべてをきちんとすることだ。今のところはQA環境で、日中絶えずランダムにテストしている。

数ヶ月前、非常に「興味深い」障害が起こった。サーチエンジンがダウンした結果、問題が下流へと波及したことにテスターが気づいたのだ。この障害の原因は、カオステストがサーチエンジンを誤った方法で再起動したことにあった。このひとつの障害から、彼らは5、6個の異なる問題を見つけることができた。

Reese氏は次のように話をまとめた。

もし可用性が重要なら、その可用性をテストしなくてはなりません。

Reese氏のプレゼンテーションはすでにQCon参加者に公開されており、後日、InfoQの読者にも公開される予定だ（注：すでに公開されている）。