信頼性の高い Azure アプリケーションの設計Designing reliable Azure applications

クラウド内で信頼性の高いアプリケーションを構築することは、従来のアプリケーション開発とは異なります。Building a reliable application in the cloud is different from traditional application development. 従来は、スケールアップのためによりハイエンドのハードウェアを購入する場合がありましたが、クラウド環境では、スケールアップではなくスケールアウトを行います。While historically you may have purchased higher-end hardware to scale up, in a cloud environment you scale out instead of up. 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。Instead of trying to prevent failures altogether, the goal is to minimize the effects of a single failing component.

信頼性の高いアプリケーションとは、次のとおりです。Reliable applications are:

  • 回復性があり、障害から適切に復旧します。アプリケーションは完全に復旧するまで、ダウンタイムおよびデータ損失を最小限に抑えて機能し続けます。Resilient and recover gracefully from failures, and they continue to function with minimal downtime and data loss before full recovery.
  • 高可用性 (HA) があり、大幅なダウンタイムもなく正常な状態で設計どおり実行されます。Highly available (HA) and run as designed in a healthy state with no significant downtime.

これらの要素の連携—およびコストに与える影響—について理解することは、信頼性の高いアプリケーションを構築する上で不可欠です。Understanding how these elements work together — and how they affect cost — is essential to building a reliable application. これは、許容されるダウンタイムの程度、会社が負担する潜在的なコスト、および復旧中に必要な機能を判断する場合に役立ちます。It can help you determine how much downtime is acceptable, the potential cost to your business, and which functions are necessary during a recovery.

この記事では、Azure アプリケーションの設計プロセスの各ステップに信頼性を組み込む方法について概説します。This article provides a brief overview of building reliability into each step of the Azure application design process. 各セクションには、プロセス内のその特定のステップに信頼性を統合する方法について詳述した記事へのリンクが含まれています。Each section includes a link to an in-depth article on how to integrate reliability into that specific step in the process. 個々の Azure サービスでの信頼性に関する考慮事項については、「特定の Azure サービスの回復性のチェックリスト」を参照してください。If you're looking for reliability considerations for individual Azure services, review the Resiliency checklist for specific Azure services.

信頼性の構築Build for reliability

このセクションでは、信頼性の高い Azure アプリケーションを構築するための 6 つの手順について説明します。This section describes six steps for building a reliable Azure application. 各ステップは、プロセスや用語を詳しく定義したセクションとリンクされています。Each step links to a section that further defines the process and terms.

  1. 要件を定義する。 Define requirements. 分解したワークロードやビジネス ニーズに基づいて可用性と復旧の要件を作成します。Develop availability and recovery requirements based on decomposed workloads and business needs.
  2. アーキテクチャのベスト プラクティスを使用する。 Use architectural best practices. 実証済みプラクティスに従い、アーキテクチャ内で考えられる障害点を識別し、アプリケーションが障害に対応する方法を決定します。Follow proven practices, identify possible failure points in the architecture, and determine how the application will respond to failure.
  3. シミュレーションと強制フェールオーバーをテストする。 Test with simulations and forced failovers. 障害をシミュレートし、強制フェールオーバーをトリガーし、これらの障害の検出テストおよび障害からの復旧テストを行います。Simulate faults, trigger forced failovers, and test detection and recovery from these failures.
  4. アプリケーションの一貫性をデプロイする。 Deploy the application consistently. 信頼性が高く反復可能なプロセスを使用して運用環境にリリースします。Release to production using reliable and repeatable processes.
  5. アプリケーションの正常性を監視する。 Monitor application health. 障害を検出し、潜在的な障害の指標を監視し、ご利用のアプリケーションの正常性を評価します。Detect failures, monitor indicators of potential failures, and gauge the health of your applications.
  6. 障害と災害に対応する。 Respond to failures and disasters. 障害が発生した日時を特定し、確定した戦略に基づいて障害に対処する方法を決定します。Identify when a failure occurs, and determine how to address it based on established strategies.

要件の定義Define requirements

ビジネス ニーズを特定し、それに応えるための信頼性計画を作成します。Identify your business needs, and build your reliability plan to address them. 以下、具体例に沿って説明します。Consider the following:

  • ワークロードと使用状況を特定する。Identify workloads and usage. "ワークロード" とは、ビジネス ロジックとデータ ストレージの要件の観点から、他のタスクとは論理的に区別される独特な機能またはタスクです。A workload is a distinct capability or task that is logically separated from other tasks, in terms of business logic and data storage requirements. 各ワークロードでは、可用性、スケーラビリティ、データの一貫性、およびディザスター リカバリーの要件がそれぞれ異なります。Each workload has different requirements for availability, scalability, data consistency, and disaster recovery.

  • 使用状況パターンについて計画する。Plan for usage patterns. 使用状況パターンもまた、要件に関与します。Usage patterns also play a role in requirements. 重要な期間と重大でない期間中での要件の違いを特定します。Identify differences in requirements during critical and non-critical periods. たとえば、納税申告用アプリケーションは、申告期間中はフェールバックできません。For example, a tax-filing application can't fail during a filing deadline. 稼働時間を確保するには、1 つのリージョンで障害が発生した場合に備えていくつかのリージョン間での冗長性を計画します。To ensure uptime, plan redundancy across several regions in case one fails. 逆に、重大でない期間中はコストを最小限に抑えるために、ご利用のアプリケーションを 1 つのリージョンで実行できます。Conversely, to minimize costs during non-critical periods, you can run your application in a single region.

  • 可用性のメトリックを確定する — "平均復旧時間" (MTTR) と "平均故障間隔" (MTBF)。Establish availability metrics — mean time to recovery (MTTR) and mean time between failures (MTBF). MTTR は、障害発生後、コンポーネントを復元するために必要な平均時間です。MTTR is the average time it takes to restore a component after a failure. MTBF とは、次の障害が発生するまでに合理的に予期されるコンポーネントの稼働時間です。MTBF is how long a component can reasonably expect to last between outages. これらのメジャーを使用して、冗長性を追加する場所を特定し、顧客に合ったサービス レベル アグリーメント (SLA) を決定します。Use these measures to determine where to add redundancy and to determine service-level agreements (SLAs) for customers.

  • 復旧メトリックを確定する — 目標復旧時間と復旧ポイントの目標 (RPO)。Establish recovery metrics — recovery time objective and recovery point objective (RPO). RTO は、インシデントの発生後に、アプリケーションを使用不可状態にすることができる最大許容時間です。RTO is the maximum acceptable time an application can be unavailable after an incident. RPO は、障害発生時に許容できるデータ損失の最大期間です。RPO is the maximum duration of data loss that is acceptable during a disaster. これらの値を取得するには、リスクの評価を実施して、組織でのダウンタイムまたはデータ損失のコストとリスクを確実に把握してください。To derive these values, conduct a risk assessment and make sure you understand the cost and risk of downtime or data loss in your organization.

    注意

    高可用性の設定内の任意の重要なコンポーネントの MTTR がシステム RTO を超えた場合、システム内の障害によって、許容できないビジネスの中断が発生する可能性があります。If the MTTR of any critical component in a highly available setup exceeds the system RTO, a failure in the system might cause an unacceptable business disruption. つまり、定義されている RTO 内でシステムを復旧させることができなくなります。That is, you can't restore the system within the defined RTO.

  • ワークロードの可用性の目標を決定する。Determine workload availability targets. アプリケーションのアーキテクチャが自社のビジネス要件を確実に満たすようにするには、ワークロードごとにターゲット SLA を定義します。To ensure that application architecture meets your business requirements, define target SLAs for each workload. アプリケーションの依存関係に加えて、可用性の要件を満たす上でのコストと複雑さを考慮します。Account for the cost and complexity of meeting availability requirements, in addition to application dependencies.

  • サービス レベル アグリーメントを理解する。Understand service-level agreements. Azure では、稼働時間と接続に関する Microsoft の確約内容が SLA に記載されています。In Azure, the SLA describes the Microsoft commitments for uptime and connectivity. 特定のサービスの SLA が 99.9% の場合は、そのサービスを 99.9% の時間、使用可能であることが期待できるということになります。If the SLA for a particular service is 99.9 percent, you should expect the service to be available 99.9 percent of the time.

    使用するソリューション内のワークロードごとに独自のターゲット SLA を定義すれば、アーキテクチャがビジネス要件を満たしているかどうかを判定できます。Define your own target SLAs for each workload in your solution, so you can determine whether the architecture meets the business requirements. たとえば、ワークロードは 99.99% の稼働時間を必要としているが、そのワークロードは SLA が 99.9% のサービスに依存している場合、そのサービスをシステムの単一障害点にしてはなりません。For example, if a workload requires 99.99 percent uptime but depends on a service with a 99.9 percent SLA, that service can't be a single point of failure in the system.

信頼性の高いアプリケーションの開発要件の詳細については、「Developing requirements for resilient Azure applications」 (回復性がある Azure アプリケーションの開発要件) を参照してください。For more information about developing requirements for reliable applications, see Developing requirements for resilient Azure applications.

アーキテクチャのベスト プラクティスを使用するUse architectural best practices

アーキテクチャ フェーズ中には、ビジネス要件を満たし、障害点を特定し、障害の範囲を最小限に抑えるプラクティスを実装することに専念します。During the architectural phase, focus on implementing practices that meet your business requirements, identify failure points, and minimize the scope of failures.

  • 障害モード分析 (FMA) を実行する。Perform a failure mode analysis (FMA). FMA では、設計の初期段階でアプリケーションに回復性が組み込まれます。FMA builds resiliency into an application early in the design stage. これは、アプリケーションで発生する可能性がある障害の種類、それぞれが及ぼす潜在的な影響、および考えられる復旧戦略を特定するのに役立ちます。It helps you identify the types of failures your application might experience, the potential effects of each, and possible recovery strategies.

  • 冗長性のプランを作成する。Create a redundancy plan. ワークロードごとに必要な冗長性のレベルは、ビジネスのニーズおよび要素に依存し、アプリケーションの全体的なコストに反映されます。The level of redundancy required for each workload depends on your business needs and factors into the overall cost of your application.

  • スケーラビリティを考慮した設計をする。Design for scalability. クラウド アプリケーションは、使用状況の変化に応じてスケーリングできる必要があります。A cloud application must be able to scale to accommodate changes in usage. 個別のコンポーネントから初め、必要に応じて、負荷の変化に自動的に対応するアプリケーションを設計します。Begin with discrete components, and design the application to respond automatically to load changes whenever possible. 設計中は、将来的に容易に拡張できるようにスケーリングの制限を念頭に置いてください。Keep scaling limits in mind during design so you can expand easily in the future.

  • サブスクリプションおよびサービスの要件について計画する。Plan for subscription and service requirements. ストレージ、接続、スループットなどの自社のビジネス要件を満たす十分なリソースをプロビジョニングするために追加のサブスクリプションが必要な場合があります。You might need additional subscriptions to provision enough resources to meet your business requirements for storage, connections, throughput, and more.

  • 負荷分散を使用して要求を分散する。Use load-balancing to distribute requests. 負荷分散は、正常でないインスタンスをローテーションから除去することで、アプリケーションの要求を正常なサービス インスタンスに分散します。Load-balancing distributes your application's requests to healthy service instances by removing unhealthy instances from rotation.

  • 回復性戦略を実装する。Implement resiliency strategies. 回復性とは、障害から回復して動作を続行する、システムの能力です。Resiliency is the ability of a system to recover from failures and continue to function. 重要なリソースの分離、補正トランザクションの使用、非同期操作の実行などの回復性設計パターンを必要に応じて実装します。Implement resiliency design patterns, such as isolating critical resources, using compensating transactions, and performing asynchronous operations whenever possible.

  • 設計に可用性の要件を組み込む。Build availability requirements into your design. 可用性とは、ご利用のシステムが動作し実際に使用可能である時間の割合です。Availability is the proportion of time your system is functional and working. アプリケーションの可用性がご利用のサービス レベル アグリーメントに確実に準拠するように対策を講じます。Take steps to ensure that application availability conforms to your service-level agreement. たとえば、単一障害点の回避、サービス レベルの目標によるワークロードの分解、大量のユーザーの調整などが挙げられます。For example, avoid single points of failure, decompose workloads by service-level objective, and throttle high-volume users.

  • ご利用のデータを管理する。Manage your data. データを格納、バックアップ、およびレプリケートする方法が重要です。How you store, back up, and replicate data is critical.

    • ご利用のアプリケーション データに合ったレプリケーション方法を選択する。Choose replication methods for your application data. ご利用のアプリケーション データは、さまざまなデータ ストアに格納され、さまざまな可用性の要件を持つ場合があります。Your application data is stored in various data stores and might have different availability requirements. データ ストアの種類ごとにレプリケーションの方法と場所を評価して、それらが要件を確実に満たすようにします。Evaluate the replication methods and locations for each type of data store to ensure that they satisfy your requirements.
    • ご利用のフェールオーバーおよびフェールバックのプロセスをドキュメント化してテストする。Document and test your failover and failback processes. 新しいデータ ストアにフェールオーバーする手順を明確に文書化し、それを定期的にテストして、手順どおりに正確および簡単に行えることを確認します。Clearly document instructions to fail over to a new data store, and test them regularly to make sure they are accurate and easy to follow.
    • ご利用のデータを保護する。Protect your data. データのバックアップと検証を定期的に行うと共に、運用環境データとバックアップ データの両方にアクセスできる単一のユーザー アカウントがないことを確認します。Back up and validate data regularly, and make sure no single user account has access to both production and backup data.
    • データの復旧について計画する。Plan for data recovery. バックアップおよびレプリケーション戦略が、ご利用のサービス レベル要件を満たすデータ復旧時間に対応していることを確認します。Make sure that your backup and replication strategy provides for data recovery times that meet your service-level requirements. アプリケーションで使用されるデータのすべての種類 (参照データやデータベースなど) を考慮します。Account for all types of data your application uses, including reference data and databases.

信頼性の高いアプリケーションの設計の詳細については、「Architecting Azure applications for resiliency and availability」 (回復性と可用性を考慮した Azure アプリケーションの設計) を参照してください。For more information about architecting reliable applications, see Architecting Azure applications for resiliency and availability.

シミュレーションと強制フェールオーバーをテストするTest with simulations and forced failovers

信頼性のテストでは、断続的にしか発生しない障害条件下で、エンドツーエンドのワークロードがどのように実行されるかを測定する必要があります。Testing for reliability requires measuring how the end-to-end workload performs under failure conditions that only occur intermittently.

  • 実際の障害をトリガーするか、またはそれらをシミュレートすることにより、一般的な障害シナリオをテストする。Test for common failure scenarios by triggering actual failures or by simulating them. フォールト挿入テストを使用して、一般的なシナリオ (障害の組み合わせを含む) と復旧時間をテストします。Use fault injection testing to test common scenarios (including combinations of failures) and recovery time.
  • 負荷がかかっているときのみ発生する障害を特定する。Identify failures that occur only under load. 運用データまたは運用データに可能な限り近い合成データを使用して、ピーク負荷の場合をテストすることで、実際の条件下でアプリケーションがどのように動作するかを確認します。Test for peak load, using production data or synthetic data that is as close to production data as possible, to see how the application behaves under real-world conditions.
  • ディザスター リカバリーの訓練を実施する。Run disaster recovery drills. ディザスター リカバリー計画を策定してから、それを定期的にテストして、機能することを確認します。Have a disaster recovery plan in place, and test it periodically to make sure it works.
  • フェールオーバーとフェールバックのテストを実行する。Perform failover and failback testing. アプリケーションの依存サービスのフェールオーバーとフェールバックが、確実に正しい順序で行われるようにしてください。Ensure that your application's dependent services fail over and fail back in the correct order.
  • シミュレーションを実行する。Run simulation tests. 実際のシナリオをテストすることで、対処する必要がある問題を明らかにすることができます。Testing real-life scenarios can highlight issues that need to be addressed. シナリオは、制御可能なものであり、ビジネスの中断を招かないことが必要です。Scenarios should be controllable and non-disruptive to the business. シミュレーション テストの計画を管理者に通知します。Inform management of simulation testing plans.
  • 正常性プローブをテストする。Test health probes. ロード バランサーおよびトラフィック マネージャーによって重要なシステム コンポーネントがチェックされるように、正常性プローブを構成します。Configure health probes for load balancers and traffic managers to check critical system components. それをテストして、適切に応答することを確認してください。Test them to make sure that they respond appropriately.
  • 監視システムをテストする。Test monitoring systems. 潜在的な障害を識別するのに役立つ重要な情報および正確なデータが監視システムから確実にレポートされるようにしてください。Be sure that monitoring systems are reliably reporting critical information and accurate data to help identify potential failures.
  • テスト シナリオにサード パーティのサービスを含める。Include third-party services in test scenarios. 復旧に加えて、サード パーティ サービスの中断が原因で発生の可能性がある障害点もテストします。Test possible points of failure due to third-party service disruption, in addition to recovery.

テストは反復的なプロセスです。Testing is an iterative process. アプリケーションをテストし、結果を測定し、障害があればそれを分析して対応して、さらにプロセスを繰り返します。Test the application, measure the outcome, analyze and address any failures, and repeat the process.

アプリケーションの信頼性のテストの詳細については、「Testing Azure applications for resiliency and availability」 (アプリケーションの回復性と可用性のテスト) を参照してください。For more information about testing for application reliability, see Testing Azure applications for resiliency and availability.

アプリケーションの一貫性をデプロイするDeploy the application consistently

デプロイには、Azure リソースのプロビジョニング、アプリケーション コードのデプロイ、構成設定の適用が含まれます。Deployment includes provisioning Azure resources, deploying application code, and applying configuration settings. 更新プログラムでは、この 3 つのタスクすべて、またはその一部が必要となる場合があります。An update may involve all three tasks or a subset of them.

アプリケーションを運用環境にデプロイした後で、更新プログラムがエラーの原因になることがあります。After an application is deployed to production, updates are a possible source of errors. 予測可能および繰り返し可能なデプロイ プロセスを使用してエラーを最小限に抑えます。Minimize errors with predictable and repeatable deployment processes.

  • アプリケーションのデプロイ プロセスを自動化する。Automate your application deployment process. 可能な限り多くのプロセスを自動化します。Automate as many processes as possible.
  • 可用性を最大限に高められるようにリリース プロセスを設計する。Design your release process to maximize availability. リリース プロセスでデプロイ中にサービスをオフラインにする必要がある場合、それがオンラインに戻るまでアプリケーションは使用できなくなります。If your release process requires services to go offline during deployment, your application is unavailable until they come back online. プラットフォームのステージングおよび運用機能を利用します。Take advantage of platform staging and production features. ブルー グリーン リリースまたはカナリヤ リリースを使用します。そうすれば、障害が発生しても、更新プログラムを迅速にロールバックできます。Use blue-green or canary releases to deploy updates, so if a failure occurs, you can quickly roll back the update.
  • デプロイのロールバック計画を立てます。Have a rollback plan for deployment. デプロイが失敗した場合に、直前の正常なバージョンに戻して、ダウンタイムを最小限に抑えるようにロールバック プロセスを設計してください。Design a rollback process to return to a last known good version and to minimize downtime if a deployment fails.
  • デプロイのログを記録して監査する。Log and audit deployments. ステージング デプロイ手法を使用する場合、運用環境では複数のバージョンのアプリケーションが実行されることになります。If you use staged deployment techniques, more than one version of your application is running in production. できるだけ多くのバージョン固有の情報を把握するため、確実なログ記録の方法を実装してください。Implement a robust logging strategy to capture as much version-specific information as possible.
  • アプリケーションのリリース プロセスを文書化する。Document the application release process. リリース プロセスを明確に定義して文書化し、オペレーション チーム全体が確実に利用できるようにしてください。Clearly define and document your release process, and ensure that it's available to the entire operations team.

アプリケーションの信頼性とデプロイの詳細については、「Deploying Azure applications for resiliency and availability」 (回復性と可用性を考慮した Azure アプリケーションのデプロイ) を参照してください。For more information about application reliability and deployment, see Deploying Azure applications for resiliency and availability.

アプリケーションの正常性を監視するMonitor application health

監視およびアラートのためのベスト プラクティスをアプリケーションに実装することで、障害を検出し、それを修正するようオペレーターに警告することができます。Implement best practices for monitoring and alerts in your application so you can detect failures and alert an operator to fix them.

  • 正常性プローブを実装して機能を確認する。Implement health probes and check functions. それをアプリケーションの外部から定期的に実行して、アプリケーションの正常性とパフォーマンスの低下を識別します。Run them regularly from outside the application to identify degradation of application health and performance.

  • 実行時間の長いワークフローを確認する。Check long-running workflows. 問題を早期に検出すると、ワークフロー全体をロールバックしたり、複数の補正トランザクションを実行したりする必要性を最小限に抑えることができます。Catching issues early can minimize the need to roll back the entire workflow or to execute multiple compensating transactions.

  • アプリケーション ログを維持する。Maintain application logs.

    • 運用環境内およびサービス境界でアプリケーションのログに記録します。Log applications in production and at service boundaries.
    • セマンティックおよび非同期のログ記録を使用します。Use semantic and asynchronous logging.
    • アプリケーション ログを監査ログから分離します。Separate application logs from audit logs.
  • リモート呼び出しの統計情報を測定し、データをアプリケーション チームと共有する。Measure remote call statistics, and share the data with the application team. 運用チームがアプリケーションの正常性を瞬時に確認できるようにするために、待機時間、スループット、99 パーセンタイルおよび 95 パーセンタイルのエラーなどのリモート呼び出しメトリックをまとめます。To give your operations team an instantaneous view into application health, summarize remote call metrics, such as latency, throughput, and errors in the 99 and 95 percentiles. 各パーセンタイル内で発生したエラーを明らかにするには、このメトリックで統計分析を実行してください。Perform statistical analysis on the metrics to uncover errors that occur within each percentile.

  • 適切な期間にわたって一時的な例外と再試行を追跡する。Track transient exceptions and retries over an appropriate time frame. 時間をかけて例外が増加する傾向は、サービスに問題があるか失敗する可能性があることを示します。A trend of increasing exceptions over time indicates that the service is having an issue and may fail.

  • 早期警告システムを設定する。Set up an early warning system. 一時的な例外やリモート呼び出しの待機時間などのアプリケーションの正常性の主要業績評価指標 (KPI) を特定し、それぞれに適切なしきい値を設定してください。Identify the key performance indicators (KPIs) of an application's health, such as transient exceptions and remote call latency, and set appropriate threshold values for each of them. しきい値に達したときに、操作にアラートを送信します。Send an alert to operations when the threshold value is reached.

  • Azure サブスクリプションの制限内で運用する。Operate within Azure subscription limits. Azure サブスクリプションには、リソース グループの数、コアの数、およびストレージ アカウントの数など、特定のリソースの種類に対する制限があります。Azure subscriptions have limits on certain resource types, such as the number of resource groups, cores, and storage accounts. リソースの種類の使用に注意してください。Watch your use of resource types.

  • サード パーティーのサービスを監視します。Monitor third-party services. 呼び出しをログに記録してから、それを一意の識別子を使用してアプリケーションの正常性と診断のログに関連付けます。Log your invocations and correlate them with your application's health and diagnostic logging using a unique identifier.

  • アプリケーションの監視および手動による復旧手順を行う複数のオペレーターをトレーニングする。Train multiple operators to monitor the application and to perform manual recovery steps. トレーニング済みのオペレーターが少なくとも 1 人以上、常に活動できる状態にあることを確認します。Make sure there is always at least one trained operator active.

アプリケーションの信頼性の監視の詳細については、Azure アプリケーションの正常性の監視に関するページを参照してください。For more information about monitoring for application reliability, see Monitoring Azure application health.

障害と災害に対応するRespond to failures and disasters

復旧計画を作成し、データの復元、ネットワーク障害、依存サービスのエラー、およびリージョン全体にわたるサービス中断がその計画で網羅されていることを確認します。Create a recovery plan, and make sure that it covers data restoration, network outages, dependent service failures, and region-wide service disruptions. 復旧戦略では、ご利用の VM、ストレージ、データベース、およびその他の Azure プラットフォーム サービスを検討します。Consider your VMs, storage, databases, and other Azure platform services in your recovery strategy.

  • Azure サポートとのやり取りについて計画する。Plan for Azure support interactions. 必要になる前に、Azure サポートに連絡するためのプロセスを確立します。Before the need arises, establish a process for contacting Azure support.
  • ディザスター リカバリー計画を文書化し、テストする。Document and test your disaster recovery plan. アプリケーションの障害がビジネスに及ぼす影響を反映したディザスター リカバリー計画を作成します。Write a disaster recovery plan that reflects the business impact of application failures. 復旧プロセスは可能な限り自動化し、手動による手順は文書化します。Automate the recovery process as much as possible, and document any manual steps. ディザスター リカバリー プロセスは定期的にテストし、計画の検証と改善を行います。Regularly test your disaster recovery process to validate and improve the plan.
  • 必要な場合に手動でフェールオーバーする。Fail over manually when required. 一部のシステムは自動的にフェールオーバーせず、手動フェールオーバーが必要です。Some systems can't fail over automatically and require a manual failover. アプリケーションがセカンダリ リージョンにフェールオーバーした場合は、運用準備テストを実行します。If an application fails over to a secondary region, perform an operational readiness test. フェールバックする前に、プライマリ リージョンが正常で、トラフィックを再び受け取る準備が整っていることを確認します。Verify that the primary region is healthy and ready to receive traffic again before failing back. アプリケーションの機能制限の内容と、一時的な問題をアプリからユーザーに通知する方法を決定します。Determine what the reduced application functionality is and how the app informs users of temporary problems.
  • アプリケーションの障害に備える。Prepare for application failure. 自動的に処理される障害、機能制限を引き起こす障害、アプリケーションを使用不能にする障害などの、障害の範囲に対して準備をします。Prepare for a range of failures, including faults that are handled automatically, those that result in reduced functionality, and those that cause the application to become unavailable. アプリケーションからユーザーに一時的な問題が通知される必要があります。The application should inform users of temporary issues.
  • データ損失から回復する。Recover from data corruption. データ ストアで障害が発生した場合、ストアを再び使用可能な状態にするとき (特にデータをレプリケートした場合) は、データに整合性があることを確認する必要があります。If a failure happens in a data store, check for data inconsistencies when the store becomes available again, especially if the data was replicated. 破損したデータをバックアップから復元します。Restore corrupt data from a backup.
  • ネットワークの停止から回復する。Recover from a network outage. キャッシュされたデータを使用すれば、ローカルでアプリケーションの機能が制限された状態で実行できる場合があります。You might be able to use cached data to run locally with reduced application functionality. そうしない場合は、アプリケーションのダウンタイムまたは別のリージョンへのフェールオーバーを検討してください。If not, consider application downtime or fail over to another region. 接続が復元されるまで、別の場所にご利用のデータを格納します。Store your data in an alternate location until connectivity is restored.
  • 依存サービスの障害から回復する。Recover from a dependent service failure. まだ利用できる機能を確認し、アプリケーションでの対処方法を決定します。Determine which functionality is still available and how the application should respond.
  • リージョン全体でのサービスの中断から回復する。Recover from a region-wide service disruption. リージョン全体にわたるサービスの中断はめったに起こりません。しかし、特に重要なアプリケーションの場合は、それに対応するための戦略が必要です。Region-wide service disruptions are uncommon, but you should have a strategy to address them, especially for critical applications. 別のリージョンへのアプリケーションの再デプロイ、またはトラフィックの再配布が可能な場合があります。You might be able to redeploy the application to another region or redistribute traffic.

障害とディザスター リカバリーに対応する方法の詳細については、「Failure and disaster recovery for Azure applications」 (Azure アプリケーションの障害とディザスター リカバリー) を参照してください。For more information about responding to failures and disaster recovery, see Failure and disaster recovery for Azure applications.

次の手順Next steps