Azure Database for MySQL - フレキシブル サーバーのサービス レベル
Azure Database for MySQL - フレキシブル サーバー インスタンスは、バースト可能、General Purpose、Business Critical の 3 つのサービス レベルのいずれかで作成できます。 基になる VM SKU によって、B シリーズ、D シリーズ、E シリーズで使用されるサービス レベルが区別されます。 選択したコンピューティング レベルおよびサイズで、サーバーで使用できるメモリと仮想コアが決まります。 まったく同じストレージ テクノロジが、すべてのサービス レベルで使用されます。 すべてのリソースは、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 から 32 TiB |
| データベース バックアップのリテンション期間 | 1 ～ 35 日間 | 1 ～ 35 日間 | 1 ～ 35 日間 |
** 64.80 と 96 の仮想コアを除き、それぞれ 504 GiB、504 GiB、672 GiB のメモリを備えています。
* Ev5 コンピューティングは、QPS と待機時間に関し、他の VM シリーズの中で最も高いパフォーマンスを発揮します。 Ev5 コンピューティングのパフォーマンスと利用可能なリージョンの詳細については、こちらをご覧ください。
フレキシブル サーバーのサービス レベル
コンピューティング レベルを選択するには、最初に次の表を使用してください。
| コンピューティング レベル | 対象のワークロード |
|---|---|
| バースト可能 | 最大の CPU は常に必要ないワークロードに最適です。 |
| General Purpose | 負荷分散されたコンピューティングとメモリ、およびスケーラブルな I/O スループットを必要とする大部分のビジネス ワークロード。 たとえば、Web アプリやモバイル アプリ、その他のエンタープライズ アプリケーションをホストするためのサーバーが挙げられます。 |
| Business Critical | 高速トランザクション処理と高いコンカレンシーを実現するためのインメモリ パフォーマンスを必要とする、高パフォーマンス データベース ワークロード。 たとえば、リアルタイム データと高パフォーマンスなトランザクション アプリや分析アプリを処理するためのサーバーが挙げられます。 |
サーバーを作成した後に、コンピューティング レベル、コンピューティング サイズ、およびストレージ サイズを変更できます。 コンピューティングのスケーリングには再起動が必要で、60 秒から 120 秒かかりますが、ストレージのスケーリングに再起動は必要ありません。 また、他の調整とは関係なく、バックアップの保持期間の長さを調整することもできます。 詳細については、「リソースのスケール」セクションを参照してください。
サービス レベル、サイズ、サーバーの種類
コンピューティング リソースは、そのレベルとサイズに基づいて選択することができます。 これにより、仮想コアとメモリ サイズが決まります。 仮想コアは、基になるハードウェアの論理 CPU を表します。
バースト可能
バースト可能サービス レベルに使用可能なサーバーの種類の詳細な仕様は、次のとおりです。
| コンピューティング サイズ | 仮想コア | 物理メモリ サイズ (GiB) | 合計メモリ サイズ (GiB) | サポートされる最大 IOPS | 最大接続数 | 一時ストレージ (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4. | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1,700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
General Purpose
General Purpose サービス レベルに使用可能なサーバーの種類の詳細な仕様は、次のとおりです
| コンピューティング サイズ | 仮想コア | 物理メモリ サイズ (GiB) | 合計メモリ サイズ (GiB) | サポートされる最大 IOPS | 最大接続数 | 一時ストレージ (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Business Critical
Business Critical サービス レベルに使用可能なサーバーの種類の詳細な仕様は、次のとおりです。
| コンピューティング サイズ | 仮想コア | 物理メモリ サイズ (GiB) | 合計メモリ サイズ (GiB) | サポートされる最大 IOPS | 最大接続数 | 一時ストレージ (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ds_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Azure Database for MySQL – フレキシブル サーバーの Business Critical レベルの既定のゾーン回復性: 2024 年 12 月中旬以降、Azure Database for MySQL – フレキシブル サーバーの Business Critical レベルでプロビジョニングされたすべての新しいサーバーには、ゾーンの回復性が組み込まれています。追加料金は発生しません。 つまり、データ ファイルとログ ファイルはゾーン冗長ストレージに自動的に格納されるため、ゾーン障害からの迅速な復旧が保証されます。 高可用性が有効になっていない場合でも、ゾーン冗長バックアップによるシームレスな保護の恩恵を受けることができます。 Azure Database for MySQL フレキシブル サーバーでのビジネス継続性の概要。
Azure Database for MySQL フレキシブル サーバーでのメモリ管理
MySQL では、クエリ処理やキャッシュなど、さまざまな操作においてメモリが極めて重要な役割を果たします。 Azure Database for MySQL フレキシブル サーバーは、MySQL サーバー プロセス (mysqld) のメモリ割り当てを最適化し、効率的なクエリ処理、キャッシュ、クライアント接続管理、スレッド処理のための十分なメモリ リソースを確実に受け取ります。 MySQL でメモリがどのように使用されるかについて詳しく説明します。
物理メモリ サイズ (GB)
次の表の物理メモリ サイズ (GB) は、Azure Database for MySQL フレキシブル サーバーで使用可能なランダム アクセス メモリ (RAM) をギガバイト (GB) 単位で表しています。
合計メモリ サイズ (GiB)
Azure Database for MySQL フレキシブル サーバーでは、合計メモリ サイズ (GB) が提供されます。 これは、サーバーで使用できるメモリの合計を表し、物理メモリと一時記憶域 SSD コンポーネントのセット量の組み合わせです。 この統合ビューは、リソース管理を効率化するように設計されており、Azure MySQL Server (mysqld) プロセスで使用できるメモリの合計にのみ集中できます。 メモリの割合 (memory_percent) メトリックは、Azure MySQL サーバー プロセス (mysqld) によって占有されるメモリの割合を表します。 このメトリックは、合計メモリ サイズ (GB) から計算されます。 たとえば、Memory Percent メトリックの値が 60 と表示されている場合、Azure MySQL Server プロセスは、Azure Database for MySQL フレキシブル サーバーで使用可能な合計メモリ サイズ (GB) の 60% を使用していることを意味します。
MySQL Server (mysqld)
Azure MySQL サーバー プロセス mysqld は、コア データベース操作エンジンです。 起動時に、構成とワークロードの要求に基づいてメモリを利用して、InnoDB バッファー プールやスレッド キャッシュなどの合計コンポーネントを初期化します。 たとえば、InnoDB バッファー プールは、クエリの実行速度を向上させるために頻繁にアクセスされるデータとインデックスをキャッシュし、スレッド キャッシュはクライアント接続スレッドを管理します。 詳細情報。
InnoDB ストレージ エンジン
MySQL の既定のストレージ エンジンとして、InnoDB は、頻繁にアクセスされるデータをキャッシュし、innodb バッファー プールやログ バッファーなどの内部構造を管理するためにメモリを使用します。 InnoDB バッファー プール は、ディスク I/O を最小限に抑えるために、テーブル データとインデックスをメモリに保持し、パフォーマンスを向上させます。 InnoDB バッファー プール サイズ パラメーターは、サーバーで使用可能な物理メモリ サイズ (GB) に基づいて計算されます。 Azure Database for MySQL フレキシブル サーバーで使用できる InnoDB バッファー プールのサイズの詳細について説明します。
スレッド数
クライアント接続は、接続マネージャーによって処理される専用スレッドを介して管理されます。 これらのスレッドは、クライアント操作の認証、クエリ実行、および結果の取得を処理します。 詳細情報。
使用可能なコンピューティング シリーズの詳細については、負荷の急増に対応できる B シリーズ仮想マシンのサイズ、General Purpose Dadsv5 シリーズDdsv4 シリーズ、Business Critical Edsv4/Edsv5 シリーズ/Eadsv5 シリーズの Azure VM ドキュメントを参照してください。
バースト可能なシリーズ インスタンスのパフォーマンス制限
Note
負荷の急増に対応できる B シリーズ仮想マシンのサイズの場合、VM が起動/停止または再起動されると、クレジットが失われる可能性があります。 詳しくは、「負荷の急増に対応できる B シリーズ仮想マシンのサイズ」をご覧ください。
バースト可能コンピューティング レベルは、継続的な完全な 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 パフォーマンスを必要とする運用ワークロードにはお勧めしません。 バースト可能レベルでは、Azure Database for MySQL - フレキシブル サーバーでの読み取りレプリカと Azure Database for MySQL - フレキシブル サーバーでの高可用性の概念機能の作成はサポートされていません。 このようなワークロードと機能には、General Purpose や Business Critical などコンピューティング レベルがより適切です。
Azure の B シリーズ CPU クレジット モデルの詳細については、「負荷の急増に対応できる B シリーズ仮想マシンのサイズ」と「B シリーズの CPU クレジット モデル」を参照してください。
バースト可能レベルでの CPU クレジットの監視
バースト可能コンピューティング レベルで最適なパフォーマンスを維持するには、CPU クレジット残高の監視が不可欠です。 Azure Database for MySQL フレキシブル サーバーには、CPU クレジットに関連する 2 つの主要なメトリックが用意されています。 アラートのトリガーのための理想的なしきい値は、ワークロードとパフォーマンスの要件によって異なります。
Azure Database for MySQL - フレキシブル サーバーの監視: このメトリックは、インスタンスによって消費された CPU クレジットの数を示します。 このメトリックを監視することは、インスタンスの CPU 使用率パターンを理解し、そのパフォーマンスを効果的に管理するのに役立ちます。
Azure Database for MySQL - フレキシブル サーバーの監視: このメトリックは、インスタンス用に残っている CPU クレジットの数を示します。 このメトリックを監視すると、CPU クレジットが使い果たされたためにインスタンスのパフォーマンスが低下することを防止できます。 未使用の CPU クレジット メトリックが特定のレベルを下回った場合 (たとえば、使用可能なクレジット合計の 30% 未満) は、現在の CPU 負荷が継続した場合にインスタンスが CPU クレジットを使い果たすリスクがあることを示します。
メトリックに関するアラートを設定する方法の詳細については、このガイドを参照してください。
Storage
プロビジョニングするストレージは、フレキシブル サーバーで使用可能なストレージ容量です。 ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、および MySQL サーバー ログに使用されます。 バースト可能サービス レベルと General Purpose サービス レベルの場合、ストレージ範囲は最小 20 GiB から最大 16 TiB に及びます。 これに代わって、ストレージのサポートは、Business Critical サービス レベルで最大 32 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 の自動スケーリングがサポートされます。 Azure Database for MySQL - フレキシブル サーバーの Storage IOPS 最小 IOPS はすべてのコンピューティング サイズで 360 であり、最大 IOPS は選択したコンピューティング サイズによって決まります。 コンピューティング サイズごとの最大 IOPS の詳細については、こちらの表を参照してください。
重要
**最小 IOPS は、すべてのコンピューティング サイズで 360 です
**最大 IOPS は、選択したコンピューティング サイズによって決まります。
Azure Database for MySQL - フレキシブル サーバーのメトリックを使用して、Azure portal (Azure Monitor を使用) で I/O 消費量を監視できます。 コンピューティングに基づく最大 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 の自動スケーリングは、各サービス レベルとコンピューティング サイズの "サポートされている最大 IOPS" に自動でスケールアップします。 これにより、手動でスケーリングせずに最適なパフォーマンスが保証されます
この 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 から "バースト可能" に切り替えることを検討してください。
- 使用されていない場合は、サーバーを停止します。
- バックアップを長期間、保持する必要がない場合は、バックアップの保持期間を短縮します。