マイクロサービスは、エンドツーエンドの責務を持って自動化されたCI/CDパイプラインを運用する、独立したチームに適している。一方で、エンドツーエンドのテストによるソフトウェアの品質保証は、ソフトウェアコンポーネントの迅速な統合とリリースに相反する場合もある。エンドツーエンドのテストがフェールすると、その原因となった問題が解決されるまで、関連するすべてのマイクロサービスのCI/CDパイプラインがブロックされることになるからだ。
シニアコンサルタントのLukas Pradel氏はAgile Testing Days 2020で、マイクロサービスのエンドツーエンドテストに関する課題について講演した。
Pradel氏が最初に言及したのは、マイクロサービスベースのシステムにおけるエンドツーエンドの実装は想像以上に面倒な作業である、という点だ。技術的に見れば、テスト目的のために運用環境をコピーするというのは、それほど難しい作業ではないように思われる。しかしながら、サービスが均質ではなく、異なるチームによってメンテナンスされているため、各サービスに一貫性のあるデータを提供するというような一見簡単に見えるタスクでさえ、実は非常に難しい場合もあるのだ。データがリアルタイムであったり、外部システムやレガシシステムが絡んでくると、この傾向が特に顕著になる、とPradel氏は言う。
エンドツーエンドテストが不安定なことは周知の事実だが、高度な分散システムにおいては、状況はさらに悪くなる。"テストがフェールする理由が無数にあることも珍しくないのです"、とPradel氏は言う。"うまくいかないことはたくさんあります。"
犯人とテストケース失敗の影響を特定するという問題もある。Pradel氏が説明する。
分散システムでブラックボックステストを使用する場合、エラーの原因を探し当てるのは簡単ではありません。
そして何よりも、エンドツーエンドテストがフェールすると、関連するすべてのマイクロサービスのデリバリがブロックされてしまうのです。
すべてのチームが共通の理解を持ち、信頼が高く効果的なコミュニケーションを確立するための組織的な取り組みは、ともすれば見過ごされがちだ、とPradel氏は説明する。
エンドツーエンドテストを誰が書き、誰が実装し、誰がメンテナンスするのか？自明なサービス境界が失われたことで、それらの責任は唐突に不明瞭なものになりました。現実的なシナリオとして、50以上のサービスを15あるいは20のチームがメンテナンスし、それぞれが自身のバックログと優先度を持つ、という状況に直面することもあるでしょう。
マイクロサービスシステムをエンドツーエンドでテストするべきかどうか、という質問に単純な答はない。どちらに決めてもよいが、その判断は軽率であったり、代替案を考慮しないものであってはならない、とPradel氏は説明する。
エンドツーエンドテストはソフトウェアの品質を向上し、潜在する危険なバグの発見に寄与する一方で、デプロイメント頻度とリードタイムを大幅に低下させ、サービスとチームの間を結び付けます。諺にもあるように、"ケーキを食べれば、ケーキはなくなる (一挙両得はできない)"のです。
Lukas Pradel氏に、マイクロサービスのエンドツーエンドテストについて聞いた。
InfoQ: マイクロサービスベースのアプリケーションをテストするためのテストステージは、どのようなものなのでしょうか？
Lukas Pradel: 古くからの友人 — テストピラミッドが、ここでその大きな価値を改めて証明してくれます。底辺から始めましょう。まず最初は信頼できるユニットテストです。マイクロサービスアーキテクチャは迅速なデリバリという目標を念頭に選択されるものですから、テスト駆動開発は必須と言ってよいでしょう。数百というユニットテストが存在するかも知れませんが、ピラミッドの下部では信頼性、速度、分離性がいずれも最も高いので、まったく問題にはなりません。
次にあるのは統合テストです。ここではすべてのユニットが、実際のデータベースやメッセージングシステムと連携して機能するかどうかを検証します。インテグレーションテストの数は、ユニットテストに比較してずっと少ないでしょう。ピラミッドを上がれば、テストケースはさらに少なくなります。
その次に、契約テストが行われる場合があります。これは、プロバイダとコンシューマの間で合意されたインターフェースが正しく実装されていることを確認するものです。
ピラミッドの上部に達すると、マイクロサービスがユーザインタフェースを持っている場合にはUIテストがあります。
そして最後、ピラミッドの頂上に、テストケースをカスタマジャーニー(customer journey)に大まかにマッピングさせるエンドツーエンドテストがあるのです。エンドツーエンドテストでは、ユーザが対話するシステムの末端に特定のインプットを適用して、その結果について検査するという、ブラックボックス方式を採用します。
ピラミッドの上部に行くほど、テストに要するコストや労力、複雑さが大きく上昇する一方で、信頼性、速度、分離性といったものは下がっていきます。
InfoQ: マイクロサービスのエンドツーエンドテストの課題を考えた時、代替策はないのでしょうか？
Pradel: エンドツーエンドテストの大きな目標は、ユーザに影響するような欠陥を持ったサービスリリースの可能性を最小化することです。ですが、この目標を達成するために、自由に使用できるツールが他にもあります。例えばブルーグリーンデプロイメントでは、2つの運用環境を用意して、ひとつをすべてのトラフィックを受信する安定環境(これをブルーとします)にします。新しいサービスをロールアウトする場合には、グリーン環境にのみデプロイして、最初は少量のトラフィックをグリーン環境にルーティングし、その後は継続的に割合を増やしていきます。何か問題が発生した場合は、すべてのトラフィックを再度ブルーにルーティングすれば、素早くロールバックすることができます。すべてがうまくいけば、最終的にグリーンが新たな安定環境になって、次のデプロイメントを開始することができるのです。
フィーチャートグルという方法もありますが、私は、あまり多用すべきではないと思っています。さらに、すべての分散システムは、完璧なアプリケーションパフォーマンス管理(APM)を備えなくてはなりません。理想的には、ユーザが気付く前に、何か問題があることが分かるようになるでしょう。最後に述べておきたいのは、エンドツーエンドテストは運用環境でも実行可能だ、ということです。これによって、エンドツーエンドテストのフェールがマイクロサービスのデリバリパイプラインをブロックする、という問題を解決できます。
InfoQ: エンドツーエンドテストによるソフトウェア品質の保証は、ソフトウェアコンポーネントの統合やリリースの迅速化に相反する、という話がありましたが、詳しく説明して頂けますか？
Pradel: マイクロサービスアーキテクチャが選ばれるのは、リードタイムの短縮とコンポーネントの迅速かつ独立的なデプロイメントに対する強いニーズが理由であり、それをバックアップする組織構造 — エンドツーエンドの責務を持った小規模で権限のある独立的チームの存在が条件となります。そのため、多くの場合において、完全に自動化されたCI/CDパイプラインが利用されています。その一方で、コミュニケーションや複雑な社会技術システムへの需要が高くなる、という欠点もあります。
エンドツーエンドテストはこのパーティを台無しにするものです — ひとつのテストがフェールすると、問題の特定と解決が終了するまで、関係するすべてのマイクロサービスのCI/CDパイプラインがストールすることになるからです。しかし、これには数時間、場合によっては数日を要すこともあります。こうなると、チームはもはや独立しているとは言えなくなります。実際に私たちは"デプロイメントウィンドウ"というものを経験しています。これは、エンドツーエンドテスト環境がレッドで誰もデプロイできない作業日が長く続いた後に、それが解決してグリーンのウィンドウが挟まり、そこで全員が一気にデプロイするために、まったく別の理由で再びエンドツーエンドテストがフェールする、という状況です。結果として、関係するすべてのチームが強いフラストレーションを抱えることになるのです。
InfoQ: このジレンマにどう対処して、最終的にどのような解決策に至ったのですか？
Pradel: 長年にわたって悩まされていると、一方でエンドツーエンドテストがその目的も果たしている、ということを忘れてしまいがちになります。ですが、エンドツーエンドテストによってたくさんのバグを発見することができたのは、疑いのない事実なのです。ユーザに提供したのは、その結果です。
結局のところは、ステークホルダも参加して優先順位を慎重に見極める必要があります。ソフトウェア品質が最優先事項ならば、いかなる欠点があろうとも、エンドツーエンドテストは必須です。
しかしながら、機能を短期間で提供する必要があり、品質のニーズよりマイクロサービスのメリットの方が上回る場合、例えば非常に競争の激しい市場のプロダクトであるならば、私たちの議論した代替案を検討した方がよいかも知れません。私たちの場合は、ステークホルダが前者を選択したので、それに従ってデメリットを受け入れたのです。