回復力についてはエンジニアリングを理解する

完了

Microsoft では、回復性を "通常の運用に対する障害や課題に直面した場合に顧客の期待を満たすビジネス プロセスまたはサービスの機能" と定義しています。Microsoft Online Services の規模では、オンライン サービスの可用性を維持するために回復性が重要です。 それを理解しているからこそ、Microsoft は回復力のあるサービスを構築しているのです。

  • ハードウェアには障害がつきものです。 ハード ドライブの平均障害前時間 (MTFB) を 10 万時間と仮定します。 1 台のハード ドライブの場合、障害は 11.5 年に 1 回なので、管理可能に思います。 しかしながら、1 千万台のハード ドライブを持っていれば、障害はおよそ 30 秒に 1 回の割合で発生します。 一般的なハードウェア コンポーネントの障害に対する回復力は、オンライン サービスをどのように設計して構築するかについての重要な特徴となっています。
  • 人は皆、ミスを犯します。 一般的な IT 実装において、100 台のサーバーを持つシステムである人物が 1 日に 100 件の操作を行うとします。 99% の精度でも、1 日 に 1 回はミスが発生します。 これを 25 万台のサーバーへと拡大してみると、1 日 2500 件のミスとなります。
  • ソフトウェアにはバグがあります。 サービスを最新の状態に保つためには、ソフトウェアの更新プログラムを継続的に展開していく必要があります。 回復力の高いサービスは、ソフトウェアの新しいバグや、これまで発見されてこなかったバグの両方から自身を保護する必要があります。

Microsoft の超大規模クラウドを使用し、サービス自動化を導入して、複数の障害モードに対する回復力のあるサービスを実現することで、これらの課題に対応しています。

回復力の原則であるアクティブ/アクティブ サービス設計、障害の分離、爆発半径の低減、継続的改善を実現するためのエンジニアリングをグラフィックで表現したもの

アクティブ/アクティブ サービス設計

可能な限り、Microsoft のサービスがアクティブ/アクティブ回復性を備えて設計や展開がなされていることを確認します。 これは、サービスの重要なコンポーネントに障害が発生した場合に、可用性を失うことなく同じコンポーネントを引き継ぐことができることを意味します。 アクティブ/アクティブ展開は、アクティブなコンポーネントに障害が発生した場合にパッシブなコンポーネントがワークロードを引き継ぎ、サービスの可用性やデータの整合性を一時的に中断していた従来のアクティブ/パッシブ モデルを置き換えるものです。 アクティブ/アクティブ サービス設計は、その他の展開モデルと比較して大幅に改善されており、さまざまな種類のサービス障害に対する回復力を提供します。

障害の分離

障害の分離は、1 つのコンポーネントの障害が他のコンポーネントの障害を引き起こすのを防ぐことで、サービスの回復力を高めます。 障害の分離は、コンポーネントの障害からの自動回復に必要となる範囲を減らすことで、アクティブ/アクティブ サービス設計を補完します。 Microsoft は、障害が他のシステム コンポーネントに分散して影響を与えるのを防ぐために、クラウド サービスの障害ゾーンのサイズを小さくするために継続的に取り組みます。

障害の分離のために使用される戦略には、次のようなものがあります。

  • サービス コンポーネント内やサービス コンポーネント間での細かい障害制御: たとえば、Exchange Online のデータベース可用性グループを使用すれば、サービス内の障害が特定の可用性グループへと与える影響を制限することができます。
  • サービスの可用性のためのマルチプロトコル管理: たとえば、Teams でのファイルへのアクセスに影響を与えるインシデントは、SharePoint Online を介してファイルへのアクセスを行うことによって軽減することができます。
  • 地域化と細かいシステム設計: Microsoft のサービス設計では、論理的なササービス インフラストラクチャーと物理的なサービス インフラストラクチャーをより細かい単位に分割しています。 これにより、小規模サービス管理と大規模サービス管理の両方が持つ柔軟性を活かした、インシデントの範囲に基づく適切な対応が可能となります。
  • 負荷分散と調整: Microsoft のサービスは、通常のサービス運用の一環として、システム コンポーネント間のトラフィックとデータを定期的にシャッフルします。 必須ではないサービス側のトラフィックは、メール配信のような重要なトラフィックを優先するために調整されます。 これにより、コンポーネントの障害やサービス インシデントが発生した場合に、Microsoft のシステムが自動的に重要なサービスを優先するようになります。

爆発半径の低減

障害の分離と密接に関連するのは、インシデントの "爆発半径" の概念です。インシデントが発生した場合、爆発半径は、インシデントがオンライン サービスに与える影響の広さを指します。 Microsoft は、潜在的なインシデントの爆発半径を低減するために常に努力しています。 インシデント対応についての事後検討で、許容不可能な爆発半径を持つインシデントの種類が発見された場合には、将来的に類似したインシデントが発生した場合の影響を低減するためのサービスの更新プログラムに投資を行うことで対応しています。

継続的改善

インシデントが発生した場合、Microsoft のインシデント対応プロセスにより、それぞれのインシデントは解決のために確実に管理されます。 Microsoft は標準化されたメトリックスを使用し、インシデントがサービスの可用性とパフォーマンスに与える影響を追跡します。 顧客への影響が大きいインシデントは、インシデントの事後レビューの対象となります。 インシデントの事後レビューで得られた主な調査結果と軽減策は、影響を受けた顧客が閲覧できるようにサービス正常性ダッシュボードへと投稿されます。

インシデントの事後レビューは、将来的な類似した問題の発生を防止したり、その範囲を制限したりする可能性のある回復性についての改善点の特定に役立てられます。 インシデントから得た教訓をサービス チーム間で共有することで、それぞれのチームは類似したインシデントを直接経験することなく改善策を実装することができます。

詳細情報