10/1に、ServerlessConf 出店ブース始め、会場におられる方も、AWSを利用されている方がほとんどだった様子だったので、講演では、AWSを普段使っておられる方を想定して、お話しをしました。ただ、盛り上がった一方、詳細なアーキテクチャが知りたかったとか、AWSのλとの違いがわからなかったというご意見をいただきましたので、そういうフォローアップ記事を書いてみようと思いました。
個人的には、Serverless は、Microservicesの次のパラダイムぐらいの勢いがありますが、どのような利用がされているかのアイデアとその未来を知りたくて参加しました。ちなみに、スポンサーセッションと思われていますが、一応、スポンサーセッションではなく、サブミッションを出しています。本イベントは、非常に熱気があり、学びも多く、素晴らしいイベントでした。こんなにも素晴らしいイベントをこんなにも早く日本でも開催いただいた、主催の吉田さんに本当に感謝です!
では、早速、AWSな人に贈る Azure のServerless のお話し、そして最後に、私が感じたServerless の未来についてお話ししてみたいと思います。
1. 講演概要
講演の概要は、9/26-30 まさに直前に行われたMicrosoft Igniteでの発表の資料を中心に、いくつかのデモを加えて行われたものです。講演資料はこちらになります。講演資料は、当日、日本人と海外の方が両方おられたので、英語の資料で、日本語で講演というスタイルにしました。
2. Azure Functions (AWSのλっぽいもの)
Azureでの、Serverless のサービスは、Azure Functions というサービスです。一緒に講演した、佐藤(NEO)直生さんが、当日早速 Getting Started 等のURLを整理したブログを書いてくれたので共有したいと思います。
[ServerlessConf Tokyo] Serverless Patterns with Azure Functions (Azure Functionsでのサーバーレス パターン)satonaoki.wordpress.com
このサービスは、元々 Azure で使われていた、WebJobs という仕組みが元になっています。何らかのトリガーをきっかけに、バッチ等 の小さなプログラムを動かすこの仕組みは、Serverless のAzure Functions を動作させるためには最適な仕組みでした。
AWS のλに相当する Azure Functions は Azure の PaaS 基盤である App Service の上に構築された仕組みで、Web Appsをはじめとした、例えばWebのPaaSを使っていれば、そこにサーバーを新たに建てることなく、バッチを実行することができました。 そして、C#はもちろんの事、様々な言語で動作します。中身は現在のところ、Windowsサーバーがベースとなった、Windowsの技術がバックグラウンドにあります。ただ、このWebJobsを創るためには、そこまで大変ではありませんが、ちょっとめんどくさい部分があったのは事実でした。
2.1. トリガ
Azure Functions では、Severless を実現するため、この仕組みをつかって、そもそもの Web Appsすらも起動することなくこのサービスを利用可能にしました。想定するシナリオとしては
- Timer
- Data Processing
- Webhook + API
それに加えて、Blobストレージ(S3相当)へファイルをアップロードする、Queueにメッセージを投げるなどのきっかけを元に、プログラムを実行します。結果は、Blob(S3相当)、HTTP, ServiceBus (SQS相当)、データベース、通知のハブや、SendGrid, Twilio へのサポートをテンプレートレベルでサポートしており、他のものも自分でコードを書けば何とでもなります。
2.2. インプット / アウトプット
インプット、アウトプットのリソースとしては、様々なサービス、プロトコルと連携します。下記の図がわかりやすいと思います。
Azure Functions の画面では次のようなイメージでインプット、アウトプットを設定できますし、設定ファイルでももちろん設定できます。
2.3. 言語
使用できる言語は、C#, Node.js, F#, Python, PHP, 等、、、と書いています。他にもBashや、Cmd、PowerShell等も動作するみたいですし、私の同僚は、Goを動かすものを書いていました。
2.4. プログラム構成
これはC#の例ですが、下記のようなプログラム構成になっており、run.csxがC#のファイルです。function.json が設定ファイル。そしてproject.json は、nugetパッケージ（npm や、Ruby gemsの様なもの)を取得するために使えるファイルです。
function.json
{
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "pictures",
"connection": "pooryou_STORAGE"
}
],
"disabled": false
}
project.json
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.ProjectOxford.Face": "1.2.1.2"
}
}
}
}
今回私がデモで使用したソースコードは、簡単ですが、GitHubにあげておきました。より細かい情報は、佐藤さんがPowerPointの資料に書いてくれています。より細かいプログラム構造(nodeの場合)、使える言語、トリガの種類などです。
2.5. AWS λと比較したメリット
ブースにいるときにAWSを普段使っておられる方から、「ここはAzureのほうがいいね！」と言っていただいたポイントがいくつかあったので、それを共有しておきたいと思います。私も深くAWSの事を知っているわけではありませんが、あくまでブースに来ていただいた人から学んだことですので、細かいミスなどはご容赦ください。また、そういうものがあれば本ブログをリンクして是非皆様のブログでフォローしていただければと思います。
これは個人的な意見ですが、ざっくりうと「すべてをコントロールしたい人は AWS」、「レールに乗って楽したい人は Azure」というイメージを持っています。 もちろん、Azure でも、Linux/Windows の IaaSとかは使えますが、Azureの面白さはやっぱり、PaaSや、SaaSだと思います。またこの辺りは別のポストでお話ししてみたいので、割愛します。
Azure Functionsに絞ると、ざっくりいうと次の通りです。
2.5.1. わかりやすい GUI
統一されたわかりやすい GUIは、Azure の良さの一つです。 Azure Functions の場合は、結構 Azure で操作する、エディタがなかなかイケています。なぜなら、このエディタはかのエリック・ガンマが作成した、Visual Studio Online の技術が使われているからです。彼もマイクロソフトの一員です。結構これだけでも、自分的にはうれしい！
2.5.2. 様々なトリガ・イベント
Serverless の選定要素の一つを現在実現されているもののみで考えると、どれぐらいいろいろな、トリガや言語に対応しているか？というのがキーになると思います。Azure Functions では、Blob(S3相当), Timer, IoT/EventHub, Webhook, http, Queue(SQS相当), SaaS SendGrit, ServiceBus等のトリガに対して、C#, Node, Bash, PowerShell, Python, PHP等多くの言語に対応しています。
2.5.3. プログラム構造の透明化
λでは、サーバレスのコードを書くとそれが、どういう形で格納されているかわかりません。一方 Azure Functions では、先に説明 した通り、構造が明確であり、サーバーレスですので、しばらくしたら寝てしまいますが、サーバーぽいものの中にどのように格納されている かが、KUDOというツールで見ることができます。また、パッケージマネージャ(npm, nuget)等も、使えるというのも利点です。
2.5.4. デバッグ機能の充実
デバッグも先のKUDUを使ってログを見たり、コマンドをたたいてみたりということができて大変便利です。
2.5.5. Azure の機能との連携
これはあまり比較のメリットではありませんが、Serverless の場合、いかに楽にnano serviceを書けるのががポイントになると思います。そのケースで、Azure はいろんなサービスがあり、Azure Functions と連携しているのでこれはラクチンです。
2.5.6. API Gateway不要
AWSのAPI Gateway に相当する httpのトリガが用意されていますので、API Gatewayの様なものを設置する必要がありません。つまりそこに課金もされません。
もちろん、λの利点もあると思いますので、このようなメリットデメリットを考慮して皆様の環境で便利なほうを是非ご利用ください！先行されておられるAWSさんと比較してもなかなかのものですね。(2016/10/3時点の情報)
ちなみに、ブースの会場で、AWSの方と話したのですが、「競合とかなんとかいうより、Cloudをもっと多くの人に使ってほしいですよね」という素敵な話されていて、本当にその通りだなと思いました。DevOps もそうですが、競合とかそんなパイを食い合うようなセコい話ではなくて、もっと多くの人がCloudを使うようになれば、みんなHappyになってくると思います。
3．デモンストレーション
当日じっくり解説する時間がなかったので、こちらのデモの内容とコードを公開しておこうと思います。このデモは、Unityと、Cognitive Service という、マイクロソフトのAIの研究の成果を使ったAPIサービスを利用しています。
弊社の藤本氏が作成した、Interactive いちゃLoveゲームというUnityで作られたゲームが元になっています。このゲームは、Cognitive Service のEmotion APIという人の顔の感情を読み取るAPIを使っています。ゲームをやっている人の感情に合わせてゲームの反応を変えるというデモンストレーションです。スペースバーを押すと、PCのカメラで画像を撮り、それを、Emotion APIにRESTベースで送付して感情分析をして、キャラクターの振る舞いを変更しています。 キャラクターデザインと、ボイスは、ちょまどさんが担当しています。
この面白いゲームの詳細を知りたい人は、次のブログポストで説明されています。
私の方では、このゲームに対して、プレイヤーの属性を分析したいと思ったので、写真を撮った後に、それをBlobストレージ(S3相当)にアップし、それをトリガーに、Azure Functions(λ相当) を起動しています。Functionsで、Cognitive ServiceのFace APIをコールして、プレイヤーの年齢、感情、顔の輪郭、ひげの位置などの情報を分析して、それをSQLサーバーに送付しています。このFACEAPIを使うと、社員をいくつか覚えさせると、その人かどうかの判別を行うこともできます。 最後に、PowerBIというBIサービスにその情報を連携させて、分析を行うというデモでした。実際に、Serverless アーキテクチャを使うと、簡単に実装できたのでとても楽しかったです。パターンとしては、ある意味王道的な使い方ですが、本当にさっくり作ることができました。これは楽です！
ご興味がある方は、ソースコードを置いておきましたので、ご参照ください。実は佐藤さんは、更に凄いCognitive Service を使い倒したデモを用意していましたが、時間の関係でお見せできませんでした。
4. Azure の関連情報
さて、AWSを使ったままでも使える、Cognitive Service 等の情報を共有しておきたいと思います。 Cognitive Service に関してはエバンジェリストの大森彩子さんがいい資料をたくさん作ってくれています。紹介したもの以外にも動画をリアルタイムに解析したり、画像/文章の感情分析したり、言語解析したり、翻訳したりとむっちゃ凄いサービスになっているので、個人的にも熱いサービスですが、REST-APIを呼ぶだけなので簡単に使えます。 次のような情報が日本語でもあるようです。
1. Cognitive Services の機能紹介などは MSDN Blog
2. 実装方法など具体的な手順、コードなどは Qiita
3. 説明資料 (PPT)
最初のステップとしては、以下の記事がおすすめです。
a. Cognitive Service でできることをざっと知りたい人向け (from ①)
「人間にとって “自然な” アクションの実装 ～ Microsoft Cognitive Services を始める前に」
b. エンジニアで実際にコード書いて理解したい人向け (from ②)
「人工知能パーツ Microsoft Cognitive Services を使った表情分析アプリを作ろう！」 Emotion API × JavaScript 編
Emotion API × Bot Framework (C#)編 qiita.com
Azure Functions のサンプル等
真壁さんがこんなサンプルとその解説を書いてくれています！
Azure Functionsで運用管理サーバレス生活(使用量データ取得編) · re-imagine
まだ仕掛ですがこんなものもある様子
もちろん、プレゼンテーション資料にもたくさんリンクをつけていますので、Azure Functions 自体の資料もお楽しみください。
5. Serverless に感じる未来
マーチンファウラー氏の、Serverless アーキテクチャで有名なサーバーレスですが、日本語では、会場にも来てブースをサポートしてくれていたデプロイ王子こと廣瀬一海さんの記事が私はわかりやすくて好きです。
今回のサーバーレスカンファレンスでも、いろいろ面白い事例や使い方が出てきてとても面白かったのですが、Nano Serviceという言葉もある通り、マイクロサービスとのつながりもとても強く感じました。
個人的な意見では、現在マイクロサービスの環境がたくさん出ています。例えば、DC/OSは、データセンタOSと呼ばれて、クラスタ自体をまるで１台のサーバーかのように扱い、リソースのアロケーションをしてくれたりします。大変未来的で私は大好きなプラットフォームですが、残念ながら現時点では、せっかくリソースを最適化してくれていますが、使わなくても、使っても、VMを上げておく必要があります。 デプロイ後もVMの存在を意識する必要があります。
現在のアーキテクチャでいうと、IaaS, Container, PaaS, Serverless の順番にどんどんやることが減っており、よりプログラムに集中できる環境ができています。ただ、現時点では、Serverless は、サーバーを立てるまでもないものや、グルーコード、イベントの処理などの簡単なもに対するユースケースがうまく行きそうです。
しかし、ちょっと先の未来を見ていくと、DC/OSみたいなサービスは本来、VMの存在は忘れてリソース配置をしてくれるものだと思いますし、PaaSもできれば、VMの境目を意識しなくていいような状態になったとしたら、凄く楽で便利な世界が広がると思います。 つまり、それは思いっきりサーバーレスの世界で、サーバーレスで出来ることが、PaaSと、現時点でのサーバーレスで出来ることの間が縮まって、PaaSと見分けがつかなくなるときに、本当にサーバーレスの凄い世界がやってくる気がします。しかも、それは、たぶん数年とかからない気がします。私が知らないだけですでにそういうものが存在するかもしれませんが。
また、Ito Naoya さんのパネルもすごく面白いお話しでしたが、最後に、「この事例は、本当は、Actorを使うとうまくいくと思う」という話をされておられました。個人的に、マイクロソフトの出しているものでも最もホットなものとして、Service Fabricというのがあります。 これ激アツです。これは、マイクロサービスのPaaSというとんでもないもので、もともと、Azureの各種サービスに使われていた基盤を公開したものです。Stateless/Stateful のサービス、そして、Actorをホストしてくれます。Stateful / Actor に関しては、デプロイするとサーバーに対して、レプリカを自動で組んでくれて、VMがダウンしたとしても、メモリを共有しているので、処理がそのまま継続して実行されたります。つまり、Netflixさんがやっているような、カオスモンキーを使うようなFault Injectionをぶちかませる基盤が最初から手に入る感じです。実際に、Service Fabric には、そのようなChaos Testing のAPIが最初から組み込まれています。
そして、Actorをガンガンにサポートしています。次のゲームとかを見ると基盤の凄さが伝わるかもしれません。余談ですが熱くなってしまいました。
このように、Azure も個人的には激熱なテクノロジーがたくさんあって、むっちゃ楽しいです。是非皆さんもよかったら楽しんでくださいね！
最後に
主催の吉田さんが、世界に向けて、日本のServerlessの盛り上がりを記事にされておられます。素晴らしいです！
これは単に宣伝ですが、Azure が気になる方はこんなイベントもあります！