• 3 分

Tailwind Traders のような組織では、ミッション クリティカルなアプリに高い信頼性が求められます。 オンプレミス ベースのアプリに求められる信頼性を実現するには、サーバーやストレージなどのコンピューティング リソースを追加購入することが一般的です。 より多くのコンピューティング リソースを購入すると、オンプレミス インフラストラクチャに冗長性を持たせることができます。

また、ミッション クリティカルなアプリとその関連データは、障害が発生した後、理想的には障害が発生した時点まで回復可能であることも重要です。 この回復性は、多くの場合、バックアップ、復元コンポーネント、およびプロシージャによって提供されます。 Azure でホストされているアプリを持つ組織や、ハイブリッド アプリをデプロイしている組織には、他の検討事項およびオプションがあります。

信頼性の高いアプリは次のとおりです。

• コンポーネントの障害に対する回復性。

• 可用性が高く、大きなダウンタイムのない正常な状態で実行できる。

求められる回復性と高可用性を実現するには、まず要件を規定する必要があります。

要件を定義する

要件を規定するには、次のことを行う必要があります。

• ビジネス ニーズを確認する。

• それらのニーズに対応するための回復性プランを構築する。

次の検討事項の表を使用して、このプロセスを進めてください。

考慮事項	説明
ワークロードとその使用状況はどうなっていますか?	ワークロードとは、ビジネス ロジックとデータ ストレージの要件の観点から、他のタスクとは論理的に区別される独特な機能またはタスクです。 各ワークロードには、可用性、スケーラビリティ、データの一貫性、およびディザスター リカバリーに関して異なる要件があります。
ワークロードの使用パターンは何ですか?	使用パターンによって要件が決まる可能性があります。 重要な期間と重要でない期間の要件の違いを確認します。 アップタイムを確保するために、1 つのリージョンで障害が発生した場合の複数のリージョンにまたがる冗長性を計画します。 逆に、重要でない期間のコストを最小限に抑えるために、単一のリージョンでアプリケーションを実行できます。
可用性メトリックとは何ですか?	平均回復時間 (MTTR) と平均故障間隔 (MTBF) が、一般的に使用されるメトリックです。 MTBF とは、次の障害が発生するまでに合理的に予期されるコンポーネントの稼働時間です。 MTTR は、障害発生後、コンポーネントを復元するために必要な平均時間です。 これらのメトリックを使用して、冗長性を追加する必要がある場所を判別し、顧客のサービス レベル アグリーメント (SLA) を決定します。
回復メトリックとは何ですか?	目標回復時間 (RTO) は、インシデント発生後、アプリの 1 つが使用できなくなることを許容できる最大時間です。 回復ポイントの目標 (RPO) は、災害発生時に許容できるデータ損失の最大期間です。 目標回復レベル (RLO) も検討してください。 このメトリックは、回復の粒度を判別します。 つまり、サーバー ファーム、Web アプリ、サイトを回復できなければならないか、それとも特定の項目だけ回復できればよいかということです。 これらの値を判別するには、リスク評価を実施します。 組織のダウンタイムまたはデータ損失のコストとリスクを把握しておいてください。
ワークロードの可用性の目標とは何ですか?	アプリ アーキテクチャがビジネス要件を満たすようにするうえで、各ワークロードの目標 SLA を規定することは役に立ちます。 アプリケーションの依存関係に加えて、可用性の要件を満たす上でのコストと複雑さを考慮します。
お客様の SLA は何でしょうか。	Azure では、稼働時間と接続に関する Microsoft の確約内容が SLA に記載されています。 特定のサービスの SLA が 99.9% の場合は、そのサービスを 99.9% の時間、使用可能であることが期待できるということになります。

前述の質問に答えて、ソリューション内のワークロードごとに独自の目標 SLA を規定します。 これにより、アーキテクチャがビジネス要件を確実に満たすようにすることができます。 たとえば、99.99 パーセントのアップタイムを必要とするワークロードが、99.9 パーセントの SLA を持つサービスに依存している場合、そのサービスをシステムの単一障害点に設定することはできません。

回復要件を規定したら、適切な回復テクノロジを選択できます。