この記事はWanoグループ Advent Calendar 2020１9日目の記事になります。19ったら19です。
AWSでInfrastructure as Code、やってるでしょうか。
やるにしても辛いことも多いですね。
最近やってるものの構成や困ったところをメモしておきます。
今やってる構成
現行プロダクトでは、
- s3やrdsなどステートフルなものや、ライフサイクル上いろんなアプリから参照されるものは「コンポーネント目線で水平分割」(terraform)
- インフラという以上にアプリ寄りのコンポーネントや最悪消えてもいいものは「サービス目線で自由に垂直分割」(ツール自由)
くらいでふわふわやってます。
以下のような構成です。
v2
├── data_id
│ ├── 01_emulated_resources.tf
│ ├── 02_existed_resources.tf
│ ├── 03_ssm_params.tf
│ ├── Readme.md
│ ├── outputs.tf
│ └── variables.tf
├── production
│ ├── ap-northeast-1
│ │ ├── backend
│ │ └── service
│ └── global
│ ├── 000_route53_hostzone
│ ├── 010_acm
│ ├── 015_cdn
│ └── 020_route53_record
└── stage
├── ap-northeast-1
│ ├── backend
│ └── service
└── global
├── 000_route53_hostzone
├── 010_acm
├── 015_cdn
└── 020_route53_record
だんだん「がんばらないIaC」がテーマになっていったので、
- 愚直な構成でworkspaceは使わない
- moduleはあんまり使わない
- 過度なtfstateやcloudformation stackの水平分割/DRYは行わない(せいぜいステートフルなものに留める)
- 変更頻度が少ないものは非IaCな既存リソース使ってもOK(ただしmoduleとしてarn等の集約はする)
くらいの温度感でやっています。
垂直/水平、ライフサイクルの視座
IaCはそもそも「宣言的であること」「冪等であること」に核心があり、jsonやらyamlやらhclやらのDSLで記述することから始まったと認識しています。
どっちかというとweb3層っぽいのの基盤を構築するのが得意だったんですね。
ですが特にSaaSやらビジネスロジックよりのコンポーネントやらも併せて扱いたいという欲求が出てきて、現実にはデプロイライフサイクルと依存関係で皆一回は分割構成に迷うことになるかと思います。
よくある例だと、「Lambda」ですね。
「依存関係や認可管理はIaCツール内で解決したいけど、コード自体はバリバリビジネスロジックなので別で管理/デプロイしたい」ということがちょくちょくあります。
現行プロジェクトでは、ちょっとしたものはIaCツール上でコードも一緒にデプロイしちゃっています。
それとは別に、「重要なロジックを持ったLambda」や「StepFunctionsなどばりばりにビジネスロジックを持ったクラウドコンポーネント」は、LambdaやStepFunctionsなどガワやダミーだけterraformでデプロイ(Create)し、ロジックやコード本体は別デプロイ(Update)とするみたいなことをやっています。
(terraformはignore_changeがあるのでこういうことはしやすいです。)
もちろん、サーバーレスアプリなどそもそもビジネスロジック寄りのシステムはそれ全体で垂直分割する、などの判断もあるかと思います。
その場合でもライフサイクルや他のアプリとの関係などの視座は必要ですね。
宣言的であることと依存関係と
tfstateやstackを分けると、現実には宣言的と言いながらもデプロイオペレーションが発生します。
よくある例だとroute53,cloudfront,acm,s3の関係性が考えたようには依存が一方向に綺麗にはならない、みたいなやつですね。
このへんはterraformなりcloudformationなりの問題というより、AWS初期のコンポーネントにありがちな相互依存や独自arn生成みたいなものが辛さの中心にある気がします。
gitopsとかCIでインフラ構築されてる方とかこれみんなどうやってるんですかね?
今は前述のコード例のように、tfstate(stack)別にprefixで番号を振り、擬似的に依存の順番を表現しています。
これから
大きくなっていくシステムを助ける上で、これからもクラウドコンポーネントにはだいぶお世話になっていきます。と同時にそれを適切に管理するためのプラクティスも2021年は引き続き学んでいきたいですね。ただしあんまりがっつりがんばらない。