# サーバーレスとは

サーバーの準備や管理をクラウド事業者に任せる実行方式です。処理量の変化に対応しやすい一方、料金や実行時間の制限はサービスごとに確認が必要です。

## サーバーレスとは

サーバーレスは、アプリケーションを動かすサーバーの準備や管理をクラウド事業者に任せる[実行方式](https://cloud.google.com/discover/what-is-serverless-computing)です。多くのサービスでは、利用者がサーバーの台数を決めて維持する代わりに、設定と制約の範囲で処理量に応じて実行環境を調整します。例えば、画像がアップロードされたときだけ画像を縮小する処理を実行できます。

サーバーが存在しないわけではありません。利用者が設備を管理せずに必要なときに使う点は、建物内に発電設備を持たず電力会社から電気を利用する形に似ています。電気の例とは異なり、実行回数や、処理をすぐ始められるよう実行環境を待機させる設定なども料金に影響するサービスがあります。

コンテナはアプリケーションと必要なソフトウェアをまとめる技術です。一方、サーバーレスは実行環境の管理を任せる方式なので、コンテナをサーバーレス環境で実行する構成もあります。

![サーバーレスを使う側はアプリの不具合対応、データ内容の確認、アクセス権の設定を担い、クラウド事業者はサーバーを管理する。範囲はサービスで異なる](https://media.marketing.kdotdev-tunnel.org/glossary-serverless-02ad07b8dd800f46f419b7bd7b6901caac47b691a10c295bf7c2812e877ba6f2.png)

## 何を任せ、何が残るか

例えば、申込フォームの送信をきっかけに確認メールを送る場合、送信を受けてメールを作るプログラムを用意し、サービスに登録します。申込がない間のサーバーの維持や、申込が集中したときの実行環境の増減は、利用するサービスの設定と制約の範囲で事業者が管理します。

![申込を契機にサーバーレスで確認メールを申込者へ送信する。事業者は設定と制約の範囲で、サーバー基盤の管理と申込集中時の実行環境の増減を担う](https://media.marketing.kdotdev-tunnel.org/glossary-serverless-5b018d88a76f61794b49fc6fb74886f09cd1d3016cb86fb72c97ed91d8b57554.png)

実行方法の1つにFaaS（Function as a Service）があります。関数と呼ぶ特定の処理を行うプログラムを登録し、データの到着などを契機に実行するサービスです。サーバーレスには関数だけでなく、コンテナやデータベースを扱うサービスもあります。

事業者に任せる範囲はサービスで異なります。アプリケーションの不具合、データの内容、アクセス権限、処理が失敗したときの対応は利用者側で確認が必要です。クラウドの[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)でも、事業者が基盤を管理する一方、利用者はデータや設定に関する責任を持ちます。

確認メールの例では、同じ申込を複数回受け取る場合に備え、申込IDを使った重複送信の対策を設計します。送信結果と失敗した申込を記録し、担当者が確認して再処理できるようにします。AWS Lambdaの[非同期呼び出しでは重複や未処理が発生する場合](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async-error-handling.html)があります。失敗や未処理の通知を確認する担当と、申込が集中したときに連携先が処理できる量も決めます。

![利用者は事前に申込IDを使ったメールの重複送信対策と、送信結果・失敗した申込を記録できる仕組みを用意する。運用時に担当者が失敗・未処理の通知と記録を確認し、必要に応じて再処理する](https://media.marketing.kdotdev-tunnel.org/glossary-serverless-b2e235184e584af1199630f7beb3e6bed6565992ec74348db442ec9b9ccb6299.png)

## 費用は利用量でどう変わるか

サーバーレスは、使う時間が限られ、処理量が増減するシステムで費用を抑えられる場合があります。自社で常時稼働するサーバーを確保せずに済むためです。ただし、常に最安になるわけではありません。

![Lambda Event Functionsのオンデマンド料金に関わる課金リクエスト数、実行時間、割当メモリと、保存・メールや待機設定の別料金の可能性](https://media.marketing.kdotdev-tunnel.org/glossary-serverless-8e46faa0976400e88203c51d3960a9c29d5160cc26712fb8ab03e3fafcf0c57f.png)

例えば、AWS LambdaのEvent Functionsをオンデマンドで利用する場合は、[課金対象のリクエスト数と、割り当てたメモリ量・実行時間](https://aws.amazon.com/lambda/pricing/)に応じた料金体系です。非同期イベントは、データの大きさによって追加のリクエストとして課金される場合があります。保存先やメール送信など、組み合わせるサービスには別の料金が発生する場合があります。実行環境を待機させる設定なども含め、サービスごとに確認します。

比較するときは、まず通常期と申込が集中する時期を分け、それぞれの処理が起動する回数と1回の所要時間、作業領域であるメモリの量を見積もります。例えば、月単位で関数の費用にデータ保存やメール送信の費用、設定と監視を担う人の作業を加えます。同じ期間のサーバーを確保する方式の料金と運用作業も比較します。処理回数が増えても想定外の請求にならないよう、利用量と費用を監視する担当が必要です。

## どの処理に向いているか

画像の縮小や申込時の通知のように、発生するたびに完了する処理は検討しやすい用途です。処理が発生しない時間があり、サーバーの管理作業を減らしたい場合に適しています。

![短時間の突発処理ではサーバーレスを候補にし上限と料金を確認する。長時間・常時稼働も上限と料金を確認し、上限超過時は分割や別方式を比較する](https://media.marketing.kdotdev-tunnel.org/glossary-serverless-8c5d6c191f88fc5d82456b5b1d788bb498ed27953b6d602e575ef91177869b1d.png)

一方、1回の処理が長時間に及ぶ場合や、停止せずに稼働し続ける必要がある場合は、実行時間の上限と料金を先に確認します。例えば、通常のAWS Lambda Event Functionsでは[1回の実行は最大15分](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)ですが、実行形態によって上限は異なります。上限を超える処理は分割するか、長時間のタスクに対応する別のサービスや実行方式を選びます。

また、利用がない状態から処理を開始すると、[実行環境の準備に伴う遅延](https://cloud.google.com/run/docs/tips/general)が発生する場合があります。応答を待てない画面では、実際のサービスと設定で応答時間を検証します。特定サービスの機能に依存すると、他の環境へ移行する際に設定やプログラムの変更が[必要になる場合](https://cloud.google.com/discover/what-is-serverless-computing)があるため、移行の可能性も比較材料です。