サーバレスアーキテクチャとは何か？～AWS LambdaとAPI Gatewayによる簡単なAPIの実装を試す

サーバレスアーキテクチャによるアプリケーション開発実践入門 第1回

　サーバレスアーキテクチャという単語はバズワード化していますが、単語そのものが一人歩きしており、実際に使ってみようとなるとAWS Lambdaを少し触ってみた程度、という方が多いのではないでしょうか？ 本連載では、AWSを利用したSPA （Single Page Application）の開発を通じて、サーバレスアーキテクチャの考え方を知っていただき、Webアプリケーションとして作成していく際にどのような構成を取ればよいのか、開発環境やテストなどはどのように行えばよいか、実際のコードを交えながら解説していきます。また、連載の終盤では、ベンダーロックインのデメリットに対する対策として、AWS以外のサービスを利用した場合にはどのような構成を取れるか、などについても触れていきたいと考えています。

サーバレスアーキテクチャってなんだろう？

　現在クラウドサーバーの主流となっている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のような違いがあります。

表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のようになります。

表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を用いて簡単なアプリケーションが開発できるようになることを目的とします。