こんにちは。miztr55です。
今回は、IaC（Terraform）の導入についていろいろ大変だったので、振り返りも兼ねて備忘録的に書いています。
後述の対象者にとって有益なものになると幸いです。
2023.6 - 2023.9の間に実装したものを記事にしてますので、その当時のものになります。
対象者
- IaC、特にTerraformの導入を検討している
- そのメリット、デメリットを把握したい
- 他社事例を見てみたい
※実装の技術的な部分を前提として、「導入したときにどうなったか」にフォーカスした記事になります
参考：Terraform連載 第1回：いまさら聞けない、IaCってなに？～Terraform、IaSQLの紹介～ | NTTテクノクロスブログ
1. 背景や前提
- AWSでのインフラ構築をしているが、基本的にマネジメントコンソール上での操作のみであった
- Terraformで信頼性やスピードを上げて日々の業務を効率化させたかった（ミスの低減や作業スピードの向上）
- 過去にTerraformでの構築をやっていた（後から知る）が、現状はやれておらず、コンソール上での操作のみになっている
- 実装担当者である筆者は、久々にAWSを触るほぼジュニアなインフラ（SRE）エンジニア
2. 経緯
- 新しくプロダクトをリリースするということで、IaC、つまりTerraformでAWSリソースの構築することになる
- 構築するにあたって最低限必要なAWSリソースを定め、本構築プロジェクトのゴールとした
- それ以外のリソースは、Terraformで作成せず、マネジメントコンソール上で作成
- （この時点で、Terraformのコードによるリソースと、コンソール上で作成したリソースが混在）
- 一旦、構築完了したのでリリース（検証、本番環境）
- その後、残りのリソースをTerraformで作成し、完全なコード化を目指そうとするが、実装の方法を踏まえると、負荷が大きいことやデプロイのしづらさが判明.
- Import や planをもちろん駆使していたが、完全コード化の道のりは長く、完全コード化の後の運用スピードが向上するかどうかは懐疑的
- あとで判明したこと.
- 本プロジェクト自体、リリース後の運用を考えずにスタートしていた
- 過去にやっていたTerraformの実装も新規構築だけで、リリース後の運用はやっていなかった（つまり、リリース後の運用実績が自社でなかった）
- え、この辺をちゃんと考えてやらなきゃいけなくね、、、？？
3. 結論
- 良かった点
- 反省点
- 上記の反省点を克服できるような工夫ができればいいが、会社の状況や体制を鑑みて導入するのがベター（あたりまえだが、、）
- つまり、ちゃんと目的を言語化し、それが達成できるかどうかを考えながら導入するのが良い（あたりま(ry）
4. 反省点を踏まえ、工夫して克服した点
- 同じアカウント上で、混在したリソースをすべてコード化するのではなく、別アカウントへ全てコード化されたものを新規で構築するという方針で切り替える
- 切り替え時はアカウントごと切り替えて、古いアカウントは破棄する
- そうすれば、混在時のコンフリクトも起きないので安全に切り替えができる（古いアカウントのリソースを過不足なく作成することが前提）
5. 所感
きちんと振り返りをチーム内で実施し、少しやり方を変えたことで大きな事故は起きなかったのかなと感じています。
本記事の方法がベストな選択とは思いませんが、一旦は前に進めることができたのではないかと思います。
一般論的にはメリットもありますので、うまくそのメリットを享受できるようにすればいいですが、苦労している他社さんもいらっしゃるのではないかと思います。（他社さんにヒアリングしたところ、似たようなところにぶち当たっているようでした）
この記事の内容を踏まえ、ぜひチャレンジしてみてください。そして、いい方法を弊社まで共有お願いできればと思います（笑）
その他
- 利用していたもの
- GitHub
- 新規構築時）Terraform Module
