IaCとCI/CDは何を達成すればよいのか？ 導入検討にあたってすべきこと、さけるべきこと
概要と背景
かつて先進的な取り組みであったIaCやCI/CDも昨今はさほど珍しいものではなくなりました。その有益性が実感されていればこそでしょう。DORAのサイトにおいても、“Infrastructure-as-code allows you to manage changes effectively, and to apply information security controls. “と述べられるように、効果的かつセキュアな運用にIaCやCI/CDは大きく貢献します。
しかし具体的にどのようなメリットがあるのかを改めて説明しようとすると意外と難しいものです。そこでこの機にまとめなおしてみました。
DevOpsにつきもののCI/CD、そのメリットとは？
なぜIaCとCI/CDを用いるのか。得るべきそのメリットとは。
IaCとCI/CDのメリットをそれぞれ整理したのが以下の表です。
IaC（Infrastructure as Code）のメリット
| 区分 | 具体的な利点 | 説明 |
|---|---|---|
| 再現性 | 同じコードから何度でも同一環境を構築可能 | 設定漏れや設定ミスの発生を抑止し、環境差異の極めて少ない環境構築が可能になります。 |
| 可読性・共有性 | インフラを設定で可視化できる | 必然的に設定が明文化されるため、知識が属人化しにくくなります。 |
| バージョン管理 | Gitでバージョン管理できる | インフラをGitで管理できます。変更を追いかけるロールバックも容易です。 |
| モジュール化による再利用 | 共通コードで省力化 | 何度も利用する設定をモジュール化して使いまわせば効率よく構築できます。設定ミスがおきづらいことから信頼性も高いです。 |
| ツールの利用 | 静的解析でチェックできる | checkovなどでコードレベルでインフラの構成をチェックできます。 |
実はIaC（インフラのコード化）単体ではメリットを出しづらく、多くはほかの施策や技術と組み合わせることで効果を発揮します。
例えば、再現性や可読性、モジュール化による再利用はそれを可能にするコードを書いてこそ機能します。バージョン管理はGitを導入・運用していなければなりません。静的解析のツールも同様です。
IaCの導入とは、ただTerraform（あるいはCDKやCloudFormation等）を用いるだけではなく、その他のツールや技術も合わせた総合的な施策なのだと言えます。
CI/CDのメリット
| 区分 | 具体的な利点 | 説明 |
|---|---|---|
| 自動化による信頼性向上 | plan -> (approve) -> apply を自動で実行できる | 作業ミスやメンバーごとの手順の違いなどを抑止します。運用の信頼性を向上させます。 |
| テスト・チェックの確実な実行 | 静的解析やterraform planなどを自動実行できる | チェック忘れがなくなります。手動で行っているとフォーマッタやテストツールの実行を忘れるのも日常茶飯事です。 |
| ガバナンス強化 | レビューと承認フローを必須にできる | terraform planの結果とApprove機能のことです。Githubの機能と組み合わせるとさらに強力です。雑な仕事、悪意ある（！）作業を抑止できます |
| 証跡保存 | コード変更・CI 実行ログが残る | ログがチーム共用の場に残るため追跡が容易になります。 |
| アクセス権の保護 | 権限をクラウド上で集中管理できる | 普段はCI/CDで更新するようにしておけばメンバーが普段から強すぎる権限を持たずに済みます。ただしブレイクグラスや、そこまでシビアでないならAssumeRoleなど、臨時作業の手段も用意しておく必要があります。 |
CI/CDの売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話（？）が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。
時折言われるデプロイの高速化については、インフラ構築の世界ではあまり期待すべきでないと思われます。むしろ速度重視ならローカルからterraform applyを実施するほうがよほど早いでしょう。mainブランチにマージしたら即自動でリリースするような運用にすれば話が変わるかもしれませんが、terraform planの結果を確認せずにterraform applyをかけるべきとは思えません。
逆にIaCもCI/CDも実施していなければ何が起こりがちなのか
もしもコード化なし、デプロイ作業の自動化なしという古式ゆかしい状況では何が起こりがちのでしょうか？ 比較のために検討してみました。
IaC未実施
- 設定ミス : 手動変更には設定ミスが付き物です。実際の環境と手順書の差分が生じます。下手をすると手順書自体ありません。何が違うのか以前の問題です。環境差異もしばしば起きて、二次被害を出すことにもなるでしょう。
- 莫大な手間 : 手動変更は量が多いと大変です。Terraformのコードで数分もあれば事足りる作業が一日がかりということもありえます。
CI/CD未実施
- 作業ミスの多発、作業の不統一 : 人のやることですから作業ミスが起こります。また、このようなスタイルでは各メンバーがそれぞれめいめい勝手に自己流で作業することも珍しくないのですが、これも運用負荷を酷く悪化させます。
- 確認作業リードタイム増加 : これは上記の事情にも関わってきます。ミスや不統一なプロセスのために確認作業が重くなるのです。
- 証跡がない : 開発者のローカルにしか記録がない（あるいはローカルにすらない）ため、何か起きても追いかけるのが困難です。
CI/CDの課題
CI/CDはいいことづくめのようですが、やはりメリット・デメリットがあります。総じて運用がうまくまわりはじめた後はメリットが多いものの、そこまでこぎつけるのが大変という傾向があります。
| 分類 | 課題 | 対応策の例 |
|---|---|---|
| 学習が大変 | Terraform/HCL・CIパイプライン・周辺ツールなどなど憶えることが多い | 小さく初めて段階的に展開する。でも最後は頑張るしかない。 |
| 構築運用コスト | CI/CD用環境を構築するのも大変、コードを用意するのも大変。 | 経験者や外部専門家、AIの活用 |
| セキュリティに気をつかう必要あり | 最後はterraform applyを自動で実行するため大きな権限を渡すことになる | 危険があることの認識。承認プロセスや構築したインフラのテストを丁寧に行う。 |
| 遅い | HCLが大きすぎる、スクリプトの作りがまずい、プロセスが必要以上に厳重などの理由でapplyにたどり着くまでが遅い | 本番環境は遅くても信頼性を重視すべき。しかし開発環境では柔軟に対応できないか検討。 |
結論
IaCとCI/CDはチームの規模によらず導入する価値があります。開発効率の向上につながるかはプロジェクトの性格次第と思いますが、信頼性の向上はどのようなプロジェクトでもその恩恵を得られるでしょう。構築・運用の労力や学習コストは小さくないものの、その効果は大きいため、規模の大小にかかわらず、本番稼働する予定のプロジェクトなら極力導入することが望ましいと考えます。
ただし無暗に導入してもメリットが出るとは限らず、かえってデメリットばかり目立つことにもなりかねません。
「なにを得たいのか。そのために何をすべきか」
それを導入前に洗い出しておくことが肝要です。
Show Text to ShareIaCとCI/CDのメリットをおさらい。 得るべきそのメリットとは。 IaCとCI/CDは何を達成すればよいのか？ 導入検討にあたってすべきこと、さけるべきこと https://www.tricrow.com/devops/why-cicd.html
