Azure Database for MySQL - フレキシブル サーバーのサービス レベル
適用対象:
Azure Database for MySQL - フレキシブル サーバー
Azure Database for MySQL フレキシブル サーバーは、Burstable、General Purpose、Business Critical の 3 つの異なるサービス レベルのいずれかで作成できます。 サービス レベルは、B シリーズ、D シリーズ、E シリーズで使用される、基になる VM SKU によって区別されます。 選択したコンピューティング レベルおよびサイズで、サーバーで使用できるメモリと仮想コアが決まります。 同じストレージ テクノロジが、すべてのサービス レベルで使用されます。 リソースはすべて、MySQL サーバー レベルでプロビジョニングされます。 1 つのサーバーには 1 つ以上のデータベースを含めることができます。
| リソース/レベル | バースト可能 | 汎用 | Business Critical |
|---|---|---|---|
| VM シリーズ | B シリーズ | Dadsv5-seriesDdsv4-series | Edsv4/Edsv5-series*/Eadsv5-series |
| 仮想コア | 1、2、4、8、12、16、20 | 2、4、8、16、32、48、64 | 2、4、8、16、32、48、64、80、96 |
| 仮想コアあたりのメモリ | 変数 | 4 GiB | 8 GiB ** |
| ストレージ サイズ | 20 GiB から 16 TiB | 20 GiB から 16 TiB | 20 GiB から 16 TiB |
| データベース バックアップのリテンション期間 | 1 ～ 35 日間 | 1 ～ 35 日間 | 1 ～ 35 日間 |
** それぞれ 504、504、672 GiB のメモリがある 64、80、96 個の仮想コアを除く。
* Ev5 コンピューティングは、QPS と待ち時間に関して、他の VM シリーズの中で最高のパフォーマンスを提供します。 Ev5 コンピューティングのパフォーマンスと利用可能なリージョンの詳細については、こちらをご覧ください。
コンピューティング レベルを選択するには、最初に次の表を使用してください。
| コンピューティング レベル | 対象のワークロード |
|---|---|
| バースト可能 | 最大の CPU を継続的に必要とするわけではないワークロードに最適です。 |
| General Purpose | 負荷分散されたコンピューティングとメモリ、およびスケーラブルな I/O スループットを必要とする大部分のビジネス ワークロード。 たとえば、Web アプリやモバイル アプリ、その他のエンタープライズ アプリケーションをホストするためのサーバーが挙げられます。 |
| Business Critical | 高速トランザクション処理と高いコンカレンシーを実現するためのインメモリ パフォーマンスを必要とする、高パフォーマンス データベース ワークロード。 たとえば、リアルタイム データと高パフォーマンスなトランザクション アプリや分析アプリを処理するためのサーバーが挙げられます。 |
サーバーを作成した後に、コンピューティング レベル、コンピューティング サイズ、およびストレージ サイズを変更できます。 コンピューティングのスケーリングには再起動が必要で、これに 60 ～ 120 秒かかるのに対し、ストレージのスケーリングには再起動は不要です。 また、他の調整とは関係なく、バックアップの保持期間の長さを調整することもできます。 詳細については、「リソースのスケール」セクションを参照してください。
サービス レベル、サイズ、サーバーの種類
コンピューティング リソースは、そのレベルとサイズに基づいて選択することができます。 これにより、仮想コアとメモリ サイズが決まります。 仮想コアは、基になるハードウェアの論理 CPU を表します。
使用可能なサーバーの種類の詳細な仕様は次のとおりです。
| コンピューティング サイズ | 仮想コア | メモリ サイズ (GiB) | サポートされる最大 IOPS | 最大接続数 |
|---|---|---|---|---|
| バースト可能 | ||||
| Standard_B1s | 1 | 1 | 320 | 171 |
| Standard_B1ms | 1 | 2 | 640 | 341 |
| Standard_B2s | 2 | 4 | 1280 | 683 |
| Standard_B2ms | 2 | 8 | 1,700 | 1365 |
| Standard_B4ms | 4 | 16 | 2400 | 2731 |
| Standard_B8ms | 8 | 32 | 3100 | 5461 |
| Standard_B12ms | 12 | 48 | 3800 | 8193 |
| Standard_B16ms | 16 | 64 | 4300 | 10923 |
| Standard_B20ms | 20 | 80 | 5000 | 13653 |
| 汎用 | ||||
| Standard_D2ads_v5 | 2 | 8 | 3200 | 1365 |
| Standard_D2ds_v4 | 2 | 8 | 3200 | 1365 |
| Standard_D4ads_v5 | 4 | 16 | 6400 | 2731 |
| Standard_D4ds_v4 | 4 | 16 | 6400 | 2731 |
| Standard_D8ads_v5 | 8 | 32 | 12800 | 5461 |
| Standard_D8ds_v4 | 8 | 32 | 12800 | 5461 |
| Standard_D16ads_v5 | 16 | 64 | 20000 | 10923 |
| Standard_D16ds_v4 | 16 | 64 | 20000 | 10923 |
| Standard_D32ads_v5 | 32 | 128 | 20000 | 21845 |
| Standard_D32ds_v4 | 32 | 128 | 20000 | 21845 |
| Standard_D48ads_v5 | 48 | 192 | 20000 | 32768 |
| Standard_D48ds_v4 | 48 | 192 | 20000 | 32768 |
| Standard_D64ads_v5 | 64 | 256 | 20000 | 43691 |
| Standard_D64ds_v4 | 64 | 256 | 20000 | 43691 |
| Business Critical | ||||
| Standard_E2ds_v4 | 2 | 16 | 5000 | 2731 |
| Standard_E2ads_v5 | 2 | 16 | 5000 | 2731 |
| Standard_E4ds_v4 | 4 | 32 | 10000 | 5461 |
| Standard_E4ads_v5 | 4 | 32 | 10000 | 5461 |
| Standard_E8ds_v4 | 8 | 64 | 18000 | 10923 |
| Standard_E8ads_v5 | 8 | 64 | 18000 | 10923 |
| Standard_E16ds_v4 | 16 | 128 | 28000 | 21845 |
| Standard_E16ads_v5 | 16 | 128 | 28000 | 21845 |
| Standard_E32ds_v4 | 32 | 256 | 38000 | 43691 |
| Standard_E32ads_v5 | 32 | 256 | 38000 | 43691 |
| Standard_E48ds_v4 | 48 | 384 | 48000 | 65536 |
| Standard_E48ads_v5 | 48 | 384 | 48000 | 65536 |
| Standard_E64ds_v4 | 64 | 504 | 48000 | 86016 |
| Standard_E64ads_v5 | 64 | 504 | 48000 | 86016 |
| Standard_E80ids_v4 | 80 | 504 | 48000 | 86016 |
| Standard_E2ds_v5 | 2 | 16 | 5000 | 2731 |
| Standard_E4ds_v5 | 4 | 32 | 10000 | 5461 |
| Standard_E8ds_v5 | 8 | 64 | 18000 | 10923 |
| Standard_E16ds_v5 | 16 | 128 | 28000 | 21845 |
| Standard_E32ds_v5 | 32 | 256 | 38000 | 43691 |
| Standard_E48ds_v5 | 48 | 384 | 48000 | 65536 |
| Standard_E64ds_v5 | 64 | 512 | 48000 | 87383 |
| Standard_E96ds_v5 | 96 | 672 | 48000 | 100000 |
使用可能なコンピューティング シリーズの詳細については、バースト可能 (B シリーズ)、汎用 Dadsv5-seriesDdsv4 シリーズ、およびビジネス クリティカルな Edsv4/Edsv5 シリーズ/Eadsv5 シリーズの Azure VM ドキュメントを参照してください。
Note
バースト可能 (B シリーズ) コンピューティング レベルでは、VM が開始/停止または再起動すると、クレジットが失われる可能性があります。 詳細については、バースト可能 (B シリーズ) の FAQ に関する記事を参照してください。
ストレージ
プロビジョニングするストレージは、フレキシブル サーバーで使用可能なストレージ容量です。 ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、および MySQL サーバー ログに使用されます。 すべてのサービス レベルで、サポートされるストレージは、最小で 20 GiB、最大で 16 TiB です。 ストレージは 1 GiB 単位でスケーリングされ、サーバーの作成後にスケールアップすることができます。
Note
ストレージはスケールアップのみ可能で、スケールダウンすることはできません。
ストレージの上限、ストレージの割合、およびストレージで使用されるメトリックを使用して Azure portal、(Azure Monitor を含む) でストレージの使用量を監視できます。 メトリックの詳細については、 監視に関する記事 を参照してください。
容量の上限に到達
サーバーで使用されているストレージが、プロビジョニングされた制限に近づくと、サーバーが読み取り専用モードになって、サーバー上で失われた書き込みがすべて保護されます。 プロビジョニングされたストレージが 100 GiB 以下のサーバーでは、空きストレージが、プロビジョニングされたストレージ サイズの 5% 未満になると、読み取り専用とマークされます。 プロビジョニングされたストレージが 100 GiB を超えるサーバーは、空きストレージが 5 GiB 未満になると、読み取り専用とマークされます。
たとえば、110 GiB のストレージをプロビジョニングしている場合は、実際の使用量が 105 GiB を超えると、サーバーが読み取り専用とマークされます。 または、5 GiB のストレージをプロビジョニングしている場合は、ストレージの空き容量が 256 MB 未満になると、サーバーが読み取り専用としてマークされます。
サービスがサーバーを読み取り専用にしようとしている間、すべての新しい書き込みトランザクション要求はブロックされ、既存のアクティブなトランザクションの実行は継続されます。 サーバーが読み取り専用に設定された場合、後続のすべての書き込み操作とトランザクションのコミットは失敗します。 読み取りクエリは、中断せずに作業を続行します。
サーバーの読み取り専用モードを解除するには、サーバーで、プロビジョニングされたストレージを増やす必要があります。 これを行うには、Azure portal または Azure CLI を使用します。 プロビジョニングされたストレージを増やすと、サーバーは再び、書き込みトランザクションが可能な状態になります。
サーバーのストレージがしきい値に近づいたときに、それを通知するアラートを設定しておくことで、読み取り専用状態に入るのを防ぐことをお勧めします。 詳細については、アラートの設定方法に関するドキュメントを参照してください。
ストレージの自動拡張
ストレージの自動拡張により、サーバーのストレージが不足して読み取り専用になることを防ぎます。 ストレージの自動拡張が有効になっている場合は、ワークロードに影響を与えることなく、ストレージが自動的に拡張します。 すべての新しいサーバーの作成時に、ストレージの自動拡張は既定で有効になっています。 プロビジョニングされたストレージが 100 GB 以下のサーバーでは、空きストレージが、プロビジョニングされたストレージの 10% を下回ると、プロビジョニングされるストレージ サイズが 5 GB 単位で増加します。 プロビジョニングされたストレージが 100 GB を超えるサーバーの場合、空きストレージ領域が、プロビジョニングされたストレージ サイズの 10 GB を下回ると、プロビジョニングされるストレージ サイズが 5% 単位で増加します。 上で指定されている最大ストレージの制限が適用されます。 [コンピューティングとストレージ] ページの [設定] でプロビジョニングされた更新済みストレージを確認するには、サーバー インスタンスを最新の状態に更新します。
たとえば、1000 GB のストレージをプロビジョニングしていて、実際の使用量が 990 GB を超えた場合、サーバーのストレージ サイズは 1050 GB に増加します。 あるいは、20 GB のストレージをプロビジョニングしている場合、ストレージ サイズは空きストレージが 2 GB 未満になると 25 GB に増加します。
自動スケールアップされたストレージは、スケールダウンできないことに注意してください。
IOPS
Azure Database for MySQL – フレキシブル サーバーでは、追加の IOPS のプロビジョニングがサポートされます。 この機能を使用すると、無償の IOPS 制限を超えて追加の IOPS をプロビジョニングできます。 この機能を使用すると、ワークロードの要件に基づいてプロビジョニングされる IOPS の数をいつでも増減できます。
最小 IOPS はすべてのコンピューティング サイズで 360 であり、最大 IOPS は選択したコンピューティング サイズによって決まります。 コンピューティング サイズあたりの最大 IOPS の詳細については、[表](#compute-tiers-size-and-server-types) を参照してください。
最大 IOPS は、コンピューティング サイズごとの使用可能な最大 IOPS によって決まります。 B シリーズ、Ddsv4 シリーズ、および Edsv4 シリーズ/ Edsv5 シリーズのドキュメントで、列 "キャッシュが無効な場合の最大ディスク スループット:IOPS/MBps" を参照してください。
重要
無償の IOPS は、(コンピューティング サイズの "キャッシュが無効な場合の最大ディスク スループット: IOPS/MBps" と、300 + プロビジョニングされたストレージ (GiB 単位) * 3) の最小値と等しくなります
最小 IOPS は、すべてのコンピューティング サイズで 360 です
最大 IOPS は、選択したコンピューティング サイズによって決まります。
Azure portal (Azure Monitor を含む) での自分の I/O 使用量は、IO の割合メトリクスを使用して監視できます。 コンピューティングに基づく最大 IOPS よりも多くの IOPS が必要な場合は、サーバーのコンピューティングをスケーリングする必要があります。
IOPS の自動スケーリング
Azure Database for MySQL - フレキシブル サーバーは、レベル 1 のワークロードに対して最高のパフォーマンスを実現することを基本としており、ワークロードのニーズに応じてデータベース サーバーのパフォーマンス (IO) をシームレスに自動でスケールできるようにすることで改善することが可能です。 これは、ユーザーが 1 秒あたり一定量の IO を事前にプロビジョニングすることなく、オンデマンドで IOPS をスケーリングできるようにするオプトイン機能です。 この IOPS の自動スケーリング機能を使用すると、サーバーがワークロードのニーズに応じて IOP を自動的にスケールアップまたはスケールダウンするため、Azure Database for MySQL - フレキシブル サーバーでの IO 管理を安心して行うことができます。
この IOPS の自動スケーリングを使用すると、サーバーで使用された IO の分の料金だけを支払い、予備のリソースをプロビジョニングしてその分の料金を支払う必要がなくなるため、時間とコストの両方を節約できます。 加えて、ミッション クリティカルなレベル 1 アプリケーションでは、ワークロードでいつでも追加の IO を使用できるようにすることによって、一貫したパフォーマンスを実現できます。 IOPS の自動スケーリングを使用すると必要な管理が排除されるため、Azure Database for MySQL のお客様に最小限のコストで最高のパフォーマンスを提供できます。
バックアップ
サービスによって、サーバーのバックアップが自動的に取得されます。 1 ～ 35 日間の範囲で保持期間を選択できます。 バックアップの詳細については、バックアップと復元の概念に関する記事を参照してください。
リソースのスケール
サーバーを作成した後は、コンピューティング レベル、コンピューティング サイズ (仮想コアおよびメモリ)、ストレージ容量、およびバックアップの保持期間を個別に変更できます。 コンピューティング サイズは、スケールアップまたはスケールダウンすることができます。 バックアップの保持期間は、1 ～ 35 日間の範囲でスケールアップまたはスケールダウンできます。 ストレージ サイズは増やすことのみ可能です。 リソースのスケーリングは、ポータルまたは Azure CLI を使用して実行できます。
Note
ストレージ サイズは増やすことのみ可能です。 増加後に、より小さなストレージ サイズに戻すことはできません。
コンピューティング レベルまたはコンピューティング サイズを変更すると、サーバーが再起動され、新しいサーバーの種類が有効になります。 システムが新しいサーバーに切り替わるほんの短時間、新しい接続を確立できず、コミットされていないすべてのトランザクションがロールバックされます。 この時間の長さは変動しますが、ほとんどの場合は 60 ～ 120 秒です。
ストレージのスケーリングおよびバックアップの保持期間の変更は、オンライン操作であり、サーバーの再起動は不要です。
価格
最新の料金情報については、サービスの料金ページを参照してください。 必要な構成のコストについては、Azure portal で、選択したオプションに基づいて [コンピューティング + ストレージ] タブに表示される月額コストをご覧ください。 Azure サブスクリプションを取得していない場合は、Azure 料金計算ツールを使用して見積もり価格を確認できます。 Azure 料金計算ツールの Web サイトで [項目の追加] を選択し、 [データベース] カテゴリを展開します。 [Azure Database for MySQL] を選択し、デプロイの種類として [フレキシブル サーバー] を選択してオプションをカスタマイズします。
サーバーのコストを最適化する場合は、次のヒントを検討してください。
- コンピューティングの使用率が低すぎる場合は、コンピューティング レベルまたはコンピューティング サイズ (仮想コア) をスケールダウンします。
- ワークロードで、完全な計算能力が継続的には必要でない場合は、コンピューティング レベルを General Purpose および Business Critical から "バースト可能" に切り替えることを検討してください。
- 使用されていない場合は、サーバーを停止します。
- バックアップを長期間、保有する必要がない場合は、バックアップの保持期間を短縮します。
次のステップ
- ポータルで MySQL サーバーを作成する方法を確認します。
- サービスの制限事項を確認します。