Azure Database for MySQL - フレキシブル サーバー

適用対象: Azure Database for MySQL - フレキシブル サーバー

MySQL コミュニティ エディションを搭載した Azure Database for MySQL は、次の 2 つのデプロイ モードで利用できます。

  • フレキシブル サーバー
  • シングル サーバー

この記事では、フレキシブル サーバー デプロイ モデルの概要を示し、主要概念について概説します。 ワークロードに適したデプロイ オプションを決定する方法については、「Azure で適切な MySQL サーバー オプションを選択する」をご覧ください。

概要

Azure Database for MySQL フレキシブル サーバーは、データベース管理機能と構成設定のよりきめ細かな制御と柔軟性を提供するように設計された、運用環境対応のフル マネージド データベース サービスです。 フレキシブル サーバー アーキテクチャにより、ユーザーは単一の可用性ゾーン内および複数の可用性ゾーンにまたがる高可用性を選択できます。 また、フレキシブル サーバーでは、より優れたコスト最適化制御によって、サーバーを停止/起動する機能や、完全なコンピューティング容量を継続的には必要としないワークロードに最適な、バースト可能なコンピューティング層を実現できます。 フレキシブル サーバーでは、予約インスタンスもサポートされ、最大 63% のコストを削減でき、コンピューティング容量要件が予測できる運用環境ワークロードに最適です。 サービスでは、MySQL 5.7 と 8.0 のコミュニティ バージョンがサポートされています。 このサービスは現時点で一般提供されており、さまざまな Azure リージョンで利用できます。

フレキシブル サーバー デプロイ オプションには、Burstable、General Purpose、Business Critical という 3 つのコンピューティング レベルが用意されています。 各レベルには、データベース ワークロードをサポートする異なるコンピューティング容量とメモリ容量が用意されています。 バースト可能レベルで月あたり数ドル払い、最初のアプリを構築し、後から実際のソリューションのニーズに応じて、スケールを調整することができます。 動的なスケーラビリティにより、データベースは変化の激しいリソース要件に透過的に対処することができます。 必要なときに必要な分のリソースにのみ課金されます。 詳細については、コンピューティングとストレージに関するページを参照してください。

フレキシブル サーバーは、以下に適しています

  • バックアップ、高可用性、セキュリティ、監視などの機能の簡単なデプロイ、簡素化されたスケーリング、データベース管理の低いオーバーヘッド
  • 制御とカスタマイズに優れた、MySQL のコミュニティ バージョンを必要とするアプリケーション開発
  • 同じゾーン、ゾーン冗長による高可用性、管理されたメンテナンス期間のある運用環境ワークロード
  • シンプルな開発体験
  • エンタープライズ グレードのセキュリティ、コンプライアンス、プライバシー

フレキシブル サーバーの最新情報については、Azure Database for MySQL - フレキシブル サーバーの新機能に関するページを参照してください。

フレキシブル サーバーの概念図

12 か月間の無料プラン

Azure 無料アカウントを使用すると、フレキシブル サーバーを 12 か月無料で使用できます。1 か月あたりの上限は次のとおりです。

  • Burstable B1MS インスタンスを 750 時間。これは、データベース インスタンスを毎月十分に継続実行できるだけの時間です。
  • 32 GB のストレージと 32 GB のバックアップ ストレージ。

このプランを利用して、Azure Database for MySQL - フレキシブル サーバーを使用するアプリケーションを開発し、デプロイできます。 Azure 無料アカウントを使用して、フレキシブル サーバーを無料で作成および使用する方法について詳しくは、こちらのチュートリアルを参照してください。

可用性ゾーン内および可用性ゾーン間での高可用性

Azure Database for MySQL フレキシブル サーバーでは、自動フェールオーバーによる高可用性を構成できます。 高可用性ソリューションは、障害によってコミットされたデータが失われることがないように、またアプリケーションの全体的な稼働時間が増加するように設計されています。 高可用性が構成されている場合、フレキシブル サーバーでは、スタンバイ レプリカが自動的にプロビジョニングされ、管理されます。 プライマリ レプリカとセカンダリ レプリカの両方について、プロビジョニングされたコンピューティングとストレージに対して請求されます。 高可用性アーキテクチャ モデルには、次の 2 つがあります。

  • ゾーン冗長の高可用性 (HA): このオプションは、複数の可用性ゾーンにわたってインフラストラクチャの完全な分離と冗長性を実現する場合に適しています。 最高レベルの可用性が提供されますが、複数のゾーンにわたってアプリケーションの冗長性を構成する必要があります。 ゾーン冗長 HA は、可用性ゾーン内のインフラストラクチャ障害に対して最高レベルの可用性を実現する必要があり、可用性ゾーン全体の待機時間を許容できる場合に推奨されます。 ゾーン冗長 HA は、リージョンが複数の可用性ゾーンをサポートし、ゾーン冗長 Premium ファイルシェアが利用可能な場合に、利用できる Azure リージョンのサブセットです。

ゾーン冗長 HA

  • 同一ゾーンの高可用性 (HA): このオプションは、プライマリ サーバーとスタンバイ サーバーの両方が同じ可用性ゾーンに含まれ、ネットワーク待機時間が短いインフラストラクチャの冗長性に適しています。 ゾーン間でアプリケーションの冗長性を構成せずに高可用性を実現します。 単一の可用性ゾーン内で、ネットワーク待機時間が最も短い最高レベルの可用性を実現する必要がある場合は、同一ゾーン HA が推奨されます。 同一ゾーン HA は、Azure Database for MySQL フレキシブル サーバーを作成できるすべての  Azure リージョンで使用できます。

同じ冗長高可用性

詳細については、高可用性の概念に関するページを参照してください。

マネージド メンテナンス期間によるパッチの自動適用

このサービスでは、基になるハードウェア、OS、およびデータベース エンジンの自動修正が実行されます。 パッチには、セキュリティとソフトウェアの更新プログラムが含まれています。 MySQL エンジンの場合、マイナー バージョンのアップグレードも、計画メンテナンス リリースの一部として含まれています。 ユーザーは、パッチ適用のスケジュールをシステム管理として構成することも、カスタム スケジュールを定義することもできます。 メンテナンス スケジュールの間に、パッチが適用され、パッチ適用プロセスの一環として更新を完了するためにサーバーの再起動が必要になる場合があります。 カスタム スケジュールを使用すると、ユーザーはパッチ適用のサイクルを予測可能にし、ビジネスへの影響が最小限のメンテナンス期間を選択できます。 一般に、サービスは、継続的インテグレーションとリリースの一環として、毎月のリリース スケジュールに従います。

詳細については、予定メンテナンスに関するページを参照してください。

自動バックアップ

フレキシブル サーバー サービスにより、サーバーのバックアップが自動的に作成され、ユーザーが構成したローカル冗長または geo 冗長のストレージにそれが保存されます。 バックアップを使用すると、サーバーを、バックアップのリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、リテンション期間を 1 日から 35 日までの範囲で構成できます。 すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。

詳細については、バックアップの概念に関する記事を参照してください。

ネットワーク分離

Azure Database for MySQL フレキシブル サーバーに接続するには、2 つのネットワーク オプションがあります。 プライベート アクセス (VNet 統合) オプションとパブリック アクセス (許可された IP アドレス) オプションです。

  • プライベート アクセス (VNet 統合) – お使いの Azure Virtual Network 内にフレキシブル サーバーをデプロイできます。 Azure の仮想ネットワークでは、非公開の、セキュリティで保護されたネットワーク通信が提供されます。 仮想ネットワーク内のリソースでは、プライベート IP アドレスを通した通信が可能です。

    以下の機能が必要な場合は、VNet 統合オプションを選択します。

    • プライベート IP アドレスを使用して、同じ仮想ネットワーク内の Azure リソースからフレキシブル サーバーに接続する
    • VPN または ExpressRoute を使用して Azure 以外のリソースからフレキシブル サーバーに接続する
    • パブリック エンドポイントがない
  • パブリック アクセス (許可された IP アドレス) – パブリック エンドポイントを使用してフレキシブル サーバーをデプロイできます。 パブリック エンドポイントは、パブリックに解決できる DNS アドレスです。 "許可されている IP アドレス" という語句は、サーバーへのアクセス許可を付与することが選択された IP の範囲を意味します。 これらのアクセス許可は、ファイアウォール規則と呼ばれます。

詳細については、ネットワークの概念に関する記事を参照してください。

数秒以内でのパフォーマンスの調整とスケール

フレキシブル サーバー サービスは、次の 3 つの SKU レベルで使用できます: Burstable、General Purpose、Business Critical。 バースト可能レベルは、完全なコンピューティング能力を継続的には必要としない低コストの開発およびコンカレンシーの低いワークロードに最適です。 General Purpose および Business Critical は、高いコンカレンシー、スケール、予測可能なパフォーマンスを必要とする運用ワークロードに適しています。 最初は月数ドルの小規模データベースでアプリを構築し、後から実際のソリューションのニーズに応じて、スケールをシームレスに調整することができます。 ストレージのスケーリングはオンラインであり、ストレージの自動拡張がサポートされています。 フレキシブル サーバーを使用すると、ストレージに関係なく、無償の IOPS 制限を超えて最大 20 K 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) ファイルの位置ベースに基づいています。 データイン レプリケーションの使用を検討する主なシナリオは次のとおりです。

詳細については、データイン レプリケーションの概念に関する記事を参照してください。

サーバーを停止および開始してコストを最適化する

フレキシブル サーバー サービスを使用すると、サーバーをオンデマンドで停止および開始して、コストを最適化することができます。 コンピューティング層の課金は、サーバーが停止すると直ちに停止されます。 これにより、開発、テスト、期限付きの予測可能な運用ワークロードにおいて、大幅なコスト削減を実現できます。 サーバーは、すぐに再起動しない限り 30 日間は停止状態のままになります。

詳細については、サーバーの概念に関する記事を参照してください。

エンタープライズ グレードのセキュリティ、コンプライアンス、プライバシー

フレキシブル サーバー サービスでは、保存データのストレージ暗号化に FIPS 140-2 認証済みの暗号モジュールが使用されます。 データ (バックアップを含む) と、クエリの実行中に作成される一時ファイルは暗号化されます。 このサービスでは、Azure ストレージ暗号化に含まれる AES 256 ビット暗号が使用され、キーはシステムによって管理されます (既定)。

サービスでは、既定で適用されるトランスポート層セキュリティを使用して、動作中のデータが暗号化されます。 フレキシブル サーバーは、トランスポート層セキュリティ (TLS 1.2) を使用した暗号化接続を既定でサポートしており、TLS 1.0 と TLS 1.1 を使用した受信接続はすべて拒否されます。 require_secure_transport サーバー パラメーターを設定することで、SSL 強制を無効にすることができ、また、サーバーの最小 tls_version を設定できます。

詳細については、フレキシブル サーバーへの暗号化された接続の使用方法に関する記事を参照してください。

フレキシブル サーバーを使用すると、Azure 仮想ネットワーク (VNet 統合) を使用してサーバーに完全にプライベートでアクセスできます。 Azure Virtual Network 内のサーバーには、プライベート IP アドレスを介してのみアクセスおよび接続できます。 VNet 統合を使用すると、パブリック アクセスが拒否され、パブリック エンドポイントを使用してサーバーに到達することはできません。

詳細については、ネットワークの概念に関する記事をご覧ください。

監視とアラート

フレキシブル サーバー サービスには、組み込みのパフォーマンス監視機能とアラート機能が搭載されています。 すべての Azure メトリックは 1 分間隔で、各メトリックの 30 日間の履歴が保持されます。 メトリックにアラートを構成できます。 サービスにより、リソース使用率を監視し低速クエリ ログを構成できるようにするホスト サーバー メトリックが公開されます。 これらのツールを使用すると、ワークロードをすばやく最適化し、最適なパフォーマンスが得られるようにサーバーを構成することができます。 Azure Database for MySQL フレキシブル サーバーでは、Azure Monitor ブックを使用し、遅いクエリと監査ログ データを視覚化できます。 ブックを使用すると、データを分析し、Azure portal 内に豊富な視覚レポートを作成するための柔軟なキャンバスが得られます。 Azure Database for MySQL フレキシブル サーバーでは、Server Overview、AuditingQuery Performance Insights という 3 つのブック テンプレートを面倒な設定なしで利用できます。 Query Performance Insight ブックは、次のような情報を提供することで、データベースのパフォーマンスのトラブルシューティングに費やす時間を短縮できるように設計されています。

  • 実行時間の長いクエリの上位 N 個とその傾向。
  • クエリの詳細: クエリ テキストと、クエリ時間の最小、最大、平均、および標準偏差を含む実行履歴の表示。
  • リソース使用率 (CPU、メモリ、ストレージ)。

さらに、コミュニティ監視ツール (MySQL フレキシブル サーバーでの Percona Monitoring and Management など) を使用でき、これらのツールと統合することができます。

詳細については、監視の概念に関する記事を参照してください。

移行

このサービスでは、MySQL のコミュニティ バージョンが実行されます。 これにより、アプリケーションの完全な互換性が確保され、MySQL エンジン上で開発された既存のアプリケーションをフレキシブル サーバーに移行するために必要なリファクタリング コストが最小限に抑えられます。 フレキシブル サーバーへの移行は、次のオプションを使用して実行できます。

オフライン移行

オンラインの移行または最小限のダウンタイムの移行

初期シード処理では、mydumper/myloader の整合性バックアップ/復元でデータイン レプリケーションを使用します。 詳細については、チュートリアル: 最小限のダウンタイムでの Azure Database for MySQL - シングル サーバーから Azure Database for MySQL – フレキシブル サーバーへの移行に関する記事のステップ バイ ステップの手順を参照してください

5 つの簡単な手順で Azure Database for MySQL - 単一サーバーからフレキシブル サーバーに移行するには、こちらのブログを参照してください。

詳細については、「Azure Database for MySQL への移行に適切なツールを選択する」を参照してください。

Azure Azure リージョン

Azure でワークロードを実行する利点の 1 つは、グローバルに展開できることです。 Azure Database for MySQL フレキシブル サーバーは、現在、次の Azure リージョンで提供されています。

Region 可用性 同一ゾーン HA ゾーン冗長 HA geo 冗長バックアップ
オーストラリア東部 ✔️ ✔️ ✔️ ✔️
Australia Southeast ✔️ ✔️ ✔️
ブラジル南部 ✔️ ✔️ ✔️
カナダ中部 ✔️ ✔️ ✔️
カナダ東部 ✔️ ✔️ ✔️
インド中部 ✔️ ✔️ ✔️
米国中部 ✔️ ✔️ ✔️
中国東部 2 ✔️ ✔️
中国北部 2 ✔️ ✔️
China North 3 ✔️ ✔️
東アジア (香港) ✔️ ✔️ ✔️
米国東部 ✔️ ✔️ ✔️ ✔️
米国東部 2 ✔️ ✔️ ✔️
フランス中部 ✔️ ✔️ ✔️
フランス南部 ✔️ ✔️ ✔️
ドイツ中西部 ✔️ ✔️
東日本 ✔️ ✔️ ✔️ ✔️
西日本 ✔️ ✔️ ✔️
韓国中部 ✔️ ✔️ ✔️ ✔️
韓国南部 ✔️ ✔️ ✔️
米国中北部 ✔️ ✔️ ✔️
北ヨーロッパ ✔️ ✔️ ✔️ ✔️
ノルウェー東部 ✔️ ✔️
カタール中部 ✔️ ✔️ ✔️
南アフリカ北部 ✔️ ✔️
米国中南部 ✔️ ✔️ ✔️ ✔️
インド南部 ✔️ ✔️ ✔️
東南アジア ✔️ ✔️ ✔️
スウェーデン中部 ✔️ ✔️
スイス北部 ✔️ ✔️ ✔️
スイス西部 ✔️ ✔️ ✔️
アラブ首長国連邦北部 ✔️ ✔️
英国南部 ✔️ ✔️ ✔️
英国西部 ✔️ ✔️ ✔️
USGov バージニア州 ✔️ ✔️
USGov アリゾナ ✔️ ✔️ ✔️
USGov テキサス ✔️ ✔️ ✔️
米国中西部 ✔️ ✔️ ✔️
西ヨーロッパ ✔️ ✔️ ✔️ ✔️
米国西部 ✔️ ✔️ ✔️
米国西部 2 ✔️ ✔️ ✔️
米国西部 3 ✔️ ✔️

連絡先

Azure Database for MySQL フレキシブル サーバーについてのご質問やご提案については、Azure Database for MySQL チームまでメール (@Azure DB for MySQL) でお送りください。 このメール アドレスはテクニカル サポートのエイリアスではありません。

さらに、適切な連絡先について次の点を考慮してください。

  • Azure サポートに問い合わせる場合は、Azure portal からチケットを申請します
  • アカウントを使用して問題を修正するには、Azure Portal でサポート要求を提出します。
  • フィードバックを提供したり、新しい機能を要求したりするには、[UserVoice](https://feedback.azure.com/forums/597976-azure-database-for-postgresql) でエントリを作成します。

次のステップ

Azure Database for MySQL - シングル サーバー デプロイ モードの概要を確認したので、以下のことを行う準備ができました。