概要： - 以下の主要コンポーネントを備えたSAASソリューションがあります。 1.管理者がデータを編集できるWebポータルのバックエンドがあります。 2.モバイルデバイスから呼び出されるWeb APIがあります。モバイルデバイスは、進捗状況を読んでいる生徒を追跡または報告します。AzureはデータベースCPUの制限をあまりにも過ぎます
これまでのソリューションは仮想サーバーでホストされていました。 ここでは、ソリューションをAzureフレームワークに移行して、弾性データベースプールのスケーラビリティを利用できるようにします。 ポストを非同期的に処理できるときにモバイルデバイスから大量のポストを処理するためにイベントトピックを使用していますが、 がありますが、同期処理が必要なポストがいくつかあり、Azureのファブリックは複数同時接続。
問題の例： -
だから、Azureのは、次のようなクエリを実行します： -
SELECT q.Category, COUNT(*)
FROM Question q
JOIN Answer a
ON a.QuestionId = q.QuestionId
GROUP BY q.Category
ORDER BY q.Category
すべての次のシナリオで97％以上のSQLのCPUピーク： -
1. DTUは50であり、複数の同時呼び出しがあります。
2. DTUは1500で、同時コール数は5以上です。
3. DTUは4000で、同時コール数は20以上です。
Microsoftとのサポート呼び出しを開始しました。 SQLの統計情報とインデックスからWeb APIのプライシング層までを調査するのに1週間以上を費やしました。 上記のシナリオでは、CPUがSQLデータベースのピークを迎えているという証拠が残っています。
これは、必然的に「システムの大きなチャンクを書き直す」という議論につながります。
したがって、根本的な問題は、弾性データベースプールが標準SQLデータベースの能力の近くで実行できないように見えることです。 また、スタンドアロンデータベースのパフォーマンスは、仮想サーバーのパフォーマンスと競合していないようです。
パフォーマンスを維持し、スケーラビリティを追加する理由から、Elasticデータベースプールが推奨されたため、これは非常に不満です。 現在、1つの仮想サーバーで700以上の顧客を実行しています。顧客ごとに1つのシャード・データベースを作成する予定です。 これは、何百人もの顧客から数万人の顧客に拡大することができるという考えです。 現実には、Azureファブリックを仮想サーバー上のパフォーマンスに近い場所で実行するために戦っています。 この質問は、Azureが妥当なペースで重要ではない作業を実行する上で重要な経験を持つ人がいるかどうかを尋ねることです。 （システムの大きなチャンクを書き換える必要はありません）
ありませんか？あなたに質問してください。それをきれいにすると、閉じます。 – Paparazzi
単一のデータベース・インスタンスからプールに移行することは、常にリフト・アンド・シフトではありません。現在、データ依存型ルーティングをどのように処理しているかを考慮する必要があります。次に、データベース接続を接続の範囲（マスタとテナントの両方の接続）の両方で考慮する必要があります。 MSがあなたのアプリケーションの大きな断片を書き直すよう提案している場合、あなたは弾力的なスケールのために準備ができていないかもしれないいくつかの領域を見つけたかもしれません。質問を単位に分解したいのであれば、あるインスタンスから多くのインスタンスに移行する方法には満足しています。 –
ありがとう@ShannonLowder、私はあなたが正しいことを認識しています。 私はリファクタリングが必要ではないことを望んでいましたが、今は不可避だと私は受け入れました。 –