弊社MMMはサーバーレス開発・運用を6年ほど続けてきました。その過程で様々な知見をためてきました。今回は、AWSのサーバーレスの中でFaaS (Function as a Service)をターゲットに、メリット・デメリット、そして最後にサーバーレスの使いどころについてご紹介いたします。本音ベースの考えをお伝えしたいと考えています。

なお、本記事はWebアプリケーションのアーキテクチャを考えるCTOの方、アーキテクトの方を対象にした記事となっています。

現在、AWSとしてはFargateなどもサーバーレスに分類しているようですが、今回は対象外としています。また、内容は一部過去ブログサーバーレス開発を5年続けてきたMMMがサーバーレスのつらさを紹介しますにかぶる部分もありますが、ご了承ください。

サーバーレスのメリット

スケールする

適切に設計すればほぼ無限にスケールします。また、適切に設計しなくてもだいたいスケールします。
ただ、以下のような各マネージドサービスの各種制限値によりスケールしきれないことがあるので注意は必要です。きちんとメトリクスを取って監視しておくとよいでしょう。

• Lambdaのメモリ
• Lambdaのディスク容量
• Lambdaの実行時間
• API Gatewayのタイムアウト
• DynamoDBのプロビジョンドキャパシティユニット

高可用性

高可用性において意識するべきところが少なく、自然と高可用性が担保されます。
ただし一点気をつけなければならないのは、サーバーレスにおいては多数のコンポーネントを直列に組み合わせることが多く、サービス全体のSLAとしては各コンポーネントのSLAを掛け算したものになってきます。したがってSLA自体はそこまで高くならないケースが多いです。

運用負荷軽減

サーバーの管理から解放される、OS等のパッチ適用をする必要もない、このメリットは非常に大きいです。
ただし、コンポーネントが分散しているため、一度障害が発生すると調査コストは比較的高くなります。弊社でもまだナレッジがたまりきっていないのが正直なところであり、障害調査コスト軽減のため運用チームで日々改善に取り組んでいます。

ほぼ完全な従量課金

クラウドの価値として重要な従量課金ですが、サーバー型では完全な従量課金とはなりません。しかし、サーバーレスではほぼ完全な従量課金となります。サービスが使われなければ利用料金はほぼゼロです。ただ、かなり大きくスケールした場合はサーバーレスが高くなるケースも多くあるでしょう。

サーバーレスのデメリット

レスポンスタイムの遅さ

現時点で、Lambdaは起動に少なからず時間がかかるため、シビアに性能が求められる場面では利用しないほうがベターです。LambdaのProvisioned Concurrencyを利用すればLambdaの同時実行数を事前にプロビジョニングできますが、これは常に使うべきものではなく、突発的なアクセス増に対応するのが主目的になるかと考えています。

テストのしにくさ

サーバーレスにおいてはローカルの開発環境でテストを完結させることが非常に難しいです。したがって最終的にテストは実際のAWS環境を利用して動かして確認する必要がでてきます。

開発メンバーの集めにくさ

サーバーレス開発を経験したことのあるエンジニアはまだまだ少ない印象です。サーバー前提のシステムがきちんと開発できる、かつAWSのマネージドサービスに知見があるエンジニアであればスムーズに開発に入れると思います。

情報の少なさ

上記、開発メンバーの集めにくさとも関連しているのですが、まだまだサーバーレスの情報は少ないため、手探りで開発していく意気込みが必要です。

サーバーレスの使いどころ

考えられるユースケース

AWSが形で考えるサーバーレス設計という記事を公開しており、よく整理されています。ただし、ある程度具体的なユースケースと、一般的なユースケースが混ざっているので注意が必要です。

例えば、AWSサーバーレス多層アーキテクチャは、従来型の多層アプリケーションをサーバーレスにするという、非常に一般的なユースケースになっています。しかし、あらゆる多層アプリケーションをサーバーレスにすればいいというものではありません。逆に言えば従来の多層アプリケーションで問題がない場合にサーバーレスを積極的に選ぶ理由はないと考えます。

しかし、例えば「画像処理 / シンプルなデータ加工」などはイベントドリブン・S3の相性などで非常にサーバーレスに適したケースであることが多くあります。したがって基本は従来型の多層アプリケーション、それに加えてサーバーレスに適したユースケースについてはサーバーレスで実装、というのが基本的には良い使い方になるかと思います。

弊社での例をご紹介

先ほど書いたように画像処理の部分だけをサーバーレスで実装した例です。

弊社で開発したWebで試験が受けられるシステムがあります。そのシステムはモノリシックなRailsアプリケーションとなっていました。
そこに、動画試験機能 (動画を閲覧し、それに対して動画で回答する機能) を追加したいという要件がありました。動画試験においては、「キャプチャした細切れの動画をアップロードし、それらを結合する処理」が必要でしたが、Railsアプリケーションに実装するよりもイベントドリブンなサーバーレスアーキテクチャが適していたため、動画試験機能についてはサーバーレスで開発しました。

アーキテクチャ図は以下の通りです。

従来型の多層アプリケーションとサーバーレスを組み合わせた良い例だったと思います。

なお、注意事項ですが、作り捨てのLambda関数以外は、サーバーレスコンポーネントのデプロイは必ずAWS Serverless Application Model (SAM) やServerless Frameworkなどのフレームワークを利用しましょう。手作業で実施するとカオスになります。

まとめ

来年のサーバーレス業界の動向を楽しみにしています！

shimo