スタック同士を依存させたら、一部だけ直したいのに CloudFront が作り直された — CDK の参照を SSM Parameter Store 経由に外した話
AWS CDK でスタックを分割し、CloudFormation の Export / Fn.importValue で値を渡していたら、部分的に直したいだけの変更で CloudFront ディストリビューションが作り直しになった。当時は Route 53 も未導入で、作り直すたび外部の DNS サービスにサブドメインを登録し直す羽目に。スタック間参照を SSM Parameter Store 経由に外して疎結合にした経緯。
はじめに
インフラをコードで書くとき、ある程度の規模になるとスタック（デプロイの単位）を分割する。ネットワークを作るスタック、ロードバランサを作るスタック、アプリを載せるスタック——といった具合だ。
分けたら当然、あるスタックが作ったものの ID を、別のスタックから参照したいという話になる。ここで素直に「スタック同士を直接つなぐ」やり方を選んだ結果、しばらく痛い目を見た。本記事はその話と、参照の仕方を変えて抜けた経緯。
素直な参照＝スタック同士を固く結ぶこと
CloudFormation には、スタックが値を Export し、別のスタックが Fn.importValue で参照する仕組みがある。CDK からも素直に書けるので、最初はこれで組んでいた。
問題は、この参照が依存関係そのものになることだ。Export された値が他から参照されている間、その値を変更したり、出している側を作り直したりできない。参照している側が事実上のロックになる。
つまり「値を借りている」つもりが、実態としてはスタック同士が固く結ばれている。片方を触りたいだけなのに、もう片方が邪魔をする。
何が起きたか：一部を直したいだけで CloudFront が作り直しになる
具体的にどう痛かったか。
インフラを部分的に更新したいだけの場面で、依存が絡んでCloudFront ディストリビューションが作り直しになることがあった。作り直しになるとドメイン名（xxxx.cloudfront.net）が変わる。しかも CloudFront は作成も伝播も速い部類ではないので、待ち時間もそれなりに乗る。
さらに間の悪いことに、当時はまだRoute 53 を使っていなかった。ドメインは外部の DNS サービスで持っていて、サブドメインの向き先も手で登録していた。結果どうなるか——作り直しのたびに、その管理画面を開いてサブドメインを登録し直す。
「ちょっと直したい」が、毎回この儀式を引き連れてくる。手間がかかるだけでなく、その間はサイトが正しく引けない時間も生まれる。作業のたびに憂鬱になる類の面倒さだった。
直し方：直接つながず、置き場を一つ挟む
そこで、参照の仕方を変えた。スタック同士を直接つながず、SSM Parameter Store（AWS Systems Manager のパラメータストア）を経由させる。
- 値を作った側は、その ID を決まった名前でパラメータとして書き出す（CDK なら
ssm.StringParameter）。 - 使う側は、同じ名前で読む（
ssm.StringParameter.valueForStringParameter）。
これだけで、CloudFormation 上の依存関係が消える。つながっているのは「パラメータ名という文字列」だけになり、片方を作り直しても、もう片方が反対しない。デプロイの順序も、更新の自由度も一気に楽になった。
失うものもある。CloudFormation が依存関係を把握しなくなるので、「参照されている値をうっかり消す」のを止めてくれる仕組みも同時に手放すことになる。要は、安全装置と引き換えに自由を買っている。ただ自分の場合、その安全装置は事故を防ぐより先に「部分的に直せない」という形で毎回牙を剥いていたので、迷いはなかった。
キー名は必ず定数に寄せる
参照が文字列になる以上、打ち間違いが一番怖い。書き出す側と読む側でキーが 1 文字ずれても、CDK も CloudFormation も何も教えてくれない。デプロイして初めて「見つからない」と言われる。
なので、キー名は定数として 1 箇所にまとめ、両側から同じ定数を呼ぶようにした。命名も /{プロジェクト}/{スコープ}/{環境}/{リソース} のような階層に統一している。こうしておくと、Parameter Store を一覧したときに「どのスタックが・どの環境向けに出した値か」がそのまま読める。型の後ろ盾を失った分は、命名と定数化で取り返すという考え方だ。
後日談：Route 53 に移したら痛みの半分が消えた
その後、DNS も Route 53 へ移した。レコードを CDK で管理できるようになったので、作り直しのたびに外部サービスの画面を開く儀式は消えた。
順序としては逆になったが、振り返ると当時の痛みは二つの原因の掛け算だった。スタック同士が固く結ばれていたことと、手で運用していた部分が経路上に残っていたこと。片方だけ直しても半分しか楽にならない。実際、参照を疎結合にした時点で「作り直しが起きにくく」なり、Route 53 へ移した時点で「作り直しが起きても痛くなく」なった。
おわりに
IaC でスタックを分割すると、必ず「値の受け渡し」が問題になる。CloudFormation の Export のように用意されている素直な手段は、たいてい依存関係とセットになっていて、書きやすさと引き換えに更新の自由度を差し出している。
小さいうちはそれで困らない。困り始めるのは、全部を作り直したくないほど育ってからだ。しかもその頃には、依存を外す作業自体が面倒になっている。
この件で学んだのは、分割の設計で見るべきは「どう繋ぐか」より「どこを独立して作り直せるようにしておくか」だということ。作り直したい単位が独立していないと、規模が大きくなるほど手が出せなくなる。参照を Parameter Store 経由にするのは、そのための一番安い手段だった。