特定の Azure サービスの回復性のチェックリスト

  • [アーティクル]

回復性とは、障害から回復して動作を続行する、システムの能力です。 各テクノロジには独自の障害モードがあり、アプリケーションの設計および実装の際に考慮する必要があります。 このチェックリストを使用して、個々の Azure サービスの回復性の考慮事項を確認します。 回復性があるアプリケーションの設計の詳細については、信頼性の高い Azure アプリケーションの設計に関するページを参照してください。

App Service

Standard または Premium レベルを使用します。 これらの階層は、ステージング スロットと自動バックアップをサポートします。 詳細については、「Azure App Service プランの詳細な概要」を参照してください

スケールアップまたはスケールダウンを回避します｡ 代わりに、通常の負荷の下でパフォーマンスの要件を満たす階層とインスタンスのサイズを選択してから、インスタンスをスケールアウトしてトラフィック量の変化を処理してください。 スケールアップとスケールダウンにより、アプリケーションの再起動がトリガーされることがあります。

構成をアプリ設定として格納します。 アプリ設定を使用して、構成設定をアプリケーション設定として格納してください。 Resource Manager テンプレートに、または PowerShell 使用して設定を定義して、それを自動化されたデプロイや更新プロセスの一部として適用できるようにしてください。それによって信頼性が向上します。 詳細については、「Azure App Service での Web アプリの構成」をご覧ください。

運用とテスト用に別々の App Service プランを作成します。 テストには運用環境のデプロイのスロットを使用しないでください。 同じ App Service プラン内のすべてのアプリが同じ VM インスタンスを共有します。 運用デプロイとテスト デプロイを同じプランに入れると、運用デプロイに悪影響を与える可能性があります。 たとえば、ロード テストは実稼働の運用サイトの機能を低下させる可能性があります。 テスト デプロイを別のプランに入れて、運用バージョンから切り離してください。

Web アプリから Web API を分離します。 ソリューションに Web フロントエンドと Web API の両方がある場合は、それらを別々の App Service アプリに分解することを検討してください。 この設計により、ソリューションをワークロード別に分解しやすくなります。 Web アプリと API を別々の App Service プランで実行できるため、それらを個別にスケーリングできるようになります。 最初はこのレベルのスケーラビリティが不要な場合は、アプリを同じプランにデプロイし、後で必要に応じて別のプランに移行することができます。

Azure SQL データベースをバックアップするのに App Service バックアップ機能を使用しないでください。 代わりに、SQL Database 自動バックアップを使用してください。 App Service のバックアップでは、データベースを SQL BACPAC ファイルにエクスポートします。DTU のコストがかかります。

ステージング スロットにデプロイします。 ステージング用のデプロイ スロットを作成します。 アプリケーションの更新プログラムをステージング スロットにデプロイし、運用環境にスワップする前にデプロイを確認してください。 これにより、運用環境で不正な更新が発生する可能性が減少します。 また、すべてのインスタンスが、運用環境にスワップする前に確実にウォーム アップされます。 ウォームアップとコールドスタートに時間がかかるアプリケーションは多数あります。 詳細については、「Azure App Service の Web アプリのステージング環境を設定する」をご覧ください。

前回正常起動時 (LKG) のデプロイを保持するデプロイ スロットを作成します。 運用環境に更新プログラムをデプロイするときは、以前の運用環境のデプロイを LKG スロットに移動してください。 これにより、不適切なデプロイをより簡単にロールバックできます。 後で問題を見つけた場合は、LKG バージョンにすばやく戻ることができます。 詳細については、基本的な Web アプリケーションに関するページをご覧ください。

アプリケーションのログ記録や Web サーバーのログ記録を含む、診断のログ記録を有効にしてください。 監視と診断にはログ記録が重要です。 「Azure App Service での Web アプリの診断ログの有効化」をご覧ください。

Blob Storage にログを記録します。 これによって、データの収集と分析が簡単になります。

ログ用の別のストレージ アカウントを作成します。 ログとアプリケーション データに同じストレージ アカウントを使用しないでください。 これは、ログ記録によってアプリケーションのパフォーマンスが低下するのを防ぐのに役立ちます。

パフォーマンスを監視する。 New Relic やApplication Insights などのパフォーマンス監視サービスを使用して、負荷がかかった状態のアプリケーションのパフォーマンスと動作を監視してください。 パフォーマンスの監視により、アプリケーションをリアルタイムで理解できます。 これにより、問題を診断し、障害の根本原因分析を行うことができます。

Azure Load Balancer

Standard SKU を選択する Standard Load Balancer は、Basic では提供されない、信頼性のディメンション (可用性ゾーンとゾーンの回復性) を提供します。 つまり、あるゾーンがダウンしても、ゾーンの冗長性を備えた Standard Load Balancer が影響を受けることはありません。 これにより、デプロイがリージョン内のゾーン障害に耐えられるようになります。 さらに、Standard Load Balancer はグローバルな負荷分散をサポートしているため、リージョンで障害が発生してもアプリケーションが影響を受けることはありません。

少なくとも 2 つのインスタンスをプロビジョニングする バックエンドに少なくとも 2 つのインスタンスを使用して Azure LB をデプロイします。 単一のインスタンスでは、単一障害点になってしまいます。 スケールを構築するために、LB を Virtual Machine Scale Sets とペアにすることをお勧めします。

アウトバウンド規則を使用する アウトバウンド規則を使用することで、SNAT ポートが枯渇することによって生じる接続エラーが発生しないようにすることができます。 送信接続の詳細 アウトバウンド規則を使用すると、小規模から中規模のデプロイでソリューションを向上させることができますが、運用環境のワークロードでは Standard Load Balancer または任意のサブネット デプロイを VNET NAT と結合することをお勧めします。

Application Gateway

少なくとも 2 つのインスタンスをプロビジョニングします。 少なくとも 2 つのインスタンスのある Application Gateway をデプロイしてください。 単一のインスタンスは、単一障害点です。 冗長性とスケーラビリティのために、2 つ以上のインスタンスを使用してください。 SLA に適合するためには、2 つ以上のメディアまたは大きめのインスタンスをプロビジョニングする必要があります。

Azure Cosmos DB

リージョン間でデータベースをレプリケートします。 Azure Cosmos DB では、Azure Cosmos DB データベース アカウントに Azure リージョンをいくつでも関連付けることができます。 Azure Cosmos DB データベースには、1 つの書き込みリージョンと複数の読み取りリージョンを含めることができます。 書き込みリージョンに障害がある場合は、別のレプリカから読み取ることができます。 クライアント SDK はこれを自動的に処理します。 書き込みリージョンを別のリージョンにフェールオーバーすることもできます。 詳細については、「Azure Cosmos DB を使用してデータをグローバルに分散させる方法」をご覧ください。

Event Hubs

チェックポイントを使用します。 イベント コンシューマーは、事前定義された間隔で永続的ストレージに現在位置を書き込む必要があります。 このように、コンシューマーで障害が発生した場合 (たとえば、コンシューマーがクラッシュした場合や、ホストに障害が発生した場合)、新しいインスタンスは最後に記録された位置からストリームの読み取りを再開できます。 詳細については、イベント コンシューマーに関するページをご覧ください。

重複メッセージを処理します。 イベント コンシューマーに障害が発生すると、メッセージの処理は最後に記録されたチェックポイントから再開されます。 最後のチェックポイントの後で既に処理されたメッセージはすべて、再度処理されます。 したがって、メッセージ処理ロジックがべき等であるか、アプリケーションでメッセージの重複を除去できる必要があります。

例外を処理します。 イベント コンシューマーは、通常、ループ内のメッセージをバッチで処理します。 1 つのメッセージによって例外が発生した場合は、メッセージのバッチ全体を失わないように、その処理ループ内の例外を処理する必要があります。

配信不能キューを使用します。 メッセージを処理した結果、一時的でないエラーが発生した場合は、状態を追跡できるように、メッセージを配信不能キューに配置します。 シナリオによっては、メッセージを後で再試行したり、補正トランザクションを適用したり、他の何らかのアクションを実行したりする可能性があります。 Event Hubs には、組み込みの配信不能キュー機能がないことに注意してください。 Azure Queue Storage または Service Bus を使用して配信不能キューを実装したり、Azure Functions またはその他のイベント処理メカニズムを使用したりすることができます。

セカンダリ Event Hubs 名前空間にフェールオーバーして、ディザスター リカバリーを実装します。 詳細については、「Azure Event Hubs geo ディザスター リカバリー」を参照してください。

Azure Cache for Redis

geo レプリケーションを構成します。 geo レプリケーションには、レベルが Premium である Azure Cache for Redis の 2 つのインスタンスをリンクするメカニズムが用意されています。 プライマリ キャッシュに書き込まれたデータは、読み取り専用のセカンダリ キャッシュにレプリケートされます。 詳細については、「Azure Cache for Redis の geo レプリケーションの構成方法」を参照してください

データ永続化を構成します。 Redis の永続化を使用すると、Redis に格納されたデータを保持できます。 また、スナップショットを取得したりデータをバックアップしたりして、ハードウェア障害のときに読み込むことができます。 詳細については、「Premium Azure Cache for Redis のデータ永続化の構成方法」を参照してください

永続ストアとしてではなく、一時的なデータ キャッシュとして Azure Cache for Redis を使用する場合、これらの推奨事項は適用されません。

複数のレプリカをプロビジョニングします。 読み取りの高可用性のためには少なくとも 2 つのレプリカ、読み取り/書き込みの高可用性のためには少なくとも 3 つのレプリカを使用してください。

複数リージョンのデプロイ用のインデクサーを構成します。 複数リージョンのデプロイがある場合は、インデックス作成の継続性のためのオプションを検討してください。

  • データ ソースが geo レプリケーションされている場合は、一般に、各リージョンの Azure Search サービスのそれぞれのインデクサーをそのローカル データ ソース レプリカにポイントする必要があります。 ただし、このアプローチは、Azure SQL データベースに格納されている大規模なデータセットは推奨されません。 その理由は、Azure Search がセカンダリ SQL Database レプリカからは増分インデックス作成を実行できず、プライマリ レプリカからしか実行できないためです。 代わりに、すべてのインデクサーをプライマリ レプリカにポイントしてください。 フェールオーバー後は、新しいプライマリ レプリカで Azure Search インデクサーをポイントします。

  • データ ソースが geo レプリケートされていない場合は、同じデータ ソースにある複数のインデクサーをポイントして、複数のリージョン内の Azure Search サービスがデータ ソースからのインデックス作成を継続的に単独で行うようにしてください。 詳細については、「Azure Search のパフォーマンスと最適化に関する考慮事項」をご覧ください。

Service Bus

運用ワークロードには Premium レベルを使用します。 Service Bus の Premium メッセージングでは、専用の予約済み処理リソースと、予測可能なパフォーマンスとスループットをサポートするためのメモリ容量が提供されます。 また、Premium メッセージング レベルでは、Premium のお客様だけがいち早く利用できる新機能にもアクセスできます。 予想されるワークロードに基づいて、メッセージング ユニットの数を決定できます。

重複メッセージを処理します。 メッセージ送信後すぐにパブリッシャーで障害が発生した場合、またはネットワークやシステムで問題が発生した場合は、メッセージが配信されたことをエラーのため記録できないことがあり、同じメッセージがシステムに 2 回送信される可能性があります。 Service Bus では、重複の検出を有効にすることで、この問題を処理できます。 詳しくは、「重複検出」をご覧ください。

例外を処理します。 メッセージング API では、ユーザー エラー、構成エラー、その他のエラーが発生すると、例外が生成されます。 クライアント コード (送信側と受信側) では、コード内でこれらの例外を処理する必要があります。 バッチ処理では、例外処理を使用してメッセージのバッチ全体が失われるのを防ぐことができるので、特に重要です。 詳しくは、「Service Bus メッセージングの例外」をご覧ください。

再試行ポリシー。 Service Bus を使用すると、アプリケーションに最適な再試行ポリシーを選択できます。 既定のポリシーでは、最大 9 回の再試行が許され、待機時間は 30 秒ですが、これをさらに調整できます。 詳しくは、Service Bus の再試行ポリシーに関するページをご覧ください。

配信不能キューを使用します。 複数回再試行しても、メッセージを処理できないか、またはどの受信者にも配信できない場合、メッセージは配信不能キューに移動されます。 配信不能キューからメッセージを読み取り、検査して、問題を修復するプロセスを実装します。 シナリオに応じて、そのままのメッセージで再試行したり、メッセージを変更して再試行したり、メッセージを破棄したりします。 詳しくは、「Service Bus の配信不能キューの概要」をご覧ください。

geo ディザスター リカバリーを使用します。 geo ディザスター リカバリーを使用すると、Azure リージョン全体またはデータセンターが災害により使用できなくなった場合でも、別のリージョンまたはデータセンターでデータの処理が続けられることが保証されます。 詳細については、「Azure Service Bus の geo ディザスター リカバリー」を参照してください。

ストレージ

読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) 用にストレージ アカウントを構成します。 RA-GRS または RA-GZRS を使用すると、データがセカンダリ リージョンにレプリケートされます。 RA-GRS ではプライマリ リージョン内でローカル冗長ストレージ (LRS) が使用され、RA-GZRS ではプライマリ リージョン内でゾーン冗長ストレージが使用されます。 どちらの構成でも、セカンダリ リージョン内のデータへの読み取り専用アクセスが提供されます。 プライマリ リージョンでストレージが停止した場合、アプリケーションはセカンダリ リージョンからデータを読み取ることができます (この可能性に備えて設計した場合)。 詳細については、「Azure Storage の冗長性」を参照してください。

VM ディスクには、マネージド ディスクを使用します。マネージド ディスクでは、ディスクが単一障害点にならないように相互に十分に分離されるため、可用性セットの VM の信頼性が向上します。 また、マネージド ディスクはストレージ アカウントで作成した VHD の IOPS 制限の対象ではありません。 詳細については、「Azure での Windows 仮想マシンの可用性の管理」をご覧ください。

Queue Storage では、別のリージョンにバックアップ キューを作成します。 Queue Storage では、項目をキューやデキューすることができないため、読み取り専用レプリカの使用は制限されています。 代わりに、別のリージョンのストレージ アカウントにバックアップ キューを作成します。 Azure Storage が停止した場合、アプリケーションは、プライマリ リージョンが再び使用可能になるまで、バックアップ キューを使用できます。 そうすることで、停止中もアプリケーションで新しい要求を引き続き処理できます。

SQL Database

Standard または Premium レベルを使用します。 これらの階層は、より長いポイントインタイム リストア期間 (35 日間) を提供します。 詳細については、「SQL Database のオプションとパフォーマンス」をご覧ください。

SQL Database の監査を有効にします。 監査は、悪意のある攻撃や人的ミスの診断に使用できます。 詳細については、「SQL Database 監査の使用」をご覧ください。

アクティブ Geo レプリケーションを使用します。 アクティブ Geo レプリケーションを使用して、さまざまなリージョンに読み取り可能なセカンダリ レプリカを作成します。 プライマリ データベースに障害が発生した場合、またはオフラインにする必要がある場合は、セカンダリ データベースへの手動フェールオーバーを実行します。 セカンダリ データベースは、フェールオーバーするまでは読み取り専用のままです。 詳細については、「Azure SQL Database のアクティブ geo レプリケーション」をご覧ください。

シャーディングを使用します。 シャーディングを使用して、データベースを水平方向にパーティション分割することを検討してください。 シャーディングによって障害を分離できます。 詳細については、「Azure SQL Database によるスケール アウト」をご覧ください。

人的ミスから復旧するには、ポイントインタイム リストアを使用します。 ポイントインタイム リストアは、データベースを以前の特定の時点に戻します。 詳細については、「データベースの自動バックアップを使用した Azure SQL Database の復旧」を参照してください。

サービスの停止から復旧するには、geo リストアを使用します。 geo リストアは geo 冗長バックアップからデータベースを復元します。 詳細については、「データベースの自動バックアップを使用した Azure SQL Database の復旧」を参照してください。

Azure Synapse Analytics

geo バックアップを無効にしないでください。 既定では、Synapse Analytics により、ディザスター リカバリー用にデータの完全バックアップが 24 時間ごとに作成されます。 この機能を無効にすることはお勧めしません。 詳細については、「geo バックアップ」を参照してください。

VM で実行されている SQL Server

データベースをレプリケートします。 データベースをレプリケートするには、SQL Server Always On 可用性グループを使用します。 1 つの SQL Server インスタンスが失敗した場合は、高可用性を提供してください。 詳細については、「n 層アプリケーションの Windows VM を実行する」をご覧ください。

データベースをバックアップします。 既に Azure Backup を使用して VM をバックアップしている場合は、DPM を使用した SQL Server ワークロード用 Azure Backup を使用することを検討してください。 このアプローチでは、組織用の 1 つのバックアップ管理者の役割と、VM および SQL Server 用の 1 つにまとめられた復旧手順があります。 それ以外の場合は、Microsoft Azure への SQL Server マネージド バックアップを使用してください。

Traffic Manager

手動フェールバックを実行します。 Traffic Manager のフェールオーバーの後は、自動的にフェールバックするのではなく、手動フェールバックを実行してください。 フェールバックする前に、すべてのアプリケーション サブシステムが正常であることを確認してください。 そうしないと、アプリケーションがデータセンター間で切り替わる状況が発生する可能性があります。 詳細については、「高可用性を得るために複数のリージョンで VM を実行する」をご覧ください。

正常性プローブのエンドポイントを作成します。 アプリケーションの全体的な正常性についてレポートするカスタム エンドポイントを作成してください。 これにより、クリティカル パスが失敗した場合に、フロント エンドだけでなく Traffic Manager をフェールオーバーできます。 エンドポイントは、重要な依存関係が正常でない場合、または到達できない場合に、HTTP エラー コードを返す必要があります。 ただし、重要でないサービスについてはレポートしないでください。 そうしないと、必要のないときに正常性プローブがフェールオーバーをトリガーして、誤検知が生じる可能性があります。 詳細については、「Traffic Manager エンドポイントの監視とフェールオーバー」をご覧ください。

Virtual Machines

単一の VM で運用環境のワークロードを実行しないでください。 単一の VM のデプロイには計画または計画外メンテナンスに対する回復力がありません。 代わりに、ロード バランサーを前面に配備して、複数の VM を可用性セットまたは仮想マシン スケール セットに配置してください。

VM をプロビジョニングするときに、可用性セットを指定します。 現時点では、VM がプロビジョニングされた後に、VM を可用性セットに追加する方法はありません。 既存の可用性セットに新しい VM を追加するときは、必ず VM 用の NIC を作成し、NIC をロード バランサーのバックエンド アドレス プールに追加してください。 そうしないと、ロード バランサーがその VM にネットワーク トラフィックをルーティングしなくなります。

各アプリケーション層を別々の可用性セットに配置します。 N 層のアプリケーションでは、同じ可用性セットの別の層からは VM を配置しないでください。 可用性セット内の VM は、障害ドメイン (FD) と更新ドメイン (UD) にまたがって配置されています。 ただし、FD と UD の冗長性の利点を活用するには、可用性セットのすべての VM が同じクライアント要求を処理できる必要があります。

Azure Site Recovery を使用して VM をレプリケートします。 Site Recovery を使用して Azure VM をレプリケートすると、すべての VM ディスクが、ターゲット リージョンに継続的かつ非同期的にレプリケートされます。 復旧ポイントは数分ごとに作成されます。 これにより目標復旧時点 (RPO) が数分単位で設定されます。 ディザスター リカバリー訓練を、運用環境のアプリケーションまたは実行中のレプリケーションに影響を与えることなく、必要な回数だけ実施できます。 詳細については、「Azure へのディザスター リカバリー訓練を実行する」を参照してください。

パフォーマンスの要件に基づいて適切な VM サイズを選択します。 既存のワークロードを Azure に移動する場合は、オンプレミスのサーバーに最も適合性が高い VM サイズから開始します。 次に、CPU、メモリ、およびディスクの IOPS について、実際のワークロードのパフォーマンスを測定し、必要に応じてサイズを調整します。 これにより、アプリケーションがクラウド環境で期待どおりに動作することを確認できます。 また、複数の NIC が必要な場合は、各サイズの NIC の制限に注意してください。

VHD 用のマネージド ディスクを使用します。マネージド ディスクでは、ディスクが単一障害点にならないように相互に十分に分離されるため、可用性セットの VM の信頼性が向上します。 また、マネージド ディスクはストレージ アカウントで作成した VHD の IOPS 制限の対象ではありません。 詳細については、「Azure での Windows 仮想マシンの可用性の管理」をご覧ください。

OS ディスクではなく、データ ディスクにアプリケーションをインストールします。 そうしないと、ディスク サイズの上限に達する可能性があります。

Azure Backup を使用して VM をバックアップします。 バックアップにより偶発的なデータ損失から保護されます。 詳細については、Recovery Services コンテナーを使用した Azure VM の保護に関するページをご覧ください。

診断ログを有効にする。 基本的な正常性メトリック、インフラストラクチャ ログ、およびブート診断が含まれます。 VM が起動不可能な状態になった場合は、起動エラーを診断するのにブート診断が役立ちます。 詳細については、「Azure 診断ログの概要」を参照してください。

Azure Monitor を構成します。 ゲスト オペレーティング システムとそこで実行されるワークロードも含め、Azure 仮想マシンから監視データを収集して分析します。Azure Monitor に関する記事、および Azure Monitor のクイックスタートをご覧ください。

Virtual Network

パブリック IP アドレスを許可したりブロックしたりするには、サブネットにネットワーク セキュリティ グループを追加します。 悪意のあるユーザーからのアクセスをブロックしたり、アプリケーションにアクセスする権限を持つユーザーからのアクセスのみを許可したりしてください。

カスタムの正常性プローブを作成します。 ロード バランサー正常性プローブでは、HTTP または TCP のいずれかをテストできます。 VM が HTTP サーバーを実行している場合、HTTP プローブは TCP プローブよりも優れた正常性状態のインジケーターです。 HTTP プローブでは、すべての重要な依存関係を含む、アプリケーションの全体的な正常性をレポートするカスタム エンドポイントを使用してください。 詳細については、「Azure Load Balancer の概要」を参照してください。

正常性プローブをブロックしないでください。 ロード バランサー正常性プローブは、既知の IP アドレスである 168.63.129.16 から送信されます。 任意のファイアウォール ポリシーまたはネットワーク セキュリティ グループの規則で、この IP を送受信するトラフィックをブロックしないでください。 正常性プローブをブロックすると、ロード バランサーによってローテーションから VM が削除されることがあります。

ロード バランサーのログ記録を有効にします。 ログには、プローブの応答に失敗したことが原因で、ネットワーク トラフィックを受信していない、バックエンドの VM 数が表示されます。 詳細については、「Azure Load Balancer のログ分析」をご覧ください。