次の方法で共有


Azureでデータ ストアを選択する準備をする

クラウド導入に合わせてランディング ゾーン環境を準備する場合は、ワークロードをホストするためのデータ要件を決定する必要があります。 Azureデータベース製品とサービスは、さまざまなデータ ストレージ シナリオと機能をサポートします。 データ要件をサポートするようにランディング ゾーン環境を構成する方法は、ワークロードのガバナンス、技術、ビジネスの要件によって異なります。

データ サービスの要件を特定する

ランディング ゾーンの評価と準備の一環として、ランディング ゾーンでサポートする必要があるデータ ストアを特定する必要があります。 このプロセスでは、ワークロードを構成する各アプリケーションとサービスを評価して、データ ストレージとアクセスの要件を決定します。 これらの要件を特定して文書化したら、ランディング ゾーンのポリシーを作成して、ワークロードのニーズに基づいて許可されるリソースの種類を制御できます。

ランディング ゾーン環境にデプロイするアプリケーションまたはサービスごとに、使用する適切なデータ ストア サービスを決定するのに役立つ開始点として、次の情報を使用します。

機能の要件

データの性質と、データの使用方法を検討します。

  • データ形式: 構造化 (テーブル)、半構造化 (JSON、XML、キー値)、または非構造化 (イメージとドキュメント)

  • 目的: トランザクション データのオンライン トランザクション処理 (OLTP) または複雑なアドホック データ分析のためのオンライン分析処理 (OLAP)

  • 検索のニーズ: インデックス作成機能またはフルテキスト検索機能

  • 特化: 高次元データ用のベクトルストアまたは高度に相互接続されたデータ用のグラフデータベース

  • データ アクセス方法: 直接クエリ言語 (SQL や Gremlin など)、REST API、SDK、または組み合わせ。 一部のプラットフォームでは、独自の API レイヤーへのアクセスが制限され、クエリの柔軟性と統合オプションに影響します。

  • データ リレーションシップ: 結合、グラフ トラバーサル、または階層構造

  • 整合性モデル: 厳密、最終的、または構成可能な一貫性

  • スキーマの柔軟性: 書き込み時のスキーマ (固定) とスキーマの読み取り時 (柔軟)

  • コンカレンシーのニーズ: オプティミスティックロックとペシミスティックロック、多くの書き込みが発生するシナリオ

  • データ ライフ サイクル: 有効期間が短いデータと長期アーカイブデータ、ホット データとコールド データ

  • データ移動: 抽出、変換、読み込み (ETL) の要件。抽出、読み込み、変換 (ELT) の要件。パイプラインとの統合

非機能要件

パフォーマンスとスケーラビリティの期待を評価します。

  • 待機時間とスループット: リアルタイム処理とバッチ処理
  • スケーラビリティ: 垂直スケーリングと水平スケーリング、およびグローバル分散
  • 信頼性と可用性: サービス レベル アグリーメント (SLA) の要件とフェールオーバー戦略
  • 制限: ストレージサイズ、スループット制限、パーティションの制約

コストと管理に関する考慮事項

運用オーバーヘッドと予算の要因:

  • マネージドとセルフホステッド: サービスとしてのソフトウェア (SaaS)、サービスとしてのプラットフォーム (PaaS)、サービスとしてのインフラストラクチャ (IaaS) のトレードオフ (制御、運用上のオーバーヘッド、柔軟性)
  • リージョンの可用性: データ所在地とコンプライアンスのニーズ
  • コストの最適化: 階層化ストレージ、パーティション分割、キャッシュ
  • ライセンスと移植性: ベンダーのロックインとオープン ソースの互換性

セキュリティとガバナンス

組織のポリシーとの整合性を確保します。

  • 暗号化: 保存時と転送中の暗号化
  • 認証と承認: ロールベースのアクセスと ID の統合
  • 監査と監視: アクティビティ ログ、アラート、診断
  • ネットワーキング: プライベート エンドポイント、ファイアウォール規則、仮想ネットワーク統合

DevOps とチームの準備

ソリューションをサポートおよび進化させるチームの能力を評価します。

  • スキル セット: クエリ言語、SDK、およびツールに関する知識
  • クライアントのサポート: 言語バインドとドライバーの可用性
  • ツールの統合: 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと監視ツール

主な質問

Azure データベース サービスのデシジョン ツリーに基づいて意思決定を行うために、ワークロードに関する次の質問に回答します。

  • OS およびデータベース エンジンに対して必要な制御レベルは何ですか? 一部のシナリオでは、データベース ワークロード用のソフトウェア構成とホスト サーバーの高度な制御または所有権が必要です。 これらのシナリオでは、カスタム IaaS 仮想マシン (VM) をデプロイして、データ サービスのデプロイと構成を完全に制御できます。 このレベルの制御は必要ないかもしれませんが、完全な PaaS ソリューションに移行する準備ができていない可能性があります。 その場合、マネージド インスタンスは、マネージド プラットフォームの利点を提供しながら、オンプレミスのデータベース エンジンとの互換性を高めることができます。

  • ワークロードではリレーショナル データベース テクノロジが使用されますか? その場合は、Azure SQL DatabaseAzure Database for MySQL、および Azure Database for PostgreSQL から選択します。これらはすべてマネージド PaaS データベース機能を提供します。

  • ワークロードはSQL Serverを使用しますか? Azureでは、ワークロードは IaaS ベースの SQL Server on Azure Virtual Machines または PaaS ベースの SQL Database でホストされるサービスで実行できます。 選択は、データベースの管理、修正プログラムの適用、バックアップの実行、またはこれらの操作をAzureに委任するかどうかによって異なります。 一部のシナリオでは、機能要件のために IaaS でホストされるSQL Serverが必要です。 詳細については、「Azureを参照してください。

  • Azure ソリューションには、Power Platform または Dynamics 365 ワークロードが含まれますか?Microsoft Dataverse は、Power Platform およびDynamics 365 ビジネス アプリケーション用の SaaS データ プラットフォームです。 この記事の PaaS および IaaS データベース サービスとは異なり、Dataverse はすべてのインフラストラクチャとエンジン管理を抽象化します。 リレーショナル データ ストアには、組み込みのビジネス ルール、詳細なセキュリティ (ロールベース、行レベル、列レベル)、標準化されたCommon Data Modelが用意されています。 クライアント アプリケーションは主に、基になるデータベース エンジンに SQL 接続を直接送信するのではなく、Dataverse API を介してデータにアクセスします。これにより、クエリの柔軟性とスループットが、Azureネイティブ データベース サービスと比較して制限されます。 Power Apps、Power Automate、Power Pages、またはDynamics 365を使用するソリューションの部分について Dataverse を評価します。 高スループット処理、複雑な分析クエリ、または直接データベース制御を必要とする同じソリューションのコンポーネントの場合は、Dataverse と共にAzureネイティブ データベース サービスを使用します。 Dataverse Azure Synapse Link for Dataverse、Microsoft Fabric などのツールを使用して、Dataverse サービスとAzure サービスの間でデータを同期できます。

  • ワークロードでキー値データベース ストレージを使用しますか?Azure Managed Redis は、最新の Redis Enterprise バージョンに基づくマネージド インメモリ データ ストアです。 待機時間が短く、スループットが高くなります。 Azure Cosmos DB では、キー値のストレージ機能も提供されます。

  • ワークロードでドキュメントまたはグラフ データを使用しますか?Azure Cosmos DB は、さまざまなデータ型と API をサポートするマルチモデル データベース サービスです。 また、ドキュメント データベースとグラフ データベースの機能も提供します。 Azure DocumentDB は、フル マネージドのオープン ソースの MongoDB 互換データベース サービスです。

  • ワークロードで Apache Cassandra のAzure Managed Instanceを使用しますか<>既存のデータセンターをAzureに拡張したり、クラウド専用クラスターとデータセンターとして機能したりできるマネージド Apache Cassandra クラスターを提供します。

  • ワークロードに高容量のデータ分析機能が必要ですか?Microsoft Fabric は、エンタープライズ対応のエンド ツー エンドの分析プラットフォームです。 データ移動、データ処理、インジェスト、変換、リアルタイム イベント ルーティング、レポート作成を統合します。

  • ワークロードには検索エンジン機能が必要ですか? Azure AI Search を使用して、アプリケーションに統合できる AI 強化のクラウドベースの検索インデックスを構築できます。

  • ワークロードで時系列データを使用しますか?Azure Data Explorer は、大量のデータをほぼリアルタイムで分析する、管理された高パフォーマンスのビッグ データ分析プラットフォームです。

各アプリケーションまたはサービスのデータベース オプションを評価する方法の詳細については、「 データ ストア モデルについて」を参照してください。

一般的なデータベース シナリオ

次の表に、一般的な使用シナリオの要件と、それらを処理するための推奨されるデータベース サービスを示します。

目標 推奨されるデータベース サービス
クラウド内のマネージドでインテリジェントな SQL データベースを使用してスケーリングするアプリを構築します。 SQLデータベース
クラウド内のマネージド up-to-date SQL インスタンスを使用して、SQL Serverアプリケーションを最新化します。 Azure SQL Managed Instance
完全なSQL Server互換性と OS レベルのアクセスを維持しながら、SQL ワークロードをAzureに移行します。 SQL Server on Virtual Machines
オープンソースの PostgreSQL でスケーラブルでマネージドなエンタープライズ対応アプリを構築し、高パフォーマンスで単一ノード PostgreSQL をスケールアウトするか、PostgreSQL と Oracle ワークロードをクラウドに移行します。 Azure Database for PostgreSQL
マネージド コミュニティの MySQL データベース サービスを使用して、オープンソースのモバイルおよび Web アプリに高可用性とエラスティック スケーリングを提供するか、MySQL ワークロードをクラウドに移行します。 Azure Database for MySQL
任意の場所、任意の規模で低待機時間と高可用性を保証するアプリケーションを構築するか、Cassandra、Gremlin、およびその他のNoSQLワークロードをクラウドに移行します。 Azure Cosmos DB
MongoDB ワークロードをクラウドに移行するか、高容量の垂直および水平スケーリングを使用してハイブリッドおよびマルチクラウド アプリケーションを構築する Azure DocumentDB
既存の Cassandra データ クラスターとアプリを最新化し、マネージド インスタンス サービスを使用して柔軟性を向上します。 Azure Managed Instance for Apache Cassandra
オープンソースと互換性のあるメモリ内データ ストアを使用して、高速でスケーラブルなアプリケーションを提供します。 Azure Managed Redis
Power Platform または組み込みのデータ モデリング、ビジネス ロジック、セキュリティを使用してDynamics 365を使用して、ビジネス アプリケーションを構築または拡張します。 Microsoft Dataverse

データベースとデータ プラットフォームの機能の比較

次の表に、Azure データ サービスとMicrosoft Dataverseで使用できる機能を示します。

特徴 SQL Database SQL Managed Instance Azure Database for PostgreSQL Azure Database for MySQL(アジュール データベース for MySQL) Apache Cassandra のAzure Managed Instance Azure Cosmos DB Azure マネージド Redis Azure DocumentDB Microsoft Dataverse
データベースの種類 リレーショナル リレーショナル リレーショナル リレーショナル NoSQL NoSQL メモリ内 NoSQL リレーショナル (マネージド)
データ モデル リレーショナル リレーショナル リレーショナル リレーショナル ワイド列 マルチモデル: ドキュメント、ワイド列、キー値、グラフ キーと値 ドキュメント リレーショナル
分散型マルチプライマリ書き込み いいえ いいえ いいえ いいえ イエス イエス イエス イエス いいえ
仮想ネットワーク接続のサポート 仮想ネットワーク サービス エンドポイント ネイティブ仮想ネットワークの実装 仮想ネットワークの挿入 (フレキシブル サーバーのみ) 仮想ネットワークの挿入 (フレキシブル サーバーのみ) ネイティブ仮想ネットワークの実装 仮想ネットワーク サービス エンドポイント 仮想ネットワーク サービス エンドポイント 仮想ネットワーク サービス エンドポイント マネージド仮想ネットワークのサポート

Azure Private Link service は、Azure データ サービスがプライベート ネットワーク経由で通信できるようにすることで、ネットワーク設計を簡素化します。 この表に示すほとんどのAzureデータベース サービスでは、private エンドポイントを介したAzure Private Linkがサポートされています。 マネージド インスタンス データベース サービスの場合、これらのインスタンスは仮想ネットワークにデプロイされるため、プライベート エンドポイントをデプロイする必要はありません。 Microsoft Dataverseは、Azure リソースではなく Power Platform でホストされ、その仮想ネットワークとプライベート接続のオプションについては、 Power Platform の管理された仮想ネットワークのサポートで説明されています。

リージョン別の提供状況

Azureは、どこでも顧客やパートナーにリーチするために必要な規模でサービスを提供するのに役立ちます。 クラウドデプロイを計画するときは、ワークロード リソースをホストするAzureリージョンを決定します。

ほとんどのAzureリージョンでは、ほとんどのデータベース サービスがサポートされています。 一部のリージョンでは、これらの製品のサブセットのみがサポートされていますが、主に政府機関のお客様を対象としています。 データベース リソースをデプロイするリージョンを決定する前に、「リージョン 別に利用可能な製品 」を参照して、リージョンの可用性の最新の状態を確認してください。

Microsoft Dataverse環境は、特定のAzure リージョンではなく、Power Platform geography (United States、ヨーロッパ、オーストラリアなど) にデプロイされます。 データは選択した地域内に留まりますが、その地域内のどのAzureリージョンが環境をホストするかを制御することはできません。 他のAzure サービスとのコロケーションを計画する場合、または特定の待機時間またはdata 常駐要件がある場合は、このより粗いリージョンの粒度を考慮してください。

グローバル インフラストラクチャAzure詳細については、「Azure geographies」を参照してください。

データ所在地とコンプライアンスの要件

データ ストレージに関連する法的および契約上の要件は、多くの場合、ワークロードに適用されます。 これらの要件は、組織の場所、データ ストアをホストする物理資産の管轄権、および該当するビジネス セクターによって異なる場合があります。 データ義務の次のコンポーネントについて考えてみましょう。

  • データの分類
  • データの場所
  • 共有責任モデルでのデータ保護の責任

これらの要件の詳細については、Azure でコンプライアントなデータ レジデンシーとセキュリティを実現するを参照してください。

コンプライアンスの取り組みの一部として、データベース リソースが物理的に配置されている場所の制御が含まれる場合があります。 Azure領域は、geographies と呼ばれるグループに編成されます。 Azure geography は、地理的および政治的境界内のデータ所在地、主権、コンプライアンス、回復性の要件を尊重します。 ワークロードがデータ主権またはその他のコンプライアンス要件の対象である場合は、準拠しているAzure地域のリージョンにストレージ リソースをデプロイする必要があります。

データベース サービスの制御を確立する

ランディング ゾーン環境を準備するときに、ユーザーがデプロイできるデータ ストアを制限するコントロールを確立できます。 コントロールは、コストを管理し、セキュリティ リスクを制限するのに役立ちます。 開発者と IT チームは、ワークロードをサポートするリソースをデプロイおよび構成できます。

ランディング ゾーンの要件を特定して文書化したら、Azure Policy を使用して、ユーザーが作成できるデータベース リソースを制御できます。 コントロールでは、 データベース リソースの種類の作成を許可または拒否できます。

たとえば、SQL Database リソースのみを作成するようにユーザーを制限できます。 ポリシーを使用して、ユーザーがリソースを作成するときに選択できるオプションを制御します。 たとえば、特定のバージョンのSQL Serverのみを IaaS VM にインストールできるようにすることで、ユーザーがプロビジョニングできる SQL Database SKU を制限できます。 詳細については、「Azure Policy組み込みのポリシー定義を参照してください。

クラウド資産全体のリソース、リソース グループ、サブスクリプション、管理グループにポリシーを適用する必要があります。

Microsoft Dataverse環境は、Azure Policyではなく、Power Platform 管理センターを介して個別に管理されます。 マネージド環境データ損失防止ポリシーを使用して、環境の作成、コネクタの使用状況、およびデータ移動を制御します。 ソリューションがAzureネイティブ データベースと Dataverse の両方にまたがる場合は、両方のコントロール プレーンにわたってガバナンスを計画します。

次のステップ

次の記事を使用して、特殊なデータ ストアを選択します。