枯れた技術を「攻め」の武器に：Terraformによるブルーカナリア・デプロイメントの真髄
インフラ構築において、Terraformを単なるリソース生成ツールと見なしているなら、それは大きな損失だ。Terraformは、「あるべき状態を宣言し、差分を埋める」という強力な再帰的アプローチを持つ。これを利用すれば、複雑なデプロイ戦略さえも宣言的コードの一部として管理できる。
今回は、ブルーグリーンデプロイとカナリアリリースを融合させた「ブルーカナリア」を、Terraformの`random`プロバイダとRoute 53の加重ルーティングを用いて、堅牢かつスケーラブルに実装する方法を紐解く。
—
1. なぜ「宣言的」なトラフィック制御が必要なのか
多くの現場では、デプロイ後のトラフィック切り替えをCI/CDツール（JenkinsやGitHub Actions）のスクリプトで力技で行っている。だが、それでは「今のネットワーク構成がどうなっているか」という真実がコード外に漏れ出す。
Terraformでトラフィック比率を管理する最大のメリットは、「今のデプロイ状態」をGit履歴として残せる点にある。障害発生時、`git revert`でトラフィックを即座に安全なバージョンへ戻せる――これこそが、SREが追求すべき「冪等性による生存戦略」だ。
—
2. 実装の要：Randomプロバイダによる「確率的制御」の罠を回避する
単純にランダム関数を使うだけでは、`terraform apply`のたびにルーティングが変わってしまう。ここで重要なのは、「変動を意図的に制御する」ことだ。
`random_integer`を使いつつ、デプロイ単位で固定されたシードを与えることで、計画的なカナリアリリースを実現する。
カナリアの段階（0-100）を管理する変数
variable “canary_weight” {
type = number
description = “カナリア環境へ流すトラフィックの割合 (0-100)”
default = 10
}
意図的に変動させるための擬似乱数
resource “random_integer” “canary_id” {
min = 1
max = 1000
# 破壊的変更が必要な際のみseedを変えるよう設計する
keepers = {
version = var.canary_weight
}
}
—
3. Route 53 加重ルーティングによる実装サンプル
ALBとRoute 53を組み合わせ、DNSレベルでトラフィックを制御するアーキテクチャだ。以下のコードは、安定版（Blue）と新版（Canary）への重み付けを行う設定である。
resource “aws_route53_record” “canary_weighted” {
zone_id = var.hosted_zone_id
name = “api.production.internal”
type = “A”
# カナリア用レコード
weighted_routing_policy {
weight = var.canary_weight
}
set_identifier = “canary-v2”
alias {
name = aws_lb.canary.dns_name
zone_id = aws_lb.canary.zone_id
evaluate_target_health = true
}
}
resource “aws_route53_record” “stable_weighted” {
zone_id = var.hosted_zone_id
name = “api.production.internal”
type = “A”
# 安定版は残りすべて（100 – canary_weight）
weighted_routing_policy {
weight = 100 – var.canary_weight
}
set_identifier = “stable-v1”
alias {
name = aws_lb.stable.dns_name
zone_id = aws_lb.stable.zone_id
evaluate_target_health = true
}
}
—
4. 現場で震える「フォールバック戦略」と自動化の極意
ここからがプロの領域だ。Terraform単体でトラフィックを制御しても、それが「正常か異常か」を判断できなければ意味がない。
究極の自動化：Terraform × Custom Provider/Script
Terraformの実行をトリガーにするのではなく、「CloudWatch Alarmのステータスを監視し、Terraformの変数ファイルを自動更新して再デプロイするコントローラー」を構築せよ。
1. 死活監視: ALBのターゲットグループの5xxエラー率をCloudWatchで監視。
2. 自動ロールバック: 異常検知時にLambdaを起動。LambdaはGitHub APIを叩き、`canary_weight`を`0`に書き換えたPRを自動作成＆マージする。
3. 継続的インフラ: マージによって動くGitHub Actionsが`terraform apply`を実行し、トラフィックを即座に引き戻す。
パフォーマンスを極めるための最適化ハック
- 状態の分割: Stateファイルが肥大化すると`plan`速度が低下する。`terragrunt`やTerraform Cloudのワークスペース機能を使い、ルーティング設定と基盤リソースを物理的に分離せよ。
- ALBのウォームアップ: 加重ルーティング切り替え時に接続が切れないよう、ALBの`deregistration_delay`をチューニングし、Connection Drainingの時間を適切に設計すること。
—
最後に：コードは「生き物」である
ブルーカナリアデプロイは、単なる技術的ギミックではない。それは、ユーザーへの影響を最小化しながら、システムを絶えず進化させるという「SREの意志」そのものだ。
Terraformでこの構成を構築する際、もっとも警戒すべきは「手動介入」だ。一度コード化したルーティングルールを、決してコンソールから直接いじってはならない。すべての変更をGitのタイムラインに乗せ、論理的な裏付けを持つ変更のみがシステムを通過できるようにする。
さあ、このコードを武器に、デプロイの恐怖からエンジニアを解放してくれ。それができるのは、ツールを骨の髄まで掌握した君だけなのだから。