Azure Cosmos DB でのストレージ コストを最適化する

  • [アーティクル]

適用対象: NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB では、無制限のストレージとスループットを提供します。 Azure Cosmos DB コンテナーまたはデータベース上でプロビジョニング/構成する必要のあるスループットとは異なり、ストレージは使用料に基づいて課金されます。 使用する論理ストレージに対してのみ課金され、ストレージを事前に予約する必要はありません。 ストレージは、Azure Cosmos DB コンテナーに対して追加または削除したデータに基づいて、自動的にスケール アップ/ダウンします。

Storage コスト

ストレージは GB 単位で課金されます。 ローカル SSD を使用したストレージは、データおよびインデックス作成で使用されます。 使用される合計ストレージは、Azure Cosmos DB を使用しているすべてのリージョンで使用される、データおよびインデックスに必要なストレージと等しくなります。 Azure Cosmos DB アカウントを 3 つのリージョン間でグローバルにレプリケートする場合は、それらの 3 つのリージョンでの合計ストレージ コストに対して支払います。 ストレージ要件を見積もるには、容量プランナー ツールを参照してください。 Azure Cosmos DB でのストレージのコストは $0.25 GB/月です。最新の更新情報については、価格設定ページを参照してください。 アラートを設定して、Azure Cosmos DB コンテナーによって使用されるストレージを判断したり、ストレージを監視するには、Azure Cosmos DB の監視 に関する記事を参照してください。

アイテムのサイズによってコストを最適化する

Azure Cosmos DB では、最適なパフォーマンスとコストの利点を得るために、アイテムのサイズが 2 MB 以下であることが想定されています。 2 MB を超えるデータを格納するアイテムが必要な場合は、アイテムのスキーマを再設計することを検討してください。 スキーマを再設計できないというまれなケースでは、アイテムをサブアイテムに分割し、それらを一般的な識別子 (ID) で論理的にリンクすることができます。 Azure Cosmos DB のすべての機能は、その論理識別子に固定することで一貫して動作します。

インデックス作成によってコストを最適化する

既定では、データに自動的にインデックスが付けられるので、使用される合計ストレージが増大する可能性があります。 ただし、このオーバーヘッドを低減するために、カスタムのインデックス ポリシーを適用できます。 ポリシーによって調整されていない自動インデックス作成は、アイテムのサイズの約 10 から 20% になります。 インデックス ポリシーを削除またはカスタマイズすることで、書き込みに対して追加のコストは発生せず、追加のスループット容量は必要ありません。 カスタムのインデックス作成ポリシーを構成するには、Azure Cosmos DB でのインデックス作成に関するページを参照してください。 前にリレーショナル データベースを使用したことがあれば、"すべてにインデックスを作成" するには、2 倍以上のストレージが必要だと思うかもしれません。 しかし、Azure Cosmos DB での平均的なケースでは、それよりもかなり小さくて済みます。 Azure Cosmos DB は、低ストレージ フットプリント用に設計されているので、自動インデックス作成の場合にも、インデックスのストレージ オーバーヘッドは一般的に低くなります (10 から 20%)。 インデックス作成ポリシーを管理することで、インデックス フットプリントとクエリ パフォーマンスのトレードオフを、よりきめ細かく制御できます。

有効時間および変更フィードによってコストを最適化する

データが不要になったら、有効期限 や 変更フィード を使用して Azure Cosmos DB アカウントから適切に削除するか、または Azure BLOB Storageや Azure データ ウェアハウスなどの別のデータ ストアに古いデータを移行することができます。 Azure Cosmos DB は、Time to Live (TTL) を使用して、一定の期間が経過したらアイテムをコンテナーから自動的に削除する機能を提供します。 既定では、コンテナー レベルで Time to Live を設定し、項目ごとに値をオーバーライドできます。 コンテナー レベルまたはアイテム レベルで TTL を設定すると、アイテムが最後に変更されてからその期間が経過した後で、Azure Cosmos DB によってそれらのアイテムが自動的に削除されます。 変更フィードを使用すると、Azure Cosmos DB 内の別のコンテナーまたは外部データ ストアにデータを移行できます。 移行ではダウン タイムは発生せず、移行が完了したら、ソース Azure Cosmos DB コンテナーを削除するために有効期限を削除する、または構成することができます。

リッチ メディア データ タイプによってコストを最適化する

ビデオやイメージなどのリッチ メディア タイプを格納する場合、Azure Cosmos DB にはさまざまなオプションがあります。 これらのリッチ メディア タイプを Azure Cosmos DB 項目として格納することも 1 つのオプションです。 アイテムあたり 2 MB の制限があり、データ アイテムを複数のサブアイテムにチェーニングすることにより、この制限を回避できます。 または、これらを Azure BLOB Storage に格納し、メタデータを使用して Azure Cosmos DB 項目から参照することもできます。 この方法にはさまざまな長所と短所があります。 1 つ目の方法では、通常の Azure Cosmos DB 項目に加えてリッチ メディア データ タイプに対して、待機時間、スループット SLA、ターンキー グローバル配信機能の観点から最高のパフォーマンスを実現します。 ただし、サポート価格は高くなります。 メディアを Azure BLOB Storage に格納することで、全体的なコストを削減できます。 待機時間が重要な場合は、Azure Cosmos DB 項目から参照されるリッチ メディア ファイルに対して Premium Storage を使用できます。 これは、低コストでエッジ サーバーのイメージを処理して geo 制限を回避するために、CDN とネイティブに統合されています。 このシナリオの短所としては、Azure Cosmos DB と Azure BLOB Storage の 2 つのサービスを処理する必要があるので、運用コストが増大する可能性があります。

使用されたストレージを確認する

Azure Cosmos DB コンテナーのストレージ使用量を確認するには、コンテナーに対して HEAD 要求または GET 要求を実行し、x-ms-request-quota ヘッダーと x-ms-request-usage ヘッダーを調べます。 または、.NET SDK を使用する場合、DocumentSizeQuota プロパティと DocumentSizeUsage プロパティを使用して、使用されたストレージを取得できます。

SDK の使用

// Measure the item size usage (which includes the index size)
ResourceResponse<DocumentCollection> collectionInfo = await client.ReadDocumentCollectionAsync(UriFactory.CreateDocumentCollectionUri("db", "coll"));   

Console.WriteLine("Item size quota: {0}, usage: {1}", collectionInfo.DocumentQuota, collectionInfo.DocumentUsage);

次のステップ

次は、先に進み、以下の各記事で Azure Cosmos DB でのコストの最適化の詳細について学習することができます。