障害モードのオブザーバビリティ
障害モードを軽減するには、まず、ワークロードに現在影響している、または今後影響する障害を検出する必要があります。軽減策は、アクションを実行する必要があるというシグナルがある場合にのみ有効となります。つまり、軽減策の作成には、少なくとも、障害の影響を検出するために必要なオブザーバビリティがある、または構築されていることを確認することが含まれます。
次の 2 つの側面で、障害モードの観測可能な症状について考慮する必要があります。
-
システムで影響が目に見える状態に近づいていることを通知する、先行指標とは何か?
-
障害モードが発生した後、できるだけ早くその影響を表示できる遅行指標とは何か?
例えば、データベース要素に適用される過剰な負荷障害では、先行指標として接続数が考えられます。接続数の着実な増加は、データベースが接続制限を間もなく超える可能性があることを示す先行指標として確認できます。そのため、最近の使用頻度が最も低い接続を終了するなどの措置を実行して、接続数を減らすことができます。遅行指標は、データベース接続制限を超え、データベース接続エラーへと引き上げられたときを示します。アプリケーションとインフラストラクチャのメトリクスを収集することに加えて、障害がカスタマーエクスペリエンスに与える影響を検出するために、主要業績評価指標 (KPI) を収集することを検討してください。
可能であれば、オブザーバビリティ戦略に両指標を含めることをお勧めします。場合によっては先行指標を作成できないことがありますが、遅行指標については軽減する障害ごとに常に計画する必要があります。適切な軽減策を選択するには、先行指標または遅行指標で障害を検出したかどうかも考慮する必要があります。例えば、ウェブサイトへのトラフィックが急増したとします。遅行指標のみが表示される可能性があります。この場合、新しいリソースのデプロイには時間がかかるため、自動スケーリングのみでは最適な軽減策とは言えませんが、スロットリングによってほぼ即時に過負荷を防ぎ、アプリケーションの負荷をスケールまたは軽減する時間ができます。逆に、トラフィックが徐々に増加する場合は、先行指標が表示されます。この場合、システムを自動的にスケールして応答するまでに時間があるため、スロットリングは適切ではありません。