ソフトウェアテストの観点を変える、『レジリエンス・テスト』とは

ソフトウェアをテストするとき、どのような観点で物事を見るべきでしょうか。その選択肢として注目されているのが、『レジリエンス・テスト』という言葉。

ネットワーク機器で有名なシスコ（Cisco）は、2016年中盤までに、実に75%の自社製品でレジリエンス・テストを行ってきました。

レジリエンスとは、回復力や弾力という意味です。このテストでは、ソフトウェアやアプリケーションにある一定の負荷をかけ、動作の変化を観察します。「非機能テスト」に分類され、ソフトウェアのストレス耐性を測るのが目的です。

デジタル産業の消費者が増え続ける現在、ソフトウェアの信頼性はさらに重要なものとなっています。レジリエンス・テストの観点を学びましょう。

レジリエンス・テストとは？

ソフトウェアをテストする時には、さまざまな観点から問題を追求する必要があります。一番は機能面について、そして、パフォーマンス、バグについてなどがあります。

その中でも、特に重要なものがレジリエンス（耐性）に関するテストです。ユーザーの操作による負荷や他の要因から耐え、基本的な機能を保持しつつデータを損失せずに運用できるかどうかを測ります。

100%故障しないソフトウェアは存在しませんから、リカバリー機能をもうけることは必須です。しっかりとしたデータ消失対策を備えておくことで、万が一クラッシュした場合でもデータが残っていたり、最新の状態まで復元することが可能になります。

解決策のひとつとして、クラウドサーバーでソフトウェアを実行することがおすすめです。

家庭や職場のコンピューターよりも高機能で安定しているので、システム面でのエラーは起こりにくくなります。また、サーバーで問題が発生しても優れたリカバリー機能があるはずなのでずっと安心です。

機能面でのテストではないことから、非機能テストのひとつに含まれています。非機能テストには、コンプライアンステスト、耐久テスト、ロードテスト、リカバリーテストなどが挙げられます。

レジリエンス・テストの観点を学べる実用例

Netflixの「サルの軍隊」

日本では2015年からサービスが開始されたNetflix。Amazonが提供するクラウドサービスを利用して映画のストリーミングを行っています。

Netflixでは、通称「カオスモンキー」と呼ばれるツールを使うことでレジリエンス・テストを行いました。

カオスモンキーは、「データセンターに解き放たれた、武器を持った野生のサル」というコンセプトのもと作られたプログラムです。クラウドサーバー中でランダムにシステム内の部品を停止し、それでも通常通りのサービスが行えるか、をテストしてシステムの改良を試みました。

これを繰り返し行うことで、自動的に問題を解決できるリカバリーシステムが完成しました。

この成功を生かし、Netflixは複数のテストツールを運用。それらは「猿の軍隊」と呼ばれ、より広い範囲の問題の改善や、異常の検出、セキュリティーの強化を行っています。

モンキーは全部で７種類あり、システム遅延を仮想的に作り出すサル、不要な物を停止してくれるサル、異常を見つけ出してくれるドクターモンキー、メモリーやディスクをお掃除してくれるサル、脆弱性や証明書の異常を探してくれるセキュリティーモンキー、使用地域の問題を解決してくれるサル、そしてAmazonサーバーへの接続を強制的に停止するカオスゴリラがあります。

これらのサルたちを実際にユーザーが使用中である平日の日中にクラウドサーバーに解き放ち、エンジニアがその場で問題の解決に当たります。こうすることにより、現実で起こり得る課題をシミュレーションしてより信頼できるサービスをNetflixは実現しました。

問題に対するこのアプローチの方法は高く評価され、今では多くの会社で使われています。2016年には、「Spinnaker」に対応した「Chaos Monkey 2.0」がNetflixからリリースされました。

IBMでのレジリエンス・テスト

システムにエラーが起きた時、ユーザーに一切の影響を及ぼさないのならば、それは理想的です。しかし現実的には不可能なので、IBMはユーザーへのインパクトを最小限に抑えることを目標としています。

IBMのチームは、ふたつの要素に着目してレジリエンス・テストのガイドラインを作成しました。ひとつ目はシステムに問題が起きた時のインパクトの大きさ。そしてふたつ目はサービスレベルの許容範囲についてです。

例えば、ホストのコンピューターが故障した場合、実行中のプログラムを他のコンピューターに乗り換えることで、引き続きサービスを行うことができます。この場合は数分程度の遅延で済むと思われます。

さらに大きい規模での故障、例えばデータセンター自体が故障してしまった場合は、同じプロセスでプログラムの引き継ぎが可能ですが、サービス復旧までの時間はより長くなってしまいます。最低でも数時間の遅延が出てしまうことでしょう。

このふたつの例で示しているのは、ユーザーへの影響は、起こった問題の大きさによって変わるということです。当たり前のことに聞こえるかもしれませんが、問題の深刻さや大きさによってアプローチ方法を変えることは大切です。

IBMが提示するガイドラインは7つのステップで構成されています。

1. テストケースを作る
2. テストケースを試してみる
3. テスト結果を観察する
4. テスト結果の問題を特定する
5. テスト結果を数値化する
6. システムの構成ごとに数値を比べる
7. 最初のステップから繰り返す

詳しくは、英語ではありますがこちらのリンクで説明されています。

最後に

サービスやソフトウェアに対して、ユーザーの評価はますます厳しくなってきています。クラウドサーバーを利用することでシステムが故障する危険性はだいぶ減少しますが、レジリエンスの観点からテストを行うなどして、故障やエラーの対応に細心の注意を払う必要があります。

テスト環境がコントロールできるのなら、システムの脆弱性やさまざまな問題を発見して改善することができるNetflixの「サルの軍隊」的なアプローチ方法をがおすすめ。IBMのように理論にもとづいて体系化された方法でのアプローチなら、多くの企業に取り入れやすいでしょう。

（翻訳：Juri Ando）