コンピューティング リソースは仮想コアとして提供されます。仮想コアは、基礎となるハードウェアの論理 CPU を表します。 プロビジョニングのストレージ サイズとは、クラスターでシャードに利用できる容量のことです。 ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、データベース サーバー ログに使われます。 コンピューティングとストレージの設定は、個別に選択できます。 選んだコンピューティングとストレージの値は、クラスター内のシャードごとに適用されます。
Azure Cosmos DB for MongoDB 仮想コアでのコンピューティング
1 つのシャードの RAM の合計容量は、選んだ仮想コアの数に基づいています。
| クラスター レベル | 仮想コア | 1 つのシャード、GiB RAM |
|---|---|---|
| M10 | 1 (バースト可能) | 2 |
| M20 | 2 (バースト可能) | 4 |
| M25 | 2 (バースト可能) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Azure Cosmos DB for MongoDB 仮想コアでのストレージ
プロビジョニングするストレージの合計容量によって、クラスター内の各シャードに使用できる I/O 容量も決まります。
| ストレージ サイズ、GiB | 最大 IOPS |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5,000 |
| 2,048 | 7,500 |
| 4,095 | 7,500 |
| 8,192 | 16,000 |
| 16,384 | 18,000 |
| 32,767 | 20,000 |
† 空きディスク バーストでの最大 IOPS。 最大 512 GiB までのストレージでは、空きディスク バーストが有効になっています。
コンピューティングとストレージの構成に対する IOPS の最大化
"コンピューティング" の各構成には、仮想コアの数に応じた IOPS 制限があります。 選んだストレージで IOPS が完全に利用されるように、クラスターのコンピューティング構成を選んでください。
| ストレージ サイズ | ストレージの IOPS、最大 | 最小コンピューティング レベル | 最小仮想コア |
|---|---|---|---|
| 最大 0.5 TiB | 3,500† | M30 | 2 仮想コア |
| 1 TiB | 5,000 | M40 | 4 仮想コア |
| 2 TiB | 7,500 | M50 | 8 仮想コア |
| 4 TiB | 7,500 | M50 | 8 仮想コア |
| 8 TiB | 16,000 | M60 | 16 仮想コア |
| 16 TiB | 18,000 | M60 | 16 仮想コア |
| 32テビバイト (TiB) | 20,000 | M60 | 16 仮想コア |
† 空きディスク バーストでの最大 IOPS。 最大 512 GiB までのストレージでは、空きディスク バーストが有効になっています。
たとえば、シャードあたり 8 TiB 以上のストレージが必要な場合は、ノードのコンピューティング構成で 16 仮想コア以上を選んでください。 それを選ぶと、選択したストレージによって提供される IOPS 使用率を最大にできます。
コンピューティングとストレージに関する考慮事項
ワーキング セットとメモリに関する考慮事項
Azure Cosmos DB for MongoDB 仮想コアでは、"ワーキング セット" とはアプリケーションによって頻繁にアクセスされて使われるデータの部分を指します。 これには、アプリケーションの一般的な操作の間に定期的に読み取りまたは書き込みが行われるデータとインデックスの両方が含まれます。 多くのデータベースと同様に MongoDB でもワーキング セットが RAM に収まるとパフォーマンスが最高になるため、ワーキング セットの概念はパフォーマンスの最適化にとって重要です。
MongoDB データベースのワーキング セットを定義して理解するには、次のコンポーネントを検討します。
- 頻繁にアクセスされるデータ: このデータには、アプリケーションが定期的に読み取りまたは更新を行うドキュメントが含まれます。
- インデックス: クエリ操作で使われるインデックスも、高速アクセスのためにはメモリに読み込まれる必要があるため、ワーキング セットの一部を形成します。
- アプリケーションの使用パターン: アプリケーションの使用パターンを分析すると、データのどの部分が最も頻繁にアクセスされているかを特定するのに役立ちます。
ワーキング セットを RAM に保持すると、低速のディスク I/O 操作が最小限になるので、MongoDB データベースのパフォーマンスを向上させることができます。 ワーキング セットが利用できる RAM より大きい場合は、データ モデルの最適化、RAM の追加、またはシャーディングを使用した複数のノードへのデータの分散を検討します。
ワークロードに最適な構成の選択
Azure Cosmos DB for MongoDB 仮想コア ワークロードに適したコンピューティングとストレージの構成を決定するには、アプリケーションの要件と使用パターンに関連するいくつかの要因を評価する必要があります。 最適な構成を決定するための主な手順と考慮事項は次のとおりです。
ワークロードを理解する
- データの量: インデックスも含め、データの合計サイズを見積もります。
- 読み取り/書き込み比率: 書き込み操作に対する読み取り操作の比率を確認します。
- クエリ パターン: アプリケーションで実行されるクエリの種類を分析します。 たとえば、単純な読み取り、複雑な集計などです。
- コンカレンシー: データベースで処理する必要がある同時実行操作の数を評価します。
現在のパフォーマンスを監視する
- リソース使用率: Azure にワークロードを移動する前に監視ツールを使って CPU、メモリ、ディスク I/O、ネットワークの使用状況を追跡し、Azure Cosmos DB for MongoDB 仮想コア クラスターで MongoDB ワークロードの実行を始めた後はメトリックを監視します。
- パフォーマンス メトリック: 待ち時間、スループット、キャッシュ ヒット率などの主要なパフォーマンス メトリックを監視します。
- ボトルネック: 高い CPU 使用率、メモリの不足、低速のディスク I/O など、既存のパフォーマンスのボトルネックを特定します。
リソースの要件を見積もる
- メモリ: ワーキング セット (頻繁にアクセスされるデータとインデックス) が RAM に収まることを確認します。 ワーキング セットのサイズが利用できるメモリより大きい場合は、RAM の追加またはデータ モデルの最適化を検討します。
- CPU: クエリの負荷とコンカレンシーの要件を処理できる CPU 構成を選びます。 CPU 負荷の高いワークロードでは、必要なコアが多くなる場合があります。 Azure Cosmos DB for MongoDB 仮想コア クラスターで 'CPU 使用率' メトリックと '最大' 集計を使って、コンピューティングの過去の使用パターンを確認します。
- ストレージ IOPS: 読み取りと書き込みの操作を処理するのに十分な IOPS を持つストレージを選びます。 クラスターで 'IOPS' メトリックと '最大' 集計を使って、ストレージ IOPS の過去の使用状況を確認します。
- ネットワーク: アプリケーションとデータベース間のデータ転送を処理するのに十分なネットワーク帯域幅があることを確認します (特に分散セットアップの場合)。 SR-IOV などの高速ネットワーク テクノロジをサポートするように MongoDB アプリケーションのホストを構成したことを確認します。
適切にスケーリングする
- 垂直スケーリング: コンピューティングと RAM をスケールアップおよびスケールダウンし、ストレージをスケールアップします。
- コンピューティング: ワークロードで一時的な増強が必要な場合、または長時間にわたって CPU 使用率が 70% を超えることがよくある場合は、クラスターの仮想コアと RAM を増やします。
- Azure Cosmos DB for MongoDB 仮想コア データベースのデータ保持期間が適切であることを確認します。 データ保持を使うと、不要なストレージの使用を回避できます。 'ストレージ使用率' と 'ストレージ使用量' メトリックの一方または両方と '最大' 集計に対してアラートを設定して、ストレージの使用状況を監視します。 ワークロードのサイズが使用率 70% を超える場合は、ストレージの増量を検討します。
- 水平スケーリング: ワークロードが拡大したら、パフォーマンスと容量管理の向上のため、クラスターで複数のシャードを使って、複数の Azure Cosmos DB for MongoDB 仮想コア ノードにデータを分散させることを検討します。 これは、大きなデータセット (2 から 4 TiB を超えるもの) と高いスループットのアプリケーションに特に役立ちます。
- 垂直スケーリング: コンピューティングと RAM をスケールアップおよびスケールダウンし、ストレージをスケールアップします。
テストして繰り返す
- ベンチマーク: 最も頻繁に使われるクエリをさまざまな構成で測定して、パフォーマンスへの影響を判断します。 CPU/RAM と IOPS のメトリックとアプリケーション レベルのベンチマークを使います。
- ロード テスト: ロード テストを実施して運用ワークロードをシミュレートし、選んだ構成のパフォーマンスを検証します。
- 継続的な監視: Azure Cosmos DB for MongoDB 仮想コアのデプロイを継続的に監視し、ワークロードと使用パターンの変化に基づき必要に応じてリソースを調整します。
これらの要因を体系的に評価し、構成を継続的に監視して調整すると、特定のワークロードに対する MongoDB のデプロイの適切な最適化を実現できます。
ストレージに関する考慮事項
ワークロードに適したストレージ サイズの決定では、いくつかのことを考慮して、パフォーマンスとスケーラビリティが最適になるようにします。 Azure Cosmos DB for MongoDB 仮想コアでのストレージ サイズに関する考慮事項を次に示します。
データ サイズを見積もる:
- Azure Cosmos DB for MongoDB 仮想コア データの予想されるサイズを計算します。 検討事項:
- 現在のデータ サイズ: 既存のデータベースから移行する場合。
- 増加率: 時間の経過に伴って追加されるデータの量を見積もります。
- ドキュメントのサイズと構造: ストレージの効率に影響を与えるので、データ スキーマとドキュメントのサイズを把握します。
- Azure Cosmos DB for MongoDB 仮想コア データの予想されるサイズを計算します。 検討事項:
インデックスを考慮する:
- Azure Cosmos DB for MongoDB 仮想コアでは、効率的なクエリのためにインデックスが使われます。 インデックスは余分なディスク領域を消費します。
- 以下に基づいてインデックスのサイズを見積もります。
- インデックスの数。
- インデックスを作成するフィールドのサイズ。
パフォーマンスに関する考慮事項:
- ディスクのパフォーマンスはデータベースの操作に影響します。ワーキング セットが RAM に収まらないワークロードの場合は特にそうです。 検討事項:
- I/O スループット: IOPS (1 秒あたりの入出力操作数) は、1 秒間にストレージ ディスクに送信される要求の数です。 ストレージ サイズが大きいほど、IOPS が増えます。 読み取り/書き込み操作に対して十分なスループットを確保します。 クラスターで使われている IOPS を監視するには、'IOPS' メトリックと '最大' 集計を使います。
- 待ち時間: 待ち時間は、アプリケーションが 1 つの要求を受信し、その要求をストレージ ディスクに送信して、クライアントに応答を送信するまでの所要時間です。 待機時間は、IOPS とスループットに加え、アプリケーションのパフォーマンスの重要な評価基準となります。 待ち時間は、主に、使われるストレージの種類とストレージの構成によって定義されます。 Azure Cosmos DB for MongoDB のような管理サービスでは、Premium SSD ディスクなどの高速ストレージが、待ち時間の短縮に最適化された設定で使われます。
- ディスクのパフォーマンスはデータベースの操作に影響します。ワーキング セットが RAM に収まらないワークロードの場合は特にそうです。 検討事項:
将来の拡大とスケーラビリティ:
- 将来のデータの拡大とスケーラビリティのニーズに備えます。
- 頻繁にストレージを拡張することなく拡大に対応するため、現在のニーズより多くのディスク領域を割り当てます。
計算の例:
- 初期データ サイズは 500 GiB であるとします。
- インデックスを含めると、700 GiB に増加する可能性があります。
- 2 年間でデータが 2 倍になると予想される場合は、1.4 TiB (700 GiB * 2) を計画します。
- オーバーヘッド、増加、運用のニーズのためのバッファーを追加します。
- 現時点で 1 TiB のストレージから始めて、サイズが 800 GiB を超えたら 2 TiB に拡大できます。
ストレージ サイズの決定には、現在と将来のデータ ニーズの見積もり、インデックス作成と圧縮の検討、適切なパフォーマンスとスケーラビリティの確保を組み合わせる必要があります。 また、MongoDB の最適なパフォーマンスを維持するには、定期的な監視と、実際の使用状況と増加傾向に基づく調整も重要です。