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モデルでいうところの統合テスト、システムテストと段階を徐々に上げてテストすべきでしょう。しかしながら、その理論を実践するには一般の企業ではお金も人員も足りません。従って、筆者は以下のような考えを提唱しています。

筆者の考える、今後の2つのテストの主流

　膨大なブラックボックステストの一つ一つを検討し、統合テストやシステムテストに割り振るにはあまりにもコストがかかり過ぎます。それなら1つか2つのブラックボックステスト手法を選んで、最終工程のテストで実施するのはどうでしょうか。つまり、統合テストとシステムテストという概念を1つにします。そのためのテスト手法の最有力候補がカオスエンジニアリングだと考えています。

カオスエンジニアリングの目的

　カオスエンジニアリングについて詳しく説明します。前述の通り、カオスエンジニアリングはNetflixよって考案されたテストとされています。その目的は、以下の通りです。

• エンジニアがさまざまなサービス実行状況を1つのシングルシステムとして見ることができる
• 本当の入力値（異常値）を入れることでシステムの振る舞いを理解でき、システムの境界で何が起こるかを監視できる

　全てのソフトウェアは複雑です。単一のソフトウェアとして見ることも難しい世の中です。そこで、システムの境界値の入力をテストケースとして設定してシステム全体の振る舞いを見ることは、品質保証の観点で非常に重要です。ある意味、それは境界値テストになります。

カオスエンジニアリングと探索的テスト

　カオスエンジニアリングと探索的テストは似ています。探索的テストは多くの情報があるので、ここでは割愛しますが、要は膨大×膨大＝無限大の対象に何も考えず無謀にテストしても、ほんの数％しかテストできないでしょう。猿がキーボードを打ち続けてもシェークスピアのような文章は書けないように、ランダムといってもそれなりに真剣に（探索的に）、シナリオを考える必要があります。

　ランダムに入力はできますが、ランダムな状態遷移はできません。ある状態からある状態に遷移することを確認する、状態遷移テストというテスト手法があります。以下のような図の状況を考えてください。ただランダムに入力しているだけだと、状態1から状態4にはなかなかたどり着けません。従って、テスト担当者は状態1から5に対してまずはその状態にたどり着いた状態でランダムテスト（カオスエンジニアリング）をする必要があります。テスト担当者はランダムテストをお膳立てすることが今後の重要な責務になるのではないでしょうか。

ランダムを考慮した状態遷移テスト

カオスエンジニアリングと品質、生産性

　昨今、マイクロサービスがはやっています。ソフトウェアを小さく分割して開発することは効率の面でも、品質の面でもメリットがあります。マイクロサービスアーキテクチャは、ミューテーションテストで個々の品質を担保し、マイクロサービス間の連携に対してはカオスエンジニアリングを行う、理想的ではないでしょうか？

マイクロサービスにおけるシステムテストの姿

　マイクロサービスの開発は現代のソフトウェア品質を良くするだけでなく、開発効率も向上させます。実際に、人数の少ないチームの方がコーディング工程でのバグ検出率が高いという報告もあります。

プロジェクトの人数の増加と欠陥数

　また、下図のようにチームの人数が増えれば増えるほど、1人当たりの生産性が落ちてきます。

生産性およびその効率

　アジャイル開発の本質を下記に示しました。

• 不安定な状態を保つ（Built-in instability）
• プロジェクトチームは自ら組織化する（Self-organizing project teams）
• 開発フェーズを重複させる（Overlapping development phases）
• マルチ学習（Muti-learning）
• 柔らかなマネジメント（Subtle control）
• 学びを組織で共有する（Organizational transfer of learning）

　開発単位の全てが小さいチームで、自発的に開発することがアジャイル開発の本質の一つだといえます。その個々のチームがマイクロサービスの単位とイコールならばさらに良いでしょう。個々のマイクロサービスの品質は、開発に携わる各チームが担保します。往々にしてチーム間のコミュニケーション（人およびマイクロサービス間）不足からバグが生み出されてしまいますが、それをカオスエンジニアリングで担保できれば、品質の多くの部分が保証されるのではないでしょうか。

　次回はこれまでの連載の内容をふまえて「これからの時代のアジャイル開発におけるテスト」について考えます。

著者紹介

高橋 寿一

情報工学博士。1964年東京生まれ。フロリダ工科大学大学院にてCem Kaner博士、James Whittaker博士にソフトウェアテストの指導を受けた後、広島市立大学にてソフトウェアテスト研究により博士号取得。米国Microsoft、SAP Labs、ソニーを経て、AGEST 執行役員 CTSO、AGEST Testing Lab.所長およびAGEST Academy学長を現職として兼任。情報処理学会及びIEEE会員

参考文献

• Todd Little, “Value Creation and Capture: A model of the Software Development Process,” IEEE Software, May/June, 2004
• Principles of chos engineering, https://principlesofchaos.org/ja/, 2018
• Ali Basiri, Niosha Behnam, Rund de Rooij, Lorin Hochstein, Luke Kosewski, Justin Reynolds, and Casey Rosenthal, “Chaos Engineering” IEEE Software, May/June 2016