2022年5月、シナジーマーケティングはSynergy!のインフラをオンプレミスからクラウドAWSへ移行するプロジェクトを完了しました。
記事はこちら。
https://corp.synergy-marketing.co.jp/story/article/220907_project-frog
移行前から一部、Terraform / AWS CloudFormation / Ansible などを利用していましたが 移行の際に全面的にTerraformによるIaC（Infrastructure as Code）化を実施しました。
実際に1年近く運用をして改めて感じられるIaCの良い点、苦労している点を紹介したいと思います。
良い点
バージョン管理（Git）の恩恵
あらためて、バージョン管理の素晴らしさを強く実感しています。
バージョン管理をしていれば、「いつ」「だれが」「どう変更したのか」が簡単に追跡できます。
もう、バージョン管理（Git）がない世界には戻れません。
Infrastructureへのバージョン管理の導入は、下記のような問題を実際に解決へ導いてくれました。
- 古い設定や変更などの経緯が追えるようになり、わからないということを防いでくれる。
- 設定やプログラムが各環境、各サーバだけにしかないようなことを防ぐ。
- 過去の設定がバージョン管理により残っており、戻すのが容易。
- メンバーへ設定状況をコードベースで説明できる。
また、CIサーバからTerraform Codeと各環境とで差分が発生していないかを確認するように設定しています。
これにより、手動による変更やクラウド側の仕様変更を素早く検知でき、コードと実態の差をなくすことができています。
オペレーションコスト・人的ミスの減少
システムの動作環境としては、development / staging / productionの3環境を用意しており、これらを同じソースコードで管理するようにしています。
そのため、development環境で構築が終わるタイミングで、残りの環境の準備が整っている状態となります。
以前までは、3環境分の準備と手順、構築が必要でした。またこれらを手順書にしたがって3環境分実施する必要がありました。
今では apply 1つで構築できます。三分の一とは言いませんが、かなりの構築コストの削減となっています。
構築手順書もterraform applyを実行するだけでよく、人的ミスが発生する余地を減らすことができています。
苦労している点
マネージメントコンソールから作成する方が早い場合がある
Terraformの導入にはある程度の学習コストが必要です。Terraformで対応するよりマネージメントコンソールで対応した方が早い場合は多々あります。
将来のメンテナンスコストは下がりますが、その分構築時に時間が掛かることになります。
メンバー間でも議論はありましたが、将来のために割り切ってIaC化を進めることにしました。
運用が進むにつれ、学習が進み学習コストの問題は解決しつつあります。
Terraformに対応していないリソースが存在する
Terraform ( AWS Provider )は高頻度でバージョンアップをしてくれていますが、AWS側でAPIが提供されていないなどいくつかの理由でTerraformに対応していないリソースが存在します。
アップデートのリリースノートを確認するなど定期的にアップデート状況を確認しています。アップデート状況をみて、インポート機能を使い、取り込むようにしています。
また、そのためTerraformと手動で作成したリソースが混在することになります。
default_tags機能を使ってTerraformで作ったリソースにはTagを付与するようにしています。それによりリソースがどのように作られたのか判断しています。
実行に時間が掛かるようになってきた
システム規模によるものが大きいですが、取り扱うクラウドリソースが増え、Terraformの実行に時間がかかるようになってきました。
複数のStateファイルに分けるなど工夫していく必要があると考えています。
最後に
時代は常に変化し続けています。その中で競争に勝ち、成長を続けていくためには、常に新しい時代に適応していく必要があります。
クラウド移行して1年近くたちますが幸いにも大きなトラブルなく運用できています。これからも変化を恐れずに新しい技術を取り入れていきたいと考えています。
KitagawaNaoki最近はインフラまわりを触ることが多いです。
