お客様が有効にしたディザスター リカバリー
重要
この記事で "(プレビュー)" と付記されている項目は、現在、パブリック プレビュー段階です。 このプレビューはサービス レベル アグリーメントなしで提供されており、運用環境ではお勧めしません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
アップタイムを最大化するために、Azure AI Studio での事業継続の維持とディザスター リカバリーの準備について事前に計画を立てておきます。 Azure AI Studio は Azure Machine Learning アーキテクチャに基づいて構築されているため、基本的なアーキテクチャを参照すると便利です。
Microsoft は、Azure サービスを常に使用できるようにする作業に取り組んでいます。 そうはいっても、計画外のサービス停止が発生する可能性はあります。 リージョン規模のサービス停止に対処するため、ディザスター リカバリー計画を用意しておくことをお勧めします。 この記事では、次のことについて説明します。
- Azure AI Studio と関連リソースの複数リージョンへのデプロイを計画する。
- ログ、ノートブック、Docker イメージ、その他のメタデータを回復できる可能性を最大限に高めます。
- ソリューションの高可用性に対応した設計を行う。
- 別のリージョンへのフェールオーバーを開始する。
重要
Azure AI Studio 自体では、自動フェールオーバーやディザスター リカバリーは提供されていません。
Azure AI Studio の Azure サービスの概要
Azure AI Studio は、複数の Azure サービスに依存します。 これらのサービスの一部は、ユーザー サブスクリプションでプロビジョニングされています。 これらのサービスの高可用性構成は、ユーザーが行う必要があります。 Microsoft は、Microsoft サブスクリプションで作成される一部のサービスを管理します。
次のような Azure サービスがあります。
Azure AI Studio インフラストラクチャ: Azure AI Studio ハブとプロジェクト用の Microsoft マネージド環境。 [基となるアーキテクチャ](Azure AI Studio アーキテクチャ ドキュメント) は、Azure Machine Learning によって提供されます。
必要な関連リソース: Azure AI Studio ハブとプロジェクトの作成時にサブスクリプションでプロビジョニングされるリソース。 これらのリソースには、Azure Storage と Azure Key Vault が含まれます。
- 既定のストレージには、モデル、トレーニング ログ データ、データ アセットの参照などのデータがあります。
- Key Vault には、Azure Storage と接続の資格情報があります。
省略可能な関連リソース: Azure AI Studio ハブにアタッチできるリソース。 これらのリソースには、Azure Container Registry と Application Insights が含まれます。
- Container Registry には、トレーニングおよび推論環境用の Docker イメージがあります。
- Application Insights は、Azure AI Studio を監視するためのものです。
コンピューティング インスタンス: ハブのデプロイ後に作成するリソース。 Microsoft によって管理されるモデル開発環境。
接続: Azure AI Studio は、他のさまざまなサービスに接続できます。 高可用性の設定の構成は、ユーザーが行う必要があります。
次の表に、Microsoft が管理する Azure サービスと、ユーザーが管理するものを示します。 また、既定で高可用性になっているサービスも示します。
| サービス | 管理者 | 既定で高可用性 |
|---|---|---|
| Azure AI Studio インフラストラクチャ | Microsoft | |
| 関連付けられているリソース | ||
| Azure Storage | あなたが | |
| Key Vault | あなたが | ✓ |
| Container Registry | あなたが | |
| Application Insights | あなたが | NA |
| コンピューティング リソース | ||
| コンピューティング インスタンス | Microsoft | |
| Azure AI サービスなどの外部サービスへの接続 | 自分 |
この記事の残りの部分では、これらの各サービスを高可用性にするために必要な操作について説明します。
複数リージョンへのデプロイを計画する
複数リージョンへのデプロイは、2 つの Azure リージョンで Azure AI Studio と他のリソース (インフラストラクチャ) を作成することに依存しています。 リージョン規模での停止が発生した場合、他のリージョンに切り替えることができます。 リソースをデプロイする場所を計画する際は、次の点を考慮してください。
リージョンの可用性: 可能であれば、同じ地理的領域でリージョンを使用します。最も近いリージョンにする必要はありません。 Azure AI Studio のリージョンの可用性を確認するには、「リージョン別の Azure 製品」を参照してください。
Azure ペア リージョン: ペアになったリージョンでは、プラットフォームの更新が調整され、必要に応じて復旧作業が優先されます。 ただし、ペアになっているリージョンがすべてのリージョンでサポートされることはありません。 詳細については、「Azure のペアになっているリージョン」をご覧ください。
サービスの可用性: ソリューションで使用されるリソースを、ホット/ホット、ホット/ウォーム、またはホット/コールドのいずれにするかを決定します。
- ホット/ホット: 両方のリージョンが同時にアクティブになり、1 つのリージョンですぐに使用を開始できます。
- ホット/ウォーム: プライマリ リージョンがアクティブになり、セカンダリ リージョンでは重要なリソース (デプロイされたモデルなど) を開始する準備ができています。 重要でないリソースは、セカンダリ リージョンに手動でデプロイする必要があります。
- ホット/コールド: プライマリ リージョンがアクティブになり、セカンダリ リージョンには必要なデータと共に Azure AI Studio と他のリソースがデプロイされています。 モデル、モデル デプロイ、パイプラインなどのリソースは、手動でデプロイする必要があります。
ヒント
ビジネス要件によっては、異なる Azure AI Studio リソースを異なる方法で扱ってもかまいません。
Azure AI Studio は、他のサービスに基づいて構築されています。 一部のサービスは、他のリージョンにレプリケートするように構成できます。 その他のものは、複数のリージョンで手動で作成する必要があります。 次の表に、サービスの一覧、レプリケーションの責任、および構成の概要を示します。
| Azure サービス | Geo レプリケートの責任 | 構成 |
|---|---|---|
| AI Studio のハブとプロジェクト | 自分 | 選んだリージョンにハブとプロジェクトを作成します。 |
| AI Studio コンピューティング | 自分 | 選択したリージョンにコンピューティング リソースを作成します。 動的にスケーリングできるコンピューティング リソースの場合は、両方のリージョンに、ニーズに見合った十分なコンピューティング クォータがあることを確認してください。 |
| Key Vault | Microsoft | 両方のリージョンの Azure AI Studio ハブとリソースで同じ Key Vault インスタンスを使います。 Key Vault は、セカンダリ リージョンに自動的にフェールオーバーします。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。 |
| ストレージ アカウント | 自分 | Azure Machine Learning では、geo 冗長ストレージ (GRS)、geo ゾーン冗長ストレージ (GZRS)、読み取りアクセス geo 冗長ストレージ (RA-GRS)、または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) を使用した "既定のストレージ アカウント" のフェールオーバーはサポートされていません。 ニーズに応じてストレージ アカウントを構成し、ハブに使います。 後続のすべてのプロジェクトでは、ハブのストレージ アカウントが使われます。 詳細については、「Azure Storage の冗長性」を参照してください。 |
| Container Registry | Microsoft | Container Registry インスタンスを構成して、Azure AI Studio 用にペアになっているリージョンにレジストリを geo レプリケートするようにします。 両方のハブ インスタンス用に同じインスタンスを使います。 詳細については、「Azure Container Registry の geo レプリケーション」を参照してください。 |
| Application Insights | あなたが | 両リージョンのハブに対して Application Insights を作成します。 データ保持期間と詳細を調整するには、「Application Insights でのデータの収集、保持、保存」を参照してください。 |
セカンダリ リージョンでの高速な復旧と再起動を可能にするには、次のような開発方法をお勧めします。
- Azure Resource Manager テンプレートを使用します。 テンプレートは、"コードとしてのインフラストラクチャ" であり、サービスを両方のリージョンで迅速にデプロイできます。
- 2 つのリージョン間のずれを避けるために、継続的インテグレーションとデプロイのパイプラインを更新して両方のリージョンにデプロイします。
- 両方のリージョンのユーザーに対するロールの割り当てを作成します。
- 両方のリージョンに対し、Azure Virtual Networks などのネットワーク リソースとプライベート エンドポイントを作成します。 ユーザーが両方のネットワーク環境にアクセスできるようにします。 たとえば、両方の仮想ネットワークに VPN と DNS の構成を行います。
高可用性向けの設計
可用性ゾーン
可用性ゾーンをサポートする特定の Azure サービス 可用性ゾーンをサポートするリージョンの場合、ゾーンが停止すると、すべてのプロジェクトが一時停止になり、データは保存する必要があります。 ただし、ゾーンがオンラインに戻るまで、データは更新できません。
詳しくは、「サービスとリージョンの可用性ゾーンのサポート」をご覧ください。
重要なコンポーネントを複数のリージョンにデプロイする
目指す事業継続のレベルを決定します。 レベルはソリューションのコンポーネントによって異なる場合があります。 たとえば、運用パイプラインまたはモデル デプロイの場合はホット/ホット構成とし、開発の場合はホット/コールドにすることができます。
Azure AI Studio はリージョン サービスであり、サービス側とサブスクリプション内のストレージ アカウント上の両方にデータを保存します。 リージョン規模の障害が発生すると、サービス データは復旧できません。 ただし、ストレージの冗長性が適用されている場合は、サービスによってサブスクリプションのストレージ アカウントに保存されたデータを回復できます。 サービス側に保存されるデータの大部分はメタデータ (タグ、資産名、説明) です。 ストレージ アカウントに保存されるのは、通常、アップロードされたデータなどの非メタデータです。
接続については、2 つの異なるリージョンに 2 つの個別のリソースを作成してから、ハブ用に 2 つの接続を作成することをお勧めします。 たとえば、ビジネス継続性のために AI Services が重要なリソースである場合、2 つの AI Services リソースとハブ用の 2 つの接続を作成することは、ビジネス継続性にとってお勧めの戦略になります。 この構成の場合、1 つのリージョンがダウンしても、まだ 1 つのリージョンが動作します。
ビジネス継続性に不可欠なハブの場合は、リソースを 2 つのリージョンにデプロイします。
分離ストレージ
AI アプリケーションをカスタマイズするためにデータに接続するシナリオでは、通常、データセットは Azure AI 内だけでなく、Azure AI の外部でも使用される可能性があります。 データセットのボリュームは非常に大きくなる可能性があるため、このデータを別のストレージ アカウントに保存することをお勧めします。 どのデータ レプリケーション戦略が自分のユース ケースにとって最も理にかなっているかを評価します。
AI Studio で、データに接続します。 異なるリージョンに複数の AI Studio インスタンスがある場合でも、接続は複数のリージョンにまたがって機能するため、同じストレージ アカウントを指している可能性があります。
フェールオーバーの開始
フェールオーバー ハブで作業を続行する
プライマリ ハブが使用できなくなった場合は、セカンダリ ハブに切り替えて開発を続行できます。 障害が発生した場合、Azure AI Studio からセカンダリ ハブにジョブは自動的に送信されません。 新しいハブまたはプロジェクトのリソースを指すようにコード構成を更新します。 ハブまたはプロジェクト参照のハードコーディングは避けることをお勧めします。
Azure AI Studio は、ハブ間で成果物やメタデータを同期または回復することはできません。 アプリケーションのデプロイ戦略によっては、続行するためにフェールオーバー ハブ内の成果物を移動または再作成する必要があります。 geo レプリケーションを有効にして関連リソースを共有するようにプライマリ ハブとセカンダリ ハブを構成する場合、フェールオーバー ハブから一部のオブジェクトを直接使用できる可能性があります。 たとえば、両方のハブが同じ Docker イメージ、構成されたデータストア、Azure Key Vault リソースを共有する場合などです。
Note
サービス停止が発生したときに実行中のジョブは、セカンダリ ハブに自動的に移行されません。 また、停止が解決したときに、ジョブがプライマリ ハブで再開されて正常に完了する見込みもありません。 代わりに、セカンダリ ハブまたは (停止が解決した後の) プライマリ ワークスペースのいずれかで、これらのジョブを再送信する必要があります。
Recovery options
リソースの削除
ハブとその既存のリソースが誤って削除された場合、一部のリソースは論理的な削除が有効になっており、リソースを復旧できる可能性があります。 ハブとプロジェクトは論理的な削除をサポートしていません。 削除されたハブまたはプロジェクトは復旧できません。 一部の基となるリソースは論理的な削除をサポートしているため、復旧できる可能性があります。 論理的な削除オプションがあるサービスについては、表を参照してください。
| サービス | 論理的な削除が有効 |
|---|---|
| Azure AI Studio ハブ | サポートされていない |
| Azure AI Studio プロジェクト | サポートされていない |
| Azure AI サービスのリソース | はい |
| Azure Storage | 削除されたストレージ アカウントの復旧に関する記事を参照してください。 |
| Azure Key Vault | はい |
次のステップ
- Azure AI Studio を使うセキュリティで保護されたインフラストラクチャのデプロイについては、セキュリティで保護されたハブの作成に関する記事を参照してください。
- SLA の詳細については、Azure のサービス レベル アグリーメントのページを参照してください。