エンジニアの皆さん、こんにちは。
インフラの世界で避けて通れない最大の恐怖、それは「本番環境でのリソース差し替えによるダウンタイム」です。特にRDSやDynamoDB、あるいは複雑なネットワーク構成において、一度構築したリソースを「安全に」別のリソースへと切り替える作業は、多くのエンジニアが冷や汗をかく瞬間でしょう。
今日は、AWS CloudFormationの奥義とも言える`DeletionPolicy`と`DependsOn`を組み合わせ、「ダウンタイムゼロの移行（Blue/Green的なリソース置き換え）」を実現するテクニックを伝授します。
これは単なるツール操作ではなく、「インフラの生存戦略」そのものです。マスターすれば、あなたのデプロイに対する恐怖心は消え去ります。
—
1. なぜ「DeletionPolicy」と「DependsOn」が重要なのか？
CloudFormationはデフォルトでは「既存リソースを更新する」挙動をとります。しかし、データベースの型変更や特定の属性変更は、強制的な「リソースの削除と再作成」を伴い、その瞬間にサービスは停止します。
- `DeletionPolicy: Retain`: スタックからリソースが削除されても、実体（データ）をAWS上に残し続ける。これがないと、リソース差し替え時にデータが消滅します。
- `DependsOn`: CloudFormationの実行順序を強制的にコントロールする。これを使わないと、新リソースが立ち上がる前に旧リソースが消され、通信の断絶が発生します。
この2つを組み合わせることで、「新リソースの生存を確認してから、旧リソースを安全に切り離す」という、極めて高度なフローが構築できるのです。
—
2. 実践：安全なリソース置き換えテンプレート
ここでは、DBの接続先や設定を無停止で切り替えるようなシナリオを想定したコードの核心部分を見ていきましょう。
Resources:
# 旧リソース（最初はこれを使っている）
OldDatabase:
Type: AWS::RDS::DBInstance
Properties:
DBInstanceClass: db.t3.micro
# 重要な防衛策：スタック更新で削除されても手動で消えるのを防ぐ
DeletionPolicy: Retain
# 新リソース（準備段階）
NewDatabase:
Type: AWS::RDS::DBInstance
Properties:
DBInstanceClass: db.t3.small # インスタンスタイプを変更した新しいDB
# 明示的な依存関係：新DBが完全に立ち上がるまで、旧DBの処理を待機させる
DependsOn:
- OldDatabase
# アプリケーションサーバー（新DBを参照するように更新する）
AppServer:
Type: AWS::EC2::Instance
Properties:
UserData:
Fn::Base64: !Sub |
#!/bin/bash
# 新しいDBエンドポイントに接続先を切り替えるスクリプト
echo “Connecting to ${NewDatabase.Endpoint.Address}” > /var/www/html/db_config
DependsOn:
- NewDatabase
—
3. 本番環境での「極限の安全」を担保する手順
テンプレートを書いただけでは不十分です。以下の手順を踏むことで、事故を確実に防ぎます。
1. Retentionの徹底: `DeletionPolicy: Retain` を付けた状態で一度スタックを更新します。これにより、万が一新しいリソースに不具合があっても、旧リソースはAWS上に無傷で残ります。
2. 検証フェーズ: `NewDatabase` が立ち上がった状態で、アプリケーション側が新旧どちらのDBを参照しているかログを確認します。
3. 切り替え（フェイルオーバー）: アプリ側の設定を新DBへ完全に向けます。
4. クリーンアップ: 全てが安定稼働していることを確認した後、初めて `DeletionPolicy` を解除するか、手動で不要になった `OldDatabase` を削除します。
—
4. 初心者の方へ：最初の一歩（Hello World的アプローチ）
まずは、簡単なS3バケットで練習してみましょう。
1. 環境準備: AWS CLIをインストールし、`aws configure` で認証情報を設定してください。
2. テンプレート作成: 上記の `Retain` を使ったS3バケットを作成し、一度 `aws cloudformation deploy` でデプロイします。
3. リソースの置き換え: テンプレートのバケット名を変更し、再度デプロイします。
4. 確認: コンソールを確認してください。古いバケットが「削除されずに残っている」ことが確認できれば、あなたはもう「破壊を恐れないインフラエンジニア」の入り口に立っています。
—
最後に：エンジニアとしての心構え
「自動化」とは、単にコードを書くことではありません。「失敗した時にどうリカバリするか」というリスクの可視化をコードの中に組み込むことです。
`DeletionPolicy` と `DependsOn` は、インフラエンジニアにとっての「安全装置」です。これらを使いこなすことで、あなたの構築するインフラは、より堅牢で、かつ大胆な進化ができるようになります。
毎日のデプロイが、「怖い作業」から「確実な成果を出す作業」に変わる。その感覚をぜひ味わってみてください。何か詰まったら、いつでもまた聞きに来てくださいね。応援しています！