Netflix考案のテスト「カオスエンジニアリング」を探る――システムのあらゆる部分を“壊す”、そのメリットとは：海外企業に学ぶテスト自動化（2）

海外の先進的企業の事例を基にテスト自動化に使われる手法を解説する本連載。第2回は、Netflixが考案したテスト手法「カオスエンジニアリング」について。

[高橋寿一，AGEST]

　前回に引き続き、今回も膨大×膨大＝無限大をテーマに、カオスエンジニアリングを説明していきます。カオスエンジニアリングはNetflixが考案したテスト手法です。

　カオスエンジニアリングという言葉を聞いたことがありますか？　簡単にいうと、システムのプロセスやCPU、仮想マシンをランダムに止めて、システム全体が致命的な状態に陥らないようなシステム設計をするためのツールです。

AWS上のカオスエンジニアリングツール

　Amazon Web Services（AWS）上にはすでにカオスエンジニアリングのためのツールが実装されており、比較的簡単に実行できます。例えば、上記の画面のようなツールで「asw:ecs:stop-instances」をアクションとして選ぶと、インスタンスを自動的に止めてくれます。

　ミューテーションテスト（第1回参照）がソースコードレベルで壊していたものを、今回紹介するカオスエンジニアリングではシステムレベルでランダムに壊します。もしかすると将来、テストは品質を保証するというより、一度壊してからソフトウェアを保証するというスタイルに進んでいくかもしれません。カオスエンジニアリングはあらゆるところを「壊す」ことを目指しています。言い換えると、非機能テストに近づいています。例えば、CPUに負荷をかけたり、ネットワークのスピードを少し落としたり……。カオスエンジニアリングは、今後の中・大規模システムには必須のテスト手法だと筆者は考えています。

　古来のシナリオテストは下記のようなシナリオで大量にテストを重ねます。

ユーザー登録シナリオテストケース1

1.ログインする

2.ユーザー登録画面で、ユーザー登録をする

3.登録されたユーザーに対して、xxxをする

4.登録されたユーザーを削除する

期待結果：xxxがデータベース上とUI上で削除されていることを確認する

　このようなテストを実施し、リリース後にバグが出たら「シナリオテストケースが足りないので、もっとテストケースを追加しましょう」という話に陥ります。

　現実的に考えて、現代の複雑かつ巨大で不安定（クラウドやオートスケール）なシステムでこのようなシナリオテストはやっていられません。いかにして無限のシナリオを自動化し、全てを網羅できないにしろ、効率的（ランダム）に網羅的に行っていくかを考えなければなりません。

　テストをする上で一番に必要なのは、第1回で説明したミューテーションテストのように、丁寧に単体テストをすることだと筆者は考えています。実際にはそれだけでは足りないので、その足りない部分をVモデルでいうところの統合テスト、システムテストと段階を徐々に上げてテストすべきでしょう。しかしながら、その理論を実践するには一般の企業ではお金も人員も足りません。従って、筆者は以下のような考えを提唱しています。