サーバーレスとは?仕組みを簡単解説

まずは、これだけ

サーバーレスは、サーバー管理をクラウドに任せて、必要な処理だけを書く考え方。
サーバーが存在しないのではなく、設定や増減、監視の多くを自分で持たない形です。

ブラウザからサーバーレスへリクエストが届き、関数が自動実行されてDBや認証サービスを使いレスポンスを返す図解
サーバーレス:管理をクラウドに任せる 関数:必要な時だけ動く処理

サーバーレスの基本

サーバーレスは、Webアプリの処理を動かすサーバーを自分で用意し続けるのではなく、クラウドサービスに管理を任せる作り方です。

名前だけ見ると「サーバーがない」と思いやすいですが、実際にはクラウド側にサーバーがあります。開発者は、そのサーバーの細かい設定や台数管理を意識しにくくなる、という意味で使われます。

サーバーはある

ただし、自分で直接管理する範囲が小さくなる。

処理を書く

リクエストやイベントに反応する小さな処理を書く。

クラウドに任せる

起動、台数調整、監視などの一部をサービス側に任せる。

サーバー管理ありとの違い

従来のサーバー運用では、サーバーの設定、監視、負荷に合わせた増減などを考える必要があります。小さな機能を作るだけでも、動かす場所の面倒を見る時間が発生します。

サーバーレスでは、開発者は「どの処理を動かすか」に集中しやすくなります。たとえば問い合わせ送信、画像変換、Webhook受信、APIの一部処理など、小さく独立した処理と相性がよいです。

サーバー管理ありでは設定、監視、増減を自分で見るが、サーバーレスでは処理だけ書き管理をクラウドに任せる比較図
サーバーレスは、サーバーの面倒を見る時間を減らし、処理を書くことに寄せる考え方です。
設定

OSや実行環境の細かな管理を減らしやすい。

監視

ログや実行回数などをクラウド側の機能で見られる。

増減

リクエスト量に合わせた実行数の調整を任せやすい。

イベントで処理が動く

サーバーレスでは、処理がずっと起動して待ち続けるというより、何かが起きた時に実行される形で考えることが多いです。この「何か」をイベントと呼びます。

HTTPリクエストが届いた時、ファイルがアップロードされた時、決まった時刻になった時、Webhookが届いた時などに、用意した関数が実行されます。

イベントが来た時だけサーバーレス関数が実行され、リクエストが増えると自動で実行数が増える図解
イベントが来た時だけ関数が実行され、リクエストが増えると実行数も増えます。
1 イベント リクエストや通知が届く
2 実行 必要な関数が動く
3 連携 DBや外部APIを使う
4 返却 結果をレスポンスにする

向いている場面

サーバーレスは、短い処理を必要な時だけ動かしたい場面に向いています。アクセスが急に増える可能性がある機能や、たまにしか動かない処理でも使いやすいです。

一方で、長時間動き続ける処理や、細かく実行環境を調整したい処理では、普通のサーバーやコンテナのほうが分かりやすいこともあります。

APIの一部

問い合わせ送信、通知、認証後の小さな処理など。

イベント処理

ファイルアップロード後の変換や、Webhook受信後の処理。

定期実行

毎日決まった時刻の集計や、軽いメンテナンス処理。

よく出てくる名前

サーバーレスを調べると、AWS Lambda、Vercel、Cloudflare Workers のような名前が出てきます。全部を同じものとして覚えるより、どの場所で処理を動かすサービスなのかで見ると分かりやすいです。

Lambdaはクラウド上で関数を動かす代表例です。Vercelはフロントエンド公開とサーバーレス関数をまとめて扱いやすいサービスです。Cloudflare Workersは利用者に近い場所、いわゆるエッジで処理を動かす選択肢としてよく出てきます。

AWS Lambda

イベントに反応して関数を実行する、サーバーレスの代表的なサービス。

Vercel

Webサイト公開とAPI的な処理をまとめて扱いやすい、フロント寄りの開発で見かけるサービス。

Cloudflare Workers

利用者に近いエッジで処理を動かすサービス。短い処理や高速な応答で話題に上がりやすい。

ここまでのまとめ

サーバーレスは、サーバーが消える技術ではありません。サーバー管理をクラウドに任せ、イベントが来た時に必要な処理を実行する作り方です。

サーバーレスは、サーバーを意識しない魔法ではなく、サーバー管理の多くをクラウドへ任せる設計です。