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の売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話（？）が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。