Azure Database for MySQL - フレキシブル サーバーのサービス レベル
適用対象:
Azure Database for MySQL - フレキシブル サーバー
Azure Database for MySQL - フレキシブル サーバー インスタンスは、バースト可能、General Purpose、Business Critical の 3 つの異なるサービス レベルのいずれかで作成できます。 サービス レベルは、B シリーズ、D シリーズ、E シリーズで使用される、基になる VM SKU によって区別されます。 選択したコンピューティング レベルおよびサイズで、サーバーで使用できるメモリと仮想コアが決まります。 同じストレージ テクノロジが、すべてのサービス レベルで使用されます。 すべてのリソースは、Azure Database for 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 | 最大接続数 | 一時ストレージ (SSD) GiB |
|---|---|---|---|---|---|
| バースト可能 | |||||
| Standard_B1s | 1 | 1 | 320 | 171 | 4 |
| Standard_B1ms | 1 | 2 | 640 | 341 | 4 |
| Standard_B2s | 2 | 4 | 1280 | 683 | 4 |
| Standard_B2ms | 2 | 8 | 1,700 | 1365 | 16 |
| Standard_B4ms | 4 | 16 | 2400 | 2731 | 32 |
| Standard_B8ms | 8 | 32 | 3100 | 5461 | 64 |
| Standard_B12ms | 12 | 48 | 3800 | 8193 | 96 |
| Standard_B16ms | 16 | 64 | 4300 | 10923 | 128 |
| Standard_B20ms | 20 | 80 | 5000 | 13653 | 160 |
| 汎用 | |||||
| Standard_D2ads_v5 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D2ds_v4 | 2 | 8 | 3200 | 1365 | 75 |
| Standard_D4ads_v5 | 4 | 16 | 6400 | 2731 | 150 |
| Standard_D4ds_v4 | 4 | 16 | 6400 | 2731 | 150 |
| Standard_D8ads_v5 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D8ds_v4 | 8 | 32 | 12800 | 5461 | 300 |
| Standard_D16ads_v5 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D16ds_v4 | 16 | 64 | 20000 | 10923 | 600 |
| Standard_D32ads_v5 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D32ds_v4 | 32 | 128 | 20000 | 21845 | 1200 |
| Standard_D48ads_v5 | 48 | 192 | 20000 | 32768 | 1800 |
| Standard_D48ds_v4 | 48 | 192 | 20000 | 32768 | 1800 |
| Standard_D64ads_v5 | 64 | 256 | 20000 | 43691 | 2400 |
| Standard_D64ds_v4 | 64 | 256 | 20000 | 43691 | 2400 |
| Business Critical | |||||
| Standard_E2ds_v4 | 2 | 16 | 5000 | 2731 | 75 |
| Standard_E2ads_v5 | 2 | 16 | 5000 | 2731 | 75 |
| Standard_E4ds_v4 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E4ads_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v4 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E8ads_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v4 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E16ads_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v4 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E20ads_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v4 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E32ads_v5 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E48ds_v4 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E48ads_v5 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E64ds_v4 | 64 | 504 | 64000 | 86016 | 2400 |
| Standard_E64ads_v5 | 64 | 504 | 64000 | 86016 | 2400 |
| Standard_E80ids_v4 | 80 | 504 | 72000 | 86016 | 2400 |
| Standard_E2ds_v5 | 2 | 16 | 5000 | 2731 | 75 |
| Standard_E4ds_v5 | 4 | 32 | 10000 | 5461 | 150 |
| Standard_E8ds_v5 | 8 | 64 | 18000 | 10923 | 300 |
| Standard_E16ds_v5 | 16 | 128 | 28000 | 21845 | 600 |
| Standard_E20ds_v5 | 20 | 160 | 28000 | 27306 | 750 |
| Standard_E32ds_v5 | 32 | 256 | 38000 | 43691 | 1200 |
| Standard_E48ds_v5 | 48 | 384 | 48000 | 65536 | 1800 |
| Standard_E64ds_v5 | 64 | 512 | 64000 | 87383 | 2400 |
| Standard_E96ds_v5 | 96 | 672 | 80000 | 100000 | 3600 |
使用可能なコンピューティング シリーズの詳細については、バースト可能 (B シリーズ)、汎用 Dadsv5-seriesDdsv4 シリーズ、およびビジネス クリティカルな Edsv4/Edsv5 シリーズ/Eadsv5 シリーズの Azure VM ドキュメントを参照してください。
Note
バースト可能 (B シリーズ) コンピューティング レベルでは、VM が開始/停止または再起動すると、クレジットが失われる可能性があります。 詳細については、バースト可能 (B シリーズ) の FAQ に関する記事を参照してください。
バースト可能なシリーズ インスタンスのパフォーマンス制限
バースト可能コンピューティング レベルは、継続的な完全な CPU を継続的に必要としないワークロードにコスト効率の高いソリューションを提供するように設計されています。 このレベルは、開発、ステージング、テスト環境など、非運用環境のワークロードに最適です。 バースト可能コンピューティング レベルに固有の機能は、"バースト" する機能、つまり、ワークロードが必要とするときに最大 100% の vCPU を使用してベースライン CPU パフォーマンスを超える利用ができることです。 これは、CPU クレジット モデルによって可能になります。これにより、B シリーズ インスタンスは CPU 使用率が低い期間中に "CPU クレジット" を蓄積できます。 CPU 使用率が高い期間にはこれらのクレジットを使用することで、インスタンスがベース CPU パフォーマンスを超えてバーストできるようになります。
ただし、バースト可能なインスタンスは、CPU クレジットを使い果たすとベース CPU パフォーマンスで動作することに注意することが重要です。 たとえば、Standard_B1ms のベース CPU パフォーマンスは 20%、つまり 0.2 仮想コアです。 バースト可能レベルのサーバーが、基本レベルを超えた CPU パフォーマンスを必要とするワークロードを実行していて、CPU クレジットを使い果たした場合、サーバーでパフォーマンスの制限が発生し、最終的にサーバーのさまざまなシステム操作 (停止/起動/再起動など) に影響する可能性があります。
Note
Standard_B1s/Standard_B1ms/Standard_B2s などの、バースト可能 (B シリーズ) コンピューティング レベルのサーバーの場合、ホスト メモリ サイズが比較的小さいため、memory_percent メトリックが 100% に達していない場合でも、継続的なワークロード下でクラッシュ (メモリ不足) が発生する可能性があります。
このスロットリングのために、サーバーで接続の問題が発生し、システム操作が影響を受ける可能性があります。 このような状況での対応方針として、クレジットを蓄積するために B シリーズのクレジット バンク モデルに従ってサーバーのワークロードを一時停止するか、サーバーを General Purpose レベルや Business Critical レベルなどの上位レベルにスケーリングすることの検討をお勧めします。
そのため、バースト可能コンピューティング レベルは特定の種類のワークロードに対しては大幅なコストと柔軟性のメリットを提供しますが、一貫した CPU パフォーマンスを必要とする運用ワークロードにはお勧めしません。 バースト可能レベルでは、読み取りレプリカと高可用性機能を作成する機能はサポートされていません。 このようなワークロードと機能については、General Purpose や Business Critical などコンピューティング レベルがより適切です。
Azure の B シリーズ CPU クレジット モデルの詳細については、「B シリーズのバースト可能なインスタンス」と「B シリーズの CPU クレジット モデル」を参照してください。
バースト可能レベルでの CPU クレジットの監視
バースト可能コンピューティング レベルで最適なパフォーマンスを維持するには、CPU クレジット残高の監視が不可欠です。 Azure Database for MySQL フレキシブル サーバーには、CPU クレジットに関連する 2 つの主要なメトリックが用意されています。 アラートのトリガーのための理想的なしきい値は、ワークロードとパフォーマンスの特定の要件によって異なります。
消費された CPU クレジット: このメトリックは、インスタンスによって消費された CPU クレジットの値を示します。 このメトリックを監視することは、インスタンスの CPU 使用率パターンを理解し、そのパフォーマンスを効果的に管理するのに役立ちます。
未使用の CPU クレジット: このメトリックは、インスタンスに残っている CPU クレジットの値を示します。 このメトリックを監視すると、CPU クレジットが使い果たされたためにインスタンスのパフォーマンスが低下することを防止できます。 未使用の CPU クレジット メトリックが特定のレベルを下回った場合 (たとえば、使用可能なクレジット合計の 30% 未満) は、現在の CPU 負荷が継続した場合にインスタンスが CPU クレジットを使い果たすリスクがあることを示します。
メトリックに関するアラートを設定する方法の詳細については、このガイドを参照してください。
記憶域
プロビジョニングするストレージは、フレキシブル サーバーで使用可能なストレージ容量です。 ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、および 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 に増加します。
自動スケールアップされたストレージは、スケールダウンできないことに注意してください。
Note
ストレージの自動拡張は、高可用性構成サーバーに対して既定で有効になっており、無効にすることはできません。
IOPS
Azure Database for MySQL フレキシブル サーバーでは、事前プロビジョニングされた IOPS と IOPS の自動スケーリングがサポートされます。 詳細情報。 最小 IOPS はすべてのコンピューティング サイズで 360 であり、最大 IOPS は選択したコンピューティング サイズによって決まります。 コンピューティング サイズごとの最大 IOPS の詳細については、こちらの表を参照してください。
重要
**最小 IOPS は、すべてのコンピューティング サイズで 360 です
**最大 IOPS は、選択したコンピューティング サイズによって決まります。
Azure portal (Azure Monitor を含む) での自分の I/O 使用量は、IO の割合メトリクスを使用して監視できます。 コンピューティングに基づく最大 IOPS よりも多くの IOPS が必要な場合は、サーバーのコンピューティングをスケーリングする必要があります。
事前プロビジョニングされた IOPS
Azure Database for MySQL フレキシブル サーバーには、事前プロビジョニングされた IOPS が用意されているため、Azure Database for MySQL フレキシブル サーバー インスタンスに特定の数の IOPS を割り当てることができます。 この設定により、ワークロードの一貫した予測可能なパフォーマンスが保証されます。 事前プロビジョニングされた IOPS を使用すると、ストレージ ボリュームの特定の IOPS 制限を定義できるため、1 秒あたりの一定数の要求を処理できるようになります。 これにより、信頼性が高く、確実なレベルのパフォーマンスが得られます。 事前プロビジョニングされた IOPS を使用すると、IOPS 制限を超える追加の 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 フレキシブル サーバーのお客様に最小限のコストで最高のパフォーマンスを提供できます。
動的スケーリング: 自動スケーリング IOPS は、ワークロードの実際の需要に基づいて、データベース サーバーの IOPS 制限を動的に調整します。 これにより、手動による介入や構成なしで最適なパフォーマンスが保証されます。
ワークロードの急増への対応: 自動スケーリング IOPS を使用すると、アプリケーションのパフォーマンスを損なうことなく、お使いのデータベースでワークロードの急増や変動をシームレスに処理できます。 この機能により、使用量がピークになる期間であっても、応答にばらつきがなくなります。
コスト削減: IOPS が事前プロビジョニングされる場合、固定の IOPS 制限が指定され、使用量に関係なく支払われるが、それとは異なり、自動スケーリング IOPS では、使用した I/O 操作の数だけ支払います。
バックアップ
サービスによって、サーバーのバックアップが自動的に取得されます。 1 ～ 35 日間の範囲で保持期間を選択できます。 バックアップの詳細については、バックアップと復元の概念に関する記事を参照してください。
リソースのスケール
サーバーを作成した後は、コンピューティング レベル、コンピューティング サイズ (仮想コアおよびメモリ)、ストレージ容量、およびバックアップの保持期間を個別に変更できます。 コンピューティング サイズは、スケールアップまたはスケールダウンすることができます。 バックアップの保持期間は、1 ～ 35 日間の範囲でスケールアップまたはスケールダウンできます。 ストレージ サイズは増やすことのみ可能です。 リソースのスケーリングは、ポータルまたは Azure CLI を使用して実行できます。
Note
ストレージ サイズは増やすことのみ可能です。 増加後に、より小さなストレージ サイズに戻すことはできません。
コンピューティング レベルまたはコンピューティング サイズを変更すると、サーバーが再起動され、新しいサーバーの種類が有効になります。 システムが新しいサーバーに切り替わるほんの短時間、新しい接続を確立できず、コミットされていないすべてのトランザクションがロールバックされます。 この時間の長さは変動しますが、ほとんどの場合は 60 ～ 120 秒です。
ストレージのスケーリングおよびバックアップの保持期間の変更は、オンライン操作であり、サーバーの再起動は不要です。
価格
最新の料金情報については、サービスの料金ページを参照してください。 必要な構成のコストについては、Azure portal で、選択したオプションに基づいて [コンピューティング + ストレージ] タブに表示される月額コストをご覧ください。 Azure サブスクリプションを取得していない場合は、Azure 料金計算ツールを使用して見積もり価格を確認できます。 Azure 料金計算ツールの Web サイトで [項目の追加] を選択し、 [データベース] カテゴリを展開します。 [Azure Database for MySQL] を選択し、デプロイの種類として [フレキシブル サーバー] を選択してオプションをカスタマイズします。
サーバーのコストを最適化する場合は、次のヒントを検討してください。
- コンピューティングの使用率が低すぎる場合は、コンピューティング レベルまたはコンピューティング サイズ (仮想コア) をスケールダウンします。
- ワークロードで、完全な計算能力が継続的には必要でない場合は、コンピューティング レベルを General Purpose および Business Critical から "バースト可能" に切り替えることを検討してください。
- 使用されていない場合は、サーバーを停止します。
- バックアップを長期間、保持する必要がない場合は、バックアップの保持期間を短縮します。
次のステップ
- ポータルで Azure Database for MySQL フレキシブル サーバー インスタンスを作成する方法をご確認ください。
- サービスの制限事項を確認します。