合成の誤謬（本番環境へのデプロイが難しい理由）

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

DevOpsによるソフトウェアデリバリーを効果的に機能させる基本原則の1つが、「早期に、頻繁にテストする」ことです。実際、CI/CD（継続的インテグレーション／継続的デリバリー）には、ビルドと、そのビルドの自動テストが含まれます。個々のコンポーネントだけでなく、アプリケーション全体を対象とします。

テスト駆動開発（TDD）はその手法の1つです。ほかにも、単体テストとシステムテストをビルドおよびリリースプロセス自体に組み込む方法があります。機能テストと回帰テストは不可欠であり、アジリティの高い環境では、リポジトリへの単純な「コミット」を契機に実行されることがよくあります。

したがって、ソフトウェアが本番環境へのデプロイ担当者に「引き渡される」時点では、その準備が十分に整っていると高い確信を持てることが期待されます。

<p>もちろん、実際にそうであれば、この記事を書く必要はなかったでしょう。</p>

ソフトウェアを本番環境に投入する際に越えなければならない壁（誤解のないように言えば、その壁は今も存在します）で、私たちは哲学で「合成の誤謬」と呼ばれるものにしばしば陥ります。この論理的誤謬は一般に議論や証明に当てはめられますが、興味深いことに、著者の Ali Almossawi 氏は The Book of Bad Arguments の中で、ソフトウェアを題材にこの「誤った議論」をわかりやすく説明しています（哲学者やディベートの達人を目指すあらゆる年齢の方に、ぜひお薦めしたい一冊です）。

非形式的誤謬、根拠のない仮定、合成の誤謬と分割の誤謬

このソフトウェアシステムの各モジュールは、一連の単体テストを受け、そのすべてに合格しています。したがって、モジュールを統合しても、このソフトウェアシステムが、それらの単体テストで検証された不変条件に違反することはありません。しかし実際には、個々の部分を統合すると、依存関係によってシステムに新たな複雑性が生じ、それが潜在的な障害につながる別の要因となる可能性があります。-- https://bookofbadarguments.com/ p.46

CI/CDプロセスの最終段階では、ソフトウェアが必ずしもこの誤謬に陥るとは限りません。単体テストだけでなく、それらの単位を統合して完全な「システム」またはアプリケーションを構成するためのテストも実施されているためです。

しかし、本番環境に移行すると、また3つ目の段階に逆戻りします。それまでのテスト結果だけを根拠に、システムが期待どおりに動作し続けるとは限りません。なぜなら、アプリケーションの定義が変わり、ソフトウェアやプラットフォームだけでなく、アプリケーションを稼働させ、利用を待つ消費者や企業ユーザーの画面に届けるために必要なネットワークやアプリケーションサービスのコンポーネントも含まれるようになるためです。

ネットワークとアプリサービスは、リクエストとレスポンスが通過するデータパスに影響を与えます。これらのサービスの多くは、すべてではないものの、開発者が予期しなかった形でリクエストやレスポンスを変更する場合があります。そのため、個々のサービスとアプリコンポーネントを厳密にテストしていても、本番環境に移行すると、アプリケーションに不具合が発生する可能性があります（実際、多くの場合に発生します）。障害が起きる。誤動作する。

これは、本番環境において合成の誤謬に陥っているためです。アプリ開発者（およびDevOps）はこの誤謬を理解し、本番稼働前のテストで対処していますが、ネットワーク層での統合も統合であること、そしてシステム全体の運用上の完全性に影響を及ぼす可能性があることを、依然として見落としがちです。

答えは明らかに思えます。「それなら、本番環境でテストすればいい！」

しかし、実際にはそうしませんし、そうしないことは誰もが分かっています。本番環境は共有環境であり、そこで厳密なテストを行うと、共有リソースやシステムに巻き添え被害が及ぶリスクが高まり、サービス停止につながる可能性があるためです。サービス停止は利益と生産性の低下を意味し、その責任を負いたい人はいません。本番環境では可能な個別テストだけを実施し、後で何かが壊れたり、うたわれていたとおりに動作しなかったりしたときに、開発者の責任にするほうがはるかに簡単です。

これは結局のところ、本番ネットワークを侵食しつつあるソフトウェア革命を陰で推進する要因の1つです。かつては、本番環境と同等のテスト環境を複製して維持することは、あまりにも困難でコストがかかりました。共有インフラストラクチャの中には、高価で広い設置スペースを必要とするものもあります。そのネットワークを複製することは、財務面でも運用面でも賢明ではありません。

しかし、クラウドコンピューティングと仮想化によってソフトウェアが導入され、その後広く採用されるようになったことで、ソフトウェアベースのネットワークは低コストで複製できるだけでなく、Infrastructure as Codeのような概念によって複製が容易になるという考え方が注目され始めています。さらに、ネットワークを複製してテストを実施した後に破棄できるため、同じリソースを再利用して、ほかのアプリケーションでも同様の作業を行えます。

まだ実現には至っていませんが、着実に近づいています。仮想（ソフトウェア）ベースのネットワークサービスやアプリケーションサービスをCI/CDパイプラインに統合する取り組みは、実際には一部で考えられている以上に現実のものとなっています。従来はインフラストラクチャ（ネットワーク）ベースだったロードバランシング、アプリケーションルーティング、Webアプリケーションセキュリティなどのサービスも、コンテナベースのアーキテクチャのような環境に統合されることで、ソフトウェアのビルドサイクルに深く組み込まれつつあります。これらはソフトウェアベースのソリューションであるため、少なくともビルドプロセスのテスト段階に組み込むことができ、本番環境へのデプロイによって不具合やエラーが生じないという確信を高められます。

そのソフトウェアを基盤として、「Infrastructure as Code」を適用することで、さらに一歩先へ進めます。ビルドおよびリリースサイクル中にポリシーと構成を設計・調整し、ほとんど、あるいはまったく変更せずに本番環境へデプロイできれば、本番環境に存在する合成の誤謬の解消に確実に近づきます。

これらのサービス（アプリケーションサービスの中でも特にアプリケーションを中心とするサービス）をCI/CDのテストフェーズに統合するほど、本番環境へのデプロイが成功するという確信を関係者全員がより強く持てるようになります。

現在見られるもう1つの誤解は、「本番環境」に対するテストが「本番システム」のテストを意味するというものです。多くの場合、本番環境のデータパスを構成するアプリサービスはテストに含まれていません。こうしたサービスも含める必要があります。そうすることで、エラーを極めて特殊なものにまで絞り込み、実際に対処するための時間とリソースを確保できます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事