コンピューティング ユニットとストレージ ユニットの説明

この記事では、コンピューティング ユニットとストレージ ユニットの概念と、最大コンピューティング ユニットまたは最大ストレージ ユニットに達した場合に何が起こるかについて説明します。

コンピューティング ユニットとは

コンピューティング ユニットは、単一の Azure Database for MySQL サーバーで使用できることが保証される CPU 処理スループットの測定値で、 CPU とメモリ リソースを組み合わせた測定値です。 一般的に、50 コンピューティング ユニットの場合は 1/2 コア、100 コンピューティング ユニットは 1 コア、2000 コンピューティング ユニットでは 20 コアに相当する処理スループットがサーバーに対して保証されます。

コンピューティング ユニットあたりのメモリ量は、Basic、Standard、および Premium サービス レベル用に最適化されています。 パフォーマンス レベルを上げてコンピューティング ユニットを 2 倍にすると、その単一の Azure Database for MySQL が利用できるリソース セットを 2 倍にした場合と同じ効果が得られます

たとえば、Standard 2000 コンピューティング ユニットでは、100 コンピューティング ユニットで構成された Standard の 20 倍の CPU スループットとメモリが実現します。 ただし、Standard 100 コンピューティング ユニットの CPU スループットは、Basic 100 コンピューティング ユニットと同じですが、Standard レベルで事前構成されたメモリ量は、Basic レベルで構成されているメモリ量の 2 倍になるため、ワークロードのパフォーマンスが向上し、トランザクションの待ち時間が改善されます。

重要

ワークロード パフォーマンス スループットの予測と、優れたユーザー同時実行性を実現するために、Standard サービス レベルを選択することを強くお勧めします。

サービス レベルは、事実上アプリケーション ダウンタイムなしで、いつでも変更することができます。 単一の Azure Database for MySQL ごとに一対多のデータベースを作成し、オンデマンドでパフォーマンスを調整すると、ビジネスやアプリの多くでコストを柔軟に管理できるようになります。

重要

現在、サポートされているのは、サービス レベル内でのパフォーマンス レベルのスケールアップ/スケールダウンです。 たとえば、Standard の 100 コンピューティング ユニットから 400 コンピューティング ユニットにスケールアップできます。 同様に、Standard の 400 コンピューティング ユニットから 100 コンピューティング ユニットにスケールダウンできます。 サービス レベル間、たとえば Basic レベルと Standard レベルの間でのスケールアップ/スケールダウンは今後サポートされる予定です。

ストレージ ユニットとは

ストレージ ユニットは、単一の Azure Database for MySQL サーバーで使用できることが保証されるプロビジョニング済みストレージ容量の測定値です。 各サービス レベルのプロビジョニング済みストレージの容量は固定されていて、選択したサービス レベルの料金に含まれています。

次の表に示すように、ストレージ ユニットは、必要に応じて、コンピューティング ユニットとは別に許容される最大ストレージまで 125 GB 単位でスケールできます。

サービス レベルの機能 Basic Standard Premium\*
基本ストレージ ユニット 50 GB 125 GB 250 GB
最大合計ストレージ 1050 GB 10000 GB 4000 GB
ストレージ IOPS 保証 該当なし はい あり
最大ストレージ IOPS 該当なし 30,000 40,000

Standard サービス レベルと Premium サービス レベルも、プロビジョニング済み IOPS 保証を提供します。 使用可能なプロビジョニング済み IOPS は、サービス レベルおよび構成されているストレージ容量によって異なります。 Standard レベルでデプロイされたサーバーについては、IOPS は、プロビジョニング済みストレージの 3 倍に固定されています。

たとえば、プロビジョニング済みストレージ が 125 GB の場合、サーバーでは 375 プロビジョニング済み IOPS を使用できます。 Premium レベルでは非常に低待機時間の、高 IOPS ストレージが用意されています。 Premium レベルでデプロイされたサーバーの場合、低待機時間のプロビジョニング済み IOPS は、プロビジョニング済みストレージの 5 ~ 10 倍にスケールできます。

重要

構成済みコンピューティング ユニットがワークロードのボトルネックになっていると、使用可能なプロビジョニング済み IOPS を最大限に利用できないことがあります。 コンピューティング ユニットを監視し、使用可能なプロビジョニング済み IOPS を十分に活用できない場合は、コンピューティング ユニットのスケーリングを検討することをお勧めします。

プロビジョニング済みストレージをインクリメントしてストレージ ユニットをスケーリングすることは、Standard レベルと Premium レベルのプロビジョニング済み IOPS を比例的に増やすことと同じです。

重要

Basic レベルでは、IOPS 保証は提供されません。

ワークロードで必要とされるコンピューティング ユニットの数を判断する方法

既存のオンプレミスまたは仮想マシンで実行されている MySQL を移行する場合、コンピューティング ユニットの数を判断するには、ワークロードに必要な処理スループットのコア数を見積もります。

オンプレミスまたは仮想マシンが現在使用しているのが 4 コアの場合は (CPU のハイパースレッド数を除く)、まず Azure Database for MySQL 用に 400 コンピューティング ユニットを構成します。 コンピューティング ユニットのスケールアップとスケールダウンは、ワークロードのニーズに応じて動的に行うことができ、事実上、アプリケーションのダウンタイムは発生しません。 ポータルまたは CLI を使用してコンピューティング ユニットの使用量を監視して、MySQL サーバーのリソースを適切なサイズに調整することもできます。

ワークロードで必要とされるストレージ ユニットの数を判断する方法

必要なストレージ ユニットの数を見積もるには、まず、必要なストレージ容量を確認します。 Basic、Standard、および Premium レベルでは、SKU に組み込まれているストレージが付属しています。

次に重要なのは、必要な IOPS を判断することです。 Basic レベルは、可変 IOPS を保証なしで提供します。 Standard レベルは、プロビジョニング済みストレージに対する 3 つの IOPS/GB の固定比率でスケールされ、IOPS 保証をサポートします。 ポータルまたは CLI を使用してプロビジョニング済み IOPS の使用量を監視して、使用状況を判断することもできます。

重要

一度プロビジョニングされたストレージ ユニットを動的にスケールダウンすることはできません。

コンピューティング ユニット/ストレージ ユニットが最大数に達した場合に起こること

選択したサービス レベル/パフォーマンス レベルで許可されている最大限度までデータベース ワークロードを実行するため、必要なリソースを提供できるようにパフォーマンス レベルが調整、制御されます。

ワークロードがコンピューティング ユニット/プロビジョニング済み IOPS のいずれかの上限に達した場合、許可される最大レベルでリソースを引き続き受け取りますが、クエリの待ち時間が長くなる場合があります。 上限に達してもエラーにはなりませんが、ワークロードが遅くなり、遅延が深刻になった場合はクエリのタイムアウトが発生するようになります。

許可される最大接続数の制限に達した場合は、明示的なエラーが発生します。 リソース制限の詳細については、Azure Database for MySQL のリソース制限に関するページをご覧ください。

次のステップ

Azure Database for MySQL のサービス レベル