サーバーレスをあらためて考えてみる

これは豆蔵デベロッパーサイトアドベントカレンダー2023第14日目の記事です。

クラウド、特にAWSではサーバーレスというワードを耳にしない日はないでしょう。AWS Lambdaがローンチされた2014年以降サーバーレスという名がつけられるサービスも増加しつづけています。それとともにサーバーレスの意味が曖昧なものになってきているようにも感じています。

広い定義では、システム開発・運用を行う上でサーバー構築や管理をクラウドプロバイダに任せて自身はそれらを意識しないことを指して使われている場合があります。しかしこの定義ではいわゆるマネージドサービスは全てサーバーレスと呼んでいいことになりそうです。

サーバーレスなプロダクトを提供しているmomento社のブログ記事「Fighting off faux-serverless bandits with the true definition of serverless」の中で、サーバーレスの核となる理念が挙げられています。

• シンプルさ
• 瞬時の起動
• 瞬時の弾力性

「シンプルさ」は人によって捉え方が変わる気がしています。AWS Lambdaのようなサーバーレスの代表例であっても、時代とともに構成するための項目が増えてきているため、シンプルとは言えないと考える人もいるのではないでしょうか。とはいえ、仮想サーバー (VM) のセットアップや負荷分散、自動スケーリング等々を自前で構成することを考えれば十分にシンプルだといえます。

サーバーレスというためには、サービスが呼び出された時瞬時に処理が開始される必要があるということです。サービスを利用するため特定のAPIを呼び出す前にサービスのインスタンスを起動したり、起動を待つということではこの理念を満たすことができません。また瞬時に起動可能に作られたサービスは、サービスが利用されていない時に停止できることを意味します。

変動するキャパシティに瞬時に対応できる弾力性が必要です。この要求は日に日に高くなっているように感じています。今では秒未満の短ければ短いほどいいとされるスケーリングが求められ、急激なスパイクにも対応できるべきと考えている利用者も多くいるでしょう。

サーバーレスの核の理念と似たものに「リアクティブ宣言」があります。リアクティブ宣言の中でリアクティブシステムは次の側面が重要だと書かれています。

• 即応性 (Responsive)
• 耐障害性 (Resilient)
• 弾力性 (Elastic)
• メッセージ駆動 (Message Driven)

基本的に同じ方向性のもののように感じつつも、一般的にリアクティブシステムの構築には Kubernetes のようなコンテナ環境の利用が多いと感じています。弾力性はサーバーレスほどの瞬時性は求められていません。シャーディングや負荷分散、そして予測的なスケーリングの利用が書かれています。

コンテナはコンテナを動作するためのOSを含むノードと呼ばれるインスタンスが必要になるのが一般的です。ノードの起動は瞬時とはいえないため、ノードの増減を必要とする場合の弾力性はサーバーレスに劣ると考えられます。またこのノード数の計画はコンテナがどの程度スケーリング可能かを制限することにもつながるため、常時稼働するコンテナ数にフィットさせるのではなく、予測されるスパイクに対応する余力を持たせることになります。

リアクティブ宣言にあるリアクティブシステムと比較して、サーバーレスが有効なのは必要なキャパシティの予測が不可能な場合や、予測されるスパイクに対応するノード数と平常時に必要なノード数に大きな差がある場合があげられます。

最近ではオールインワンのソフトウェアプロダクトが減って、SaaSプロダクトの開発が増えていると感じています。SaaSプロダクトはAPIを公開して外部から利用する形をとります。公開APIを持つプロダクトの設計、開発には「サーバーレスの核の理念」を意識すると良さそうです。

サーバーレスなプロダクトを提供するのはかなりのチャレンジが必要になるでしょう。例えば計画停止をせずにバージョンアップや機能追加ができるようにするということだけでも、かなりの困難があるでしょう^[1]。サーバーレスの価値を理解し、競争力のあるプロダクト開発のドライブ、支援をしていきたいと考えています。