回復性

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

コンポーネントの誤動作、プラットフォームの停止、パフォーマンスの低下、その他の障害が発生することが予想されます。 システムに回復性を組み込むことで、フォールト トレランスを実現し、パフォーマンスの低下を抑えることができます。

サンプル シナリオ

Contoso Air は社内開発部門を持つ民間航空会社です。 メインの LOB アプリケーションは、顧客が Contoso Air で直接フライトを予約できる予約ソリューションです。 このアプリは Azure に組み込まれ、Azure App Service、Cosmos DB、Azure Functions、Azure Logic Apps、Azure Service Bus を使用します。

障害リスクを特定します。

システム内の潜在的な障害ポイント (特に重要なコンポーネントの障害ポイント) を特定し、ユーザー フローとシステム フローへの影響を判断します。

潜在的な各障害ポイントの障害ケース、ブラスト半径、障害の強度を分析します。 障害ケースとその強度は、バックエンド プロセスの一時的な損失などの比較的影響の少ないシナリオから災害による大規模な停止まで多岐に及ぶことがあります。 この分析を実行すると、コンポーネント レベルでエラー処理機能の設計を決定するのに役立ちます。

"Contoso の課題"

  • この LOB アプリケーションは、マーケティングからコマースまで多くの重要な機能を提供します。 チケット購入ユーザー フローは、最も重要なフローと考えられています。 障害の際にフローの復旧を最適化できるよう、ワークロード チームは信頼性を高める対策をさらに実装する必要があると判断しました。
  • チームはコンポーネントの分離やフローの再設計などの改善のための時間を設定していますが、この時間を使用して価値を最大限に高めることに注力したいと考えています。

"アプローチの適用と結果"

  • チームは、外部支払いゲートウェイを潜在的な障害ポイントとして識別します。 ゲートウェイの可用性は高いものの、ネットワークの問題や要求の極端な増大によって一時的な障害が発生する可能性があります。 複数の同時要求が送信されることでオーバーロードが発生すると、ゲートウェイは一部の要求を拒否することがあります。
  • 最初の要求がゲートウェイによって拒否されると、ユーザーは要求を再送信する必要があるためユーザー エクスペリエンスが低下するとチームは考えています。

自己保存の仕組みを実装する

設計パターンを正しく使用し、設計をモジュール化して障害を分離することで、自己保存機能を構築します。

システムに自己保存機能を組み込むことで、問題がダウンストリーム コンポーネントに影響するのを防止できます。 システムは、一時的な障害と永続的な障害、パフォーマンスのボトルネック、信頼性に影響を与える可能性のあるその他の問題を軽減できます。 また、ブラスト半径を最小限に抑えることができます。

"Contoso の課題"

  • 一時的な障害によってユーザーの要求が支払いゲートウェイによって拒否されるリスクを最小限に抑えたいとチームは考えています。 一部のエラー条件には一時的な性質があるため、同じ要求が再送信されると成功する可能性が高くなります。

"アプローチの適用と結果"

  • チームはフロー内でカスタム ロジックを開発することで、再試行可能なエラーが検出された際にしばらく待った後にトランザクションを再試行できます。
  • 再試行パターンを組み込むためにソリューションの設計が変更されるため、要求が正常に処理されるかエラーの最大数に達するまで、再試行の間の待機時間が多少長くなります。
  • また、チームは Azure Service Bus でイベントに基づくアプローチを活用して、このフローのユーザー操作とバックエンドの支払い処理機能を切り離すことを決定します。 (最大数の再試行の発生後に) メッセージの処理中に回復不能なエラーが発生すると、バックエンド プロセッサはその要求の処理を中止し、後で再処理できるようにメッセージをキューに残します。

包括的な冗長性と回復性を構築する

さまざまなアプリケーション層でレイヤーの冗長性と回復性を構築します。

物理ユーティリティと即時データ レプリケーションの冗長性を目指します。 また、サービス、運用、担当者を対象とする機能レイヤーの冗長性を目指します。 冗長性は単一障害点を最小限に抑えるために役立ちます。 たとえば、1 つ以上のコンポーネント、可用性ゾーン、またはリージョン全体に影響する停止が発生すると、冗長な (アクティブ/アクティブまたはアクティブ/パッシブ) デプロイ環境を使用すると、アップタイムの目標を満たすことができます。

中継要素を追加すると、コンポーネント間の直接的な依存関係を防止し、バッファリングを改善できます。 この 2 つのメリットにより、システムの回復性を強化できます。

"Contoso の課題"

  • Service Bus を使用して再試行を実装し、UI から支払いのゲートウェイ呼び出しを切り離すことで、このフローの信頼性が大幅に向上しましたが、ビジネス部門の関係者はプライマリ リージョンの致命的な障害が原因で発生する可能性のあるデータ損失について心配しています。

"アプローチの適用と結果"

  • チームは Service Bus の Premium レベルへのアップグレードを決定します。 そうすることで、そのレベルの Availability Zones サポート機能を利用できます。 この機能により、データの複数のコピーが物理的に分離された 3 つの機能 (可用性ゾーン) に保存され、サービスにはデータセンターの完全で致命的な損失に即座に対処するための十分な容量が確保されます。
  • さらに、チームは Azure Service Bus の geo ディザスター リカバリーを構成することで、可能性は低いもののプライマリ リージョンの完全な障害が発生した場合に使用されるセカンダリ リージョンにデータを継続的にレプリケートできます。

自分の知識をチェックする

1.

誤動作が発生した際に復旧できるよう、ワークロードにどのような機能を設計する必要がありますか?

2.

ワークロードに冗長性を追加するにはどうすればいいのでしょうか?

3.

ワークロード チームは、DDoS 攻撃がワークロードに及ぼす影響を理解する必要があります。 テストの前にチームは何をする必要がありますか?