構成の誤謬 (本番環境へのデプロイが難しい理由)
DevOps がソフトウェアの提供にうまく機能するための基本的なルールの 1 つは、「早期にテストし、頻繁にテストする」というものです。 実際、CI/CD (継続的インテグレーション/継続的デリバリー) ドメインの一部は、ビルドとそれらのビルドの自動テストです。 個々のコンポーネントだけでなく、アプリケーション全体です。
テスト駆動開発 (TDD) は 1 つの方法であり、もう 1 つの方法は、ビルドおよびリリース プロセス自体の一部としてユニット テストとシステム テストを単純に統合することです。 機能テストと回帰テストは必須であり、高度にアジャイルな環境ではリポジトリへの単純な「コミット」によってトリガーされることがよくあります。
したがって、ソフトウェアが本番環境への導入を担当する人々の手に「届けられる」頃には、その準備状況に大きな自信が持てるようになることが期待されます。
もちろん、もしそうなら、私はこの投稿を書いていないでしょう？
ソフトウェアが本番環境に配信されるときに越える壁 (間違いなく、その壁は今も存在しています) は、哲学で「構成の誤謬」として知られているものにしばしば遭遇する場所です。 この論理的誤謬は、一般的に議論や証明に適用されますが、興味深いことに、著者Ali AlmossawiのThe Book of Bad Arguments (あらゆる年齢の哲学者や討論チャンピオンの卵に強くお勧めします) では、この「悪い議論」の簡単な説明の基礎となっているのはソフトウェアです。
非形式的誤謬、不当な仮定、合成と分割
このソフトウェア システムの各モジュールは、一連の単体テストを受けており、すべて合格しています。 したがって、モジュールが統合されると、ソフトウェア システムは、それらのユニット テストによって検証された不変条件のいずれにも違反しなくなります。 現実には、個々のパーツを統合すると、依存関係によってシステムに新たな複雑さが生じ、その結果、潜在的な障害の新たな原因が生じる可能性があります。 -- https://bookofbadarguments.com/ p.46
現在、CI/CD プロセスの最終段階では、ソフトウェアは必ずしもこの誤りに陥る傾向はありません。 ユニットテストだけでなく、それらのユニットを統合して完全な「システム」またはアプリケーションを形成するテストも実施されています。
しかし、生産段階に入ると、また振り出しに戻ってしまいます。 これらのテストに基づいて、システムが期待どおりに動作し続けると想定することはできません。 これは、アプリケーションの定義がソフトウェアやプラットフォームだけでなく、いわばアプリを動かし、熱心な消費者や企業ユーザーの画面に配信するために必要なネットワークやアプリ サービスのコンポーネントも含むように変更されたためです。
ネットワークとアプリ サービスは、要求と応答が通過するデータ パスに影響を与えます。 実際、これらのサービスの多くは、開発者が予期していなかった方法でリクエストと応答を変更する可能性がありますが、すべてではありません。 したがって、個々のサービスとアプリ コンポーネントがすべて厳密にテストされていても、実稼働環境になるとアプリケーションに障害が発生する可能性があります (多くの場合、その可能性は高くなります)。 失敗だ。 間違いを犯してください。
これは、本番環境で構成の誤謬に陥ったためです。 アプリ開発者 (および DevOps) はこの誤りを理解し、実稼働前のテストで対処していますが、ネットワーク層での統合は依然として統合であり、実際には全体の運用の整合性に影響を与える可能性があることを認識していないことがよくあります。
答えは明らかです。それなら本番環境でテストするだけです!
ただし、私たちはそうしませんし、あなたも私もそうしないことを知っています。 運用環境は共有環境であるため、運用環境での厳格なテストは共有リソースやシステムへの付随的な損害のリスクを高め、停止を引き起こす可能性があります。 停止は利益と生産性の低下を意味し、誰もその責任を負いたくありません。 運用環境で可能な個別のテストを実行し、後で何かが壊れたり、宣伝どおりに動作しなかったりしたときに開発者を責める方がはるかに簡単です。
これは結局のところ、生産ネットワークを蝕んでいるソフトウェア革命の静かな推進力の 1 つです。 かつては、本番環境と一致するテスト環境を複製して維持することは非常に困難でコストもかかりました。 共有インフラストラクチャの一部は高価であり、多くのスペースを占有します。 そのネットワークを複製することは、財務的にも運用的にも賢明ではありません。
しかし、クラウド コンピューティングと仮想化によるソフトウェアの導入とその後の採用により、ソフトウェア ベースのネットワークの複製は手頃な価格であるだけでなく、インフラストラクチャ アズ コードなどの概念により容易になるという考え方が前面に出てきました。 それだけでなく、複製、テスト、破棄も可能で、リソースを再利用して他のアプリケーションでも同じことができます。
まだそこには至っていませんが、近づいてきています。 仮想 (ソフトウェア) ベースのネットワークとアプリケーション サービスを CI/CD パイプラインに統合することは、実際には一部の人が考えるよりもはるかに現実的です。 従来、インフラストラクチャ (ネットワーク) ベースのサービス (負荷分散、アプリ ルーティング、Web アプリ セキュリティ) は、コンテナー ベースのアーキテクチャなどの環境への統合により、ソフトウェア ビルド サイクルに高度に統合されています。 ソフトウェア ベースのソリューションであるため、ビルド プロセスの少なくともテスト フェーズに組み込むことができ、運用環境での展開によって障害やエラーが発生しないという信頼性が高まります。
そのソフトウェアを基に、「インフラストラクチャ・アズ・コード」の適用により、さらに進化します。 ビルドおよびリリース サイクル中にポリシーと構成を設計および微調整し、ほとんどまたはまったく変更せずに本番環境に展開できる場合、本番環境に存在する構成上の誤りを確実に排除できるようになります。
これらのサービス（アプリ サービスの中で最もアプリ中心）が CI/CD テスト フェーズに統合されるほど、本番環境への展開が成功するという自信が高まります。
なぜなら、今日存在するもう一つの誤解は、「本番環境」に対するテストは「本番システム」を意味するというものである。 多くの場合、本番環境でデータ パスを形成するアプリ サービスは含まれません。 そうすることで、エラーを本当に難解なものにまで減らし、実際にそれらに対処するための時間とリソースを確保できるようになります。