COLUMN

Azureの基盤上でMySQLを動かす！フルマネージドサービスの Azure Database for MySQLの特徴や注意点を解説

AzureでMySQLを使いたいという要望に合わせて生まれた「Azure Database for MySQL」。Azureの可用性99.99%のサービスレベルアグリーメント（SLA）により、ほぼ24時間365日の継続的な稼働が期待できます。その秘密はクラスター内でのフェールオーバー実現。一般的なサービスでは、複数のデータセンターやアベイラビリティゾーン（AZ）にVMをデプロイし、フェールオーバーを実現しますが、Azure Database for MySQLでは、マルチAZ配置などの設計無しで、同一リージョン内でのフェールオーバーを可能にしています。また、AIを使用したデータベースの監視と最適化や豊富なセキュリティ機能も提供されています。

今回は、Azureの基盤上でMySQLと同様に利用できるAzure Database for MySQLについて解説していきます。

Azure Database for MySQLとは

Azure Database for MySQLは、MySQL Community Editionのバージョン5.6、5.7、および8.0をベースとし、オンプレミス環境のMySQLと同様に利用できるフルマネージドサービスです。

Azure Database for MySQLの主な機能とメリット

さっそく、Azure Database for MySQLの主な機能とメリットについてみていきましょう。

各種アップデートや管理作業が不要

フルマネージドなサービス全体にいえることですが、OSのアップデートやデータベースのセキュリティパッチ適用などは不要です。また各種サーバー設定変更や、障害対応などの対応についてもサービスの管理元が実施するため、管理者の対応負荷が軽減できます。

データベースの障害分析やチューニングなどに必要な監視機能

Azure Database for MySQLでは、CPUとストレージの使用率、データベースのログオンおよび接続試行の成功数や失敗数、データベース操作、SQL問合せ、トランザクション情報などを提供しています。

また過去のパフォーマンス改善事例などを学習させたAIを使用することで、サーバー間のワークロードを分析してパフォーマンス向上についての必要な情報が効率よく得られます。

Query Performance Insightやパフォーマンスの推奨事項機能により、実行時間の長いクエリや最適化の余地がある部分を特定しやすく、チューニングの際に役立ちます。

35日間のバックアップが可能

Azure Database for MySQLは、最大で35日分のバックアップを自動で取得できます。このバックアップは、ポイントインタイムリカバリ(PITR)ができます。

PITRでは、ある時点でのバックアップがベースバックアップとして取得され、さらにデータベースの変更によって発生するWAL(Write Ahead Logging)ファイルがアーカイブとしてバックアップされます。データベースのリストア時には、バックアップにWALファイルを順番に適用していくことで、障害発生直前までのデータベースのデータに戻せます。

またAzure Database for MySQLが持つ「Basicプラン」「汎用プラン」「メモリ最適化プラン」の3つの価格プランのうち、汎用プランとメモリ最適化プランのみでの提供となりますが、冗長バックアップストレージが利用できます。このストレージを利用すると、現在のリージョンとペアになっているデータセンターにもデータがレプリケートされるため、ディザスタリカバリを意識した運用を行うことができます。

オンラインでのデータベース移行ができる

Azure Database Migration Serviceの継続的同期機能を併用すると、データベースサーバーをAzureに移行する際の停止を最小限に抑えて移行できます。移行にあたっては、まず移行元のサーバーからAzure Database for MySQL へのデータコピーを実施します。その後サービスを停止せずに、新たに生じるデータの更新を継続的に同期。データの更新が同期しきったところで、サービスを停止してAzureへ切り替えます。これにより最小限のダウンタイムでデータベースを移行できます。

Azure Service fabricで高可用性を実現

Azureの可用性99.99%のSLAにより、ほぼ停止のないサービス提供が期待できます。Azure Database for MySQLは、一般的なVirtual Machine(VM)上にAzure Database for MySQLを展開するのではなく、Azure Service fabric（スケーラブルなクラウドアプリケーション開発のための、マイクロサービスとコンテナーのパッケージ化とデプロイ、管理を簡単に行うことができる、Microsoftの分散システムプラットフォーム）上に展開されるため、標準で冗長化されたデータベース環境が構成されます。また、スケールダウン・スケールアップ時のダウンタイムが最小限に抑えられることも魅力のひとつです。

他のサービスでは、複数のデータセンターやアベイラビリティゾーンにVMをデプロイしてフェールオーバーする必要がありました。しかし、その形態では適用されるSLAもIaaSと同等になってしまいます。Azure Database for MySQLはAzure Service fabric上で自動的なフェールオーバーを実施することにより、ひとつのリージョン内でSLA99.99％を実現しているのです。

Azureのセキュリティ機能やデータ保護機能が利用できる

Azure Database for MySQLでは、MySQL／PostgreSQLネイティブ認証、SSL接続、ファイアウォール（IPホワイトリスト方式）、データベースバックアップ、読み取りレプリカ機能(データ同期)、暗号化（AES 256）など、Azureが持つ多彩なセキュリティ機能やデータ保護機能が利用できます。また Azure Database for MySQLではAzureのVnetが使用でき、Azureのネットワーク内に閉じた通信ができるので、不正な通信のリスクを最小限にできます。また、他のシステムのネットワークを経由しないためレスポンスも高速です。

Azure Database for MySQLを使用するうえでの注意点

続いて、Azure Database for MySQLを使用するうえでの注意点をみていきましょう。

コスト増とコントロールできない項目に注意

フルマネージドサービスに共通していえることですが、オンプレミスやIaaS上にMySQL Serverを立てるときのような細かいチューニングはできません。技術的に非常に細かな個々の要件に応える必要があるシステムやセキュリティ的にクラウドシステムを利用できないシステムを構築する場合には、オンプレミスでデータベースを構築せざるを得ないこともあるでしょう。

また、緊急メンテナンスが提供元の判断で実施されてしまうことにも注意が必要です。（緊急であっても、サービス利用に影響がある計画的メンテナンスについては事前にアナウンスがなされます。）

仕様による制限事項が複数ある

Azure Database for MySQLには、主に次のような細かい制限事項が存在します。

• Basicプランで作成されたサーバーは、汎用プランまたはメモリ最適化プランに変更できません
• 同様に汎用プランまたはメモリ最適化プランで作成されたサーバーは、Basicプランに変更できません
• Azure Database for MySQLとの通信では、3306番のポートが使われます。ファイアウォールなどで3306番ポートでの通信が許可されているか確認しておきましょう
• バックアップ冗長オプションを構成できるのは、サーバーの作成時だけです。サーバーを展開してしまうとバックアップ冗長オプションは構成できなくなります。
• データベースは自動的にバックアップできますが、リストア時には、新規作成したサーバーにリストアする必要があります
• 一度サーバーを削除すると復元は不可能です。サーバーを削除してしまうと、仕様上そのサーバーに属するデータベースもすべて削除され、復元は一切できなくなります
• パッチ適用時は自動でフェールオーバーするため、セッションが切れる可能性があります。サービスを稼働させる際には、セッションの切断時に自動で張り直すよう設定しましょう
• VNetでの通信は、汎用プランとメモリ最適化プランでのみ使用可能です。Basicプランでは使用できません
• Azure Database Migration Serviceでサービス停止を最小限にした移行を実施するには、Premiumプランでインスタンスを作成する必要があります。
• 読み取りレプリカ機能は、汎用プランとメモリ最適化プランで使用可能です。Basicプランでは使用不可能です
• ストレージはスケールアップのみ可能で、スケールダウンすることはできません
• リージョンによってストレージ入出力性能が異なります。米国東部、北ヨーロッパ、東南アジアなどの地域では、最大で16TBおよび20,000IOPSのストレージが利用できます。その他のリージョンではストレージ能力が劣り、最大4TBおよび最大6000IOPSのストレージしか利用できません。

Azure Database for MySQLの料金

Azure Database for MySQLの料金は、使用するリソース量や利用時間に基づいて課金されます。

詳しくは公式サイトの料金表でご確認ください
価格 - Azure Database for MySQL | Microsoft Azure(Microsoft Azure公式ページ)

Azure Database for MySQLで可用性の高いシステム運営を

Azure Database for MySQLの最大のメリットは、その高い可用性です。99.99%のSLAにより、ほぼ24時間365日の継続的な稼働が期待できます。

AzureのPaaSデータベースサービスには他にも、「Azure SQL Database」、「Azure Database for PostgreSQL」、「Azure Cosmos DB」などのサービスがあります。

なかでも可用性が高く、ミッションクリティカルなシステムに対して有効なのが、Azure Cosmos DBですが、他のデータベースサービスの決定的な違いはデータベースの仕組みです。Azure Database for MySQL、Azure SQL Database、Azure Database for PostgreSQLは「リレーショナルデータベース(RDB)」、Cosmos DBは「NoSQL」と呼ばれる仕組みで動作します。

「NoSQL」は、データベースの一貫性の保持は重視せず、さらに入力チェックを実施しないことによりデータ入出力の速度を早め、さらにデータベースを水平分散できるようにしています。そのためNoSQLはRDBと比較してデータの処理速度が高速で、自由な拡張が可能です。

反面、メリットで重視していない点がそのままデメリットとなり、データの一貫性や検索能力はRDBに劣ります。水平分散させることができるように厳密な一貫性は求めていませんし、SQL言語を使用できないため、複雑な検索が不可能です。厳密なデータの一貫性や複雑な検索が求められるシステムにはRDBが向いています。

Azure PaaS データベースサービスでのデータベース選択では、そのような特徴を踏まえて、まず、RDSかNo SQLかの選択を行いましょう。

なお、RDBであるAzure Database for MySQL、Azure SQL Database、Azure Database for PostgreSQLはもともとオンプレミスデータベースであり、AzureのPaaSデータベースサービスにおいても、SQL Server（Azure SQL DatabaseはSQL ServerのAzure版）やMySQLは比較的シンプルな仕様、PostgreSQLは機能が豊富といった、それぞれの特性が引き継がれています。オンプレミスでのデータベース選択の時と同様に、利用したい要件に応じて選択しましょう。

Azure Database for MySQLはSLAで高い可用性がコミットされています。24時間365日いつでも使えるシステムをめざすなら、RDBの特徴を活かせるシステムにAzure Database for MySQLを検討してみてはいかがでしょうか。