もうかなり前になってしまいますが、
渋谷のAzure Antennaに参加してきました。
参加したハンズオンは、
Azure Functions と キューで構築するNoOpsスケーラブルバッチ処理基盤
です（リンク先にスライドや講義資料など全てあります）。
de:codeでNoOpsという概念に感銘を受けたので、一回話を聞こうと思い、参加しました。
学んだ内容はAzure上でのサーバレスアーキテクチャのベストプラクティス、
と呼んでも良いような内容です。
0.そもそもサーバレスとは？
コミケで買った本は、細かくFaaS(Function as a Service)とFunctional SaaSに分けて議論しているように見えますが、自分の理解を述べます。
コミケ本の人と主張は同じで(多分)、私もサーバの存在を考えずに何かしらの小さな機能を実現できる仕組み、だと思っています。
クラウド時代において、実際には物理的なサーバがどこかのデータセンターで動いているわけですが、
一個人からすると、実質無限にサーバが使えると仮定しても差し支えないような状況になりました。
また、各クラウドベンダーがそれらの大量にあるサーバを管理してくれているので、ハードウェアの故障が起きても、別のサーバをすぐ使えるし、そのような対応は不要になりました。
そして、実質無限ともいえるそれらのサーバの一部を少しの期間だけ貸してもらい、機能を実行するという形態がサーバレスと呼ばれているものだと思っています。
クラウドベンダー側からすると、サーバを大量に管理しているので、スケールメリットがある上に客は大量にいるので儲かるかつ、
我々からすると、少しの期間だけサーバを借りるだけになるので、払う料金は少なくて済む、
というWin-Winの関係が築けているものだと思っています。
一瞬だけどこかのサーバで実行されても良いようにサーバレスのプログラムは書かなければならないという制約をクリアすれば、
スケールしやすいし、エラーが他にも波及しないというメリットもありますので、最近流行ってきている印象を受けます。
1.作成した構成
作成した構成はAzure Storage Queue + Azure Functions + CosmosDBです（上述のリンク先から図は拝借）。
これの何がベストプラクティスか、というポイントを説明します。
①キューを用いているところ
クラウド時代の設計として、有名なものの一つとして、
Queue-based load levelingパターンというものがあります。
サーバレスアーキテクチャは前述の通り、スケールしやすいというメリットがありますので、
キューを用いた設計にすると、キューのメッセージ数に応じてスケールし、
パフォーマンスが出ます。
また、変なメッセージが入ってきても、機能実行が独立していますので、
他のメッセージ処理に影響が及びません。
なのでキュー+Azure Functionsという構成はとても良い、ということになります。
(話の筋とは少しずれますが、Azureにいろいろあるキューのうち、Azure Storage Queueが選定されているのは、それがStorageの一つで、設定がしやすいのが理由かな、と想像しています)
②NoSQLを用いているところ
サーバレスアーキテクチャは前述の通りスケールしやすい、というメリットがありますが、
これは従来のRDBには辛い話です。
というのも、RDBはトランザクション処理の関係ではないかと思いますが、
同時接続数が限られているからです。
スケールしたサーバレスのものが大量に接続してくると、RDBにはつらいものがあります。
そこで、ここで使われているのがNoSQLです。
NoSQLのデータベースは並列分散のアーキテクチャを取っているものですので、
同時接続も並列分散して捌くことが可能です。
ですので、NoSQLの一種である、CosmosDBはAzure Functionsとの組み合わせの相性がとても良いことになります。
2.サーバレスアーキテクチャの今後への期待
今までサーバレスは素晴らしい、ということを書いてきていますが、
まだまだこの技術は発展途上であることが否めないのも事実です。
具体的には、サーバレスはコールドスタート問題というものをそのアーキテクチャ上抱えています。
サーバレスは
プログラムが呼ばれる→実行領域を確保する→ライブラリ等の準備をする→実際の実行
という流れをこなさなければならず、実行に時間がかかります。
Azure Functionsには、Run-From-Zipなど、コールドスタート問題に対処する仕組みがありますが、
それでも、もう少し速くなったほうが嬉しいというのが今の実情です。
これに対応して、App Serviceプランというのもがあり、これは事前に使うサーバを用意しておく、というものです。
が、App Serviceプランだと事前にサーバを借りておくことになってしまうので、サーバレスとは言い難いのではないかと個人的には考えています。
しかし、この部分はAWS等も含め、各社力をいれているところですので、ゆくゆくはコールドスタート問題はほぼ考えなくて良いところまで行くのではないか、と想像しています。
3.その他
サーバレスアーキテクチャと相性が良いと思うものの一つにあまり叩かれることのないAPIがあります。
具体的には、SendGridのevent webhookでの受信などです。
APIを叩くとメールが送れるという非常に便利なサービスとして有名なSendGridですが、
実運用だと不達メールや宛先間違いなどでうまくメールが送れないときがあります。
そのときに自分でSendGridが叩くAPIをこちらで用意しておけば、そのAPIを叩いてくれる、
というのがevent webhookというサービスです。
規模にもよりますが、不達メールや宛先間違いというのは確率として高いものではないので、
叩かれる頻度としてはそこまで高くありません。
そんなときにAzure Functionsで叩かれる口を用意しておけば、安価に対処できてしまう、という訳ですね。
いやはやすごい時代になったなぁと思います。
一昔前だとあんまり使われないAPI1本だけ用意したい、とかでもそこそこ費用かかってたよな、と思います。
4.まとめ
ハンズオンに参加して、流行りのサーバレスのベストプラクティスの設計を学んできました。
サーバレスはまだ発展途上ですが、間違いなく次世代の中心になるものだと思いますので、
展開が速いですが、自分のペースでキャッチアップしたいな、と思います。
ずさずさ
最新記事 by ずさずさ (全て見る)
- Azure Functions V1を使う - 2019年1月6日
- EventGridの使用を始めるときにつまずいたところ - 2018年12月2日
- サーバレス周りの話 - 2018年9月17日
