AWS Lambda + API Gatewayでサーバーレスのメール送信関数を用意することにした。
そして、そのインフラ構築にTerraformを利用してみたのだが、結論、API GatewayとTerraformはどうにも相性がよくないように思われる。
なにが困るのか
- 開発時、ガンガンデプロイしてトライ＆エラーを繰り返したい開発の作業と、どうしても慎重な操作を必要とするTerraformはあんまり合ってない。
- 本番は本番で、まるまる全て更新しようとするTerraformと、変更点は必要最小限に抑えたい本番デプロイという作業では方向性がずれている気がしてならない。うっかりAPI GatewayのデプロイIDを更新してしまうとデグレードを起こしてしまうという問題が実際に起きた。個人の開発環境なのでそこまで大きな問題ではなかったが、これを業務で起こすリスクを背負い続けるのは相当嫌なものがある。
- Terraformで作るとなるとインフラエンジニアの得意分野になってくるわけだが、APIの構築や設計はアプリケーションエンジニアが自由にしたい部分。いちいちインフラエンジニアにお伺いを立てないとAPIの設計もままならない開発体制というのはいかがなものか？
ではどうするか
コンソールからの手作業は再現性が怪しくなるので、それはそれで嬉しくない。
そこで、API GatewayはTerraformを使わないか、使うにしても初期構築だけに留める。そしてCLIのようにコマンド化されつつもTerraformよりは柔軟に対応できるツールで運用するほうがよいのではないかと思われる。使ったことはないが、CDKももしかしたら便利かもしれない。
なんにせよ、根本的に、アプリケーションエンジニアがTerraformを使わねばならない開発体制は負担が大きくなりがちである。アプリケーションエンジニアが自由に作業できるべき業務については、Terraformのコードをゴリゴリ触らないと作業ができないよう設計するよりも、インフラエンジニア側が歩み寄って（つまりTerraformに一元化できなくなる点は妥協して）、アプリケーションエンジニアが作業しやすいよう開発体制を設計したほうがよいことが多いのでは、と個人的に思う。
