Azure Database for MySQL の動作のしくみ

9 分

このユニットでは、Azure Database for MySQL のしくみについて、まずはアーキテクチャを説明します。また、サービスがワークロードのニーズに合わせて高可用性、バックアップ機能、スケーリングを実現する方法についても説明します。

Azure Database for MySQL のアーキテクチャ

次の図は、Azure Database for MySQL - フレキシブルサーバーのインスタンスのアーキテクチャを示しています。

MySQL インスタンスは、Azure VM 上で実行されます。
データおよびログは、Azure Premium Storage に保存されます。
データは、バックアップと回復性のためにローカル冗長ストレージ全体で 3 回レプリケートされます。このサービスには、ゾーン冗長または geo 冗長ストレージバックアップを構成するためのオプションも用意されています。
さらに、MySQL フレキシブルサーバーに接続されたさまざまなクライアントアプリを同じ可用性ゾーン内に併置するオプションもあります。

さらに、同じゾーンまたはゾーン冗長の高可用性をオプトインして、スタンバイレプリカを自動的にプロビジョニングおよび維持することもできます。

高可用性のしくみ

Azure Database for MySQL - フレキシブルサーバーの場合、単一の可用性ゾーン内では、ホスティングサーバーに障害が発生すると、次の手順が実行されます。

Azure により、新しい仮想マシン (VM) がプロビジョニングされます。
新しくプロビジョニングされた VM に、Azure によってストレージファイルとデータファイルがマップされます。
MySQL データベースエンジンがオンラインになります。
クライアントアプリケーションが、新しい MySQL インスタンスに再接続します。

Note

複数のゾーンにわたって高可用性をプロビジョニングした場合、ホットスタンバイサーバーは同じ Azure リージョン内の別の可用性ゾーンに保持されます。このサーバーは、プライマリサーバーの完全に同期されたレプリカです。プライマリサーバーで障害が発生した場合、ホットスタンバイサーバーが中断を最小限に抑えて迅速に引き継ぐことで、サービスの可用性を維持できます。

バックアップのしくみ

バックアップを使用して、保持期間 (プレビュー段階では、35 日間または長期保有の場合は最長 10 年間) 内の任意の時点にサーバーを復元できます。

スケーリングのしくみ

Azure Database for MySQL のスケーリングでは、アプリケーションのニーズに応じてコンピューティングリソースを調整する必要があり、これは、ユーザーの需要や処理される操作の複雑さ、ビジネスの成長などの他の要因に基づいて変動する可能性があります。この柔軟性は、最適なパフォーマンスとコスト効率を維持するために不可欠です。

スケールのタイプ

垂直スケーリング (スケールアップ/スケールダウン)
- コンピューティングのスケーリング:これは、MySQL フレキシブルサーバーのコンピューティングレベルの変更を指します。 Azure にはコンピューティングレベルがいくつか用意されており、それぞれ異なる種類のワークロードに対応するように設計されています。
  - バースト可能:CPU 使用率が断続的に急増するが、連続した完全な CPU パフォーマンスを必要としない環境に適しています。
  - General Purpose: 幅広いアプリケーション向けに設計され、コンピューティング、メモリ、I/O リソースのバランスを提供します。
  - Business Critical: より強力な CPU と高速な I/O を備え、高トランザクション、低遅延のワークロードに適した、データベースに最高のパフォーマンスを提供します。
- メモリと CPU 割り当て:選択したレベルに応じて、データベースで使用可能な仮想コアの数と RAM の量をスケーリングできます。これは、より大規模または複雑なクエリを処理する能力に直接影響し、より多くの同時接続を処理できるようになります。
水平方向のスケーリング
- Azure Database for MySQL では、読み取りレプリカを追加して複数のサーバーに読み取りトラフィックを分散することで水平方向にスケーリングでき、プライマリサーバーを書き込み可能な状態に保ちながら読み取りパフォーマンスを向上させることができます。水平スケーリングにより、データベースはより多くのクエリ負荷を処理できるようになり、アプリケーションの応答性が向上します。
ストレージのスケーリング
- 動的ストレージのスケーリング:Azure Database for MySQL を使用すると、ダウンタイムなしでストレージ容量を増やすことができます。小さな割り当てから始め、データの増加に合わせてスケールアップできます。
- 自動拡張機能:この機能は、容量制限に達する前にストレージサイズを自動的に増やし、ストレージの制約に関連する中断を防ぎます。

IOPS の自動スケーリング

自動スケーリング IOPS (1 秒あたりの入出力操作数) は、現在のワークロードに基づいて I/O スループットを動的に調整する機能です。これは、データベースが負荷の急激な増加に手動操作なしで対応できることを保証するため、予測不能またはスパイクが発生しやすいワークロードパターンに特に役立ちます。

負荷に基づく IOPS スケーリング:ワークロードが増加し、より多くの I/O スループットが必要な場合、自動スケール機能によって、選択したコンピューティングレベルで許可される最大 IOPS の上限が自動的に増加します。逆に、アクティビティが少ない期間中は IOPS が削減され、コストが最小限に抑えられます。
優れた費用対効果:実際の使用量に基づいて IOPS を自動的に調整することで、散発的に発生する可能性があるピーク負荷を処理するためにリソースを過剰にプロビジョニングするのではなく、使用した IOPS に対してのみ料金を支払います。

スケーリングに関するベストプラクティス

Azure Database for MySQL を効果的にスケーリングするには、Azure Monitor を使用してパフォーマンスメトリックを監視し、重要なアラートを設定し、使用パターンを確認して将来の成長を計画し、ピーク外の時間帯にスケーラビリティをテストして、負荷が増加してもスムーズなパフォーマンスを確保します。

これらのスケーリングメカニズムを理解して使用することで、Azure Database for MySQL フレキシブルサーバーが常に効率的に実行され、ビジネスの現在と将来の両方のニーズに適応できるようになります。

エンジンの動作を構成して調整する

Azure Database for MySQL でサーバー変数とパラメーターを簡単に構成およびカスタマイズするには、Azure portal、Azure CLI、または REST API を使用して、クエリキャッシュサイズ、接続タイムアウト、ストレージエンジンの基本設定などの設定を調整し、特定のワークロードに最適なパフォーマンスと動作を確保できます。

次に、Azure Database for MySQL が、組織、そのアプリ、データベースのワークロードのニーズを満たしているかどうかを検討します。