一定の期間の高トラフィックのバーストにより、スロットリング(429)が発生します。この問題を軽減するために、現在、AzureポータルでRUを増やし、後で減らしています。
メトリックに基づいてスケールアップ/スケールダウンしたいのですが、ドキュメントDBコンテナー用に作成された物理パーティションの数は表示されません。
とにかく負荷がパーティション全体に均等に分散されないため、私は物理パーティションレベルにはまったく移動しません。おそらく、パーティションの平均スループットは気にしないでしょうが、最悪の場合には対処する必要があります。
したがって、完全な自動スケールが必要な場合は、スロットルイベントの追跡(事後に発生)またはRUの総使用量の監視(パーティショニングマジック)に集中します。両方のパスが本当に複雑になり、真の自動スケールが得られる可能性があり、おそらくこれらの組み合わせが必要になります。アップスケーリングは達成可能であるように見えますが、その後、いつダウンするか、どのレベルまでトリッキーかを決定します。
予期せぬ事態を予想し、事態が発生する前に確実に対応することは困難です。より簡単なソリューションと比較して、シナリオでそれが価値があるかどうかを明確に検討してください。
さらに簡単な解決策は、平均ピーク負荷傾向に従って、準備されたスケジュール(つまり、平日+時刻)によってRU制限を設定することです。
これは、予期しないピークまたはフォールオフに対して自動スケーリングされず、予期しないものに調整するためにいくつかの監視が必要になりますが、とにかくそうですか?このような単純なソリューションがもたらすものは、最小限の労力で柔軟なスループット制限と平均的な日の予測可能なコストです。
必要なWRUの制限がいつでもわかったら、それを実行するのは簡単です。増加または減少またはRU制限をプログラムして、たとえば Azure関数 を実行できます。制限を実際に変更するC#の例は次のとおりです。
var offer = client.CreateOfferQuery()
.Where(r => r.ResourceLink == collection.SelfLink).Single();
offer = new OfferV2(offer, newthroughput);
client.ReplaceOfferAsync(offer);
Azure関数は定期的にティックし、構成したスケジュールまたは収集したイベントに応じて、それに応じてnewthroughput
を調整します。
実装するオートスケールソリューションが何であれ、いくら高くても構わない程度のハードリミットを適切に設定することを検討してください。そうしないと、事故や悪意のあるアクティビティ(DDOS)が発生した場合に、Azureから予期しない請求書を受け取る可能性があります。ある時点でスロットルを使用する方が良いでしょう。
https://github.com/giorgited/CosmosScale
このライブラリは、自動スケーリングを支援するために作成しました。私たちはAzure関数を使用して午前中にスケーリングを行い、夜間に縮小しましたが、効率が悪いことに気付きました。
上記のライブラリーは、ユーザーが提供した希望のRUの最大値までスケールアップし、非アクティブでない場合はスケールダウンします。一括操作は単一操作とは異なる方法で処理されます。ベンチマーク統計を含む完全な情報については、githubを参照してください。
免責事項:私はこのライブラリの作者です。
これに対する最新の回答があります(2019-11-19現在):「自動パイロット」機能(現在プレビュー版)は、スケールアップとスケールダウンを自動的に実行します。
これを書いている時点では、Azure PortalのCosmos DBアカウントの[プレビュー機能]ブレードにあります。プレビューから出ると、明らかに移動します。最新の手順はここにあります: https://docs.Microsoft.com/en-us/Azure/cosmos-db/provision-throughput-autopilot