サーバーレスとは ― FaaSの仕組みとメリット・デメリット

サーバーレスとは、サーバの確保、更新プログラムの適用（パッチ適用）、台数の調整といった運用管理を、利用者ではなくクラウド事業者が行うサービス形態です。サーバという機器そのものが無くなるわけではありません。画像のアップロードやフォームの送信があったときだけ短い処理を動かしたい場面で、候補になります。

サーバーレスの中心となる実行方式は、FaaS（Function as a Service）です。IaaS・PaaS・SaaSの3つのサービスモデルを定義したNISTのSP 800-145には、FaaSやサーバーレスという語は出てきません。

そのため、主要なクラウド事業者3社の公式ドキュメントで定義を確かめました。AWS・Microsoft Azure・Google Cloudのどれも、利用者がサーバを管理しなくてよい点をサーバーレスの特徴に挙げています。

Google Cloudは、FaaSを「関数と呼ぶ小さなコードの単位で開発する」仕組みと説明しています。このコードは、特定のイベントに応じてクラウド事業者が実行します。FaaSの具体的なサービスの例は、AWS Lambdaの記事で説明しています。

FaaSでは、利用者があらかじめ関数のコードを登録しておきます。トリガーと呼ぶイベント（HTTPリクエストやファイルのアップロードなど）が発生すると、事業者が関数を実行します。

関数を実行するには、コードを動かすための実行環境が必要です。実行環境が残っていなければ、事業者は新しく作ってから関数を実行します。環境を作る分だけ応答が遅れます。この遅れをコールドスタートと呼びます。Google Cloudは、コールドスタートを「関数がしばらく実行されていないと、事業者が実行環境を縮小する。次にイベントが来ると、環境を作り直してコードを読み込む。この遅延がアプリケーションを遅くする」と説明しています。

実行環境が残っていれば、事業者はそれを再利用します。この場合はコードの読み込みが要らないため、コールドスタートより短い時間で関数を実行できます。AWSのドキュメントにも、実行が終わった環境をすぐに削除せず保持できると書かれています。

FaaSの料金は、主に関数を実行した回数と時間で決まります。Google Cloudの比較によると、FaaSの課金はミリ秒単位の実行時間に基づきます。イベントを待っているだけの時間には、原則として課金されません。

ただし、コールドスタートで実行環境を作る時間を課金に含める事業者もあります。AWS Lambdaのドキュメントには、この時間も課金されると明記されています。また、コールドスタートを避けるために実行環境を常に用意しておく設定を使うと、待機中にも料金がかかります。

FaaSも、IaaS・PaaS・SaaSの記事で説明した3つのサービスモデルと同じように、運用管理の範囲で見分けられます。違いは、扱う単位と、処理量に合わせた増減（スケール）のしかたです。

IaaSは仮想マシンなどの基盤を扱い、PaaSはアプリケーション全体を動かす環境を扱います。FaaSが扱うのは、関数という小さな単位のコードです。扱う単位が小さくなるほど、利用者が管理する範囲は狭くなります。

サーバーレスの最大のメリットは、サーバの管理作業が要らないことです。AWSは自社のFaaSサービスの特徴として、基盤となるインフラ、インスタンスのパッチ適用、容量をAWSが管理することを挙げています。

2つ目のメリットは、使った分だけ課金されることです。常時起動サーバは起動している間ずっと課金されますが、FaaSは主に関数を実行した回数と時間で課金されます。アクセスが少ない時間帯が多いシステムほど、この違いが料金に表れます。

3つ目のメリットは、処理量に合わせて自動でスケールすることです。Google Cloudの説明では、FaaSのスケールは、リクエストのたびに即座に、ゼロまで含めて自動で行われます。利用者は、台数やスペックを事前に見積もらずに済みます。

1つ目のデメリットは、コールドスタートによる遅延です。実行環境を新しく作る分だけ応答が遅くなるため、常に低い遅延が求められる処理には向きません。

2つ目のデメリットは、実行時間の上限です。多くのFaaSサービスでは、1回の実行で動ける時間に上限があります。たとえばAWS Lambdaでは、1回の実行は標準で最大15分です。上限の長さは事業者やプランによって異なり、Azure Functionsには上限を設けないプランもあります。上限のあるサービスで長時間の処理を動かすなら、別の実行方式を選ぶ必要があります。処理を段階に分けられるなら、AWS Step Functionsのようなワークフローのサービスでつなぐ方法もあります。

3つ目のデメリットは、事業者ごとの実装の違いです。トリガーの種類や設定方法は事業者ごとに異なるため、別の事業者へ移すときにコードの書き換えが必要になることがあります。

サーバーレスが向いているのは、イベントをきっかけに短い時間で終わる処理です。たとえば、ファイルのアップロードを受けて画像を縮小する処理や、HTTPリクエストに応えるAPIがあります。HTTPで呼び出すWeb APIの仕組みは、Web APIの記事で説明しています。サーバーレスの関数は、決済の完了などを知らせるWebhookの受け口にも使えます。アクセスが不定期で、何もしない時間が長いシステムほど、使った分だけの課金が有利になります。

向いていないのは、前の節のデメリットに当たる処理です。常に低い遅延が求められる処理と、実行時間の上限を超える長い処理がこれに当たります。また、一日中アクセスが多いシステムでは、常時起動サーバのほうが安くなることがあります。どちらが安いかは、次の節の図で確かめられます。

月間のリクエスト数が多いか少ないかで、FaaSと常時起動サーバのどちらが安いかは変わります。次の図で、仮の単価を入れて、どちらが安いかと2つが同額になるリクエスト数を計算できます。初期値は説明のための仮の数値で、どの事業者の実際の料金でもありません。

実際のFaaSの料金は、実行時間・メモリ量・実行回数の組み合わせで決まります。この図では、それらをまとめた値を1回あたりの実行コストとして入れます。無料利用枠や、サーバの運用にかかる人手の費用は計算に含めていません。

• NIST Special Publication 800-145「The NIST Definition of Cloud Computing」（2. Service ModelsはIaaS・PaaS・SaaSの3つを定義しており、FaaSは定義していません）
• AWS Lambda公式ドキュメント「What is AWS Lambda?」
• AWS Lambda公式ドキュメント「Lambda execution environment」
• AWS Lambda公式ドキュメント「Lambda quotas」
• Microsoft Learn「Azure Functions Overview」
• Microsoft Learn「Azure Functions hosting options」
• Google Cloud「What is Function as a Service (FaaS)?」