はじめに
※この記事は「LTSグループAdvent Calendar 2023」の一環として執筆されました。
開発エンジニアとして転職してからそろそろで3年がたちそうで、その間、RubyやPythonを使ったアプリ開発と、AWS環境でのインフラ構築・運用に携わってきました。
今回の記事では、AWSのマネコンで作業していた現状から、Terraformを使って、EC2からFargateへの移行をコードで構成管理できるように進めていることを記載しようと思います。
背景
自社で数年間運用しているサービスのインフラ環境は現在EC2やRDSなどを使った基本的なWebサーバーの構成となっています。
インフラ専門といったチームがあるわけではなく、アプリ開発の一部メンバーが運用・保守をしている状態です。
この状況だと、アプリ開発に集中すべきな一方で、ミドルウェアのアップデートなどが後回しになりがちとなっていました。
そこで、AWS Fargateへ移行し、インフラ管理をタスク定義とDockerfileで管理することができれば、メンテナンスの手間も減少するのではないかと考えました。
ただ、既に稼働中のサービスをEC2からFargateへ移行するために、検証環境と本番環境を別で構築する必要がありました。
マネコンを使って手動で構築すると属人化になりがちになるため、今回をきっかけにインフラ構築をコードで構成管理できるようTerrafromの導入を決めました。
方針とディレクトリ構成
Google Cloudのベストプラクティスを参考に環境ごとでディレクトリを分けるようにしました。
├── envs
│ ├── dev
│ ├── <service-name> # VPCやRDSなどの基本的なインフラコンポーネント
│ │ ├── backend.tf
│ │ ├── locals.tf
│ │ ├── provider.tf
│ │ ├── ...other...
│ ├── monitoring # 監視系のインフラコンポーネント
│ ├── batch # バッチ処理に関するコンポーネント
│ └── cicd # CI/CDに関するコンポーネント
│ └── ...other...
│ ├── prod
│ ├── <service-name>
│ │ ├── backend.tf
│ │ ├── locals.tf
│ │ ├── provider.tf
│ │ ├── ....other...
│ ├── monitoring
│ ├── batch
│ └── cicd
│ └── ...other...
│ └── stg
│ ├── <service-name>
│ │ ├── backend.tf
│ │ ├── locals.tf
│ │ ├── provider.tf
│ │ ├── ...other...
│ ├── monitoring
│ ├── batch
│ └── cicd
│ └── ...other...
├── modules
└── ...other...
進めてみて
moduleは適切に設計して利用すべき
moduleはTerraformの複数のリソースを再利用可能な単位として扱うことができ、とても便利だと思いAWSのリソース単位で作成していたのですが、 こちらの構成だと単なる薄いラッパーとなってしまい。
- モジュールの汎用性が高くはならなかった
- モジュールが大量に作成されていってしまう
という事態に落ちいり、下記記事に記載があるようなアンチパターンにハマってしまいました。
サービスごとのディレクトリ構成の工夫
Terraform導入において、ログ監視やバッチ処理などアプリチームに密に関連しているものに関して、将来的にはアプリチームにも担当してもらえるよう専用のディレクトリを設けてみました。
このようにすることで、アプリチームは自分たちの関心がある分野に集中しやすくなる
一方で、ECSやRDSの基盤よりの作業はインフラチームで効率的に管理できるようになるのではないかと考えています。
最後に
Terraformを取り入れてみて、まだ行き届いていない点も多いのですが、コードによるインフラ管理がもたらす最大のメリットは、属人化の問題を減らせることだと感じています。
今回の学びをもとに積極的にIac化を進めていこうと思います。
参考URL