Azure Database for MySQL - シングル サーバーのサービス レベル

適用対象: Azure Database for MySQL - 単一サーバー

Azure Database for MySQL サーバーは、Basic、汎用、およびメモリ最適化の 3 つのサービス レベルのいずれかで作成できます。 サービス レベルは、プロビジョニングできる仮想コアでのコンピューティング量、仮想コアあたりのメモリ、データの格納に使用されるストレージ テクノロジによって区別されています。 リソースはすべて、MySQL サーバー レベルでプロビジョニングされます。 1 つのサーバーには 1 つ以上のデータベースを含めることができます。

価格レベルを選択する場合は、まず次の表を参考にしてください。

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 – 単一サーバーでは、サーバーに次のバックエンド ストレージがサポートされます。

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 リージョンでサポートされています。

自分のサーバーがどの種類のストレージで実行されているかを特定する方法はありますか?

お使いのサーバーのストレージの種類を確認するには、[設定]>[コンピューティングとストレージ] ページに移動します

• サーバーが Basic SKU を使用してプロビジョニングされている場合、ストレージの種類は Basic ストレージです。
• サーバーが General Purpose または Memory Optimized 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 サーバーを作成する方法を確認します。
• サービスの制限について確認します。
• 読み取りレプリカを使用してスケールアウトする方法を確認します。