100を超えるマイクロサービスをテストする
次にご紹介するのは、CloudBees社のIsa Vilacides氏による「Testing In The Hundred Microservices World: When The Pyramid Becomes An Hourglass」です。モノリシックなシステムがマイクロサービス化されていく中で、氏が学んだことが紹介されていました（執筆担当：藤原大）。
モノリシックなシステムと、マイクロサービスのような分散型システムにおけるエンドツーエンドテストを比較してみましょう。モノリシックだとテストは遅く、信用性も低く、メンテンナンスやデバッグも難しいですが、システムが大きく1つなのはシンプルです。
一方で、マイクロサービスの場合、モノリシックとほとんど同じ悩みを持ちますが、たくさんのサービスが存在する分、複雑になりがちです。
ユニットテストやインテグレーションテストを見てみましょう。こちらは大きく違いが見えます。
- モノリシックだとテストは速く、マイクロサービスだとそれほど速くならない
- モノリシックだと信頼性は高いが、マイクロサービスだとそれほど高くならない
- メンテナンスやデバッグはどちらも同じぐらい簡単
- テスト自体は開発環境などにおける仮想的なテストとなるが、マイクロサービスの場合、モックを用意するなどの対応が必要
こうやって比べてみると、改めてマイクロサービスのテストのしにくさが見えてきます。
このため、PACT（Consumer-Driven Contract testingを実現するためのツール）などを活用しながら、それぞれのマイクロサービスの独立性を高め、すばやいフィードバックを実現していく必要があります。
さらに、時代とともにアーキテクチャが大きく変わっていくため、テストピラミッド（テストを作っていくためのコンセプトの一つ）も再考が必要だと氏は語ります。
まず氏が考えたのは本番でのテストです。このセッションの説明では、
- 開発環境でのテスト
- 内部からのみアクセスできる本番環境でのテスト
- 本番環境でのテスト
と環境を分け、それぞれで問題が起きたときにすぐに戻せるようにデプロイプロセスを設計します。そのための技術としては、
- 機能を有効／無効にするためのスイッチ（Feature flags）
- 機能を徐々に公開していく仕組み（Canary rollouts）
- 開発者やその関係者が日常的にアプリやサービスを利用する（Dogfooding）
が有効です。その結果、テストピラミッドは以下のような形になっていくと考えられます。
まったく別のセッションでも「本番におけるテスト」が議論されていました。本番でのテストという概念は、新しいものではありませんが、マイクロサービスやDevOpsといった時代背景の影響なのか、再注目されているように感じます。
