「サーバーレス」は、サーバーの管理を意識せずにアプリを動かせる仕組みですが、言葉だけでは、どんなものが作れるのか、イメージしにくいかもしれません。本記事では、サーバーレスで作れるWebアプリの具体例と、そのときの基本的な構成、向き・不向きを紹介します。サーバーレスの基本的な考え方は、サーバーレスアーキテクチャとは？向いているケースを解説で解説しています。
サーバーレスの基本構成
サーバーレスの構成は、いくつかの部品を組み合わせて作ります。代表的な部品は次のとおりです。
- フロントエンド：画面部分。静的なファイルをクラウドに置き、CDNで配信する
- 関数（ファンクション）：処理を行うプログラム。リクエストを受けたときだけ実行される（AWS Lambda、Azure Functions、Google Cloudの関数サービスなど）
- API の窓口：画面と関数をつなぐ入り口（API Gatewayなど）
- データベース：データの保存先。マネージドのNoSQLやRDBを利用する
- 認証：ログイン機能。マネージドの認証サービスを利用する
- ストレージ：画像やファイルの保存先（オブジェクトストレージ）
サーバーの構築や、OSの更新、スケールの調整といった作業を、クラウド側に任せられる点が特徴です。
具体例① お問い合わせフォーム
コーポレートサイトなどで、よく使われる例です。静的なWebサイトに設置したフォームから、入力内容をAPIに送信し、関数が内容をチェックして、メールで担当者に通知します。必要に応じてデータベースにも保存します。問い合わせの数が少ない間は、費用がほとんどかからず、サーバーの管理も不要になります。迷惑メール対策（スパム防止）の仕組みも、関数の中に組み込めます。
具体例② 画像のアップロードと自動リサイズ
ユーザーが画像をストレージにアップロードすると、それをきっかけに関数が自動で起動し、サムネイルや、サイズ違いの画像を生成して保存する、という構成です。ファイルが追加されたときだけ処理が動くため、無駄がありません。ECサイトの商品画像や、ブログの投稿画像の処理に向いています。
具体例③ 定期的なバッチ処理
毎日深夜にデータを集計してレポートを作る、期限切れのデータを整理する、といった定期処理は、スケジュールをきっかけに関数を起動する形で実現できます。専用のサーバーを24時間動かしておく必要がなく、実行した時間分だけの費用で済みます。
具体例④ 外部サービスとのWebhook連携
決済サービスやチャットツールからの通知（Webhook）を受け取って、処理を行う例です。決済が完了したら注文のステータスを更新する、チャットでメッセージが届いたら自動で返信する、といった仕組みです。外部からのリクエストは、いつ来るか分からないため、リクエストがあったときだけ動くサーバーレスと相性がよい使い方です。
サーバーレスが向いているケース
- アクセス数の変動が大きい、または、使われない時間帯が多い
- 小さな処理を、独立した機能として切り出して作りたい
- 運用の手間を減らし、少人数で運営したい
- 新しいサービスを、素早く試したい
注意しておきたい点
起動の遅れ（コールドスタート）
しばらく使われていなかった関数は、最初の実行時に起動の準備が必要で、応答が少し遅くなることがあります。応答速度が厳しく求められる処理では、対策や設計の工夫が必要です。
実行時間などの制限
関数には、1回の処理で実行できる時間やメモリの上限があります（サービスによって異なります）。長時間かかる処理や、大量のデータを一度に扱う処理は、分割するなどの工夫が必要です。
特定のクラウドへの依存
サーバーレスの機能は、クラウドごとに仕様が異なるため、特定のサービスに強く依存した設計になりやすい面があります。将来の移行しやすさをどこまで重視するかを、事前に考えておきましょう。
開発・テストの難しさ
手元のパソコンで動作を再現するのが難しいこともあり、開発やデバッグの方法に慣れが必要です。ログの出力と監視の仕組みを、最初から整えておくことをおすすめします。
費用の見通し
使った分だけの課金は、少量なら安く済む反面、アクセスが急増すると、費用も急増します。想定されるリクエスト数をもとに、費用を事前に試算し、上限のアラートを設定しておくと安心です。
導入を検討するときの進め方
サーバーレスを初めて採用する場合は、いきなり基幹システムに適用するのではなく、影響の小さい機能から始めるのが現実的です。たとえば、お問い合わせフォームの処理や、画像の自動リサイズなど、独立していて、失敗しても業務への影響が少ない機能を、試験的に作ってみます。そこで、開発の勝手や運用の手間、費用の実態をつかんでから、適用範囲を広げていくと、リスクを抑えられます。
運用面で整えておきたいこと
ログの収集と、エラーの通知、費用の上限アラートは、最初に設定しておくと安心です。また、関数の数が増えると、全体の構成が把握しにくくなるため、構成図や、各機能の役割をまとめたドキュメントを、並行して整備しておきましょう。
よくある質問
Q. 既存のシステムを、サーバーレスに移行すべきですか？
A. すでに安定して動いているシステムを、無理に移行する必要はありません。新しく作る機能や、変動の大きい一部の機能から試すのが現実的です。
Q. サーバーレスなら、運用は不要になりますか？
A. サーバーの管理は不要になりますが、監視、ログの確認、費用の管理、セキュリティ設定といった運用は、引き続き必要です。
まとめ
サーバーレスは、お問い合わせフォーム、画像処理、定期バッチ、Webhook連携など、処理が発生したときだけ動かせばよい用途で、力を発揮します。一方で、起動の遅れや実行時間の制限、特定のクラウドへの依存といった注意点もあります。自社の用途に合うかどうかを見極めながら、小さな機能から試してみてください。
