クラウドネイティブな継続的デリバリのためのパターンとプラクティス

RIO — Volkswagenのトラックおよびバス部門 — のチーフアーキテクトであるChristian Deger氏が、先頃ロンドンで開催されたContinuous Lifecycle Conferenceで、クラウドネイティブな継続的デリバリを実装するためのパターンとプラクティスについて講演した。氏が取り上げたのは、(コンテナ化を活用した)デプロイメントパイプラインの分離パターン、(プロセスとインフラストラクチャの両面で)デリバリの所有を認められたプロダクトチーム、動的で不変、かつ構成可能なインフラストラクチャ(モノリスを回避し、マクロおよびマイクロインフラストラクチャを区別する)などの話題だ。

継続的インテグレーション(CI)と継続的デリバリ(CD)は、自律型チームにとって、動的に生成されたインフラストラクチャを対象として、独自のサービスを高い頻繁でデプロイするためには不可欠なものだ。クラウドネイティブの概念と現代的なインフラストラクチャ・アズ・コードをソフトウェアデリバリシステムに適用することで、“プラットフォームに予め配置され、すべてがコードで処理されるような、新たなサービスのための分離されたパイプラインを短期間で構築”することが可能になる。

障害に耐え、待ち時間なくフィードバックを提供できる、信頼性の高いデリバリシステムを備えることは、現代のソフトウェアデリバリでは前提条件になっている。コンテナ化されたCI/CDインフラストラクチャでは、次のようなことが可能になる。

• 独立したビルド: 必要なエージェントプロファイル(あるアプリケーションにはJava 8だが、別のアプリはまだJava 7で動作している、というように)を備えたクリーンなコンテナが生成され、ビルド時間中のみ実行される。
• エラスティック性: 各ビルドが独自のコンテナエージェントを所有することにより、待ち時間の排除とリソース使用率の向上を実現する。

インフラストラクチャ・アズ・コードを定義することにより、(障害発生時などに)ゼロからのデリバリ復帰を可能にすると同時に、UI経由の変更がバージョン管理下に置かれないために、コンフィギュレーションのぶれが必然的に生じるスノーフレークCI/CDサーバを回避することが可能になる。

Deger氏は、プロジェクトの最初のタスクとして、(新たなサービスのための)新たなパイプラインを短期間かつ予測可能な作業でセットアップ可能であることの重要性を強調した(さもなくば、長いブートストラップ時間を避けるという理由のみで、既存のサービスに対して多くの責任を負わなければならなくなる危険性がある)。コードあるいはコンフィギュレーションとして定義されたパイプライン(ステージ、タスク、依存性、アーティファクトなど)を持つことで､パイプラインを短時間で再生することが可能になり、サービスへの変更が最小の遅延でデリバリできることから、障害からのさらなる迅速な復帰が可能になる。今日ではほとんどのパイプラインオーケストレーションツールが、パイプライン・アズ・コード(実装はまちまちだが)を備えている。

自律的チームはデリバリパイプライン全体を所有する必要があるので、パイプライン定義を対応するサービスのコードと合わせてバージョン管理することを、Deger氏は推奨している。具体的には各サービスが、実際のサービスコードと共に、パイプライン定義やインフラストラクチャコードを含む独自のコードリポジトリを所有するべきだ、というのが氏の意見だ。後者の変更についても、通常のアプリケーション変更と同じくパイプラインを通過することで、トレーサビリティや信頼性を確保することが可能になる。これはつまり、インフラストラクチャの作成あるいは更新は、パイプラインから動的に起動する必要があるということだ。

インフラストラクチャのモノリス化(全サービスの定義を単一のリポジトリに格納する、あるいは定義をデータベースやコンピュートインスタンス、ミドルウェアといったレイヤ別にグループ化する)を回避することは、Deger氏にとって非常に重要な課題だ。サービスバウンダリに合わせて独立したインフラストラクチャのスタック(マイクロインフラストラクチャ)を構築し、分野横断的で変更が少なく、サービスに依存しない部分(ネットワークやセキュリティなど)をグローバルなスタック(マクロインフラストラクチャ)に残すことを、氏は推奨する。サービスは、共有するマクロインフラストラクチャの内部で動作するために、そのパラメータをインポートする。

スライドイメージはChristian Deger氏の提供による

講演で紹介されたもうひとつの重要な概念は、 アプリケーションコードだけでなく、複数のレベルでサービスの依存関係を切り離す(あるいはコントロールする)、というものだ。サービス毎に独立したパイプラインに加えて、その他の依存関係 — 例えばサービスベースイメージ(AMI、Dockerなど) -- を(特定バージョンに対して)固定化することで、例えばイメージのアップデートによって複数のパイプラインが同時に起動され、動作中のシステムの大部分が再デプロイされる、というような、リスクの高い状況を回避する必要がある。

Deger氏の推奨で最も論議を呼びそうなのは、パイプラインにおけるステージング環境を廃止することだ。サービスの変更率が高い(少なくとも時間単位)ことにより、サービスの新バージョンを他のすべてのサービスのライブバージョンに対して(ステージング環境で)テストすることは不可能に近い、と氏は主張する。結果としてステージングを待つ時間がボトルネックになるか、あるいは、ステージングでのテストにおいて複数のサービスの変更が結合されるモノリスをリリースした後にデプロイすることになるか、のいずれかになる。

そうではなく、コンシューマ主導型の契約テストを活用し、運用における修復時間(MTTR)を最小限にすることによって、サービスの変更の独立的なデプロイや、運用環境での動作が期待通りであることの監視が可能になる。さらに影響を低減するためには、カナリアリリース(特に新インスタンスのエラー率やレイテンシ、ロードを厳密に監視する場合)や機能トグル(異常のある機能を即座にオフする)、ブルー・グリーンデプロイメント(少なくともデータベースが変更されていなければ、実行環境を以前にバージョンに短時間でロールバック可能)といったデプロイメント戦略を採用するべきだ。特定のケース(大規模なコードリファクタリングなど)では、ダークローンチが有効な場合もある。ダークローンチでは、デプロイされた新バージョンにもライブ環境と同じ要求を与えることにより、応答が機能的に正しいか、新インスタンスが負荷を処理できているか、などをコントロールするものだ。

講演全体を通じてDeger氏は、デリバリ(自身のパイプラインとCIインスタンスに責任を持つ)からインフラストラクチャ(サービスを実行するマイクロスタックを定義する)、ランタイム(マイクロスタックにログや監視などの運用機能を含む)まで、チームがサービスを所有することの重要性を何度となく強調した。パターンやプラクティス、ガイドラインは共有するべきだが、実際の作業を集中させてはならない。チームの自律性が失われ、他チームとの関係性がデリバリを遅くするからだ。

スライドイメージはChristian Deger氏の提供による