回復性に優れた Azure 用アプリケーションの設計Designing resilient applications for Azure

分散システムでは、障害が発生します。In a distributed system, failures will happen. ハードウェアの障害が発生することがあります。Hardware can fail. ネットワークに一時的な障害が起きることがあります。The network can have transient failures. まれに、サービス全体またはリージョン全体で中断が発生する可能性がありますが、こうしたことについても計画しておく必要があります。Rarely, an entire service or region may experience a disruption, but even those must be planned for.

クラウドで信頼性の高いアプリケーションの構築は、エンタープライズ設定で信頼性の高いアプリケーションの構築とは異なります。Building a reliable application in the cloud is different than building a reliable application in an enterprise setting. 従来は、スケールアップのためにハイエンドなハードウェアを購入していましたが、クラウド環境では、スケールアップではなくスケールアウトする必要があります。While historically you may have purchased higher-end hardware to scale up, in a cloud environment you must scale out instead of scaling up. クラウド環境は、汎用的なハードウェアを使用することで低コストを維持できます。Costs for cloud environments are kept low through the use of commodity hardware. この新しい環境では、エラーを回避し、"平均故障間隔" を最適化することではなく、"復元までの平均時間" に集中できます。Instead of focusing on preventing failures and optimizing "mean time between failures," in this new environment the focus shifts to "mean time to restore." 目標は、障害の影響を最小限に抑えることです。The goal is to minimize the effect of a failure.

この記事では、Microsoft Azure で回復性に優れたアプリケーションを構築する方法の概要について説明します。This article provides an overview of how to build resilient applications in Microsoft Azure. まず、回復性という用語の定義と関連する概念から説明します。It starts with a definition of the term resiliency and related concepts. 次に、設計、実装からデプロイ、運用までというアプリケーションの有効期間全体に体系的な方法を使用することで、回復性を実現するプロセスについて説明します。Then it describes a process for achieving resiliency, using a structured approach over the lifetime of an application, from design and implementation to deployment and operations.

回復性とはWhat is resiliency?

回復性とは、障害から回復して動作を続行する、システムの能力です。Resiliency is the ability of a system to recover from failures and continue to function. 障害を回避することではなく、ダウンタイムまたはデータの損失を回避するように障害に対応することです。It's not about avoiding failures, but responding to failures in a way that avoids downtime or data loss. 回復性の目的は、障害後にアプリケーションを完全に機能している状態に戻すことです。The goal of resiliency is to return the application to a fully functioning state following a failure.

回復性には、高可用性とディザスター リカバリーという 2 つの重要な側面があります。Two important aspects of resiliency are high availability and disaster recovery.

  • 高可用性 (HA) は、大幅なダウンタイムなしに、正常な状態で実行を継続するアプリケーションの能力です。High availability (HA) is the ability of the application to continue running in a healthy state, without significant downtime. "正常な状態" とは、アプリケーションが応答し、ユーザーがアプリケーションに接続して対話できるという意味です。By "healthy state," we mean the application is responsive, and users can connect to the application and interact with it.
  • ディザスター リカバリー (DR) は、まれに発生する大きなインシデント、すなわち地域全体に影響するサービス中断のように、一時的なものではない大規模な障害から回復する能力です。Disaster recovery (DR) is the ability to recover from rare but major incidents: non-transient, wide-scale failures, such as service disruption that affects an entire region. ディザスター リカバリーには、データ バックアップやアーカイブの他に、バックアップからのデータベースの復元などの手動操作も含まれる場合があります。Disaster recovery includes data backup and archiving, and may include manual intervention, such as restoring a database from backup.

HA と DR のとらえ方として、障害の影響が HA 設計で対応できる限度を超えたときに DR が始まると考えることができます。One way to think about HA versus DR is that DR starts when the impact of a fault exceeds the ability of the HA design to handle it. たとえば、ロード バランサーの背後に複数の VM を配置すると、いずれかの VM で障害が発生しても可用性は維持されますが、同時にすべての VM で障害が発生した場合は維持されません。For example, putting several VMs behind a load balancer will provide availability if one VM fails, but not if they all fail at the same time.

回復力のあるアプリケーションを設計するときには、ご自分の可用性要件を理解する必要があります。When you design an application to be resilient, you have to understand your availability requirements. どの程度のダウンタイムを許容できますか。How much downtime is acceptable? これは、ある程度はコストによって決まります。This is partly a function of cost. 起こり得るダウンタイムによってご自分のビジネスが被るコストはいくらになりますか。How much will potential downtime cost your business? アプリケーションの可用性を高めることにいくら投資したいですか。How much should you invest in making the application highly available? また、何をもってアプリケーションが使用可能であるとするかについても定義する必要があります。You also have to define what it means for the application to be available. たとえば、ユーザーが注文を送信しても、通常の時間枠内にシステムで処理できない場合、アプリケーションは "停止" 状態でしょうか。For example, is the application "down" if a customer can submit an order but the system cannot process it within the normal timeframe? また、特定の種類の障害が発生する可能性と、リスク軽減戦略のコスト効果が高いかどうかについても考慮します。Also consider the probability of a particular type of outage occurring, and whether a mitigation strategy is cost-effective.

もう 1 つの一般的な用語にビジネス継続性 (BC) があります。BC とは、自然災害やサービスの停止などの悪条件の発生時と発生後に、重要なビジネス機能を実行できることです。Another common term is business continuity (BC), which is the ability to perform essential business functions during and after adverse conditions, such as a natural disaster or a downed service. BC は、物理的な設備、人、コミュニティ、運輸、IT を含め、業務全体が対象です。BC covers the entire operation of the business, including physical facilities, people, communications, transportation, and IT. この記事ではクラウド アプリケーションを中心に扱いますが、回復性の計画は BC 要件全体のコンテキストで行う必要があります。This article focuses on cloud applications, but resilience planning must be done in the context of overall BC requirements. 詳細については、National Institute of Science and Technology (NIST) の「[Contingency Planning Guide][capacity-planning-guide]」(危機管理計画ガイド) を参照してください。For more information, see the [Contingency Planning Guide][capacity-planning-guide] from the National Institute of Science and Technology (NIST).

回復性を実現するプロセスProcess to achieve resiliency

回復性はアドオンではありません。Resiliency is not an add-on. システムの設計に追加し、運用方法に組み込む必要があります。It must be designed into the system and put into operational practice. 一般的なモデルは次のとおりです。Here is a general model to follow:

  1. 定義: ビジネスのニーズに基づいて可用性の要件を定義します。Define your availability requirements, based on business needs.
  2. 設計: 回復性を考慮してアプリケーションを設計します。Design the application for resiliency. 実証済みの手法に従ったアーキテクチャから始めて、そのアーキテクチャで考えられる障害点を特定します。Start with an architecture that follows proven practices, and then identify the possible failure points in that architecture.
  3. 実装: 障害を検出し、回復する戦略を実装します。Implement strategies to detect and recover from failures.
  4. テスト: 障害をシミュレートし、強制的なフェールオーバーをトリガーして実装をテストします。Test the implementation by simulating faults and triggering forced failovers.
  5. デプロイ: 信頼性が高い反復可能なプロセスを使用して、アプリケーションを運用環境にデプロイします。Deploy the application into production using a reliable, repeatable process.
  6. 監視: アプリケーションを監視して障害を検出します。Monitor the application to detect failures. システムを監視することで、アプリケーションの正常性を評価し、必要に応じてインシデントに対応できます。By monitoring the system, you can gauge the health of the application and respond to incidents if necessary.
  7. 対応: 手動の介入が必要なインシデントが発生した場合に対応します。Respond if there are incidents that require manual interventions.

以降、これらの各手順について詳しく説明します。In the remainder of this article, we discuss each of these steps in more detail.

回復性の要件を定義するDefining your resiliency requirements

回復性の計画は、ビジネス要件から始まります。Resiliency planning starts with business requirements. ビジネス要件という点で回復性について考える場合の方法をいくつか挙げます。Here are some approaches for thinking about resiliency in those terms.

ワークロードごとに分解するDecompose by workload

多くのクラウド ソリューションは、複数のアプリケーション ワークロードで構成されます。Many cloud solutions consist of multiple application workloads. このコンテキストで "ワークロード" という用語は、ビジネス ロジックとデータ ストレージ要件の点で、他のタスクとは論理的に区別できる個別の機能またはコンピューティング タスクを意味します。The term "workload" in this context means a discrete capability or computing task, which can be logically separated from other tasks, in terms of business logic and data storage requirements. たとえば、eコマース アプリには次のようなワークロードがあります。For example, an e-commerce app might include the following workloads:

  • 製品カタログの閲覧と検索。Browse and search a product catalog.
  • 注文の作成と追跡。Create and track orders.
  • 推奨事項の表示。View recommendations.

これらのワークロードは、可用性、スケーラビリティ、データの一貫性、ディザスター リカバリーなどの要件が異なる可能性があります。These workloads might have different requirements for availability, scalability, data consistency, disaster recovery, and so forth. これらもビジネス上の決定事項です。Again, these are business decisions.

また、使用パターンについても考慮します。Also consider usage patterns. システムが使用可能である必要がある特定の重要な期間はありますか。Are there certain critical periods when the system must be available? たとえば、税金申告書サービスが申告期限の直前に停止してはならない、大規模なスポーツ イベント中にビデオ ストリーミング サービスは稼働している必要がある、などです。For example, a tax-filing service can't go down right before the filing deadline, a video streaming service must stay up during a big sports event, and so on. 重要な期間中は、複数のリージョンにまたがる冗長的なデプロイにして、1 つのリージョンで障害が発生してもアプリケーションがフェールオーバーできるようにすることができます。During the critical periods, you might have redundant deployments across several regions, so the application could fail over if one region failed. ただし、複数リージョンのデプロイはコストが高くなるため、重要な期間以外は、1 つのリージョンでアプリケーションを実行することができます。However, a multi-region deployment is more expensive, so during less critical times, you might run the application in a single region.

RTO と RPORTO and RPO

考慮すべき 2 つの重要なメトリックとして、目標復旧時間と回復ポイントの目標があります。Two important metrics to consider are the recovery time objective and recovery point objective.

  • 目標復旧時間 (RTO) は、インシデントが発生した後に、アプリケーションに許容する使用不能状態の最大時間です。Recovery time objective (RTO) is the maximum acceptable time that an application can be unavailable after an incident. RTO が 90 分の場合、災害発生から 90 分以内にアプリケーションを実行状態に復元できる必要があります。If your RTO is 90 minutes, you must be able to restore the application to a running state within 90 minutes from the start of a disaster. RTO を非常に低い値にする場合、リージョン全体の停止から保護するために、スタンバイ状態で継続的に動作する第 2 のデプロイを維持する必要があります。If you have a very low RTO, you might keep a second deployment continually running on standby, to protect against a regional outage.
  • 回復ポイントの目標 (RPO) は、災害発生時に許容できるデータ損失の最大期間です。Recovery point objective (RPO) is the maximum duration of data loss that is acceptable during a disaster. たとえば、単一のデータベースにデータを格納し、他のデータベースへのレプリケーションなしで、毎時のバックアップを実行する場合、最大 1 時間のデータを失う可能性があります。For example, if you store data in a single database, with no replication to other databases, and perform hourly backups, you could lose up to an hour of data.

RTO と RPO はビジネス要件です。RTO and RPO are business requirements. リスク評価の実施は、アプリケーションの RTO と RPO の定義に役立ちます。Conducting a risk assessment can help you define the application's RTO and RPO. もう 1 つの一般的なメトリックは、平均復旧時間 (MTTR) です。MTTR は、障害発生後にアプリケーションの復元にかかる平均時間です。Another common metric is mean time to recover (MTTR), which is the average time that it takes to restore the application after a failure. MTTR は、システムに関する経験的事実です。MTTR is an empirical fact about a system. MTTR が RTO を超えると、システム障害の結果、定義されている RTO 以内にシステムを復元できなくなるため、許容できないビジネスの中断が発生します。If MTTR exceeds the RTO, then a failure in the system will cause an unacceptable business disruption, because it won't be possible to restore the system within the defined RTO.

SLASLAs

Azure のサービス レベル アグリーメント (SLA) では、稼働時間と接続性に関する Microsoft のコミットメントが示されています。In Azure, the Service Level Agreement (SLA) describes Microsoft’s commitments for uptime and connectivity. 特定のサービスの SLA が 99.9% の場合は、そのサービスを 99.9% の確率で使用可能だと予想できることを意味します。If the SLA for a particular service is 99.9%, it means you should expect the service to be available 99.9% of the time.

注意

また、Azure SLA には、SLA が満たされない場合にサービス クレジットを取得するための規定と、各サービスの "可用性" の詳細な定義も含まれています。The Azure SLA also includes provisions for obtaining a service credit if the SLA is not met, along with specific definitions of "availability" for each service. SLA のこの側面は、強制ポリシーとして機能します。That aspect of the SLA acts as an enforcement policy.

お客様のソリューションの各ワークロードには、独自の目標 SLA を定義することをお勧めします。You should define your own target SLAs for each workload in your solution. SLA があると、アーキテクチャがビジネス要件を満たしているかどうかを評価できるようになります。An SLA makes it possible to evaluate whether the architecture meets the business requirements. たとえば、ワークロードのアップタイム要件が 99.99% で、SLA が 99.9% のサービスに依存している場合、そのサービスをシステムの単一障害点にしてはなりません。For example, if a workload requires 99.99% uptime, but depends on a service with a 99.9% SLA, that service cannot be a single-point of failure in the system. 救済策として、サービスで障害が発生した場合に備えてフォールバック パスを用意するか、そのサービスの障害から復旧する他の措置を実行する方法があります。One remedy is to have a fallback path in case the service fails, or take other measures to recover from a failure in that service.

次の表は、さまざまな SLA レベルで考えられる累積的なダウンタイムの一覧です。The following table shows the potential cumulative downtime for various SLA levels.

SLASLA 週あたりのダウンタイムDowntime per week 月あたりのダウンタイムDowntime per month 年あたりのダウンタイムDowntime per year
99%99% 1.68 時間1.68 hours 7.2 時間7.2 hours 3.65 日3.65 days
99.9%99.9% 10.1 分10.1 minutes 43.2 分43.2 minutes 8.76 時間8.76 hours
99.95%99.95% 5 分5 minutes 21.6 分21.6 minutes 4.38 時間4.38 hours
99.99%99.99% 1.01 分1.01 minutes 4.32 分4.32 minutes 52.56 分52.56 minutes
99.999%99.999% 6 秒6 seconds 25.9 秒25.9 seconds 5.26 分5.26 minutes

当然ながら高可用性が望ましく、他の項目は同じくらいです。Of course, higher availability is better, everything else being equal. ただし、99.99...% の 9 の桁数を増やすにつれて、そのレベルの可用性を実現するためのコストと複雑さは増大します。But as you strive for more 9s, the cost and complexity to achieve that level of availability grows. 99.99% のアップタイムは、月あたりの合計ダウンタイムの約 5 分に換算されます。An uptime of 99.99% translates to about 5 minutes of total downtime per month. 5 つの 9 (99.999%) を実現するために、複雑さとコストが増大する価値はありますか。Is it worth the additional complexity and cost to reach five 9s? その答えはビジネス要件によって変わります。The answer depends on the business requirements.

SLA を定義する場合の他の考慮事項を次に示します。Here are some other considerations when defining an SLA:

  • 4 つの 9 (99.99%) を実現するには、手動操作による障害からの復旧には依存できません。To achieve four 9's (99.99%), you probably can't rely on manual intervention to recover from failures. アプリケーションには自己診断機能と自己復旧機能が必要です。The application must be self-diagnosing and self-healing.
  • 4 つの 9 を超えると、SLA を満たすことができるほど迅速に障害を検出することは困難です。Beyond four 9's, it is challenging to detect outages quickly enough to meet the SLA.
  • SLA を測定する時間枠について考慮します。Think about the time window that your SLA is measured against. この時間枠を短くするほど、許容度は厳格になります。The smaller the window, the tighter the tolerances. 時間単位または日単位のアップタイムという観点で SLA を定義することはおそらく意味がありません。It probably doesn't make sense to define your SLA in terms of hourly or daily uptime.

複合 SLAComposite SLAs

Azure SQL Database に書き込む App Service Web アプリについて検討します。Consider an App Service web app that writes to Azure SQL Database. この記事の執筆時点で、このような Azure サービスには次の SLA があります。At the time of this writing, these Azure services have the following SLAs:

  • App Service Web Apps = 99.95%App Service Web Apps = 99.95%
  • SQL Database = 99.99%SQL Database = 99.99%

複合 SLA

このアプリケーションで予想される最大ダウンタイムはどのくらいですか。What is the maximum downtime you would expect for this application? いずれかのサービスで障害が発生すると、アプリケーション全体で障害が発生します。If either service fails, the whole application fails. 一般的に、各サービスで障害が発生する可能性は独立しているため、このアプリケーションの複合 SLA は 99.95% × 99.99% = 99.94% です。In general, the probability of each service failing is independent, so the composite SLA for this application is 99.95% × 99.99% = 99.94%. これは個々の SLA よりも低い値です。複数のサービスに依存するアプリケーションは潜在的な障害点が多くなるため、これは驚くことではありません。That's lower than the individual SLAs, which isn't surprising, because an application that relies on multiple services has more potential failure points.

一方、複合 SLA を改善するには、独立したフォールバック パスを作成する方法があります。On the other hand, you can improve the composite SLA by creating independent fallback paths. たとえば、SQL Database が使用できない場合は、後で処理できるようにトランザクションをキューに格納します。For example, if SQL Database is unavailable, put transactions into a queue, to be processed later.

複合 SLA

この設計の場合、データベースに接続できない場合でも、アプリケーションは使用可能な状態です。With this design, the application is still available even if it can't connect to the database. ただし、データベースとキューの両方で同時に障害が発生すると、アプリケーションは使用できなくなります。However, it fails if the database and the queue both fail at the same time. 同時に障害が発生する時間の予測される割合は 0.0001 × 0.001 なので、この組み合わせのパスに関する複合 SLA は次のとおりです。The expected percentage of time for a simultaneous failure is 0.0001 × 0.001, so the composite SLA for this combined path is:

  • データベース OR キュー = 1.0 − (0.0001 × 0.001) = 99.99999%Database OR queue = 1.0 − (0.0001 × 0.001) = 99.99999%

合計複合 SLA は次のとおりです。The total composite SLA is:

  • Web アプリ AND (データベース OR キュー) = 99.95% × 99.99999% = 99.95% 以下Web app AND (database OR queue) = 99.95% × 99.99999% = ~99.95%

ただし、この方法にはトレードオフがあります。But there are tradeoffs to this approach. アプリケーション ロジックは複雑になり、キューのコストがかかり、データの一貫性に関する問題も考慮が必要になる可能性があります。The application logic is more complex, you are paying for the queue, and there may be data consistency issues to consider.

複数リージョン デプロイの SLASLA for multi-region deployments. もう 1 つの HA 手法は、アプリケーションを複数のリージョンにデプロイし、1 つのリージョンのアプリケーションで障害が発生した場合にフェールオーバーするように Azure Traffic Manager を使用する方法です。Another HA technique is to deploy the application in more than one region, and use Azure Traffic Manager to fail over if the application fails in one region. 2 リージョンのデプロイの場合、複合 SLA は次のように計算されます。For a two-region deployment, the composite SLA is calculated as follows.

N は、1 つのリージョンにアプリケーションをデプロイした場合の複合 SLA であるとします。Let N be the composite SLA for the application deployed in one region. 同時に両方のリージョンのアプリケーションで障害が発生する可能性は (1 − N) × (1 − N) と予測されます。The expected chance that the application will fail in both regions at the same time is (1 − N) × (1 − N). そのため、次のようになります。Therefore,

  • 両リージョンの複合 SLA = 1 − (1 − N)(1 − N) = N + (1 − N)NCombined SLA for both regions = 1 − (1 − N)(1 − N) = N + (1 − N)N

最後に、Traffic Manager の SLA を考慮する必要があります。Finally, you must factor in the SLA for Traffic Manager. この記事の執筆時点で Traffic Manager の SLA は 99.99% です。At the time of this writing, the SLA for Traffic Manager SLA is 99.99%.

  • 複合 SLA = 99.99% × (両リージョンの複合 SLA)Composite SLA = 99.99% × (combined SLA for both regions)

また、フェールオーバーは瞬時に完了しないので、フェールオーバー時にはある程度のダウンタイムが発生する可能性があります。Also, failing over is not instantaneous and can result in some downtime during a failover. Traffic Manager エンドポイントの監視とフェールオーバーに関するページを参照してください。See Traffic Manager endpoint monitoring and failover.

計算された SLA 値は便利なベースラインですが、可用性のすべてを把握できる訳ではありません。The calculated SLA number is a useful baseline, but it doesn't tell the whole story about availability. 重要ではないパスで障害が発生した場合、アプリケーションの機能を適切に低下できることがよくあります。Often, an application can degrade gracefully when a non-critical path fails. 書籍のカタログを表示するアプリケーションを例に説明します。Consider an application that shows a catalog of books. そのアプリケーションが表紙のサムネイル画像を取得できない場合は、プレース ホルダー イメージを表示することができます。If the application can't retrieve the thumbnail image for the cover, it might show a placeholder image. この場合、画像を取得できないと、アプリケーションの稼働時間は減りませんが、ユーザー エクスペリエンスには影響が出ます。In that case, failing to get the image does not reduce the application's uptime, although it affects the user experience.

回復性の設計Designing for resiliency

設計フェーズで、障害モードの分析 (FMA) を実行することをお勧めします。During the design phase, you should perform a failure mode analysis (FMA). FMA の目標は、潜在的な障害点を特定し、アプリケーションがその障害に対して対応する方法を定義することです。The goal of an FMA is to identify possible points of failure, and define how the application will respond to those failures.

  • アプリケーションはこのような障害をどのように検出するでしょうか。How will the application detect this type of failure?
  • アプリケーションはこのような障害にどのように対応するでしょうか。How will the application respond to this type of failure?
  • このような障害のログ記録と監視はどのように行うでしょうか。How will you log and monitor this type of failure?

FMA プロセスの詳細と、Azure 固有の推奨事項については、Azure の回復性ガイダンスの障害モードの分析に関するページを参照してください。For more information about the FMA process, with specific recommendations for Azure, see Azure resiliency guidance: Failure mode analysis.

障害モードと検出戦略の特定例Example of identifying failure modes and detection strategy

障害点: 外部 Web サービス/API の呼び出し。Failure point: Call to an external web service / API.

障害モードFailure mode 検出戦略Detection strategy
サービスを使用できないService is unavailable HTTP 5xxHTTP 5xx
調整Throttling HTTP 429 (要求が多すぎます)HTTP 429 (Too Many Requests)
認証Authentication HTTP 401 (権限がありません)HTTP 401 (Unauthorized)
遅い応答Slow response 要求のタイムアウトRequest times out

回復性戦略Resiliency strategies

ここでは、一般的な回復性戦略の調査について説明します。This section provides a survey of some common resiliency strategies. ほとんどの項目は特定のテクノロジに限定されていません。Most of these are not limited to a particular technology. このセクションの説明では、各手法の背後にある一般的な考えをまとめ、詳細なドキュメントのリンクを紹介しています。The descriptions in this section summarize the general idea behind each technique, with links to further reading.

一時的な障害を再試行するRetry transient failures

一時的な障害は、ネットワーク接続の一時的な喪失、データベース接続の欠落、またはサービスがビジー状態のときのタイムアウトが原因で発生します。Transient failures can be caused by momentary loss of network connectivity, a dropped database connection, or a timeout when a service is busy. 多くの場合、一時的な障害は、要求を再試行するだけで解決できます。Often, a transient failure can be resolved simply by retrying the request. 多くの Azure サービスでは、クライアント SDK が呼び出し元には認識されない方法の自動再試行を実装しています。詳細については、サービス固有の再試行ガイダンスに関するページを参照してください。For many Azure services, the client SDK implements automatic retries, in a way that is transparent to the caller; see Retry service specific guidance.

再試行ごとに、合計待機時間が追加されます。Each retry attempt adds to the total latency. また、失敗した要求が多すぎると、保留中の要求がキューに蓄積されるため、ボトルネックの原因になる可能性があります。Also, too many failed requests can cause a bottleneck, as pending requests accumulate in the queue. これらのブロックされた要求が重要なシステム リソース (メモリ、しきい値、データベース接続など) を保持することで、障害が連鎖する可能性があります。These blocked requests might hold critical system resources such as memory, threads, database connections, and so on, which can cause cascading failures. この問題を回避するために、再試行間隔を長くして、失敗した要求の合計数を制限します。To avoid this, increase the delay between each retry attempt, and limit the total number of failed requests.

複合 SLA

詳細については、「Retry Pattern」(再試行パターン) を参照してください。For more information, see Retry Pattern.

インスタンス全体の負荷分散Load balance across instances

スケーラビリティのために、インスタンス数を増やしてクラウド アプリケーションをスケールアウトすることをお勧めします。For scalability, a cloud application should be able to scale out by adding more instances. この方法では、正常ではないインスタンスをローテーションから除去できるため、回復性も改善されます。This approach also improves resiliency, because unhealthy instances can be removed from rotation.

例:For example:

  • 複数の VM をロード バランサーの内側に配置します。Put two or more VMs behind a load balancer. ロード バランサーはトラフィックをすべての VM に分散します。The load balancer distributes traffic to all the VMs. Run load-balanced VMs for scalability and availability」(スケーラビリティと可用性のために負荷分散された VM を実行する) を参照してください。See Run load-balanced VMs for scalability and availability.
  • Azure App Service アプリを複数インスタンスにスケールアウトします。Scale out an Azure App Service app to multiple instances. App Service は自動的にインスタンス全体に負荷を分散します。App Service automatically balances load across instances. Basic web application」(基本的な Web アプリケーション) を参照してください。See Basic web application.
  • Azure Traffic Manager を使用して、一連のエンドポイント全体でトラフィックを分散します。Use Azure Traffic Manager to distribute traffic across a set of endpoints.

データをレプリケートするReplicate data

データのレプリケートは、データ ストアの一時的ではない障害を処理する場合の一般的な戦略です。Replicating data is a general strategy for handling non-transient failures in a data store. Azure SQL Database、Cosmos DB、Apache Cassandra など、多くのストレージ テクノロジにはレプリケーション機能が組み込まれています。Many storage technologies provide built-in replication, including Azure SQL Database, Cosmos DB, and Apache Cassandra.

読み取りパスと書き込みパスの両方を考慮することが重要です。It's important to consider both the read and write paths. 戦略テクノロジに応じて、複数の書き込み可能なレプリカ、または単一の書き込み可能なレプリカと複数の読み取り専用レプリカを用意する必要があります。Depending on the storage technology, you might have multiple writable replicas, or a single writable replica and multiple read-only replicas.

可用性を最大限にするために、レプリカを複数のリージョンに配置する方法もあります。To maximize availability, replicas can be placed in multiple regions. ただし、データをレプリケートすると待機時間が長くなります。However, this increases the latency when replicating the data. 通常、複数リージョンをまたがるレプリケートは非同期に行われます。これは最終的な整合性モデルであり、レプリカで障害が発生した場合にはデータ損失が発生する可能性があります。Typically, replicating across regions is done asynchronously, which implies an eventual consistency model and potential data loss if a replica fails.

機能を適切に低下させるDegrade gracefully

サービスで障害が発生し、フェールオーバー パスがない場合、許容範囲のユーザー エクスペリエンスを提供した状態で、アプリケーションの機能を適切に低下させることができます。If a service fails and there is no failover path, the application may be able to degrade gracefully while still providing an acceptable user experience. 例:For example:

  • 作業項目を後で処理できるようにキューに格納します。Put a work item on a queue, to be handled later.
  • 予測値を返します。Return an estimated value.
  • ローカルにキャッシュされたデータを使用します。Use locally cached data.
  • ユーザーにエラー メッセージを表示しますShow the user an error message. (この選択肢は、アプリケーションが要求への応答を停止するよりも優れています)。(This option is better than having the application stop responding to requests.)

高負荷のユーザーを調整するThrottle high-volume users

少数のユーザーが過剰な負荷を発生させることがあります。Sometimes a small number of users create excessive load. その結果、他のユーザーに影響が及び、アプリケーションの全体的な可用性が低くなる可能性があります。That can have an impact on other users, reducing the overall availability of your application.

単一のクライアントが大量の要求を行った場合、一定期間、アプリケーションはクライアントを調整することができます。When a single client makes an excessive number of requests, the application might throttle the client for a certain period of time. この調整期間、(詳細な調整戦略に基づいて) アプリケーションはそのクライアントからの要求の一部またはすべてを拒否します。During the throttling period, the application refuses some or all of the requests from that client (depending on the exact throttling strategy). 調整のしきい値は、ユーザーのサービス レベルによって変わる可能性があります。The threshold for throttling might depend on the customer's service tier.

調整は、クライアントが悪意を持って実行している場合に限定されません。サービス クォータを超えたというだけの理由で行われます。Throttling does not imply the client was necessarily acting maliciously, only that it exceeded its service quota. 場合によっては、コンシューマーが常にクォータを超えているか、動作が正しくない可能性があります。In some cases, a consumer might consistently exceed their quota or otherwise behave badly. この場合は、さらにユーザーをブロックすることがあります。In that case, you might go further and block the user. 通常、このブロックを行うには、API キーまたは IP アドレス範囲をブロックします。Typically, this is done by blocking an API key or an IP address range.

詳細については、「Throttling pattern」(調整パターン) を参照してください。For more information, see Throttling Pattern.

サーキット ブレーカーを使用するUse a circuit breaker

サーキット ブレーカー パターンを使用すると、失敗する可能性がある操作をアプリケーションで繰り返し再試行することを回避できます。The Circuit Breaker pattern can prevent an application from repeatedly trying an operation that is likely to fail. これは、回路がオーバーロードになったときに電流を遮断するスイッチである物理的なサーキット ブレーカーと似ています。This is similar to a physical circuit breaker, a switch that interrupts the flow of current when a circuit is overloaded.

サーキット ブレーカーはサービスの呼び出しをラップします。The circuit breaker wraps calls to a service. 以下の 3 つの状態があります。It has three states:

  • クローズClosed. これが通常の状態です。This is the normal state. サーキット ブレーカーは要求をサービスに送信し、カウンターで最近のエラー数が追跡されます。The circuit breaker sends requests to the service, and a counter tracks the number of recent failures. 指定した期間内にエラー数がしきい値を超えると、サーキット ブレーカーはオープン状態に切り替わります。If the failure count exceeds a threshold within a given time period, the circuit breaker switches to the Open state.
  • オープンOpen. この状態になると、サーキット ブレーカーはサービスを呼び出すことなく、すべての要求を即時に失敗させます。In this state, the circuit breaker immediately fails all requests, without calling the service. アプリケーションは、レプリカからデータを読み取る、単にユーザーにエラーを返すなどの軽減パスを使用する必要があります。The application should use a mitigation path, such as reading data from a replica or simply returning an error to the user. サーキット ブレーカーがオープンに切り替わると、タイマーが開始されます。When the circuit breaker switches to Open, it starts a timer. タイマーが期限切れになると、サーキット ブレーカーは半オープン状態に切り替わります。When the timer expires, the circuit breaker switches to the Half-open state.
  • 半オープンHalf-open. この状態で、サーキット ブレーカーは制限された数の要求をサービスに送信します。In this state, the circuit breaker lets a limited number of requests go through to the service. 要求が成功した場合、サービスが復旧したと見なし、サーキット ブレーカーはクローズ状態に戻ります。If they succeed, the service is assumed to be recovered, and the circuit breaker switches back to the Closed state. それ以外の場合はオープン状態に戻ります。Otherwise, it reverts to the Open state. 半オープンの場合、復旧中のサービスに突然大量の要求が送信されることはなくなります。The Half-Open state prevents a recovering service from suddenly being inundated with requests.

詳細については、「Circuit Breaker Pattern」(Circuit Breaker パターン) を参照してください。For more information, see Circuit Breaker Pattern.

負荷平準化を使用してトラフィックの急増をなくすUse load leveling to smooth out spikes in traffic

アプリケーションではトラフィックの急増が起きることがあり、これがバックエンドのサービスに大きな負荷をかけることがあります。Applications may experience sudden spikes in traffic, which can overwhelm services on the backend. バックエンド サービスが要求にすばやく応答できない場合、要求がキューに格納されることや (バックアップ)、サービスによってアプリケーションが調整されることがあります。If a backend service cannot respond to requests quickly enough, it may cause requests to queue (back up), or cause the service to throttle the application.

この状況を回避するために、バッファーとしてキューを使用することができます。To avoid this, you can use a queue as a buffer. 新しい作業項目がある場合、バックエンド サービスを即時に呼び出すのではなく、アプリケーションで作業項目をキューに格納して非同期に実行します。When there is a new work item, instead of calling the backend service immediately, the application queues a work item to run asynchronously. キューは、負荷のピークを平準化するバッファーとして機能します。The queue acts as a buffer that smooths out peaks in the load.

詳細については、Queue-Based Load Leveling パターンに関するページを参照してください。For more information, see Queue-Based Load Leveling Pattern.

重要なリソースを分離するIsolate critical resources

1 つのサブシステムで複数の障害が連鎖し、アプリケーションの他の部分で障害が発生する可能性があります。Failures in one subsystem can sometimes cascade, causing failures in other parts of the application. これが起きるのは、障害によってスレッドやソケットなどのリソースが適切なタイミングで解放されない場合で、リソースの消費につながります。This can happen if a failure causes some resources, such as threads or sockets, not to get freed in a timely manner, leading to resource exhaustion.

これを回避するには、システムを分離グループにパーティション分割して、1 つのパーティションでの障害がシステム全体をダウンさせないようにします。To avoid this, you can partition a system into isolated groups, so that a failure in one partition does not bring down the entire system. この手法は、バルクヘッド パターンとも呼ばれます。This technique is sometimes called the Bulkhead pattern.

次に例を示します。Examples:

  • データベースをパーティション分割し (テナント別など)、各パーティションに Web サーバー インスタンスの別プールを割り当てます。Partition a database (for example, by tenant) and assign a separate pool of web server instances for each partition.
  • 個別のスレッド プールを使用して、異なるサービスの呼び出しを分離します。Use separate thread pools to isolate calls to different services. こうすることで、いずれかのサービスで障害が発生した場合の障害の連鎖を回避できます。This helps to prevent cascading failures if one of the services fails. 例については、Netflix の Hystrix ライブラリを参照してください。For an example, see the Netflix Hystrix library.
  • コンテナーを使用して、特定のサブシステムに使用できるリソースを制限します。Use containers to limit the resources available to a particular subsystem.

複合 SLA

補正トランザクションを適用するApply compensating transactions

補正トランザクションは、別の完了したトランザクションの影響を元に戻すトランザクションです。A compensating transaction is a transaction that undoes the effects of another completed transaction.

分散システムでは、厳密なトランザクションの一貫性を実現することが非常に困難な可能性があります。In a distributed system, it can be very difficult to achieve strong transactional consistency. 補正トランザクションは、各手順で元に戻すことができる一連の小規模な個別トランザクションを使用することで、一貫性を実現する方法です。Compensating transactions are a way to achieve consistency by using a series of smaller, individual transactions that can be undone at each step.

たとえば、旅行を予約する場合、ユーザーは車、ホテルの客室、航空便を予約する可能性があります。For example, to book a trip, a customer might reserve a car, a hotel room, and a flight. これらいずれかの手順に失敗した場合、操作全体が失敗します。If any of these steps fails, the entire operation fails. 操作全体に単一の分散トランザクションを使用するのではなく、各手順に補正トランザクションを定義することができます。Instead of trying to use a single distributed transaction for the entire operation, you can define a compensating transaction for each step. たとえば、車の予約を元に戻すには、予約を取り消します。For example, to undo a car reservation, you cancel the reservation. 操作全体を完了するために、コーディネーターは各手順を実行します。In order to complete the whole operation, a coordinator executes each step. いずれかの手順が失敗すると、コーディネーターは補正トランザクションを適用し、完了したすべての手順を元に戻します。If any step fails, the coordinator applies compensating transactions to undo any steps that were completed.

詳細については、「Compensating Transaction Pattern」(補正トランザクション パターン) を参照してください。For more information, see Compensating Transaction Pattern.

回復性のテストTesting for resiliency

一般的に、アプリケーション機能のテストと同じ方法 (単体テストの実行など) で回復性をテストすることはできません。Generally, you can't test resiliency in the same way that you test application functionality (by running unit tests and so on). 代わりに、断続的にのみ発生する障害条件下で、エンドツーエンドのワークロードが動作する方法をテストする必要があります。Instead, you must test how the end-to-end workload performs under failure conditions which only occur intermittently.

テストは反復的なプロセスです。Testing is an iterative process. アプリケーションをテストし、結果を測定し、結果のすべてのエラーを分析して対応し、プロセスを繰り返します。Test the application, measure the outcome, analyze and address any failures that result, and repeat the process.

フォールト挿入テストFault injection testing. 実際のエラーをトリガーするまたはシミュレートすることによって、システムの障害への回復性をテストすることができます。Test the resiliency of the system during failures, either by triggering actual failures or by simulating them. テストされる一般的な障害シナリオを次に示します。Here are some common failure scenarios to test:

  • VM インスタンスのシャットダウン。Shut down VM instances.
  • プロセスのクラッシュ。Crash processes.
  • 証明書の期限切れ。Expire certificates.
  • アクセス キーの変更。Change access keys.
  • ドメイン コントローラー上の DNS サービスのシャットダウン。Shut down the DNS service on domain controllers.
  • RAM やスレッド数など、使用可能なシステム リソースの制限。Limit available system resources, such as RAM or number of threads.
  • ディスクのマウント解除。Unmount disks.
  • VM の再デプロイ。Redeploy a VM.

回復時間を測定し、ビジネス要件を満たしていることを確認します。Measure the recovery times and verify that your business requirements are met. 障害モードの組み合わせもテストします。Test combinations of failure modes as well. 障害が連鎖しないこと、分離された方法で処理されることを確認します。Make sure that failures don't cascade, and are handled in an isolated way.

これが、設計フェーズで潜在的な障害点を分析することが重要なもう 1 つの理由です。This is another reason why it's important to analyze possible failure points during the design phase. この分析結果をテスト計画に反映させることをお勧めします。The results of that analysis should be inputs into your test plan.

ロード テストLoad testing. Visual Studio Team ServicesApache JMeter などのツールを使用してアプリケーションのロード テストを行います。Load test the application using a tool such as Visual Studio Team Services or Apache JMeter. ロード テストは、過負荷状態またはサービスの調整が行われているバックエンド データベースなど、負荷がかかった状態でのみ発生する障害を特定するために重要です。Load testing is crucial for identifying failures that only happen under load, such as the backend database being overwhelmed or service throttling. 運用データまたは運用データに可能な限り近い総合的なデータを使用して、ピーク負荷の場合をテストします。Test for peak load, using production data or synthetic data that is as close to production data as possible. 目標は、実際の条件下でアプリケーションがどのように動作するかを確認することです。The goal is to see how the application behaves under real-world conditions.

回復性のデプロイResilient deployment

アプリケーションを運用環境にデプロイした場合、更新プログラムがエラーの原因になることがあります。Once an application is deployed to production, updates are a possible source of errors. 最悪の場合には、更新プログラムの不良でダウンタイムが発生することがあります。In the worst case, a bad update can cause downtime. この問題を回避するために、デプロイ プロセスを予測可能で反復的にする必要があります。To avoid this, the deployment process must be predictable and repeatable. デプロイには、Azure リソースのプロビジョニング、アプリケーション コードのデプロイ、構成設定の適用が含まれます。Deployment includes provisioning Azure resources, deploying application code, and applying configuration settings. 1 つの更新プログラムで、この 3 つすべて、または一部が行われることがあります。An update may involve all three, or a subset.

手動のデプロイはエラーが起きやすいという点が重要です。The crucial point is that manual deployments are prone to error. そのため、必要に応じて実行可能で、何かが失敗した場合に再実行できる自動的なべき等プロセスを用意することをお勧めします。Therefore, it's recommended to have an automated, idempotent process that you can run on demand, and re-run if something fails.

  • Resource Manager テンプレートを使用して、Azure リソースのプロビジョニングを自動化します。Use Resource Manager templates to automate provisioning of Azure resources.
  • Azure Automation Desired State Configuration (DSC) を使用して VM を構成します。Use Azure Automation Desired State Configuration (DSC) to configure VMs.
  • アプリケーション コードに自動デプロイ プロセスを使用します。Use an automated deployment process for application code.

コードとしてのインフラストラクチャイミュータブル インフラストラクチャという回復性のデプロイに関連する 2 つの概念があります。Two concepts related to resilient deployment are infrastructure as code and immutable infrastructure.

  • コードとしてのインフラストラクチャは、コードを使用してインフラストラクチャのプロビジョニングと構成を行う手法です。Infrastructure as code is the practice of using code to provision and configure infrastructure. コードとしてのインフラストラクチャには、宣言型の方法、命令型の方法 (またはその両方の組み合わせ) を使用することができます。Infrastructure as code may use a declarative approach or an imperative approach (or a combination of both). 宣言型の方法の例として、Resource Manager テンプレートがあります。Resource Manager templates are an example of a declarative approach. PowerShell スクリプトは、命令型の方法の一例です。PowerShell scripts are an example of an imperative approach.
  • イミュータブル インフラストラクチャは、運用環境にデプロイした後にインフラストラクチャを変更すべきではないという原則です。Immutable infrastructure is the principle that you shouldn’t modify infrastructure after it’s deployed to production. そうしないと、場当たりの変更が適用され、変更内容を正確に把握しづらくなり、システムについて論理的に判断しづらくなる状態に陥る可能性があります。Otherwise, you can get into a state where ad hoc changes have been applied, so it's hard to know exactly what changed, and hard to reason about the system.

もう 1 つの問題は、アプリケーションの更新プログラムを展開する方法です。Another question is how to roll out an application update. ブルーグリーン デプロイまたはカナリア リリースなどの手法を採用して高度に制御された方法で更新プログラムをプッシュし、不適切なデプロイの考えられる影響を最小限に抑えることをお勧めします。We recommend techniques such as blue-green deployment or canary releases, which push updates in highly controlled way to minimize possible impacts from a bad deployment.

  • ブルーグリーン デプロイは、ライブ アプリケーションとは別の運用環境に更新プログラムをデプロイする手法です。Blue-green deployment is a technique where an update is deployed into a production environment separate from the live application. デプロイの検証が完了したら、トラフィック ルーティングを更新されたバージョンに切り替えます。After you validate the deployment, switch the traffic routing to the updated version. たとえば、Azure App Service Web Apps を使用すると、このステージング スロットが可能になります。For example, Azure App Service Web Apps enables this with staging slots.
  • カナリア リリースは、ブルーグリーン デプロイと似ています。Canary releases are similar to blue-green deployments. すべてのトラフィックを更新されたバージョンに切り替えるのではなく、トラフィックの一部を新しいデプロイにルーティングすることで更新プログラムを少数のユーザーに展開します。Instead of switching all traffic to the updated version, you roll out the update to a small percentage of users, by routing a portion of the traffic to the new deployment. 問題が発生した場合は、以前のデプロイに戻します。If there is a problem, back off and revert to the old deployment. 問題が発生しない場合は、より多くのトラフィックを新しいバージョンにルーティングします。トラフィックの 100% になるまでこの手順を実行します。Otherwise, route more of the traffic to the new version, until it gets 100% of the traffic.

どの方法を採用する場合でも、新しいバージョンが機能しなかった場合に最後の正常なデプロイに戻すことができるようにします。Whatever approach you take, make sure that you can roll back to the last-known-good deployment, in case the new version is not functioning. また、エラーが発生した場合、アプリケーション ログでエラーの原因となったバージョンを特定できるようにします。Also, if errors occur, the application logs must indicate which version caused the error.

監視と診断Monitoring and diagnostics

監視と診断は回復性にとって非常に重要です。Monitoring and diagnostics are crucial for resiliency. 何かが失敗した場合、失敗したことを把握し、障害の原因を分析する必要があります。If something fails, you need to know that it failed, and you need insights into the cause of the failure.

大規模な分散システムの監視は、大きな課題です。Monitoring a large-scale distributed system poses a significant challenge. 数十単位の VM で実行されるアプリケーションを例にして説明します。— 各 VM 1 つずつにログを記録し、ログ ファイルを確認し、問題を解決することは実用的ではありません。Think about an application that runs on a few dozen VMs — it's not practical to log into each VM, one at a time, and look through log files, trying to troubleshoot a problem. さらに、VM インスタンス数はおそらく静的ではありません。Moreover, the number of VM instances is probably not static. アプリケーションのスケールインとスケールアウトで VM 数は増減し、インスタンスが失敗して再プロビジョニングが必要になることがあります。VMs get added and removed as the application scales in and out, and occasionally an instance may fail and need to be reprovisioned. さらに、一般的なクラウド アプリケーションは複数のデータ ストア (App Storage、SQL Database、Cosmos DB、Redis Cache) を使用することや、単一のユーザー アクションが複数のサブシステムに広がることがあります。In addition, a typical cloud application might use multiple data stores (Azure storage, SQL Database, Cosmos DB, Redis cache), and a single user action may span multiple subsystems.

監視と診断プロセスは、いくつかの異なる段階があるパイプラインと考えることができます。You can think of the monitoring and diagnostics process as a pipeline with several distinct stages:

複合 SLA

  • インストルメンテーションInstrumentation. 監視と診断の生データは、多様なソースに由来します。たとえば、アプリケーション ログ、Web サーバー ログ、OS のパフォーマンス カウンター、データベース ログ、Azure プラットフォームに組み込まれている診断などです。The raw data for monitoring and diagnostics comes from a variety of sources, including application logs, web server logs, OS performance counters, database logs, and diagnostics built into the Azure platform. Most Azure サービスには、問題の原因特定に使用できる診断機能があります。Most Azure services have a diagnostics feature that you can use to determine the cause of problems.
  • 収集と保存Collection and storage. 生インストルメンテーション データは多様な場所に多様な形式で保持される可能性があります (たとえば、アプリケーション トレース ログ、IIS ログ、パフォーマンス カウンターなど)。Raw instrumentation data can be held in various locations and with various formats (e.g., application trace logs, IIS logs, performance counters). このようなさまざまなソースは収集され、統合されて、信頼性の高いストレージに格納されます。These disparate sources are collected, consolidated, and put into reliable storage.
  • 分析と診断Analysis and diagnosis. データの統合後は、分析して問題を解決し、アプリケーションの正常性の全体を把握することができます。After the data is consolidated, it can be analyzed to troubleshoot issues and provide an overall view of application health.
  • 視覚化とアラートVisualization and alerts. この段階では、オペレーターが問題や傾向にすばやく気づくことができる方法で利用統計情報が表示されます。In this stage, telemetry data is presented in such a way that an operator can quickly notice problems or trends. たとえば、ダッシュボードや電子メールのアラートがあります。Example include dashboards or email alerts.

監視は障害の検出と同じではありません。Monitoring is not the same as failure detection. たとえば、アプリケーションが一時的なエラーを検出して再試行し、ダウンタイムが発生しないことがあります。For example, your application might detect a transient error and retry, resulting in no downtime. それでも再試行操作はログに記録されるので、エラー率を監視して、アプリケーション正常性の全体像を把握することができます。But it should also log the retry operation, so that you can monitor the error rate, in order to get an overall picture of application health.

アプリケーション ログは、診断データの重要なソースです。Application logs are an important source of diagnostics data. アプリケーションのログ記録には、次のようなベスト プラクティスがあります。Best practices for application logging include:

  • 運用環境でログを記録します。Log in production. そうしないと、最も必要な場合に洞察できません。Otherwise, you lose insight where you need it most.
  • サービスの境界でイベントのログを記録します。Log events at service boundaries. フローがサービス境界をまたがる関連付け ID を含めます。Include a correlation ID that flows across service boundaries. トランザクション フローが複数のサービスを経由し、いずれかが失敗した場合、関連付け ID でトランザクションが失敗した理由を特定できます。If a transaction flows through multiple services and one of them fails, the correlation ID will help you pinpoint why the transaction failed.
  • セマンティック ログ (構造化ログとも呼ばれます) を使用します。Use semantic logging, also known as structured logging. 構造化されていないログの場合、ログ データの使用と分析の自動化が困難です。こうした自動化はクラウド規模で必要になります。Unstructured logs make it hard to automate the consumption and analysis of the log data, which is needed at cloud scale.
  • 非同期のログ記録を使用します。Use asynchronous logging. そうしないと、ログ アプリケーションによって、ログ記録イベントの書き込みを待機中に要求がブロックされ、要求がバックアップされ、アプリケーションで障害が発生する原因になる可能性があります。Otherwise, the logging system itself can cause the application to fail by causing requests to back up, as they block while waiting to write a logging event.
  • アプリケーションのログ記録は、監査と同じではありません。Application logging is not the same as auditing. 監査は、コンプライアンスまたは法規制上の理由で行われることがあります。Auditing may be done for compliance or regulatory reasons. そのため、監査レコードは完全である必要があります。トランザクションの処理中に削除が発生することは許容されません。As such, audit records must be complete, and it's not acceptible to drop any while processing transactions. アプリケーションに監査が必要な場合、診断ログとは別に維持する必要があります。If an application requires auditing, this should be kept separate from diagnostics logging.

監視と診断の詳細については、「Monitoring and diagnostics guidance」(監査と診断のガイダンス) を参照してください。For more information about monitoring and diagnostics, see Monitoring and diagnostics guidance.

手動の障害対応Manual failure responses

これまでのセクションでは、高可用性に重要な自動的な復旧戦略を中心に説明してきましたが、Previous sections have focused on automated recovery strategies, which are critical for high availability. 手動操作が必要な場合もあります。However, sometimes manual intervention is needed.

  • アラートAlerts. アプリケーションで、積極的な介入が必要な可能性がある警告の兆候を監視します。Monitor your application for warning signs that may require proactive intervention. たとえば、SQL Database または Cosmos DB がアプリケーションを常に調整している場合は、データベース容量の増加や、クエリの最適化が必要な可能性があります。For example, if you see that SQL Database or Cosmos DB consistently throttles your application, you might need to increase your database capacity or optimize your queries. この例では、アプリケーションが調整エラーを透過的に処理している場合でも、利用統計情報でアラートが報告されるので、対応することができます。In this example, even though the application might handle the throttling errors transparently, your telemetry should still raise an alert so that you can follow up.
  • 手動フェールオーバーManual failover. 一部のシステムは自動的にフェールオーバーせず、手動フェールオーバーが必要です。Some systems cannot fail over automatically and require a manual failover.
  • 運用準備状況のテストOperational readiness testing. アプリケーションがセカンダリ リージョンにフェールオーバーした場合、運用準備状況のテストを実行してから、プライマリ リージョンにフェールバックすることをお勧めします。If your application fails over to a secondary region, you should perform an operational readiness test before you fail back to the primary region. テストでは、プライマリ リージョンが正常で、トラフィックを再び受け取る準備が整っていることを確認します。The test should verify that the primary region is healthy and ready to receive traffic again.
  • データ整合性チェックData consistency check. データ ストアで障害が発生した場合、特にデータがレプリケートされた場合には、ストアを再び使用可能な状態にするときにデータに整合性がある必要があります。If a failure happens in a data store, there may be data inconsistencies when the store becomes available again, especially if the data was replicated.
  • バックアップからの復元Restoring from backup. たとえば、SQL Database で地域的な停電が発生した場合、最新のバックアップからデータベースの geo リストアを実行する方法があります。For example, if SQL Database experiences a regional outage, you can geo-restore the database from the latest backup.

ディザスター リカバリー計画を文書化し、テストします。Document and test your disaster recovery plan. アプリケーションの障害によるビジネスの影響を評価します。Evaluate the business impact of application failures. できるだけ多くのプロセスを自動化し、手動の手順を文書化します。たとえば、バックアップからの手動のフェールオーバーやデータの復元などです。Automate the process as much as possible, and document any manual steps, such as manual failover or data restoration from backups. ディザスター リカバリー プロセスは定期的にテストし、計画の検証と改善を行います。Regularly test your disaster recovery process to validate and improve the plan.

概要Summary

この記事では、クラウド固有の一部の課題を特に取り上げながら、包括的な観点から回復性について説明しました。This article discussed resiliency from a holistic perspective, emphasizing some of the unique challenges of the cloud. たとえば、クラウド コンピューティングの分散の特性、汎用的なハードウェアの使用、一時的なネットワーク障害の存在などです。These include the distributed nature of cloud computing, the use of commodity hardware, and the presence of transient network faults.

この記事の主な点を次に示します。Here are the major points to take away from this article:

  • 回復性によって可用性が高くなり、障害からの平均復旧時間が短くなります。Resiliency leads to higher availability, and lower mean time to recover from failures.
  • クラウドで回復性を実現するには、従来のオンプレミス ソリューションのさまざまな手法が必要です。Achieving resiliency in the cloud requires a different set of techniques from traditional on-premises solutions.
  • 偶発的に回復性が実現することはありません。Resiliency does not happen by accident. 初期段階から設計し、構築する必要があります。It must be designed and built in from the start.
  • 回復性は、計画、コーディングから運用まで、アプリケーションのライフサイクルのあらゆる部分に関係します。Resiliency touches every part of the application lifecycle, from planning and coding to operations.
  • テストと監視をお勧めします。Test and monitor!