Azure Database for MySQL 単一サーバー
適用対象:
Azure Database for MySQL - シングル サーバー
重要
Azure Database for MySQL の単一サーバーは提供終了パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、「Azure Database for MySQL 単一サーバーの動作」を参照してください 。
MySQL コミュニティ エディションを搭載した Azure Database for MySQL は、次の 2 つのデプロイ モードで利用できます。
- フレキシブル サーバー
- シングル サーバー
この記事では、単一サーバー デプロイ モデルの概要を示し、主要概念について概説します。 フレキシブル サーバー デプロイ モードについては、フレキシブル サーバーの概要を参照してください。 ワークロードに適したデプロイ オプションを決定する方法については、「Azure で適切な MySQL サーバー オプションを選択する」をご覧ください。
概要
Azure Database for MySQL 単一サーバーは、最小限のカスタマイズ用に設計されたフル マネージド データベース サービスです。 単一サーバー プラットフォームは、修正プログラムの適用、バックアップ、高可用性、最小限のユーザー構成と制御によるセキュリティなど、データベース管理機能のほとんどを処理するよう設計されています。 このアーキテクチャは、単一の可用性ゾーンで 99.99% の可用性を備えた組み込みの高可用性を実現するよう最適化されています。 MySQL 5.6 (廃止)、5.7、8.0 のコミュニティ バージョンをサポートしています。 このサービスは現時点で一般提供されており、さまざまな Azure リージョンで利用できます。
単一サーバーは、既に単一サーバーを活用している既存のアプリケーションにのみ最適です。 新たに開発または移行する場合は、デプロイ オプションとしてフレキシブル サーバーが推奨されます。 フレキシブル サーバーと単一サーバーのデプロイ オプションの違いについては、最適なデプロイ オプションを選択する方法に関するドキュメントを参照してください。
高可用性
単一サーバー デプロイ モデルは、組み込みの高可用性と、低コストでの弾力性用に最適化されています。 このアーキテクチャでは、コンピューティングとストレージが分離されています。 データベース エンジンは独自のコンピューティング コンテナー上で実行され、データ ファイルは Azure Storage に格納されます。 ストレージには、データベース ファイルの 3 つのローカル冗長同期コピーが保持され、データの持続性が確保されます。
計画済みまたは計画外のフェールオーバー イベント中にサーバーがダウンした場合、サービスでは次の自動化された手順を使用してサーバーの高可用性が維持されます。
- 新しいコンピューティング コンテナーがプロビジョニングされます
- データ ファイルを含むストレージが新しいコンテナーにマップされます
- 新しいコンピューティング コンテナーで MySQL データベース エンジンがオンラインになります
- ゲートウェイ サービスによって透過的なフェールオーバーが確保されるので、アプリケーション側の変更は不要です。
一般的なフェールオーバー時間は 60 秒から 120 秒です。 単一サーバーのクラウド ネイティブの設計により、99.99% の可用性をサポートし、パッシブ ホット スタンバイのコストを削減することができます。
Microsoft が管理するデータセンターのグローバル ネットワークによって強化された、Azure の業界をリードする可用性 99.99% のサービス レベル アグリーメント (SLA) により、アプリケーションの 24 時間 365 日の継続的な稼働が可能になります。
自動修正
このサービスでは、基になるハードウェア、OS、およびデータベース エンジンの自動修正が実行されます。 パッチには、セキュリティとソフトウェアの更新プログラムが含まれています。 MySQL エンジンの場合、マイナー バージョンのアップグレードは自動的に行われ、パッチ サイクルの一部として含まれます。 パッチの適用に必要なユーザー アクションや構成設定はありません。 パッチの適用頻度は、ペイロードの重要度に基づいてサービスによって管理されます。 一般に、サービスは、継続的インテグレーションとリリースの一環として、毎月のリリース スケジュールに従います。 ユーザーは、計画メンテナンスの通知にサブスクライブすることで、予定されているメンテナンスの通知をそのイベントの 72 時間前に受け取ることができます。
自動バックアップ
単一サーバーでは、サーバーのバックアップが自動的に作成され、ユーザーが構成したローカル冗長または geo 冗長ストレージに保存されます。 バックアップを使用すると、サーバーを、バックアップのリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて、リテンション期間を最大 35 日に構成できます。 すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。 詳細については、バックアップに関する記事をご覧ください。
数秒以内でのパフォーマンスの調整とスケール
単一サーバーは、Basic、General Purpose、メモリ最適化の 3 つの SKU レベルで使用できます。 Basic レベルは、低コストの開発と低コンカレンシーのワークロードに最適です。 General Purpose および Memory Optimized は、高いコンカレンシー、スケール、予測可能なパフォーマンスを必要とする運用ワークロードに適しています。 最初は月数ドルの小規模データベースでアプリを構築し、後から実際のソリューションのニーズに応じて、スケールを調整することができます。 ストレージのスケーリングはオンラインであり、ストレージの自動拡張がサポートされています。 動的なスケーラビリティにより、データベースは変化の激しいリソース要件に透過的に対処することができます。 消費したリソースについてだけ支払います。 詳細については、価格レベルに関するページを参照してください。
エンタープライズ グレードのセキュリティ、コンプライアンス、ガバナンス
単一サーバーでは、保存データのストレージ暗号化に FIPS 140-2 認証済みの暗号モジュールが使用されます。 データ (バックアップを含む) と、クエリの実行中に作成される一時ファイルは暗号化されます。 このサービスでは、Azure ストレージ暗号化に含まれる AES 256 ビット暗号が使用され、キーはシステム マネージド (既定) またはカスタマー マネージドにできます。 サービスでは、既定で適用されるトランスポート層セキュリティ (SSL/TLS) を使用して、動作中のデータが暗号化されます。 このサービスでは、TLS バージョン 1.2、1.1、1.0 がサポートされており、TLS の最低バージョンを適用することができます。
このサービスを使用すると、プライベート リンクを使用してサーバーにプライベート アクセスすることができ、オプションのオープンソース リレーショナル データベース用 Microsoft Defender プランを通じて脅威からの保護が提供されます。 オープンソース リレーショナル データベース用 Microsoft Defender によって、通常とは異なる、害を与えるおそれがあるアクセスや悪用がデータベースに対して試みられていることを示す異常なアクティビティを検出します。
ネイティブ認証に加えて、Single Server では Microsoft Entra ID 認証がサポートされています。 Microsoft Entra 認証は、Microsoft Entra ID で定義および管理されている ID を使用して MySQL サーバーに接続するメカニズムです。 Microsoft Entra 認証を使用すると、データベース ユーザーの ID や他の Azure サービスを一元管理でき、アクセスの制御が簡素化および一元化されます。
監査ログを使用して、すべてのデータベース レベルのアクティビティを追跡できます。
単一サーバーは、FedRAMP、HIPAA、PCI DSS など、業界をリードするすべての認定に準拠しています。 Azure のプラットフォーム セキュリティについては、Azure セキュリティ センターをご覧ください。
Azure Database for MySQL のセキュリティ機能の詳細については、セキュリティの概要に関するページを参照してください。
監視とアラート
単一サーバーには、組み込みのパフォーマンス監視機能とアラート機能が搭載されています。 すべての Azure メトリックは 1 分間隔で、各メトリックの 30 日間の履歴が保持されます。 メトリックにアラートを構成できます。 このサービスでは遅いクエリのログを構成できます。また、このサービスには、他とは異なるクエリ ストア機能が用意されています。 クエリ ストアを使用すると、実行時間が最長のクエリおよびリソースを最も消費しているクエリを迅速に特定できるので、パフォーマンスのトラブルシューティングが簡単になります。 これらのツールを使用すると、ワークロードをすばやく最適化し、最適なパフォーマンスが得られるようにサーバーを構成することができます。 詳細については、監視に関する記事を参照してください。
移行
このサービスでは、MySQL のコミュニティ バージョンが実行されます。 これにより、アプリケーションの完全な互換性が確保され、MySQL エンジン上で開発された既存のアプリケーションを単一サーバーに移行するために必要なリファクタリング コストが最小限に抑えられます。 単一サーバーへの移行は、次のいずれかのオプションを使用して実行できます。
- ダンプと復元 – ユーザーがダウンタイムを許容できるオフライン移行では、mysqldump や mydumper などのコミュニティ ツールを使用してダンプと復元を行うことで、最も迅速に移行することができます。 詳細については、ダンプと復元を使用した移行に関する記事を参照してください。
- Azure Database Migration Service – 高速データ移行を使用して単一サーバーへのシームレスで簡素化されたオフライン移行を行うには、Azure Database Migration Service を利用できます。
- データイン レプリケーション – 移行のダウンタイムを最小限にするために、binlog ベースのレプリケーションに依存するデータイン レプリケーションを利用することもできます。 データイン レプリケーションは、移行をより細かく制御する必要がある現場のエキスパートが、最小限のダウンタイムで移行を行う場合に適しています。 詳細については、データイン レプリケーションに関する記事をご覧ください。
連絡先
Azure Database for MySQL についての質問や提案は、Azure Database for MySQL チームにメール (@Ask Azure DB for MySQL) でお送りください。 このメール アドレスはテクニカル サポートのエイリアスではありません。
さらに、適切な連絡先について次の点を考慮してください。
- Azure サポートに問い合わせる場合は、Azure portal からチケットを申請します。
- アカウントを使用して問題を修正するには、Azure Portal でサポート要求を提出します。
- フィードバックを提供したり、新しい機能を要求したりするには、
[ UserVoice](https://feedback.azure.com/forums/597976-azure-database-for-postgresql) でエントリを作成します。
次のステップ
Azure Database for MySQL - シングル サーバー デプロイ モードの概要を確認したので、以下のことを行う準備ができました。
最初のサーバーを作成する。
次の任意の言語を使って最初のアプリを作成します。