このページの本文へ

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

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

2017年06月20日 07時00分更新

文● 羽野三千世/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 マイクロソフトは、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日前まで)され、リストアはメニューから実行できます。本当の意味で、運用から解放されたフルマネージドのデータベースサービスと言えます」。

カテゴリートップへ

ASCII.jp特設サイト

クラウド連載/すっきりわかった仮想化技術

ピックアップ