信頼性の高い Azure アプリケーションを設計する

クラウド内で信頼性の高いアプリケーションを構築することは、従来のアプリケーション開発とは異なります。 これまでは、アプリケーション プラットフォーム全体で障害が発生する可能性を最小限に抑えるために、数レベルの冗長なよりハイエンドのハードウェアを購入していたかもしれませんが、クラウドでは、障害が発生することを事前に確認します。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 ここで考えられる失敗は、Azure の機能ではなく、高度な分散システムに固有のものです。

重要なポイント

  • 可能な場合、信頼性を向上し、コストを最適化するために、Availability Zones を使用します。
  • 障害の影響を受けた場合に動作するようにアプリケーションを設計します。
  • PaaS のネイティブの回復性機能を使用して、全体的なアプリケーションの信頼性をサポートします。
  • スケールアウトのための設計
  • 必要な容量が Azure サービスのスケール制限とクォータ内にあることを確認します。

リージョン内での Availability Zones の使用

要件によって、Availability Zones 単独で提供されるよりも高い障害分離が必要な場合は、複数のリージョンにデプロイすることを検討してください。 障害状態のフェールオーバーのために、複数のリージョンを使用する必要があります。 追加コストを考慮する必要があります。 コストの例としては、データとネットワーク、Azure Site Recovery などのサービスなどがあります。

リージョン内で Availability Zones を使用するようにアプリケーション アーキテクチャを設計します。 Availability Zones を使用すると、データセンター レベルのフォールト トレランスを提供することで、リージョン内のアプリケーションの可用性を最適化できます。 ただし、アプリケーション アーキテクチャでは、それらを効果的に使用するために、ゾーン間で依存関係を共有することはできません。

Note

Availability Zones では、各ゾーンとゾーン間の帯域幅の責任が暗黙的に分離されるため、ゾーン間で非常に 「打ち解けた」アプリケーションのパフォーマンスとコストに関する考慮事項が生じることがあります。 これは、コストを削減するために SLA を向上させるためにAvailability Zones を考慮することもできるという意味になります。

アプリケーションのパフォーマンス上の理由で、コンポーネント近接が必要かどうかを検討します。 アプリケーションの全体または一部が待機時間の影響を受けやすい場合は、複数リージョンおよび複数ゾーンの戦略の適用性を制限できるコンポーネントのコロケーションが必要になることがあります。

障害に対応する

パブリック クラウドでは失敗を回避することはできません。そのため、アプリケーションは障害に対応し、信頼性を確保するための回復性が必要になります。 アプリケーションは、重要なアプリケーションのシナリオと機能全体において、地域、ゾーン、サービス、またはコンポーネントの障害によって影響を受けた場合でも動作するように設計する必要があります。 アプリケーション操作では、障害中に機能が低下したり、パフォーマンスが低下したりする場合があります。

障害状態のときにアプリケーションがどのように利用可能かを把握するための可用性戦略を定義します。 これは、すべてのアプリケーション コンポーネントとアプリケーション デプロイのスタンプ全体に適用する必要があります。たとえば、複数の地域スケール単位のデプロイ方法を使用します。 コストにも影響があります。高可用性を実現するには、より多くのリソースを事前にプロビジョニングする必要があります。 アクティブ/アクティブ セットアップでは、単一のデプロイよりもコストが高くなりますが、1 つのスタンプで負荷を軽減し、必要なリソースの総量を減らすことによって、コストのバランスを取ることができます。

可用性戦略に加えて、アプリケーションやその主要なシナリオに対して、ビジネス継続性のディザスター リカバリー (BCDR) 戦略を定義します。 ディザスター リカバリー戦略では、再デプロイ、ウォームスペアのアクティブ/パッシブ、またはホットスペアのアクティブ/アクティブ アプローチを使用して、リージョンの停止や重要なプラットフォームサービスの損失など、障害の状況にアプリケーションがどのように対応しているかを把握する必要があります。

コストを削減するには、アプリケーションのコンポーネントとデータをグループに分割することを検討してください。 次に例を示します。

  • 保護する必要があります
  • 保護する方が良いです
  • 同じポリシーを使用してすべてのデータを保護するのではなく、短期/再構築/損失が可能

信頼性を向上させるための考慮事項

アプリケーションは、管理サービスを使用するように設計されていますか。


Azure で管理されるサービスは、アプリケーション全体の信頼性をサポートするネイティブな回復性機能を提供します。 これらの機能を利用するには、サービスとしてのプラットフォーム (PaaS) を使用する必要があります。 PaaS オプションの方が構成や管理が簡単です。 VM をプロビジョニングしたり、Vnet を設定したり、修正プログラムや更新プログラムを管理する手間が省けるだけでなく、VM 上でのソフトウェア実行に関するその他すべてのオーバーヘッドが解消されます。 詳細については、「マネージサービスの使用」を参照してください。

アプリケーションはスケール アウトするように設計されていますか。


Azure は、エラスティック スケーラビリティを提供しており、スケールアウトするよう設計しなければなりません。ただし、アプリケーションはスケールユニット アプローチを活用してサービスとサブスクリプションの制限をナビゲートし、それぞれのコンポーネントとアプリケーションが全体として水平にスケーリングできるようにします。 スケールインについては忘れないでください。コストを削減するには重要です。 たとえば、App Service のスケールインとスケールアウトは、ルールを使用して行います。 多くの場合、顧客はスケールアウト ルールを記述し、スケールイン ルールは記述しません。 これにより、App Service コストが高くなります。

アプリケーションは複数の Azure サブスクリプションにデプロイされていますか?


関連するサブスクリプションの制限またはクォータを移動できるかどうかを分析する際には、アプリケーションのサブスクリプションの状況と、コンポーネントがサブスクリプション内またはサブスクリプション間でどのように編成されるかを理解することが重要です。 Azure のサブスクリプションとサービスの制限を確認し、必要な容量が Azure サービスのスケール制限とクォータ内にあることを確認します。 詳しくは、「Azure サブスクリプションとサービスの制限」をご覧ください。

次のステップ

メインの記事に戻る: 設計