Azure Database for MySQL PostgreSQLを使って運用の手間を省きませんか？

Editor's Notes

• #2: それではお時間になりましたので、Azure Database for MySQL / PostgreSQLを使ってアプリケーション開発に注力しませんか？ということで、 わたくし、日本マイクロソフトでAzureのプリセールスエンジニアをしております伊藤よりお話させていただきます
• #3: 本セッションの目次になります。 まず、ご存知の方も多いかと思いますが、PaaSとは何かというところ、そしてAzureのPaaSサービスはどのようなものがあるか、というところを説明します。 そして、本セッションのメインであります、Azure Database for MySQL / PostgreSQLについて、どういった機能があるか、どういったメリットがあるかというところを、実際に画面を見ていただきながらお話させていただきます。 最後にまとめとQAになります。
• #4: 本ウェビナーのポイントになります。 大きくわけて2つあります。 まずは「データベース管理の時間が減らせる」という点です。 今回紹介するAzure Database for MySQL / PostgreSQLを使うことで、5分もあればデータベース環境はすぐに手に入りますので、サーバを用意して、MySQLをインストールして、といった作業が必要なくなりますので、 スピード感ある開発が可能になります。 また、運用に関しては、パッチ適用だったり、容量が足りなくなったらディスクの追加とか、本当なら開発したいのに運用に追われることがあると思いますが、このサービスを使用することで、そういった運用の手間からは解消されますので、開発に注力できるようになります。 その２としては、クラウドのメリットを最大限に活用して頂きたい点です。 高可用性といいますと、同じサーバを用意して、ロードバランサーなどでアクセスを振り分けてデータはrsyncなどで同期して…など色々な設計が必要ですし、技術的にも少し難易度の高いものが必要になりますが、 このサービスでは高可用性はデフォルトで組まれておりますので、難しい構成も考える必要はありません。 また、これはクラウドで最大のメリットだと思うのですが、何かサービスを開始するときは、今までだと最大アクセスなどを考えてハードウェアのスペックが必要だったと思いますが、クラウドだとまずは小さなスペックでサービスを開始して、 サービスの成長と共にマシン性能を上げることが出来るので、手軽に低コストでサービス提供が出来るようになります。 では、まずはPaaSサービスの紹介をしたいと思います。
• #5: では、AzureのPaaSサービスの紹介です。
• #6: こちらはAzureにどういったサービスがあるか、という図になります。 ここには58のサービスが書かれています。肝心のAzure Database for MySQLがないので、合わせて59あります。 現在も色々とサービスは開発中ですので、この数はどんどん増えていくことになるかと思います。 この真中の赤色で囲われている部分が、AzureのPaaSサービスになります。 ご存知の方も多いかもしれませんが、PaaSとはなにか、というものを改めて説明します。
• #7: この図は、左から、オンプレミス、IaaS、PaaS、SaaSを、「誰が管理するのか」というものを表した図になります。 緑色が、使用するユーザが管理する部分、青色が、クラウドベンダーが管理する部分になります。 オンプレミスだと、サーバー筐体や、ディスク、ネットワークの設計などを自分で構成、管理する必要があります。 ディスクを何本もさして、RAID構成を組んだり、ネットワークだと、スイッチでどのようにネットワークを組むか、などですね。 IaaSだと、この部分はクラウドベンダーが管理することになります。 ユーザはどんなスペックのサーバが必要かですとか、ディスクの容量、ネットワークの範囲などをGUIでポチポチと決めていくだけで、そのとおりのサーバ環境がすぐに手に入ります。 サーバ自体の保守は必要なく、クラウドベンダーが行う部分になります。 ユーザーは、そのサーバーが動いているOSの管理を行う必要があります。例えばパッチの適用や、OSのセキュリティ対策などです。 PaaSになると、サーバーの中身までクラウドベンダーが管理することになります。 IaaSでは必要だったパッチの適用や、OSのセキュリティ対策、可用性の構築など、このあたりはクラウドベンダーが保守することになります、青色の部分が増えていることがお分かりかと思います。 また、手軽にその環境が手に入るようになります。ですので、ユーザはアプリケーション開発や、データのことだけ考えるだけでよくなります。 SaaSは、弊社のサービスであればOffice 365など、そのアプリケーションを使用するだけ、というものです。 では、実際にどういった部分をクラウドベンダーが保守しているのか？すなわち、PaaSのメリットはなにか、というものは次のスライドになります。
• #8: PaaSを使うことによるメリットは大きく分けて2つです。 まずはインフラ基盤の設計や運用から開放される点です。 オンプレミスだと、どうしてもハードウェアの設計が必要になります。実際にパーツを入れるという点ではなく、 このサービスはどれくらいのスペックが必要なのだろう？ということももちろん設計になります。この点はIaaSも同じメリットがあるのですが、 スモールスタートも可能ですし、ひとまず使ってみよう、ということが可能です。 次に、バックアップの設計です。 PaaSの場合はバックアップのことを考える必要はありません。特に今回紹介するAzure Database for MySQL / PostgreSQLでは、デフォルトで7日間のバックアップを自動で取得します。 7日間以内なら、任意のタイミングでリストアすることが可能です。こちらは後ほど画面を見て頂きたいと思います。 次にDR対策です。ディザスタリカバリの環境は、別のデータセンターに同じ環境を用意して、災害時にその環境にフェールオーバーしたりなど、技術的にも敷居は高いです。それに同じ環境を別のデータセンターに持つということは、 単純に倍の数のサーバを持つ必要がありますので、それだけコストがかかるということにもなります。PaaSを使うことで、DR環境は手軽に用意することが可能です。 また、パッチ適用や、脆弱性対応など、「やらないといけないけど平日にはできない」対応は多いのではないでしょうか。エンドユーザーとの調整を行い、ユーザが使用していない時間帯や、夜間・休日出勤をしてパッチ適用・再起動をして、サービスの正常性を確認するということは システム運用をしていると必ずといっていいほど直面する問題だと思います。PaaSであれば、パッチ適用などは裏側で自動で実施されるので、ユーザに影響与えることなくセキュリティを担保することが出来ます。 設計・運用の開放だけでなく、コスト削減もメリットとして挙げられます。 先程のDR環境の構築でも触れましたが、データセンターを運用するコストというものは、しっかりとしたファシリティでオンプレミス環境を運用する上では避けられないコストでしょう。自社内でサーバを運用する手ももちろんありますが、その場合はしっかりとしたファシリティを用意するという部分でコストがかかることになります。 実際にクラウド移行の検討をされているお客様に理由を尋ねると、「データセンター費用が結構大きくて」という理由を挙げられる方が結構いらっしゃいます。 こういったものがなくなることでコスト削減が見込まれますし、 先程の夜間のパッチ適用など、また普段運用する上でかかる人のコストもかかってきますが、PaaSを使うことで自動でパッチ適用などが実施されますので、このあたりも削減が見込まれることがメリットとなります。 では、このPaaSの基盤、特に今回紹介するデータベースのサービスがどういった基盤で動いているのかを紹介したいと思います。
• #9: Azure Database for MySQL / PostgreSQLは、Azure SQL Databaseと同じ基盤で動いています。 SQL Databaseは、本日紹介するAzure Database for MySQL / PostgreSQLと同じPaaSサービスで、SQL ServerのPaaS版とお考え頂けたらと思います。 SQL Databaseは、Azureが誕生した2010年から存在しているサービスで、もう8年もの実績を誇ります。 その実績ある基盤と同じ部分で動いていますので、この点はまず信頼頂けたらと思います。 次に「マイクロサービス的な実装」と書かれていますが、簡単にマイクロサービスの説明をしますと、マイクロサービスは小さなサービスを組み合わせてアプリケーションを開発するスタイルのことを言います。 基本的にアプリケーションというのは、サーバーの上に色々なミドルウェアなどがインストールされ、それぞれ連携してアプリケーションとして動いていると思いますが、 マイクロサービスであれば小さなサービス自体はそれぞれ単体で動作して、それぞれのサービスの疎通はREST APIなどの軽量な方式で行われます。 コンテナをご存知の方がいれば、コンテナのようなものをイメージして頂くと、それに近いイメージが想像できるかと思います。 このマイクロサービスのメリットを続けてお話しますと、今までのアプリケーションだと、必要なサービスが全てサーバ上に乗ってアプリケーションが提供されています。 例えばWebもシステムだと、Webのミドルウェアと、DBのミドルウェアが乗っています。そのシステムが、例えばアクセス数が捌ききれなくなったときにどう対処するかというと、そのサーバ丸ごとスケールアウトする必要がありました。同じシステムのサーバをもう一台用意して、アクセスを振り分けるという方法です。 これがマイクロサービスのアーキテクチャだと、それぞれが独立して動いていて、フロントのWebが捌ききれなくなった場合はフロントだけ、バックエンドのDBが捌ききれなくなったらDBだけをスケールアウトすることで対応できるので、柔軟なスケールの変更が可能になりました。 また、プログラムや設定の変更を行った場合、今までのシステムの場合は全体を再デプロイが必要だったり、時間がかかります。しかし、マイクロサービスの場合はそれぞれのロジックが独立していてかつ小さいので、変更の影響範囲を小さくすることができます。 この2つのメリットを備えているのがマイクロサービスです。 AzureではService Fabricというサービスでリリースしていまして、Azure SQL DatabaseとこのAzure Database for MySQL / PostgreSQLはこの基盤で動いています。 マイクロサービスのメリットを活用して、動的なリソース変更や再構成が可能になっています。 また、マイクロサービスを用いることで、SQL Databaseと同じ99.99%のSLAを担保しています。 これまでがPaaSはどういったものなのか、またそのメリットについてご紹介しました。 では改めて、今回のメインでありますAzure Database for MySQL / PostgreSQLの紹介をします。
• #11: 3月20日にリリースされた本サービスですが、フルマネージドのMySQL、PostgreSQLになります。 先程お話したPaaSのメリットをそのまま享受できるサービスになっています。バックアップやパッチ適用などはAzureにお任せです。 IaaSでは、「CPU何コア、メモリ何GB」といったスペックを選定することが多かったと思いますが、本サービスでは、仮想コアを選択する方式になっています。 選択した仮想コアごとにメモリの容量が決まっています。ただ、メモリ容量については公開されておりませんのでご注意ください。 また、先ほど紹介したService Fabricが基盤になっていますので、ダウンタイムなしでスケールアップなどもできますし、高可用性のシステムがデフォルトで組まれています。 Community版のMySQLやPostgreSQLを使用していて、マイクロソフトで独自改造されていることはありません。今までお使いのツールやドライバですぐに利用することが可能です。
• #12: バージョンについてはMySQLは5.6、5.7をサポートしていて、InnoDBエンジンがベースになっています。記載しておりますが、MyISAMは構築することはできません。 PostgreSQLに関しても同じくコミュニティ版で、9.5、9.6をサポートしています。 先程、アップデートなどはAzureにお任せとお伝えしましたが、マイナーバージョンのアップデートのみAzure側で自動で実施されます。 PostgreSQLですと、例えば9.5から9.6へのアップデートは自動で実施されず、9.5.1から9.5.2といったマイナーバージョンのアップデートのみが実施されます。 また、現状は手動でもメジャーバージョンのアップデートは出来ませんので、バージョンを切り替えたい場合はデータベースを移行して頂く必要があります。
• #13: スペックはこのようになっています。 まず、Basic , 汎用 , メモリ最適化の違いについて説明します。 Basicは、開発やテスト環境、小規模なアプリケーションを使用する際に選択されるようなスペックになります。 汎用は、大部分のシステムに利用できます。Webサイトやアプリケーション、基幹システムなどにも利用できます。ストレージ種類のところに「Premium」と書いていますが、 こちらはSSDを利用しており、またIOPSもディスクサイズを増やすことで増えていきますので、I/Oスループットを必要とするシステムにもご利用頂きやすいスペックになっています。 I/Oが必要な場合はディスク容量を増やせばOKということになります。 メモリ最適化は、汎用に比べて、メモリの数が倍になっています。ちなみに汎用はBasicの2倍のメモリを搭載しています。メモリについては公開されていないので正確な数値をお伝えすることはできないのですが、 メモリ最適化を選択するばあいというのは、高速なトランザクション処理が必要だったり、インメモリのパフォーマンスが必要だったりなど、高いパフォーマンスを出すことを常に求められるようなシステムに対して向いています。 分析系のソフトを使用するサーバに対するデータベースなどでは、こちらを利用するのがいいかと思います。 メモリ最適化もSSDを使用しています。 ストレージは5GBから2TBまで選択できますが、ストレージに格納されるのは、データベースファイルだけでなく、一時ファイルやトランザクションログ、MySQLサーバログを含みます。 現状では、Basic から 汎用など、またいだスペック変更が出来ない点には注意してください。
• #14: データベースに対してのアクセス方法です。 今までのツールやドライバでアクセス可能ですので、データベースのエンドポイントに対して、MySQL Workbenchや、Pgadminといったツールを使って接続が可能です。 スライドの右側、左側にかかれているのがその部分になります。 データベースの手前にはGatewayが設けられており、こちらがアクセス先のエンドポイントを提供しています。 対象のゲートウェイから内部にあるデータベースにアクセスします。このゲートウェイについてはあとのスライドで改めて説明します。 画面上部の部分に関しては、Azure ポータルやコマンドベースでAzureを管理するAzure CLIからデータベースにアクセスする部分になるのですが、パラメータ変更や、スペック変更、監視などをREST APIを使って管理しています。 ポータルやCLIからのアクセスに関しては全てREST APIを通して行い、データベースの管理を行います。
• #15: 先程ゲートウェイが存在するとお伝えしましたが、このゲートウェイは高可用性やスケールアップの実現のためには不可欠なサービスになっています。 高可用性の場合を見てみます。 これはPostgreSQLクライアントからAzure Database for PostgreSQLに対して接続をしています。 Gatewayからデータベースに対してアクセスをしているのですが、ゲートウェイ先のアクセスするデータベースは、Primaryと2台のSecondaryで構成されています。 データベースに障害が発生した場合に、裏側でフェールオーバーが自動で走り、Secondaryが自動的にプライマリに昇格します。そして別のサーバがSecondaryになり、Primaryと2台のSecondaryになります。 PostgreSQLクライアント側は、リトライをすることで、Gateway内にある新しいデータベースにアクセスでき、そのまま利用が可能になります。 ですので、クライアント側では再接続のロジックを組んで頂くことで、DB側でもし障害が合った際も、エンドユーザからすると特に気になることなくアプリケーションを利用し続けることができる、ということになります。 1台のPrimaryと2台のSecondaryがあるとお伝えしましたが、これはあくまで裏側のことで、利用されるユーザーは気にすることはなく、また料金はかかりません。
• #16: スケールアップも同様です。 こちらは実際に画面をみて頂き、スケールアップをしてみます。
• #17: 次にAzure Database for MySQL / PostgreSQLのセキュリティ機能を紹介します。 大きく分けて3つの要素でセキュリティ保護を行っております。 まずはID認証です。こちらはそれぞれのDBのネイティブ認証を使っており、ユーザー名・パスワードでログインを行います。 次にアクセス管理です。アクセス管理は、通信はSSLを使っており暗号化しております。また、サーバーファイアウォールとして、特定のIPアドレスからのみアクセスを可能とします。 また、Azureの同じサブスクリプション内からのアクセスを可能にするかどうかを選択することも可能です。 アクセス管理をどのようにするのかは実際に画面をご覧頂きたいと思います。 最後にデータ保護として、データベースとバックアップデータはAES-256の形式で暗号化されています。
• #18: バックアップに関しては、自動でバックアップされます。 こちらもご覧頂きたいと思います。 もちろん、Azure Database for MySQL / PostgreSQLのバックアップリストア機能を無理に利用する必要はなく、 今まで行われていたmysqldumpやpg_dumpを使ったバックアップやリストアも可能です。ただ、こちらは従来と変わらず整合性を保つために書き込み禁止などを考慮する必要はあります。
• #19: こちらも実際にご覧頂けたらと思いますが、リソースの状況もAzureポータルから確認が可能です。 また、リソースの状況によってアラートの設定が可能になっています。 メールの送信、アラートをWebhookとして利用したり、Azureのサービスの1つであるLogic Appのトリガーとしても利用可能です。Logic Appとは、ノンプログラミングで各サービスのワークフローを作成するサービスです。 Webhookを利用して、アラートが発生したらSlackに投稿したり、Logic Appを利用して、「CPUが80%を超えた際にスペックアップさせる」といったようなオートスケールの設定も可能です。 では、リソース状況の画面を実際に見て頂きたいと思います。
• #20: 最後に、既存のデータベースシステムを本サービスで可動させる方法について説明します。 よくある方法としては、mysqldumpやpg_dumpでダンプファイルを取得して、新しいAzure Database サービスにリストアする方法です。 新しくデータベースを立ち上げ、コマンドベースやGUIの管理ツールでリストアして利用します。 こちらのメリットは、やはり今までとやり方が変わらない、というところでしょうか。 次に、Attunity というデータベースレプリケーションソリューションを利用する方法です。 本来有償のソリューションなのですが、Attunity社とMicrosoftでパートナーシップを組み、 Microsoftの製品へのマイグレーションに関してのみライセンスを無償提供するプログラムが現在ございますので、こちらを使用して移行することも可能です。 最後にリードオンリーレプリカを利用する方法です。現在可動しているシステムのレプリカをAzure上に構築し、Azure上のデータベースをマスターに昇格させて移行する方法です。 AzureのMySQL同士でのリードオンリーレプリカは現在Private Previewのステータスとなっております。 様々なマイグレーション方法がございますので、システム要件にあった方法をご活用頂き、是非Azure Database for MySQL / PostgreSQLをご利用頂ければと思います。 Attunity Replicateは、データベース、DWH、Hadoopなどの異なるソース/ターゲット間において、高速で簡単なリアルタイム・データ・レプリケーションを可能にするソリューションです。Time-to-Value (価値が生み出される時間)を短縮し、ビジネス・ニーズに最適化したデータ分析処理・分析基盤の構築を支援します。ビッグデータ時代といわれる今、企業は既存の情報資産を分析し、新たな価値を発見し、新しいビジネスをスタートさせるチャンスと言われています。データレプリケーション製品、Attunity Replicateはそんなデータ分析をスタートさせるための特効薬です。データベースに眠る既存の情報資産をクリック操作だけで、リアルタイムで、データウェアハウスに転送する事ができ、すぐにデータ分析を開始する事が可能です。 A free license of Attunity Replicate for Microsoft Migrations is provided for 12 months, to allow each migration. Customers requiring extended migration periods and additional data sources can purchase such licenses directly from Attunity.
• #21: Azure Database for MySQL / PostgreSQLに関しては既存のツールを使って接続できるので、新しい技術を学ぶ必要はないので、学習コストはかかりません。 あえて学ぶ部分があるとしたらAzureポータル上でポチポチとクリックしてデータベースを作る部分でしょうか。
• #22: Azure Web Appsという、AzureのウェブアプリケーションをホストするPaaSサービスがあるのですが、そのサービスとも非常に相性がいいです。 MySQLは、特にWebアプリケーションで利用されることが多いかと思うのですが、 Azure DB for MySQLは同じPaaSサービスであるWeb AppsのDBプロバイダーとしても利用が可能です。 Web Appsは、PHPなどの言語で作ったアプリケーションをFTPやgitを通じてデプロイするだけで動作するので、 データベースが必要な場合はアプリケーションの接続先をAzure Database for MySQLにしてあげるだけでOKです。
• #23: Web App と Azure Database for MySQL / PostgreSQLは、両方のサービスを一気にデプロイすることが可能です。
• #24: Azure Cloud Shellという、ブラウザ上からシェルを動作させることができるサービスがあるのですが、 そこからmysqlコマンドを使って接続することも可能です。 自社内からデータベースにアクセスする場合、自社のグローバルIPをファイアウォールに登録しなければいけませんが、 こちらはAzureのサービスなので、Azure内のサービスからのアクセスを可能にするだけでMySQLコマンドを使ってアクセスすることが可能になるので、 無駄にファイアウォールを開ける必要がなくなり、少しだけでもセキュリティレベルを高く保つことが可能です。 こちらは実際に見て頂ければと思います。
• #25: MySQLではInnoDBのみサポート、MyISAMは未サポート 先程メモリの容量は非公開ということをお伝えしましたが、InnoDBバッファープールに関しては、価格レベルやvCoreの数で関連付けされています。 この資料は後ほどお渡ししますので、どのようなパラメーターがサポートされているかはご確認頂ければと思います。 以下は未サポート 項目 内容 Basic レベルの innodb_file_per_table OFF innodb_flush_log_at_trx_commit 1 sync_binlog 1 innodb_log_file_size 512 MB
• #26: メモリに関するパラメーターである、shared_bufferなどは設定できません。
• #28: 本資料はお送りしますので、MySQLやPostgreSQLのパラメーターに関してどんなパラメーターがサポートしているのかご確認頂けたらと思いますが、 このパラメーターはないの？などがあるかと思います。また、こんな機能があったら嬉しいのに。。。というものもあるかと思います。 そんなときは、是非フィードバックをお願いします。また、この機能がほしい！というものは既に挙げられているかもしれませんので、それを見かけたときはvoteを押していただけたらと思います。 マイクロソフトはお客様の声を聴いて機能をどんどん改善していっておりますので、是非このフィードバックのページをご覧いただけたらと思います。 少しどんなフィードバックが来ているか見てみましょう。
• #30: 改めてメリットに関してまとめです。 大きくわけて4つあります。 まず運用負荷軽減についてです。Azure SQL Databaseという、Azureサービス開始時から動いている実績ある基盤の上で動いていて、そのあたりは信頼して頂ければと思います。 パッチ適用やバックアップに関して特に手を動かすことはありませんし、監視設定もどのメトリックを選んでどこにメール送信する？などを選ぶだけでOKです。 高可用性については、まず可用性が組み込まれていて、可用性のために追加の料金を払う必要はありません。 また、アプリケーション側で再接続のロジックを組む必要はありますが、スケールアップやスケールダウンを自在に行うことができますし、もしも障害があったとしても自動でフェールオーバーされる仕組みになっています。 セキュリティに関しては、Azureのサービス自体が色んなセキュリティ関連のコンプライアンス認証を受けております。 また、通信はSSLで暗号化されていますし、データが保存されるストレージ自体が暗号化されています。接続可能なIPアドレスをホワイトリスト形式で設定をして、セキュリティレベルを高めることができます。 最後に利便性として、こちらは今まで通りの使い方でMySQL やPostgreSQLを使えます。 データベースはコミュニティ版を使っていますし、マイクロソフトが独自に改造をしていることもなく、何か特別なドライバやツールが必要といったところはありません。 このように、PaaSのメリットをそのまま受けてデータベースを使用できるのがAzure Database for MySQL / PostgreSQLの特徴です。
• #31: 最初にお伝えしましたが、最後に改めて本セッションのポイント2つになります。 いかがでしたでしょうか、こちらのポイントがご理解いただけましたでしょうか。是非、Azure Database for MySQL / PostgreSQLをご利用頂き、このポイントを体感して頂ければと思います。