サーバレスアーキテクチャってなんだろう？
現在クラウドサーバーの主流となっているAWS EC2では、クラウド上に仮想サーバーを作り、それに対して時間単位ごとの料金を計算して請求する仕組みになっています。このモデルは、ユーザーが大量にアクセスしてきた場合でも、クラウド上のサーバーを次々に起動し、処理を分散することによって大量のアクセスを捌くことができます。また、ユーザーのアクセスがある程度安定している時には、クラウド上のサーバーを最低限必要な数に抑えることにより、比較的安価に流動性のあるユーザー数に対応できることから多くのサービスで採用されています。
このようなIaaS（Infrastructure as a Service）型サービスの場合、ホスティングサーバー同様に、クラウドサーバー上のOSやミドルウェア（ngixnやApacheなど）の管理・セキュリティアップデート等が必要であったり、高いパフォーマンスを出そうとするとそれなりのチューニングが必要になるなど、フロントサイドエンジニアや、インフラを触ったことのないアプリケーションエンジニアにとっては敷居の高いサービスでもありました。
一方、今回の連載で扱うAWS Lambdaは、FaaS（Function as a Service）型のサービスです。
IaaSやPaaSと比較して、FaaSを用いたシステムはステートレスな関数の集まりであることが強制されるため、自然とマイクロサービスの組み合わせとなることが特徴です。
FaaS型のサービスは、原則としてユーザーからのアクセスなどによって、プログラムが動いている間のみ課金が行われます。また、IaaS型のサービスと異なり、サーバー自体に対するパフォーマンスチューニングやセキュリティアップデート等はFaaSサービス提供側が行ってくれます[1]。
FaaS型のサービスには、AWS Lambdaの他にGoogle Cloud FunctionsやAzure Functionsなどもあり、いずれもサーバー自体に対するパフォーマンスチューニングやセキュリティアップデート等はFaaSサービス提供側が行ってくれます。
IaaS及びPaaS、FaaSでは大まかに表1のような違いがあります。
| IaaS | PaaS | FaaS | |
|---|---|---|---|
| 提供範囲 | ネットワーク、仮想マシン、OS | アプリケーションを開発・実行するためのプラットフォーム | スクリプトの実行環境 |
| 主なサービス | Amazon EC2、さくらのクラウドなど | Heroku、Google App Engineなど | AWS Lambda、Azure Functionsなど |
| 触ることができるレイヤー | OSレイヤーからアプリケーション、ファンクションまで | アプリケーションとファンクション | ファンクションのみ |
| 開発のしやすさ | オンプレミスの環境とほとんど変わらない | さまざまなドキュメントやノウハウが日本語で検索できる | 英語の公式ドキュメントは存在するが、少し難しいことをしようとすると、公式ドキュメントにも載っていないことが多い |
| Dockerなどのコンテナ環境整っている | 整っている | 整っている | docker-lambdaなどを利用すればある程度可能 |
| 現時点で利用可能な言語 | ほぼどんな言語でも利用可能 | Ruby、PHP、Node.js、Python、Java、Go、Clojure、Scala | Node.js、Python、Java |
| 保守の特徴 | 正しく運用しようとすると、ネットワークの知識や仮想化の細かい知識が必要 | IaaSに比べると簡単だが、それぞれのサービス独自の制約があるため、使いこなすにはそれなりにノウハウが必要 | エラー時の通知や、設計をきちんと行うことができれば、保守の難易度は高くない |
| 費用の発生 | 原則として仮想マシンの起動時間中は常に費用が発生する。また、オートスケール後にスケールダウンを忘れるなど、人的なミスにより費用が膨れる場合もある | アクセスが来ない場合は起動せずに待機する、という選択肢を取ることはできるが、実際には常時稼働することになるパターンが多い。IaaSと比較するとスケールアップやスケールダウンの設定は行いやすい反面、細かいチューニングは難しい | ファンクションが呼ばれてから、ファンクションが終了するまでの間のみ課金される。また、スケールアップやスケールダウンはサービス側が自動的に行うため、チューニングの必要もない[2] |
また、上記を踏まえた上でそれぞれの比較を行うと、表2のようになります。
| IaaS | PaaS | FaaS | |
|---|---|---|---|
| 構成の自由度 | ◎ | ○ | ○ |
| 開発のしやすさ | ◎ | ○ | ○ |
| 保守のしやすさ | ○ | △ | ◎ |
| 言語選択の自由度 | ◎ | ○ | △ |
| CI連携のしやすさ | ○ | ◎ | △ |
| ログの取りやすさ | ◎ | ○ | ○ |
| 費用の安さ | △ | △ | ◎ |
IaaS及びPaaS、FaaSそれぞれのサービスの違いを大まかに把握していただけたかと思います。
本連載では、FaaSサービスの祖とも言えるAWS Lambdaを取り上げながら、実践的なアプリケーションを作成していきます。
注
[1] サービス提供側がチューニングしてくれるのはあくまでミドルウェアアプリケーションまでです。サービスのコアとなるソースコードのパフォーマンスチューニングは別途必要となります。
[2] マシンパワーが必要なファンクション単位でメモリを増やすことはあります（AWS Lambdaでは、メモリ量に比例したCPUパワーとその他のリソースが割り当てられます）。
対象読者
前提としてJavaScriptやTypeScript、HTTPステータスコード、Cookie、CDN（AWS CloudFront及びAWSS3）の知識があると望ましいですが、やや難しいと思われる箇所については補足を加え、これらの前提知識に対してあまり自身がない方でも、AWS Lambdaを用いたサーバレスアーキテクチャ構成の簡単なアプリケーションを構築できるように解説していきます。
Node.jsを触った事のない方も対象読者とし、他の言語でMVCフレームワークを使用している方にも馴染みのある言葉での言い換えや比喩表現などを極力用います。
本連載のゴール
本連載ではAWS上にある各種サービスを、サーバレスアーキテクチャを用いて連携させ、一般的なWebサービスに必要とされる認証機能やデータの永続化、そしてSwaggerを用いたAWS Lambda及びAPI Gateway、SPAの代表的なフレームワークであるAngularを用いて簡単なアプリケーションが開発できるようになることを目的とします。
