はじめに
CICDという言葉が一般的になって数年がたとうとしています。
昨今では、IaCがデフォルトとなり、インフラもパイプラインをくむというのが一般的になっているのではないでしょうか？
今回は、インフラ、アプリのパイプラインをどのように設計すべきか、判断ポイントも含めて解説していきたいと思います。
アプリとインフラのCICD
アプリケーションとインフラのCICDについて解説していきます。
まず、インフラに関しては、CloudFormationやCDK、TerraformなどIaCのツールをパイプライン上で実行することでデプロイ、テストが可能です。
アプリケーションについては、考え方が様々です。
アプリケーションを独立したパイプラインとする場合や、アプリケーションはビルドまで、そのイメージのみを利用したインフラでのデプロイです。
以下３つの選択肢が考えられます。それぞれ解説していきます。
- インフラのパイプラインで全てデプロイ
- アプリケーションとインフラのパイプラインを明確に分離
- アプリケーションはビルドまで、デプロイはインフラのパイプラインで実施
インフラのパイプラインですべてのデプロイを実施
シンプルにすべてのデプロイをインフラのパイプラインで実施するパターンです。
この場合、パイプラインも管理対象もシンプルになります。CDK等のIaCツールのコードを管理し、そのコードからデプロイを実行するのみです。アプリケーションの変更で、実際にはインフラに変更がなくても、このパイプラインを実行する必要があります。
アプリケーションとインフラのパイプラインを明確に分離
アプリケーション部分をインフラのパイプラインから切り離す構成です。この例で考えてみると、コンテナ部分の管理をIaCから切り離し、APPのパイプラインでデプロイを実行、それ以外の変更の場合、インフラのパイプラインで変更するという構成になります。コンテナ部分がIaCと乖離したり、管理外となってしまうことが多少気になりますが、アプリケーションのデプロイを切り離すことができるので、頻繁なAppデプロイや、チーム構成によっては開発のスピード向上に繋がります。
アプリケーションはビルドまで、デプロイはインフラのパイプラインで実施
ちょうど中間の構成です。アプリケーション側のパイプラインではビルドとイメージ格納までを担当します。それ以外はすべてインフラのパイプラインで実行、IaCとの乖離も発生しません。
チーム構成と責任
様々なチーム構成が考えられます。大規模PJで典型的なパターンとしては、インフラとアプリが明確に別れたチーム構成です。また、アプリケーション毎に小さなチームが存在する構成、運用と開発でチームが分かれている構成など、様々です。何がいいかは、その運用の仕方や構成によって変わるので、一概には言えません。重要なのは、そのチームの責任範囲がどこなのか、それは適切なのかという点です。
例えば、アプリケーションチームに開発権限があるが、インフラがすべてのデプロイをしているというケースでは、アプリケーションチームが開発をするたびに、インフラチームにデプロイの依頼がいくことになるでしょう。デプロイの頻度が多ければ多いほど、インフラチームの負荷は高まります。また、デプロイの正常性確認はインフラチームでは判断できないので、その都度アプリケーション側に判断を求めたりテストを依頼するなどやり取りが増加するでしょう。この場合、アプリケーションチームにデプロイの責任を委ねるということも選択肢として考えることができます。アプリケーションチームがアプリケーションのデプロイに責任をもつことで、パイプラインと責任を切り離します。アプリケーションのデプロイにインフラチームが関与することなくデプロイが実施できるため、開発スピードとかけるコストが削減できるのです。
案ごとのメリデメ
| 案 | メリット | デメリット |
|---|---|---|
| インフラのパイプラインですべてのデプロイを実施 | インフラ側でAWS上の設定値すべてを管理できる、IaC＝実機状態が担保可能 | アプリケーションの変更などにおいても、IaCの実行が必須、デプロイにインフラチームの稼働が必要、デプロイに時間がかかる可能性がある |
| アプリケーションとインフラのパイプラインを明確に分離 | アプリケーションのデプロイをインフラ依存無しで実行可能、開発スピードの向上 | アプリケーションチームがパイプラインを理解する必要がある、IaCとコンフリクトをおこないように注意が必要 |
| アプリケーションはビルドまで、デプロイはインフラのパイプラインで実施 | インフラパイプラインと同様、責任が明確になる | インフラパイプラインと同様 |
案ごとの選択基準とメリット・デメリット
| 案 | 適用が適切なケース | メリット | デメリット |
|---|---|---|---|
| インフラのパイプラインですべてのデプロイを実施 | - チーム規模が小さく、インフラ・アプリを一括で管理可能 - アプリ変更が頻繁ではない - IaCを100%正確に適用したい |
- AWS上の設定値すべてをインフラチームが一元管理可能 - IaCと実機状態が常に一致する |
- アプリ変更時でもIaCの実行が必要で効率が悪い - デプロイ時にインフラチームの稼働が必要 - デプロイに時間がかかる可能性 |
| アプリケーションとインフラのパイプラインを明確に分離 | - アプリケーションのデプロイ頻度が非常に高い - アプリとインフラを別々のチームが管理 - 開発スピードを優先したい |
- アプリケーションのデプロイをインフラ依存なしで実施可能 - 開発スピードの向上 - チーム間の責任分離が明確 |
- アプリチームがパイプラインを理解する必要がある - IaCとの乖離が発生する可能性 |
| アプリケーションはビルドまで、デプロイはインフラのパイプラインで実施 | - 中規模以上のチームで、アプリとインフラの管理を部分的に分離したい - IaCの一貫性を担保しつつ、開発スピードも重視したい |
- IaCとの乖離が発生しない - 責任分担が明確になる - インフラ変更を伴うデプロイに一元化できる |
- インフラチームがデプロイ頻度の増加に対応する必要がある |
選択基準の具体例
インフラのパイプラインですべてのデプロイを実施
- 適用例: 小規模スタートアップで、インフラとアプリケーションを同じエンジニアが管理している場合。
- 注意点: アプリケーションの更新頻度が増えると運用負担が大きくなるため、規模が拡大した場合は構成の見直しを検討。
アプリケーションとインフラのパイプラインを明確に分離
- 適用例: 大規模プロジェクトで、インフラチームとアプリケーションチームが独立して動いている場合。特にコンテナやサーバーレス環境で頻繁なデプロイが必要な場合。
- 注意点: IaCとアプリの間で設定や環境が乖離しないように、明確なルールやモニタリングが必要。
アプリケーションはビルドまで、デプロイはインフラのパイプラインで実施
- 適用例: アプリケーションチームがデプロイ作業を理解していない場合や、IaCの一貫性を重視したい場合。
- 注意点: 中規模以上のプロジェクトでは、デプロイの効率化や自動化の工夫が必要になる。
まとめ
CICDやIaCを活用したインフラとアプリケーションのパイプライン設計には、プロジェクト規模やチーム構成、デプロイ頻度などによって適切な構成が異なります。
選択のポイント
-
チーム構成
- チーム間での責任範囲を明確化し、デプロイ作業の効率を最大化。
-
デプロイ頻度
- 頻繁なデプロイが必要な場合は、アプリとインフラを分離した方が効率的。
-
プロジェクト規模
- 小規模ならシンプルな構成、大規模ならスケールを意識した構成が有効。
-
IaCとの整合性
- IaCとの乖離を防ぐ仕組み（テストやモニタリング）を構築する。
最適なCICD構成を選ぶことで、チームの生産性向上や運用コスト削減が期待できます。プロジェクトの状況や課題を踏まえ、柔軟に対応することが重要です。