サーバレスとは？クラウドサーバとの違いやメリット・デメリットを解説

サーバレスとは、自社でサーバを準備せずにシステム構築や運用を行えるクラウドサービスのひとつです。通常、プログラムを実行するには、アプリケーションプログラムの実行環境としてサーバを構築しなくてはなりません。また、プログラムを確実に実行するため、サーバの能力以上のリクエストが集中した場合、あるいはリクエストが集中することがわかっている場合は、サーバのメモリやストレージを増強する必要があります。

サーバレス環境の場合は、実行環境のすべてをサービスの提供会社に一任できるため、自社の担当者はサーバを意識する必要がありません。つまり、サーバは存在するものの、その準備や運用・管理に時間や人的リソースを割く必要がなくなるのです。

サーバレスと混同されがちな言葉に、「クラウドサーバ」「レンタルサーバ」があり、いずれも手元に物理サーバを置かず、面倒な構築や管理を一任できる点は共通しています。では、クラウドサーバとレンタルサーバの違いはどこにあるのでしょうか。

クラウドサーバとレンタルサーバの違い

クラウドサーバは、事業者が持っている物理的なサーバに複数の仮想の専用サーバを作り、利用者はインターネットを通じてそこにアクセスして利用するサービスです。CPUやメモリはそれぞれの仮想サーバ内に、仮想的に作成されます。初期費用がかからず、費用は従量課金制で、サーバの稼働時間で決まります。
一方のレンタルサーバは、その名のとおり物理的なサーバをレンタルし、複数のユーザと共用で使うものです。CPUやメモリは複数のユーザで共有し、それぞれのWebスペースが作られます。多くの場合、導入の初期費用に加え、月々定額の利用料がかかります。

サーバレスはクラウドサーバの一種

サーバレスは、クラウドサーバの一種です。クラウドサーバにはさまざまな利用形態がありますが、サーバレスはその中でもFaaS（Function as a Service）と近い形態といわれています。FaaSはサーバやネットワークのほか、OSやアプリケーションの実行環境もすべてクラウド事業者が提供する形です。
そのほか、APIを利用して銀行のシステムに接続するBaaS（Banking as a Service）という形態も、サーバレスと呼ばれることがあります。

自社サーバの運用に腐心する担当者にとって、サーバレスは業務の効率化と負担の軽減につながる多くのメリットがあります。ここからは、サーバレスのメリットを解説します。

コストが削減できる

サーバレスの場合、オンプレミスやレンタルサーバのように初期費用がかかりません。システムを利用した時間やプログラム実行回数に応じた従量課金制のため、利用頻度によってはかなりコストを抑えられる場合があります。また、障害対応やバックアップなどもサービス提供事業者に任せられるため、サーバのBCP（事業継続計画）対策が必要なく、その分のコストも削減できるでしょう。

サーバの保守管理・運用が不要

自社でサーバを構築・運用する場合、保守管理が必須です。しかし、サーバレスの場合は保守管理もサービス提供事業者が担うため、利用者側の人的リソースが不要です。これまでサーバ業務に従事していた人員をアプリケーション開発にシフトさせることで、より本質的な業務にリソースを集中投下できます。

サーバの数を自動的に配置できる

サーバレスでは、アクセス数やデータ数などのリソースの割り当てもサービス提供者側が行うため、ユーザ側がサーバの状況を想定して調整する必要がほぼありません。想定の負荷を超えた大量のアクセスなどがあっても、サーバが落ちることなく運用できるでしょう。

自社のシステムがサーバレスに適しているかどうかを判断するには、デメリットにも目を向けて、総合的に判断することが大切です。ここからは、サーバレス導入で考えられるデメリットについて紹介します。

処理上の制約がある

サーバレスは、サービスによっては、最大処理時間、レスポンスのデータ容量などの制限が設けられていることがあります。こうした制限を知らずに導入すると、大量のデータを処理したいときなどに対応できません。
また、ストレージがなく、ステートレスな処理や関数の実装が求められる点にも注意してください。ステートを保持できないため、アクセスごとに対応が必要です。

既存コードが使えないことがある

サービスによって、使える言語が制限されていることがあり、既存のコードがそのまま利用できない場合があります。主要言語はサポートされていますが、事前にどのコードが利用できるか確認しておいたほうがいいでしょう。

デバッグが難しい

プログラムの不具合を解消するデバッグ手段に制限がある点は、サーバレス導入の壁のひとつです。ローカルサーバではテストができず、これまでのデバッグ手法が使えない可能性があることは知っておきましょう。ローカルにサーバレスのアプリケーションを構築してテストできるツールも登場していますが、導入にコストがかかることに注意が必要です。

サーバレスのセキュリティへの責任は提供側にあると思われがちですが、そうとも言い切れません。サーバレスにすることでOSパッチの管理が不要になることDoS攻撃が阻止できるなど、セキュリティが向上する面もありますが、一般的なWebアプリケーションの脆弱性はサーバレスでもあり、対策が必要です。クラウド環境のセキュリティを考える際、こういった脆弱性に対して、いかにタイムリーに対策できるかが重要になるでしょう。
Webアプリケーションを安全に保ち、セキュリティ事故を防ぐためには、ユーザ側でも適切な対策が必要です。以下に対策の例を挙げます。

設定ミスの防止

AWS Lambdaを利用する際は、関数の公開対象が全ユーザ対象ではないこと、同じIAMロールが共有されていないこと、追跡が有効になっていることを確認してください。さらに、最新バージョンのランタイム環境が使用されていることを確認することも必要です。

依存関係の追跡

サーバレス環境の各機能で使用されている依存関係と、オープンソースプロジェクトを追跡できるようにしておきます。これによってライブラリ内の脆弱性にフラグをつけることができ、できるだけ迅速に修正できるようになります。また、脆弱なライブラリのサーバレスサービスを利用していても、継続的に監視することで、セキュリティプロセスと監査を改善できるでしょう。

Webアプリケーション層の保護

RASP（Runtime Application Self-Protection）は、Webアプリケーションやそのランタイム実行環境に組み込まれる技術で、Webアプリケーションへの不正な入力や攻撃を検知して防御する機能です。サーバレスで利用することで、動作中のWebアプリケーションのステータスをリアルタイムで監視できます。