【入門編】巨大化しすぎたCloudFormationテンプレートの分割・移行アンチパターン:既存スタックの切り離しとインポートの全手順 – インフラ構成管理(IaC)活用バイブル

クラウドインフラの世界へようこそ。君が今直面している「巨大化しすぎたCloudFormationテンプレート」という怪物は、多くのエンジニアが通る試練だ。数千行に及ぶYAMLの海で、たった一行の修正が全世界を壊す恐怖に震える日々は、今日で終わりにしよう。

今日は、サービスを停止させることなく、一枚岩のスタックを安全に分解し、再構築する「外科手術」の手法を授ける。

—

1. なぜ「一枚岩(Monolithic)」は悪なのか?

IaCにおいて、巨大なスタックは「密結合」の温床だ。VPC、DB、アプリケーションが一つのファイルに同居していると、DBの設定を少し変えたいだけなのに、関係のないロードバランサーまで再デプロイの対象になってしまう。

このアンチパターンから脱却する鍵は「疎結合」だ。 リソースのライフサイクルごとにスタックを分割し、責任範囲を明確にする必要がある。

—

2. 安全に切り離すための「外科手術」4ステップ

既存リソースを壊さずに別スタックへ移動させるための、現場で磨き上げられた手順を伝授する。

ステップ1:現状の可視化と依存関係の整理

まずはテンプレートを眺め、どのリソースが「独立して運用可能か」を見極める。ネットワーク(VPC等)とアプリケーション層(EC2/ECS等)で分けるのが鉄則だ。

ステップ2:抽出先スタックの作成(ドライラン)

まずは、切り出したいリソースだけを記述した「新しいテンプレート」を作成する。ただし、まだ既存のリソースとは紐付けない。

ステップ3:Resource Importで「所有権」を奪取する

ここが最大の山場だ。AWSの「リソースインポート機能」を使う。

1. 新規スタックを作成する際、テンプレート内でインポート対象のリソースを定義する。
2. AWSコンソールから「既存のリソースをインポート」を選択。
3. `DeletionPolicy: Retain` を必ず設定する。万が一失敗しても、リソースが消滅するのを防ぐための「命綱」だ。

新しいスタックのテンプレート例
Resources:
MyDatabase:
Type: AWS::RDS::DBInstance
DeletionPolicy: Retain # 失敗時の削除を防ぐ重要設定
Properties:
DBInstanceIdentifier: my-existing-db
# …既存の設定と完全に一致させること

ステップ4:旧スタックからの削除

新スタックでリソースが管理下に入ったことを確認したら、旧スタックから該当リソースのコードを削除する。この際、`DeletionPolicy` を適切に設定しておけば、AWSは「スタックの管理下からは外すが、リソース自体は削除しない」という挙動をとる。

—

3. スタック間の橋渡し:`Export` と `ImportValue` の作法

分断したスタック同士をどう繋ぐか。ここで `Fn::ImportValue` を使う。

  • Export: 親スタック(例:ネットワーク層)で値を公開する。
  • ImportValue: 子スタック(例:アプリ層)でその値を受け取る。

親スタック(VPC)で出力
Outputs:
VpcIdExport:
Value: !Ref MyVPC
Export:
Name: !Sub “${AWS::StackName}-VpcId”

子スタックで参照
Resources:
MySecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
VpcId: !ImportValue “NetworkStack-VpcId”

※注意点: `ImportValue` を使うと、出力側スタックを更新しようとした際に「参照されているから削除できない」というエラーが発生する。これは「依存関係の逆転」を防ぐ健全な強制力だ。疎結合を保つために、この制約と付き合う覚悟を持とう。

—

4. 初心者が陥る「罠」と回避策

  • 罠1:リソース名の衝突

インポート時に名前が重複するとエラーになる。事前に `Resource Identifier` を正確に把握しておくこと。

  • 罠2:修正の連鎖

一度にすべてを分割しようとしないこと。まずは「最も依存関係の少ないリソース」から一つずつ切り出す。「小さく分割し、即座にデプロイして確認する」。これがSREの鉄則だ。

—

さあ、君の手でインフラを解き放とう

一枚岩のテンプレートを分割することは、インフラに「機動力」を与えることと同義だ。変更の影響範囲が小さくなれば、心理的な負担も減り、デプロイの頻度も劇的に上がる。

CloudFormationは一見古臭いツールに見えるかもしれない。しかし、その堅牢さと「状態を管理する」思想は、現代のクラウドアーキテクチャにおいても至高の技術だ。

まずは、小さなリソース一つから分割を試してみてほしい。その成功体験が、君をより高みへと連れて行ってくれるはずだ。応援しているよ。何か詰まったら、いつでもまた聞きに来てくれ。

タイトルとURLをコピーしました