serverlessconfに参加してきました。
serverlessに関しての知見があまりなかったので、すごい有意義な勉強会となりました。
- そもそもserverlessとは
- serverlessによって実現できること
- serverlessの思想
- 現状
そもそもserverlessとは
パネルディスカッションでも盛り上がっていましたが、 Serverlessとは何を指すのか？
実際にCPUなどのリソース管理をしないServerlessと FaaS（Function as a Service）の機能をベースとして構成としてのServerless の２つが議論に上がっていました。
自分なりには、前者に関してはいわゆるマネージドサービスであると思っているので、 後者のものをServerlessの概念として考えています。
serverlessによって実現できること
Serverless自体が注目されてたのは、AWS lambdaがきっかけです。 AWS lambdaとは、サーバを管理するのではなく、コード（ファンクション）を管理するのみで、デプロイもコードです。 lambdaが呼び出されるたびに毎回起動してファンクションが実行されます。
そのlambdaの登場によってリソース管理が必要なくなります。 今まではサーバにデプロイしていたため、そのサーバの要件に対してリソースが少ない場合、作り直す必要がありました。 しかし、lambdaを利用する場合、リソースに関しては気にしなくてもよいのです。 そう、圧倒的に運用負荷が下がるのです。
serverlessの思想
www.slideshare.net
上記のスライドを是非見てもらいたいのですが、serverless の思想が示されています
- オンデマンドで計算リソースを利用するべき
- 一つの目的のためのステートレスなファンクションを書くべき
- プッシュ型でイベント駆動のパイプラインで設計すべし
- フロントエンドに機能を充実させる
- 3rdパーティサービスを積極的に取り入れる
ItoNaoyaさんも言っていましたが、マイクロサービス的観点だと、１サーバに載せる機能は境界づけられたコンテキスト内の内容でした。 しかし上記の思想を取り入れると、lambdaで担保するものは１機能になっていきます。
現状
現状のlambdaでは、以下のデメリットがあります。
- 計算時間がコストになりうる上、5分のタイムアウト制約もありますので、重い処理は実行できません。
- lambdaなどのFaaSでは、使える言語が特定されてしまいます。
- Javaなどは起動時間が遅いため、それをwebサービスのレスポンスとして利用するとサービスとして提供できるレベルに達しません。
薄いサービスならば作成できると思いますが、全てをserverlessで置き換えることはまだまだ難しそうです。 そもそも、その要件が満たせる状況になっても置き換えるかというのは疑問です。 というのも、複雑なビジネスロジックであればあるほど、コードとして再利用がし辛くなり抽象化ができなくなってしまうからです。
では、対応例として考えられるものは
- botなどの厳しいレイテンシを求められないもの
- バッチの発火
- 薄いサービス
でしょうか。
まとめ
serverlessという単語自体が曖昧な単語となってしまって、実際バズワードにもなりそうですが、 今後一つの潮流として、素早いサービスを作る上で絶対に避けて通れない考え方だと思います。
サービスを作る際に、serverlessも一つの手法の対象として考えれるようにキャッチアップしていく必要がありそうです。
