オブザーバビリティはテストにどう影響するのか

オブザーバビリティ(observability, 可観測性)は現在のシステム状況を明らかにし、ある種のテストを置き換えることができる。低リスクのアプリケーション分野であれば、オブザーバビリティをテストの代役とすることで、継続的デリバリによる迅速なフィードバックと、短時間の変更リリースが可能になる。

MooのエンジニアリングマネージャであるAmy Phillips氏は、QCon London 2018で、オブザーバビリティのテストについて講演した。InfoQはこのカンファレンスに関して、これまでにもQ&Aや要約、記事を通じてお伝えしている。

InfoQはPhillips氏にインタビューして、自己修復システムのテスト、オブザーバビリティ、未来がテストにもたらすものついて聞いた。

InfoQ: 継続的デリバリは、テストにどのような影響を与えたのでしょう？

Amy Phillips: 継続的デリバリは、迅速なフィードバックを重視し、リリースパイプラインでの自動化テストの利用を促しました。それが変革をもたらす唯一の方法とは言いませんが、効率的なリリースプロセスの設計をチームに促す強い契機とはなっています。どのテストを実行すべきか、いつ実行するのが妥当かといった考慮も、その中に含まれます。

継続的デリバリを利用するチームがテスト量を減らすということはありませんが、ローカルでのテストや運用テストについて、より明確な意図を持って行っていることは確かです。機能トグル(feature toggle)の利用も、テストを自動リリースパイプラインからプロダクションに移行する上で一役買っています。

継続的デリバリの最も興味深い側面のひとつは、開発者に対する普及の度合いです。継続的デリバリを成功させる上でテストが重要な役割を果たしていることは、ソフトウェアのビルド、テスト、リリースで協業する真のクロスファンクショナルチームへと繋がっています。

InfoQ: 自己修復システムのテストにはどのような問題があるのでしょう？

Phillips: 他のシステムに比較して、自己修復システムのテストが特に難しいという部分はありません。アプリケーションが“動作する”上でテストが必要なことに変わりはありませんが、テスト時のインフラストラクチャが常に正しく動作するものと想定しないように、注意が必要です。

テストやデバッグにおいてやっかいなもののひとつは、断続的に発生する問題です。発生することは分かっていても、特定やトレースをすることは困難です。さらに自己修復システムでは、人の介入を必要とせずに障害を引き起こした根本的な問題を解決することによって、問題をより難しくする可能性があります。

テスタはアプリケーションプラットフォームを十分理解しなければなりませんし、プラットフォームチームは実施されるテストを十分理解しなければなりません。一致協力してオブザーバビリティのテクニックを活用することで、この問題を軽減ないし排除することが可能になります。

InfoQ: システムを適切に動作させる上で、オブザーバビリティはどのように役立つのでしょう？

Phillips: テストはシステムに関する情報を収集ためにするものですが、オブザーバビリティが現在のシステム状態を示すのに対して、“動作確認”チェックを行なうタスクに陥ることが少なくありません。この２つは一緒になることで、実際に起きていることをより明確にするものです。

私は以前、サプライヤに関する詳細情報とともに、さまざまな要因に基づいた特別な値引き率を保持するWebシステムをテストしたことがあります。システムはプロセス全体として、テストを伴って段階的に構築されていました。

ある日誰かが、ひとつのサプライヤに対して明らかに間違ったレートが設定されていることに気付きました。ログを調査して計算を再テストした結果、誰かが誤って値を編集してしまったという結論に達したのですが、念のためにログを追加しておきました。

数週間の後、同じことが、今度は違うサプライヤに対して起こりました。今度は十分なログ情報があったため、編集ミスでないことが分かっていました。実際にそのサプライヤは、数ヶ月間変更されていませんでした。それでも値は間違っていて、その理由が分からなかったので、さらにログを追加しました。

最終的に分かったのは、十分なログが取得できた時に問題が発生するということでした。データベースから検索された数値が誤っているという、MySQLの“奇妙な”動作によって引き起こされていることが明らかになったのです。

私たちのビルドとテストはすべて、“正しく動作しているか？”という疑問に集中していました。この場合、“No”という答が返ってくると、デバッグに長い時間が必要になります。このような状況では、テストに加えてオブザーバビリティも重視することが有効です。

InfoQ: オブザーバビリティはテストの代替になるのでしょうか？

Phillips: ある種のテストに対しては、オブザーバビリティはすでに代替となっていると思います。ずっと以前からモニタリングは、全テストの適切な代替手段であると考えられてきました。何か問題があることが分かっていて、変更を短時間でリリース可能な優れたリリースパイプラインがあれば、低リスクのアプリケーション分野は、テストに代えてオブザーバビリティに依存するのに極めて適しています。

“正しいものを開発しているか？”という考慮に加えて、“動作しないことをどうすれば分かるのか？”という疑問を持ってシステムを開発するのは、システム状態に対するさまざまな見地を与えるとともに、問題の発生と影響を低減することを可能にします。

InfoQ: 将来的にアジャイルは、どのようになっていくと思いますか？

Phillips: システムにはそれぞれのニーズがありますが、一般論としては、テストは今後よりコラボレーティブな場所に移っていくのではないかと思います。テスタと開発者は以前よりも緊密な協力の下で作業するようになりましたが、さらに現在では、テスタの価値感がOpsエンジニアリングにも関わるようになってきています。

現在では、テストに関わるすべての人にとって、リスクの想定や適切なシナリオのデザインといった創造的な側面が、これまでになく重要なスキルになっています。今後はより多くのチームが、システム構築完了後に1回だけ行うチェックボックス作業としてのテストから離れることを期待しています。