Azure Health Data Services 匿名化サービス (プレビュー) の信頼性
この記事では、匿名化サービス (プレビュー) における信頼性のサポートについて説明します。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。
リージョン間のディザスター リカバリー
ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。
DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。
各匿名化サービス (プレビュー) は、単一の Azure リージョンにデプロイされます。 リージョン全体が使用できない場合、またはパフォーマンスが大幅に低下している場合:
- ARM コントロール プレーン機能は、停止中は読み取り専用に制限されます。 サービス メタデータ (リソース プロパティなど) は、常に Microsoft によってリージョン外にバックアップされます。 停止が終了したら、コントロール プレーンへの読み書きを行えるようになります。
- 停止中は匿名化やジョブ API 要求などのすべてのデータ プレーン要求が失敗します。 顧客データは失われませんが、ジョブの進行状況メタデータは失われる可能性があります。 停止が終了したら、データ プレーンへの読み書きを行えるようになります。
ディザスター リカバリーのチュートリアル
Azure リージョン全体が利用できない場合でも、ワークロードの高可用性を確保することは可能です。 アクティブ/アクティブ構成で 2 つ以上の匿名化サービスをデプロイし、Azure Front Door を使用して、トラフィックを両方のリージョンにルーティングすることができます。
このアーキテクチャ例では、次のようになります。
- 同一の匿名化サービスが 2 つの異なるリージョンにデプロイされます。
- Azure Front Door は、両方のリージョンにトラフィックをルーティングするために使用されます。
- 障害の発生時に、1 つのリージョンがオフラインになると、Azure Front Door はトラフィックを他方のリージョンにだけルーティングします。 このような geo フェールオーバー時の目標復旧時間は、Azure Front Door が一方のサービスが異常であることを検出するのに要する時間による制限を受けます。
RTO と RPO
アクティブ/アクティブ構成を採用する場合は、目標復旧時間 (RTO) を 5 分に設定する必要があります。 どのような構成でも、回復ポイントの目標 (RPO) は 0 分 (顧客データの喪失が発生しない) に設定する必要があります。
ディザスター リカバリー プランを検証する
前提条件
Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。
このチュートリアルを完了するには、以下が必要です。
Azure Cloud Shell で Bash 環境を使用します。 詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンス コマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、Azure CLI でのサインインに関するページを参照してください。
初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。
リソース グループを作成する
このチュートリアルでは、異なる Azure リージョン内の 2 つの匿名化サービス (プレビュー) が必要です。 このチュートリアルでは米国東部と米国西部 2 リージョンを使いますが、独自のリージョンを自由に選んで構いません。
管理とクリーンアップを簡単にするため、このチュートリアルのすべてのリソースに対して 1 つのリソース グループを使います。 ディザスター リカバリーの状況でリソースをさらに分離するには、リージョンやリソースごとに個別のリソース グループを使うことを検討します。
次のコマンドを実行して、リソース グループを作成します。
az group create --name my-deid --location eastus
匿名化サービス (プレビュー) を作成する
「クイックスタート: 匿名化サービス (プレビュー) をデプロイする」の手順に従って、米国東部と米国西部 2 に 1 つずつ、2 つの個別のサービスを作成します。
次の手順で Azure Front Door をデプロイするときにバックエンド アドレスを定義できるように、各匿名化サービスのサービス URL をメモします。
Azure Front Door を作成する
マルチリージョンのデプロイでは、アクティブ/アクティブまたはアクティブ/パッシブの構成を使用できます。 アクティブ/アクティブ構成では、要求は複数のアクティブなリージョンに分散されます。 アクティブ/パッシブ構成では、セカンダリ リージョンのインスタンスは実行されていますが、プライマリ リージョンで障害が発生しない限り、そこにトラフィックが送信されることはありません。 Azure Front Door に組み込まれてる機能を使って、これらの構成を有効にできます。 高可用性とフォールト トレランスのためのアプリの設計について詳しくは、「回復性と可用性に対応するように Azure アプリケーションを設計する」をご覧ください。
Azure Front Door プロファイルを作成する
次に、トラフィックをサービスにルーティングするための Azure Front Door Premium を作成します。
az afd profile create を実行して Azure Front Door プロファイルを作成します。
Note
Premium の代わりに Azure Front Door Standard をデプロイする場合は、--sku パラメーターの値を Standard_AzureFrontDoor に置き換えます。 Standard レベルを選択した場合、WAF ポリシーを使用してマネージド ルールを展開することはできません。 価格レベルの比較について詳しくは、「Azure Front Door レベルの比較」を参照してください。
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| パラメーター | 価値 | 説明 |
|---|---|---|
profile-name |
myfrontdoorprofile |
リソース グループ内で一意である Azure Front Door プロファイルの名前。 |
resource-group |
my-deid |
このチュートリアルのリソースが含まれるリソース グループ。 |
sku |
Premium_AzureFrontDoor |
Azure Front Door プロファイルの価格レベル。 |
Azure Front Door エンドポイントを追加する
az afd endpoint create を実行して、Azure Front Door プロファイルにエンドポイントを作成します。 このエンドポイントは、要求をサービスにルーティングします。 このガイドを終えたら、プロファイルに複数のエンドポイントを作成できます。
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| パラメーター | 価値 | 説明 |
|---|---|---|
endpoint-name |
myendpoint |
プロファイルの下にあるエンドポイントの、グローバルに一意の名前。 |
enabled-state |
Enabled |
このエンドポイントを有効にするかどうか。 |
Azure Front Door の配信元グループを作成する
az afd origin-group create を実行して、2 つの匿名化サービスを含む配信元グループを作成します。
az afd origin-group create --resource-group my-deid --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Https --probe-interval-in-seconds 60 --probe-path /health --sample-size 1 --successful-samples-required 1 --additional-latency-in-milliseconds 50 --enable-health-probe
| パラメーター | 価値 | 説明 |
|---|---|---|
origin-group-name |
myorigingroup |
配信元グループの名前。 |
probe-request-type |
GET |
行われた正常性プローブの要求の種類。 |
probe-protocol |
Https |
正常性プローブに使用するプロトコル。 |
probe-interval-in-seconds |
60 |
正常性プローブ間の秒数。 |
probe-path |
/health |
配信元の正常性を判断するために使われる、配信元を基準とするパス。 |
sample-size |
1 |
負荷分散決定で考慮するサンプルの数。 |
successful-samples-required |
1 |
サンプル期間内に成功する必要があるサンプルの数。 |
additional-latency-in-milliseconds |
50 |
プローブが最短待機時間バケットに分類される余分な待機時間 (ミリ秒単位)。 |
enable-health-probe |
正常性プローブの状態を制御するための切り替えを行います。 |
配信元を Azure Front Door の配信元グループに追加する
az afd origin create を実行して、オリジン グループにオリジンを追加します。 --host-name および --origin-host-header パラメーターでは、プレースホルダー値 <service-url-east-us> を実際の米国東部のサービス URL に置き換え、スキーム (https://) はそのままにします。 値は abcdefghijk.api.eastus.deid.azure.com のようになるはずです。
az afd origin create --resource-group my-deid --host-name <service-url-east-us> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid1 --origin-host-header <service-url-east-us> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
| パラメーター | 価値 | 説明 |
|---|---|---|
host-name |
<service-url-east-us> |
プライマリ匿名化サービスのホスト名。 |
origin-name |
deid1 |
配信元の名前。 |
origin-host-header |
<service-url-east-us> |
この配信元に要求を送信するためのホスト ヘッダー。 |
priority |
1 |
このパラメーターを 1 に設定することで、すべてのトラフィックをプライマリ匿名化サービスに転送します。 |
weight |
1000 |
負荷分散のための、特定の配信元グループ内での配信元の重み。 1 から 1000 の間である必要があります。 |
enabled-state |
Enabled |
この配信元を有効にするかどうか。 |
https-port |
443 |
配信元への HTTPS 要求に使われるポート。 |
このステップを繰り返して、2 つ目の配信元を追加します。 --host-name と --origin-host-header パラメーターでは、プレースホルダーの値 <service-url-west-us-2> を米国西部 2 のサービスの URL に置き換え、スキーム (https://) はそのままにします。
az afd origin create --resource-group my-deid --host-name <service-url-west-us-2> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid2 --origin-host-header <service-url-west-us-2> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
両方のコマンドにある --priority パラメーターに注意してください。 配信元はどちらも優先度 1 に設定されているため、Azure Front Door は両方の配信元をアクティブとして扱い、トラフィックを両方のリージョンに転送します。 1 つの配信元の優先度が 2 に設定されている場合、Azure Front Door はその配信元をセカンダリとして扱い、もう一方の配信元がダウンしない限り、すべてのトラフィックをそちらに転送します。
Azure Front Door ルートを追加する
az afd route create を実行して、エンドポイントをオリジン グループにマップします。 このルートでは、エンドポイントからの要求を配信元グループに転送します。
az afd route create --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --origin-group myorigingroup --supported-protocols Https --link-to-default-domain Enabled
| パラメーター | 価値 | 説明 |
|---|---|---|
endpoint-name |
myendpoint |
エンドポイントの名前。 |
forwarding-protocol |
MatchRequest | バックエンドにトラフィックを転送するときに、このルールが使用するプロトコル。 |
route-name |
route |
ルートの名前。 |
supported-protocols |
Https |
このルートでサポートされているプロトコルのリスト。 |
link-to-default-domain |
Enabled |
このルートを既定のエンドポイント ドメインにリンクするかどうか。 |
この変更がグローバルに反映されるまでに時間がかかるため、このステップを終えるまで約 15 分かかります。 この時間経過後、Azure Front Door は完全に機能するようになります。
Front Door をテストする
Azure Front Door Standard/Premium プロファイルを作成する際、グローバルに構成がデプロイされるまでに数分かかります。 完了したら、作成したフロントエンド ホストにアクセスできます。
az afd endpoint show を実行して、Front Door エンドポイントのホスト名を取得します。 これは abddefg.azurefd.net のようになるはずです
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
ブラウザーで、前のコマンドから返されたエンドポイント ホスト名に移動します: <endpoint>.azurefd.net/health。 要求は自動的に米国東部のプライマリ匿名化サービスにルーティングされるはずです。
インスタントのグローバル フェールオーバーをテストするには:
ブラウザーを開き、次のエンドポイント ホスト名にアクセスします:
<endpoint>.azurefd.net/health。「プライベート アクセスの構成」の手順に従って、米国東部の匿名化サービスのパブリック ネットワーク アクセスを無効にします。
ブラウザーを更新します。 トラフィックが米国西部 2 の匿名化サービスに転送されるようになったため、同じ情報ページが表示されるはずです。
ヒント
フェールオーバーが完了するには、ページの更新が数回必要になる場合があります。
次に、米国西部 2 の匿名化サービスのパブリック ネットワーク アクセスを無効にします。
ブラウザーを更新します。 今回はエラー メッセージが表示されます。
一方の匿名化サービスのパブリック ネットワーク アクセスを再度有効にします。 ブラウザーを更新すると、正常性状態が再び表示されるはずです。
これで、Azure Front Door を通してサービスにアクセスできることと、フェールオーバーが意図したとおりに機能することの検証が完了しました。 フェールオーバー テストが完了したら、他方のサービス上のパブリック ネットワーク アクセスを有効にします。
リソースをクリーンアップする
前の手順では、リソース グループ内に Azure リソースを作成しました。 今後これらのリソースが不要である場合は、次のコマンドを実行してリソース グループを削除します。
az group delete --name my-deid
このコマンドは、完了するまで数分かかることがあります。
復旧を開始する
サービスの回復状態を調べるには、<service-url>/health に要求を送信します。