release-it

Release It! フレームワーク

本番環境に対応したソフトウェアを設計、デプロイ、運用するためのフレームワークです。QA を通過したソフトウェアが、本番環境で生き残れるとは限りません。本番環境は過酷であり、システムはあらゆるレベルで障害を想定し、対処する必要があります。

中核となる原則

すべてのシステムは、いずれ設計上の限界を超える負荷にさらされます。 問題は障害が発生するかどうかではなく、システムが段階的に性能を低下させるのか、それとも壊滅的に停止するのかです。本番環境に対応したソフトウェアは、単に正しく動作するだけではありません。回復力があり、可観測性を備え、人の介入なしに部分的な障害が発生しても動作し続けます。

スコアリング

目標：8/8。 クイック診断で本番システムを採点します。8項目（タイムアウト、サーキットブレーカー、バルクヘッド、ダウンタイムなしのデプロイ、詳細なヘルスチェック、関連付けられたテレメトリー、ピークを超える負荷テスト、障害注入）の各行で「はい」と回答した場合、1ポイントです。評価基準：7～8 ＝すべての統合ポイントに上限が設定され、分離され、可観測性があり、デプロイとリリースが分離されている状態。4～5 ＝一部のパターンは導入済みですが、診断項目のうち3行以上に不備がある状態（例：上限のない再試行、プールの共有、簡易的なヘルスチェック）。≤2 ＝サーキットブレーカーもキャパシティモデルも障害テストもなく、問題が起きない前提に依存している状態。必ず現在のスコア、不合格の行、および各項目に対する具体的な修正策を示してください。

Release It! フレームワーク

ソフトウェアが本番環境に直面しても生き残れるかどうかを左右する6つの領域：

1. 安定性に関するアンチパターン

中核概念： 障害は統合ポイントを介して伝播し、システムの境界を越えて連鎖します。最も危険なパターンは、コード内のバグではありません。システムがストレス下で相互作用したときに生じる創発的な振る舞いです。

有効な理由： こうしたパターンは障害発生時に繰り返し見られます。名前を挙げて監査しましょう。すべての統合ポイントを確認し、現在どのアンチパターンを引き起こし得るかを問い、手当たり次第に強化するのではなく、その弱点を具体的に解消してください。

重要なポイント：

• 統合ポイントは最大の障害要因です。すべてのソケット、HTTP 呼び出し、キューにリスクがあります。
• 応答がないより、応答が遅いほうが深刻です。スレッドを占有し、プールを枯渇させ、呼び出しチェーンの上流へ遅延を伝播させます。
• 結果セットに上限がないと、無害なクエリでも、データ量がテスト時の想定を超えた際にメモリ不足によるクラッシュを引き起こします。
• ユーザーによる負荷は、どんなテストでも予測できません。ボット、再試行の集中、フラッシュクラウドなどがあります。自社のマーケティング施策でインフラに過負荷をかけると、自らサービス拒否攻撃を引き起こすことになります。
• ブロックされたスレッドは、気づかれにくい障害要因です。デッドロックや競合は、すべてが停止するまでエラーを示さないことがあります。

コードへの適用例：

コンテキスト	対策	例
HTTP 呼び出し	すべてのリモート呼び出しは失敗、停止、または不正なデータを返す可能性があると想定します	すべての外部呼び出しにタイムアウトとサーキットブレーカーを設定します
データベースクエリ	結果セットの件数に上限を設けます	LIMIT を追加し、すべての一覧エンドポイントでページネーションを使用します
スレッドプール	依存先ごとにプールを分離します	決済ゲートウェイ用と検索用のプールを分けます
マーケティング施策	キャパシティ計画に合わせてローンチを調整します	ブラックフライデーの前にスケールアップし、クーポンの引き換えをキューに入れます

障害発生時の切り分けや統合ポイントの強化には、references/anti-patterns.md を参照してください。各アンチパターンについて、障害のシナリオと、それを検知する症状が記載されています。

2. 安定性パターン

中核となる概念： それぞれのアンチパターンには、安定性パターンで対処します。サーキットブレーカーは障害の連鎖を止め、バルクヘッドは影響範囲を隔離し、タイムアウトは停止したリソースを解放します。これらを組み合わせることで、システムは負荷がかかっても破綻せず、しなやかに対応できます。

有効な理由： それぞれのパターンが、1つの障害による被害に上限を設けます。ブレーカーが作動すると、際限のない障害の連鎖が、局所的な即時拒否に変わります。バルクヘッドは、停止を1つのプール内に封じ込めます。ブレーカーの作動は想定内の出力として扱い、作動時ではなく、開いたままの状態が続く場合にページ通知を行います。

主な知見：

• サーキットブレーカー：3つの状態（closed、open、half-open）があり、しきい値回数の失敗後に作動し、定期的に復旧を試します
• タイムアウト：すべてのアウトバウンド呼び出しに、接続タイムアウトと読み取りタイムアウトの両方が必要であり、呼び出しチェーンの上流へ伝播させます
• 指数バックオフとジッターを組み合わせた再試行により、復旧時のサンダリングハードを防ぎます
• Fail Fast：失敗すると分かっているリクエストは、リソースを浪費する前に拒否します。ハンドシェイクを使うと、サーバーは作業が送信される前に拒否できます
• 定常状態：システムには不要物（ログ、セッション、一時ファイル）が蓄積します。自動クリーンアップを設計します
• Let It Crash：不明な状態のまま動作を続けるより、正常に再起動するほうが適切な場合が多くあります

コードでの適用例：

コンテキスト	パターン	例
サービス呼び出し	サーキットブレーカー	60秒間に5回失敗したらopenにし、30秒後にhalf-openにする
リソースの分離	バルクヘッド	重要な処理と重要でない処理に専用の接続プールを用意する
ネットワーク呼び出し	タイムアウトの伝播	接続1秒、読み取り5秒。期限を下流に伝播させる
再試行	バックオフ＋ジッター＋予算	基本100ms、再試行は最大3回、フリート全体の再試行予算は20%
データのクリーンアップ	定常状態	24時間を超えたセッションを削除し、500MBでログをローテーションする

ブレーカーの実装やしきい値の調整については、references/stability-patterns.mdを参照してください。状態遷移図、パラメーターの範囲、何を失敗とみなすかの表、パターンの組み合わせ方が記載されています。

3. キャパシティと可用性

中核となる概念： キャパシティは単一の数値ではありません。CPU、メモリ、ネットワーク、ディスクI/O、接続プール、スレッドからなる多次元関数です。キャパシティプランニングでは、どのリソースが最初にボトルネックになるのか、また、その負荷がどの程度なのかを把握します。

有効な理由： テストされていないシステムは、最悪のタイミングであるピーク負荷時に障害を起こします。理論上ではなく実際の限界を把握することで、現実的なSLAを設定し、ユーザーが限界に達する前にスケールできます。

主な知見：

• テストの分類：ロードテスト（想定トラフィック）、ストレステスト（限界を超える負荷）、ソークテスト（長時間の負荷。リークを検出）、スパイクテスト（突発的なバースト）
• ユニバーサル・スケーラビリティ・ロー：スループットが線形にスケールすることはありません。競合と一貫性維持のコストにより、収穫逓減が生じます
• プール枯渇は、アプリケーションから見るとデータベース障害と同じように見えます。デフォルト値ではなく、実測した同時実行数に基づいてプールサイズを決めます
• 「クラウドは無限にスケールする」は誤解です。自動スケーリングには遅延、コールドスタート、厳格な上限があります

コードでの適用例：

コンテキスト	パターン	例
ロードテスト	ピークまで段階的に増やし、その後2倍にして劣化を観察する	レイテンシがSLOを超えるまでRPSを増やす
接続プール	実測した同時実行数に基づいてサイズを決める	プールをP99のアクティブ接続数＋20%の余裕に設定する
ソークテスト	24～72時間、キャパシティの80%で実施する	メモリ、接続、ファイルハンドルのリークを検出する
キャパシティモデル	サービスごとのボトルネックを記録する	「サービスXは2000 RPSでメモリがボトルネック。インスタンスあたり4GB」

ロードテストの計画やプールサイズの設定については、references/capacity-planning.mdを参照してください。テスト手法、プールとスレッドの調整、ユニバーサル・スケーラビリティ・ローのモデリングが記載されています。

4. デプロイとリリース

中核となる考え方： デプロイ（サーバーへのコードの配置）とリリース（ユーザーへの公開）は、切り離すべき別々の操作です。リスクを抑えてデプロイし、自信を持ってリリースします。

効果がある理由： 障害のほとんどは変更によって発生します。切り離すことで、本番環境にデプロイして検証した後でトラフィックを振り向けられます。問題が起きた場合は、デプロイではなくリリースをロールバックします。

重要なポイント：

• ゼロダウンタイムのデプロイは必須です。ローリング、ブルーグリーン、カナリアのいずれかを使用します
• フィーチャーフラグを使うと、コードをダークローンチし、デプロイとは独立して有効化できます
• データベースのマイグレーションは後方互換性を保つ必要があります。デプロイ中は旧コードと新コードが同時に動作します（拡張・縮小方式）
• イミュータブルインフラストラクチャ：稼働中のサーバーにはパッチを適用せず、新しいイメージをビルドしてデプロイし、古いものを破棄します
• ロールバックはロールフォワードより速くなければなりません。ロールバックに30分かかるなら、デプロイを避けるようになります

コードへの適用例：

コンテキスト	パターン	例
デプロイ	ヘルスチェックゲート付きブルーグリーン	グリーンにデプロイし、スモークテストを実行してから、ルーターを切り替えます
段階的なロールアウト	自動ロールバック付きカナリア	トラフィックの5%をカナリアに振り向け、エラー率が1%を超えたら自動ロールバックします
フィーチャーのリリース	緊急オフスイッチ付きフラグ	フラグを設定してリリースし、10%に対して有効化して監視し、段階的に拡大します
スキーマ変更	拡張・縮小マイグレーション	列を追加し、両方に書き込み、バックフィルしてから古い列を削除します

リリースやスキーマ変更を計画する際は、references/deployment-strategies.mdを参照してください。ブルーグリーン／カナリア／ローリングの仕組み、拡張・縮小マイグレーションの手順、インフラストラクチャ・アズ・コードについて説明しています。

5. ヘルスチェックとオブザーバビリティ

中核となる考え方： 観測できないものは運用できません。ヘルスチェック、メトリクス、ログ、トレースは、本番環境におけるシステムの感覚器官です。後付けではなく、設計上の重要な要素として扱います。

効果がある理由： トレースされていない障害は、ユーザーから報告されるまで見えません。高カーディナリティの構造化イベント（事前集計されたカウンターだけではなく）を出力することで、新たな計装を追加する前でも、過去のインシデントについて新しい問いを立てられます。

重要なポイント：

• ヘルスチェックには、浅いチェック（プロセスが稼働中か）と深いチェック（依存先に到達可能か、リソースが利用可能か）の2種類があります
• 3つの柱：構造化ログ（何が起きたか）、メトリクス（どれだけ起きたか）、分散トレース（どこで、どのくらい時間がかかったか）
• サービスにはREDメソッド（レート、エラー、継続時間）、リソースにはUSEメソッド（使用率、飽和度、エラー）を使います
• SLI（ユーザー体験を測定）→SLO（目標）→SLA（契約）の順に定義します
• 原因（CPU）ではなく、ユーザーが体感する症状（エラー率、レイテンシー）に対してアラートを設定します。ダッシュボードを見れば、5秒以内に「システムは正常か？」がわかるようにします

コードへの適用例：

コンテキスト	パターン	例
ヘルスエンドポイント	ディープヘルスチェック	/healthでDB、キャッシュ、キュー、ディスクの状態を報告します
サービスメトリクス	RED計装	エンドポイントごとのレート、エラー率、p50/p95/p99レイテンシー
分散トレーシング	トレースコンテキストの伝播	ヘッダーにトレースIDを含め、サービス間のログを関連付けます
アラート	生のしきい値ではなくSLOのバーンレート	「エラーバジェットの消費が10倍」対「CPU > 80%」

サービスに計装を追加する際やSLOを設定する際は、references/observability.mdを参照してください。ヘルスチェックの設計、RED／USEメトリクスのセット、SLI→SLO→SLAの連鎖、バーンレートアラートについて説明しています。

6. 適応性とカオスエンジニアリング

安全上の注意： カオスエンジニアリングの実験は、設計時の計画作業です。以下のパターンは、AI エージェントが自律的に実行する操作ではなく、何をテストし、何を確認するかを説明しています。すべての障害注入は、適切な承認、ロールバック計画、影響範囲の制御を整えたうえで、専用ツール（Gremlin、Litmus、AWS FIS など）を使用し、権限を持つエンジニアが実施する必要があります。

基本概念： レジリエンスへの信頼は、現実的な障害条件下でテストすることで得られます。カオスエンジニアリングでは、制御された方法でシステムに実験を行い、予期しない事態にも耐えられるという信頼を築きます。

有効な理由： 実際に障害が起きるまでは、システムが障害にどう対処するかはわかりません。制御された障害注入によって、未知の未知を、実際の停止を引き起こす前に既知の既知へと変えられます。

主なポイント：

• まず定常状態を定義します。逸脱を検出するには、測定可能な基準値が必要です
• すべての実験に仮説を設定します。「X が失敗したとき、システムは Y になると考えます」
• 本番環境以外の環境で小規模に始めます（プロセスを 1 つ停止する、1 回の呼び出しに遅延を加えるなど）。承認を得ながら段階的に拡大します
• 影響範囲を最小限に抑えます。カナリア対象、機能フラグ、緊急停止機能を活用します。本番環境での実験には明示的な承認と即時のロールバックが必要です
• 定期的な実験を自動化します。GameDay 演習ではシステムとチームの両方をテストします
• 弱点の発見が罰せられるのではなく、称賛される文化を築きます

コードでの適用例：

コンテキスト	パターン	例
プロセス障害	カオスエンジニアリングツールを使った制御された終了	Gremlin／Litmus でポッドを 1 つ停止し、SLO 内で復旧することを確認
ネットワーク障害	カオスエンジニアリングツールを使った遅延／分断の注入	DB 呼び出しに +500ms の遅延を加え、サーキットブレーカーが作動することを確認
依存関係の障害	カオスエンジニアリングツールを使った下流サービスの停止のシミュレーション	payment API から 503 を返し、適切に縮退することを確認
GameDay	予定されたチーム演習	「午後 2 時にプライマリ DB が読み取り専用になる」—対応を訓練

障害実験または GameDay を設計する際は、references/chaos-engineering.md を参照してください。定常状態に関する仮説、影響範囲の制御、そして本番環境以外から取り組みを拡大する方法について説明しています。

よくある間違い

間違い	うまくいかない理由	対策
外部への呼び出しにタイムアウトがない	依存関係の 1 つが遅いだけでシステムが停止します	すべての外部呼び出しに接続タイムアウトと読み取りタイムアウトを設定します
上限のない再試行	再試行の集中が障害を増幅させます	指数バックオフ、ジッター、フリート全体の再試行予算を設けます
スレッド／接続プールの共有	1 つの依存関係の障害ですべてが枯渇します	バルクヘッドを導入し、依存関係ごとにプールを分離します
浅いヘルスチェックのみ	依存関係に障害があるインスタンスにもトラフィックが送られます	下流サービスへの接続を確認する詳細なヘルスチェックを実施します
正常系のテストのみ	最初の実障害が起きるまで問題なく動作します	主要リリースの前に負荷テスト、ソークテスト、カオステストを実施します
デプロイとリリースの連動	すべてのデプロイが一か八かの高リスクになります	機能フラグ、カナリア、ブルー／グリーンを活用します
原因に対するアラートで、症状に対するアラートがない	ユーザーが気づかないまま影響を受けている間に CPU アラートが発火します	エラー、レイテンシ、可用性など、ユーザー向け SLI に基づいてアラートを設定します
キャパシティモデルがない	負荷が 2 倍になるとシステムがダウンします	ボトルネックをモデル化し、予想ピークの 3 倍まで負荷テストを行います

クイック診断

本番システムを監査します。

質問	いいえの場合	対応
すべての外向き呼び出しにタイムアウトが設定されていますか？	呼び出しが停止し、スレッドがブロックされます	すべての箇所に接続タイムアウトと読み取りタイムアウトを追加します
重要な依存関係にサーキットブレーカーが設定されていますか？	1つの障害でシステム全体が停止します	しきい値を適切に調整したブレーカーを追加します
プールは依存関係ごとに分離されていますか？	障害がほかの依存関係にも波及します	専用プールを使ったバルクヘッドを実装します
ダウンタイムなしでデプロイできますか？	デプロイによって障害が発生します	ローリング、ブルーグリーン、またはカナリアデプロイを行います
ヘルスチェックで依存関係を検証していますか？	正常に動作していないインスタンスにトラフィックが送られます	DB、キャッシュ、キューをテストする詳細なヘルスチェックを実施します
ログ、メトリクス、トレースは相関付けられていますか？	デバッグのたびにログを手作業で検索することになります	ID を相関付けた分散トレーシングを導入します
想定ピークを超える負荷テストを実施しましたか？	実際の負荷下での障害モードが不明です	ピークの 2～3 倍の負荷でテストし、限界点を記録します
障害注入を実践していますか？	レジリエンスが理論上のものにとどまります	リスクの低い実験からカオスエンジニアリングを始めます

参考資料

手法の全容、実体験に基づく事例、実装の詳細については、以下をご覧ください。

• "Release It! Design and Deploy Production-Ready Software" (第 2 版) Michael T. Nygard 著

著者について

Michael T. Nygard はソフトウェアアーキテクトです。1 日に数百万件のトランザクションを処理する大規模な本番システムの構築と運用に 30 年以上携わっています。Release It!（2007 年刊、第 2 版は 2018 年刊）は、DevOps およびサイト信頼性エンジニアリングの運動を支える基礎的な書籍となり、コードを書いた後も、アーキテクトはシステムに対する責任を持ち続けなければならないと説いています。