Azure DocumentDB には、クラスターを垂直方向と水平方向の両方にスケーリングする機能が用意されています。 コンピューティング クラスターレベルとストレージ ディスクは機能的には相互に依存しますが、コンピューティングとストレージのスケーラビリティとコストは切り離されます。
垂直スケーリング
垂直方向のスケーリングには、次の利点があります。
- アプリケーション チームは、データを論理的にシャーディングするための明確なパスを常に持っているとは限りません。 さらに、論理シャーディングはコレクションごとに定義されます。 複数のハードされていないコレクションを含むデータセットでは、データをパーティション分割するためのデータ モデリングがすぐに面倒になる可能性があります。 クラスターをスケールアップするだけで、アプリケーションの増大するストレージとコンピューティングのニーズを満たしながら、論理シャーディングの必要性を回避できます。
- 垂直方向のスケーリングでは、データの再調整は必要ありません。 物理シャードの数は変わらず、クラスターの容量のみが増加し、アプリケーションに影響はありません。
- スケールアップとスケールダウンは、サービスを中断せず、ダウンタイムがゼロの操作です。 アプリケーションの変更は必要なく、安定した状態の操作を継続できます。
- コンピューティング リソースは、アクティビティが少ない既知の時間枠の間にスケールダウンすることもできます。 もう一度スケール ダウンすると、少ない物理シャード間でデータを再調整する必要がなくなり、サービスを中断しなくてもダウンタイムがゼロになります。 ここでも、クラスターをスケールダウンした後にアプリケーションを変更する必要はありません。
- 最も重要なのは、コンピューティングとストレージを個別にスケーリングできることです。 より多くのコアとメモリが必要な場合は、ディスク サイズをそのままにしておき、クラスター層をスケールアップできます。 同様に、より多くのストレージと IOPS が必要な場合は、クラスター層をそのまま残して、ストレージ サイズを個別にスケールアップできます。 必要に応じて、コンピューティングとストレージの両方を個別にスケーリングして、コンポーネントの弾力性要件が他のコンポーネントに影響を与えることなく、各コンポーネントの要件を個別に最適化できます。
水平スケーリング
最終的に、アプリケーションは垂直方向にスケーリングするだけでは不十分な時点まで拡張されます。 ワークロードの要件は、最大のクラスター層の容量を超えて増加する可能性があり、最終的にはより多くのシャードが必要になります。 Azure DocumentDB での水平スケーリングには、次の利点があります。
- 論理的にシャード化されたデータセットでは、基になる物理シャード間でデータのバランスを取るためにユーザーの介入は必要ありません。 サービスは、論理シャードを物理シャードに自動的にマップします。 ノードが追加または削除されると、データはデータベースの内部で自動的に再調整されます。
- 要求は、クエリ対象のデータのハッシュ範囲を所有する関連する物理シャードに自動的にルーティングされます。
- Geo分散クラスターには、同種のマルチノードの構成があります。 したがって、論理的なシャードマッピングと物理シャードマッピングは、クラスターのプライマリリージョンとレプリカリージョン間で一貫しています。
コンピューティングとストレージのスケーリング
コンピューティング リソースとメモリ リソースは、 ディスク IOPS よりも Azure DocumentDB の読み取り操作に影響します。
- 読み取り操作では、まずコンピューティング レイヤー内のキャッシュを参照し、キャッシュからデータを取得できなかった場合はディスクにフォールバックします。 1 秒あたりの読み取り操作の速度が高いワークロードでは、クラスター層をスケールアップして CPU リソースとメモリ リソースを増やすと、スループットが向上します。
- 読み取りスループットに加えて、読み取り操作あたりのデータ量が多いワークロードでも、クラスターのコンピューティング リソースをスケーリングするメリットがあります。 たとえば、メモリが多いクラスター層では、ドキュメントあたりのペイロード サイズが大きくなり、応答あたりのドキュメント数が多くなります。
ディスク IOPS は、コンピューティング リソースの CPU とメモリ容量よりも Azure DocumentDB の書き込み操作に影響します。
- 書き込み操作では、常にデータがディスクに保持されます (読み取りを最適化するためにメモリにデータを保持することに加えて)。 IOPS が高いディスクが大きいほど、特に大規模に実行する場合に、書き込みスループットが高くなります。
- このサービスでは、シャードあたり最大 32 TB のディスクがサポートされ、シャードあたりの IOPS が増え、書き込み負荷の高いワークロード (特に大規模な場合) にメリットがあります。
ストレージの負荷の高いワークロードと大きなディスク
クラスター層あたりの最小ストレージ要件なし
前述のように、ストレージ リソースとコンピューティング リソースは、課金とプロビジョニングのために分離されます。 これらは凝集単位として機能しますが、個別にスケーリングできます。 M30 クラスター層には、32 TB のディスクをプロビジョニングできます。 同様に、M200 クラスター層では、ストレージとコンピューティングの両方のコストを最適化するために 32 GB のディスクをプロビジョニングできます。
大容量ディスク (32 TB 以上) を使用した TCO の削減
通常、NoSQL データベースでは、物理シャードあたりのストレージは 4 TB に制限されます。 Azure DocumentDB では、最大 8 倍の容量と 32 TB のディスクが提供されます。 ストレージの負荷の高いワークロードの場合、物理シャードあたり 4 TB のストレージ容量には、ワークロードのストレージ要件を維持するために大量のコンピューティング リソースが必要です。 コンピューティングはストレージよりもコストが高く、サービスの容量制限によりコンピューティングが過剰にプロビジョニングされると、コストが急速に膨らむ可能性があります。
200 TB のデータを含むストレージの負荷の高いワークロードについて考えてみましょう。
| シャードあたりのストレージ サイズ | 200 TB を維持するために必要な最小シャード数 |
|---|---|
| 4 TiB | 50 |
| 32テビバイト (TiB) | 7 |
コンピューティング要件の削減により、ディスクのサイズが大きくなると大幅に減少します。 ワークロードのスループット要件を維持するために必要な物理シャードの最小数を超える場合がある一方で、シャードの数を 2 倍または 3 倍にしても、ディスクが小さい 50 シャード クラスターよりもコスト効率が高くなります。
大きなディスクでの記憶域の階層化をスキップする
ストレージ負荷の高いシナリオでのコンピューティング コストに対する即時の対応は、データを "階層化" することです。 トランザクション データベース内のデータは、最も頻繁にアクセスされる "ホット" データに制限され、より大きな量の "コールド" データはコールド ストアにデタッチされます。 これにより、運用が複雑になります。 パフォーマンスも予測不可能であり、アクセスされるデータ層によって異なります。 さらに、システム全体の可用性は、ホット データ ストアとコールド データ ストアの両方を組み合わせた回復性に依存します。 サービス内の大規模なディスクでは、ストレージの負荷の高いワークロードのコストが最小限に抑えられるため、階層化ストレージは必要ありません。