【ITニュース解説】CI/CD Reimagined: End Staging Chaos with Ephemeral Infrastructure

ソフトウェア開発では、プログラムを作成し、テストし、利用者に届けるまでの一連の流れを効率化することが常に求められている。Continuous Integration（継続的インテグレーション）とContinuous Delivery/Deployment（継続的デリバリー/デプロイ）を組み合わせたCI/CDは、そのための強力な手段として長年多くの企業に採用されてきた。コードの変更が頻繁に行われても、自動的にビルドされ、テストされ、リリース準備が整うようにする仕組みだ。これにより、ソフトウェアをより速く、より高品質に提供することが可能となり、多くの時間とコストが投じられてきた。

しばらくの間、このCI/CDパイプラインの最適化は効果を発揮していた。しかし、近年では状況が変化している。特に、クラウド上で動作する分散型のマイクロサービスという手法でソフトウェアを開発するチームが増えるにつれて、新たな、そして深刻な問題が表面化してきたのだ。これまで問題だと思われていたCI/CDパイプラインそのものよりも、インフラストラクチャ、具体的には「ステージング環境」と呼ばれる共有のテスト環境が、リリースの速度を低下させ、開発者を疲弊させ、誰も得をしない「犯人探し」を生み出す新しいボトルネックになっている。

この問題は単なるちょっとした不便さではない。それはソフトウェア開発の規模が拡大するにつれて、根本的な問題として浮上してきた。従来の、単一で長く使い続けられる共有ステージング環境というモデルは、開発チーム間でゼロサムゲームを生み出してしまう。複数のチームがそれぞれの変更をこの共有環境に入れようと常に競争し、その結果、環境は頻繁に壊れてしまう。環境が壊れると、「誰が原因で壊したのか」を特定するために何時間も費やされることになり、開発者は自分のコードをテストできない。クリーンなテスト期間が確保できないままリリースを強行したり、リリースの自信を持てないまま進めたりすることになる。ある100人規模のチームのエンジニアリングディレクターは、これを「マージ競争の後に犯人探しが始まる」と表現している。

開発者は、テストの大部分を、時間のかかる「アウターループ」と呼ばれる共有ステージング環境でのテストに費やすことになる。個人の開発環境で行う「インナーループ」でのテストは、基本的な単体テストやモックを使ったテストに限られ、システム全体の統合的な動作を確認できないという問題がある。

この壊れたステージング環境がもたらす影響は非常に大きく、リリースの遅延にとどまらない。まず、開発者の生産性が大幅に低下し、不満が募る。開発者が自分の機能の実装を終えても、それで仕事が終わるわけではない。共有ステージング環境が空くのを待つ「キュー」に入ることになる。現実的な環境でコードをテストできないため、開発の勢いが失われてしまうのだ。プルリクエスト（コード変更の提案）が共有ステージング環境に入り、フィードバックを得られるまでの平均時間は、数時間から数日にも及ぶことがある。ステージング環境が不安定だと、どれほど慎重に計画されたリリースのスケジュールも崩壊してしまう。開発者がステージング環境が利用可能になるのを待ったり、安定するのを待ったりすることほど、生産性を低下させるものはない。例えば、100人規模のエンジニアリングチームにおいて、開発者一人あたり週に8時間の生産性が失われると控えめに見積もっても、それは20%の生産性損失となり、年間数億円規模のエンジニアリング能力の損失に相当する。このように、テストプロセスにおける継続的な摩擦と制御の欠如は、システムへの信頼を損ない、開発者の不満を増大させる原因となる。

次に、品質が損なわれ、リスクが増大する。ボトルネック化したステージング環境は、かえって偽りの安心感を生み出すことがある。チームは、時間がかかり手動で行われるプロセスが品質を保証すると考えるかもしれないが、実際はその逆だ。ステージング環境でのテストが難しいと、チームはテストを避けたり、テストを不徹底にしたりするようになる。その結果、複数の機能がまとめてデプロイされることになり、大きな、よりリスクの高いリリースが行われる。これにより、もしバグが発生した場合、その原因を特定することがほぼ不可能になる。あるコメント投稿者が指摘するように、単一のステージング環境は、異なるアプリケーションが本番環境で平和に共存できない状況を検知するためにあるはずだ。しかし、それが不安定だと、テスト結果を信頼できなくなり、最終的に本番環境で予期せぬ問題に直面することになる。これは、独立したデプロイメントを前提とするマイクロサービスにおいては特に深刻な問題だ。

さらに、運用上の混乱とコストの増大も引き起こされる。この問題は開発チームだけに留まらず、運用チームに大きな負担をかける。インフラチームやDevOpsチームは、常に「誰がステージングを壊したのか」という問題のトラブルシューティングやデバッグに時間を取られ、本来の戦略的な業務から遠ざけられてしまう。ステージング環境は、手動での調整や設定の変更が繰り返されるうちに、本番環境から徐々に乖離していき、その価値をさらに低下させていく。CI/CDの失敗からの回復時間は、高性能なチームでは15分以内、上位5%では5分以内であるのに対し、多くの組織では環境管理の複雑さから、より長い回復時間を要しているという調査結果もある。このような状況に対し、ステージング環境を増やすという解決策を提案する人もいるが、これは問題を増幅させるだけだ。新しい環境一つ一つにメンテナンス、監視、データ同期が必要となり、コストは高騰し、さらに複雑な運用上の悪夢へとつながってしまう。

こうした課題に対応するため、業界では「プラットフォームエンジニアリング」と呼ばれる取り組みが進められている。Gartnerの予測では、2027年までに大規模ソフトウェア開発組織の80%がプラットフォームエンジニアリングチームを設立するとされており、2023年には51億ドルだった市場規模が2033年には510億ドルに達すると予測されている。しかし、その導入はまだ挑戦的な段階だ。「State of Platform Engineering Report 2024」によると、プラットフォームチームの45%が何も測定しておらず、プラットフォームエンジニアリングを導入後に顕著な改善があったと報告しているのはわずか22%に過ぎない。プラットフォームエンジニアリング組織のコミュニティ責任者であるサム・バーリーン氏は、「うまくやっている組織では素晴らしい結果が出ているが、そうでない組織では全く逆の状況だ。何をしているのか理解できていない人もいる」と述べている。

では、CI/CDパイプラインが問題ではなく、テスト環境を複製することも解決策ではないとしたら、何が答えなのだろうか。

新しいモデルは、既存のインフラストラクチャを、分離された並行テストをサポートするように変革することだ。単一の巨大な環境を奪い合うのではなく、開発者一人ひとりに、自分の機能のための個人用で一時的な「サンドボックス」を提供するという考え方だ。これは、システム全体を完全に複製するという、古くて高価なモデルとは異なる。現代のアプローチは、本番環境で一部のユーザーに新しい機能を提供する「カナリーリリース」のような、開発者向けのテスト方法と似ている。一つの共有された基準となる環境、例えば既存のステージングクラスタを稼働させ続け、新しい機能ごとに、変更される特定のサービスだけを「フォーク」（分岐）させる。

以前は、複数のチームの変更が衝突する単一で壊れやすいステージング環境だった。それが、スマートなリクエストルーティングによって、環境の複製なしに並行テストを可能にする共有ステージング環境へと変わるのだ。これは、サービスメッシュなどの技術を活用したインテリジェントなリクエストルーティングによって実現される。開発者が自分の変更をテストしたい場合、一意のルーティングキーが設定され、スマートなルーティングによって、その「サンドボックス」のためのトラフィックはフォークされたサービスに向かい、それ以外のすべてのトラフィックは安定した基準のサービスに届くようにする。これにより、開発者Aは、同じ基盤インフラを共有しながらも、開発者Bの作業に影響されることなく自分のプルリクエストをテストできる。DoorDashは本番環境内での高速フィードバックループを実現するシステムを導入し、Lyftは共有開発環境を管理するための洗練されたコントロールプレーンを開発するなど、すでに先進的な組織ではこのアプローチが実証されている。これらのアプローチは、完全な環境複製というオーバーヘッドなしに、マイクロサービスアーキテクチャの複雑さを大幅に簡素化する。

この新しいスマートなインフラストラクチャモデルを採用することで、ソフトウェアデリバリーのあらゆる側面において抜本的な改善がもたらされる。まず、開発者の生産性が劇的に向上する。「待ち行列の惨劇」が解消されるのだ。開発者はステージング環境の空きを待つ必要がなくなり、コードを書き終えた直後にすぐにテストを開始できる。これは、より高速なフィードバックループ、コンテキスト切り替えの減少、そして開発の勢いを維持することにつながる。

次に、ソフトウェアの品質が向上する。コードをマージする前のテストが、単体テストやモックに限定されなくなる。開発者は、共有された基準環境に対して現実的な統合テストやエンドツーエンドテストを実施できるようになり、問題を開発サイクルのかなり早い段階で発見できる。これにより、「誰がステージングを壊したのか」というデバッグに費やされる時間はほぼゼロにまで削減される。

さらに、コスト効率も大きく改善される。このアプローチは、環境全体を複製するよりもはるかにコスト効率が高い。変更されたサービスだけを複製し、スタックの残りの部分は共有するためだ。これは「最高財務責任者（CFO）の注意を悪い意味で引く」ことのない、拡張性のあるソリューションだ。クラウド支出の無駄遣いを報告する組織が91%に上るにもかかわらず、インフラ投資を増やしている組織が66%に達しているという調査結果もあり、この効率化は非常に重要だ。

最後に、運用が大幅に簡素化される。不安定で常に稼働している環境を管理する運用上の負担が著しく軽減される。一時的なリソースのクリーンアップは自動化できるため、サンドボックスのライフサイクルに連動させることができる。

この「シフトレフト」（開発プロセスの早い段階でテストを行うこと）は、よりスマートなインフラストラクチャモデルによって実現され、マイクロサービスアーキテクチャの真の価値である「独立した継続的なデプロイメント」を可能にする鍵となる。これは、チームが並行して作業し、安定性や品質を犠牲にすることなく、ビジネスが要求する速度で動けるようにすることを目指している。

これまで私たちは、ソフトウェアデリバリーライフサイクルの中で、最適化するべきではない部分に焦点を当てすぎていたのかもしれない。CI/CDは確かに不可欠だが、これからはパイプラインの先を見て、インフラストラクチャに存在する新しいボトルネックに対処する時期が来ている。共有ステージング環境を、単一のチームしか使えない障壁から、複数のチームが利用できる動的なプラットフォームへと変革することで、開発チームは摩擦を排除し、リリースの速度を向上させ、本来の生産性を取り戻すことができるだろう。このような変革を実装しようとする組織は、Signadotのようなソリューションを検討できる。これは、カスタムのインフラルーティングシステムを構築する複雑さなしに、カナリーリリースのような開発者テストを可能にするKubernetesネイティブのサンドボックスを提供する。