Goldstine研究所

mosuke5's tech blog

ブログ移転しました。5秒後にリダイレクトします。

三葉よ、サーバーレス、それもまた結び。

タイトルちょっとふざけました。 (が、半分本気。最後の方でわかる。)

ServerlessConf Tokyoに参加してきた。
今年8月からパブリッククラウドの事業に異動していて、(異動ブログ
開発者の立場よりクラウド提供側の立場として参加してきたので、また面白かった。

せっかくなので、自分なりにサーバレスについてまとめる。
新しいことというよりは、自分の中での整理した感じ。

1. サーバレスってなんだっけ

カンファレンスの中でもサーバレスの定義についてはいろいろな意見がでていた。
Martin Fowlerのブログではサーバレスの定義として下記2つが書いてある。

  • BaaS (Backend as a Service) : ex) firebase
  • FaaS (Function as a Service) : ex) AWS Lambda

martinfowler.com

ですが、ここでは焦点を絞って話すためにもFaaSということにしておく。
主にFaaSについて話したいのと、BaaSもいれてしまうとSaaSもサーバレスとかややこしいことになるので。

AWS Lambda

なんといってもサーバレスの概念を推し進めたのはAWS Lambdaでしょう。
説明はいまさら不要だと思うが、少しだけ。

コードを AWS Lambda にアップロードすると、サービスが AWS インフラストラクチャを使用してコードの実行を代行するコンピューティングサービスです。コードをアップロードして、Lambda 関数と呼ばれる関数を作成することで、AWS Lambda がコードを実行するサーバーのプロビジョニングおよび管理を行います。(https://aws.amazon.com/jp/lambda/details/)

課金モデルは関数呼び出した回数、および実行に利用したコンピュートのスペックによって決まる。
また特徴的なことは、AWSの他のサービスで発生したイベントをトリガーに実行できること。
例えば、Amazon S3にファイルアップロードされたことをトリガーにLambdaを実行できるのだ。

サーバレスの特徴

サーバレス自体そしてサーバレスで実装することの特徴しては下記がある。

  1. クラウド上のイベントを契機に実行できる
  2. 実行環境は、immutableで時間が立つと消える
  3. 実行環境は独立していて、コードは基本的にstatelessである
  4. 上記のようにimmutableでstatelessな構造につくるからこそスケールしやすい

2. どんな用途で利用しているか

クラウド基盤のイベントをトリガーとして

個人的に一番強力だと思っている使い方。上で説明したとおりだが、クラウド上のプロダクトに対してのイベントをトリガーに処理を行うことができる。
例えばこんな場合を想定してみよう。

ユーザが写真をアップロードするサービスで、アップロードした写真にたいして何かしらの画像解析をしてメタ情報を持ちたいとする。
ざっと従来のやりかただと2つくらいやり方が思い浮かぶ。

(1) アップロードするたびにアプリケーションサーバで画像解析をする
  • 解析にほとんど時間がかからない場合などはこれでいいと思う
  • 時間がかかるようなだとユーザへのレスポンスが遅くなる
  • 速くしようと思うとスケールアップで対応するしかない(やばい)
(2) バッチ処理でやる
  • バッチ処理で画像解析はまとめてやる。一番よくあるのでは?
  • 例えば5分に一度のバッチ処理で、5分間にたまった写真にたいしてまとめて処理する
  • バッチ処理でまとめて処理した場合、どこかでコケたときが辛い
  • この例ならそうでもないが、バッチ処理ではたいていスケールアウトが辛い

このケースに対してLambdaであればどうなるか。
1000件のアップロードに対して、1000回のLambda実行によって対応できる。
これは何万件きても同じことで、スケールの面で大変優れている。
また、1件ごとに処理するため、エラーが発生した場合に原因などとても追いやすい。

アプリのAPIとして

AWSでいうと、API Gatewayと組み合わせて、APIサーバとして利用するケース。
S3などのデータストアに直接アクセスできるように作ることもできるため、ファイルアップロードなどで使われることが多いとか。
個人的には今のところあまり魅力的には感じない使い方。

事例紹介

カンファレンスのなかで日経新聞社さんののサーバレスアーキテクチャの事例が一番よかったのでぜひ目を通しほしい。

speakerdeck.com

ポイントとしては下記。見事にLambdaの特徴を活かした利用をしている。

  • 新聞は基本的には朝刊と夕刊の2回で限られたときだけ処理する点
    • 常時稼働させたくない。EC2立ち上げっぱなしにする必要がない。
  • しかし、号外や速報など臨時の場合もただあり、それにも備えられる点
  • 日によってニュースの量が異なるため、いつでもスケールできる必要がある点

3. クラウドベンダーからみたサーバレスの立ち位置

クラウドベンダーにとってサーバレスはどういう立ち位置なのだろうか。
ぼくは「各サービスの横串」と考えています。
EC2、S3、RDSなどなどそれぞれのサービスは単体としてとてもよくできている。
しかし横の連携をしようと思うと別途様々な工夫が必要なのが現状だ。

サーバレスはその横の連携を担うのだ。
各サービス間を紐で固く結びつけてしまう。クラウドロックインを加速させる役割も持つ。

「三葉よ、サーバレス、それもまた結び。」

そして、IoTへの布石。
IoTの世界ではリアルタイムなセンサーの情報のやりとりでデバイスとデータセンタ間の通信遅延が許容できないことがある。
そこでいま研究が進んでいるエッジコンピューティング(フォグコンピューティングとも)などがあるが、
LambdaのようにImmutable, Statelessが前提で作られる、どこの環境でも実行可能な状態はIoTと相性がいいようにみえる。

今後どうなっていくかはわからないが、
バイスに近いエッジコンピューティング側はLambdaでさばき、そのさばいたデータを中央のデータセンターへ、
なんていうことが主流になってくるかもしれない。と思うとFaaSの存在は見逃せない気がしてくる。