デジタル庁クラウドチームが説明しようとしないIaCを導入する本当の意義

デジタル庁クラウドチームはモダンなシステム構築の手法としてIaCの利用を勧めている。しかし、これまた説明に具体性がなくよくないので役に立つのか疑問に思われている。

IaCは宣言型プログラミング言語でインフラストラクチャーのリソース配置を記す技術（e.g. terraform）の総称で、クラウド事業者のサービスやコンテナオーケストレーションツール（i.e. Kubernetes）にそのコードを書いたテキストファイルを読み込ませることで、クラウドの設定を行うことができる。

この説明からだと利点が想像できないと思うが、デジタル庁クラウドチームの以下の説明^*1でも分からないと思う。

インフラの運用管理をクラウドのコンソールやコマンド操作ではなく、コード化しコードを実行することでインフラを構築、変更する。

• IaCはインフラ構成をコードとして管理し、変更管理もIaCコードで行う。CI/CDパイプラインと組み合わせてIaCコードのデプロイを自動化することで、インフラの構成変更を環境へログインしたり手作業することなく実施する。
• IaCはクラウドのマネージドサービスを使用することで、すべてのインフラ機能を一元的にコードで表現できるようになる。ただし、データベースやストレージ等の永続データを保管するサービスについてはIaCによる管理から外す等の工夫が必要となる。

何がIaCの利点か分かっていない気がする。少なくとも、予備知識のない読み手は理解できない。自動化をしても「リリース頻度が高くない基幹系システムでは大きな効果は見込めない」という感想が述べられていた。

だが、オペレーターから見てIaCの利点は明快で、更新頻度が低くても利益がある。

ドキュメントを最新に保てる

ドキュメント化で頻繁に問題になるのは、稼動システムよりもドキュメントが古いことが頻繁に起きることだ。手順書の誤りが発見された後、オペレーターが臨機応変に対応してしまい、手順書が更新されないなどで起きる。だが、IaCで運用すればコードを書いたテキストファイルが常に最新だ。そして、可視化ツールなどでそこから図示もできる。

dry-runによる作業の事前検証の容易化

手順書の作成はそれが正しいものか確認するのに骨が折れる。セットアップに何時間もかかるような場合、試験環境で通しで作業できるようになるまでも大変だ。IaCで書いておくとdry-run（e.g. terraform plan）でテストができ、結果を確認できる。運用中のシステムを変更する場合、変更箇所（差分）も出る。

コーディング支援ツールの利用が可能

テキストだけに、Gitのような分散バージョン管理システムが利用できる。また、ここ数年で生成AIのコーディング支援を受けやすいと言う利点が新たに出てきた。ハルシネーションが怖いかも知れないが、そこはdry-runと併用するので問題は抑制できる。

図示と事前検証の自動化もあるので自動化に御利益があるのは嘘ではないが、デジタル庁クラウドチームは「デプロイを自動化」としか言っていないから御利益が分からない。継続的インテグレーションおよび継続的デプロイメント (CI/CD) パイプラインに言及があるので、上述についても念頭にある可能性もあるが、CI/CDパイプラインが何を意味するのかはそんなに自明ではない。

こういうことはAWSでのterraformの使い方を調べていけばすぐ分かることなのだが、インフラエンジニアではないとそういう事はまずしない。忙しいので。役所のIT担当者が分かるように、マニュアルの概説をコピペしたかのような説明ではなくて、実際のオペレーションを思い出しながら説明を書いて欲しかった。

*1ガバメントクラウドにおけるモダン化の定義 | ガバメントクラウドの全般的なガイド | GCASガイド