Azure Database for MySQL - フレキシブル サーバー デプロイ モデル
適用対象:
Azure Database for MySQL - フレキシブル サーバー
MySQL コミュニティ エディションを搭載した Azure Database for MySQL は、次の 2 つのデプロイ モードで利用できます。
- Azure Database for MySQL フレキシブル サーバー
- Azure Database for MySQL 単一サーバー
この記事では、フレキシブル サーバー デプロイ モデルの概要を説明し、中核となる概念を紹介します。 ワークロードに適したデプロイ オプションを決定する方法については、「Azure で適切な MySQL サーバー オプションを選択する」をご覧ください。
概要
Azure Database for MySQL フレキシブル サーバーは、データベース管理機能と構成設定のきめ細かな制御と柔軟性を高めることを目的に設計された、運用環境対応のフル マネージド データベース サービスです。 フレキシブル サーバー アーキテクチャにより、ユーザーは単一の可用性ゾーン内および複数の可用性ゾーンにまたがる高可用性を選択できます。 また、フレキシブル サーバーでは、より優れたコスト最適化制御によって、サーバーを停止/起動する機能や、完全なコンピューティング容量を継続的には必要としないワークロードに最適な、バースト可能なコンピューティング層を実現できます。 Azure Database for MySQL フレキシブル サーバーでは、予約インスタンスもサポートされているため、コストを最大 63% 削減でき、予測可能なコンピューティング容量要件を持つ運用ワークロードに最適です。 サービスでは、MySQL 5.7 と 8.0 のコミュニティ バージョンがサポートされています。 このサービスは現時点で一般提供されており、さまざまな Azure リージョンで利用できます。
フレキシブル サーバー デプロイ オプションには、バースト可能、汎用、Business Critical の 3 つのコンピューティング レベルが用意されています。 各レベルには、データベース ワークロードをサポートする異なるコンピューティング容量とメモリ容量が用意されています。 バースト可能レベルで月あたり数ドル払い、最初のアプリを構築し、後から実際のソリューションのニーズに応じて、スケールを調整することができます。 動的なスケーラビリティにより、データベースは変化の激しいリソース要件に透過的に対処することができます。 必要なときに必要な分のリソースにのみ課金されます。 詳細については、コンピューティングとストレージに関するページを参照してください。
フレキシブル サーバーは、以下に適しています
- バックアップ、高可用性、セキュリティ、監視などの機能に対する、デプロイの容易性、スケーリングの簡略化、データベース管理オーバーヘッドの低減。
- 制御とカスタマイズに優れた、MySQL のコミュニティ バージョンを必要とするアプリケーション開発。
- 同じゾーン、ゾーン冗長による高可用性、管理されたメンテナンス期間が含まれている運用環境ワークロード。
- 開発エクスペリエンスの簡略化。
- エンタープライズ グレードのセキュリティ、コンプライアンス、プライバシー。
Azure Database for MySQL フレキシブル サーバーの最新情報については、Azure Database for MySQL フレキシブル サーバーの新機能に関する記事を参照してください。
12 か月間の無料プラン
Azure 無料アカウントを使用すると、Azure Database for MySQL フレキシブル サーバーを 12 か月間無料で使用でき、1 か月あたりの上限は次のとおりです。
- Burstable B1MS インスタンスを 750 時間。これは、データベース インスタンスを毎月十分に継続実行できるだけの時間です。
- 32 GB のストレージと 32 GB のバックアップ ストレージ。
このオファーを利用して、Azure Database for MySQL フレキシブル サーバーを使用するアプリケーションを開発し、デプロイできます。 Azure 無料アカウントを使用して、Azure Database for MySQL フレキシブル サーバーを無料で作成および使用する方法については、こちらのチュートリアルを参照してください。
可用性ゾーン内および可用性ゾーン間での高可用性
Azure Database for MySQL フレキシブル サーバーを使用すると、自動フェールオーバーによる高可用性を構成できます。 高可用性ソリューションは、障害によってコミットされたデータが失われることがないように、またアプリケーションの全体的な稼働時間が増加するように設計されています。 高可用性が構成されている場合、フレキシブル サーバーでは、スタンバイ レプリカが自動的にプロビジョニングされ、管理されます。 プライマリ レプリカとセカンダリ レプリカの両方について、プロビジョニングされたコンピューティングとストレージに対して請求されます。 高可用性アーキテクチャ モデルには、次の 2 つがあります。
- ゾーン冗長の高可用性 (HA): このオプションは、複数の可用性ゾーンにわたってインフラストラクチャの完全な分離と冗長性を実現する場合に適しています。 最高レベルの可用性が提供されますが、複数のゾーンにわたってアプリケーションの冗長性を構成する必要があります。 ゾーン冗長 HA は、可用性ゾーン内のインフラストラクチャ障害に対して最高レベルの可用性を実現する必要があり、可用性ゾーン全体の待機時間を許容できる場合に推奨されます。 ゾーン冗長 HA は、リージョンが複数の可用性ゾーンをサポートし、ゾーン冗長 Premium ファイルシェアが利用可能な場合に、利用できる Azure リージョンのサブセットです。
- 同一ゾーンの高可用性 (HA): このオプションは、プライマリとスタンバイの両方のサーバーが同じ可用性ゾーン内にあるため、ネットワーク待機時間が短いインフラストラクチャの冗長化に適しています。 ゾーン間でアプリケーションの冗長性を構成せずに高可用性を実現します。 単一の可用性ゾーン内で、ネットワーク待機時間が最も短い最高レベルの可用性を実現する必要がある場合は、同一ゾーン HA が推奨されます。 同一ゾーン HA は、Azure Database for MySQL フレキシブル サーバー インスタンスを作成できるすべての Azure リージョンで使用できます。
詳細については、高可用性の概念に関するページを参照してください。
マネージド メンテナンス期間によるパッチの自動適用
このサービスでは、基になるハードウェア、OS、およびデータベース エンジンの自動修正が実行されます。 パッチには、セキュリティとソフトウェアの更新プログラムが含まれています。 MySQL エンジンの場合、マイナー バージョンのアップグレードも、計画メンテナンス リリースの一部として含まれています。 ユーザーは、パッチ適用のスケジュールをシステム管理として構成することも、カスタム スケジュールを定義することもできます。 メンテナンス スケジュールの実行時にパッチが適用され、更新を完了するために、パッチの適用プロセスの一環としてサーバーの再起動が必要になる場合があります。 カスタム スケジュールを使用すると、ユーザーはパッチ適用のサイクルを予測可能にし、ビジネスへの影響が最小限のメンテナンス期間を選択できます。 一般に、サービスは、継続的インテグレーションとリリースの一環として、毎月のリリース スケジュールに従います。
詳細については、予定メンテナンスに関する記事を参照してください。
自動バックアップ
Azure Database for MySQL フレキシブル サーバー サービスにより、サーバーのバックアップが自動的に作成され、ユーザーが構成したローカル冗長または geo 冗長のストレージに保存されます。 バックアップを使用すると、サーバーを、バックアップのリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、リテンション期間を 1 日から 35 日までの範囲で構成できます。 すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。
詳細については、バックアップの概念に関する記事を参照してください。
ネットワーク分離
Azure Database for MySQL フレキシブル サーバーに接続するには、2 つのネットワーク オプションがあります。 プライベート アクセス (VNet 統合) オプションとパブリック アクセス (許可された IP アドレス) オプションです。
プライベート アクセス (VNet 統合) - Azure Database for MySQL フレキシブル サーバー インスタンスを Azure Virtual Network にデプロイできます。 Azure の仮想ネットワークでは、非公開の、セキュリティで保護されたネットワーク通信が提供されます。 仮想ネットワーク内のリソースでは、プライベート IP アドレスを通した通信が可能です。
次の機能が必要な場合は、仮想ネットワーク統合オプションを選択します。
- プライベート IP アドレスを使用して、同じ仮想ネットワーク内の Azure リソースから Azure Database for MySQL フレキシブル サーバー インスタンスに接続する。
- VPN または ExpressRoute を使用して Azure 以外のリソースから Azure Database for MySQL フレキシブル サーバーに接続する。
- パブリック エンドポイントがない。
パブリック アクセス (許可された IP アドレス) – パブリック エンドポイントを使用して Azure Database for MySQL フレキシブル サーバーをデプロイできます。 パブリック エンドポイントは、パブリックに解決できる DNS アドレスです。 "許可されている IP アドレス" という語句は、サーバーへのアクセス許可を付与することが選択された IP の範囲を意味します。 これらのアクセス許可は、ファイアウォール規則と呼ばれます。
詳細については、ネットワークの概念に関する記事をご覧ください。
数秒以内でのパフォーマンスの調整とスケール
Azure Database for MySQL フレキシブル サーバーは、バースト可能、汎用、Business Critical の 3 つのサービス レベルで使用できます。 バースト可能レベルは、完全なコンピューティング能力を継続的には必要としない低コストの開発およびコンカレンシーの低いワークロードに最適です。 汎用および Business Critical は、高いコンカレンシー、スケーリング、予測可能なパフォーマンスを必要とする運用ワークロードに適しています。 最初は月数ドルの小規模データベースでアプリを構築し、後から実際のソリューションのニーズに応じて、スケールをシームレスに調整することができます。 ストレージのスケーリングはオンラインであり、ストレージの自動拡張がサポートされています。 Azure Database for MySQL フレキシブル サーバーを使用すると、ストレージに関係なく、無償の IOPS 制限を超えて最大 80K IOPS まで追加の IOPS をプロビジョニングできます。 この機能を使用すると、ワークロードの要件に基づいてプロビジョニングされる IOPS の数をいつでも増減できます。 動的なスケーラビリティにより、データベースは変化の激しいリソース要件に透過的に対処することができます。 消費したリソースについてだけ支払います。
詳細については、コンピューティングとストレージの概念に関する記事を参照してください。
最大 10 個の読み取りレプリカを使用して、読み取りワークロードをスケールアウトする
MySQL は、インターネット規模の Web およびモバイル アプリケーションを実行するための一般的なデータベース エンジンの 1 つです。 多くのお客様は、オンライン教育サービス、ビデオ ストリーミング サービス、デジタル支払いソリューション、eコマース プラットフォーム、ゲーム サービス、ニュース ポータル、政府機関、医療機関の Web サイトなどにそれを使用しています。 これらのサービスは、Web またはモバイル アプリケーションでのトラフィックの増加に合わせて、サービスを提供し、スケーリングする必要があります。
アプリケーション側に関しては、通常、アプリケーションは Java または PHP で開発され、Azure 仮想マシン スケール セットや Azure App Services で実行されるように移行されたり、Azure Kubernetes Service (AKS) で実行するようにコンテナー化されたりします。 App Service、または AKS が基盤となるインフラストラクチャで仮想マシン スケール セットを使用すると、新しい VM が瞬時にプロビジョニングされ、アプリケーションのステートレス コンポーネントがレプリケートされて要求に対応するため、アプリケーションのスケーリングが簡略化されます。ただし、多くの場合、データベースは、集中的なステートフル コンポーネントとしてボトルネックになります。
読み取りレプリカ機能を使用すると、データを Azure Database for MySQL フレキシブル サーバー インスタンスから読み取り専用サーバーにレプリケートできます。 ソース サーバーから最大で 10 個のレプリカにレプリケートできます。 レプリカは、MySQL エンジンのネイティブなバイナリ ログ (binlog) ファイルの位置ベースのレプリケーション テクノロジを使用して、非同期で更新されます。 ProxySQL などのロード バランサー プロキシ ソリューションを使用して、アプリケーションのリファクタリング コストを発生させることなく、アプリケーションのワークロードを読み取りレプリカにシームレスにスケールアウトすることができます。
詳細については、読み取りレプリカの概念に関する記事を参照してください。
データイン レプリケーションを使用したハイブリッドまたはマルチクラウドのデータ同期をセットアップする
データイン レプリケーションを使用すると、外部の MySQL サーバーから Azure Database for MySQL フレキシブル サーバーにデータを同期できます。 外部サーバーとして、オンプレミス、仮想マシン内、Azure Database for MySQL Single Server、または他のクラウド プロバイダーによってホストされるデータベース サービスを使用できます。 データイン レプリケーションは、バイナリ ログ (binlog) ファイルの位置ベースに基づいています。 データイン レプリケーションの使用を検討する主なシナリオは次のとおりです。
- ハイブリッド データ同期
- マルチクラウド同期
- 最小限のダウンタイムでの Azure Database for MySQL フレキシブル サーバーへの移行
詳細については、データイン レプリケーションの概念に関する記事を参照してください。
サーバーを停止および開始してコストを最適化する
Azure Database for MySQL フレキシブル サーバー サービスを使用すると、サーバーをオンデマンドで停止および開始して、コストを最適化できます。 コンピューティング レベルの課金は、サーバーが停止すると直ちに停止されます。 この機能を使用すると、開発中やテスト中に加え、期限付きの予測可能な運用ワークロードに対して、大幅なコスト削減を実現できます。 サーバーは、すぐに再起動しない限り 30 日間は停止状態のままになります。
詳細については、サーバーの概念に関する記事を参照してください。
エンタープライズ グレードのセキュリティ、コンプライアンス、プライバシー
Azure Database for MySQL フレキシブル サーバーでは、保存データのストレージ暗号化に FIPS 140-2 認証済み暗号モジュールが使用されます。 データ (バックアップを含む) と、クエリの実行中に作成される一時ファイルは暗号化されます。 このサービスでは、Azure ストレージ暗号化に含まれる AES 256 ビット暗号が使用され、キーはシステムによって管理されます (既定)。
Azure Database for MySQL フレキシブル サーバーでは、既定で適用されるトランスポート層セキュリティを使用して、動作中のデータが暗号化されます。 Azure Database for MySQL フレキシブル サーバーでは、トランスポート層セキュリティ (TLS 1.2) を使用する暗号化された接続が既定でサポートされており、TLS 1.0 と TLS 1.1 を使用する受信接続はすべて拒否されます。 require_secure_transport サーバー パラメーターを設定すると、TSL/SSL 強制を無効にしてサーバーの最小 tls_version を設定できます。
詳細については、Azure Database for MySQL フレキシブル サーバー インスタンスへの暗号化された接続の使用方法に関する記事を参照してください。
Azure Database for MySQL フレキシブル サーバーを使用すると、Azure 仮想ネットワーク (仮想ネットワーク) 統合を使用してサーバーにフルプライベート アクセスできます。 Azure 仮想ネットワーク内のサーバーには、プライベート IP アドレスを介してのみアクセスおよび接続できます。 仮想ネットワーク統合を使用すると、パブリック アクセスが拒否され、パブリック エンドポイントを使用してサーバーに到達することはできません。
詳細については、ネットワークの概念に関する記事をご覧ください。
監視とアラート
Azure Database for MySQL フレキシブル サーバーには、組み込みのパフォーマンス監視機能とアラート機能が搭載されています。 すべての Azure メトリックは 1 分間隔で、各メトリックの 30 日間の履歴が保持されます。 メトリックにアラートを構成できます。 Azure Database for MySQL フレキシブル サーバーにより、リソース使用率を監視するためのホスト サーバー メトリックが公開され、低速クエリ ログを構成できます。 これらのツールを使用すると、ワークロードをすばやく最適化し、最適なパフォーマンスが得られるようにサーバーを構成することができます。 Azure Database for MySQL フレキシブル サーバーを使用すると、Azure Monitor ブックを使用して、低速クエリ ログと監査ログのデータを視覚化できます。 ブックを使用すると、データを分析し、Azure portal 内に豊富な視覚レポートを作成するための柔軟なキャンバスが得られます。 Azure Database for MySQL フレキシブル サーバーでは、3 つのブック テンプレート (Server Overview、Auditing、Query Performance Insights) を追加設定なしで使用できます。 Query Performance Insight ブックは、次のような情報を提供することで、データベースのパフォーマンスのトラブルシューティングに費やす時間を短縮できるように設計されています。
- 実行時間の長いクエリの上位 N 個とその傾向。
- クエリの詳細: クエリ テキストと、クエリ時間の最小、最大、平均、標準偏差を含む実行履歴を表示します。
- リソース使用率 (CPU、メモリ、ストレージ)。
さらに、コミュニティ監視ツール (Azure Database for MySQL フレキシブル サーバーでの Percona Monitoring and Management など) を使用でき、これらのツールと統合できます。
詳細については、監視の概念に関する記事を参照してください。
移行
Azure Database for MySQL フレキシブル サーバーでは、PostgreSQL のコミュニティ バージョンを実行します。 これにより、アプリケーションの完全な互換性が確保され、MySQL エンジン上で開発された既存のアプリケーションを Azure Database for MySQL フレキシブル サーバーに移行するために必要なリファクタリング コストが最小限に抑えられます。 Azure Database for MySQL フレキシブル サーバーへの移行は、次のオプションを使用して実行できます。
オフライン移行
- ソースと Azure の間のネットワーク帯域幅が適切な場合 (高速 ExpressRoute など) は、Azure Data Migration Service を使用します。 詳細については、「DMS を使用して MySQL を Azure Database for MySQL フレキシブル サーバーにオフラインで移行する - Azure Database Migration Service」の詳細な手順を参照してください
- mydumper/myloader を使用して圧縮設定を利用し、低速ネットワーク (パブリック インターネットなど) 経由で効率的にデータを移動します。 詳細については、「mydumper または myloader を使用して大規模なデータベースを Azure Database for MySQL フレキシブル サーバーに移行する」の詳細な手順を参照してください
オンラインの移行または最小限のダウンタイムの移行
初期シード処理では、mydumper/myloader の整合性バックアップ/復元でデータイン レプリケーションを使用します。 詳細については、最小限のダウンタイムでの Azure Database for MySQL シングル サーバーから Azure Database for MySQL フレキシブル サーバーへの移行に関するチュートリアルの記事の詳細な手順を参照してください。
5 つの簡単な手順で Azure Database for MySQL シングル サーバーから Azure Database for MySQL フレキシブル サーバーに移行するには、こちらのブログを参照してください。
詳細については、Azure Database for MySQL フレキシブル サーバーへの移行に適したツールの選択に関する記事を参照してください。
Azure Azure リージョン
Azure でワークロードを実行する利点の 1 つは、グローバルに展開できることです。 Azure Database for MySQL フレキシブル サーバーは、現在、次の Azure リージョンで利用できます。
| リージョン | 可用性 | 同一ゾーン HA | ゾーン冗長 HA | geo 冗長バックアップ |
|---|---|---|---|---|
| オーストラリア中部 | ✔️ | ✔️ | ❌ | ❌ |
| オーストラリア東部 | ✔️ | ✔️ | ✔️ | ✔️ |
| Australia Southeast | ✔️ | ✔️ | ❌ | ✔️ |
| ブラジル南部 | ✔️ | ✔️ | ✔️ | ✔️ |
| カナダ中部 | ✔️ | ✔️ | ✔️ | ✔️ |
| カナダ東部 | ✔️ | ✔️ | ❌ | ✔️ |
| インド中部 | ✔️ | ✔️ | ✔️ | ✔️ |
| 米国中部 | ✔️ | ✔️ | ❌ | ✔️ |
| 中国東部 2 | ✔️ | ✔️ | ❌ | ❌ |
| China East 3 | ✔️ | ✔️ | ❌ | ✔️ |
| 中国北部 2 | ✔️ | ✔️ | ❌ | ❌ |
| China North 3 | ✔️ | ✔️ | ✔️ | ✔️ |
| 東アジア (香港特別行政区) | ✔️ | ✔️ | ✔️ | ✔️ |
| 米国東部 | ✔️ | ✔️ | ✔️ | ✔️ |
| 米国東部 2 | ✔️ | ✔️ | ✔️ | ✔️ |
| フランス中部 | ✔️ | ✔️ | ✔️ | ✔️ |
| フランス南部 | ✔️ | ✔️ | ❌ | ✔️ |
| ドイツ中西部 | ✔️ | ✔️ | ✔️ | ✔️ |
| ドイツ北部 | ✔️ | ✔️ | ❌ | ✔️ |
| イスラエル中部 | ✔️ | ✔️ | ✔️ | ❌ |
| イタリア北部 | ✔️ | ✔️ | ✔️ | ❌ |
| 東日本 | ✔️ | ✔️ | ✔️ | ✔️ |
| 西日本 | ✔️ | ✔️ | ❌ | ✔️ |
| JIO インド西部 | ✔️ | ✔️ | ❌ | ❌ |
| 韓国中部 | ✔️ | ✔️ | ✔️ | ✔️ |
| 韓国南部 | ✔️ | ✔️ | ❌ | ✔️ |
| 米国中北部 | ✔️ | ✔️ | ❌ | ✔️ |
| 北ヨーロッパ | ✔️ | ✔️ | ✔️ | ✔️ |
| ノルウェー東部 | ✔️ | ✔️ | ✔️ | ❌ |
| ノルウェー西部 | ✔️ | ✔️ | ❌ | ❌ |
| ポーランド中部 | ✔️ | ✔️ | ❌ | ❌ |
| カタール中部 | ✔️ | ✔️ | ✔️ | ❌ |
| 南アフリカ北部 | ✔️ | ✔️ | ✔️ | ❌ |
| 南アフリカ西部 | ✔️ | ✔️ | ❌ | ❌ |
| 米国中南部 | ✔️ | ✔️ | ✔️ | ✔️ |
| インド南部 | ✔️ | ✔️ | ❌ | ✔️ |
| 東南アジア | ✔️ | ✔️ | ✔️ | ✔️ |
| スペイン中部 | ✔️ | ✔️ | ❌ | ✔️ |
| スウェーデン中部 | ✔️ | ✔️ | ✔️ | ❌ |
| スイス北部 | ✔️ | ✔️ | ✔️ | ✔️ |
| スイス西部 | ✔️ | ✔️ | ❌ | ✔️ |
| アラブ首長国連邦中部 | ✔️ | ✔️ | ❌ | ✔️ |
| アラブ首長国連邦北部 | ✔️ | ✔️ | ✔️ | ❌ |
| 英国南部 | ✔️ | ✔️ | ✔️ | ✔️ |
| 英国西部 | ✔️ | ✔️ | ❌ | ✔️ |
| USGov バージニア州 | ✔️ | ✔️ | ❌ | ✔️ |
| USGov アリゾナ | ✔️ | ✔️ | ❌ | ✔️ |
| USGov テキサス | ✔️ | ✔️ | ❌ | ✔️ |
| 米国中西部 | ✔️ | ✔️ | ❌ | ✔️ |
| 西ヨーロッパ | ✔️ | ✔️ | ✔️ | ✔️ |
| 米国西部 | ✔️ | ✔️ | ❌ | ✔️ |
| 米国西部 2 | ✔️ | ✔️ | ✔️ | ✔️ |
| 米国西部 3 | ✔️ | ✔️ | ✔️ | ✔️ |
Contacts
Azure Database for MySQL フレキシブル サーバーについてご不明な点やご提案がある場合は、Azure Database for MySQL フレキシブル サーバー チーム (@Ask Azure Database for MySQL flexible server) までメールをお送りください。 このメール アドレスはテクニカル サポートのエイリアスではありません。
さらに、適切な連絡先について次の点を考慮してください。
- Azure サポートに問い合わせる場合は、Azure portal からチケットを申請します。
- アカウントを使用して問題を修正するには、Azure Portal でサポート要求を提出します。
- フィードバックを提供したり、新しい機能を要求したりするには、
[ UserVoice](https://feedback.azure.com/forums/597976-azure-database-for-postgresql) でエントリを作成します。
次のステップ
ここで、Azure Database for MySQL フレキシブル サーバー デプロイ モードの概要を確認したので、以下のことを行う準備ができました。