「de:code 2017」レポート：VMではなくマイクロサービス上に展開されたDB
インフラから解説、Azure PaaSでMySQL/PostgreSQLを使う意義
2017年06月20日 07時00分更新
マイクロソフトは、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日前まで）され、リストアはメニューから実行できます。本当の意味で、運用から解放されたフルマネージドのデータベースサービスと言えます」。
