Microsoft Build 2017 のキーノートで発表のあった MySQL / PostgreSQL 関連の発表をざっくりと
Microsoft が MySQL/PostgreSQL のマネージドサービスを始めます
内部的にはずっと前から取り組みがされていて、多くの新規 Azure ユーザから望まれていた一方なかなか出てこなかった MySQL/PostgreSQL のマネージドサービスがいよいよ出てきました。 azure.microsoft.com azure.microsoft.com 何年も待ったわ～ほんとに。。。
これまでの MySQL/PostgreSQL マネージドサービスの課題
各種クラウドにあるサービスには大きく2つの課題があったと思います
“インスタンス” というサイジング
どのサービスも基本的に “仮想マシン” 単位で要求性能とキャパシティを決めて、そこにセットアップの自動化とバックアップ、そして別インスタンスへのフェイルオーバーを提供するものでした。 仮想マシンでのプロビジョニングはこれまでの運用感覚からいうと分かりやすい一方、仮想マシンへの手入れができないのでその点は諦める必要があるところがありました。
“ダウンタイム” のトレードオフ
障害発生時のフェイルオーバーが発生した場合、他のサービスではDNSによるフェイルオーバーだったりして、クライアント側が接続について考慮する必要がありました。 スケールアップのための操作には、シャットダウンが必要であり、これもサービスを一度メンテナンスモードにするなどのダウンタイムの考慮が必要でした。 また、MHAを使っている人がやるようなダウンタイムなしの運用を求めると、仮想マシンを使わざるを得なくなります。
Azure Database for MySQL/PostgreSQL の特徴
“コンピュートユニット” と “ストレージユニット” というサイジング
Azure Database for MySQL/PostgreSQL は、インスタンスという概念が存在しません。
“どの程度のCPUとメモリを利用するか” という、所望のワークロードに合わせたプランを選択することになります。
実際に Azure Portal からサービスを受けようとすると
このように、処理量と要求ストレージをスライダーで設定する形になります。
Preview 中はこの変更に制限があるようですが、GA までにはこの設定変更が任意のタイミングに(運用中であっても変更可能!)できるようになるはずです。
docs.microsoft.com ここにざっくりとした解説がありますが、もっと詳しいリソースガバナンスについてはいずれ MySQL Casual などで話をしたいと思います。
Azure SQL Databaseと同様のダウンタイム
こうなると当然気になってくるのが “ユニット変更したときの挙動はどうなるの？” という点だと思います。 Azure Database for MySQL/PostgreSQL の挙動を知るには、Azure SQL Database の仕組みを知ることが近道です。 Azure SQL Database がどういう挙動をするかは docs.microsoft.com このドキュメントにありますが “average under 4 seconds, and in more than 99% of cases is less than 30 seconds.” が示す通り、基本的にこのダウンタイムでスケールアップ/スケールダウン、フェイルオーバーが行われます。 この特徴は MySQL/PostgreSQL のサービスにも引き継がれており、 docs.microsoft.com こちらにも全く同様の記述があります。
この仕組みについてもいずれ詳しく MySQL Casual などで話をしたいと思います。
Azure SQL Database for MySQL/PostgreSQL がより良くワークするユースケース
Movable TypeやWordpressなどのCMSやEC-Cubeなどのソフトウェアパッケージとの組み合わせ
普段のワークロードはそれほど高くないが、柔軟かつダウンタイムを短く運営したいという受託の多いWeb開発企業にとって、サービスをほぼ止めずに切り替えができるデータベースサービスは有利に働くと思います。
たくさんのDB/スキーマを管理しなければならないSaaS企業
SaaSの構築パターンとして、アプリは共通だがDB/スキーマを分ける運用をしている会社さんは多いのではないかと思います。 そういったサービスでありがちなのが、特定顧客のマスターだけ負荷が上がり始めるなど、ワークロードの偏りです。 そういう時に、ダウンタイムがより短くスケールアップできる選択肢があると、サービス運営にかかる負担を下げられるのではないでしょうか。
おわりに
Previewが始まったばかりなので、まだまだこれからですが、ついにMicrosoftがSQL Server以外のRDBMSを正式にサポートするということは大きな変化だと思います。 ご関心のある方はぜひ触ってみて、フィードバックを送ってください。
(General Feedback): New (2470 ideas) – Customer Feedback for Microsoft Azure
では。
※追記
キーノートの後のセッションで、ローンチ時点から日本リージョン(Japan East/Japan West両方!)で展開されることが発表されました。これで皆さん安心して(?)お試しいただけますね！
ISUCON6参加者が実践したInfrastructure as CodeあるいはISUCON6のAzureインフラ解説
ISUCON6予選参加者の皆様、お疲れさまでした。
今回の ISUCON は Microsoft Azure ということで、多くの方にとってなじみのない環境だったと思います。
そこで、今回の ISUCON6 の予選問題がどのような仕組みで展開されているのか、Azure IaaSの仕組みを交えて解説します。
はじめに
@matsuuさんの多大な努力によって、運営に提案しようと思っていた構成の大半がすでに作られていました。
使ったことのないクラウドを触り始めてすぐに作り上げてしまうのは、さすがです！
復習される際はぜひ、@matsuuさんの作ったテンプレートを活用するとよいでしょう。
Azure IaaSの概要
Azureはおおむね国ごとにジオという単位で分けられており、その中に2つ以上のリージョンを持っています。
リージョンはそれぞれペアになるものが存在していて、日本では東日本と西日本がそれぞれペアリージョンになります。
そして、リージョンの中には複数のデータセンターが存在するという構成です。
データセンター内では、物理サーバの配置を"クラスター"という単位で配置しています。
クラスターは同種のハードウェアの集まりで、例えばXeon E5-2673 v3の乗った10G NICのサーバなど、スペックが統一されたものです。
ユーザが仮想マシンを起動すると、裏側では "ファブリックコントローラ" と呼ばれるものが、その仮想マシンをどのクラスターに配備するかを決定します。
仮想マシンをファブリックコントローラが配備することを "デプロイメント" と呼び、これは一つのクラスターを対象に配備が行われます。デプロイメントはクラスターを跨ぐことはありません。
デプロイメントは、リソースマネージャーモデルの仮想マシンであれば、後述の "可用性セット" 単位で1つのデプロイメントとして扱われます。
これは管理画面にも一切出てこないもので。通常ユーザはこのクラスターを意識することはありません。
ユーザがクラスターを意識するタイミングがあるとすれば、インスタンスタイプ変更の時です。
クラスターは "同一スペックのサーバの集合である" と説明した通り、インスタンスタイプの変更はこのクラスターの範囲の中で行うことになります。
ですので、最初にAシリーズなどの古めのスペックのインスタンスタイプで仮想マシンを作ると、古いクラスターに着地することになり、その後Dシリーズへ変更するにはVMを一度削除する必要があります。
クラスター内部の構造
クラスター内部では "障害ドメイン" という単位で電源やネットワーク機器が配置されていて、これらの装置の障害がほかの障害ドメインに影響を及ぼさないように設計されています。ひとつのクラスターは、数十の障害ドメインで構成されています。
先に少し触れた "可用性セット" ですが、仮想マシンのメニューにそういうものがある事に気付いた人もいるかと思います。
これは、複数の仮想マシンを同一の可用性セットに入れると、最大で3つの障害ドメインに分散配置されるようになるものです。
Azureの各種サービスはこれらの基盤の上に成立しています。
Azureにおけるリソース管理の概念
ISUCON6予選では "Deploy to Azure" ボタンを押して "リソースグループ" を作成し、その中に仮想マシンやネットワーク、予約済みIPといった "リソース" を展開しました。
Azureにおけるリソース管理はこの "リソースグループ" という単位で複数のリソースを行うのが基本です。
Azureにおいては全てのものがリソースであり、必ずどこかのリソースグループに属します。
リソースグループは図にある通り、リージョンを超えて広げることができます。もちろん海外のリージョンでもOKです。
リソースへのアクセス制御は、リソース、リソースグループごとにアクセス制御(IAM)で設定をすることができます。
これとは別に、タグも存在しています。タグはリソースに対して "キー = 値" 形式で付与することができます。
例えば "所属プロジェクトAに属するリソースグループ" とか "本番環境である" とか、そういった分類をするときに利用します。
ISUCON6予選で皆さんが行った "Deploy to Azure" の仕組み
Azureではリソースを宣言型のテンプレートを用いて管理しています。
ポータル画面から何かのリソースを作った場合、裏側ではすべてテンプレート定義として生成され、管理されています。
逆に言うと、独自のテンプレートを定義して、それを読み込ませることも可能ということです。
今回のISUCON6予選ではこの手法を用いて、運営の用意したテンプレートを各自のAzureアカウント内へサーバ環境をデプロイする手法を取りました。
下記が、そのテンプレートの基本構成です
{ "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "", "parameters": { }, "variables": { }, "resources": [ ], "outputs": { } }
テンプレートの要素詳細はドキュメントを見ていただくとして、定義の中で特に重要なのが resouces セクションです。
resouces セクションでは、作成若しくは更新されるリソースを定義します。と、書いてもわかりにくいと思うので、実際の仮想マシンの定義内容を見ていきましょう。
{ "type": "Microsoft.Compute/virtualMachines", "name": "[parameters('vmName')]", "apiVersion": "2015-06-15", "location": "[variables('location')]", "tags": {}, "properties": { "hardwareProfile": { "vmSize": "Standard_D2_v2" }, "storageProfile": { "imageReference": { "publisher": "Canonical", "offer": "UbuntuServer", "sku": "16.04.0-LTS", "version": "latest" }, "osDisk": { "name": "[concat(parameters('vmName'), '-os')]", "createOption": "FromImage", "vhd": { "uri": "[concat('https', '://', variables('storageAccountsName'), '.blob.core.windows.net', '/', variables('commonName'), '/', parameters('vmName'), '-os.vhd')]" }, "caching": "None" } }, "osProfile": { "computerName": "[parameters('vmName')]", "adminUsername": "[variables('adminUsername')]", "customData": "BASE64Encoded-userdata", "linuxConfiguration": { "disablePasswordAuthentication": true, "ssh": { "publicKeys": [ { "path": "[concat('/home/', variables('adminUsername'), '/.ssh/authorized_keys')]", "keyData": "[parameters('sshPublicKey')]" } ] } }, "secrets": [] }, "networkProfile": { "networkInterfaces": [ { "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]" } ] } }, "resources": [], "dependsOn": [ "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountsName'))]", "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]" ] },
"type": "Microsoft.Compute/virtualMachines" 部が仮想マシンを表す記述です。Azureで提供されているtypeはCLIの "azure provider list" コマンドで確認することができます。
"name": "[parameters('vmName')]" 部はその名の通りこのリソースの名前を定義する部分です。parametersは運営の用意したテンプレートにあるparametersセクションに記述されたものを指定しています。
locationはvariablesセクションにある "location": "[resourceGroup().location]" という記述の通り、そのリソースグループが定義されたロケーションに合わせる設定になっています。
"properties" で、それぞれのtypeが要求する属性を指定していきます、仮想マシンの場合は "仮想マシンタイプ" "ストレージ設定" "OSプロファイル" "ネットワーク設定" "依存しているリソース" が主に設定を必要とする項目です。
この定義で仮想マシンが立ち上がるわけですが、実際のプロビジョニングは別に走ります。その指定をしているのが "osProfile" -> "customeData" です。
ここにBASE64エンコードしたスクリプト(今回はbashスクリプト)を書いておくことで、起動後にcloud-initによってプロビジョニングする形です。
#!/bin/sh # init script for isucon6-qualifier set -ex export DEBIAN_FRONTEND=noninteractive apt update apt install -y --no-install-recommends ansible git aptitude apt remove -y snapd cd /tmp && wget -O- https://isucon6qimage.blob.core.windows.net/isucon6q/isucon6-qualifier.tar.gz | tar zxvf - cd /tmp/isucon6-qualifier/provisioning/image/ansible PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ansible-playbook -i localhost, *.yml --connection=local -t prod cd /tmp/isucon6-qualifier/provisioning/image ./db_setup.sh cd /tmp && rm -rf /tmp/isucon6-qualifier && rm -rf /tmp/ansible-tmp-* shutdown -r now
こういうJSONを書く時に、どういう構成になっているか視覚的に見られる方が良いでしょう。そんな時はARMVIZを使うと、図のようにどんな構成になっているかを可視化できますので、Azureでインフラ構築をする際にはぜひ活用してみてください。
作成したJSONは、どこかパブリックな場所に置いて https://portal.azure.com/#create/Microsoft.Template/uri/ にエスケープしたURLを渡すか、Azureポータル管理画面の "テンプレートのデプロイ" から投入することもできます。
他にはAzure CLIのコマンド "azure group deployment create -f
今自分が使っている環境の設定がどうなっているかを見たい、という場合 https://resources.azure.com/ にアクセスすると、閲覧可能なサブスクリプション配下の設定状況を見ることができるので、一度見てみると良いでしょう。
うぇー結局JSONかよめんどくせ〜と思ったあなたへ
AzureといえばMicrosoftが提供しているわけですが、MicrosoftといえばVSCodeも提供しているわけでして、このテンプレートもVSCodeで書くことができます。
azure.microsoft.com
このページに書いてある通り、"ext install azurerm-vscode-tools" すれば、補完を効かせて記述することができます。
VSCodeにはTerminalが統合されているので、そのまま "azure group deployment create -f
ひとりじゃなくてみんなで使うためのgolangの本 "みんなのGo言語"
9/9(金)発売の "みんなのGo言語" を Daisuke Maki (@lestrrat) | Twitter さんから頂戴しまして、一足先に読むことができました。感謝を込めて感想を書かせていただきます。
みんなのGo言語[現場で使える実践テクニック]：書籍案内｜技術評論社
本書のカバー範囲と対象読者
本書はいわゆる "これからGoを始めたい" 人向けの本ではありません。 A Tour of Go でできるような最初のイロハはカバーされていません。 すでにGoを多少触り始めていて、一人だけで書くのではなく、周りの同僚や仲間など複数の人間が関わる環境でどのようにGoを活用していくべきかの指針をまとめたものと捉えると良いでしょう。 もちろんこれから始めたいという人に対して役に立たないわけではありませんので、特にチーム開発運用にGoを取り入れたいと考えている方には得られるものが多くちりばめられていると思います。
一通り読んだ所感
前述の通り、本書は第1章から "チーム開発" という言葉が出てくる通り、個人がひっそり写経するものではなく、多くの人どうしでGoを使った開発をしていくために "チーム開発の始め方" "マルチプラットフォーム対応" "実際のアプリ/CLIツール開発の実践" "テスト" "ハック的な黒魔術" まで幅広くテーマを扱っているので、広い視野を持って読むとより著者たちがこれまでの実運用でどのようなことを考えてGoを使ってきたか見えてくるのではないでしょうか。 特に3章はバージョン管理からチューニングまでをカバー範囲としてまとめられており、また、6章では長く運用を続けていくために必要なテストの手法が実践的にまとめられています。 私は普段、仕事でGoを書く立場ではありませんが、もし使う機会があればこの書籍を片手に実践していこうと思います。
おわりに
"みんなのGo言語" はその書籍名の通り、ひとりではなくみんなで使うときにどのように対応していけば良いか、著者一同の実践ノウハウが詰まっています。 著者一同が実践してきた内容や良いとされていることを一通り押さえており、ページ数も多すぎないので気軽に読むことができます。
もしあなたが "なんとなく気になってるんだけどどうやって使ったら、導入していったらよいだろう" とお悩みの場合は、本書は良いGoライフを得る一助となるでしょう。
最後に重ねまして @lestrrat さん、ありがとうございました。
クラウドを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すための一冊
俺たちのリーダーこと @iara さんが著者に名前を連ねている、Amazon Web Services 実践入門を発売前に頂戴することができたので、御礼を兼ねて感想などをまとめさせていただきます。
本書のカバー範囲と対象読者
本書は入門本と銘打たれている通り、IaaSと一部のマネージドサービスを紹介しつつ、UIとCLI両方での操作がまとめられています。
オンラインマニュアルにも同様のことは書かれているわけですが、本書では実際に手を動かしてみるにはこうしましょう、という切り口でまとめられているので "クラウドをこれから使いたい、でもどうやって触ったらいいかわからない" という人がまず写経的にやってみるのに適していると感じました。
他にも、 "今AWS使っているんだけどUIからポチポチとやっているだけだよ" という方がもう一歩深い使い方を学んでいくというところでも役立つと思います。
そういった側面が強いため、手順をまとめたマニュアル集といった趣になっており、事例や深く突っ込んだ使用法については言及されていません。
読んだ所感
リーダーの書いた5章を読んだ時に、"最近はむしろこういうネットワーク設計とかしなくなってきたな" と思ったところが気づきというか振り返りがありました。
従来のクラウド活用は、物理サーバとネットワークの設計をクラウドに持ち込んで再現するといった向きが多かったと思います。
自分自身がいち技術者としてクラウドを触り始めたのはIaaSであり、やはりそういった "既存技術をうまくIaaSに合わせていく" アプローチで作っていました。
最近のクラウド利用はそのようなVMを並べるところから徐々に、PaaS/SaaSを組み合わせてサービスを作る流れになってきています。サーバーレスアーキテクチャとか言われているようなやつですね。
PaaS自体はSalesforceやGoogleのApp Engineに代表されるようなサービスが既に7年前くらいにはあったわけですが、その利点が広く取り沙汰されるようになってきたのはここ1〜2年かなと。
"as a Service" をうまく組み合わせてサービスを作る際には、IaaSでやっていたようなネットワーク設計は(PaaS/SaaSの陰に隠れて見えなくなり)利用者が考慮する必要がなくなるわけです。
とは言え "我々はクラウドフリーで常にVMと仮想ネットワークしか使いません" という主義の会社もあれば、"うちではas a Serviceをうまく組み合わせる人のことをインフラエンジニアって呼ぶよ" という会社もあるので、すぐに見えなくなるものでもないし、ましてネットワークの技術自体が無くなることはあり得ないのだけれど、うっかりすると触れる機会がどんどん少なくなっていくものになるなと。
そういった流れの良し悪しについては色々な言説ありますが、何を選べばよいかを判断できるような人材になったほうが、著者の言う "もっと生産的で有用な時間を確保できる" ようになると考えます。
おわりに
"Amazon Web Services実践入門" はAWSを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すのにちょうど良いでしょう。
今の時代、"How"はAWSに限らず掃いて捨てるほど存在しているので、適切に選びとってサービスを作っていけるステップとして本書を使うと有意義だと考えます。
最後に、本書を贈っていただきました @iara さんに感謝申し上げます。ありがとうございました。
JAWS-UG Meguro #2 で "今更聞けないストリーム処理のあれとかこれ" というLTをしました。
最近はAzureをよくさわるんですが、AWSも引き続きホットなのでJAWS-UG Meguro #2へ行ってきました。
単に行くだけというのも面白くないので、最近いろいろ調べているストリーム処理回りについて一度整理しておこうということで、基盤と技術選択についての簡単なまとめをLTしたのでここに貼っておきます。
www.slideshare.net
これから始めたい人で、よくわからないけどとにかく始めて何かしら可視化したいという人は引き続き Azure Stream Analytics をお勧めします。
次回テーマは運営のAWS SAの方に希望を言うと良いそうです。
個人的にはAWS上でのネットワーク設計とかいろんな人の話を聞いてみたいかなと思ったりします。
YAPC::Asia 2015でAzureの話をした件とハッカソンの運営をした件
YAPC::Asia 2015 での発表
- Discover the Microsoft Azure と題して、Azureの特徴ある "as a Service" の紹介と、その基盤について入門的な発表をいたしました。
- 以前 "今後は複数のクラウド事業者が提供するサービスを組み合わせて開発する流れが加速する" と書いたかと思いますが、各社特徴あるサービスがどんどん出てきており、かなり選択の幅は広がってきたと思います。
- 今回紹介したPowerBIなんかを試してみたいという方は、下記の記事をご覧いただくのが手っ取り早いかと思います。 qiita.com
ハッカソンの運営
- 2013年にも運営をさせてもらったわけですが、今回はGitHubさんの協力もあって、内容がかなり充実したものになりました。
- YAPC::Asia 本編でトークのあった、Ben OgleさんのElectron話と、mizchiさんの開発話(から発展して逆質疑応答になっていたのは面白い展開でした)
- 普段交流のない人とも交流ができて、いろいろとインプットを得ることができました。
所感
昨年 YAPC::Europe に参加した話をしたところ、今年は日本から8名(‼)参加するとのことで、いい流れだなと思います。 これまでの運営形態でのYAPC::Asiaはいったん終了という話ですが、builderscon.ioの発表もあり、カンファレンスは今後も盛り上がっていくといいなと思いますし、微力ながら協力できることは積極的にしていきたいです。
牧さんをはじめ、スタッフの皆様、とても良いイベントをありがとうございました。 過去最大の会場規模でも平和裏に進んだのは凄いことだと思います。
個人的なハイライト
- SUZURIさんとmotemenさんの発想が完全に一致
Microsoft に入社しました
失業エントリからはや1ヶ月、新しいチャレンジとしてこの5月から Microsoft で働くことにしました。
前職では "どスタートアップ" からいっぱしの上場企業になるまでのサービス基盤をやり遂げることが出来ました。
が、ここ半年ちょい、運用系仕事を減らしていた最中は “開発シフトしていきたい” みたいなことを思ってはいたのですが、失業して時間ができたので改めて振り返ってみて思い直したのは “自分はやはり基盤側の方により興味関心が強い” ということでした。
また、ハウジングの物理基盤から IaaS + SaaS へ移行させる取り組みをして感じたのは “開発技術や運用基盤の選択は生産性と俊敏性をより重視すべき” というものでした。
実際 AWS で EC2 を使っているユーザが BigQuery で集計/分析したりするような事例は沢山出てきており、SaaS, PaaS をウマイこと組み合わせてサービスを構築する流れがますます加速するでしょう。
そういった考えに立つと開発技術から運用基盤であるクラウド、果てはコンテンツ配信基盤まで持っていてサービスライフサイクルのほとんどを受け入れられる Microsoft の動向にひっそり注目するようになっていました。
元々 Microsoft に限らずクラウドの向こう側に興味関心はあったわけですが、たまたま中の人にお話を伺う機会があり、幸いにもオファーをいただけたこともあり飛び込むことにしました。
振り出しは国内でクラウド関連の仕事をすることになりますが、よりパフォームできれば場所にこだわらずにチャレンジしていこうと思っております。
今後ともよろしくお願いします。
あ、肉とか鮨のお誘いは引き続き歓迎いたしております。