FaaS、PaaS、サーバーレスアーキテクチャのメリット

この記事では、サーバーレスとは何か、PaaSやSPaaSとの比較、サーバーレスアーキテクチャのメリットとコスト、フレームワークの必要性について議論する。

当初、サーバーレスという言葉は、バックエンドアプリケーションを動かすためのサーバーのセットアップと管理を、開発者が気にする必要がないことを意味していた。サーバーを必要としないわけではなく、バックエンドのインフラストラクチャはサードパーティプロバイダによってメンテナンスされ、データベース、メッセージング、認証などの必要な機能はサービスとして提供されるということだ。こうしたサービスインフラストラクチャは通常、BaaS（Backend-as-a-Service）やMBaaS（Mobile Backend-as-a-Service）と呼ばれた。

ところが、Amazonがサーバーレスのパラダイムを別のレベルに引き上げた。彼らは2014年にAWS Lambdaを発表し、クラウドで動かすアプリケーションに新しいシステムアーキテクチャを取り入れたのだ。そこには、サーバー上で動作して、HTTPリクエストやAPI呼び出しを待つ永続的なプロセスはない。代わりに、AWSのサーバーのひとつで、コードの断片、通常は単なる関数の実行をトリガーするためのイベントメカニズムがある。

このパラダイムを使うと、サーバーのことを考える必要がなくなる。重要なのは、特定のイベントの発生時に実行されるコードを書くことだけだ。コードを実行するサーバーを見つけて必要に応じてスケールさせるのは、クラウドプロバイダーがやってくれる。関数を実行するのに使われるコンテナは、その実行が終了すると即座に廃棄される。そして、コードの実行は100ms単位で計測され、使ったリソース分だけ課金される。このタイプのサービスをFaaS（Function-as-a-Service）と呼ぶ人もいる。クラウドコンピューティングが誕生して以来、登場してきた多数のYet-Another-as-a-Service (YAssS) のひとつだ。

FaaSプロバイダはAmazonだけではない。Google Cloud Functions、Microsoft Azure Functions、オープンソース実装を使ったIBM OpenWhisk、Iron.io、Webtaskなど他にもある。

サーバーレスアーキテクチャはナノサービスと相性が良い。マイクロサービスが比較的小さなビジネス機能を解決するためのプロセスだとすれば、ナノサービスはそれぞれの機能の一部を扱うものだ。例えば、マイクロサービスがアカウントの全CRUD操作を実行するのに必要なコードで表現されるとしたら、個別のアカウント操作（Create、Read、Update、Delete）ごとにナノサービスがあるということだ。“Create Account” イベントがトリガーされると、個別のナノサービスがAWS Lambda関数として実行される。ナノサービスという言葉を使う人はあまりなく、マイクロサービスもしくはただのサービスを使うのを好む人が多い。

FaaSをただのPaaSだと考えている人もいるが、Intent MediaでVP of Engineeringを務めるMike Roberts氏は、別の意見を持っている。

多くのPaaSアプリケーションは、リクエストごとにアプリケーション全体を起動・終了させることを狙ってはいません。それに対し、FaaSプラットフォームはまさにそれを狙っているのです。…

FaaSとPaaSの運用上の大きな違いは、スケーリングにあります。たいていのPaaSでは、依然としてスケーリングについて考える必要があります。例えばHerokuの場合、実行するのにいくつのDynoが必要か考えるでしょう。FaaSアプリケーションの場合、これはまったく目に見えません。たとえPaaSアプリケーションをオートスケールするようセットアップしたとしても、個々のリクエストのレベルでそうしたくはないでしょう（非常に特殊なトラフィックプロファイルでない限り）。したがって、コストに関して、FaaSアプリケーションはずっと効率的なのです。

Roberts氏は、全員がPaaSを捨ててFaaSを使い始めるべきだとは考えていない。彼は理由をいくつかあげている。「ツールとAPIゲートウェイの成熟が、おそらく一番大きいでしょう。さらに、PaaSで実装された12-Factor Appsでは、最適化のためにアプリ内読み出し専用キャッシュを使えるかもしれません。これはFaaSにはない選択肢です。」

自らをSenior ThinkerでRaconteurと呼ぶCamille Fournier氏はツイートでこう述べた。「サーバーレスサービスはストアドプロシージャのようなものになるんじゃないかと思っています。それはすぐに大きな技術的負債になる名案です」。この問題に対して、Roberts氏はこう考えている。FaaSをSPaaS（Stored-Procedures-as-a-Services）に置き換えることができるのは、サーバーレス関数が単に「データベースへのアクセスをラップする小さなコードの断片」である場合だけだが、FaaS関数は様々な目的に使えるので、この対比は正しくはない。彼はまた、ストアドプロシージャと違って、サーバーレス関数はベンダー固有の言語やフレームワークを必要とせず、容易にテストができて、バージョン管理ができると述べている。

サーバーレスアーキテクチャに関して、ThoughtWorksの開発者であるBadri Janakiraman氏は、FaaSによってもたらされる変化について述べている。ロジックの大半を含む長寿命のサーバープロセスは、プロプライエタリおよびサードパーティのサービスに分解され、アプリケーションのフローコントロールはクライアントに移るだろうと。

たいていのサーバーレスアプリケーションは、様々なサードパーティサービスを使って、従来サーバーがやっていたタスクを実現しています。これらサードパーティサービスは、Amazon AWSやAzureのような、相互運用される豊富なサービスのエコシステムかもしれませんし、ParseやFirebaseのような完成した機能セットを提供しようとする単一サービスかもしれません。これらのサービスが提供する抽象化は、インフラ的なもの（メッセージキュー、データベース、エッジキャッシングなど）やハイレベルなもの（連合アイデンティティ、ロールおよびケイパビリティ管理、検索など）かもしれません。

一般的なサーバーベースのWebアプリケーションの主たる責務のひとつは、リクエスト-レスポンスのサイクルをコントロールすることです。サーバーサイドのコントローラーが入力を処理し、適切なアプリケーション動作を実行し、通常はテンプレートエンジンを使って、動的なレスポンスを構築します。これに対して、サーバーレスアプリケーションでは、アプリケーション動作はサードパーティサービスを組み合わせて作られます。クライアントサイドのコントロールフローと動的なコンテンツ生成が、サーバーサイドのコントローラーの代わりをします。リッチなJavaScriptアプリケーション、モバイルアプリケーション（そして、ますます増えているTVや組み込みIoTアプリケーション）は、APIの呼び出しとクライアントサイドUIフレームワークを使うことで、様々なサービス間のやりとりをまとめて、動的なコンテンツを生成します。

Janakiraman氏はサーバーレスアプリケーションを実装するメリットについて、コストの大幅な削減（クラウドでサーバーをまるまる借りるためにお金を支払う必要がなく、実行に使ったリソースの分だけ支払えばよいため）、スケーラビリティ（イベントによって実行をトリガーされる独立したサービスをスケールさせるのは簡単であるため）、そして、インフラの運用管理が不要であることを挙げている。コストに関して、Janakiraman氏は「単一のアプリケーションを複数のサービスで作られたものに分割する概念的オーバーヘッドは大きく、使われるサービスの数と多様性が増加し」、開発とテストがより複雑になるとも述べている。

FaaSベースで完全なバックエンドを作る場合、サーバーレスアプローチには別の隠れたコストがある。serverless.comはドキュメントで次のように説明している。

AWS Lambdaはアプリケーションの開発/運用に強力かつ新たな方法を提供しますが、完全にAWS Lambdaに基づく最初のプロジェクトを構築しようとして、私たちはどうしても構造が必要になることに気づきました。Lambdaがもたらすコンテナをすべて管理するのは、大変な作業です。そこに複数の開発チーム、複数のステージ、複数のリージョンのサポートが加わり、あなたはすぐに混乱に陥るでしょう。

Serverless Inc.がServerless Frameworkを作っているのはそのためだ。これはFaaSを使ったWeb、モバイル、IoT向けアプリケーションの構築を助けるオープンソースプロジェクトだ。現在のところAWS Lambdaで動いており、フレームワークの作者らは将来的に別のプロバイダもサポートしようとしている。このフレームワークには、Lambda関数のローカルおよびリモートでの実行とテスト、Lambda関数のデプロイ、AWS API Gatewayに対するREST APIのデプロイ、Lambdaイベントのデプロイ、複数のAWSリージョンのサポートなど、多数の機能がある。サポートしている言語には、JavaScript/Node.jsとPythonがあり、そこにJavaを追加しようと取り組んでいるところだ。その他の言語も今後追加されるだろう。

別のサーバーレスフレームワークにApexがある。同様の機能を備え、AWS、JavaScript/Node.js、Go、Java、Pythonをサポートし、将来的に他のプロバイダのサポートを計画している。

サーバーレスアーキテクチャについてさらに学びたい人のために、amazon.comのCTOであるWerner Vogels氏は、AWS Lambdaを使ったアプリケーションを構築するためのリファレンスアーキテクチャを多数公開している。彼はそこで、モバイルバックエンド、リアルタイム処理、Webアプリケーション、IoT向けバックエンド、Kinesisベースのリアルタイムストリーム処理のための指針を提供している。リファレンスアーキテクチャで説明されている原則は、使うサービスを変更するだけで、他のFaaSプロバイダにも適用することができる。