エクスポート (0) 印刷
すべて展開

Failsafe: Guidance for Resilient Cloud Architectures

更新日: 2014年6月

作成者: Marc Mercuri、Ulrich Homann、Mark Simms、Jason Wescott、Andrew Townhill

校閲者: Michael Thomassy、Curt Peterson、Stuart Ozer、Fran Dougherty、Tim O’Brien、Hatay Tuna、Patrick Butler Monterde、Mark Kottke、Lewis Curtis、William Bellamy

発行日:2014 年 6 月

フェールセーフ 名詞。メカニズムやシステムなどの機能停止を防ぐために自動的に動作または機能するように設計されたもの。

従業員、市民、コンシューマーなどの個人は、アプリケーション、コンピューティング、データなどのサービスにすぐにアクセスできることを求めています。これらのサービスに接続する人の数も、接続に使用されるデバイスの数も、増加の一途を辿っています。こうした "常時オン" のサービスの世界では、それらのサービスをサポートするシステムが、可用性と回復力を念頭に置いて設計されている必要があります。

このようなサービスは、定義済み構成の汎用ハードウェアを使用して設定されたクラウド環境にデプロイされます。従来は、よりハイエンドのハードウェアを購入してスケールアップしてきたのではないでしょうか。クラウド環境の場合は、スケールアウトする必要があります。クラウド環境の場合、汎用ハードウェアを使用することでコストを抑えられます。汎用ハードウェアではいつか障害が発生します。そのため、クラウドには本当の意味で障害を受け入れるアーキテクチャが必要です。従来は、障害を防ぐことと、"平均無故障間隔" を最適化することに集中してきたのではないでしょうか。新しいクラウド環境では、"最小限の影響で復元する平均時間" が重視されています。

開発したサービスが複合サービスになる可能性は十分にあります。複合サービスは、1 つまたは複数のファーストパーティまたはサードパーティ プラットフォームおよびサードパーティ プロバイダー サービスで構成されます。このようなサービスは、障害がいつか発生するクラウド インフラストラクチャに構築されます。アーキテクチャにおいても、使用しているサービスでもいつか障害が発生することを想定する必要があります。インフラストラクチャ アーキテクチャと同様に、アプリケーション アーキテクチャ設計でも障害を受け入れる必要があります。

Microsoft のフェールセーフ イニシアチブは、回復力のあるクラウド アーキテクチャを作成するための一般的なガイダンス、それらのアーキテクチャを Microsoft テクノロジ上に実装するためのガイダンス、およびそれらのアーキテクチャを特定のシナリオで実装するための秘訣を提供することを目的としています。このドキュメントの作成者は、Microsoft の Cloud + Enterprise 部門、Trustworthy Computing、Microsoft Consulting Services のメンバーです。

このドキュメントでは、スケーラビリティと回復力を備えたシステムを設計するためのアーキテクチャ上の考慮事項について説明します。

このドキュメントは以下のセクションで構成されています。

  • ワークロードによるアプリケーションの分解: ワークロード中心のアプローチにより、コスト管理の強化、ワークロードに最適なテクノロジを選択できる柔軟性、可用性と回復力に対するよりきめ細かなアプローチが実現されることを説明します。

  • ライフサイクル モデルの確立: アプリケーションのライフサイクル モデルを確立すると、運用時のアプリケーションの想定される動作を定義したり、アーキテクチャ全体の要件および詳細を特定したりすることができます。

  • 可用性モデルと可用性プランの確立: 可用性モデルは、ワークロードに期待される可用性のレベルを明らかにします。これは、サービスを確立するときのさまざまな決定を十分な情報に基づいて行うために欠かせません。

  • 障害点、障害モード、障害の影響の特定: 回復力のあるアーキテクチャを作成するには、障害点と障害モードについて理解し、それらを特定することが重要です。具体的には、障害を引き起こす可能性があるものを事前に把握して記録する必要があります。これにより、分析と計画のためのアウトラインが確立されます。

  • 回復力のパターンと考慮事項: これは、このドキュメントの大半を占めるセクションです。このセクションには、コンピューティング、ストレージ、およびプラットフォームの各サービスの主要な考慮事項が含まれています。これらの考慮事項は、正常なアプリケーションを提供するための実証済みのプラクティスに重点を置いています。

  • 操作のための設計: "常時オン" のサービスが期待される世界では、サービスを操作のために設計することが重要になります。ここでは、ライフサイクル全体にわたって、操作のための設計の実証済みのプラクティスを紹介します (正常性モデルの確立、遠隔測定の実装、オペレーターや開発者に対する遠隔測定の情報の表示など)。

一般に、アプリケーションは複数のワークロードで構成されます。

個々のワークロードに関連付けられている要件、ビジネスにとっての重要性、および財務上の考慮事項のレベルは、同じとは限りません (通常は異なります)。そのため、アプリケーションをワークロードに分解すると貴重な柔軟性が得られます。ワークロード中心のアプローチにより、コスト管理の強化、ワークロードに最適なテクノロジを選択できる柔軟性、可用性とセキュリティに対するワークロード固有のアプローチ、新機能の追加と配置における柔軟性とアジリティなどが実現されます。

回復力について検討する際には、シナリオのコンテキストで考えるのも有効です。次に、一般的なシナリオの例を示します。

  • スポーツ データ サービス

    スポーツ情報のデータ サービスを提供しているお客様がいます。このサービスには主要なワークロードが 2 つあります。1 つは、選手とチームの統計情報を提供するワークロードです。もう 1 つは、現在行われている試合のスコアと解説を提供するワークロードです。

  • 電子商取引 Web サイト

    確立されたモデルを使用して Web サイトで物品を販売しているオンライン小売店舗があります。このアプリケーションには数多くのワークロードがあります。中でも最も一般的なのは、"検索と閲覧" と "チェックアウト" です。

  • ソーシャル

    コミュニティのメンバーがフォーラムに参加したり、コンテンツを作成したり、ゲームを楽しんだりできる話題のソーシャル サイトがあります。このアプリケーションには、登録、検索と閲覧、ソーシャル インタラクション、ゲーム、電子メールなど、数多くのワークロードがあります。

  • Web

    Web サイトで顧客にエクスペリエンスを提供したいと考えている組織があります。このアプリケーションでは、PC ベースのブラウザーと一般的なモバイル デバイス (携帯電話、タブレットなど) の両方でエクスペリエンスを提供する必要があります。このアプリケーションには、登録、検索と閲覧、コンテンツのパブリッシュ、ソーシャル コメント、モデレーション、ゲームなど、数多くのワークロードがあります。

ここでは、上のシナリオの 1 つを詳しく検討して、複数の子ワークロードに分解してみます。電子商取引 Web サイトには、閲覧と検索、チェックアウトと管理、ユーザー登録、ユーザー作成コンテンツ (レビューと評価)、カスタマイズなど、数多くのワークロードがあります。

以下は、このシナリオの 2 つの主要なワークロードの定義の例です。

  • 閲覧と検索: 顧客が製品カタログを閲覧したり、特定の製品を検索したり、買い物かごや欲しいものリストを管理したりできるようにします。このワークロードには、匿名ユーザー アクセス、1 秒以下の応答時間、キャッシュなどの特性があります。予想を超えるユーザー ロードによる応答時間の増加や、製品在庫の更新のためのアプリケーション トレラント割り込みにより、パフォーマンスが低下する場合があります。そのような場合は、アプリケーションで引き続きキャッシュから情報を提供することもできます。

  • チェックアウトと管理: 顧客による製品の注文、注文の追跡とキャンセル、配送方法と支払方法の選択、およびプロファイルの管理を支援します。このワークロードには、セキュリティで保護されたアクセス、キューによる処理、サード パーティの支払いゲートウェイへのアクセス、バックエンドのオンプレミス システムへの接続などの特性があります。このアプリケーションでは、応答時間の増加は許容されても失注は許容されません。したがって、支払いを処理したり配送を手配したりできるかどうかに関係なく、常に顧客の注文が受け入れられて記録されるように設計されています。

アプリケーションのライフサイクル モデルでは、運用時のアプリケーションの想定される動作を定義します。アプリケーションのシステムに対する需要は、機能レベルでもスケール レベルでも、フェーズやタイミングによって異なります。ライフサイクル モデルにはこれを反映します。

各ワークロードについて、適切なレベルの詳細度で関連するすべてのシナリオのライフサイクル モデルを定義する必要があります。ライフサイクル モデルを定義するときには、時間、日、週、または季節ごとの変化に注目し、そこから、各期間に固有の容量、可用性、パフォーマンス、およびスケーラビリティの要件を特定します。

図 1. 業界とシナリオ別のライフサイクル例

多くの場合、独自のライフサイクルになる期間があります。次に例を示します。

  • 休暇の時期に発生する需要のピークに関連する急上昇。

  • 確定申告の提出期限の直前に発生する増加。

  • 朝と夕方の通勤時間。

  • 年末の勤務評定の提出時期。

多くの組織では、このようなシナリオと、それに関連するシナリオ固有のライフサイクルを理解しています。

分解によって、ワークロード レベルで社内に複数のサービス レベル契約 (SLA) を設定できます。たとえば、スポーツ データ API の例では、99.99% の目標 SLA が設定されていました。 この API は、"ライブ スコア + 解説" と "チーム、プレイヤー、 リーグの統計情報" という 2 つのワークロードに分

"ライブ スコア + 解説" ワークロードの場合、ライフサイクルは "オフとオン" パターンです。一方、"チーム、プレイヤー、リーグの統計情報" の可用性は持続的です。ワークロードによって分解することで、複合サービスの集約したワークロードが持つ可用性のニーズに合わせて、SLA を設定することができます。

図 2

ライフサイクル モデルが特定されたら、次に、可用性モデルと可用性プランを確立します。アプリケーションの可用性モデルは、ワークロードに期待される可用性のレベルを明らかにします。これは、サービスを確立するときのさまざまな決定を十分な情報に基づいて行うために欠かせません。

ここでは、考慮する必要がある問題と可能な対策について説明します。

可用性プランを作成する際には、アプリケーション、そのアプリケーションのワークロード、およびそれらのワークロードのために使用されるサービスの可用性の目標を理解することが重要です。

ワークロードのライフサイクルを理解することで、必要な SLA を選択できるようになります。サービスの SLA を一般公開しないこともできます。ただし、アーキテクチャとしては、達成したい可用性の基準を目標にする必要があります。

構築するソリューションの種類によっては、高い可用性を実現するために考慮事項やオプションが多数あります。商用サービス プロバイダーは 100% の SLA を提供しません。これは、そのレベルの SLA を提供する複雑さとコストは実現不可能であり、利益がでないためです。アプリケーションをワークロード レベルに分解することで、可用性に対するアプローチを決定し、実装することができます。アプリケーション全体について 99.99% の稼働時間を達成することは実現不可能かもしれませんが、1 つのアプリケーションの 1 つのワークロードであれば達成可能です。

ワークロード レベルでも、すべてのオプションを実装するとは限りません。どのオプションを実装するかは要件によって決まります。どのオプションを選択するにしても、十分な情報に基づいてすべてのオプションをよく検討する必要があります。

自律性は、サービス全体を構成する部品間の独立性および依存度の削減に関連しています。サービスを設計するときには、関連する機能をサービス内の自律的な単位にまとめることができるように、コンポーネント、データ、および外部エンティティに対する依存関係を調べる必要があります。これにより、自律的な単位を個別に更新できるアジリティや、それらのスケーリングのきめ細かな制御が実現されます。

ワークロードのアーキテクチャは、多くの場合、手動介入に依存しない自律的なコンポーネントで構成されます。これらのコンポーネントでは、依存しているエンティティが使用できなくてもエラーは発生しません。自律的な部品で構成されたアプリケーションには次のような特徴があります。

  • 高い可用性と運用性

  • 高い回復力と容易な障害復旧

  • 異常な障害状態が発生するリスクが小さい

  • レプリケーションによるスケーリングが容易

  • 手動介入が必要になる可能性が低い

これらの自律的な単位では、サービスの継続性を確保するために、非同期通信、プル ベースのデータ処理、および自動化がよく利用されます。

将来的には、垂直と水平の両方のシナリオで、市場が進化して特定の機能のインターフェイスが標準化されるようになるでしょう。そうなれば、自律的な単位の作業を、さまざまなプロバイダーや (おそらくは) 実装を利用して解決できるようになります。これは、サービスの継続性を確保するために、ポリシーに基づいて自律的に行われます。

ほとんどのサービスは、自律性を切望しつつ (ホスティングのためだけでも) サード パーティのサービスに依存します。それらの依存サービスの SLA を理解して、可用性プランに組み込むことが重要です。

ここでは、サービスに関連する可能性があるさまざまな種類の SLA を特定します。サービスの種類ごとに、主な考慮事項およびアプローチと、確認すべき質問を紹介します。

パブリック クラウド プラットフォームのサービス

商用クラウド コンピューティング プラットフォームによって提供されるサービス (コンピューティング、ストレージなど) の SLA は、規模の大きい多数の顧客に対応するように作られています。そのため、これらのサービスの SLA には交渉の余地はありません。異なる SLA を持つ複数のサービス レベルの層が用意されている場合もありますが、個々の層では交渉の余地はありません。サービス プロバイダーは、SLA が異なる階層化されたサービス レベルを使用して、予測可能なサービス品質を提供しています。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

サード パーティの "無料" サービス

多くのサード パーティがコミュニティに "無料" サービスを提供しています。民間組織の場合、それらは主に、自分たちの主要な製品やサービスを中心とするアプリケーションのエコシステムを作る目的で提供されています。公的機関の場合は、税金によって政府に料金を支払ったことになっている市民や企業にデータを提供するために行われています。

これらのサービスには、ほとんどの場合、SLA がありません。したがって、可用性は保証されません。SLA が提供される場合も、通常は、コンシューマー アプリケーションに適用される制限や、その制限を適用するためのメカニズムに重点が置かれています。たとえば、サービス呼び出しの回数または頻度 (1 分あたりの回数) やサービスを呼び出すサーバーの数が制限を超えたソリューションを調整したりブラックリストに登録したりする場合などがあります。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • そのサービスはコモディティ サービスか (必要な機能やデータが複数のサービス プロバイダーから提供されているか)?

  • (コモディティ サービスの場合) インターフェイスに他のサービス プロバイダーとの相互運用性が確保されているか (他のサービス プロバイダーのサービスから直接、または利用可能な抽象化レイヤーを介して利用できるか)?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

サード パーティの商用サービス

サード パーティによって提供される商用サービスには、料金を支払う顧客のニーズに対応するように設計された SLA があります。可用性のレベルが異なる複数の SLA が用意されている場合もありますが、それらの SLA には交渉の余地はありません。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • そのサービスはコモディティ サービスか (必要な機能やデータが複数のサービス プロバイダーから提供されているか)?

  • (コモディティ サービスの場合) インターフェイスに他のサービス プロバイダーとの相互運用性が確保されているか (他のサービス プロバイダーのサービスから直接、または利用可能な抽象化レイヤーを介して利用できるか)?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

コミュニティ クラウドのサービス

組織のコミュニティ (サプライ チェーンなど) がメンバー組織にサービスを提供する場合があります。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • コミュニティのメンバーが異なる SLA について交渉することは可能か?

  • そのサービスはコモディティ サービスか (必要な機能やデータが複数のサービス プロバイダーから提供されているか)?

  • (コモディティ サービスの場合) インターフェイスに他のサービス プロバイダーとの相互運用性が確保されているか (他のサービス プロバイダーのサービスから直接、または利用可能な抽象化レイヤーを介して利用できるか)?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

ファースト パーティ内の企業全体のクラウド サービス

企業が社内の部門や部署にコア サービス (株価データ、製品のメタデータなど) を提供する場合があります。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • 組織のメンバーが異なる SLA について交渉することは可能か?

  • そのサービスはコモディティ サービスか (必要な機能やデータが複数のサービス プロバイダーから提供されているか)?

  • (コモディティ サービスの場合) インターフェイスに他のサービス プロバイダーとの相互運用性が確保されているか (他のサービス プロバイダーのサービスから直接、または利用可能な抽象化レイヤーを介して利用できるか)?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

ファースト パーティ内の部門または部署別のクラウド サービス

企業の部門や部署が組織の他のメンバーにサービスを提供する場合があります。

このサービスの種類で考慮すべき質問:

  • サービス API の呼び出しの回数は制限されているか?

  • サービス API の呼び出しの頻度は制限されているか?

  • サービス API を呼び出すことのできるサーバーの数は制限されているか?

  • 可用性の目標の達成状況についてどのような情報が公開されているか?

  • サービスの正常性状態はどのように通知されるか?

  • サービス レベル契約 (SLA) はどのように定められているか?

  • 部門のメンバーが異なる SLA について交渉することは可能か?

  • そのサービスはコモディティ サービスか (必要な機能やデータが複数のサービス プロバイダーから提供されているか)?

  • (コモディティ サービスの場合) インターフェイスに他のサービス プロバイダーとの相互運用性が確保されているか (他のサービス プロバイダーのサービスから直接、または利用可能な抽象化レイヤーを介して利用できるか)?

  • 他のサード パーティによって提供されている同等のプラットフォーム サービスにはどのようなものがあるか?

複合サービスの真の可用性

既存のサービスを活用すると、社内向けのソリューションや商用のソリューションを提供する際のアジリティを大幅に向上させることができますが、それらの依存関係がワークロードの全体的な SLA に与える影響を正しく理解しておく必要があります。

可用性は、通常、特定の年のアップタイムの割合として表され、9 の数で呼ばれます。たとえば、99.9 は "スリー ナイン" のサービスを表し、99.999 は "ファイブ ナイン" のサービスを表します。

 

可用性 (%)

ダウンタイム/年

ダウンタイム/月

ダウンタイム/週

90% ("ワン ナイン")

36.5 日

72 時間

16.8 時間

95%

18.25 日

36 時間

8.4 時間

97%

10.96 日

21.6 時間

5.04 時間

98%

7.30 日

14.4 時間

3.36 時間

99% ("ツー ナイン")

3.65 日

7.20 時間

1.68 時間

99.5%

1.83 日

3.60 時間

50.4 分

99.8%

17.52 時間

86.23 分

20.16 分

99.9% ("スリー ナイン")

8.76 時間

43.2 分

10.1 分

99.95%

4.38 時間

21.56 分

5.04 分

99.99% ("フォー ナイン")

52.56 分

4.32 分

1.01 分

99.999% ("ファイブ ナイン")

5.26 分

25.9 秒

6.05 秒

99.9999% ("シックス ナイン")

31.5 秒

2.59 秒

0.605 秒

99.99999% ("セブン ナイン")

3.15 秒

0.259 秒

0.0605 秒

複合サービスの可用性 ("9" の数) はよく誤解されているので注意する必要があります。たとえば、あるサービスが 5 つのサービスで構成されていて、各サービスの SLA で 99.99% のアップタイムが保証されている場合、その複合サービスの可用性は 99.99% になると思われていることがよくありますが、それは間違いです。

図 3: 一般的な可用性のダウンタイム

複合 SLA は、実際には年間のダウンタイムに基づいて計算されます。たとえば、"フォー ナイン" (99.99%) の SLA を持つサービスでオフラインが許容されるのは 52.56 分までであるため、

複合サービスに SLA が 99.99% のサービスを 5 つ組み込むと、確認されている SLA のリスクは 262.8 分 (4.38 時間) になります。これによって、1 行のコードも書かないうちに可用性は 99.95% にまで下がります。

一般的に、サードパーティ サービスの可用性を変えることはできません。ただし、コードを書くときに、このドキュメントで説明するような手法を使用してアプリケーションの全体的な可用性を向上させることはできます。

noteメモ
サービスによっては、価格帯やビジネス パートナー関係に応じて提供するサービス階層が変わる場合があります。

前述したスポーツ データ API で考察してみます。ユーザーは、特定の日の特定の時間だけ試合をします。この期間中の SLA は 100% です。試合の予定がない場合、このワークロードの SLA は 0% です。"チーム、プレイヤー、リーグの統計情報" ワークロードのライフサイクル パターンにはより一貫性があります。また、このワークロードの要件は SLA が常に 99% であることです。

図 4

外部サービスを利用する際に SLA (個々のサービスの SLA とその複合サービスへの影響) を理解することの重要性は、いくら強調しても足りません。

回復力のあるアーキテクチャを作成するには、それを理解することが重要です。具体的には、障害を引き起こす可能性があるものを事前に把握して記録する必要があります。

アプリケーションとその関連ワークロード サービスの障害点と障害モードを理解しておくと、回復力と可用性の戦略を作成する際に的を絞った決定を行うための情報が得られます。

障害点とは、障害が発生するとサービスが中断する可能性がある場所です。外部からの変更を受ける設計要素に注目する必要があります。

障害点の例を以下に示します。

  • データベース接続

  • Web サイト接続

  • 構成ファイル

  • レジストリ キー

一般的な障害点のカテゴリを以下に示します。

  • ACL

  • データベース アクセス

  • 外部 Web サイト/サービス アクセス

  • トランザクション

  • 構成

  • 容量

  • ネットワーク

障害点は、障害を引き起こす可能性がある領域を定義しています。一方、障害モードは、障害が発生する可能性がある具体的な方法を特定します。

障害モードの例を以下に示します。

  • 構成ファイルが見つからない

  • トラフィックがリソースの容量を超えた

  • データベースが最大容量に達した

障害の影響とは、機能に関する障害の結果です。障害の影響と、そのような種類の障害が発生する可能性がある頻度について理解してください。理解することで、アプリケーションやサービスの障害点と障害モードに対応するタイミングと方法について優先順位を付けられるようになります。

このドキュメントでは、コンピューティング、ストレージ、プラットフォームの各サービスの主要な考慮事項について説明します。ただしその前に、回復力に影響を与えるいくつかの基本的なトピックを確認しておくことが重要です。これらは、誤解されていたり実装されていなかったりすることがよくあります。

既に説明したように、回復力のあるアーキテクチャは自律性に最適化する必要があります。自律性を実現する方法の 1 つは、通信を非同期にすることです。回復力のあるアーキテクチャでは、既定で非同期の対話を使用する必要があります。同期的な対話は、例外が発生した場合のみに限定します。

ソリューションのフロントエンドでは、ステートレス Web 層や分散キャッシュを使用する Web 層によってこの機能が提供されます。ワークロード サービス間の対話やワークロード サービス内のサービスのための通信では、キューによってこの機能が提供されます。

キューを使用すると、一方のサービスでキューにメッセージを配置して、もう一方のサービスでキューからメッセージを取得できます。これは、ロジック、時間、または量に基づいて行うことができます。この場合、プロセスを非同期にするだけでなく、キューに対する "プッシュ" または "プル" を行う層を必要に応じてスケーリングすることもできます。

アーキテクチャがサービスやリソース (データベースなど) に接続する場所ではよく一時的なエラーが発生するため、それらのサービスを使用するときには、タイムアウトの概念を導入するロジックを実装するのが一般的です。そのロジックでは、応答が行われるまでの許容時間を指定し、その時間を超えたら識別可能なエラーを生成します。タイムアウト エラーが発生した場合は、発生したコンテキストに基づいて適切に対処します。コンテキストには、そのエラーが発生した回数、リソースが利用できないことによって生じる可能性がある影響、その顧客に対するその期間の SLA の保証などが含まれます。

ワークロードを提供するサービスを設計するときには、エラーが発生するという事実を受け入れて、適切な対策を講じる必要があります。

対処する必要がある領域の 1 つが一時的なエラーです。アップタイムが 100% のサービスは存在しないため、ワークロードが依存しているサービスに接続できなくなることがあると考えるのが現実的です。サービスに接続できなくなったりエラーが返されたりする状況は、一時的な場合 (1 秒未満) もあれば永続的な場合 (プロバイダーのシャットダウン) もあります。

気付かれないようにサービス レベルを下げる

ワークロード サービスでは、そうした一時的なエラーをユーザーに気付かれないように処理する必要があります。たとえば、Netflix では、クラウド プロバイダーの障害によってプライマリ データ ストアが利用できなくなったときに、顧客に対して古いビデオ キューが使用されました。また、電子商取引サイトでは、支払いゲートウェイが利用できなくなっても注文の収集が継続されます。これにより、支払いゲートウェイが再び使用可能になった場合や、別の支払いゲートウェイにフェールオーバーした後に、注文を処理できます。

適切なサービス レベルの低下に関する考慮事項の概要

適切にサービス レベルを低下させる方法を検討する場合、主に次の考慮事項があります。

  • 要求のコンテキストが完全ではないコンポーネントは、単純にエラーになって例外メッセージを渡す必要があります。この問題を解決するには、このドキュメントで後述するように、遮断器を実装し、障害回数のしきい値に達したときに Fail Fast が発生するようにします。

  • 一時的な性質を持つ可能性がある障害は珍しくありません。このような障害は、このドキュメントで後述する再試行パターンを使用して対応します。

  • 呼び出し元は、異なるパラメーターや異なるパスを使用して要求を再試行することで、一部の失敗した要求を修正できる場合があります。

  • シナリオにとって要求の成功が重要ではない場合は、単に何もせずに障害を処理します。

  • 成功メッセージを返し、失敗した要求をキューに保存して、リソースが通常の状態に戻ったときに後で処理することで、障害に対応できます。

  • 以前は正しかったものを返すことができる場合もあります。たとえば、キャッシュ済みの資格情報、キャッシュの古いデータなどです。

  • ほぼ正しいエクスペリエンスを提供することで対応できる障害もあります。たとえば、一時的なアクセス、概算値、最適な推測値、noscript などです。

  • エラーをスローするのではなく、何らかの代替を提供できる場合もあります。たとえば、ランダム値、匿名権限、既定の画像などです。

一時的なエラー処理に関する考慮事項

一時的なエラー処理の実装に関しては、重要な考慮事項がいくつかあります。ここでは、それらについて説明します。

  • 再試行ロジック

    最も単純な形式の一時的なエラー処理では、失敗した操作を再試行します。サード パーティの商用サービスを使用している場合は、通常は "再試行ロジック" を実装することによってこの問題を解決できます。

    通常は、ロジックが再試行される回数を設計で制限する必要があります。アクションを一定の回数再試行してもエラーが解決されない場合は、エラーを登録するか、セカンダリ サービス (ワークフロー) を利用します (またはその両方を行います)。

  • 指数バックオフ

    一時的なエラーの原因が、負荷が高いためにサービスで調整が行われたことにある場合は、サービスの呼び出しを繰り返しても、調整を長引かせ、全体的な可用性に悪影響を与えるだけです。

    このような場合は、調整を回避または削減するために、サービスの呼び出しを減らすことをお勧めします。そのためには、最初に失敗したときにはすぐに再試行し、2 回目の失敗の後には 1 秒待機して、3 回目の失敗の後には 5 秒待機するなど、最終的に呼び出しに成功するかアプリケーションで定義されている失敗回数のしきい値に達するまで待機時間を徐々に増やすアルゴリズムを使用するのが一般的です。

    この方法は、"指数バックオフ" と呼ばれています。

  • べき等

    接続先のサービスでは、主要な前提として、100% の可用性はあり得ないため、再試行ロジックによる一時的なエラー処理が主要な実装方法となります。再試行ロジックを実装する場合、同じメッセージが複数回送信されたり、メッセージが誤った順序で送信されたりする可能性があります。

    操作がべき等になるように設計して、同じメッセージが複数回送信されても、データ ストアで予期しない結果が生じたり、データ ストアが汚染されたりしないようにする必要があります。

    たとえば、すべての要求のデータを挿入すると、サービス操作が複数回呼び出された場合に複数のレコードが追加される可能性があります。それを防ぐには、そのコードをインテリジェントな "upsert" として実装します。タイムスタンプまたはグローバル識別子を使用して、新しいメッセージと以前に処理されたメッセージを識別し、新しい方のメッセージのみをデータベースに挿入します。メッセージが以前に受信したメッセージより新しかった場合は、既存のレコードを更新します。

  • 補正の動作

    べき等に加えて、補正の動作の概念も考慮に入れる必要があります。接続されるシステムが増加し続けており、複合サービスも出現している現在、補正の動作を処理する方法を理解することの重要性が高まっています。

    トランサグションの概念は、基幹業務アプリケーションの開発者にとって新しいものではありませんが、ローカル データ テクノロジや関連コード ライブラリによって公開されるトランザクション機能との関連で捉えられているのが一般的です。この概念をクラウドの観点から見る際には、分散サービスのオーケストレーションに関する問題を新たに考慮に入れる必要があります。

    サービス オーケストレーションは、複数の分散システムにまたがることがあるほか、実行時間が長い場合や、ステートフルな場合もあります。オーケストレーション自体が同期的であることはほとんどなく、ビジネス シナリオに基づいて、秒単位から年単位にわたって複数のシステムで実行される可能性があります。

    たとえば、同じワークロード アクティビティで 25 の組織を結び付けることのできるサプライ チェーンのシナリオでは、1 つ以上のサービス オーケストレーションで 25 以上のシステムが相互接続される可能性があります。

    アクティビティが成功した場合、そのことを 25 のシステムに通知する必要があります。参加システムは、アクティビティの各接続ポイントで、他のシステムから受信するメッセージの相関 ID を指定できます。アクティビティの種類に応じて、その相関 ID の受信によってトランザクションの完了が通知される場合もあれば、25 の参加システムの対話がすべて完了してからすべてのシステムに確認メッセージが送信される場合もあります (1 つのサービスから直接送信される場合もあれば、各システムのオーケストレーション対話ポイントを介して送信される場合もあります)。

    複合アクティビティや分散アクティビティの失敗を処理するには、一意の識別子によって特定のトランザクションの取り消し要求を受信するためのサービス インターフェイスとサービス操作を各サービスで公開し、サービスの背後にあるワークフローでそのアクティビティの取り消しを補正します。これらのワークフローは、自動プロシージャにするのが理想的ですが、手動で修正するために組織の特定の人物にルーティングするだけでもかまいません。

遮断器とは、あらかじめ設定された制限を超えた場合に電流の流れを自動的に遮断するスイッチです。過剰な電流が回路に流れるのを防ぐためによく使用されます。ヒューズとは異なり、リセットして再利用できます。

同じパターンをソフトウェアの設計に応用できます。可用性と回復力が重視されるサービスで特に有効です。

たとえば、リソースが利用できなくなるケースは、ソフトウェアの遮断器を実装することによって適切に対処できます。

遮断器には、"閉"、"開"、"半開" という 3 つの状態があります。

"閉" 状態はアプリケーションまたはサービスの通常の状態です。"閉" 状態の場合、要求は標準のパスでルーティングされます。カウンターで障害発生率が追跡され、しきい値と照合して評価されます。この障害発生率がしきい値を超えると、遮断器は "開" 状態に変わります。データベース リソースの呼び出しを 100 回続けても成功しない場合、それ以上データベースの呼び出しを続けてもあまり意味はないと考えられます。したがって、そのしきい値で遮断器をトリガーして、適切に対処することができます。

"開" 状態の場合、遮断器は要求を対策用のパスにルーティングします。これは Fail Fast になる場合もあるし、別の形で適切にサービス レベルを低下させる場合もあります。遮断器が "開" 状態に切り替わると、タイマーも開始されます。タイマーが満了すると、"半開" 状態に切り替わります。

"半開" 状態になると、通常のパスを介して限られた数の要求をルーティングし始めます。これらの要求が成功すると、遮断器は "閉" 状態に切り替わります。この限られた数の要求が失敗すると、遮断器は "開" 状態に戻ります。

アーキテクチャに遮断器パターンを含める場合、次の点を考慮してください。

  • 遮断器は、操作でスローされた例外の種類に基づいて、"開" 状態のときにさまざまな対策やさまざまな時間を開始できます。

  • 遮断器は、すべての移行状態をログに記録する必要があります。記録することで、オペレーターは移行動作を監視し、タイマーを微調整して "開" 状態が長く続く問題や "開" 状態と "半開" 状態が頻繁に切り替わる問題を回避することができます。

  • "開" から "半開" に移行するタイマーを使用せずに、正常な状態に戻ったかどうかを確認するために遮断器で標準のパスを定期的にテストすることもできます。

  • 複数のシャードが発生する操作を扱う場合、遮断器は慎重に使用してください。このとき、稼働状態はシャード レベルの場合があり、次の 2 つのシナリオのような望ましくない結果になる可能性があります。

    • 1 つのシャードのみが失敗したときに "開" 状態に移行する。

    • 1 つまたは複数のシャードが正常に戻ったときに誤って "閉" 状態に移行する。

このパターンの一般的な実装は、データベースやデータ サービスへのアクセスに関連しています。あらかじめ設定された種類およびレベルのアクティビティが失敗すると、遮断器がトリガーされます。データの場合は、データベースやデータベースの前にあるデータ サービスに接続できない場合に遮断器がトリガーされるのが一般的です。

データベース リソースの呼び出しを 100 回続けても成功しない場合、おそらく、それ以上呼び出しを続けてもあまり意味はありません。したがって、そのしきい値で遮断器をトリガーして、適切に対処することができます。

データ サービスに接続する場合などに、一定期間内の呼び出し回数が制限を超えたために調整が適用されてサービスに接続できなくなることがあります。そのような場合は、接続が正常に確立されて許容範囲内に収まるまで遮断器で呼び出しの間隔を徐々に伸ばすことができます。

データ ストアを使用できなくなる場合もあります。その場合、データの冗長コピーがあればそのレプリカにフェールオーバーすることができますが、正確なレプリカがない場合や、プロバイダーのすべてのデータ センターでデータベース サービスがダウンしている場合は、別の方法を使用する必要があります。たとえば、代替データ サービス プロバイダーのデータを、要求されたデータの代替ソースとして使用することができます。この代替ソースは、キャッシュ、現在のクラウド プロバイダーの代替永続データ ストア タイプ、別のクラウド プロバイダー、オンプレミスのデータ センターなどから取得できます。そのような代替ソースも使用できない場合は、クライアントで適切に処理できる認識可能なエラーを返すことができます。

遮断器の例: Netflix

メディア ストリーミング企業の Netflix は、回復力のあるアーキテクチャの好例とされています。Netflix Tech Blog では、Netflix で使用されている遮断器のパターンを論じる中で、その遮断器に含まれているいくつかの条件が紹介されています。たとえば次のようなものがあります。

  1. リモート サービスへの要求がタイムアウトする。

  2. サービスの依存関係を操作するために使用されるスレッド プールと有限タスク キューの容量が 100% に達している。

  3. サービスの依存関係を操作するために使用されるクライアント ライブラリが例外をスローする。

これらはすべて、全体的なエラー率を押し上げます。そのエラー率があらかじめ定義されたしきい値を超えると、遮断器が "切れて" 直ちにフォールバックが提供されます。リモート サービスへの接続が試行されることもありません。

同じブログ エントリで、各サービスの遮断器に実装されているフォールバックの 3 つのアプローチも紹介されています。それらを以下に示します。

  1. カスタム フォールバック – 呼び出し可能なフォールバック メソッドがサービスのクライアント ライブラリで提供されるか、API サーバーでローカルに使用できるデータ (Cookie、ローカル キャッシュなど) を使用してフォールバック応答が生成されます。

  2. フェイル サイレント – メソッドが要求元のクライアントに null 値を返します。要求されているデータが省略可能な場合に有効です。

  3. フェイル ファースト – データが必要で、適切なフォールバックを使用できない場合は、クライアントに 5xx 応答が返されます。このアプローチでは、API サーバーの正常性を維持して、影響を受けているサービスがオンラインに復帰した場合に迅速に復旧できるようにすることに重点が置かれています。ただし、そのためにクライアント UX が犠牲になります。

SLA を適用するには、信頼できる相手と問題のある相手という 2 種類の外れ値をデータ サービスでどのように扱うかを決定する必要があります。

信頼できる相手とホワイト リスト

信頼できる相手とは、特別な取り決めを結んでいて、標準の SLA の例外とされる組織です。

  • 独自の契約を結んでいるサード パーティ

    サービスのユーザーから、特別な価格条件やポリシーの交渉を求められる場合があります。たとえば、データ サービスの大量の呼び出しに対して特別価格を設定する場合や、特定のデータ サービスで標準的な使用層の規定の量を超える要求を許可する場合があります。そのような顧客は、問題のある相手として処理されないように、信頼できる相手として定義する必要があります。

  • ホワイト リスト

    信頼できる相手を処理するには、ホワイト リストを定義するのが一般的です。ホワイト リストとは、信頼できる相手を識別するもので、サービスで顧客の使用を処理する際にどのビジネス ルールを適用するかを決定するために使用されます。ホワイト リストへの登録は、通常、IP アドレス範囲または API キーを承認することによって行われます。

    使用ポリシーを作成する際に、ホワイト リストをサポートするかどうかを明らかにする必要があります。サポートする場合は、顧客がホワイト リストへの登録を申請する方法、顧客をホワイト リストに追加する方法、および顧客がホワイト リストから削除される状況を指定する必要があります。

  • 問題のある相手の処理

    信頼できる相手の対極に位置するのが "問題のある相手" です。問題のある相手は、"過剰消費" などによってサービスに負担をかけます。問題のある行動は、純粋な過失による場合もあれば、意図的に行われる場合もあります。さらには、悪意に基づく場合もあります。"問題のある相手" と呼ばれるのは、それらの行動が、意図的かどうかに関係なく、1 つ以上のサービスの可用性に影響を与える可能性があるからです。

    問題のある相手は、データ サービス プロバイダーのコストを無駄に増加させる可能性があります。また、使用条件に忠実に従って、SLA に明記されている妥当なサービスを期待しているコンシューマーが、サービスにアクセスできなくなる可能性もあります。したがって、適切な対策を講じて、一貫した方法で対処する必要があります。通常は、調整とブラック リストが使用されます。

  • 調整

    データ サービスのコンシューマーによる使用の急増に対処するための方法を定義する必要があります。特定のコンシューマーからのトラフィックが急増すると、データ サービスに予想を超える負荷がかかる可能性があります。そのような場合は、そのコンシューマーからのアクセスを一定期間調整することができます。この場合、そのコンシューマーからのすべての要求が一定の間 (1 分、5 分、10 分など) 拒否されます。その間にそのコンシューマーからサービス要求が送られてくると、使いすぎのためにアクセスが調整されていることを通知するエラー メッセージが返されます。

    要求元のコンシューマーは、それに応じて対処できます (行動を改めるなど)。

    調整を実装して関連するビジネス ルールを設定するかどうかを決定する必要があります。コンシューマーに調整を適用する場合は、調整をトリガーする動作を決定する必要もあります。

  • ブラック リスト

    調整を適用しても、問題のある相手が常に行動を改めるとは限りません。調整で問題が解決されない場合は、コンシューマーのアクセスを禁止することができます。そのためにはブラック リストを使用します。ブラック リストは、ホワイト リストとは反対に、サービスへのアクセスを禁止されているコンシューマーを識別します。ブラック リストに登録されている顧客からのアクセス要求は、データ サービス リソースの使用を最小限に抑える形で適切に処理されます。

    ブラック リストへの登録は、ホワイト リストの場合と同様に、API キーまたは IP アドレス範囲を使用して行われるのが一般的です。

    使用ポリシーを作成する際に、ブラック リストに登録されることになる行為、ブラック リストへの登録に抗議する方法、およびブラック リストからコンシューマーを削除する方法を指定する必要があります。

間違いを犯さない人はいません。開発者がコードに加えた変更が予想外の結果を招く場合もあれば、DBA がデータベースのテーブルを誤って削除したり、オペレーターが変更を記録するのを忘れたりする場合もあります。このように、知らぬ間にサービスの回復力を低下させてしまうことはよくあります。

人為的なミスを減らすには、プロセスから人の手を減らすのが理にかなっています。自動化を導入すると、想定されている動作からのその場限りの不慮の逸脱によってサービスが危険にさらされる可能性を制限できます。

"すべてを自動化せよ" というマンガのキャラクターが DevOps コミュニティの間で広まっています。クラウドでは、ほとんどのサービスが API で公開されます。開発ツールから仮想化インフラストラクチャ、プラットフォーム サービス、SaaS として提供されるソリューションまで、ほとんどのものをスクリプト化できます。

スクリプトを使用することをお勧めします。スクリプトを使用すると、配置と管理で一貫性と予測可能性が確保されます。投資する価値は十分にあります。

配置の自動化

自動化の主要な領域の 1 つがソリューションのビルドと配置です。自動化を導入すると、開発チームによるテストや複数の環境への配置が容易になります。ビルドの自動化により、開発、テスト、ステージング、ベータ、および運用のすべての配置を、簡単かつ一貫した形で行うことができます。すべての環境に一貫した形で配置できれば、運用環境に配置されているものがテスト済みであることも保証されます。

デプロイメントに関連するスクリプト 、構成ファイル、およびメタデータを "コード" と考えてみてください。コードには、このようなアイテムを以下の場合にソース コントロールで管理する処理も含まれています。

  • ドキュメントの変更。

  • バージョン管理を許可する。

  • ロールベースのアクセス制御を提供する。

  • コンテンツを確実にバックアップする。

  • 単一の正しい情報源を提供する。

テスト ハーネスの確立と自動化

自動化できるもう 1 つの領域はテストです。テストの自動化は、配置の自動化と同様に、システムの回復力を確保し、それを長期的に維持するのに役立ちます。サービスのコードや使用方法は時間と共に変化するため、該当するすべてのテストが (機能レベルとスケール レベルの両方で) 行われている状態を維持することが重要です。

データのアーカイブと削除の自動化

見落とされがちな領域の 1 つがデータのアーカイブと削除です。データは、量も種類も、かつてないレベルで増加し続けています。使用しているデータベース テクノロジや必要なクエリの種類によっては、不要なデータがあると、システムの応答時間が低下したり、無駄にコストが増加したりする可能性があります。回復力プランにデータ ストアのレプリカが含まれる場合は、不要なデータをすべて削除すると、データのバックアップと復元などの管理アクティビティが迅速化されます。

コア機能に必要なデータ、コンプライアンスのために必要だがアーカイブできるデータ、および削除できる不要なデータに関連するソリューションの要件を特定します。

関連する製品やサービスの API を活用して、それらの要件の実装を自動化します。

回復力のあるアーキテクチャを作成する際には、障害ドメインとアップグレード ドメインの概念を理解することも重要です。

障害ドメイン

障害ドメインは、既知のハードウェア境界と、特定の種類の障害によって一連のコンピューターが影響を受ける可能性に基づいて、サービスの配置を制限します。障害ドメインは、同時に障害が発生する可能性がある一連のコンピューターとして定義されます。物理的特性によって定義されるのが一般的です (特定のラックのコンピューター、同じ電源を共有するコンピューターなど)。

アップグレード ドメイン

アップグレード ドメインは障害ドメインに似ています。アップグレード ドメインは、システムで同時に更新されるサービスの物理的なセットを定義します。特定のドメインの更新中もシステム全体で負荷が分散されてサービスの可用性が維持されるようにするには、クラウド プロバイダーのロード バランサーでアップグレード ドメインが認識されている必要があります。

アップグレードは次の場合に発生する可能性があります。

  • ハイパーバイザー レベル ("HostOS アップグレード")

  • オペレーティング システム レベル ("ゲスト OS アップグレード")

  • アプリケーションまたはサービスのアップグレードを環境にデプロイした結果として。

使用するクラウド プロバイダーとプラットフォーム サービスに応じて、障害ドメインとアップグレード ドメインが自動的に提供される場合もあれば、API で選択できる場合もあります。ファースト パーティまたはサード パーティのソリューションが必要になる場合もあります。

アップグレード中に障害ドメインが停止した場合の回復力

障害ドメインとアップグレード ドメインは異なりますが、重なり合うシナリオもあります。このシナリオでは、ハードウェアの障害によって仮想マシンがオフラインになるときに、同時にアップグレードが別の VM インスタンスで発生しています。この場合、2 つの VM はオフラインになります。サービスのデプロイメントに仮想マシンが 2 つだけ含まれる場合、サービスはオフラインになります。必要な SLA を達成するために必要なインスタンス数を評価するときは、この点を考慮してください。

多くの場合、クラウド プラットフォームには、リソースのグループについてアフィニティのレベルを特定する機能があります。このようなリソースは "アフィニティ グループ" または "アフィニティ セット" と呼ばれます。アフィニティ グループは、関連するリソースを共存させ、障害ドメインとアップグレード ドメインにわたってインスタンスを割り当てるうえで、基盤プラットフォームをサポートします。

オンプレミス ソリューションでは、可用性とスケーラビリティを確保するためによく冗長性が使用されます。可用性の観点から見た場合、冗長なデータ センターを使用すると、特定のデータ センターまたはデータ センターの一部でインフラストラクチャ障害が発生した場合にビジネスを継続できる可能性が高まります。

地理的に分散したコンシューマーを持つアプリケーションでは、トラフィック管理と冗長な実装により、ユーザーが (一般に待機時間の短い) ローカル リソースにルーティングされます。

noteメモ
データ回復力 (冗長性を含む) については、「データ回復力の方法の確立」というセクションで別に説明します。

冗長性とクラウド

オンプレミス環境では、重複するハードウェア、ソフトウェア、およびネットワークによって冗長性が実現されてきました。それらは、1 つの場所でクラスターに実装される場合もあれば、複数のデータ センターに分散される場合もあります。

クラウドのための戦略を検討する際には、冗長性の必要性を 3 つのベクトルにわたって正当化する必要があります。その 3 つのベクトルとは、クラウド プロバイダーの環境に配置されるコード、プロバイダー自体の冗長性、およびクラウドとオンプレミスの間の冗長性です。

配置の冗長性

使用するクラウド プロバイダーを選択したら、そのプロバイダー内の配置に関する冗長性戦略を確立する必要があります。

Platform as a Service (PaaS) に配置する場合は、問題の大半が基になるプラットフォームによって処理されますが、Infrastructure as a Service (IaaS) モデルではそうではありません。

  • データ センターに n 個のロールを配置する

    最も単純な形式の冗長性では、1 つのクラウド プロバイダーの複数のインスタンスにソリューションをデプロイします。複数のインスタンスにデプロイすることにより、1 つのノードのみをデプロイする場合に発生するダウンタイムを制限できます。

    多くの PaaS 環境では、コードをホストしている仮想マシンの状態が監視されており、異常が検出された仮想マシンを自動的に正常なノードに置き換えることができます。

  • 複数のデータ センターに配置する

    1 つのデータ センターに複数のノードを配置する方法にも利点はありますが、データ センター全体が使用できなくなる可能性を考慮に入れる必要もあります。よくあることではありませんが、自然災害や戦争が起こった場合、特定の地理的な場所でサービスが中断される可能性があります。

    SLA によっては、選択したクラウド プロバイダーの複数のデータ センターにソリューションを配置する方が適切な場合もあります。そのためにはいくつかの方法があります。それらを以下に示します。

    1. 複数のデータ センターの完全に冗長な配置

      1 つ目の方法は、複数のデータ センターの完全に冗長なソリューションとトラフィック管理プロバイダーの組み合わせです。この方法では、コンピューティング関連のコストが問題になります。データ センターの配置を追加するたびにコストが 100% ずつ増加します。

    2. フェールオーバーのためのセカンダリ データ センターの部分的な配置

      この方法では、小規模なセカンダリ データ センターに部分的な配置を行います。たとえば、標準構成のコンピューティング インスタンスが 12 個の場合、セカンダリ データ センターのデプロイメントに含まれるコンピューティング インスタンスを 6 個にします。

      この方法をトラフィック管理と組み合わせて使用すると、プライマリ データ センターのみに影響を与える問題が発生した場合に、サービスのレベルを下げてビジネスを継続できます。

      データ センター全体がオフラインになる回数は限られているため、この方法は、多くの場合、コンピューティングに対するコスト効果の高いアプローチとなります。セカンダリ データ センターに新しいインスタンスを簡単に追加できるプラットフォームでは特に有効です。

    3. バックアップ ノードを含む複数のデータ センターへの分割配置

      一部のワークロード (金融サービス業界のワークロードなど) では、固定された短い期間に大量のデータを処理する必要があります。このような状況では、短期間に大量の作業が行われるため、冗長性のコストが、その期間内に結果を出すために正当化されます。

      このような場合は、複数のデータ センターにコードを配置して、作業を分割して複数のノードで処理します。いずれかのデータ センターが使用できなくなった場合は、そのノードで処理されるはずだった作業をバックアップ ノードで処理します。

    4. それぞれの地域に適した規模の複数のデータ センターの配置

      この方法では、複数のデータ センターに存在する冗長な配置が使用されますが、それらの配置は、それぞれの地域のユーザーに合わせて適切な規模に調整されます。

プロバイダーの冗長性

データ センター中心の冗長性も有効ですが、SLA の対象は、データ センター レベルではなくサービス レベルです。現在の多くの商用サービスは、"一部の" 運用環境に新しいバージョンをデプロイして、運用環境でコードを検証するでしょう。一方、プロバイダーが提供するサービスが、複数またはすべてのデータ センターで利用できなくなる可能性もあります。

ソリューションの SLA によっては、プロバイダーの冗長性を組み込むことが望ましい場合もあります。そのためには、複数のクラウド プラットフォームで使用できるクラウド対応製品またはクラウド サービスを見つける必要があります。たとえば、Microsoft SQL Server は、ほとんどのベンダーの IaaS サービス内の仮想マシンに配置できます。

クラウド サービスの場合は、問題がより困難になります。というのも、コンピューティング、ストレージ、キューなどのコア サービスでさえ、標準のインターフェイスがないからです。クラウド サービスでプロバイダーの冗長性が必要な場合は、通常は抽象化レイヤーを使用する必要があります。ただし、抽象化レイヤーは、ソリューションに必要な機能を備えていたとしても、基になるサービスほど技術革新の速度が速くないため、プロバイダーによって提供される新機能をすぐには採用できなくなる可能性があります。

冗長なプロバイダー サービスが正当化される場合には複数のレベルが考えられます (アプリケーション全体、ワークロード、またはワークロードの特定の側面)。適切なレベルで、コンピューティング、データ、およびプラットフォームの各サービスのニーズを評価して、本当に冗長性が必要なのは何か、サービス レベルを下げることによって対処できるのは何かを特定します。

オンプレミスの冗長性

クラウド プロバイダーに依存する方法はコスト面でメリットがありますが、コンプライアンスやビジネス継続性のためにオンプレミスの冗長性が必要になる場合もあります。

ソリューションの SLA によっては、オンプレミスの冗長性を組み込むことが望ましい場合もあります。そのためには、複数の種類のクラウドで使用できるプライベート クラウド対応製品またはクラウド サービスを見つける必要があります。プロバイダーの冗長性の場合と同様、Microsoft SQL Server は、オンプレミスにも IaaS サービスにも配置できる製品の好例となります。

クラウド サービスの場合は、対応するインターフェイスや機能を持つ同等のサービスがオンプレミスに存在しないことが多いため、問題がより困難になります。

冗長なプロバイダー サービスがオンプレミスで必要とされる場合には複数のレベルが考えられます (アプリケーション全体、ワークロード、またはワークロードの特定の側面)。適切なレベルで、コンピューティング、データ、およびプラットフォームの各サービスのニーズを評価して、本当に冗長性が必要なのは何か、サービス レベルを下げることによって対処できるのは何かを特定します。

冗長性の構成方法

冗長性の構成方法を特定する際には、クラウド以前の分類を適用できます。ソリューションで使用するサービスの種類に応じて、この機能の一部が基になるプラットフォームで自動的に処理される場合もあれば、Windows Fabric のようなテクノロジによってこの機能が処理される場合もあります。

  1. アクティブ/アクティブ — 障害が発生したノードに割り当てられるはずだったトラフィックが、既存のノードに割り当てられるか、残っているノードの間で分散されます。通常は、それらのノードのソフトウェア構成が均一な場合にのみ可能です。

  2. アクティブ/パッシブ — 関連付けられているプライマリ ノードで障害が発生した場合にのみオンラインになる完全に冗長なインスタンスをノードごとに用意します。この構成は通常、追加のハードウェアを最も多く必要とします。

  3. N+1 — いずれかのノードで障害が発生した場合にオンラインになってそのロールを引き継ぐ 1 つの追加ノードを用意します。各プライマリ ノードのソフトウェア構成が均一でない場合は、その追加ノードですべてのプライマリ ノードのロールを引き継ぐことができる必要があります。通常は、複数のサービスが同時に実行されているクラスターを指します (サービスが 1 つしかない場合はアクティブ/パッシブになります)。

  4. N+M — 1 つのクラスターで多数のサービスを管理している場合、専用のフェールオーバー ノードを 1 つ用意するだけでは十分な冗長性が確保されないことがあります。そのような場合は、複数の (More than one) スタンバイ サーバーを追加して使用できます。スタンバイ サーバーの数は、コストと信頼性の要件のバランスを考慮して決定します。

  5. N 対 1 — フェールオーバー スタンバイ ノードを、元のノードが復元されるかオンラインに復帰するまでの間、一時的にアクティブ ノードにすることができます。その後は、高可用性を維持するために、サービスやインスタンスを元のノードにフェールバックする必要があります。

  6. N 対 N — アクティブ/アクティブと N+M の組み合わせで、障害が発生したノードのサービス、インスタンス、または接続が、残っているアクティブ ノードの間で再分配されます。これにより、(アクティブ/アクティブと同じように) "スタンバイ" ノードを用意する必要はなくなりますが、すべてのアクティブ ノードに追加の容量が必要になります。

トラフィックを常に地理的に分散する場合も、ビジネス継続性のシナリオを満たすために別のデータ センターにルーティングする場合も、ソリューションへの要求が適切なインスタンスにルーティングされるようにするためにはトラフィック管理機能が重要になります。

トラフィック管理サービスへの依存によって単一障害点が導入されることに注意する必要があります。アプリケーションのプライマリ トラフィック管理サービスの SLA を調査して、現在の要件によって代替トラフィック管理機能が正当化されるかどうかを確認することが重要です。

多くの大規模クラウド アプリケーションでは、Web 層のパーティション分割は適切に行われていますが、クラウドのデータ層のスケーリングはそれほど適切に行われていません。接続されるデバイスの多様化に伴って、生成および照会されるデータはかつてないレベルで増加しています。たとえば、現在では、1 日に 500,000 人の新規ユーザーをサポートするニーズは驚くものではなくなっています。

そのデータの保存、クエリ、管理など、複数の次元にまたがるパーティション分割戦略を確立することがきわめて重要です。

分解とパーティション分割

テクノロジにはそれぞれ利点とトレードオフがあるため、個々のワークロードに最適なテクノロジを利用するのが一般的です。

ソリューションをワークロードに分解すると、個々のワークロードに最適なデータ テクノロジを選択できるようになります。たとえば、Web サイトで個人用コンテンツにテーブル ストレージを使用して、応答エクスペリエンスでユーザー レベルのパーティションを活用することができます。それらのテーブル行を、レポートと分析のために定期的にリレーショナル データベースで集計することもできます。

パーティション分割戦略は、選択するテクノロジによって変わることがあります (変わるのが一般的です)。

戦略を定義する際には、戦略の変更や並行する戦略が必要になる可能性がある外れ値を特定することも重要です。たとえば、ソーシャル ネットワーキング サイトを開発した場合、通常のユーザーの接続数は 500 でも、有名人の接続数は 5,000,000 になる可能性があります。

1 億人レベルのユーザー数が見込まれるサイトで、有名人が 50,000 人未満の場合、中心のパーティション分割戦略は一般的なユーザーに合わせて最適化します。有名人は別の方法で管理します。多数のユーザーを 1 つのパーティションにグループ化し、有名人には個別のパーティションを割り当てることができます。

3 つの V を理解する

パーティション分割戦略を正しく作成するためには、まずそれを理解する必要があります。

Gartner によって広められた 3 つの V は、データの 3 つの側面に着目しています。この 3 つの観点からデータを理解すると、パーティション分割戦略に関する決定を十分な情報に基づいて行うことができるようになります。

  • Volume

    量 (Volume) は、データのサイズを指します。データの量は、パーティション分割戦略にきわめて現実的な影響を与えます。特定のデータ テクノロジの量の制限によって、サイズの制限や、大量のデータのクエリ速度などのために、データをパーティション分割せざるを得なくなる場合があります。

  • 速度 (Velocity)

    速度 (Velocity) は、データが増加する速度を指します。増加の速度が遅いデータ ストアと、1 日に 500,000 人の新規ユーザーに対応する必要があるデータ ストアでは、別のパーティション分割戦略が必要になるのが一般的です。

  • 多様性 (Variety)

    多様性 (Variety) は、ワークロードに関連するデータの種類を指します。リレーショナル データ、キーと値のペア、ソーシャル メディアのプロファイル、画像、オーディオ ファイル、ビデオなど、データの種類を理解することが重要です。これは、適切なデータ テクノロジを選択するためにも、パーティション分割戦略に関する決定を十分な情報に基づいて行うためにも必要です。

行方向のパーティション分割

データのパーティション分割の方法として最も一般的なのは、おそらく行方向のパーティション分割です。行方向のパーティション分割では、データ ストアを複数のシャードにパーティション分割するための条件を決定します。各シャードに完全なスキーマが含まれ、指定した条件に基づいてデータが適切なシャードに配置されます。

行方向のパーティション分割は、データの種類と使用方法に基づいてさまざまな方法で行うことができます。たとえば、データを顧客の姓に基づいてパーティション分割したり、日付に基づいてパーティション分割したりできます (時間、日、週、月などの間隔でパーティション分割するなど)。

図 5: 姓による行方向のパーティション分割の例

列方向のパーティション分割

もう 1 つの方法は、列方向のパーティション分割です。この方法では、さまざまなデータ ストアへのデータの配置が最適化されます。それらのデータ ストアは、多くの場合、各種のデータに関連付けられています。たとえば、図 5 の例では、顧客に関するメタデータ、サムネイル、および写真が、それぞれ異なるデータ ストアに配置されます。

列方向のパーティション分割によってデータの格納と配信が最適化される場合もあります。たとえば、図 5 の例で顧客がめったに写真を表示しない場合、レコードが要求されるたびに 3 MB の写真データを返すと、従量課金制モデルを使用している場合に無駄なコストが発生します。

図 6: 列方向のパーティション分割の例

ハイブリッド パーティション分割

多くの場合は、ハイブリッド パーティション分割戦略を確立するのが適切な方法になります。この方法では、行方向と列方向の両方のパーティション分割を 1 つのソリューションで活用できます。

図 6 は、ハイブリッド パーティション分割の例を示しています。ここでは、先ほど説明した列方向のパーティション分割が、顧客のメタデータの行方向のパーティション分割を活用できるように強化されています。

図 7: 行方向のパーティション分割の例

クラウド コンピューティングの中心にあるのはネットワークです。ネットワークは、デバイスがサービスに接続したりサービスが他のサービスに接続したりするためのファブリック (バックボーン) を提供するため、きわめて重要です。すべてのフェールセーフ アプリケーションで 3 つのネットワーク境界を考慮に入れる必要があります。

それらのネットワーク境界の詳細を以下に示します。ここでは、コンテキストを提供するための例として Azure を使用しています。

  1. ロールの境界: 従来は層と呼ばれていました。たとえば、Web 層やビジネス ロジック層がこれに当たります。Azure では、最新の分散アプリケーションの多層的な性質をインフラストラクチャ レベルでサポートするために、ロールがコア デザインの一部として正式に導入されています。同じサービスに属するロール インスタンスが 1 つのネットワーク環境のスコープ内でホストされ、1 つのファブリック コントローラーによって管理されることが保証されます。

  2. サービスの境界: 他のサービスによって提供される機能に対する依存関係を表します。たとえば、リレーショナル データベース アクセスの場合の SQL 環境や、pub/sub メッセージング サポートの場合の Service Bus がこれに当たります。 Azure では、サービスの境界はネットワークによって強制的に適用されます。 サービスの依存関係が同じネットワーク環境やファブリック コントローラー環境に含まれる保証はありません。同じ環境に含まれる場合もありますが、別のファブリック コントローラーによって管理されている別のネットワークにあることを前提にしてアプリケーションを設計する必要があります。


    図 8

  3. エンドポイントの境界: エンドポイントの境界は、クラウドの外部にあります。これには、 サービスを使用するためにクラウドに接続するすべてのコンシューマー エンドポイント (通常はデバイス) が含まれます。ネットワークは変化しやすく信頼できないため、この部分の設計では特別の配慮が必要です。クラウド環境の境界内にあるロールの境界とサービスの境界とは違って、外部の依存関係では、一定の信頼性と帯域幅を想定することはできません。そのため、デバイスがサービス (データと対話) を使用できるかどうかについて特別な注意を払う必要があります。

    ネットワークには待機時間が付きものです。ネットワークの特定の場所から別の場所に情報を渡すときには待機時間が発生します。ユーザーと依存サービスや依存ロールの両方に優れたエクスペリエンスを提供するためには、アプリケーションのアーキテクチャと設計で待機時間をできるだけ減らして、避けられない待機時間を明示的に管理する必要があります。待機時間を減らすための最も一般的な方法は、ネットワークを含むサービス呼び出しを避けることです。待機時間を減らして応答性を高めるには、データやサービスにローカルでアクセスするのが有効です。ローカルのデータやサービスを使用することは、障害対策にもなります。ユーザーやアプリケーションの要求をローカル環境で処理できれば、他のロールやサービスと対話する必要がなくなるため、障害点で依存コンポーネントを使用できなくなる可能性を排除できます。

キャッシュ

キャッシュとは、データをローカルに保存できない場合にデータ アクセスを高速化するための手法です。キャッシュは現在、ほとんどの大規模クラウド サービスで活用されています。Wikipedia の定義にもあるように、キャッシュは、アプリケーションによって繰り返し要求されるデータをローカルでアクセスできるようにします。キャッシュは次の 2 つの条件に依存しています。

  • ユーザーおよび依存アプリケーションによるデータの使用パターンが主に読み取り専用であること。電子商取引 Web サイトなど、一部のシナリオでは、ユーザーによる対話型操作の 95% を読み取り専用アクセス (閲覧とも呼ばれます) が占めることもあります。

  • キャッシュに最適な安定性と特異性を備えたデータの識別をサポートするセマンティック情報の追加レイヤーがアプリケーションの情報モデルによって提供されていること。

デバイス キャッシュ

デバイス キャッシュは、フェールセーフ イニシアチブでは焦点になりませんが、デバイス + サービス アプリケーションの使いやすさと堅牢性を向上させるための最も効果的な方法の 1 つです。デバイスまたはクライアント層でキャッシュ サービスを提供するには、すべての標準ブラウザーに実装されているネイティブ キャッシュ機能を提供する HTML5 仕様から SQL Server Compact Edition などのローカル データベース インスタンスまで、さまざまな方法があります。

分散キャッシュ

分散キャッシュの機能は強力ですが、その目的は、リレーショナル データベースなどの永続データ ストアを置き換えることではなく、分散アプリケーションの応答性を向上させることにあります。分散アプリケーションは、本質的にネットワーク中心であるため、待機時間の影響を受けやすくなります。キャッシュを導入すると、永続データ ストアへのトラフィックが減少して、データ サービスとの対話が最小限に抑えられるという効果もあります。

  • キャッシュに最適化された情報モデル

    noteメモ
    このセクションの内容の多くは、サービス指向アーキテクチャのデータに関する Pat Helland の優れた記事に基づいています。その記事は、Microsoft Developer Network で読むことができます。

    キャッシュされたデータは、本質的に古いデータです (最新のデータであるとは限りません)。キャッシュされたデータの好例となるのが、まったく別の分野ではありますが、家庭に送付される製品カタログです。製品カタログのデータは、カタログが制作された時点では最新のデータであっても、カタログが印刷されている間に古くなります。これは、カタログの制作に伴う時間の本質的な問題です。このように、キャッシュされたデータは古くなるため、キャッシュの設計では、安定性と特異性に関するデータの属性が重要になります。

    • 安定性 - 時間と空間に左右されずに明確に解釈されるデータ。これは、多くの場合、変更されないデータ値を指します。たとえば、ほとんどの企業では、顧客 ID や SKU 番号は再利用されません。安定したデータを作成するには、既存のデータに有効期限を追加する方法もあります。この場合も、製品カタログがよい例になります。一般に、カタログからの注文が受け入れられるのは 1 つ前の号までです。したがって、年に 4 回発行されるカタログの場合、製品カタログのデータが安定している期間は 6 か月になります。その間は、そのデータを発注や受注などの情報処理に使用できます。

      安定したデータは、通常、マスターまたは参照データと呼ばれます。フェールセーフ イニシアチブでは、参照データという用語を使用します。マスター データより参照データの方が意味が広いからです。マスター データという用語は、多くの企業で、非常に特殊な意味で使われています。

    • 特異性 - 同時に更新されない (または同時に更新されることが少ない) 一意に識別可能なインスタンスとの関連によって分離できるデータ。買い物かごの例で見てみましょう。買い物かごが更新されるのは明らかですが、更新の頻度は比較的低く、ストレージや処理から完全に分離することができます。

      こうした分離可能なデータを、アクティビティ データまたはセッション データと呼びます。

      この 2 つの属性を考慮に入れると、次のようなスキーマが見えてきます。


      図 9

  • 情報モデル

    情報モデルというと、アプリケーションの設計者や開発者の多くはオブジェクト モデルやエンティティ モデルを思い浮かべます。オブジェクト モデルやエンティティ モデルは情報モデルの技術と知識に含まれますが、フェールセーフ アプリケーションの情報モデルに含まれるのはそれだけではありません。

    ここでは、今日の分散された世界に必要とされる思考プロセスについて説明するにあたって、まず安定性と特異性に注目しました。もう 1 つの重要な要素は、ユーザーまたはデバイスとの対話や、実装する予定のビジネス プロセスの中で、データがどのように使用されるのかを理解することです。さまざまな形で情報デザインにオブジェクト指向モデリングを組み込む必要があります。

    • 情報の隠蔽 - ユーザーやビジネス プロセスにとって有用でない情報を隠蔽する (アクセスを提供しない) ことは、リソースの競合や、リレーショナル データベースで保存および管理されている共有データの競合を回避するための最善の方法の 1 つです。

      同時実行性を向上させるために情報の隠蔽を活用しているすばらしい例を、一般的な ERP システムと Amazon.com の在庫管理方法との違いに見ることができます。一般的な ERP システムの実装では、在庫テーブルは最も混雑している (ホットな) テーブルの 1 つです (リレーショナル データベースの実装の場合)。ERP アプリケーションは、通常、ユーザーがトランザクションを終了するまで在庫をロックします。これにより、ビジネス トランザクションが開始された時点の正確な在庫数がアプリケーションに提供されます。SAP などの一部のシステムでは、データベース ロックは回避されますが、エンキュー システムでアプリケーション ロックが取得されます。 この混雑を解消するために、オプティミスティック同時実行制御、ダーティ リードなど、 実に多くの手法がデータベース レイヤーで編み出されましたが、どの手法にもなんらかの副作用があります。実際にテーブルをロックする必要があるシナリオもありますが、そのようなシナリオはごくまれです。

      この問題をはるかに単純な方法で解決したのが Amazon.com です。 Amazon.com では、ユーザーが受け入れるか拒否するかを選択できるサービス レベル目標 (SLO) を提供しています。この SLO は、ほとんどの場合、"通常 N 時間以内にお届けします" という形で表現されています。ユーザーには、書籍などの商品の実際の在庫数はわかりませんが、その商品が入手可能かどうかはわかります。この場合、データベースをロックする必要はありません。実際、データベースに接続する必要もありません。SLO を満たすことができなかった場合は、購入者に謝罪文が (通常は電子メールで) 送られて、更新された SLO が提供されます。

    • 代替可能なリソース: "fungible (代替可能な)" という単語は、辞書では "(特に商品が) 同じような性質または種類の別のものと全体または一部を自由に交換できる" と定義されています。この概念の中心にあるのは、(先ほどと同じように) 共有データにアクセスする際の競合を減らすために、情報モデルを使用して、ユーザーがデータの特定のインスタンスではなく代替可能なインスタンスを操作できるようにするという考え方です。たとえば、ホテルの部屋を予約する場合がこれに当たります。ホテルの部屋を予約する際には、ベッドの数、オーシャン ビュー、禁煙など、細かな指定を行うことができますが、特定の部屋 (123 号室など) を指定する必要はありません。このようなモデルを使用すると、代替可能なデータのプールに関する情報をキャッシュし、そのプールに対してビジネス プロセスを実行して、チェックイン プロセスの完了後にそのプールから特定の部屋を割り当てることができます。チェックイン プロセスが開始されたら特定の部屋をプールから削除するハイブリッド モデルも可能です。

  • キャッシュの管理

    キャッシュの戦略では、適切なときに適切な情報をキャッシュすることが重要です。 キャッシュを読み込むにはさまざまな手法があります。 その概要については、「分散環境のキャッシュ処理」を参照してください。以降では、分散キャッシュに依存するフェールセーフ アプリケーションの設計に関するいくつかの考慮事項について概説します。

    • 参照データ - ホスティング環境 (ファブリック コントローラーまたはデータ センター) で災害が発生した場合、アプリケーションは別の環境に移動されます。アプリケーションのインスタンスが既にアクティブになっている場合は (アクティブ - アクティブの設計)、キャッシュに大量の関連情報 (特に参照データ) が既に含まれている可能性が高いですが、アプリケーションの新しいインスタンスを作成する場合は、キャッシュ ノードに情報は含まれていません。目的のデータがキャッシュに見つからない場合は自動的に読み込まれるようにアプリケーションを設計する必要があります。新しいインスタンスを作成する場合は、参照データをキャッシュに一括読み込みする開始ルーチンを使用することもできます。ユーザーは、クラウド インフラストラクチャによってアプリケーションが提供されるとすぐに操作を開始する可能性があるため、この 2 つを組み合わせることをお勧めします。

    • アクティビティ データ - 参照データについて説明した基本的な手法は、アクティビティ データにも適用できます。ただし、アクティビティ データには固有の注意点があります。参照データは、アプリケーションの任意の永続ストアで使用可能と見なされますが、頻繁に変更されないため、同期が問題になることはまずありません (考慮に入れておく必要はあります)。一方、アクティビティ データは、分離された状態で更新され、更新の頻度も高くはありませんが、参照データよりは変化しやすくなります。分散キャッシュでアクティビティ データを頻繁に保存して、アプリケーションのさまざまなインスタンスの間でレプリケートするのが理想的です。データの保存と同期の間隔は、短すぎると競合が発生し、長すぎるとデータの損失が発生する可能性が高くなるので注意してください。

プラットフォームとアプリケーションの関係 (特に責任の範囲) は、よく誤解されています。特に問題になるのが、データに関する領域です。

Azure などのプラットフォームには、データの複数のコピーを保存する責任がありますが (一部のサービスでは地理的冗長性が含まれる場合もあります)、保存されているデータを操作するのは、アプリケーション、ワークロード、およびそのコンポーネント サービスです。アプリケーションの操作によってアプリケーション データが破損した場合も、プラットフォームによってデータの複数のコピーが保存されています。

障害モードと障害点を確立する際には、データが破損する可能性があるアプリケーションの領域を特定することが重要です。障害が発生する場所はさまざまですが (無効なコード、サービスへの有害なメッセージなど)、関連する障害モードと障害点を特定しておくことが重要です。

アプリケーション レベルの修復

  • べき等

    接続先のサービスでは、主要な前提として、100% の可用性はあり得ないため、再試行ロジックによる一時的なエラー処理が主要な実装方法となります。再試行ロジックを実装する場合、同じメッセージが複数回送信されたり、メッセージが誤った順序で送信されたりする可能性があります。

    操作がべき等になるように設計して、同じメッセージが複数回送信されても、データ ストアで予期しない結果が生じたり、データ ストアが汚染されたりしないようにする必要があります。

    たとえば、すべての要求のデータを挿入すると、サービス操作が複数回呼び出された場合に複数のレコードが追加される可能性があります。それを防ぐには、そのコードを、レコードが存在する場合には更新を実行し、存在しない場合には挿入を実行する、インテリジェントな "upsert" として実装します。タイムスタンプまたはグローバル識別子を使用して、新しいメッセージと以前に処理されたメッセージを識別し、新しい方のメッセージのみをデータベースに挿入します。メッセージが以前に受信したメッセージより新しかった場合は、既存のレコードを更新します。

  • ワークロード アクティビティと補正の動作

    べき等に加えて、補正の動作の概念も考慮に入れる必要があります。

    現実の世界では、たとえば、クレジット カードで支払いが行われた製品を返品する場合に補正の動作が使用されます。このシナリオでは、小売店を訪れた客がクレジット カードで製品を購入します。料金は、そのクレジット カードの口座から引き落とされます。その後に製品が返品された場合、返品ポリシーに準拠していれば、クレジット カードの口座に購入金額が返金されます。

    接続されるシステムが増加し続けており、複合サービスも出現している現在、補正の動作を処理する方法を理解することの重要性が高まっています。

    トランサグションの概念は、基幹業務アプリケーションの開発者にとって新しいものではありませんが、ローカル データ テクノロジや関連コード ライブラリによって公開されるトランザクション機能との関連で捉えられているのが一般的です。この概念をクラウドの観点から見る際には、分散サービスのオーケストレーションに関する問題を新たに考慮に入れる必要があります。

    サービス オーケストレーションは、複数の分散システムにまたがることがあるほか、実行時間が長い場合や、ステートフルな場合もあります。オーケストレーション自体が同期的であることはほとんどなく、ビジネス シナリオに基づいて、秒単位から年単位にわたって実行される可能性があります。

    たとえば、同じワークロード アクティビティで 25 の組織を結び付けることのできるサプライ チェーンのシナリオでは、1 つ以上のサービス オーケストレーションで 25 以上のシステムが相互接続される可能性があります。

    アクティビティが成功した場合、そのことを 25 のシステムに通知する必要があります。参加システムは、アクティビティの各接続ポイントで、他のシステムから受信するメッセージの相関 ID を指定できます。アクティビティの種類に応じて、その相関 ID の受信によってトランザクションの完了が通知される場合もあれば、25 の参加システムの対話がすべて完了してからすべてのシステムに確認メッセージが送信される場合もあります (1 つのサービスから直接送信される場合もあれば、各システムのオーケストレーション対話ポイントを介して送信される場合もあります)。

    複合アクティビティや分散アクティビティの失敗を処理するには、一意の識別子によって特定のトランザクションの取り消し要求を受信するためのサービス インターフェイスとサービス操作を各サービスで公開し、サービスの背後にあるワークフローでそのアクティビティの取り消しを補正します。これらのワークフローは、自動プロシージャにするのが理想的ですが、手動で修正するために組織の特定の人物にルーティングするだけでもかまいません。

バックアップ

データの破損を防ぐためのアプリケーション レベルの修復に加えて、アプリケーションの修復が成功しなかった場合のために用意される修復もあります。

データ ストア (全体または一部) のバックアップ コピーの作成と復元の両方のプロセスを回復力プランに含める必要があります。データのバックアップと復元は新しい概念ではありませんが、クラウドでは新たな注意点があります。

バックアップ方法を定義する際には、データの復元に関するビジネス要件を意識する必要があります。災害のシナリオによってデータ ストアが破損したりオフラインになったりした場合に復元する必要があるデータの種類、量、およびビジネスで必要とされる速度を把握しておく必要があります。この情報は、全体的な可用性プランに影響し、バックアップと復元のプランを決定付けます。

  • リレーショナル データベース

    リレーショナル データベースのバックアップは新しいことではありません。多くの組織が、災害復旧やコンプライアンスのニーズを満たすために、データのバックアップのためのツール、方法、およびプロセスを用意しています。ほとんどの場合は、従来のバックアップ ツール、方法、およびプロセスをほぼそのまま使用できます。新しい方法を導入したり、従来の方法に手を加えたりすることもできます (データをバックアップしてクラウドベースの BLOB ストレージにコピーを保存するなど)。

    既存のプロセスやツールを評価する際には、そのクラウドベース ソリューションに適しているのはどの方法かを評価することが重要です。多くの場合、さまざまな障害モードを修復するために次の 1 つ以上の方法が適用されます。

    1. 合計バックアップ - データ ストア全体のバックアップです。データの量および増加速度に応じたスケジュールに基づいて行う必要があります。合計バックアップは、SLA を満たすために必要とされる完全なデータセットです。この種のバックアップのためのメカニズムは、データベースやデータベース サービスのプロバイダーか、そのベンダー エコシステムによって提供されるのが一般的です。

    2. ポイントインタイム - ポイントインタイム バックアップは、特定の時点のデータベースの状態を反映するバックアップです。たとえば、午後に発生したエラーによってデータ ストアが破損した場合、正午に行われたポイントインタイム バックアップを復元することによってビジネスへの影響を最小限に抑えることができます。

      個人の接続レベルが高まり続けており、いつでもサービスを利用できることが期待されているため、直近の時点にすばやく復元できる機能が不可欠となっています。

    3. 同期 - 従来のバックアップに加えて、データの同期も使用できます。たとえば、データを複数のデータ センターに保存して、それらのデータ センターの間で定期的に同期させることができます。この方法は、通常の可用性プランの一部としてトラフィック管理を利用するソリューションのデータの同期のためだけでなく、ビジネス継続性の問題が発生した場合にセカンダリ データ センターにフェールオーバーするために使用することもできます。

      サービスの利用者が常時接続している状況では、多くのシナリオでますますダウンタイムが許容されなくなるため、同期を利用することをお勧めします。

      同期には次のパターンがあります。

      - 特定のクラウド プロバイダーのデータ センター間の同期

      - 複数のクラウド プロバイダーのデータ センター間の同期

      - オンプレミスのデータ センターから特定のクラウド プロバイダーのデータ センターへの同期

      - データ センターからデバイスへの同期 (コンシューマー固有のデータ スライス)

  • 共有リレーショナル データベース

    クラウドへの移行は、多くの場合、多数のユーザーや大量のトラフィックを含むシナリオ (モバイル アプリケーションやソーシャル アプリケーションに関連するものなど) に対応するニーズによって推進されます。これらのシナリオでは、通常、アプリケーション パターンに、単一のデータベース モデルから多数のデータベース シャードへの移行が含まれます。それらのデータベース シャードは、全体的なデータセットの一部を含み、大規模な契約に最適化されています。最近 Azure 上に構築されたあるソーシャル ネットワーキング プロジェクトは、開始時のデータベース シャードの数が 400 に上ります。

    各シャードはスタンドアロン データベースであるため、アーキテクチャと管理で、個々のシャードと、すべてのシャードを含む完全なデータセットの両方について、合計バックアップ、ポイントインタイム バックアップ、およびバックアップの復元を簡単に行えるようにする必要があります。

  • NoSQL データ ストア

    リレーショナル データ ストアだけでなく、NoSQL ("Not only SQL") データ ストアのバックアップ ポリシーについても検討する必要があります。主要なクラウド プロバイダーによって提供されている最も一般的な形式の NoSQL データベースは、一般にテーブル ストアと呼ばれる、可用性の高いキーと値のペアの形式のストアです。

    NoSQL ストアは、高い可用性を備えている場合があります。場合によっては、特定のデータ センターで重大なエラーが発生した場合に損失を防ぐための地理的冗長性を備えていることもあります。しかし、通常は、アプリケーションで誤ってコンテンツを上書きしたり削除したりした場合の保護は提供されません。アプリケーション エラーやユーザー エラーはプラットフォーム サービス (BLOB ストレージなど) によって自動的に処理されないため、バックアップ方法を評価する必要があります。

    リレーショナル データベースとは違って、多くの NoSQL ストアには、バックアップを実行するための確立されたツールは用意されていません。アーキテクチャによる方法としては、レプリカ NoSQL ストアにデータの複製コピーを作成し、レプリカ ストアに配置されたソース ストアの行をなんらかの参照テーブルによって特定するのが一般的です。データを復元するには、同じテーブルを使用して、復元に使用できるレプリカ ストアのコンテンツをテーブルからの読み取りによって特定します。

    このレプリカは、ビジネス継続性の問題に応じて、同じクラウド プロバイダー、同じデータ センター、同じ No SQL データ ストアなどに配置することも、別のクラウド プロバイダー、別のデータ センター、別の NoSQL データ ストアなどに配置することもできます。配置する場所は、ワークロード サービスの SLA の目標や、関連する法規制遵守の考慮事項によって大きく左右されます。

    この決定を行う際には、コスト (特にデータの受信と送信に関連するコスト) を考慮に入れる必要があります。データ センター内のデータの移動や環境へのデータの送信を無料にしているクラウド プロバイダーはあっても、環境からのデータの送信を無料にしているクラウド プロバイダーはありません。そのため、セカンダリ クラウド プラットフォーム プロバイダーにデータを移動する場合、規模が大きくなると多大なコストが発生する可能性があります。

    noteメモ
    参照テーブルは潜在的な障害点になるため、回復力プランの一部として参照テーブルのレプリカについて検討する必要があります。

  • BLOB ストレージ

    リレーショナル データ ストアや NoSQL データ ストアと同様に、BLOB ストレージ サービスに実装されている可用性機能によってバックアップ ポリシーの実装を検討する必要がなくなると誤解されていることがよくあります。

    BLOB ストレージも地理的冗長性を備えている場合がありますが、既に説明したように、これはアプリケーション エラーに対する保護にはなりません。アプリケーション エラーやユーザー エラーはプラットフォーム サービス (BLOB ストレージなど) によって自動的に処理されないため、バックアップ方法を評価する必要があります。

    バックアップ方法には、NoSQL ストアとほぼ同じものを使用できます。BLOB はサイズが大きくなる可能性があるため、データの移動のコストと時間がバックアップと復元の方法の重要な要素になります。

  • バックアップの復元

    バックアップ ポリシーを確立して忠実に従っていたのにデータの復元のテストを行っていなかった組織の訓話を耳にしたことがある方も多いでしょう。その運命の日、実際に災害が発生してデータベースのバックアップを復元しようとしたところ、バックアップの構成が間違っていて、何年もの間オフサイトに送り続けたテープに必要な情報が含まれていないことが判明しました。

    使用するバックアップ プロセスに関係なく、テストを確立して、データを正しく復元できることと、復元が適切な時間内に行われてビジネスへの影響が最小限に抑えられることを確認する必要があります。

コンテンツ配信ネットワーク (CDN) は、頻繁に要求されるファイルの可用性とユーザー エクスペリエンスを強化するためによく使用されます。CDN のコンテンツは、初めて使用されたときにローカル ノードにコピーされます。以降の要求は、ローカル ノードで処理されます。指定した期間が過ぎると、コピーされたコンテンツが期限切れになります。期限切れになったコンテンツは、次回の要求時に再びローカル ノードにコピーする必要があります。

CDN を使用すると、さまざまな利点がある一方で、依存関係が追加されます。したがって、他の依存関係と同様に、サービス エラーの修復について事前に検討する必要があります。

CDN の適切な使用方法

CDN を使用すればあらゆる問題を最低限のコストで解決できると誤解されていることがよくあります。たとえば、あるお客様は、CDN が電子書籍のオンライン ストアのための適切なソリューションになると確信していましたが、実際はそうではありませんでした。これはなぜでしょうか。カタログに含まれる百万タイトルの書籍のうち、頻繁に要求されるタイトル ("ヒット") はごく一部で、その他のタイトルはいつ要求されるかほとんど予測できません。頻繁に要求されるタイトルでは、初めて要求されたときにローカル ノードにコピーすることにより、コスト効果の高いローカル スケールと快適なユーザー エクスペリエンスが実現されますが、その他のタイトルでは、ほぼすべての要求で 2 回コピーが行われることになります (ローカル ノードへのコピーと顧客へのコピー)。めったに要求されないコンテンツは、ローカルにコピーされてもすぐに期限切れになってしまうからです。この例は、CDN を不適切に使用すると、当初の意図とは逆に、低速でコストの高いソリューションになることを示しています。

多くの場合、ソリューションの操作の計画は、ライフサイクルのかなり後の段階にならないと行われません。真に回復力のあるアプリケーションを作成するには、操作のための設計を行う必要があります。操作のための設計の主要なアクティビティには、通常、正常性モデルの確立、遠隔測定情報のキャプチャ、状態監視サービスおよびワークフローの組み込み、オペレーターと開発者のためのデータの準備などが含まれます。

開発チームは、アプリケーションの "正常性" を見落としがちであり、時には完全に無視します。 その結果、"稼働中" または "停止" という 2 つの既知の状態でサービスの運用が開始されることがよくあります。回復力のあるサービスを設計する際には、アプリケーションの正常性条件、正常性低下状態、エラー、および正常性の依存関係を定義する正常性モデルを作成する必要があります。

障害モードと障害点の概要を示す正常性モデルを事前に作成するためには、開発者がアプリケーションの設計フェーズで "what-if" シナリオを特定および調査する必要があります。正常性モデルを操作可能にするには、サービスの正常性を伝達できるようにする必要があります。その情報をプログラムでブロードキャストするための方法、その正常性状態をインタラクティブに照会するためのインターフェイス、管理者がアプリケーションの正常性をリアルタイムで監視できるメカニズム (または既存のメカニズムへのフック)、およびアプリケーションを正常な状態に戻すための "薬" を管理者が (必要に応じて) 提供できるメカニズムを用意する必要があります。

特性の定義

特定のサービスまたはアプリケーションについて診断を行い、少なくとも 3 つの正常性のカテゴリ (正常、正常性低下、および異常) を示すデータ ポイントと値の範囲を特定する必要があります。この情報は、サービスの自己修復の自動化に使用できます。

インターフェイスの定義

正常性状態を定義したら、正常性に関連するインターフェイスを公開する必要があります。それらのインターフェイスで以下のカテゴリの操作を提供します。

  • サブスクライブしているパートナー サービスに正常性状態を送信する

    サブスクライブしているパートナー サービスに正常性の情報を送信する必要があります。送信する正常性状態は、正常性の概要と基本的な診断のみを含む簡潔なものにする必要があります。

    パートナー サービスが正常性メッセージにサブスクライブできるようにする必要があります。正常性メッセージの配信には、ソリューションに適したパスを使用できます。たとえば、サービスの正常性状態の更新をキューに配置して、サブスクライバーが取得できるようにすることができます。

    そのほか、既知の正常性報告インターフェイスが公開されているエンドポイントをサブスクライバーが提供できるようにすることもできます。正常性の情報が変更されたら、提供されたエンドポイントでサブスクライバーに情報を送信できます。

  • 遠隔測定データを配信するためのインターフェイスを公開する

    遠隔測定を使用すると、アプリケーションやサービスの現在の正常性をさまざまなレベルで確認できるため、操作に大いに役立ちます。環境でなんらかの異常が発生した場合もすぐに見つけることができます。サービスの詳細なビューが、オペレーター、サービス、およびサービス プロバイダーのダッシュボードに公開されます。

    操作に関する遠隔測定の基準には、たとえば、さまざまなロール、サービス、およびサービス上に構築された複合アプリケーションの平均 CPU 使用率、エラー、接続、キューなどがあります。

    アプリケーション固有の遠隔測定は、通常、自動的に有効化されたりプラットフォームで直接監視されたりすることはありません。したがって、サービスとアプリケーションで遠隔測定を有効にする必要があります。

  • サービスに追加の正常性診断情報を問い合わせるためのインターフェイスを公開する

    できれば、追加の正常性診断情報を問い合わせるためのインターフェイスも提供する必要があります。サブスクライバー サービスは、正常性状態で受け取った概要情報に基づいて、そのサービスとの関係に関する方針を決定するための追加情報を要求できます。

    たとえば、サービスの正常性状態に問題がある場合、コンシューマー サービスは、追加情報を取得することによって、そのサービスをそのまま使い続けるか代替プロバイダーにフェールオーバーするかを決定できます。

  • サービスとアプリケーションのレベルでサービスの正常性を修復するためのインターフェイスを公開する

    正常性情報のコンシューマーが内部サービスや関連サービスである場合は、そのサービスが既知の問題を自己修復できるようにすることができます。人間の医学と同様に、時間が経つにつれてサービスの正常性についての理解が深まり、正常性データに基づいてさまざまな処理が行われるようになる可能性があります。

    そのような処理を提供できるようにするためのインターフェイスを公開する必要があります。最も単純な形式では、再起動をトリガーする、サービスのイメージを再適用する、別の内部データ プロバイダーやサービス プロバイダーにフェールオーバーするなどの処理が考えられます。

    サービスの正常性を理解すると、異常が発生した場合にすぐに見つけることができます。操作を自動化すると、既知の問題を一貫した方法で迅速かつ規範的に修復して、サービスの自己修復を実現できます。ここでは、正常性のさまざまな側面について詳しく確認しました。

遠隔測定は、"何か (圧力、速度、気温など) を測定し、無線で別の場所に送信する特殊な装置を使用するプロセス" です。

サービスから遠隔測定データを収集することが重要です。 遠隔測定は通常、ユーザー、ビジネス、アプリケーション、インフラストラクチャという 4 つの種類のいずれかに分類されます。

ユーザー遠隔測定は、個別のターゲット ユーザーの動作を対象とします。この測定によって、ユーザーの動作の詳細情報がわかります。結果として、個別にエクスペリエンスを提供しやすくなります。

ビジネス遠隔測定には、ビジネス アクティビティやビジネスの主要パフォーマンス指標 (KPI) に関連するデータが含まれています。ビジネス遠隔測定の例として、サイトのユニーク アクティブ ユーザー数や閲覧されたビデオ数などがあります。

アプリケーション遠隔測定には、アプリケーション レイヤーと依存するサービスの正常性、パフォーマンス、およびアクティビティが含まれます。アプリケーション遠隔測定には、データ クライアントの呼び出しとログイン、例外、API 呼び出し、セッションなどの詳細情報が含まれます。

インフラストラクチャ遠隔測定には、基盤システム インフラストラクチャの正常性に関する詳細情報が含まれます。たとえば、CPU、メモリ、ネットワーク、空き容量などのリソースに関するデータが含まれます。

収集するデータと収集方法を特定する場合、データと、そのデータをどのような意図で処理するかを理解することが重要です。

まず、データの収集目的がアクションを通知または開始することかどうかを判断します。そのために、"どのくらい迅速に対応する必要があるか" という問題を考えます。ほぼリアル タイムでデータを使用し、必要に応じてアクションを開始しますか。または、月間比の動向レポートでデータを使用しますか。このような問題に対する回答で、アーキテクチャに使用する遠隔測定のアプローチとテクノロジがわかります。

次に、収集している遠隔測定データに適用する問題の種類を特定します。遠隔測定を使用して既知の問題に対応しますか。それとも調査のために遠隔測定を使用しますか。たとえば、ビジネスの場合、KPI は既知の問題に対する回答です。一方、製造元がデバイス データを調査して、エラーが発生するパターンを見つける場合、不明な問題に挑戦することになります。この製造元の場合、システム内の 1 つまたは複数のアイテムでエラーが発生します。製造元は調査を実施し、追加データも必要になります。

遠隔測定を使用して詳細情報を入手する場合、詳細情報の入手に必要な時間を考慮する必要があります。場合によっては、遠隔測定を利用して、秒単位や分単位の時間でデバイス センサーの測定値の急上昇を検出することができます。また、遠隔測定を使用して、より長い期間で Web サイトにおける週間比のユーザー数の増加を特定することもできます。

最後に、詳細情報を入手するために期間内に信号ソースから収集できるデータ量について考慮します。必要なソース信号の量を把握する必要があります。把握することで、その信号を分割する最適な方法を決められます。また、ローカルの計算とグローバルな計算の適切な混合を設定できます。

もう 1 つの考慮事項は、遠隔測定で一連のイベントを記録する方法です。多くの組織は、既定でタイム スタンプにします。ただし、サーバーのクロックがデータ センター内と複数のデータ センター全体とで一致しないので、タイム スタンプは問題になる可能性があります。時刻を定期的に同期することはできますが、サーバーのクロックはずれる (徐々に不正確になる) という証拠のドキュメントがあります。このずれによって変化が生じ、効果的な分析が損なわれる可能性があります。正確さが必要なシナリオの場合、ベクトル クロックの実装を利用するなど、代替の解決策を検討してください。

遠隔測定のアプローチを特定したら、次に信号に特性を付けます。

信号は、継続的か離散的かに分類できます。継続的信号の例として、リアル タイムのイベント データがあります。ログ ファイルのエントリは、離散的信号に含まれます。

実際のアプローチのニーズに対応するために、信号に含まれるデータ量を特定する必要があります。情報が継続的な場合、サンプリング レートを設定する必要があります。情報が離散的な場合、保存するレコードとフィルターで除外するレコードを特定する必要があります。

また、アクセスの種類も特定する必要があります。遠隔測定データのプッシュが適切な場合もあります。また、プルで遠隔測定データを取得する場合もあります。

より進化したシステムでは、既存のプッシュされた遠隔測定から得られた詳細情報によって、追加情報についてはプルを目標とする可能性があります。たとえば、プッシュされた遠隔測定が最適以下の状態を示している場合、追加の診断データをプルで取得できます。

特定の条件下ではすべての収集データが関連している可能性がありますが、常にすべての遠隔測定データを送信する必要はありません。詳細情報の取得に必要な遠隔測定の種類とデータ量に基づいて、少量のデータを取得することができます。ローカルの計算を使用して、総計、サンプリング、またはサブセットを生成し、そのデータをサービスに送信できます。標準の遠隔測定で受信したデータが最適以下の状態を示している場合、たとえばサービスから追加データを要求される可能性があります。

遠隔測定戦略を立てる場合、適切なポリシーについて考慮します。遠隔測定には、使用可能な接続が必要であり、その接続でデータを送信するにはコストがかかります。コンテキスト、接続、およびコストを考慮したポリシーを作成し、必要に応じて遠隔測定を調整してください。

ポリシーでは、現在の状態のコンテキストを考慮して、今すぐ送信するために適した遠隔測定を決定する必要があります。以前に受信した遠隔測定から得られた詳細情報と、関連するビジネス ニーズで、コンテキストがわかります。このコンテキストを利用して遠隔測定のコレクションを管理し、優先順位を付けることができます。

このようなデバイスの接続の種類は多様で (WiFi、LTE、4G、3G など)、接続が変化する可能性があります。現在のデバイスの接続は、送信する必要があるデータの決定に関連しています。接続に信頼性がないシナリオや、接続速度が低いシナリオの場合、送信される遠隔測定にポリシーで優先順位を付けることができます。

多くの場合、接続は有料で提供されます。ポリシーでは、現在、接続が従量課金制かどうかを考慮します。従量課金制の接続の場合、関連するコストと、利用できる場合は使用量の上限をポリシーで指定します。多くのデバイスでは、1 日の間に複数の種類の接続を利用します。配信に必要なコストに基づいて、各遠隔測定の優先順位の上下を設定することができます。

多くの場合、遠隔測定データは、さまざまな利用者が入手し、可視化します。運営者と開発者は、可視化が重要な 2 つの利用者です。ただし、以下のように、各利用者のニーズによって、必要な詳細レベルは異なります。

運営スタッフにとって、運用状態の概要と遠隔測定の詳細を可視化することが重要です。遠隔測定データに基づいた自動通知が導入される可能性が高いです。一方、運営者は、現在と過去のサービス パフォーマンスを可視化できるダッシュボードも必要になります。

規模が大きいアプリケーションの場合、この情報で、現在の問題をすばやく特定したり、将来的な問題を予測したりすることができます。また、運営者が影響の可能性や根本的原因を特定しやすくなる場合もあります。

図 10

上の図は、大規模なソーシャル サイトのものです。API ロールの平均 CPU 使用率、API エラー、オンラインのユーザー、Web のアクティブな接続、Web ロールの CPU 使用率、Web エラー、Web のハード接続、Web のプールされた接続、Web アプリケーション キュー、Web のソフト接続などのデータが表示されています。

上の図の遠隔測定とレポートは、サービスそのもののコードを変更せずにオペレーターがエラーを修復できる場合に特に役立ちます。オペレーターが実行できるアクティビティには、配置するロールの数を増やす、インスタンスをリサイクルするなどがあります。

過去とリアルタイムの遠隔測定データの可視化は、次の場合に利用できます。

  • トラブルシューティング。

  • 運用中のサイトの問題に関する事後分析。

  • 新しい運営スタッフのトレーニング。

オペレーターのほか、ソフトウェア開発者も遠隔測定データの重要なコンシューマーです。エラーがオペレーティング環境ではなく基になるアプリケーション コードに関連している場合もあります。開発者向けの遠隔測定ダッシュボードを用意すると、開発者が適切な措置を講じることができるようになります。

このような用途専用で作成されたサンプル ユーティリティの 2 つのスクリーンショットを以下に示します。このダッシュボードには、エラーの数、エラーのカテゴリ、および各カテゴリに固有のデータに関する詳細情報が表示されます。たとえば、エラーの総数、エラーが発生したロール インスタンスの総数、エラーが発生したデータベースの総数などのチェックのデータが含まれます。

図 11

図 12

何百万ものユーザーが利用している大規模なサイトでは、エラー アカウントが高くてもまったく問題ない場合もあります。遠隔測定を解釈する開発者向けのダッシュボードが用意されていれば、本当に問題があるかどうか、介入するのが適切かどうか、コードのどこで問題が発生しているかなどを特定できます。

関連項目

表示:
© 2014 Microsoft