# MTTR の削減
障害が発見された後、残りの MTTR 時間では実際の修理または影響の軽減を実施します。障害を修復または軽減するには、何が問題なのかを知る必要があります。このフェーズの重要なメトリクスには、1/ *影響評価*メトリクスと 2/ *運用健全性*メトリクスの 2 つの主要なグループがあります。最初のグループは、障害発生時の影響の範囲を示し、影響を受けたカスタマー、リソース、またはワークロードの数または割合を測定します。2 番目のグループは、影響がある*理由*を特定するのに役立ちます。理由が明らかになると、オペレーターとオートメーションは障害に対応し、解決できます。これらのメトリクスの詳細については、「[付録 1 — MTTD と MTTR の重要なメトリクス](appendix-1-mttd-and-mttr-critical-metrics.md)」を参照してください。
**ルール 9**
MTTD と MTTR を減らすには、可観測性と計測が不可欠です。
## 障害回避ルート
影響を軽減する最速のアプローチは、障害を回避するフェイルファストサブシステムを使用することです。このアプローチでは、冗長性を利用して、障害が発生したサブシステムの処理をスペアにすばやく移行することで MTTR を削減します。冗長性は、ソフトウェアプロセスから EC2 インスタンス、複数の AZ、複数のリージョンまで多岐にわたります。
スペアのサブシステムでは、MTTR をほぼゼロまで下げることができます。復旧時間は、スタンバイのスペアに処理を再ルーティングするのにかかる時間だけです。多くの場合、これは最小限のレイテンシーで行われ、定義された SLA の範囲内で作業を完了でき、システムの可用性を維持できます。これによっ発生するMTTR は、わずか、または気づかない程度の遅延であり、長期間利用できなくなるということはありません。
例えば、サービスが Application Load Balancer (ALB) の背後にある EC2 インスタンスを利用している場合、ヘルスチェックを 5 秒程度の短い間隔で設定し、ターゲットが異常とマークされるまでに必要なヘルスチェックの失敗は 2 回のみです。つまり、10 秒以内に障害を検出し、問題のあるホストへのトラフィックの送信を停止できます。この場合、障害が検出されるとすぐに軽減が行われるため、MTTR は MTTD と実質的に同じになります。
これこそが、*高可用性*または*連続可用性*のワークロードが達成しようとしていることです。障害が発生したサブシステムをすばやく検出して障害としてマークし、そのサブシステムへのトラフィックの送信を停止して、代わりに冗長サブシステムにトラフィックを送信することで、ワークロードの障害を迅速に回避することが理想です。
ただし、この種のフェイルファストメカニズムを使用すると、ワークロードが一時的なエラーに対して非常に敏感になるため注意が必要です。この例では、ロードバランサーのヘルスチェックが、依存関係またはワークフローのテスト (*ディープ*ヘルスチェックと呼ばれることが多い) ではなく、インスタンスのみの*シャロー*または[https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/)ヘルスチェックを実行していることを確認します。これにより、ワークロードに影響する一時的なエラーが発生したときに、インスタンスの不要な置き換えを防ぐことができます。
障害を回避するルーティングを成功させるには、可観測性とサブシステムの障害を検出する能力が不可欠です。また、影響の範囲を把握することで、影響を受けるリソースに異常または障害のマークを付けてサービスを停止し、回避できるようになります。例えば、1 つの AZ で部分的なサービス障害が発生した場合、計測により AZ にローカライズされた問題があることを特定し、復旧するまでその AZ のすべてのリソースを回避できる必要があります。
障害を回避するため、環境によっては追加のツールが必要になる場合もあります。前の ALB の背後にある EC2 インスタンスの例で、ある AZ のインスタンスがローカルヘルスチェックに合格しているのに、特定された AZ の障害が原因で別の AZ のデータベースに接続できなくなっているとします。この場合、負荷分散ヘルスチェックによってそれらのインスタンスがサービス停止になることはありません。[ロードバランサーから AZ を削除したり](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html)、インスタンスのヘルスチェックを強制的に不合格するには、別の自動化メカニズムが必要になります。これは、影響の範囲が AZ であるかどうかを特定することに依存します。ロードバランサーを使用していないワークロードでは、特定の AZ のリソースが作業単位を受け付けたり、AZ から容量を完全に削除するのを防ぐために、同様の方法が必要になります。
場合によっては、冗長なサブシステムへの作業の移行を自動化できないこともあります。例えば、テクノロジーが独自のリーダーの選択を行わない場合のプライマリデータベースからセカンダリデータベースへのフェイルオーバーなどです。これは、[AWSマルチリージョンアーキテクチャ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)では一般的なシナリオです。この種のフェイルオーバーでは、完了するまでにある程度のダウンタイムが必要で、すぐに元に戻すことができず、一定期間ワークロードは冗長にならないままです。そのため、意思決定プロセスに人が存在することが重要です。
厳密性の低い整合性モデルを採用できるワークロードでは、マルチリージョンのフェイルオーバーオートメーションを使用して障害を回避することで、MTTR を短縮できます。[Amazon S3 クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)または [Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/)などの機能は、結果的に整合性のあるレプリケーションを通じてマルチリージョン機能を提供します。さらに、CAP 定理を考えるときには、緩和された整合性モデルを使用することが有益です。ステートフルサブシステムへの接続に影響するネットワーク障害が発生しても、ワークロードが整合性よりも可用性を優先した場合でも、障害を回避するルーティングの別の方法として、エラー以外のレスポンスを提供できます。
障害を回避するルーティングは、2 つの異なる方法で実装できます。最初の戦略は、障害が発生したサブシステムのすべての負荷を処理するのに十分なリソースを事前にプロビジョニングして、静的安定性を実装することです。これは、単一の EC2 インスタンスでも、AZ 全体の容量でもかまいません。障害発生時に新しいリソースをプロビジョニングしようとすると、MTTR が増加し、復旧パスのコントロールプレーンに依存関係が追加されます。ただし、追加料金が発生します。
2 つ目の戦略は、障害が発生したサブシステムから他のサブシステムへトラフィックの一部をルーティングし、残りの容量では処理できない[余分なトラフィックを負荷分散](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)することです。このパフォーマンスが低下している間、障害が発生した容量を補うために新しいリソースをスケールアップできます。この方法では MTTR が長くなり、コントロールプレーンへの依存が発生しますが、スタンバイ容量および予備容量のコストは低下します。
## 既知の正常な状態に戻す
修復中に軽減するためのもう 1 つの一般的な方法は、ワークロードを以前の既知の正常な状態に回復させることです。最近の変更が原因で障害が発生した可能性がある場合は、その変更をロールバックすることが前の状態に戻す方法の 1 つです。
また、一時的な状態が原因で障害が発生した場合は、ワークロードを再起動することで影響が軽減される可能性があります。これらの 2 つのシナリオをについて検証してみましょう。
デプロイ時に MTTD と MTTR を最小限に抑えるには、可観測性と自動化が必要です。デプロイプロセスでは、エラー率の増加、レイテンシーの増加、または異常が発生していないか、ワークロードを継続的にモニタリングする必要があります。これらが認識されると、デプロイプロセスが停止されます。
インプレースデプロイ、ブルー/グリーンデプロイ、ローリングデプロイなど、さまざまな[デプロイ戦略](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)があります。これらはそれぞれ、既知の正常な状態に戻るために異なるメカニズムを使用する場合があります。自動的に前の状態にロールバックしたり、トラフィックをブルー環境に戻したり、手動で操作することができます。
CloudFormation には、[AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks) と同様に、スタックの作成および更新オペレーションの一部として[自動的にロールバックする機能](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html)があります。CodeDeploy は、ブルー/グリーンデプロイとローリングデプロイもサポートしています。
これらの機能を活用して MTTR を最小限に抑えるには、すべてのインフラストラクチャとコードのデプロイをこれらのサービスを使って自動化することを検討してください。これらのサービスを使用できないシナリオでは、AWS Step Functions での [saga パターンの実装](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html)により、失敗したデプロイをロールバックすることを検討してください。
*再起動*を検討する場合、いくつかの異なるアプローチがあります。これらは、作業時間が最長であるサーバーの再起動から、最短のスレッドの再起動まで多岐にわたります。次の表は、一部の再起動方法とおおよその完了までの時間をまとめたものです (桁違いを表記するためであり、これらは正確ではありません)。
| 障害復旧メカニズム | 推定 MTTR |
| --- | --- |
| 新しい仮想サーバーの起動と設定 | 15 分 |
| ソフトウェアの再デプロイ | 10 分 |
| サーバーの再起動 | 5 分 |
| コンテナの再起動または起動 | 2 秒 |
| 新しいサーバーレス関数の呼び出し | 100 ミリ秒 |
| プロセスの再起動 | 10 ミリ秒 |
| スレッドの再起動 | 10 μs |
表を見直してみると、コンテナやサーバーレス関数 ([AWS Lambda](https://aws.amazon.com/lambda/) など) を使うことは、MTTR にとって明確な利点がいくつか存在します。これらの MTTR は、仮想マシンを再起動したり、新しいマシンを起動するよりも桁違いに速いです。ただし、ソフトウェアのモジュール化による障害の分離も有益です。障害を単一のプロセスまたはスレッドに抑えることができると、その障害からの復旧は、コンテナまたはサーバーを再起動するよりもはるかに高速です。
復旧の一般的なアプローチとしては、下から上へ、つまり 1/再起動、2/リブート、3/再イメージ化/再デプロイ、4/置換という順序で進めることができます。ただし、再起動の手順に入ると、障害を回避するルーティングの方が通常は迅速です (通常、最長で 3 ～ 4 分かかります)。そのため、再起動を試みた後で影響を最も早く軽減するには、障害を回避するルーティングをし、バックグラウンドで復旧プロセスを続行して容量をワークロードに戻します。
**ルール 10**
問題解決ではなく、影響の軽減に焦点を当てる。最速の方法で通常のオペレーションに戻す。
## 障害の診断
検出後の復旧プロセスの一部には、診断期間があります。これは、オペレーターが問題が何かについて判断を試みる期間です。このプロセスには、ログのクエリ実行、運用健全性メトリクスの確認、トラブルシューティングのためのホストへのログインが含まれる場合があります。これらのアクションはすべて時間がかかるため、迅速化するためのツールやランブックを作成すると、MTTR の短縮にも役立ちます。
## ランブックと自動化
同様に、問題が何か、そしてどのような一連の作業によりワークロードを修復できるかについて判断したら、オペレーターは通常、そのために一連のステップを実行する必要があります。例えば、障害発生後、ワークロードを修復する最速の方法は、再起動かもしれません。これには、順序付けられた複数のステップが必要になることがあります。これらのステップを自動化したり、またはオペレーターに特定の指示を与えるランブックを利用すると、プロセスが迅速になり、不注意による作業ミスのリスクが軽減されます。