Azure Databricks におけるキャパシティ制約は製品の問題ではなく、Azure の基盤となる VM の可用性に起因します。クラスターが作成またはスケールされる際、Azure から動的に VM がプロビジョニングされます。特定の VM SKU が地域的に不足している場合、クラスターの操作が停止する可能性があります。最も効率的な解決策は、Microsoft のアカウントチームに連絡し、Azure のキャパシティインテークプロセスを開始してもらうことです。連絡する前に、サブスクリプション ID、希望するリージョン、VM ファミリと SKU、コア数、ワークロードの特性、およびタイムラインなどの詳細情報を準備することが重要です。キャパシティの理解には、Azure インフラストラクチャ、Azure Databricks プラットフォーム、および Spark の実行自体の 3 つのレイヤーが含まれます。レイヤー 1 の Azure インフラストラクチャは、VM SKU の可用性、地域的な供給、およびサブスクリプションの vCPU クォータによって管理されます。レイヤー 2 の Azure Databricks プラットフォームには、ジョブ、タスク、およびウェアハウスの独自の定義済みリソース制限があります。レイヤー 3 の Spark の実行には、並列処理、メモリプレッシャー、および I/O の需要が関わります。キャパシティの問題は、クラスターが保留中になったり、自動スケーリングが失敗したりするなどの一貫性のない動作として現れることがよくあります。診断するには、クラスターの終了理由とイベントログを確認し、Azure アクティビティログと照合します。地域的なキャパシティ不足とクォータ制限を区別してください。クォータの問題は増加リクエストが必要ですが、キャパシティの問題は VM SKU の変更が必要になる場合があります。即時の制約に直面している場合は、オフピーク時に操作を再試行するか、別の VM SKU またはファミリに切り替えてください。CPU バウンドなタスクには F シリーズ、I/O 重いワークロードには L シリーズなどの代替 VM ファミリを検討してください。複数の Azure リージョンにワークスペースを展開することで、地域的な多様性を実装すると、キャパシティ制約に対する回復力が高まります。さらに、コンピューティングのスケーリングが常に解決策とは限りません。データスキューや過剰なシャッフルなどのワークロード設計の問題は、キャパシティの問題を模倣する可能性があります。リパーティショニング、キャッシング、およびクエリ設計による Spark の実行の最適化は、より効果的な場合が多いです。最後に、承認されたキャパシティを維持するために、非サーバーレスワークロードのインスタンスプールを構成して、コンピューティングをアクティブにデプロイしたままにします。