継続的デプロイ実現のためにはインフラの考慮が必要という話

全国1000人のスタックフルエンジニアのみなさんこんにちは。

DevOps.comでのRe-thinking DevOps tools for Continuous Deployment successという話が興味深かったのでご紹介します。

ここで話しているのはいわゆる大きな組織においてデプロイやプロビジョニングを自動化しようとしたときにぶちあたるインフラ面でのブロッカーの話と捉えてよいでしょう。

十分な開発環境がない、開発環境のリソースの制限がきつい、本番環境と開発・テスト環境があまりに異なるといった話をよく聞きます。しかし、新しい機能を作って届けるためのサイクルタイムを短くしようと思うなら、開発プロセスだけを改善しても始まりません。速度を遅くするブロッカーが何なのかをとらえた上で、それがインフラ周りであればそれも改善しないといけません。

以下勝手訳です。

継続的デプロイ成功のためのDevOpsツール再考

ガートナーは、フォーブス・グローバル2000の企業のうち25%が2016年までに自組織でDevOpsのメソッドを積極的に取り込んでいくだろうと予測している。 DevOpsが主流になってきたので、小さな企業やプロダクションではない環境だとうまくいっていたいくつかの実装テクニックについて再考すべき時だと思う。継続的インテグレーションをうまくいかせるための一般的な前提は、プロダクション環境の現実世界のデータセンターでは現実的ではない。一般的な前提には以下が含まれる。

分離された開発やテスト環境のそれぞれで専用のリソースが使える
リグレッションテストやQAテストを実施するために十分な仮想マシンのプールがある
テスト環境はプロダクション環境にそっくりである
DevOpsワークフローを実現するのに十分なだけのツールチェーンが使える

それぞれの前提と、それがプロダクション環境での成功にあたえるインパクトについて考えてみよう。

分離された開発やテスト環境のそれぞれで専用のリソースが使える

大きな組織においては、開発とテストのための分離された専用のインフラを維持するのに非常に高額のコストがかかる。われわれの経験では、5チームかそれ以上の開発チームがある組織で、開発・テスト・QAのインフラを管理するために、より良い方法を手に入れる必要がある。これが意味するのは、そういったチームではビルドの終了をトリガーにしてすぐにリグレッションテストをおこなうことができないということだ。まず、テストの実行に必要なリソースへアクセスできることを保証する必要があるのだ。 DevOpsのツールが、共有で制約のある物理または仮想化されたインフラの予約やスケジューリングをする必要がある。

リグレッションテストやQAテストを実施するために十分な仮想マシンのプールがある

DevOpsのツールは、均質的な仮想または物理サーバにおいて開発やテストのプロセスを自動化し、アプリケーションを実行することにフォーカスしている。こういった環境では、DevOpsツールは実行やデプロイに際して、仮想環境、PaaSのツールやサーバープール用のOS(たとえばCoreOS)に依存する。残念なことに、仮想化ツールやOSツールにスケジューリングを移譲するのは、大規模プロダクション環境ではうまくいかないし、現実のデータセンターの縮図となる環境を必要とするリグレッションテストを十分にコントロールすることができない。完全なDevOpsのツールセットはワークフローによるオーケストレーションを組み込む必要があり、そこではDevOpsのそれぞれのプロセスにおいてアプリケーションが対象の仮想環境でどのように実行されるかを開発者がコントロールすることを許容しないといけない。

テスト環境はプロダクション環境にそっくりである

フォーブス・グローバル2000の企業がもつデータセンターは均質ではない。典型的には、アプリケーションが旧来のインフラ、仮想環境、パブリッククラウドの組み合わせにまたがってデプロイされるハイブリッドインフラである。それに加えて、プロダクション環境のネットワーク構造は複雑で、アプリケーションを動作させるための設定が必要だ。開発環境やテスト環境でこの複雑さを無視することは、プロダクトション環境へのアプリケーション移行が失敗するという結果になる。多くの継続的インテグレーションツールはこういった複雑な環境へのデプロイをコントロールすることはできない。このことが、今日の多くのDevOpsプロジェクトが継続的インテグレーション止まりであり、プロダクション環境への「継続的デプロイ」に至っていないことの説明になる。 DevOpsツールは単にアプリケーションのデプロイを管理できるだけでなく、アプリケーションが動作するハイブリッドインフラの設定も管理できなければならない。そして、このことは、テストインフラの設定はプロダクションインフラの縮図である必要があるということに帰結する。

DevOpsワークフローを実現するのに十分なだけのツールチェーンが使える

継続的デプロイを実現するための一般的なソリューションは、開発からデプロイまでエンドツーエンドでDevOpsツールをつなぎ合わせることだ。しかしこのやり方は問題を作りだしてしまう。というのも、それぞれのツールはプロセスのフローにおいて点と点で統合しなければならないからだ。ツール全てが線で繋がるまでは、完全なソリューションはない。ただ結局のところ、チェーンの中の次のツールは、それまでに導入している全てのツールと特別な統合をする必要はなく、あくまで前のツールとうまくつながればよい。

単純にツールをつなげることは上で述べた3つの問題を無視している。本当のエンドツーエンドのソリューションは単に開発・テスト・QA・デプロイツールを一緒につなげることではなく、以下のようなことを組み込むべきだ。