ダウンタイムのゼロ導入

（セクション： アーキテクチャとプロトコル）

1）ゼロダウンタイムとは何であり、なぜそれが必要なのか

• 顧客と統合のダウンタイムをゼロにします。
• 予測可能なリリース、迅速なロールバック、および管理可能なリスク。
• 契約の境界内でのSLO/SLI（レイテンシー、エラー、可用性）の保存。

ZDTの鍵は、1つの「魔法」技術ではなく、配信パターン、データ互換性、有能なトラフィックルーティングの組み合わせです。

2）基本的なゼロダウンタイムの原則

1.バージョンの互換性：新しいバージョンと古いバージョンは、トラフィックとデータを同時に正しく処理する必要があります。
2.操作のidempotency：再処理は状態を壊すべきではありません。
3.優雅なシャットダウンおよび関係の排水。
4.ステップバイステップの健康チェック：準備/生活テスト、健康エンドポイント。
5.ファーストクラスの市民としてのロールバック：ロールバックはhotfixよりも簡単で高速です。
6.設計による可視性：リリースマーク、シングルダッシュボード、SLOアラート。
7.自動化：リリースとロールバックシナリオはコードであり、手動ではありません。

3）ダウンタイムのない配達パターン

3.1ローリングアップデート

古いバージョンのインスタンスの一部をトラフィックから徐々に削除し、新しいバージョンに更新してプールに戻します。

長所：インフラで経済的、ちょうどk8s/ASGで。
短所：しばらくの間、クラスタは2つのバージョンで同時に動作します（バージョンのスキュー）。

3.2ブルーグリーン

2つのフルプロッド：アクティブ（青）と候補（緑）。トラフィックスイッチング-アトミックフリップ。

長所：即刻のロールバック、きれいな分離。
短所：ステートフルでは困難なインフラストラクチャコスト。

3.3カナリア/プログレッシブロールアウト

私たちは、メトリクス別のゲートで新しいバージョンにトラフィックの小さなシェア（1-5-10-25-50-100％）を与えます。

長所：最小限のブラスト半径、データ駆動ソリューション。
短所：成熟した観測性とインテリジェントなルーティングが必要です。

3.4シャドウトラフィック/ダークローンチ

実際のリクエストを（ユーザーに応答せずに）新しいバージョンにミラーリングするか、メトリクスを収集するために隠して起動します。

長所：問題の早期識別。
短所：依存症の二重負荷、副作用を制御する必要があります。。

4）交通・接続管理

4.1 準備/Liveness

Livenessはオーケストレーターに「私を再起動する」ように指示します。
準備-"トラフィックを指示しないでください、私はまだ準備ができていません。
正しい準備ロジックとタイムアウトなしでリリースすることはできません。

4.2接続排水

• 新しい接続を受け入れるのをやめて、
• アクティブの完了を待って、
• 「hung」タイムアウトを中断します。

4.3スティッキーセッションとL7ルーティング

Stickyはステートフルなシナリオに役立ちますが、ロードバランスを複雑にします。
L7ルール（パス、ヘッダー、クッキー、APIバージョン）は、カナリア/リングに便利です。

4.4長寿命の接続

WebSocket/gRPCストリーミング：ドレインモード+「GOAWAY」信号をオンにしてから更新します。
ストリームとクライアントバックホーを上回るようにウィンドウを計画します。

5）データの互換性とデータベースの移行

5.1 Expand-Migrate-Contract

1.展開：古いバージョンを壊すことなく、新しい列/インデックス/テーブルを追加します。
2.マイグレート：バックグラウンドでデータを転送します。
3.契約：安定化後のみ古いものを削除します。

5.2プラクティス

リリースウィンドウで排他的なDDLロックを避けます。
バージョン管理API/イベントコントラクト（スキーマレジストリ、CDC）。
重い移行の場合-オンラインツール、レプリカ、フェーズドスイッチング。
重複排除とidempotent消費者との二重書き込みのみ。
キューを通じた信頼性の高い統合のためのOutbox/Inbox。

6）キャッシュ、セッション、バックグラウンドジョブ

セッションとキャッシュは外部（Redis/Memcached）であるため、バージョンは交換可能です。
プールする前にキャッシュ/ジット/テンポインデックスをウォームアップします。
バックグラウンドキューをバージョンごとに分割するか、リーダーシップを使用してレースを回避します。

7）観察可能性およびSLOのゲート

黄金信号：p95/p99レイテンシ、エラー率、RPS、飽和、キューラグ。
ビジネスSLA：認可、コンバージョン、支払いの成功、ファネル手順による拒否。
Gates：ロールアウトは、カナリア≤ベースライン+劣化しきい値、およびエラー予算が燃え尽きない場合にのみ促進されます。

8）安全な完了およびロールバック

ロールバックは同じパイプラインで、反対方向のみです。「手動クラフト」ではなく、固定コマンドです。
青緑のために-裏返して下さい；カナリア-0％または以前の安定したステップへの減量。
データ：トランザクションのオフセット、再処理、イベント重複排除。

9）ゼロダウンタイムチェックリスト

リリース前に

• 1つの署名付きアーティファクト（不変）、SBOMおよび依存性チェックが収集されます。
• 実行され、テストされる準備/liveness。
• 拡張モードでの移行計画、可逆性が確認されました。
• 新しいバージョンのダッシュボードとアラートが準備され、リリースマークがスローされます。
• ステージング/プリプロッドのロールバックをチェックしました。

発売時

• 接続排水が有効になっており、タイムアウトが適切です。
• トラフィックはカナリア/リングまたはフリップ（青緑）です。
• メトリックはベースラインと比較され、ゲートのしきい値が満たされます。

リリース後

• ポストモニタリングN時間、事件はありません。
• 契約移行が完了し、一時フラグ/ルートが削除されました。
• レトロスペクティブ、プレイブックの更新。

10）アンチパターン

排水と準備なしで再作成-デプロイ-リクエストブレイク。
準備が整っていないDDL→プライムタイムのロックとタイムアウト。
サービスバージョン間で互換性のないスキームを混在させます。
ハンドラと労働者の独自性の欠如。
ゲートのない「感じでロールアウト」とベースラインとの比較。
青緑の長いDNS-TTL、フリップが数時間続く理由です。
ローリング/カナリアを使用したインスタンスメモリ内のローカルセッション/キャッシュ。

11）実装シナリオ

11.1 Kubernetes（ローリング+カナリア）

展開-'maxUnavailable=0'、 'maxSurge=25％'。
準備はウォームアップ（キャッシュの初期化、マイナーな移行）を待っています。
サービスメッシュ/重み付けルーティングによる入力（1-5-10-25-50-100％）。
アラート：p95、 5xx、キューラグ、ビジネスファネル。

11.2雲の中の青緑色

バランサーの背後に2つのスタック：'青。例を示します。COM''グリーン。例を示します。com'。
グリーン、スモーク/リグレス、リスナー/ルートスワップ（またはTTLが低いDNSスイッチ）をウォームアップします。
問題の場合-インスタントフリップバック。

11.3ステートフルサービス

データレプリカ+オンライン移行;バリデーションとダブルリーディング。
バックグラウンドジャブは、バージョン「リーダーシップ」またはスプリットキューによって実行されます。
インスタンス外のセッション/キャッシュ；stickyは一時的にのみ有効です。

12） Ficheflagsおよびクライアントアプリケーション

新機能はフラグ（segments： employees→beta→all）によって有効化されます。
モバイル/デスクトップクライアントでは、プロトコル互換性の境界と従来の劣化ポリシー（サーバーサイドのフォールバック）を考慮してください。

13）性能および費用

ローリングは安価ですが、慎重な互換性が必要です。
Blue-Greenはリリース時にはより高価ですが、ロールバックは瞬時です。
カナリアはリスクとコストのバランスをとりますが、強い観測性が必要です。
一時的なプレビューと自動クリーニングスタンドを介して保存します。

14）最低の参照パイプラインZDT

1.ビルド：単一のアーティファクト、署名、SBOM。
2.テスト：単位/統合/contract+security。
3.ステージング：煙、負荷、移行の拡大、ロールバックチェック。
4.Prod： shadow→canary （gates）または青緑色のフリップ。
5.導入後：監視、契約クリーンアップ、レトロ。

15）簡単な要約

ゼロダウンタイムは、互換性のあるバージョン+正しいルーティング+マネージドマイグレーション+オブザビリティと高速ロールバックです。コンテキスト（ローリング、ブルーグリーン、カナリア）のパターンを選択し、SLOゲートを自動化し、データをアイドル状態に保ちます。リリースはイベントではなくなり、信頼できるルーチンプロセスに変わります。