信頼性の設計原則

[アーティクル]
11/15/2023

停止と誤動作は、すべてのワークロードにとって重大な懸念事項です。信頼性の高いワークロードは、これらのイベントを存続させ 、意図した機能を常に提供し続ける必要があります。許容できる期間内に障害を検出し、耐え、復旧できるように、 回復性 が必要です。また、ユーザーが約束された品質レベルで約束された期間中にワークロードにアクセスできるように 、使用できる 必要があります。

特にワークロードが分散システムで実行されるように構築されている場合、障害が発生しないと想定することは現実的ではありません。一部のコンポーネントは失敗し、他のコンポーネントは動作し続ける可能性があります。ある時点で、ユーザーエクスペリエンスが影響を受け、ビジネス目標が損なわれる可能性があります。

ワークロードアーキテクチャには、 アプリケーションコード、インフラストラクチャ、および運用で信頼性の保証が必要です。デザインの選択によって、ビジネス要件で指定された意図は変更されません。このような変更は、重要なトレードオフと見なす必要があります。

設計原則は、開発ライフサイクル全体で考慮する必要がある信頼性の側面に関するガイダンスを提供することを目的としています。推奨されるアプローチから始め、 一連の要件の利点を正当化します。戦略を設定したら、 信頼性チェックリストを使用してアクションを推進します。

これらの原則を設計に適用しない場合、ワークロードは 運用環境の問題を予測または処理する準備ができていない可能性が最も高くなります。その結果、財政的損失につながるサービスの中断が発生する可能性があります。重大なワークロードの場合、これらの原則を適用しないと安全性が危険にさらされる可能性があります。

ビジネス要件の設計

ワークロードの意図されたユーティリティに焦点を当てて、ビジネス要件を収集します。

要件は、ワークロードに固有のユーザーエクスペリエンス、データ、ワークフロー、および特性をカバーする必要があります。 要件プロセスの結果は、期待を明確に示す必要があります。目標は達成可能であり、特定の投資を与えられたチームと交渉する必要があります。技術的な選択、実装、運用を推進するために文書化する必要があります。

アプローチ	特長
個々のコンポーネント、システムフロー、およびシステム全体のインジケーターにターゲットを設定して、成功を定量化します。これらのターゲットを使用すると、ユーザーフローの信頼性が高くなりますか?	メトリックは期待値を定量化します。複雑さを理解し、それらの複雑さのダウンストリームコストが投資制限内にあるかどうかを判断できます。ターゲット値は、理想的な状態を示します。この値をテストしきい値として使用すると、その状態からの逸脱と、ターゲット状態に戻るまでの時間を検出するのに役立ちます。コンプライアンス要件には、スコープ内フローの予測可能な結果も必要です。これらのフローの優先順位付けは、最も機密性の高い領域に注意を向けます。
プラットフォームのコミットメントを理解する。サービスの制限、クォータ、リージョン、容量の制約を考慮してください。	サービスレベルアグリーメント (SLA) はサービスによって異なります。すべてのサービスと機能が均等にカバーされるわけではありません。すべてのリージョンですべてのサービスまたは機能を利用できるわけではありません。サブスクリプションリソースの制限のほとんどはリージョンごとに行われます。カバレッジと制限を十分に理解することで、ドリフトを検出し、回復性と回復メカニズムを構築するのに役立ちます。
依存関係とその回復性への影響を判断します。	他のチームまたはサードパーティによって開発された依存インフラストラクチャ、サービス、API、および機能を追跡すると、それらの依存関係がない場合にワークロードが動作できるかどうかを判断するのに役立ちます。また、カスケードエラーを理解し、ダウンストリーム操作を改善するのにも役立ちます。開発者は、障害の影響を受けやすい可能性のある外部サービスを使用する場合に、潜在的な障害を処理する回復性のある設計パターンを実装できます。

回復性の設計

ワークロードは、引き続き完全または縮小された機能で動作する必要があります。

コンポーネントの誤動作、プラットフォームの停止、パフォーマンスの低下、リソースの可用性の制限、その他の障害が発生することを想定する必要があります。フォールト トレラントであり、正常に低下する可能性があるシステムで回復性を構築します。

アプローチ	特長
クリティカルパス上にあるコンポーネントと、低下状態で機能できるコンポーネントを区別します。	ワークロードのすべてのコンポーネントが同等に信頼性を持つ必要があるわけではありません。重要度を判断すると、各コンポーネントの重要度に従って設計するのに役立ちます。失敗した場合にエンドツーエンドの問題を引き起こす可能性があるコンポーネントとは対照的に、ユーザーエクスペリエンスをわずかに悪化させる可能性があるコンポーネントの回復性を過剰に設計することはありません。この設計は、重要なコンポーネントにリソースを割り当てるのに効率的です。また、障害分離戦略を実装して、重要でないコンポーネントが失敗した場合、または機能低下状態になった場合に、連鎖障害を防ぐために分離することもできます。
システム内の潜在的な障害ポイント (特に重要なコンポーネント) を特定し、ユーザーフローへの影響を判断します。	障害のケース、爆発半径、障害の強度 (完全または部分的な停止) を分析できます。この分析は、コンポーネントレベルでのエラー処理機能の設計に影響します。
設計パターンを正しく使用し、設計をモジュール化して障害を分離することで、自己保持機能を構築します。	システムは、問題がダウンストリームコンポーネントに影響を与えるのを防ぐことができます。システムは、一時的および永続的な障害、パフォーマンスのボトルネック、および信頼性に影響を与える可能性のあるその他の問題を軽減できます。また、爆発半径を最小限に抑えることができます。
サポートされているリージョンのサービスの容量制約を考慮して、重要なコンポーネント (アプリケーションとインフラストラクチャ) をスケールアウトする機能を追加します。	ワークロードでは、容量の急増と変動を可変に処理できます。この機能は、有効な使用の急増など、システムに予期しない負荷がある場合に重要です。ワークロードが複数のリージョンにスケールアウトするように設計されている場合は、潜在的な一時的なリソース容量の制約や、1 つのリージョンで影響を受けるその他の問題を克服することもできます。
さまざまなアプリケーション層でレイヤーの冗長性と回復性を構築します。物理ユーティリティと即時データレプリケーションの冗長性を目指します。また、サービス、運用、担当者を対象とする機能層の冗長性を目指します。	冗長性は、単一障害点を最小限に抑えるのに役立ちます。たとえば、コンポーネント、ゾーン、またはリージョンの停止がある場合、冗長デプロイ (アクティブ/アクティブまたはアクティブ/パッシブ) を使用すると、アップタイムターゲットを満たすことができます。仲介を追加すると、コンポーネント間の直接的な依存関係が防止され、バッファリングが向上します。どちらの利点も、システムの回復性を強化します。
冗長インスタンスの個々の障害を直ちに軽減し、リソースの暴走に対してバッファーを設定するためにオーバープロビジョニングします。	オーバープロビジョニングへの投資が増えると、回復性が向上します。システムは、アクティブな障害が発生しても、スケーリング操作がエラーの修復を開始する前でも、完全なユーティリティで動作し続けます。同様に、システム障害や積極的なスケーリングが発生する前に、計画されたバッファーを要求して重大なトリアージ時間を得る、予期しない暴走リソース消費のリスクを軽減できます。

回復のための設計

ワークロードは、ユーザーエクスペリエンスとビジネス目標の中断を最小限に抑えながら、あらゆる規模のほとんどの障害を予測し、復旧できる必要があります。

回復性の高いシステムでも、アーキテクチャ設計とワークロード運用の両方で、 ディザスター準備アプローチが必要です。データレイヤーには、破損した場合にワークロードの状態を修復できる戦略が必要です。

アプローチ	特長
ネゴシエートされた復旧ターゲットに合わせて、構造化、テスト、文書化された復旧計画を作成します。プランは、システム全体に加えて、すべてのコンポーネントをカバーする必要があります。	適切に定義されたプロセスにより、迅速な回復が可能になり、ビジネスの財務と評判に悪影響を及ぼすのを防ぐことができます。定期的な復旧訓練を実施すると、システムコンポーネント、データ、フェールオーバー、フェールバックの各手順を復旧するプロセスがテストされ、時間とデータの整合性が成功の重要な手段である場合の混乱を回避できます。
復旧ターゲット内のすべてのステートフルコンポーネントのデータを修復できることを確認します。	バックアップは、最後に既知の良好な状態のように、信頼された復旧ポイントを使用してシステムを動作状態に戻すために不可欠です。不変バックアップとトランザクション整合性バックアップにより、データを変更できないことと、復元されたデータが破損しないようにします。
設計に自動自己復旧機能を実装します。	この自動化により、人間の介入などの外部要因によるリスクが軽減され、ブレークフィックスサイクルが短縮されます。
ステートレスコンポーネントを変更できないエフェメラルユニットに置き換えます。	必要に応じてスピンアップして破棄できるエフェメラルユニットを構築すると、再現性と一貫性が提供されます。並列デプロイモデルを使用して、新しいユニットへの移行を段階的に行い、中断を最小限に抑えます。

操作に合わせた設計

操作を左にシフトして、エラー状態を予測します。

開発ライフサイクルの早い段階で頻繁に失敗をテストし、パフォーマンスが信頼性に与える影響を判断します。根本原因の分析と事後分析のためには、チーム間で依存関係の状態と進行中の障害の可視性を共有する必要があります。 監視可能なシステムからの分析情報、診断、アラートは、効果的なインシデント管理と継続的な改善に不可欠です。

アプローチ	特長
テレメトリを関連付けることができる監視可能なシステムを構築します。	監視と診断は重要な操作です。何かが失敗した場合は、失敗した日時、失敗した理由を知る必要があります。コンポーネントレベルでの監視は基本的ですが、コンポーネントと相関ユーザーフローの集計された可観測性は、正常性状態の全体像を提供します。このデータは、サイト信頼性エンジニアが修復の取り組みに優先順位を付けるために必要です。
潜在的な誤動作と異常な動作を予測します。優先度付けされた実用的なアラートを使用して、アクティブな信頼性エラーを表示します。より迅速なトリアージにつながる信頼性の高いプロセスとインフラストラクチャに投資します。	サイト信頼性エンジニアは、進行中のライブサイトインシデントを軽減し、ライブインシデントになる前に予測アラートによって特定された潜在的な障害を予防的に軽減できるように、直ちに通知を受けることができます。
障害をシミュレートし、運用環境と実稼働前環境でテストを実行します。	復旧に対する現実的な期待を設定できるように、運用環境で障害が発生すると便利です。これにより、障害に適切に対応する設計上の選択を行うことができます。また、ビジネスメトリックに設定したしきい値をテストすることもできます。
自動化を念頭に置いてコンポーネントを構築し、できる限り自動化します。	自動化により、人的エラーの可能性を最小限に抑え、テスト、デプロイ、運用に一貫性をもたらします。
ルーチン操作の要因と、システムの安定性への影響。	ワークロードには、アプリケーションのリビジョン、セキュリティとコンプライアンスの監査、コンポーネントのアップグレード、バックアッププロセスなどの継続的な操作が適用される場合があります。これらの変更を確認すると、システムの安定性が確保されます。
運用環境のインシデントから継続的に学習します。	インシデントに基づいて、運用前に気付かれない可能性がある設計と運用における影響と監視を判断できます。最終的には、実際のインシデントに基づいて改善を推進することができます。

シンプルな状態を保つ

アーキテクチャの設計、アプリケーションコード、および操作の過剰な設計は避けてください。

多くの場合、最も信頼性の高いソリューションにつながる追加内容ではなく、削除します。 簡素化により、制御の対象となる領域が減り、非効率性や構成の誤りや予期しないやり取りが最小限に抑えられます。一方、過剰実装では単一障害点が発生する可能性があります。バランスの取れたアプローチを維持する。

アプローチ	特長
対象となるビジネス価値を達成するのに役立つ場合にのみ、アーキテクチャにコンポーネントを追加します。クリティカルパスをリーンのままにします。	ビジネス要件の設計は、実装と管理が簡単な簡単なソリューションにつながる可能性があります。重要なコンポーネントが多すぎるのは避けてください。各コンポーネントは重大な障害点であるためです。
コード実装、デプロイ、およびプロセスで標準を確立し、文書化します。自動化された検証を使用して、これらの標準を適用する機会を特定します。	標準は一貫性を提供し、人的エラーを最小限に抑えます。標準の名前付け規則やコードスタイルガイドなどのアプローチは、品質を維持し、トラブルシューティング中に資産を簡単に識別するのに役立ちます。
理論的アプローチが、ユースケースに適用される実用的な設計に変換されるかどうかを評価します。	アプリケーションコードが細かすぎると、不要な相互依存、余分な操作、および困難なメンテナンスが発生する可能性があります。
十分なコードを開発します。	予期しないリソースの消費、ユーザーまたはデータフローのエラー、コードのバグなど、非効率的な実装の結果である問題を防ぐことができます。逆に、信頼性の問題は、コードが問題を処理するのに十分な回復性を確保するために、コードレビューにつながる必要があります。
ビジネス目標を効果的に達成するのに役立つプラットフォーム提供の機能と事前構築済みの資産を活用します。	この方法により、開発時間が最小限に抑えられます。また、同様のワークロードで使用されている、試行済みおよびテスト済みのプラクティスに依存することもできます。

次の手順

信頼性チェックリスト

次の方法で共有