どうも、吉田真吾（@yoshidashingo）です。
re:Inventで AWS Lambda が大幅アップデートされたことをきっかけに、サーバーレス・アーキテクチャという単語をよく聞くようになりました。
自分でも現在、出来る限りサーバーレスに作ってみようと進めてる案件があり、何度か説明してるときに、単語自体はとてもイージーですが、会話する相手によって概念や実装のディテールがフワっとした感じに伝わってしまうので、コンパクトに上手い説明がしたいなと思っているのが現状です。
www.slideshare.net
サーバーレス・アーキテクチャについて話してること
- サーバーレス・アーキテクチャを採用するねらいは、マネージド・サービスを使う理由としてよく言われてきたことと同じで「ビジネスへの集中」ということだと感じています。
- AWSにおけるサーバーレス・アーキテクチャの構成要素は Lambda に限らず裏側のサーバー台数というリソースを意識しない点で、 S3 や Cognito, DynamoDB, API Gateway, SNS, SQS などなど含まれている認識ですが、その他のマネージド・サービスとしてRDSやRedshift, ElastiCacheなどスケールの管理が必要なものを含むかどうかは意見が割れそうです。自分は入れてもいいと思いますが、ここの厳密さの議論は不毛なのでどちらでもよいです。
- Lambda の活用イメージが人それぞれ興味範囲によって違うようで、全般的にさらっと触れてもいまいちピンとこないらしいので、フロント／バックヤードそれぞれこういう使い方があるよとすると説明しやすいかなと思ってます。（後述）
サーバーレス・アーキテクチャの効果について
- イベント・ドリブンだからリソースの利用とそれに対する課金が合理的という話
- リソースの調達、課金がイベント単位であり、リソースを使ってない期間における課金は（永続化（DBを含むストレージ）のレイヤーを除き）発生しません。
- 今までもSNS、SQS、ELB、転送料など、使った分だけの課金というスタイルはあったが、サーバーリソースでもその合理的な方法が提供されたということととらえてます。
- サーバーレスで大幅にコスト削減できるんですか？という話についてはこのとおり、コスト効率の合理的な仕組みがそういう側面につながることが多いだろうという話で返せるだろうと思います。
- サーバーのスケールの管理や保守対応をゼロにまで削減できる可能性があるため、ユーザーはビジネスやアプリケーションの開発に専念できます。
- リソースが大量に必要になったときでもキャパシティ拡張の運用をしなくてよく、全く使ってないときにも課金を節約するような運用をしなくてもよいです。
- インフラの保守対応のコストが不要になる可能性が高いです。
- サーバーを24時間体制（オフィスにいなくても、常に対応可能という状態で）で監視しなくてもよくなります。
- 運用保守をアウトソースしてる場合、委託先のMSP事業に関して破壊的な費用削減になりえますが、より価値が高く、要求水準の高い部分に集中できるという側面もありえます。
- 例えばさほどサービスレベルは高くなくていいのにバックアップやログを吸い上げるマネージャーサーバーなどが、MSPは運用保守しなくてよくなり、お客さんは保守費用が不要になることで、両者嬉しい状況になります。
- アプリケーションのマイクロサービス化
Serverless Everywhere
Lambda が便利すぎて「あちこちサーバーレスにできそう」ということはわかりますが、具体的にサーバーレスに持ち上げる場所として、APIやWebフロントのアプリケーションだったり、インフラのつなぎとしてのバックヤードのサーバーレスなのかを分けて例示したほうが分かりやすいと感じてます。
APIフロントとしてのLambda利用
API Gatewayとの組み合わせ
- 佐々木さんもAPI Gatewayパターンとして紹介されている、3-Tierでサーバーレスという形
- クライアント側がファットになりがちな2-Tierと比較しても、認証自体をサーバーに閉じた範囲でできたり、開発者に求められるスキルも従来の3-Tierに近いのでバランスもよいのではないかと思ってます。
http://blog.takuros.net/entry/2015/10/19/081349
冒頭のスライドでも Sample CRUD Backend Workflow として紹介されていますが、一例は、API Gatewayで認証やキャッシュ、スロットリングを行い、トリガーでLambdaをコールして、S3やDynamoDBを使った処理を行うというものです。
バックヤードとしてのLambda利用
冒頭のスライドで紹介してたのは以下のようなパターン
- データの加工処理
- PlayOn!事例における動画変換処理
- リアルタイムなデータの連携処理
AWSサービス内のルールセットとしてのLambda利用
バックヤードっぽいところで Config Rules や AWS IoT のルールセットは Lambda Function です。APIっぽいところでは Amazon Echo の Alexa Skill Setの中身も Lambda Function です。今後AWSの各種リソースを動かすときにその裏側が Lambda であることはもっと増えていくのではないかと想定されます。
サーバーレス by default か
- アプリについて、はじめからAPI化できそう（アーキテクチャの選択ができる）なら問題ない。
- ミドルウェアの要件などでどうしてもEC2という場合は別にそこはそのままでいいんじゃないのと思う
- また、ジョブの動作が保証されたり、その実行状況を簡単にトレースできるなど（実行遅延や実行されなかった場合にCloudWatchからアラートが発行されるとか？）しないと乗せるのが難しい場面もあるのではないかと感じている。
- ただし、バックグラウンドなジョブはサービスレベルに大きな影響が懸念されないので、DR基盤やログのデータ連携基盤は積極的にすすめるべきだと思う。
おまけ
Lambda > コンテナ > VM（実行環境の提供速度）
- 一時期、EC2は起動に数分かかるけど、GCPはコンテナだから早いよね、EC2もそうならないかなみたいな話を聞くことがあったが、Lambdaならそもそもマシンというより実行環境が素早く提供されるので、コードがすぐに実行される。そもそもサーバーが素早く欲しいのではなく、素早く目的を果たすことがゴールなので、最短でコードが実行されるプラットフォームがあればいいというのは合理的だ
サーバーレスはPaaSじゃない
- マネージドなプラットフォームではあるが、いわゆる一般的なPaaSではありません
- リソースの調達、課金がイベントにひもづくため、無限にスケールすることもありあれば、ゼロもありえます。この点、一般的なPaaSだと台数のような「リソースを事前に指定して確保する」スタイルなので、「リソースは完全に実行したもののみ」というのとは根本的に違いますね。
- IaaSであるEC2が今まであり、その自由度を利用して様々な要件が実現されてきました。それをLambdaでサーバーレスに持ち上げるというアプローチであれば、かなりのシステムでどこをサーバーレス化できそうか比較的容易に見つけられるのではないかと思います。
- 冒頭のスライドの冒頭部分もこのアプローチで、わかりやすいですね。
- 自由度という点でいえば、コードの中でクレデンシャルを意識しなくても、IAM Roleに頼れるという点もAWSでやっている特徴のひとつですね、そういえば。