サーバーレスの理解とメリット・デメリット（2020年版）

はじめに

「サーバーレス」を周りの人に説明することが増えてきているので、現時点での考えをまとめたいと思います。
「サーバーレス」自体、現在進行形で進化しているアーキテクチャ・考え方のため、人によって概念や意見に幅があると思いますが、ここでは、自分的まとめとして整理します。

私自身は、以下のようなバックグラウンドのため、それを前提とした内容になっています。

• AWSをメインで利用
• 開発はPythonメイン、たまにJava／Goを利用
• デプロイツールとしては、ServerlessFrameworkを利用

他の観点から、追加や相違となる内容があれば、ぜひコメントを頂ければ幸いです。

サーバーレスとは何か？

まず、2020年6月段階でのサーバーレスの一般的な説明としては、以下のように言えると思います。

• サーバーのリソースを意識しない ＝ サーバーの管理・運用が不要である

その上で、いくつかの観点でサーバレスを説明します。

サーバーレスの位置づけ

仮想マシン／コンテナ／サーバレスの一般的な比較としては、以下のような内容になります。

特性	仮想マシン	コンテナ	サーバーレス
拡張の単位	仮想マシン	アプリケーション	機能
存続期間	数日から数か月	数秒から数分	数ミリ秒から数秒
パフォーマンス	予測可能	予測可能性が低い	予測可能性が最も低い
運用コスト	高	中	低
運用管理性	高	中	低
プロバイダー・ロックイン	中～高	低	高
（出典：ガートナー）

CNCF（Cloud Native Computing Foundation）におけるサーバーレスの定義

CNCFでは、サーバーレス・コンピューティングのホワイトペーパーを公開しています（2018年）。
ここでは、以下のように定義されています。

A serverless computing platform may provide one or both of the following:

1. Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions, scaling without the need to manage servers or any other underlying infrastructure.

2. Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service that auto-scales and operates transparently, this appears to the developer to be serverless.

「FaaS」は、AWS Lambda、Azure Functions、Google Cloud Functions などの関数単位でデプロイ／実行できる仕組みを指します。イベントをトリガーに関数が実行され、その関数はエフェメラル（短命で、1回の呼び出しに対してのみ持続する）です。
この仕組みが、それまでの仮想マシンなどの「サーバー」を準備する、という状況を変え、サーバーレス自体の概念を広めるキッカケになったと捉えています。
また、クラウド上での実行に限らず、OpenFaaSやKnativeといった、Kubernetes上で構築可能なFaaSプラットフォームもあります。

「BaaS」は、認証やデータベースなど、アプリケーションが必要とする機能をAPIを通じて利用できるようにしているサービスを指します。「Functional SaaS」という呼び方をされるサービスもこちらに含まれると考えています。
主なサービスの例としては、認証サービスであれば、Auth0やAmazon Cognito、データベースサービスとしては、Amazon DynamoDB、Azure Cosmos DB、Google BigQueryなどがあります。単一のサービスだけではなく、モバイルバックエンド（mBaaS）として様々な機能を提供するFirebaseなどもあります。

簡単に言えば、「FaaS」は独自のビジネスロジックを動作させることが可能なサービス、「BaaS」は必要な機能を選択して利用できるサービス、という内容になります。どちらの場合もサーバーの運用自体は考慮する必要がありません。

現在のサーバーレスの範囲（個人的な見解）

上記の通り、CNCFでは「FaaS」と「BaaS」のどちらか、もしくは、両方をサーバーレスと位置づけていますが、サーバーレス自体、現時点でも進化の真っ只中であり、その範囲も、サーバーレスという用語が登場した当初から大分変わってきている認識です。
私自身は、以下の内容を「サーバーレス」の範囲として捉えています。

• FaaS（Function as a Service）
  • サーバーレスのメイン処理部分。
  • 例：AWS Lambda、Azure Functions、Google Cloud Functions
• CaaS（Container as a Service） without Orchestration
  • サーバー／クラスタ管理の不要なコンテナサービス。「サーバーレスコンテナ」という呼ばれ方もする。
  • ただし、Kubernetesに代表されるコンテナオーケストレーションは含まない。
  • 大量のアクセス数や、比較的長い時間での実行など、FaaSだけでは対応しきれないところで利用が増えている。
  • 例：AWS Fargate、Azure Container Instances、Google Cloud Run
• サーバーレス・コンポーネント群
  • サーバーレスのサービス同士を連携させ、より広範囲・高機能なサービスやアプリケーションを実現させるためもの。
  • BaaS／Functional FaaS なども含まれるとする。
  • 例：AWSの場合、StepFunctions、DynamoDBやS3などのイベント通知（Trigger）、Cognitoによる認証サービスなど。
  • ※ Serverless Components ではない。

Amazon Aurora Serverless、Azure SQL Database serverless などの「サーバーレス」と名前が付いたDBサービスもありますが、一般的なDBサービスが固定のリソースを確保（プロビジョニング）して動作するのに対して、これらは、可変のワークロードへの対応、一定期間アクセスがないと自動的に停止する、といった特長を持つので「サーバーレス」という名前が付けられています。
ただ、ユースケースが限定されたり、既存のDBの機能をそのまま利用できるわけではなかったりと、開発／運用で注意する点がいろいろとあるので、個人的には、個別に説明するようにしています。

サーバーレスの特長

• サーバーの運用が不要
  • サーバーやOSなどのインフラに対するプロビジョニング・維持管理の作業が不要となります。これまで、それらの作業に費やしていた手間や時間を大幅に削減することが可能です。
• 柔軟なスケーラビリティ（Scalability）
  • 事前に必要なキャパシティを考慮しなくても、リクエスト数や負荷によって自動的にスケーリング（拡張／縮退）されます。
• 可用性（Availability）・回復性（Recoverability）の向上
  • 多くのサーバーレスのプラットフォーム／コンポーネントには、冗長化の構成などを意識しなくても、デフォルトで可用性と耐障害性機能が備わっています。
• 利用した分だけの課金（Pay-as-you-go）
  • 実行した分だけの課金とあり、リクエストがないアイドル時は費用が発生しない、もしくは、最小限の費用だけになります。
  • また、その費用は、サーバー単位ではなく、実行時間や利用したリソースに基づいて算出されます。

サーバーレスを導入することによる変化

イベントドリブンなモダンアーキテクチャの実現

サーバーレスアーキテクチャのベストプラクティスに沿って開発を進めていくと、自ずとイベントドリブンなアーキテクチャになっていきます。これは、そのような設計がプラットフォームによって（良い意味で）強制されたり、そのためのサービスが揃っているためです。

イベントドリブンなアーキテクチャは、簡単に言うとマイクロサービス指向における「コレオグラフィ」を実現するものになります。通常のサービス開発では「コレオグラフィ」などは、それなりの経験・スキルのあるアーキテクトが設計しないとうまく実現できていないケースが多くあると感じますが、サーバーレスを導入することによって、自然とそのようなアーキテクチャが手に入ります。これは非常に大きなメリットと言え、イベントドリブンなアーキテクチャになることで、サービス間は疎結合になり、スケール性や拡張性に優れたシステムを実現することができます。

API First な開発

FaaSの活用がメインになってくると、サービスはAPI中心になってきます。FaaSの処理単位が、APIとなること多いためです。
開発チームは自ずと API First な開発になり、また開発の単位もAPIベースになります。これにより、フロントエンドチーム<->バックエンドチームとの調整が容易になったり、サービス開発の独立性と平行性が上がったりするため、開発チームのアジリティが向上します。

モダンなアプリケーション開発のプラクティスとなっている「Beyond the Twelve-Factor App」でも、API First がそのひとつに挙げられています。自社の例でも、初めてフルサーバーレスアーキテクチャでサービス開発を行った際に、短期間で複数メンバが平行で開発を行いつつも、サービス全体の結合時に全く不整合が発生しなかったときには、感動モノでした。

上記以外にも「Beyond the Twelve-Factor App」で示されているプラクティスは、サーバーレスを導入すると、自ずと実践される要素が多くあります。
それ自体を意識していなくても、自然と実践されるようになっているのは、優れたアーキテクチャ／プロセスと言えると思います。

メリット・デメリット

これまでのサーバレスの概念を通して、メリット・デメリットを整理します。
感じるメリット・デメリットは、ロールによって異なるため、ここでは3つの視点に分けてを整理します。

視点	メリット	デメリット
ビジネス	・利用した分だけの課金となり、多くの場合、ランニングコストの低減につながる。 ・ビジネス発展／競争力向上に向けたITシステムのアジリティを向上させやすくなる。 ・コスト面／開発スピードを踏まえて、新サービスのチャレンジをしやすい。	・ベンダーロックインとなり、一度開発したモノを他クラウドベンダーへ移行するのは困難である。 ・サーバーレス・アーキテクチャで適切に開発／構築できるエンジニアは少なく、人材確保が難しい。
開発	・ビジネスロジックに集中して開発できる。 ・自動でスケールされため、冗長化の考慮／対応などは最小限で済む。 ・非同期／ステートレスな構成で、疎結合な開発を行いやすい。 ・マイクロサービスを実現しやすい。	・ベンダーロックインとなり、クラウドベンダーが異なれば、機能性や実装方法も大きく異なる（実行時間やデプロイサイズなどに制限がある）。 ・アプリケーションのデバッグは難しくなる。 ・低レイテンシを求められる機能には向かない。
運用	・サーバーの構築やパッチ適用など、構築・運用にかかる手間が不要となる。 ・サーバーダウンによる障害対応などが軽減される。	・複数のサービスが関連して動作するため、一般的なアプリケーションよりもモニタリングなどは複雑になる。 ・ランタイムの大部分がクラウド内部に隠蔽されているため、問題解析が難しくなる。 ・クラウドインフラの障害に大きく影響される。

まとめ

私自身は、2016年に行われた「ServerlessConf Tokyo」で、サーバーレスの概念に興味を持ち、そこから、既に10件を超えるサービスをフルサーバーレス（サーバーなし、RDBなし）で構築してきています。
以前は、サーバーレスでのアンチパターンや制約事項とされてきた、RDBへの接続やコールドスタートなども、今では解決する手段が登場しており、それによって、サーバーレスの適用範囲は、より拡張されてきていると実感しています。

サーバーレスにも当然デメリットはありますが、個人的には、デメリットを超えるメリットがあり、今後もサーバーレスへの潮流はより加速していくものと考えています。

AWS西谷氏の言葉を借りれば、今年がサーバーレス元年 !!

今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから.

・カスタムランタイムで実質どんな言語でも利用可能
・VPC利用時のコールドスタート改善
・Provisioned Concurrencyでスパイク対応も可能
・RDS ProxyでRDBとの接続が現実的に

これまで5年で受けたフィードバックがついに結実. 強い

— Keisuke Nishitani (@Keisuke69) January 19, 2020

本記事は、個人的見解も多く含みますが、皆さまのサーバーレスの採択の手助けになれば幸いです。

付録

用語

ここでは、よく用いる用語について、その意味を定義しておきます。

• サーバーレスコンピューティング
  • 「サーバーレス」自体と、ほぼ同意義です。
  • 広義の意味では、サーバーレスで処理を行うこと、狭義の意味では、FaaSやサーバレスコンテナなどサーバーレスの処理を実現するためのリソースを指します。
• サーバーレスアーキテクチャ
  • サーバーレスの考え方、および、サーバーレスのコンポーネントを用いたシステムの設計、および、その方法論。
• サーバーレスシステム（サーバーレスアプリケーション）
  • サーバーレスアーキテクチャに基づき構築されたシステム（アプリケーション）。

参考

• 今なぜサーバーレスなのか （吉田 真吾, 2016）
• Going Serverless, Building Applications with No Servers （Keisuke Nishitani, 2016）
• サーバーレス・アーキテクチャ概要 （吉田 真吾, 2017）
• Serverless Architectures （martinfowler.com, 2018）
• Serverless Guide（Serverless,inc. 2018）
• サーバーレスのメリットを最大限引き出すためのシステム設計手法と考え方 （toricls, 2018）
• Serverlessを支える技術 （nekoruri, 2019）