「de:code 2017」レポート：VMではなくマイクロサービス上に展開されたDB

インフラから解説、Azure PaaSでMySQL/PostgreSQLを使う意義

　マイクロソフトは、5月10日～12日にシアトルで開催した年次開発者会議「Build 2017」で、オープンソースのリレーショナルデータベース「MySQL」と「PostgreSQL」をフルマネージドのPaaSで提供する「Azure Database for MySQL」および「Azure Database for PostgreSQL」を発表した。6月19日時点で、東日本／西日本リージョンを含むAzureの11リージョンでパブリックプレビューが提供されている。

　PaaSのMySQL/PostgreSQLデータベースサービスとしては、AWSの「Amazon RDS for MySQL/PostgreSQL」、Google Cloud Platformの「Cloud SQL」（PostgreSQL向けCloud SQLは近日提供予定）などから遅れての登場になった。これらの先行するクラウドデータベースサービスとAzureの新しいデータベースサービスは、同じPaaSでも、インフラの設計が異なる。Azure Database for MySQL/PostgreSQLは、仮想マシン（VM）インスタンスではなくマイクロサービス上に展開されており、これによって、マルチAZ（アベイラビリティゾーン）配置などの設計なしに、1つのリージョン内でSLA99.99％の可用性を実現するのが特徴だ。

　5月24日、日本マイクロソフトが主催する技術者向けイベント「de:code 2017」のテクニカルセッションで、同社 エバンジェリストの久森達郎氏が、Azure Database for MySQL/ PostgreSQLの特徴について、PaaSのインフラから解説した。

日本マイクロソフト エバンジェリストの久森達郎氏

VMではなくService Fabric上に展開

　Azure Database for MySQL/PostgreSQLは、Microsoft SQL ServerのPaaSであるAzure SQL Databaseと共通の基盤上に、抽象化されたサービスとして構築されている。その実装について、久森氏は「VMではなく、Azure Service Fabric（マイクロサービスプラットフォーム）の上にSQL Database 、MySQL、PostgreSQLの各サービスが展開されています」と説明した。

Azure Database for MySQL/PostgreSQLはAzure SQL Databaseと共通基盤上にある

　Service Fabricは、AzureのIaaS層の上にクラスターをつくり、このクラスターを構成するノードの集合上にSQL Database、MySQL、PostgreSQLの各データベースサービスがデプロイされる。

データベースサービスはクラスターのノードの集合上にデプロイ

　ユーザーから見えるのは、論理データベースのエンドポイントだ。論理データベースは、裏で1つのプライマリと複数のセカンダリに多重化されており、このプライマリとセカンダリはクラスター上のノードに分散配置される。プライマリに障害が起こったときには、セカンダリの1つがプライマリに昇格（フェールオーバー）して新たに別のセカンダリが作られる（リコンフィグレーション）。このフェールオーバー、アプリケーションの展開はService Fabricの機能として自動化されている。

クラスター上のノードにプライマリとセカンダリが分散配置される

　「これまでによくあったPaaSの設計では、複数のデータセンター（DC）やAZにVMをデプロイして、DC間やAZ間をフェールオーバーしていました。これはIaaSベースの設計であり、SLAもIaaSと同等になります。Azure Database for MySQL/PostgreSQLでは、クラスター上のノード間で自動フェールオーバーする仕組みによって、1つのリージョン内でSLA99.99％を実現しています」（久森氏）。

これまでによくあるPaaSの設計

インスタンスサイズではなく「処理性能」を選択

　Service Fabricのクラスター上で高速にフェールオーバーする仕組みにより、Azure Database for MySQL/PostgreSQLは、ユーザーが設定画面上でスライダーを動かすだけでデータベースの処理性能をプロビジョニングできる。

　データベースサービスを新規作成する際は、インスタンスサイズではなく処理性能を選択する。具体的には、Azure Database for MySQL/PostgreSQLでは、「Compute Unit（CU）」という単位で必要な処理性能を選択する。「CUは、CPUとメモリーをミックスした単位で、処理できるSQLクエリの性能を選択するものです」（久森氏）。CUはデータベース作成後にいつでも変更可能で、CUを増減すると裏で自動的にフェールオーバーが行われる。「フェールオーバーが早いので、実運用をしながらCUを調整していく運用が可能です」（久森氏）。

　CUとは別にストレージサイズも選択できる。Azure Database for MySQL/PostgreSQLでは、想定ユースケースによって「Basic（軽いワークロード用途）」、「Standard（スループット重視）」、「Premium（レイテンシ重視）」の3つのプランを用意しており、プランによってストレージの種類が異なるのが特徴だ（現在のパブリックプレビューではBasic、Standardのみ）。

Azure Database for MySQL/PostgreSQLのサービスプラン

既存データベースからの移行方法は？

　このように、Azure Database for MySQL/PostgreSQLは特色あるインフラ上に構築されているが、データベースとしての使い勝手は通常のMySQL/PostgreSQLデータベースと同じだ。「論理データベースのエンドポイントには、これまで使っていたのと同じMySQL/PostgreSQLのクライアントやライブラリからSSLで接続できるようになっています」と久森氏。

　現時点での制限事項として、Azure Database for PostgreSQLはレプリケーションがサポートされていない。また、Azure Database for MySQLはリードオンリーレプリカの作成に対応していない。

　そのため、既存のデータベースを移行する場合は、PostgreSQLデータベースについてはpg_dumpコマンドで既存データベースからエクスポートし、新規作成したAzure Database for PostgreSQLサービス上にpsqlコマンドでインポートする。

PostgreSQLデータベースの移行

　MySQLデータベースも同様で、「現状では公式ドキュメントでレプリケーションによるマイグレーションがサポートされていないので」（久森氏）、mysqldumpコマンドで既存データベースからエクスポートし、新規作成したAzure Database for MySQLサービス上にmysqlコマンドでインポートする。

　最後に久森氏はAzure Database for MySQL/PostgreSQLについて、次のようにまとめた。「サーバーインスタンスのチューニングは不要で、必要な処理性能を選択して使うサービスであり、インフラを意識する必要はありません。データは自動でバックアップ（Basicでは7日前まで、Standard以上は35日前まで）され、リストアはメニューから実行できます。本当の意味で、運用から解放されたフルマネージドのデータベースサービスと言えます」。

■関連サイト

• Azure Database for MySQL
• Azure Database for PostgreSQL