ソフトウェアのリリースは、かつてはメンテナンスの時間枠と面倒な作業を意味していました。現代のチームはリリースを日常化する戦略を採用しており、ブルーグリーン デプロイメントとカナリア デプロイメントの選択は、最初に直面する選択肢の 1 つです。どちらもリスクを軽減しますが、その方法は逆です。1 つは完全な代替品を準備し、もう 1 つは実際のユーザーを使って一度に少しずつテストします。

このガイドでは、それぞれの仕組みと実際のコストについて説明します。 Python 3.13 で小規模なユーザー ルーティングとロールバックの例を実行し、その実行から出力が得られます。 Kubernetes サンプルは例示的なものであり、私たちはそれらを実行しませんでした。パーセンテージとしきい値は、適応するための開始例として扱います。

短い答え

blue-green デプロイメントでは、2 つの同一の実稼働環境を実行します。 1 つはユーザーにサービスを提供し、もう 1 つは新しいバージョンをデプロイしてテストし、その後、すべてのトラフィックを一度に切り替えます。

カナリア デプロイメントでは、新しいバージョンが古いバージョンの隣で実行されます。実際のトラフィックの小さな割合を送信し、結果を比較し、全員にサービスが提供されるまで段階的にシェアを増やします。この名前は、かつて危険を早期に警告するために鉱山労働者が使用していたカナリアに由来しています。

ブルーグリーンとカナリアを並べて

Blue-Green 導入の仕組み

1. Blue はライブであり、すべてのトラフィックを処理します。
2. 新しいバージョンをユーザー トラフィックを受信しない green にデプロイします。
3. スモーク テストと内部ユーザーを使用して、実際の運用環境でグリーンを徹底的にテストします。
4. トラフィックをグリーンに送信するようにルーター、ロードバランサー、または DNS を切り替えます。
5. 青はまだ実行中で準備ができているので、注意深く見てください。
6. 何か問題がある場合は、元に戻してください。すべてが順調であれば、青が次のアイドル環境になります。

Kubernetes では、Service のセレクターを変更することで切り替えを実行できるため、トラフィックは別のラベルが付けられた Pod に移動します。

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

長所: 概念的にシンプルで、ユーザーが見る前に正確な実稼働セットアップをテストでき、ロールバックはほぼ瞬時に行われます。 弱点: インフラストラクチャの重複は高価になる可能性があり、テストをすり抜けたバグは一度に全員に到達し、切り替え中に開いているセッションと実行中の作業に注意が必要になります。スイッチに DNS を使用している場合、キャッシュされたレコードによって遅延が発生する可能性があります。この概念は初めてですか? 初心者向けの Kubernetes チュートリアルをご覧ください。

カナリア デプロイメントの仕組み

1. 新しいバージョンを安定バージョンと並行してデプロイします。
2. トラフィックのわずかな割合 (たとえば 5%) をカナリアにルーティングします。
3. エラー率、レイテンシー、ビジネス指標を安定版と比較します。
4. 健康な場合は、25%、50%、100% と増加します。
5. 何かが低下した場合は、すべてのトラフィックを安定したバージョンに送り返します。

多くのチームは、内部スタッフでカナリアを開始し、次に低リスク地域で、その後、より広範囲の一般向けにカナリアを開始します。

長所: 悪いリリースは少数のグループにのみ影響し、実際のトラフィックからは、テスト環境では完全に再現できないことがわかります。 弱点: パーセンテージベースのルーティングとバージョンごとのメトリクスが必要で、ロールアウトに時間がかかり、2 つのバージョンがしばらくの間一緒に実行されます。小さなカナリアは、特に交通量の少ない時間帯には、静かすぎて意味のある信号を発することができない場合もあります。

安定したユーザールーティング

リクエストごとにバージョンをランダムに選択すると、古いバージョンと新しいバージョンの間を行き来する可能性があり、ユーザーに混乱を招くエクスペリエンスを与えます。一般的な解決策は、安定したユーザー ID をバケットにハッシュして、各ユーザーが常に同じ答えを得るようにすることです。

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

実際のシェアは目標をほぼ達成しました。このメソッドにはさらに 2 つの有用なプロパティがあり、実行では両方が確認されました。同じユーザーは常に同じバージョンを受け取りました。そして、5% グループの全員は依然として 25% に含まれていたため、すでに新しいバージョンを持っていた人は展開が大きくなるにつれて戻されませんでした。

実際のシステムでは、通常、サービス メッシュ、ロード バランサー、または Argo Rollouts や Flagger などのツールがこのルーティングを処理するため、自分でルーティングを記述する必要はありません。彼らが何をしているのかを理解することは依然として役立ちます。

意思決定の自動化

Canary は、誰かが実際にバージョンを比較している場合にのみ機能します。自動チェックは、人間がグラフを監視するよりも信頼性が高くなります。以下は、カナリアのエラー率と安定版のエラー率を比較する核心的なアイデアです。

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

最初のケースに注目してください。エラー率は高いように見えますが、リクエストが 100 件しかないため、まだ十分な証拠とは言えません。実際のツールはより慎重な統計を適用し、いくつかの信号を一緒に調べます。

データベースの問題

アプリケーションコードは数秒で交換できますが、データは交換できません。通常、どちらの戦略も 1 つのデータベースを共有するため、ロールアウト中およびロールバック後は、古いバージョンと新しいバージョンの両方が同じスキーマで動作する必要があります。

標準的な答えは、拡張と縮小パターンです。 name の名前を full_name に変更するとします。

1. 展開: 新しい列を追加します。古いコードは影響を受けません。
2. 移行: 両方の列に書き込み、古い行をバックフィルするコードをリリースします。
3. スイッチ: 新しい列から読み取るコードをリリースします。
4. 契約: 古い列が何も使用されなくなったら、後のリリースでは削除します。

これには数回のリリースが必要ですが、すべてのステップを安全にロールバックできます。 RENAME COLUMN を一度に実行すると、他の名前を予期していたバージョンが壊れてしまいます。長時間実行されるスキーマの変更にも、ロックが保持される可能性があるため注意してください。詳細については、SQL トランザクション を参照してください。

ローリングおよびその他の戦略

Kubernetes デプロイメントは、デフォルトでローリング アップデートを実行します。これは多くのサービスに適しています。ローリング アップデートも徐々に変化しますが、そのシェアはインスタンスの数に関連付けられており、それ自体で結果を分析したり、悪いメトリクスで一時停止したりすることはありません。

機能フラグについてはどうですか?

デプロイメントによってサーバーにコードが配置され、リリースによって機能がユーザーに利用可能になります。機能フラグを使用すると、何もデプロイせずに選択したユーザーに対して機能を有効にすることができ、これらを分離できます。これらは両方の戦略で非常にうまく機能します。フラグをオフにしてデプロイし、徐々に有効にします。フラグは、起動時にクラッシュするリリースからユーザーを保護できないため、これらの戦略に代わるものではありません。古いフラグは技術的負債として蓄積されるため、必ず削除してください。

選び方

組み合わせることもできます。一部のチームは、グリーン環境を展開し、そこにトラフィックを徐々に移行させ、クリーンな環境と制限された爆発半径を獲得します。 GitHub アクション ガイドで説明されているように、何を選択しても、CI/CD パイプラインを通じて自動化してください。

よくある間違い

• 重大なスキーマ変更を行う。 古いコードがデータを読み取れない場合、ロールバックは役に立ちません。
• ロールバック基準がない。 インシデント中ではなく、リリースが開始される前に「悪い」の意味を決定します。
• 環境を漂わせる。 緑が青と異なる場合、テストの証明は不十分になります。 コードとしてのインフラストラクチャを使用して両方を定義します。
• 技術的な指標のみを測定します。 リリースにエラーがなくても、チェックアウトが中断される可能性があります。
• ロールバックを練習しないでください。プレッシャーにさらされたときに機能するように、リハーサルをしてください。
• バックグラウンド ジョブを忘れます。 ワーカーとスケジュールされたタスクも、切り替え中に計画が必要です。

まとめ

青緑色は、きれいで素早い切り替えを可能にします。 Canary は、少量の測定された露出を提供します。監視がまだ基本的な場合は、カナリアを試す前に、ローリング アップデートまたは Blue-Green から始めて、バージョンごとのメトリクスに投資してください。次に、データベースを含む次のリリースでのロールバックをリハーサルします。この 1 回の演習で、本当に修正が必要なものが明らかになる傾向があります。

よくある質問

学び続ける