レジリエンスとアーキテクチャとは

レジリエンスとアーキテクチャは、障害や過負荷が発生しても影響を限定し、サービスを継続または迅速に復旧できるシステムを設計する取り組みです。

障害の発生を完全に防ぐことを前提とせず、単一障害点の排除、障害の分離、正常なバックエンドへの振り分け、縮退運転、データ復元などを組み合わせて信頼性を確保します。

なお、このチェックリストは必ずしもすべて導入しなければならないわけではなく、むしろプロジェクトの性格に合わせて無理のない範囲で実践するものであることに留意ください。

背景

冗長化されたシステムでも、依存関係や制御の設計によっては、一部の障害がシステム全体へ連鎖する場合があります。失敗した処理を無制限に再試行すると、その再試行自体が負荷を増幅し、障害を長引かせます。また、過負荷時にすべての要求を処理しようとすることで、正常な機能まで利用できなくなることがあります。

そのため、障害ドメインとサービスの限界を把握し、負荷を分散して障害を局所化する必要があります。利用者単位のクォータやレート制限でサービス容量を守り、需要の増減に合わせて処理能力を水平に増減させることも必要です。複数の実行系で同じ状態を扱う場合は、分散合意によって単一のリーダーを選び、ネットワーク分断時に複数のリーダーが並び立つ状態を防ぎます。

データの耐久性や復元可能性を実際のテストで確かめ、複雑さそのものが障害要因にならないよう設計を保つことも重要です。

SREアセスメントでは、レジリエンスとアーキテクチャに関する以下の事項を確認します。

チェックリスト

チェック項目
障害ドメインを特定し、重要なコンポーネントを複数のマシン・ゾーン・リージョンへ冗長配置して、単一障害点を排除できているか
利用者単位のクォータやレート制限でサービス容量を保護し、需要の増減に応じて処理能力を自動的に水平スケールできるか
ヘルスチェックにもとづいて正常なバックエンドへトラフィックを分散し、停止時には新規トラフィックを外しながら処理中の接続やリクエストを安全に完了できるか
過負荷時に重要な処理を優先し、負荷の切り捨てや機能・性能の段階的な縮退によってサービス全体の停止を避けられるか
再試行に指数バックオフ・ジッター・回数または時間の上限を設け、再試行を含む処理全体のタイムアウトを制御して障害や負荷の増幅を防げるか
（参考）重要な状態管理にクォーラムベースの分散合意を用い、単一のリーダーを選出してネットワーク分断時のスプリットブレインを防げるか
RPO・RTOに沿ってバックアップと復旧方式を設計し、バックアップの整合性確認と定期的な復元テストによってデータを実際に復旧できることを検証しているか
過度な複雑性を避け、シンプルな設計とマネージドサービスの活用によって運用上のリスクと負担を抑え、変更しやすい構成を維持しているか

対応によって得られる効果

レジリエンスを設計することで、一部の故障や急激な負荷増加がサービス全体の停止へ発展する可能性を抑えられます。障害時にも重要な機能を維持し、復旧までのユーザー影響を限定できます。

また、復元手順の実証とシンプルな構成の維持により、想定外の状況でも判断しやすくなり、データ損失や長時間停止のリスクを低減できます。