Azure DocumentDB コンピューティング リソースは、基になるハードウェアの論理 CPU を表す仮想コアとして提供されます。 プロビジョニング用のストレージサイズは、クラスタ内のシャードで利用可能な容量を指します。
ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、およびデータベース サーバー ログに使用されます。 コンピューティングとストレージの設定は、個別に選択できます。 選択したコンピューティングとストレージの値は、クラスター内の各シャードに適用されます。
Azure DocumentDB でのコンピューティング
1 つのシャード内の RAM の合計量は、選択した仮想コア数に基づいています。
| クラスター レベル | vCores | 1 つのシャード、GiB RAM |
|---|---|---|
| M10 | 1 (バースト可能) | 2 |
| M20 | 2 (バースト可能) | 4 |
| M25 | 2 (バースト可能) | 八 |
| M30 | 2 | 八 |
| M40 | 4 | 16 |
| M50 | 八 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
コンピューティングとストレージに関する考慮事項
Azure DocumentDB クラスターを構成するときは、コンピューティングとストレージの選択が特定のワークロードのパフォーマンス、コスト、スケーラビリティにどのように影響するかを理解することが重要です。
ワーキング セットとメモリに関する考慮事項
Azure DocumentDB では、ワーキング セット は、アプリケーションによって頻繁にアクセスおよび使用されるデータの部分を指します。 これには、アプリケーションの一般的な操作中に定期的に読み取りまたは書き込まれるデータとインデックスの両方が含まれます。 ワーキング セットの概念は、多くのデータベースと同様に、ワーキング セットが RAM に収まるときに MongoDB が最適に実行されるため、パフォーマンスの最適化に重要です。
MongoDB データベースワーキング セットを定義して理解するには、次のコンポーネントを検討してください。
- 頻繁にアクセスされるデータ: このデータには、アプリケーションが定期的に読み取りまたは更新するドキュメントが含まれます。
- インデックス: 高速アクセスを確保するためにメモリに読み込む必要があるため、クエリ操作で使用されるインデックスもワーキング セットの一部になります。
- アプリケーションの使用パターン: アプリケーションの使用パターンを分析すると、データのどの部分が最も頻繁にアクセスされているかを特定するのに役立ちます。
ワーキング セットを RAM に保持することで、低速なディスク I/O 操作を最小限に抑え、MongoDB データベースのパフォーマンスを向上させることができます。 ワーキング セットが使用可能な RAM を超える場合は、データ モデルの最適化、クラスターへの RAM の追加、またはシャーディングを使用して複数のノードにデータを分散することを検討してください。
ワークロードに最適な構成を選択する
Azure DocumentDB ワークロードに適したコンピューティングとストレージの構成を決定するには、アプリケーションの要件と使用パターンに関連するいくつかの要因を評価する必要があります。 最適な構成を決定するための主な手順と考慮事項は次のとおりです。
ワークロードを理解する
- データ 量: インデックスを含むデータの合計サイズを見積もります。
- 読み取り/書き込み比率: 読み取り操作と書き込み操作の比率を決定します。
- クエリ パターン: アプリケーションが実行するクエリの種類を分析します。 たとえば、単純な読み取り、複雑な集計などです。
- コンカレンシー: データベースで処理する必要がある同時実行操作の数を評価します。
現在のパフォーマンスを監視する
- リソース使用率: ワークロードをAzureに移行する前に、監視ツールを使用して CPU、メモリ、ディスク I/O、ネットワークの使用状況を追跡します。 Azure DocumentDB クラスターに MongoDB ワークロードをデプロイした後、Azure監視メトリックを使用して監視を続行します。
- パフォーマンス メトリック: 待機時間、スループット、キャッシュ ヒット率などの主要なパフォーマンス メトリックを監視します。
- ボトルネック: CPU 使用率の高さ、メモリ不足、低速ディスク I/O など、既存のパフォーマンスのボトルネックを特定します。
リソース要件の見積もり
- メモリ: ワーキング セット (頻繁にアクセスされるデータとインデックス) が RAM に収まるようにします。 ワーキング セットのサイズが使用可能なメモリを超える場合は、RAM を追加するか、データ モデルを最適化することを検討してください。
- CPU: クエリの負荷とコンカレンシーの要件を処理できる CPU 構成を選択します。 CPU 負荷の高いワークロードでは、より多くのコアが必要になる可能性があります。 Azure DocumentDB クラスターで "最大" 集計で "CPU 割合" メトリックを使用して、コンピューティングの使用状況の履歴パターンを確認します。
- ストレージ IOPS: クラスターの "最大" 集計で "IOPS" メトリックを使用して、ストレージ IOPS の使用状況の履歴を確認します。
- ネットワーク: アプリケーションとデータベース間のデータ転送を処理するのに十分なネットワーク帯域幅を確保します (特に分散セットアップの場合)。 SR-IOV などの 高速ネットワーク テクノロジをサポートするように MongoDB アプリケーションのホストを構成していることを確認します。
適切にスケーリングする
-
垂直方向のスケーリング: コンピューティング/RAM をスケールアップおよびスケールダウンし、ストレージをスケールアップします。
- コンピューティング: ワークロードで一時的な増加が必要な場合、または長時間にわたって 70% を超える CPU 使用率を超える場合は、クラスター上の仮想コア/RAM を増やします。
- Azure DocumentDB データベースに適切なデータ保有期間があることを確認します。 リテンション期間を使用すると、不要なストレージの使用を回避できます。 "最大" 集計を使用して、"ストレージの割合" または "使用されているストレージ" メトリックに アラートを設定 して、ストレージの使用状況を監視します。 ワークロードサイズが 70% 使用量を超えるので、ストレージを増やすことを検討してください。
- Horizontal scaling: クラスターに複数のシャードを使用して、複数のAzure DocumentDB ノードにデータを分散し、ワークロードの増加に合わせてパフォーマンスを向上させ、容量管理を強化することを検討してください。 このスケーリングは、大規模なデータセット (2 から 4 TiB を超える) と高スループットのアプリケーションに特に役立ちます。
-
垂直方向のスケーリング: コンピューティング/RAM をスケールアップおよびスケールダウンし、ストレージをスケールアップします。
テストと反復処理
- ベンチマーク: 構成が異なる最も頻繁に使用されるクエリの測定を実行して、パフォーマンスへの影響を判断します。 CPU/RAM と IOPS のメトリックとアプリケーション レベルのベンチマークを使用します。
- ロード テスト: ロード テストを実施して運用ワークロードをシミュレートし、選択した構成のパフォーマンスを検証します。
- 継続的な監視: Azure DocumentDB のデプロイを継続的に監視し、変化するワークロードと使用パターンに基づいて必要に応じてリソースを調整します。
これらの要因を体系的に評価し、構成を継続的に監視および調整することで、MongoDB デプロイが特定のワークロードに対して適切に最適化されていることを確認できます。
ストレージに関する考慮事項
ワークロードに適したストレージ サイズを決定するには、最適なパフォーマンスとスケーラビリティを確保するためにいくつかの考慮事項が必要です。 Azure DocumentDB のストレージ サイズに関する考慮事項を次に示します。
データ サイズの見積もり:
- Azure DocumentDB データの予想されるサイズを計算します。 以下を検討してください。
- 現在のデータ サイズ: 既存のデータベースから移行する場合。
- 成長率： 時間の経過と同時に追加されるデータの量を見積もります。
- ドキュメントのサイズと構造: ストレージの効率に影響を与えるデータ スキーマとドキュメントサイズを理解します。
- Azure DocumentDB データの予想されるサイズを計算します。 以下を検討してください。
インデックスの要素:
- Azure DocumentDB では、効率的なクエリを実行するために indexes を使用します。 インデックスは余分なディスク領域を消費します。
- 次に基づいてインデックスのサイズを推定します。
- インデックスの数。
- インデックス付きフィールドのサイズ。
パフォーマンスに関する考慮事項:
- ディスクのパフォーマンスはデータベース操作に影響します。特に、 ワーキング セット を RAM に収めることができないワークロードの場合です。 以下を検討してください。
- I/O スループット: IOPS (1 秒あたりの入出力操作数) は、1 秒間にストレージ ディスクに送信される要求の数です。 Premium SSD v2 ディスクは、コンピューティング レベルがプッシュできる最高の達成可能な IOPS と帯域幅で構成されます。 読み取り/書き込み操作に十分なスループットを確保します。 クラスターで使用されている IOPS を監視するには、"Max" 集計で "IOPS" メトリックを使用します。
- 潜在： 待機時間は、アプリケーションが 1 つの要求を受信し、それをストレージ ディスクに送信し、クライアントに応答を送信するのにかかる時間です。 待機時間は、IOPS とスループットに加えて、アプリケーションのパフォーマンスの重要な尺度です。 使用されるストレージの種類とストレージ構成は、主に待機時間を定義します。 Azure DocumentDB などのマネージド サービスでは、Premium SSD ディスクなどの高速ストレージが、待機時間を短縮するために最適化された設定で使用されます。
- ディスクのパフォーマンスはデータベース操作に影響します。特に、 ワーキング セット を RAM に収めることができないワークロードの場合です。 以下を検討してください。
将来の成長とスケーラビリティ:
- 将来のデータの成長とスケーラビリティのニーズを計画します。
- 頻繁にストレージを拡張することなく、増加に対応するために、現在のニーズを超えてディスク領域を割り当てます。
計算例:
- 最初のデータ サイズが 500 GiB であるとします。
- インデックスでは、700 GiB に増加する可能性があります。
- 2 年後にデータを 2 倍にする場合は、1.4 TiB (700 GiB * 2) を計画します。
- オーバーヘッド、増加、運用のニーズに合わせてバッファーを追加します。
- 今日は 1 TiB ストレージから始めて、サイズが 800 GiB を超えると 2 TiB にスケールアップできます。
ストレージ サイズの決定には、現在と将来のデータニーズの見積もり、インデックス作成と圧縮の検討、適切なパフォーマンスとスケーラビリティの確保の組み合わせが含まれます。 また、最適な MongoDB パフォーマンスを維持するには、実際の使用状況と増加傾向に基づく定期的な監視と調整も重要です。
バーストが可能なコンピューティングとは
バースト可能レベルは、小規模なデータベース ワークロードに合わせて調整されたインテリジェントなソリューションを提供します。 アイドル期間中の CPU パフォーマンスを最小限に抑えることで、これらのクラスターはリソース使用率を最適化します。 しかし、実際の輝きは、トラフィックやワークロードの需要の増加に応じて、完全な CPU 電力にシームレスにスケールアップできることにあります。 この適応性は、必要に応じて正確にピークパフォーマンスを提供しながら、大幅なコスト削減を実現します。
Azure DocumentDB のバースト可能なクラスター層は、サービスの初期価格ポイントを下げることで、ユーザーが Azure DocumentDB を割引価格でオンボードし、探索しやすくすることを目指しています。 このアクセスの民主化により、あらゆる規模の企業が、銀行を壊すことなくAzure DocumentDB の力を活用できます。 スタートアップ、中小企業、企業のいずれであっても、このレベルはコスト効率の高いスケーラビリティのための新しい可能性を開きます。
バースト可能レベルのプロビジョニングは、通常のレベルをプロビジョニングするのと同じくらい簡単です。クラスター層オプションでは 、"M10"、"M20"、または "M25" のみを選択する必要があります。 ここでは、Azure DocumentDB クラスターを設定する方法の詳細な手順を示すクイック スタート ガイドを示します。