ディザスター リカバリーが処理されるように HA アプリケーションを設計する
Azure にストレージ アカウントを作成し、RA-GRS が有効になるようにレプリケーションの設定を構成しました。 これで、RA-GRS ストレージ アカウントを利用する医療アプリケーションの設計を開始する準備が整いました。 このアプローチにより、プライマリ リージョンで障害が発生した場合でも、現場の医師やコンサルタントに対してアプリケーションの高可用性を保証できます。
このユニットでは、ディザスター リカバリーとフェールオーバーを処理できるアプリケーションを設計および構成する方法について見ていきます。 また、高可用性を実現するアプリケーションを設計するときに適用される考慮事項についても確認します。
アカウントのフェールオーバーのしくみ
ストレージ アカウントを GRS または RA-GRS 用に構成すると、クライアントではプライマリ エンドポイントまたはプライマリ リージョンにデータが書き込まれます。 次の図に示すように、このデータは、セカンダリ リージョンに自動的にレプリケートされます。
geo 冗長ストレージがホストされているプライマリ リージョンが使用できなくなった場合は、セカンダリ リージョンにフェールオーバーできます。
フェールオーバーが発生すると、セカンダリ リージョンが新しいプライマリ リージョンになり、すべてのデータが新しいプライマリ リージョンでアクセスできるようになります。 ストレージ アカウントに関連するすべての DNS レコードでは、新しいプライマリ リージョンを指すように DNS エンドポイントが更新されます。 このリダイレクトでは、アプリケーション コードを変更する必要はありません。
プライマリ リージョンで障害が発生すると、次の図のようになります。
重要
フェールオーバーは自動的であり、Microsoft によって制御されます。 ほとんどの Azure リージョンでは、Azure ストレージ アカウントの手動フェールオーバーは実行できません。 ただし、Microsoft では WestUS2 リージョンと CentralUS リージョンで新機能の提供を開始しました。これにより、次のコマンドを使用して、ストレージ アカウントを手動でフェールオーバーできます。
az storage account failover --name "storageaccountname"
ストレージ アカウントのフェールオーバーの影響
ストレージ アカウントのフェールオーバーが発生すると、データが失われる可能性があります。 現在のプライマリ リージョンのデータが、フェールオーバー時にセカンダリ リージョンにレプリケートされていない可能性があります。 データが失われる可能性があるかどうかは、最終同期時刻プロパティを調べて判断できます。 前の演習では、この値を検索するためにコマンドを使用し、ストレージ アカウントのレプリケーションの状態を確認しました。
回復性があるアプリケーションを設計する
アプリケーションを設計するときは、次の要因を考慮してください。
回復性:ダウンタイムとデータ損失を回避するために、障害から回復して動作し続ける機能。
高可用性: アプリケーションの 1 つ以上のコンポーネントに影響するハードウェア障害、サーバー障害、またはネットワークの問題がある場合に、正常な状態で動作し続ける機能。
ディザスター リカバリー:データセンターの停止や完全なリージョンの停止など、大規模なインシデントがアプリケーションをホストするサービスに影響する場合に復旧する機能。 ディザスター リカバリーには、Azure Site Recovery を使用したアプリケーションの手動フェールオーバーが含まれます。 Azure Site Recovery では、Azure リージョンまたは Azure バックアップ間でサーバーをフェールオーバーできます。 その後、バックアップからデータベースまたはアプリケーションを復元できます。
最終的な整合性:RA-GRS は、プライマリ エンドポイントからセカンダリ エンドポイントにデータをレプリケートすることによって機能します。 リージョン間でレプリケートされたデータを、セカンダリの場所ですぐには利用することはできません。 最終的な整合性とは、プライマリ リージョンのすべてのトランザクションが、最終的にセカンダリ リージョンに表示されることを意味します。 データは失われませんが、若干の遅延が発生する可能性があります。
医療システムでの最終的な整合性の影響を次の表に示します。 新しいレコードまたは更新されたレコードがプライマリ リージョンに書き込まれると、プライマリ ストレージの場所では最新のレコードをすぐに使用できます。 これらの更新は最終的にセカンダリ リージョンに反映されますが、伝達が行われるまでに遅延が発生する可能性があります。 セカンダリ ロケーションからデータを読み取るアプリケーションでは、古いデータが短時間表示される場合があります。
時刻 トランザクション レプリケーション 最終同期時刻 結果 T0 医師が患者のレコードを追加する トランザクションは追加されるが、レプリケートされない T1 レコードがレプリケートされる T1 最終同期時刻フィールドが更新される T2 コンサルタントが患者のレコードを更新する T1 プライマリ リージョンではレコードが更新されるがレプリケートされない T3 セカンダリ リージョンからレコードが読み取られる プライマリ リージョンから更新がまだレプリケートされていないため、セカンダリ リージョンからのデータが古い T4 レコードがレプリケートされる T4 セカンダリ リージョンのデータが更新され、最終同期時刻フィールドが更新される
RA-GRS を使用するクラウドベースのアプリケーションのベスト プラクティス
クラウド用のアプリケーションを開発する場合は、次のセクションのガイドラインを考慮してください。
一時的な障害を再試行する
データベースの切断、ネットワークの一時的な喪失、サービスからの応答時間が遅くなる待機時間の問題など、多くの状況により一時的な障害が発生する可能性があります。 アプリケーションでは、障害を検出し、それが単にサービスの中断であるか、それとも深刻な停止であるかを、判断する必要があります。 アプリケーションは、エラーが一時的なものであると考えられる場合は、障害としてリストする前に、サービスを再試行する機能を備えている必要があります。
失敗した書き込みを処理する
RA-GRS では、場所の間で書き込みがレプリケートされます。 プライマリ ロケーションで障害が発生した場合、読み取り操作をセカンダリ ロケーションに向けることができます。 ただし、このセカンダリ ロケーションは読み取り専用です。 プライマリの場所で長時間にわたる停止 (数秒以上) が発生した場合、アプリケーションは読み取り専用モードで実行する必要があります。 読み取り専用モードは、いくつかの方法で実現できます。
- 書き込み機能が元に戻るまで、すべての書き込み操作から一時的にエラーが返されます。
- 通常はキューを使用して書き込み操作をバッファーに格納し、後で書き込みの場所が使用可能になったらそれらを実行します。
- 別の場所にある別のストレージ アカウントに更新を書き込みます。 プライマリの場所が使用可能になったら、そこのストレージ アカウントにこれらの変更をマージします。
- アプリケーションをトリガーしてすべての書き込み操作を無効にし、アプリケーションが読み取り専用モードで実行されていることをユーザーに通知します。 また、アプリケーションをアップグレードする必要があり、アップグレードの実行中に確実に誰もプライマリ ロケーションを使用しないようにする場合も、このメカニズムを使用できます。
Azure Storage クライアント ライブラリを使用するアプリケーションでは、読み取り要求の LocationMode を次のいずれかの値に設定できます。
- PrimaryOnly:プライマリ ロケーションが使用できない場合、読み取り要求は失敗します。 この失敗が既定の動作です。
- PrimaryThenSecondary: 最初にプライマリ ロケーションを試し、プライマリ ロケーションが使用できない場合はセカンダリ ロケーションを試します。 セカンダリ ロケーションも使用できない場合は失敗します。
- SecondaryOnly:セカンダリ ロケーションのみを試し、使用できない場合は失敗します。
- SecondaryThenPrimary:まずセカンダリ ロケーションを試してから、プライマリ ロケーションを試します。
最終的な整合性を処理する
セカンダリ リージョンからデータが読み取られる場合に、古いデータを処理するように準備します。 リージョン間のデータのレプリケートには時間がかかるため、データがプライマリ ロケーションに書き込まれてから、各セカンダリ ロケーションにレプリケートされるまでの間に停止が発生する可能性があります。
サーキット ブレーカー パターンを使用する
分散環境では、低速のネットワーク接続、リソースのタイムアウト、リソースのオフライン移行、伝送の問題による転送中のデータの破損などが原因で、リモート リソース間の通信が失敗する可能性があります。 ほとんどの場合、これらの問題は一時的なものであり、自動的に解決します。 アプリケーションで同じ操作を再試行すると、多くの場合は成功します。
重大な障害が発生した場合は、アプリケーションでの操作の再試行を停止し、セカンダリ サイトへのフェールオーバーを開始するのが理にかなっています。
失敗した操作をアプリケーションが再試行し続けないようにするには、サーキット ブレーカー パターンを実装します。
サーキット ブレーカー パターンでは、アプリケーションが通常のサービスを再開できるように、セカンダリ サイトへの強制的なフェールオーバーが行われます。 同時に、サーキット ブレーカーでは、プライマリ サイトのリソースがオンラインに戻るかどうかの確認が継続されます。 オンラインになると、アプリケーションはプライマリ サイトに再接続できるようになります。 サーキット ブレーカーはプロキシとして機能します。 サービスを監視します。 サービスでエラーが発生した場合、サーキット ブレーカーによりアプリケーションがそのエンドポイントを再試行するのを防ぎ、代わりのエンドポイントにアクセスするよう強制します。
サーキット ブレーカー パターンと再試行パターンの違いは、再試行パターンでは、アプリケーションはオフラインになっている可能性があるリソースへの接続の再試行を続けられることです。 サーキット ブレーカー パターンでは、このような動作はできず、アプリケーションはセカンダリ接続にフェールオーバーされます。
サーキット ブレーカー パターンを実装する目的は、システムが障害から回復している間に、アプリケーションの安定性を確保することです。
障害が発生したリソースにアプリケーションで接続が試みられないようにし、代わりに動作しているリソースにリダイレクトして中断を最小限に抑えるには、サーキット ブレーカー パターンを使用します。 サーキット ブレーカーではシステムへのオーバーヘッドが増えるため、ローカル環境またはメモリ内のデータ構造にアクセスする場合は、サーキット ブレーカー パターンを使用しないでください。
サーキット ブレーカー パターンを実装するときは、読み取り要求の LocationMode を適切に設定します。 ほとんどの場合は、このモードを PrimaryThenSecondary に設定する必要があります。 プライマリ ロケーションからの読み取りがタイムアウトになった場合は、セカンダリ ロケーションが使用されます。 ただし、このプロセスが繰り返し実行されると、アプリケーションの速度が低下する可能性があります。 サーキット ブレーカーでは、プライマリ ロケーションが使用できないことが検出されたら、モードを SecondaryOnly に切り替える必要があります。 このアクションにより、読み取り操作では、プライマリ ロケーションからのタイムアウトを待たずに、セカンダリ ロケーションが試行されます。 サーキット ブレーカーでは、プライマリ ロケーションが修復されたことが推定されたら、PrimaryThenSecondary モードに戻すことができます。
詳細については、「サーキット ブレーカー パターン」を確認してください。