サーバーレスとは？

コーヒーが好きな木谷映見です。
「サーバーレス」「サーバレス」という言葉を聞いたことがありますか？
本記事を読まれている方であれば、きっと聞いたことがあると思います。最近よく聞く「サーバーレス」、なんだか良さそう、モダンでかっこいい気がする！
しかし、サーバーレスとはいったいなんなのでしょうか？本当にモダンでかっこいいのでしょうか？
本記事では、サーバーレス（サーバレス）という概念について調査したことをまとめます。

サーバーレスとは
- サーバーがある場合
- サーバーレスの場合
コンピューティングの歴史
責任共有モデル
FaaS と BaaS
- FaaS
- BaaS
サーバーレスのメリット
サーバーレスのデメリット
おわりに
参考

サーバーレスとは

サーバーレスとは、サーバー管理が不要なアプリケーションを構築して実行するという概念です。

サーバーがある場合

一般的に、システムを運用する時は、プログラムを稼働させるためのサーバーが必要です。
システムが稼働している限り、サーバーも稼働していなければなりません。サーバーの運用では、OSやミドルウェアのパッチ適用、定期的な再起動など、単純な作業であるものの、本番環境への適用はサービスへの影響を考慮し、十分な検証を行ったうえで実施しなければなりません。
耐障害性を高めるために冗長構成が必要であったり、バックアップを遠隔地に保管する必要がある等、サービスの価値提供に直結しない、様々な運用のコストがかかります。

サーバーレスの場合

サーバーレスアーキテクチャの場合、プログラムを稼働させるためのサーバーを自分たちで準備する必要がなく、耐障害性を高めるための設計やサーバーの運用業務を、外部に委託することができます。AWS でサーバーレスサービスを使う場合は、AWS にサーバーの運用業務をやってもらうというわけですね。
AWS 側で、プログラムの実行に必要なスペックに自動でスケールしたり、イベント発生時に自動でサーバーを起動してプログラムを実行したりできます。メンテナンス時間や定期的なダウンタイムは発生しません。
使った分だけの従量課金で、プログラムを実行しない間は料金がかかりません。

サーバーレスとは、「サーバーが無い」ということではなく、「サーバーの存在をユーザーが意識しなくてよい」というものです。

コンピューティングの歴史

物理サーバーからサーバーレスという概念が生まれるまでの過程を調べてみます。

物理サーバー

ソフトウェア・ハードウェアを自社で保有・管理する運用形態のことです。
クラウドと比較して「オンプレミス」と呼ばれることもあります。
アップデートのタイミングを自分たちで決めたり、システムに合わせて自分たちでカスタマイズすることができますが、電源やラックの管理、筐体を置く場所の確保、故障した際のリカバリなども自分たちで対応する必要があります。
システムの負荷を予測し、ピーク時も処理できるようにスペックのプランニングは入念におこなう必要があり、もしスペックが不足してしまったら、新しく筐体を購入したり、追加のディスクやメモリを増設する必要があります。

クラウド化がすすんできている昨今ですが、今でも物理サーバーはたくさん使用されています。物理サーバーはユーザー自身でかなり自由にカスタマイズできるというメリットもあります。早急なクラウド移行が求められていなかったり、「システムが稼働している筐体は自社ビル内になければならない」「○分以内に駆けつけられなければならない」などの決まりがある企業もあり、色々な背景を加味して、物理サーバーを選択している方々もたくさんいらっしゃいます。

仮想サーバー

仮想サーバーでは、物理サーバーで時間がかかっていた、筐体の入手、設置、電源管理等を外部に委託することができます。自社内に筐体を置く場所を確保する必要はなく、インターネット、または専用線などでサーバーに接続することができます。
利用したい OS を選択すれば、OS のインストールまで実施されたサーバーが提供されます。
物理的にすっきりしましたが、OS の管理（月次セキュリティパッチ適用や再起動、機能アップデートなど）は引き続きユーザー自身で実施する必要があり、ミドルウェアの導入や管理も必要です。

コンテナ

コンテナは、サーバー仮想化技術の一種です。
OS 上の「コンテナエンジン」というプロセスを通して、ホスト OS のカーネルを共有することで CPU やメモリなどのリソースを隔離し、仮想的な空間を作り出します。コンテナの技術は奥が深く本記事では詳細まで触れませんが、これも近年注目されており、よく使用される手法です。

サーバーレス

物理的な筐体の準備や場所の確保だけでなく、OS やミドルウェアの運用・管理まで外部にお任せできます。
詳細はサーバーレスの場合で記載しましたが、これまでご紹介したコンピューティングの概念の中で、最も運用負荷が低くなっています。

責任共有モデル

責任共有モデルを見てみましょう。責任共有モデルとは、ユーザーと AWS でシステムの責任範囲を分けて共有するモデルで、仮想サーバーでは OS メンテナンス以上はユーザー側の責任範囲となります。

サーバーレスサービスの場合、OSのメンテナンスやミドルウェアの導入・メンテナンス、さらに高可用性とスケーラビリティもAWS側で対応します。ユーザーは、システムの付加価値を高めるための開発だけに尽力できます。

ごはんを食べるイメージで例えると、


物理サーバー	材料の調達から調理まで自分でやってごはんを食べる
仮想サーバー	材料は調達してあって、調理だけ自分でやってごはんを食べる
サーバーレス	すでに用意されたごはんを買ってきて食べる

みたいな感じです。

FaaS と BaaS

サーバーレスには、FaaS (Functions-as-a-Service) と、BaaS (Backend-as-a-Service) というものがあります。

FaaS

イベント駆動型コンピューティングを提供するサービスです。
イベントまたは HTTP 要求によってトリガーされる関数を使用して、アプリケーションコードを実行および管理します。イベントによってトリガーされることを、イベントドリブンと言います。
AWS では AWS Lambda が FaaS にあたります。

BaaS

認証やデータベースなど、アプリケーションが使用する機能を API 経由で利用できるサービスです。
ユーザーが、サーバーやその他の基盤となるインフラストラクチャを準備する必要がなく、透過的に動作するサービスとして提供されるため、開発者にはサーバーレスのように見えます。
AWS では Amazon SQS、Amazon API Gateway、Amazon DynamoDB などのフルマネージドサービスが BaaS にあたります。

サーバーレスのメリット

サーバーの事前準備や管理なしでコードの実行環境を得ることができる
アプリケーションの開発だけに集中して取り組むことができる
コスト面・開発スピードを踏まえて、新サービスのチャレンジがしやすい
トリガーされたときにだけコストがかかるため、コスト削減できる場合がある
マイクロサービスに向いている
マイクロサービスとは、アプリケーションが持つ機能を細かいサービスに分割し、それぞれのサービスを連携させてシステムを動かす開発手法です。サーバーレスを利用して小さな機能単位でアプリケーションを開発し、そのアプリケーションを組み合わせて大きなソフトウェアとしての機能を実現することに向いています。

サーバーレスのデメリット

仕様上の制約がある
例えば、AWS のサーバーレスサービスとして代表的なLambdaは、最大実行時間が15分までで、同時実行数が1,000までという制約があります。
その他のフルマネージドサービスも使い方や提供できる範囲が決まっており、仕様に沿った適切な設計をする必要があります。
コールドスタート問題
サーバーレスではイベント発生をトリガーに、裏で動いているインフラストラクチャーの起動を行います。コールドスタートとは、何も起動していない状態からこのインフラストラクチャーの起動を行うことで、実行までに少し時間がかかります。即応性の求められるシステムには向いていません。
大規模な基幹システムや長時間のバッチ処理には向かない
常に起動し続けていなければならない基幹システムでは、使用していないときはコストを削減できるというサーバーレスのメリットを享受できません。
監視が複雑になる場合がある
サーバーレスではいくつものサービスが連動するので、一般のアプリケーションより監視が複雑になる可能性があります。サービス間の連携の設計や呼び出しのタイミングによって、サービスが起動しなかったり、二重に起動したりする可能性もあります。その場合の検知や再実行の処理を検討する必要があります。

おわりに

サーバーレスはサーバー管理が不要でいいことずくめのようにも見えますが、採用するにはシステムによって向き不向きがあります。
ごはんを食べるときのイメージでも、テイクアウトや外食は栄養バランスが偏ったり、食べたいものがなかったり、自炊より割高になったりと、すべてがいいことずくめというわけでもないですよね。
本記事が、サーバーレスサービスを使ったシステム構成を考える際の一助になれば幸いです。