PlatformCon 2023セッション紹介。今回はIaCについて。「How Infrastructure as Code should feel」
アプリケーションの開発の場合、様々な体験・知見から「こうあるべきだ」というのは数多く言われています。では同じようなものであるIaCではいかがでしょうか。私自身、「これはどうなんだろ？」「どういう状態になっていればいいのかな」と考えることがありました。
そうした中でこのセッションを見た時に「これは役立ち情報だ！！」と感じたので今回ご紹介させていただきます。
ターゲットユーザー
IaCはこうあるべきだ
こんなこと感じたことはありませんか？
- IaCの変更をするのは怖い
- IaCでやっていると作業が遅くなる
- IaCコードベースがスパゲッティ状態
これらを感じる場合はまさに次のことに注意しなければなりません。
IaC should feel Safe
変更するのは怖いというのはつまりそれが安全でなく、リスクがあると感じているからです。 IaCは「安全」でなければなりません。
では「安全」にするにはどうしたら良いでしょうか？
■ 開発環境を用意する
プロダクション環境に適用する前に変更を実際にテストできなければなりません。IaCは何度も環境を作ることができるものなのですから、それを実施すべきです（テストすべきです）
注意しなければならないのは「本当の開発環境を用意できているか」です。
あなたがテストしようとしたときに他の人が困る（叫び声をあげる）ことはありませんか？ もしそうならそれは誰か他の人のテスト環境をメンテナンスしているだけです。テスト環境を持っているとは言えません。
■ その変更、何が起きるか理解できていますか？
何が起きるかわからないからリスクがあると感じるものです。Terraformなどには「Plan」という機能がありますのでぜひ実行しましょう。すべての開発者は「Plan」を実行できるようにしましょう。また、PullRequestで「Plan」を実行するようにすると良いでしょう。
Iac should feel Stable
本番環境は「Long-lived」で「予測可能」であって欲しいものです。特にアプリケーションにとっては安定した環境上で稼働させたいものです。
■ アプリケーションとインフラストラクチャはどの程度依存していますか？
Iacは周囲への影響が低くあるべきです。もしIaCのデプロイとともにアプリケーションの修正・デプロイも必要とするならIaCとアプリケーションの結合度が高すぎです。アプリケーションとインフラの境界を明確にすべきです。
■ 修正はIaCの中だけで行われていますか？
変更は一度だけ、IaCの中で行われるべきです。手動で直接変更して確認しそれからIaCに修正するなどといったことはしないようにしましょう。
システムが所有権を巡って競合しないようにしましょう。例えばシークレットのローテーションやイメージ更新による自動化などはこうした競合の原因になることがあります。
Iac should feel Comprehensive
IaCは包括的（またはUnderstandable、理解しやすいもの）であるべきです。理解しやすいものであれば誰も変更を避けようとはしません。理解できないコード（IaC）は理解できないインフラストラクチャを意味します。理解できなければ修正もできないということになります。
■ IaCが複雑過ぎませんか？
IaCはシンプルであるべきです（KISSの原則）。オプションなども用意すればよいというものでもありません。そのようにできるということは、そのようにすべきということではないのです。他のエンジニアがわかるようにオプションなども必要なものののみ用意するべきです。もしそれができない（多数のオプションを用意する）ならば、詳しいドキュメントを用意すべきです。たえずそうした複雑性を導入すべきかを考えて実施しなければなりません（そうでなければシンプルなものを維持すべきです）。
■ IaCが抽象化しすぎていませんか？
Terraform modulesなどは小さな再利用可能な部品を提供できます。これは複雑性を内側に隠すことができますしDRYの原則でもあります。しかしよくある間違いは、「時期尚早な最適化」です。早期に抽象化してしまったことで変更が発生し、利用側にも影響を与えるということが考えられます。
また、サードパーティモジュールに対しては健全な懐疑心を持つべきです。オープンソースコミュニティでもモジュールは提供されていますが、何が行われるかわからない状態のまま利用すべきではありません。十分に中身を理解するメンタルモデルが重要となります。
最後にネーミングというのはいつでも難しいものです。しかし、それを考える価値は十分にあります。わかりやすいモジュール名は重要ですし、アーキテクチャを明確にするために必要に応じてモジュールの細分化を（恐れることなく）実施すべきです。
Iac should feel Fast
もしすでに定義されたIaCがあるならば、手動によるインフラストラクチャ作成が速いとは感じないはずです。
■ デプロイメントが大きくなりすぎていませんか？
IaCツールは実行時に環境のQueryやDriftの確認などを行うため、大きなデプロイメントではその時間が長くなります。デプロイメントを分割することでこうしたツールの実行時間が短縮されます。
■ 自動化は十分になされていますか？
IaCの利点は一度コードを書けば何度でもそれをデプロイできる点です。しかしそのデプロイを手動で行っている場合、複数の環境に変更をデプロイする場合何度も繰り返し実行しなければならなくなります（たとえそれが小さい修正であったとしても）。アプリケーションのCICDと同じようにIaCも自動的に実行できるようにすべきです。
適切なツールを選びましょう
組織やツールを利用するチームのスキルなどを考慮し利用するツールを決定しましょう。AWSのみを利用し、JavaScriptでのアプリケーション開発も行っているチームを対象にするならばAWS CDKなど利用することも問題有りません。CDKはAWSしか対応していませんが、もともとそれ以外使っていないのですから。 逆にある一定の大きさの組織で利用を検討する場合こうした判断はできません。複数のクラウドプロバイダーを利用していることもあります。こうした環境ではTerraformなどのツールを利用するのが最善であると考えられます。
最後に
いかがだったでしょうか。 本セッションはIaCによるインフラストラクチャ管理を行っていく上で非常に役立つ情報になるのではないでしょうか。 ぜひ今回の内容を踏まえてIaCの開発・管理方法をあらためて見直してみてはいかがでしょうか。
