ブルーグリーンデプロイメントとDNS切り替え

ブルーグリーンデプロイメントでは、本番環境を2つ丸ごと稼働させておきます。1つは現在稼働中の環境（「ブルー」）、もう1つは待機中ですが、完全にデプロイ済みで準備の整った環境（「グリーン」）です。ローリングアップデートではなく、1回の素早い切り替えで、トラフィックを両者の間で移します。この切り替えを実現する一般的な方法の1つが、特に別々のインフラやプロバイダーをまたぐ場合に使われる、DNSの変更です。グリーン環境が正常であることを確認したうえで、ドメインのレコードをグリーン環境のアドレスに向けて更新します。

単純な方法がうまくいかなくなる場面

DNSによる切り替えは、ロードバランサーのターゲットグループを切り替える場合のように、瞬時には完了しません。古い（ブルーの）応答をキャッシュしているリゾルバーは、そのレコードのTTLが切れるまで、その応答を返し続けます。つまり、TTLに比例する一定の時間は、トラフィックの一部が、切り離そうとした環境にまだ到達し続けます。TTLが1時間なら、切り替えがすべての場所で完全に終わるまでに、最大で1時間ほど、両方の環境にトラフィックが分かれる可能性があります。

• 予定している切り替えよりかなり前にTTLを下げておきます。理想的には、古いTTLの1周期分以上前に行います。そうすれば、切り替えの時点では、すべてのリゾルバーが新しい短いTTLで再キャッシュ済みになっています。
• 切り替えのあとも、少なくともTTLの期間は、古い（ブルーの）環境を完全に稼働させて正常な状態に保ち、すぐには廃止しないでください。その期間中も、実際のトラフィックを受け続けています。
• 切り替えの確認は、アプリケーションのログを見るだけでなく、DNSに直接問い合わせて行います。トラフィックがどこまで追従したかに関係なく、レコード自体が変わったことを確認できます。
• 切り替えが完了して安定したと確信できてから、TTLを通常の値に戻します。

段階的な代替手段：重み付きDNS

すべてのリゾルバーを一度に切り替えて、グリーン環境が本番の全負荷にすぐ耐えられることを期待する代わりに、重み付き（割合ベース）のルーティングポリシーに対応したDNSプロバイダーもいくつかあります。応答の95%をブルー、5%をグリーンに向け、新しい環境への信頼が高まるにつれて、80/20、50/50、とその比率を少しずつ移していきます。

シンプルで明快な切り替えと引き換えに、問題がトラフィックのごく一部にしか影響していない段階で気づけるようになります。グリーンの準備が整っていないと分かれば、数秒で100%ブルーに戻せます。切り替えを完全に済ませたあとに、プレッシャーの中で元に戻す必要はありません。

どちらの方法でも同じように検証する

どの戦略を使う場合でも、検証の手順は同じです。複数の観測地点から繰り返しドメインを解決し、実際に観測された分配が設定どおりであることを確認します。トラフィックの10%をグリーンに送るはずの重み付きポリシーが、実際には40%を送っていることがあります。重みの設定ミスや、一部のリゾルバーがキャッシュして、想定ほど頻繁に分配を引き直さないことが原因です。こうしたずれは、DNSプロバイダーのダッシュボードが現実を完璧に反映していると信頼するのではなく、実際に解決された応答を確認して初めて見つかります。