サーバレスとは？
名前から想像するとサーバが不要という印象を受けますが、実際にはアプリケーションやコードを実行する為のサーバは存在しています。でも、クラウドサービス提供側(AWS等)が実際のサーバーを用意し、管理してくれるので、管理者はクラウドにあるサーバの存在さえも意識する必要がありません。
サーバレスのメリット
先程、サーバの存在を意識する必要が無いと書きましたが、そうなると何が嬉しいのでしょう？
初期費用と手順の簡略化
例えば、Webサービスを提供する場合、ざっくり考えても以下の作業が必要となります。
- サーバを用意する（※1)
- サーバーに必要なミドルウェア、ソフトウェアをインストールする（環境設定）
- サーバに実装したアプリケーションをデプロイする
※1 クラウドを採用しない従来の方式であれば、サーバーを置く場所の確保から、サーバを調達して、OSをインストールすることから始める必要があります。
サーバレスの場合、上記のうち「アプリケーションをデプロイする」という事だけ行えばよくなります。
最初にサーバレスの設定など、必要な作業をUI上で行う必要はありますが、一度やってしまえば後は基本的に管理は不要です。
運用コスト低減
物理サーバであれば電気代が掛かりますし、クラウド上のサーバ(EC2等)であれば稼働している時間（基本的に24時間)の利用料が掛かります。しかし、サーバレスは使うサービスにもよりますが、使った分だけの費用が発生します。例えばAWSのLambdaであれば処理を実行している時間だけの課金となります。しかも100ミリ秒単位の課金なので無駄がほとんどありません。
また、自社管理やクラウド上のサーバであれば、運用中にはアクセスの増減に応じて、サーバを増強する必要も出てきますし、OSやソフトウェアの脆弱性に対応するためのアップデートにも気を使う必要があります。
リソースの最適化
アクセス増加やデータ量増加に伴う負荷上昇時の対応を考えてみます。
自社管理のサーバーであれば、CPUやメモリなどサーバのスペック自体を上げるか、別のサーバを追加して負荷分散を行う必要があります。また常にサーバーの使用量を予測し、十分なリソースを事前に用意しておく必要があります。仮想サーバであっても同じようにスペック自体を上げるか、別の仮想サーバを追加して負荷分散を行う必要があります。
一方、クラウドの仮想サーバであれば、オートスケーリングという負荷に応じて自動的に仮想サーバを増減する仕組みが使えます。サーバレスは、クラウドサービスと同じく、負荷に応じて自動的にオートスケーリングしてくれるので、運用・管理の手間が省けます。
サーバレスのデメリット
サーバレスにも当然デメリットがあります。
既存の資産(コード)が使えない事がある
これまでサーバ上で稼働させていた資産（コード）が、そのままではサーバレス環境で使えない事があります。例えば、AWSのLambdaは、開発言語としてJavaやC#、JavaScriptなど主要なものはサポートしていますが、Lambda上で動かす為の規則に則ったコードに修正が必要だったりします。
ベンダーロックインされやすい
AWSやMicrosoft、Googleなどがサーバレスのサービスを提供していますが、それぞれ独自の技術・仕様となっているので、特定のベンダーの技術に依存しやすくなります。
世界中の企業が利用しているので、いきなりサービス停止なんていう事は無いと思いますが、各ベンダーの特徴を考慮した上で採用したいところです。
処理内容に制約がある
サーバレスのサービスによっては、何らかの機能制限がある場合があります。
例えば、AWSのLambdaであれば、処理時間は最大15分、リクエストやレスポンスのデータは6MBまでといった制限があります。動画の様に重いデータを直接処理する事はできないので、そのような場合は他のサービスと連携する必要があります。
個人的には、他のサービスとどう組み合わせて必要な機能を実現するかを考えるのが、エンジニアとして楽しい部分だったりもします。
学習コストが掛かる
上に書いたデメリットに絡んできますが、サーバレスで使うサービスの特性や制限、使い方などの学習が必要となります。場合によっては、技術者の教育や確保が課題となることがあります。
従来型の開発とサーバレスを比較
新しいサービスをWebアプリケーションとして作ることを想定して、従来型の開発とサーバレスでの開発をざっくりと比較してみます。
前提
従来型の開発は、自社管理の物理サーバを利用する事とします。
リリース直後のWebアプリケーションは、まだ認知度が低く1日のアクセスは数十件〜数千件程度ですが、ある日、有名人の誰かがSNSで紹介してくれた事で話題となり急激にアクセスが増える事を考慮しておきましょう。
比較表
| コスト | 従来型の開発 | サーバレス |
|---|---|---|
| 初期コスト | サーバの調達費が必要。 | なし。 |
| 開発コスト | スクラッチ開発が基本となるのでコストは高い。 | サーバレスのサービスを組み合わせる事でコストを削減できる。 |
| 運用コスト | 固定。基本的に24時間。 ピークに合わせた構成にするとコストが跳ね上がる。 | 変動。アクセス数、処理時間による。 収益と費用がある程度比例する。 |
もう少し細かく見ていきましょう。
初期コスト
ここで言う初期コストは、インフラの準備に掛かるコストとします。
従来型の開発で物理サーバを用意する場合はサーバの導入コストが掛かります。ピーク時のアクセス数を考慮し、サーバのスペックを選定し、最初のうちは不要な台数のサーバーを用意する必要があります。
一方、サーバレスは従量課金となる為、初期コストは基本的にゼロです。
開発コスト
従来型の開発は、基本的にゼロからのスクラッチ開発となる事が多いので、設計・実装のコストが大きくなります。もちろん、既存の資産を有効利用する事で効率アップは可能です。
サーバレスの場合、クラウド上に用意されているサーバレスの様々なサービスを組み合わせる事で、開発コストを大幅に減らす事が可能です。例えば、AWSのAppSyncを使えばデータストアから必要なデータを取得する機能(API)を、ほんの少しのバックエンド実装だけで構築する事が可能です。
ただし、サーバレスの特性に合わせた設計・実装が必要となるので、従来型の開発経験しか無い場合、学習や外部の助けが必要となるため、コストが膨らむ事もあります。サーバレスの経験が豊富な人材を確保する事が重要です。
運用コスト
リリース直後（＝利用者・少）
従来型の開発は、リリース直後の利用者が少ない時でも、サーバを24時間フル稼働させておく必要があります。
もしリリース当初から将来の利用者増を見込んで、ハイスペックなマシンや複数台による冗長構成をしているのであれば、その分を含めて固定費として掛かります。更に、予測を間違った場合は悲惨な状況になりかねません。
サーバレスの方は基本的に処理時間による従量課金である為、利用者が少ない時は処理時間も短くなり、費用を安く抑える事が可能です。
SNSで紹介されて急激にアクセス増加（＝利用者・多）
従来型の開発は、ピーク時のアクセスを見込んだマシンスペックにしていたり、冗長化構成による負荷分散、オートスケーリング（※）の設定をしていれば、急激なアクセス増加にも耐えられますが、もし単一サーバで想定以上のアクセスがあった場合、最悪はサーバ負荷に伴うサービス停止に追い込まれる可能性があります。
※ オートスケーリング：負荷に応じて自動的にサーバ数が増減する仕組み
一方、サーバレスの方はアクセスの増加に応じてオートスケーリングしてくれるので、対応に手を取られる事も無いし、負荷によってサービス停止に追い込まれる危険性が少ないです。
アクセス増加により、処理時間も増加するので費用は上がっていきますが、収益も上がっているはずです。収益と費用がある程度比例しているのは分かりやすいですね。