Azure DocumentDB の高パフォーマンスストレージ

Azure DocumentDB では、Premium SSD v2 ディスクを使用して、IOPS と帯域幅の設定からストレージ容量を結合解除することで、I/O 負荷の高いワークロードに対して大幅に高いパフォーマンスを実現します。

Azure DocumentDB 上の Premium SSD v2 ストレージでは、クラスター用に構成されているストレージ容量に関係なく、構成可能な最大 IOPS と帯域幅の設定が既定で使用できます。コンピューティングレベルの IOPS と帯域幅容量によって、ストレージ容量をスケールアップする必要なく、ストレージ層で達成可能な IOPS と帯域幅が決まります。

必要なストレージ容量のみを選択する必要がある一方で、達成可能な最高の IOPS と帯域幅は、Azure DocumentDB によって追加料金なしで自動的に構成されます。最適なパフォーマンスを得るためにクラスターを確実に設定するために、追加のユーザー介入は必要ありません。その結果、 追加コストなしで 12 倍のパフォーマンスが向上します。

以前は、5,000 IOPS から 20,000 IOPS へのジャンプでは、より高いストレージニーズがない場合でも、ディスクのサイズを 1 TB から 20 TB に増やす必要があります。 Premium SSD v2 では、クラスターのコンピューティングレベルに 20,000 IOPS をプッシュして維持する容量がある限り、同じ 1 TB ディスクで 20,000 IOPS を実現できます。さらに、Premium SSD v2 ディスクでは、最大 80,000 IOPS (Premium SSD より 4 倍増加) をサポートできます。

ガイダンス

Azure DocumentDB クラスターのmaximum パフォーマンスは、ストレージサイズではなく、compute レベルのみに依存するようになりました。まず、クラスターに必要なストレージサイズのみを選択してから、ワークロードに必要な (IOPS) とスループット (MBps) を提供するコンピューティングレベルを選択します。コンピューティングレベルあたりの最大の達成可能で持続可能な IOPS と帯域幅の制限を次に示します。

IOPS とスループットの上限

Premium SSD v2 ディスクでは、クラスターは、追加 コストなしで、次の表に示す上限値で自動的に構成されます。

コンピューティングレベル	最大 IOPS	最大帯域幅 (MBps)
M30 (2 コア)	3,750	85
M40 (4 コア)	6,400	145
M50 (8 コア)	12,800	290
M60 (16 コア)	25,600	600
M80 (32 コア)	5万1,200	865
M200 (64 コア)	80,000	1,200

[前提条件]

Azure サブスクリプション
- Azure サブスクリプションがない場合は、無料アカウントを作成してください。

既存の Azure DocumentDB クラスター
- クラスターがない場合は、新しいクラスターを作成します

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Get started with Azure Cloud Shell」を参照してください。
CLI 参照コマンドをローカルで実行する場合は、Azure CLIinstallします。 Windowsまたは macOS で実行している場合は、Docker コンテナーでAzure CLIを実行することを検討してください。詳細については、「 Docker コンテナーでAzure CLIを実行する方法を参照してください。
- ローカルインストールを使用している場合は、az login コマンドを使用してAzure CLIにサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、「Azure CLI を使用して Azure に認証する方法」を参照してください。
- メッセージが表示されたら、最初に使用するときにAzure CLI拡張機能をインストールします。拡張機能の詳細については、「Azure CLIを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

Terraform 1.2.0 以降。

高パフォーマンスストレージを使用してクラスターを作成する

クラスター作成手順の一環として、 Premium SSD v2 (ハイパフォーマンス) ストレージを使用してクラスターを構成します。

Azure ポータル (https://portal.azure.com) にサインインします。
Azure ポータルメニューまたは Home ページで、リソースの作成を選択します。
New ページで、Azure DocumentDB を検索して選択します。

Azureポータルの検索機能を使ってAzure DocumentDBを見つけるためのスクリーンショットです。
Create Azure DocumentDB クラスターページで、Basics セクション内で、 Cluster レベル>> セクション内の Configure オプションを選択します。
[ 構成 ] ページで、必要に応じてクラスター層とストレージサイズを選択します。 Premium SSD v2 としてストレージの種類を選択してハイパフォーマンスストレージを有効にし、[保存] を選択して変更を適用します。
残りの詳細を入力し、[ 確認と作成] を選択します。
指定した設定を確認し、[作成] を選択します。クラスターの作成には数分かかります。リソースのデプロイが完了するまで待ちます。
最後に、Go to resource を選択して、ポータルで Azure DocumentDB クラスターに移動します。

デプロイ完了ステップのスクリーンショットで、新しいAzure DocumentDB クラスターに移動するオプションを含みます。

新しいターミナルを開きます。
Azure CLIにサインインします。
ロール定義を定義する新しいBicep ファイルを作成します。 ファイルに main.bicep という名前を付けます。

このテンプレートをファイルのコンテンツに追加します。 <cluster-name>、<location>、<username>、および<password>のプレースホルダーを適切な値に置き換えます。

resource cluster 'Microsoft.DocumentDB/mongoClusters@2025-09-01' = {
  name: '<cluster-name>'
  location: '<location>'
  properties: {
    administrator: {
      userName: '<username>'
      password: '<password>'
    }
    serverVersion: '8.0'
    storage: {
      sizeGb: 32
      type: 'PremiumSSDv2'
    }
    compute: {
      tier: 'M30'
    }
    sharding: {
      shardCount: 1
    }
    highAvailability: {
      targetMode: 'Disabled'
    }
  }
}

az deployment group create を使用してBicep テンプレートをデプロイします。 Bicep テンプレートの名前を指定し、<resource-group> プレースホルダーをターゲット Azure リソースグループの名前に置き換えます。
```
az deployment group create \
    --resource-group "<resource-group>" \
    --template-file main.bicep
```
デプロイが完了するまで待ちます。デプロイメントからの出力を評価します。

新しいターミナルを開きます。
Azure CLIにサインインします。
ターゲット Azure サブスクリプションを確認します。
```
az account show
```
新しい Terraform ファイルでクラスターを定義します。ファイルに cluster.tf という名前を付けます。

このリソース構成をファイルのコンテンツに追加します。 <cluster-name>、<resource-group>、および<location>プレースホルダーを適切な値に置き換えます。

variable "admin_username" {
  type        = string
  description = "Administrator username for the cluster."
  sensitive   = true
}

variable "admin_password" {
  type        = string
  description = "Administrator password for the cluster."
  sensitive   = true
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = "<resource-group>"
}

resource "azurerm_mongo_cluster" "cluster" {
  name                   = "<cluster-name>"
  resource_group_name    = data.azurerm_resource_group.existing.name
  location               = "<location>"
  administrator_username = var.admin_username
  administrator_password = var.admin_password
  shard_count            = "1"
  compute_tier           = "M30"
  high_availability_mode = "Disabled"
  storage_size_in_gb     = "32"
  storage_type           = "PremiumSSDv2"
  version                = "8.0"
}

ヒント

azurerm_mongo_cluster リソースを使用するオプションの詳細については、Terraform Registry のプロバイダードキュメントazurerm参照してください。

Terraform デプロイを初期化します。
```
terraform init --upgrade
```
実行プランを作成し、 cluster.tfplan という名前のファイルに保存します。 admin_username変数とadmin_password変数の入力を求められたら、値を指定します。
```
ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --out "cluster.tfplan"
```
注

このコマンドは、 ARM_SUBSCRIPTION_ID 環境変数を一時的に設定します。この設定は、バージョン 4.0 以降のazurerm プロバイダーに必要です。詳細については、azurermのサブスクリプション ID を参照してください。

実行プランを適用して、クラスターをAzureにデプロイします。

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "cluster.tfplan"

デプロイが完了するまで待ちます。デプロイメントからの出力を評価します。

新しいターミナルを開きます。
Azure CLIにサインインします。
cluster.jsonという名前の新しい JSON ファイル を作成します 。

このドキュメントをファイルのコンテンツに追加します。 <location>、<username>、および<password>プレースホルダーを適切な値に置き換えます。

{
  "location": "<location>",
  "properties": {
    "administrator": {
      "userName": "<username>",
      "password": "<password>"
    },
    "serverVersion": "8.0",
    "storage": {
      "sizeGb": 32,
      "type": "PremiumSSDv2"
    },
    "compute": {
      "tier": "M30"
    },
    "sharding": {
      "shardCount": 1
    },
    "highAvailability": {
      "targetMode": "Disabled"
    }
  }
}

az rest Azure CLI コマンドを使用して、JSON ファイルで指定された構成で新しいクラスターを作成します。要求の body として JSON ファイルの名前を指定し、次のプレースホルダーを置き換えます。

	Description
`<subscription-id>`	ターゲット Azure サブスクリプションの一意の識別子
`<resource-group>`	ターゲット Azure リソースグループの名前
`<cluster-name>`	新しい Azure DocumentDB クラスターの一意の名前

az rest \
    --method "GET" \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01" \
    --body @cluster.json

ヒント

ターゲット Azure サブスクリプションの一意識別子を取得するには、az account show を使用します。

デプロイが完了するまで待ちます。デプロイメントからの出力を評価します。

ハイパフォーマンスストレージ (Premium SSD v2 ストレージ) の現在の制限事項

カスタマーマネージドキー (CMK) は、Premium SSD v2 ストレージではサポートされていません。
Premium SSD v2 ディスクのストレージ容量の設定は、24 時間以内に最大 4 回調整できます。新しく作成されたクラスターでは、最初の 24 時間に最大 3 つのストレージ容量調整を行うことができます。
Premium SSD から Premium SSD v2 へのレプリケーションは、移行シナリオでのみサポートされます。 Premium SSD は Premium SSD v2 のパフォーマンスと一致せず、待機時間が長くなる可能性があるため、継続的なレプリケーションはサポートされていません。
Premium SSD から Premium SSD v2 へのオンライン移行は現在サポートされていません。 Premium SSD から Premium SSD V2 にアップグレードするには、Premium SSD v2 を使用して新しいサーバーへのポイントインタイムリストアを実行できます。または、Premium SSD サーバーから Premium SSD v2 サーバーに読み取りレプリカを作成し、レプリケーションの完了後に昇格させることもできます。
ディスクハイドレートを必要とする操作を実行すると、次のエラーが発生する可能性があります。このエラーは、Premium SSD v2 ディスクがディスクのハイドレート中に操作をサポートしていないために発生します。
- エラーメッセージ: ディスクがまだハイドレートされているため、操作を完了できません。しばらくしてからやり直してください。
- この動作をトリガーできる操作は次のとおりです。
  - コンピューティングのスケーリング、ストレージのスケーリングを実行し、高可用性 (HA) を連続して有効にします。
  - これには、高可用性を保証するサービスによってトリガーされるフェールオーバーも含まれます。
  - PITR (ポイントインタイムリストア) を使用して新しいクラスターを作成し、ディスクのハイドレート中にすぐに高可用性を有効にします。
- ベストプラクティスとして、Premium SSD v2 ディスクを使用する場合は、これらの操作を空けるか、順番に完了して、アクション間でディスクハイドレーションが完了するようにします。

Compare Azure DocumentDB to MongoDB
Azure DocumentDB

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-17

次の方法で共有

Azure DocumentDB の高パフォーマンス ストレージ

ガイダンス

IOPS とスループットの上限

[前提条件]

高パフォーマンス ストレージを使用してクラスターを作成する

ハイ パフォーマンス ストレージ (Premium SSD v2 ストレージ) の現在の制限事項

関連コンテンツ

フィードバック

その他のリソース

Azure DocumentDB の高パフォーマンスストレージ

高パフォーマンスストレージを使用してクラスターを作成する

ハイパフォーマンスストレージ (Premium SSD v2 ストレージ) の現在の制限事項