Azure Database for MySQL - シングル サーバーのサービス レベル
適用対象:
Azure Database for MySQL - シングル サーバー
重要
Azure Database for MySQL の単一サーバーは提供終了パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、「Azure Database for MySQL 単一サーバーの動作」を参照してください 。
Azure Database for MySQL サーバーは、Basic、汎用、およびメモリ最適化の 3 つのサービス レベルのいずれかで作成できます。 サービス レベルは、プロビジョニングできる仮想コアでのコンピューティング量、仮想コアあたりのメモリ、データの格納に使用されるストレージ テクノロジによって区別されています。 リソースはすべて、MySQL サーバー レベルでプロビジョニングされます。 1 つのサーバーには 1 つ以上のデータベースを含めることができます。
| 属性 | Basic | 汎用 | メモリ最適化 |
|---|---|---|---|
| コンピューティング世代 | Gen 4、Gen 5 | Gen 4、Gen 5 | Gen 5 |
| 仮想コア | 1、2 | 2、4、8、16、32、64 | 2、4、8、16、32 |
| 仮想コアあたりのメモリ | 2 GB | 5 GB | 10 GB |
| ストレージ サイズ | 5 GB ～ 1 TB | 5 GB から 16 TB | 5 GB から 16 TB |
| データベース バックアップのリテンション期間 | 7 ～ 35 日間 | 7 ～ 35 日間 | 7 ～ 35 日間 |
価格レベルを選択する場合は、まず次の表を参考にしてください。
| サービス レベル | 対象のワークロード |
|---|---|
| Basic | 低負荷なコンピューティングと I/O パフォーマンスを必要とするワークロード。 たとえば、開発やテスト、使用頻度の低い小規模なアプリケーションに使用するサーバーがこれに該当します。 |
| General Purpose | 負荷分散されたコンピューティングとメモリ、およびスケーラブルな I/O スループットを必要とする大部分のビジネス ワークロード。 たとえば、Web アプリやモバイル アプリ、その他のエンタープライズ アプリケーションをホストするためのサーバーが挙げられます。 |
| メモリ最適化 | 高速トランザクション処理と高いコンカレンシーを実現するためのインメモリ パフォーマンスを必要とする、高パフォーマンス データベース ワークロード。 たとえば、リアルタイム データと高パフォーマンスなトランザクション アプリや分析アプリを処理するためのサーバーが挙げられます。 |
Note
Basic サービス レベル間の動的スケーリングは現在サポートされていません。 Basic レベルの SKU サーバーを General Purpose または Memory Optimized のレベルにスケールアップすることはできません。
General Purpose または Memory Optimized のサーバーを作成したら、仮想コア数、ハードウェアの世代、および価格レベルを数秒で増やしたり減らしたりして変更できます。 また、アプリケーションのダウンタイムなしでストレージ (増量のみ) とバックアップのリテンション期間 (増減) を個別に調整できます。 バックアップ ストレージの種類は、サーバーの作成後に変更することはできません。 詳細については、「リソースのスケール」セクションを参照してください。
コンピューティング世代と仮想コア
コンピューティング リソースは仮想コアとして提供されます。仮想コアは、基礎となるハードウェアの論理 CPU を表します。 中国東部 1、中国北部 1、US DoD 中部、および US DoD 東部では、Intel E5-2673 v3 (Haswell) 2.4 GHz プロセッサに基づいた Gen 4 の論理 CPU を利用します。 その他のすべてのリージョンでは、Intel E5-2673 v4 (Broadwell) 2.3 GHz プロセッサに基づいた Gen 5 の論理 CPU を利用します。
ストレージ
プロビジョニングするストレージは、使用している Azure Database for MySQL サーバーで使用可能なストレージ容量です。 ストレージは、データベース ファイル、一時ファイル、トランザクション ログ、および MySQL サーバー ログに使用されます。 プロビジョニングするストレージの合計容量によって、ご利用のサーバーで使用できる I/O 容量も決まります。
Azure Database for MySQL – 単一サーバーでは、サーバーに次のバックエンド ストレージがサポートされます。
| ストレージの種類 | 基本 | General Purpose v1 | General Purpose v2 |
|---|---|---|---|
| ストレージ サイズ | 5 GB ～ 1 TB | 5 GB ～ 4 TB | 5 GB から 16 TB |
| ストレージの増分サイズ | 1 GB | 1 GB | 1 GB |
| IOPS | 変数 | 3 IOPS/GB 最小 100 IOPS 最大 6000 IOPS |
3 IOPS/GB 最小 100 IOPS 最大 20,000 IOPS |
Note
Basic ストレージでは、IOPS 保証は提供されません。 General Purpose ストレージでは、プロビジョニングされたストレージ サイズにより 3:1 の比率で IOPS がスケーリングされます。
Basic ストレージ
Basic ストレージは、基本の価格レベルのサーバーをサポートするバックエンド ストレージです。 Basic ストレージは、プロビジョニングされた IOPS が保証されず、待機時間が変動するバックエンドで Azure 標準ストレージを使用します。 Basic レベルは、開発用または小規模で使用頻度の低いアプリケーションで、軽量のコンピューティング、低コスト、I/O パフォーマンスが求められるワークロードに最適です。
General Purpose ストレージ
General Purpose ストレージは、General Purpose および Memory Optimized レベルのサーバーをサポートするバックエンド ストレージです。 General Purpose ストレージでは、プロビジョニングされたストレージ サイズにより 3:1 の比率で IOPS がスケーリングされます。 次に示すように、General Purpose ストレージには 2 つの世代があります。
General Purpose ストレージ v1 (最大 4 TB をサポート)
General Purpose ストレージ v1 は、サーバーあたり最大 4 TB のストレージと 6000 IOPS をサポートできるレガシ ストレージ テクノロジに基づいています。 General Purpose ストレージ v1 は、ローカル キャッシュおよびバックアップ用に MySQL エンジンを実行している計算ノードのメモリを活用するように最適化されています。 General Purpose ストレージ v1 のバックアップ プロセスは、計算ノードのメモリ内にあるデータとログのファイルを読み取り、最大 35 日間のリテンション期間のターゲット バックアップ ストレージにコピーします。 その結果、バックアップ中のストレージのメモリと IO の使用量は比較的高くなります。
すべての Azure リージョンで General Purpose ストレージ v1 がサポートされます
General Purpose ストレージ v1 で General Purpose または Memory Optimized サーバーを使用する場合は、次の点を考慮することをお勧めします
- ストレージ キャッシュとバックアップ バッファー用に 10-30% の超過メモリを考慮したコンピューティング SKU 階層を計画する
- バックアップ IO のために、データベースのワークロードで必要とされるよりも 10% 高い IOPS をプロビジョニングする
- または、下記で説明する任意の Azure リージョンで基となるストレージ インフラストラクチャが利用可能な場合は、最大 16 TB のストレージがサポートされる General Purpose ストレージ v2 (後述) に移行してください。
General Purpose ストレージ v2 (最大 16 TB のストレージをサポート)
General Purpose ストレージ v2 は、最大 16 TB および 2 万 IOPS をサポートする最新のストレージ インフラストラクチャに基づいています。 インフラストラクチャを使用できる Azure リージョンのサブセットでは、新しくプロビジョニングされたすべてのサーバーが General Purpose ストレージ v2 に既定で配置されます。 General Purpose ストレージ v2 は、MySQL の計算ノードのメモリを消費しないため、General Purpose v1 ストレージと比較して、IO 待機時間が予測しやすくなります。 General Purpose v2 ストレージ サーバー上のバックアップはスナップショットベースで、追加の IO オーバーヘッドがありません。 General Purpose v2 ストレージでは、同じストレージおよび IOPS がプロビジョニングされている場合、MySQL のサーバー パフォーマンスは General Purpose ストレージ v1 に比べて高くなります。最大 16 TB のストレージをサポートする General Purpose ストレージでは、追加コストは発生しません。 16 TB のストレージへの移行については、Azure portal からサポート チケットを開いてください。
General Purpose ストレージ v2 は、次の Azure リージョンでサポートされています。
| リージョン | General Purpose ストレージ v2 の可用性 |
|---|---|
| オーストラリア東部 | ✔️ |
| オーストラリア東南部 | ✔️ |
| ブラジル南部 | ✔️ |
| カナダ中部 | ✔️ |
| カナダ東部 | ✔️ |
| 米国中部 | ✔️ |
| 米国東部 | ✔️ |
| 米国東部 2 | ✔️ |
| 東アジア | ✔️ |
| 東日本 | ✔️ |
| 西日本 | ✔️ |
| 韓国中部 | ✔️ |
| 韓国南部 | ✔️ |
| 北ヨーロッパ | ✔️ |
| 米国中北部 | ✔️ |
| 米国中南部 | ✔️ |
| 東南アジア | ✔️ |
| 英国南部 | ✔️ |
| 英国西部 | ✔️ |
| 米国中西部 | ✔️ |
| 米国西部 | ✔️ |
| 米国西部 2 | ✔️ |
| 西ヨーロッパ | ✔️ |
| インド中部 | ✔️ |
| フランス中部* | ✔️ |
| アラブ首長国連邦北部* | ✔️ |
| 南アフリカ北部* | ✔️ |
Note
*パブリック プレビューで Azure Database for MySQL に General Purpose ストレージ v2 があるリージョン
*これらの Azure リージョンでは、General Purpose Storage v1 と v2 の両方でサーバーを作成できます。 パブリック プレビューで General Purpose Storage v2 を使用して作成されたサーバーの場合、次の制限事項があります。
- geo 冗長バックアップはサポートされません
- レプリカ サーバーは、General Purpose ストレージ v2 をサポートするリージョンに存在する必要があります。
自分のサーバーがどの種類のストレージで実行されているかを特定する方法はありますか?
お使いのサーバーのストレージの種類を確認するには、[設定]>[コンピューティングとストレージ] ページに移動します
- サーバーが Basic SKU を使用してプロビジョニングされている場合、ストレージの種類は Basic ストレージです。
- サーバーが General Purpose またはメモリ最適化 SKU を使用してプロビジョニングされている場合、ストレージの種類は General Purpose ストレージです
- サーバーでプロビジョニングできる最大ストレージ容量が 4 TB までの場合、ストレージの種類は General Purpose ストレージ v1 です。
- サーバーでプロビジョニングできる最大ストレージ容量が 16 TB までの場合、ストレージの種類は General Purpose ストレージ v2 です。
General Purpose ストレージ v1 から General Purpose ストレージ v2 に移行できますか? できる場合、追加コストはどのようになりますか?
はい。基になるストレージ インフラストラクチャがソース サーバーの Azure リージョンで利用可能な場合は、General Purpose ストレージ v1 から v2 への移行がサポートされています。 移行と v2 のストレージは、追加コストなしで利用できます。
サーバーのプロビジョニング後にストレージ サイズを増やすことはできますか?
サーバーの作成中および作成後にさらにストレージ容量を追加でき、システムではワークロードのストレージ使用量に基づいて自動的にストレージを拡張することができます。
重要
ストレージはスケールアップのみ可能で、スケールダウンすることはできません。
IO 使用量の監視
ご自身の I/O 使用量を監視するには、Azure Portal または Azure CLI コマンドを使用します。 監視する関連メトリックは、ストレージの上限、ストレージの割合、ストレージの使用量、および IO の割合です。General Purpose ストレージ v1 を使用する MySQL サーバーの監視メトリックは、MySQL エンジンによって使用されるメモリと IO を報告しますが、ストレージ層のメモリと IO の使用量をキャプチャすることは、制限によりできません。
容量の上限に到達
プロビジョニングされたストレージが 100 GB 以下のサーバーでは、空きストレージが、プロビジョニングされたストレージ サイズの 5% 未満になると、読み取り専用とマークされます。 プロビジョニングされたストレージが 100 GB を超えるサーバーは、空きストレージが 5 GB 未満である場合、読み取り専用とマークされます。
たとえば、110 GB のストレージをプロビジョニングしていて、実際の使用量が 105 GB を超えた場合、サーバーは読み取り専用とマークされます。 または、5 GB のストレージをプロビジョニングしているときに、ストレージの空き容量が 256 MB 未満になった場合、サーバーは読み取り専用としてマークされます。
サービスがサーバーを読み取り専用にしようとしている間、すべての新しい書き込みトランザクション要求はブロックされ、既存のアクティブなトランザクションの実行は継続されます。 サーバーが読み取り専用に設定された場合、後続のすべての書き込み操作とトランザクションのコミットは失敗します。 読み取りクエリは、中断せずに作業を続行します。 プロビジョニングされたストレージを増やすと、サーバーはもう一度書き込みトランザクションを受け入れる準備ができます。
ストレージの自動拡張を有効にするか、サーバーのストレージがしきい値に近づいたときに通知するためのアラートを設定しておくことをお勧めします。そうすると、読み取り専用状態に入ることを防止できます。 詳細については、アラートの設定方法に関するドキュメントをご覧ください。
ストレージの自動拡張
ストレージの自動拡張により、サーバーのストレージが不足して読み取り専用になることを防ぎます。 ストレージの自動拡張が有効になっている場合は、ワークロードに影響を与えることなく、ストレージが自動的に拡張します。 プロビジョニングされたストレージが 100 GB 以下のサーバーでは、空きストレージが、プロビジョニングされたストレージの 10% を下回ると、プロビジョニングされるストレージ サイズが 5 GB 単位で増加します。 プロビジョニングされたストレージが 100 GB を超えるサーバーの場合、空きストレージ領域が、プロビジョニングされたストレージ サイズの 10 GB を下回ると、プロビジョニングされるストレージ サイズが 5% 単位で増加します。 上で指定されている最大ストレージの制限が適用されます。
たとえば、1000 GB のストレージをプロビジョニングしていて、実際の使用量が 990 GB を超えた場合、サーバーのストレージ サイズは 1050 GB に増加します。 あるいは、10 GB のストレージをプロビジョニングしている場合、ストレージ サイズは空きストレージが 1 GB 未満になると 15 GB に増加します。
ストレージはスケールアップのみ可能で、スケールダウンはできないことに注意してください。
バックアップ ストレージ
Azure Database for MySQL は、プロビジョニングされているサーバー ストレージの 100% までをバックアップ ストレージとして追加コストなしで提供します。 この量を超えて使用するバックアップ ストレージは、月ごとに GB 単位で請求されます。 たとえば、サーバーを 250 GB のストレージでプロビジョニングする場合は、サーバーのバックアップに 250 GB の追加のストレージを追加料金なしで利用できます。 250 GB を超えるバックアップのストレージについては、価格モデルに従って請求されます。 バックアップ ストレージの使用状況に影響を与える要素を理解し、バックアップ ストレージのコストを監視および制御するには、バックアップに関するドキュメントを参照してください。
リソースのスケール
サーバーの作成後に、仮想コア数、ハードウェアの世代、価格レベル (Basic への変更、および Basic からの変更を除く)、ストレージ量、およびバックアップのリテンション期間を個別に変更できます。 バックアップ ストレージの種類は、サーバーの作成後に変更することはできません。 仮想コアの数は増やしたり減らしたりできます。 バックアップのリテンション期間は、7 日から 35 日の間でスケールアップまたはスケールダウンできます。 ストレージ サイズは増やすことのみ可能です。 ポータルまたは Azure CLI を使用して、リソースのスケーリングを実行できます。 Azure CLI を使用したスケーリングの例については、「Azure CLI での Azure Database for MySQL サーバーの監視とスケーリング」を参照してください。
仮想コア数、ハードウェアの世代、または価格レベルを変更すると、新しいコンピューティング割り当てを使用して元のサーバーのコピーが作成されます。 新しいサーバーが実行されると、接続が新しいサーバーに切り替わります。 システムが新しいサーバーに切り替わるほんの短時間、新しい接続を確立できず、コミットされていないすべてのトランザクションがロールバックされます。 スケーリング中のこのダウンタイムは、約 60 ～ 120 秒に及ぶ可能性があります。 スケーリング中のダウンタイムはデータベースの回復時間に依存します。このため、スケーリング操作時にサーバーで処理されているトランザクション アクティビティの量が多い場合は、データベースがオンラインになるまで時間がかかる可能性があります。 再起動時間が長くならないように、サーバー上のトランザクションが少ない時間帯にスケーリング操作を実行することをお勧めします。
ストレージのスケーリングおよびバックアップのリテンション期間の変更は、本当の意味でのオンライン操作です。 ダウンタイムはなく、アプリケーションには影響しません。 IOPS はプロビジョニングされたストレージのサイズに合わせてスケーリングされるため、サーバーで使用できる IOPS を増やすには、ストレージをスケールアップします。
価格
最新の料金情報については、サービスの料金ページを参照してください。 必要な構成のコストについては、Azure Portal で、選択したオプションに基づいて表示される [価格レベル] タブの月額コストを確認します。 Azure サブスクリプションを取得していない場合は、Azure 料金計算ツールを使用して見積もり価格を確認できます。 Azure 料金計算ツールの Web サイトで [項目の追加] を選択し、 [データベース] カテゴリを展開し、 [Azure Database for MySQL] を選択してオプションをカスタマイズします。
次のステップ
- ポータルで MySQL サーバーを作成する方法を確認します。
- サービスの制限について確認します。
- 読み取りレプリカを使用してスケールアウトする方法を確認します。