AzureではじめるServerless　アーキテクチャ事例と4つのキーテクノロジーを解説 Part2

TypeScriptをサポート

三宅和之氏：個人的にすごくうれしいのが、このTシャツを着ている理由でもあるんですけど、今までもNode.jsでAzure Functionsを作れたんですけれども、TypeScriptが正式利用できるようになって、type-safeな世界でAzure Functionsが書けるようになりました。

今まではやはりC#派の人とNode.js派、僕はNode.js派だったんですけど、そこでどうしても勝てなかったんです。でも、これで正式にTypeScriptでNode.jsのAzure Functionsを書けるようになったことで、もうなんか「違いありますか？」「どっちかというと、こっちのほうが書きやすくないですか？」という（笑）。

わりと個人的にはすごく優位性を感じているぐらい、非常に書きやすいですし、VSCodeと組み合わせたTypeScriptの強力な補完機能で、気持ちよく書けるようになったなって。これはHTTPトリガーですけどね。例えばAPIのペイロードもきっちりtypeで定義して、それが補完されるように実際のコードを書けるようになっているということですね。

あと、Azure FunctionsといえばDurable Functions。

去年のカンファレンスのキーノートでもこの話でけっこう盛り上がっていたのですが、本来FaaSってステートレスじゃないですか。ステートレスのくせにステートフルなワークフローを作れるという不思議なDurable Functionsという機構があるんですけれども、ここに書いている図のパターンが実装できるようになっていて。まあ、ワークフローをコードで書けるということですね。

状態を持てていて、それは永続化されます。なので、それが例えば何か途中でいったん状態を持って処理が休止される場合は、その間は課金をされないというような、わりと優れものなんです。

このDurable Functions自体も2.0に今更新されています。アクターモデルってわかりますかね。アクターモデルを実装したEntity Functionsというのができて、状態の持たせ方がもう少し柔軟にできるように、オブジェクト指向的にできるようになりました。日本語のドキュメントがあるので、詳細はリンクを読んでみてください。こういうのが出てきたり、Azure Functionsはどんどん広がっています。

最後にAzure Functionsの話題でもう1つですね。もともと先ほどPremium Planのところで説明したように、Azure Functionsに限った話ではないと思うんですけど、Azure Functionsってスケールコントローラがとても優秀です。

いろいろなメトリクスを見て適切にスケールするという処理は必ず持っていると思うのですが、そのAzure Functionsで使っているスケールコントローラをベースに、これはMicrosoftとRed Hatで共同開発して、OSS化してぜんぜん別物としてGitHubに切り出したもの(KEDA)が、使えるようになっています。

確かCNCFにこれを持っていくんじゃないかなと思うのですが、ぜんぜんAzureとは関係ない世界で、スケールコントローラ自体を外に出して、いろいろなところで応用できるようにするような取り組みもされています。最近、MSはけっこうこういうOSS活動をがんばっていますね。というところの現れです。

Azure Cosmos DBでできること

ここまでがAzure Functionsの話で、ここからはちょっとデータ系の話をしたいと思います。

Azure Cosmos DBという、AWSでいうとDynamoに該当すると思うんですけれども、特徴としてはここに書かれているような感じですね。

NoSQLで、グローバル分散できて、スループットが高いですよというような、NoSQL系でよくあるうたい文句は変わらないんですけれども。これ自体は、今となってはどのクラウドでも同じようなものがあるので、これ自体どうこう言うつもりはないのですが、このChange Feedという機能がけっこうよくできていて。

Cosmos DBにデータが入った、何かデータがアップデートされたというときに、それにあわせてデータをリアルタイムに配信する機能が最初からついているんですね。しかもその配信先は複数配信することができる。なので、データベース起点でマイクロサービスを展開するという設計ができる。

実は、最初にご紹介した2つのアーキテクチャも全部そうなんですよね。マイクロサービスをデータ起点で、例えば通常の何かNotification系につなげることもできるでしょうし、これはDatabricksからSpark、BI系のデータのパイプラインを作ることもできるし、アーカイブして別のデータベースをもう1個つくるようなパイプラインも、1つのデータ起点から同時に複数配信できる。稼働させながらこのパイプラインをどんどん追加できるという優れものになっています。僕の大好きな機能ですね。

それを実装するときに、直接SDKを使ってもいいのですが、おすすめは、Azure FunctionsにCosmos DB Triggerというのがあるので、これを使うといたって簡単にデータのフィードを取得できる。いったんFunctionsにデータが入ってしまえば、もうあとはお好きにどうぞという世界なので、これはとてもおすすめです。

だいたい配信先の1つにリアルタイムのNotificationが求められる。しかも、Webに対するNotificationがけっこう求められていて、それを仲介するWebSocketのサービスも最近Serverless化されました。もともと「SignalR」というライブラリがあったんですけれども、それがAzureでServerless化されました。

それは「Azure SignalR Service」といって、いろんな組み合わせはあるんですけれども、だいたいよくあるパターンとして、Cosmos DBのChange Feedでデータ変更を契機にAzure Functionsが動いて、そのAzure Functionsの中でSignalR Serviceを呼んで、Webに変更を配信するという。

コードはこれだけ。こんな感じ。

サーバ側は、Cosmos DBトリガーなので、設定さえされていれば、動かすと何かデータ変更があったらいきなりデータが入ってくるんですね。あとはそのデータをSignalRのバインディング……接続文字列などの設定ファイルは別途あるとして、ここにSignalRにオブジェクトをぽっと置いてあげれば、SignalRを経由してWebに配信される。

Web側は、signalr.jsというライブラリがありますので、これであらかじめWebを起動したときにコネクションを張っておいて、データをどんどんストリームで受け取ると。

こういうことができるので、一番最初に説明したような、「何かツイートがあったら、データベースを経由して、Azure Functionsを経由して、SignalRを経由して、Vue.jsのクライアントにずらーっとリアルタイムのデータをプッシュできる」みたいなものがServerlessだけで完結するようになってしまったと。このへんはけっこうSignalRサービスが出たことによる恩恵は大きいなと思っています。

最後のトピックですね。SQL DBという昔からあるRDBがあるんですけれども、技術的にはオンプレのSQLサーバとほとんど同じで、.NETとかとよく組み合わせて使われるのかな。

これに最近、まだプレビューなんですけど、Serverlessモードというのが出てきました。何をもってServerlessと言っているのかというと、これは一定時間アクセスがないと止まって、課金も止まるというやつですね。ポンと1回何かpingでも打つと、コールドスタートになってしまうのですが、また再開するという。

なので、例えば社内営業システムのような、夜は使わないようなシステムのバックエンドのDBにはもうばっちり適しているのではないかなと。少なくとも夜中に使っていない時間の課金は防げます。

それから、スケールアウトではなくてスケールアップとしてのオートスケール機能がついていて。vCoreのMinとMaxを選んで、これだと0.5〜4vCoreまで範囲を設定しておけば、負荷に応じてvCoreが増えたり減ったりしてくれるという機能も持っています。

まだプレビューですけど、このへんが出てくるとRDBの使い方も、もしかしたらServerlessのアーキテクチャの中の1つの要素として十分使えるようになってくるのではないかなと期待しています。もうすでにお試しでは使えるようになっているので、興味がある方は触ってみるといいんじゃないかなと思いますね。

Azure Serverlessの今後の課題

最後にまとめに入ります。いろいろAzure Serverlessのファミリーが増えてきているのですが、まだまだ課題はやはりあります。

データ分析もできるしデータプロセシングもできるのですが、僕の大好きなフロントエンド、ここについてはまだぜんぜん弱くてですね。フロントエンドだったら、FirebaseやNetlifyのような、SPAをきちんとホストできてDevOpsともきちんと組み合わせられるような仕組みが、正直ちょっと足りていないです。

足りていないことについては、私もMicrosoft MVPという立場でどんどんフィードバックしていますし、そういった声を上げている人は多いので、そのうち出てくるのかもしれないんですけれども、フロントエンドは本当にすごく重要な要素だと思うんですよね。そこが足りていないところが個人的には課題かなと思っています。

あと1分なので、まとめに入らせていただきます。

Azure Serverlessという広い世界はあるんですけれども、繰り返しになりますけど、それはAzure Functionsだけではないですよということが1点。

それから、それがあるために、ほぼServerlessだけで実践に使えるシナリオがかなりできてきた。実際、私は業務でそれをやっています。

あと、Azure Functionsもそうですし、それぞれのSDKはほとんど今OSSで作られているので、そのあたりコントリビュートしましょうよと。

本日話せなかったことがいろいろあるんですけど、さっきなんだかCFPの話をしていたので、ちょっとこのへんがんばってみちゃおうかななんて。けっこうおもしろい話が実はあるのでやってみようかとちょっと思い始めています。

ありがとうございました。

（会場拍手）