サーバーレスって何？

Last updated at 2017-09-15Posted at 2017-08-10

はじめに

クラウド上にアプリケーションを構築する際の設計手法として、「サーバーレスアーキテクチャー」の注目度が上がっています。
Netflixをはじめ、先進的なサービスを短いサイクルでローンチしている会社で続々と採用され、注目を集めています。

また、ガートナー社の発表でも、『企業が注視すべき、プラットフォームを実現する主要なテクノロジ』として紹介され、今後２〜５年以内にメインストリームになると予測されています。
ガートナー、「先進テクノロジのハイプ・サイクル：2017年」を発表

サーバーレスアーキテクチャーの概念、実現方法、メリット・デメリットをまとめてみました。

＜ご注意＞
本稿は2017年8月時点の情報に基づいており、現在の情報と異なっている可能性があります。
本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。

サーバーレスアーキテクチャーを実現するには、クラウドベンダー各社のイベント駆動型コード実行サービスを利用します。

イベント発生時に粒度の細かい関数（Function）を実行する、ということで、IaaS、PaaS等と対比して「Function as a Service(FaaS)」と呼ばれます。

クラウドのシェア上位3社 ¹ が提供しているFaaS

課金は使用した個々のリソース量に基づいて従量的に行われます。

（2017年9月1日追記）
本稿執筆後、IBM OpenWhiskから**IBM Cloud Functionsに名称変更**となりました。

IaaS / PaaS		FaaS
MAXを想定して性能を見積もり、設定する必要がある	→	Functionの実行時に自動的に必要なリソースが割り当てられるため、性能の見積もりも設定も不要
常時サーバーを起動させているため、未利用の時間帯の料金が無駄である	→	実際に使用したリソース量に基づいて従量的に課金されるため無駄がない
サーバーの運用監視が必要	→	サーバーの存在を意識せず、コードだけを管理すればOK

さらに、Functionごとの粒度による分割統治と、また、ステートレスな設計（そうせざるを得ない）により、必然的に機能間の依存関係が極少化されます。

したがって、上手く設計できれば、変更に対して非常に柔軟な構造になります。

ベンダーによって数値はまちまちのようですが、どれも以下のような制限・制約があります。

すなわち、あらゆるFunctionの確実な実行が保証されているわけではない、ということになります。

イベント発生のたび動的にリソースが割り当てられる、という特性上、イベント発生の間隔が短い場合はプーリング処理されますが、間隔が長い場合は初回の実行に時間がかかる傾向があります。

メリットの項で書いたことの裏返しです。
コード実行後はインスタンスが消滅するため、ステートレスで機能間の依存性がない設計が必要となります。

サーバーレスは、サーバー運用の手間やコストについて大いにメリットがあり、注目を集めています。

一方で、以下のような機能・サービスに対してサーバーレスを適用することは難しいでしょう。

マイクロサービスとサーバーレスは異なる概念です。
マイクロサービスアーキテクチャーとは、大規模なアプリケーションを小さく機能分割して統治する設計手法です。

サーバーレスは、サーバーの存在を意識しないことで、サーバー運用監視の手間が軽減されることを期待できます。
一方、マイクロサービスにはそのような概念は含まれません。
むしろ、分割した機能すべてのサーバー運用を意識しなければならないため、運用の手間が増える可能性もあります。

このことから、マイクロサービスの一部にサーバーレスを適用するという事例が多いようです。