サーバーレス・アーキテクチャの話

どうも、吉田真吾（@yoshidashingo）です。

re:Inventで AWS Lambda が大幅アップデートされたことをきっかけに、サーバーレス・アーキテクチャという単語をよく聞くようになりました。

自分も現在、サーバーレスに作る案件があり、何度か説明してるときに、単語自体はとてもイージーですが、会話する相手によって概念や実装のディテールがフワっとした感じに伝わってしまうので、コンパクトに上手い説明がしたいなと思っているのが現状です。

単純な実装方法にいきなり落とし込んで話すと「サーバー代は別に気になってないので」って返されるのがオチです。運用まで含めて変化を促すことができるはずなのに、分かってる人だけ使えばいいと思われちゃうのはちょっと悲しいですね。

(ARC308) The Serverless Company: Using AWS Lambda from Amazon Web Services

www.slideshare.net

サーバーレス・アーキテクチャについて話してること

• サーバーレス・アーキテクチャを採用するねらいは、マネージド・サービスを使う理由としてよく言われてきたことと同じで「ビジネスへの集中」ということだと感じています。
• AWSにおけるサーバーレス・アーキテクチャの構成要素は Lambda に限らず裏側のサーバー台数というリソースを意識しない点で、 S3 や Cognito, DynamoDB, API Gateway, SNS, SQS などなど含まれている認識ですが、その他のマネージド・サービスとしてRDSやRedshift, ElastiCacheなどスケールの管理が必要なものを含むかどうかは意見が割れそうです。自分は入れてもいいと思いますが、ここの厳密さの議論は不毛なのでどちらでもよいです。
• Lambda の活用イメージが人それぞれ興味範囲によって違うようで、全般的にさらっと触れてもいまいちピンとこないらしいので、フロント／バックヤードそれぞれこういう使い方があるよとすると説明しやすいかなと思ってます。（後述）
  • API GatewayやCognito、DynamoDBと組み合わせた「APIフロントとしてのサーバーレス」
  • DBレプリケーションや監査ログのデータ連携、AWSの各種サービス内のルールセットにLambdaを活用した「バックヤードとしてのサーバーレス」

サーバーレス・アーキテクチャの効果について

• イベント・ドリブンだからリソースの利用とそれに対する課金が合理的という話
  • リソースの調達、課金がイベント単位であり、リソースを使ってない期間における課金は（永続化（DBを含むストレージ）のレイヤーを除き）発生しません。
  • 今までもSNS、SQS、ELB、転送料など、使った分だけの課金というスタイルはあったが、サーバーリソースでもその合理的な方法が提供されたということととらえてます。
  • サーバーレスで大幅にコスト削減できるんですか？という話についてはこのとおり、コスト効率の合理的な仕組みがそういう側面につながることが多いだろうという話で返せるだろうと思います。
• サーバーのスケールの管理や保守対応をゼロにまで削減できる可能性があるため、ユーザーはビジネスやアプリケーションの開発に専念できます。
  • リソースが大量に必要になったときでもキャパシティ拡張の運用をしなくてよく、全く使ってないときにも課金を節約するような運用をしなくてもよいです。
  • インフラの保守対応のコストが不要になる可能性が高いです。
    • サーバーを24時間体制（オフィスにいなくても、常に対応可能という状態で）で監視しなくてもよくなります。
    • 運用保守をアウトソースしてる場合、委託先のMSP事業に関して破壊的な費用削減になりえますが、より価値が高く、要求水準の高い部分に集中できるという側面もありえます。
      • 例えばさほどサービスレベルは高くなくていいのにバックアップやログを吸い上げるマネージャーサーバーなどが、MSPは運用保守しなくてよくなり、お客さんは保守費用が不要になることで、両者嬉しい状況になります。
• アプリケーションのマイクロサービス化
  • API Gateway にキャッシュや認証、スロットリングを任せることができます。
  • Lambda Function からS3やDynamoDBなど外部リソースにアクセスすることでデータ操作について自由度の高いアプリケーション処理が可能です。今までLambdaの設定可能なタイムアウト値が1分だったのが、5分にまで拡張されたので、さらに自由度が上がってるなと感じます。

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!事例における動画変換処理
• リアルタイムなETLなど、データの連携処理
  • S3にアップロードされたファイルをLambdaで加工してDynamoDBに入れる
  • Kinesis Streamsに受け取ったデータをLambdaで加工してRedshiftに入れたり、SNSに通知をする
  • DynamoDBへのPutをトリガーにLambdaで別のDynamoDBのテーブルにレプリケーションしたり、Redshiftに入れたりする
  • SNSの通知をトリガーにLambdaを使い別のSNSのトピックにパブリッシュしたり、KinesisにPutしたりする

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＝リソースを事前に指定（サーバー台数など）して確保する
  • Lambdaを中心としたサーバーレス＝リソースは完全に実行したもののみ確保される、キャパシティは気にしなくていい
• IaaSであるEC2が今まであり、その自由度を利用して様々な要件が実現されてきました。それをLambdaでサーバーレスに持ち上げるというアプローチが多そうなので、かなりのシステムでどこをサーバーレス化できそうか比較的容易に見つけられるのではないかと思います。
  • 冒頭のスライドの冒頭部分もこのアプローチで、わかりやすいですね。
• 自由度という点でいえば、コードの中でクレデンシャルを意識しなくても、IAM Roleに頼れるという点もAWSでやっている特徴のひとつですね。

さいごに

• 全体的に書いたつもりだけど、直近でアプリは書いてないんでインフラ寄りなサーバーレスの意見という感じにはなりましたね。
• アプリやフロントとしてのサーバーレス、インフラとしてのサーバーレスと、説明上便宜的に分けて書いてみたが、全体的なアーキテクチャを考えるときにはそこは垣根を置く意味はなさそうに感じてます。
• サーバーレス・アーキテクチャについて誰が定義するというものでもないのであれですが、いろんな角度の意見をお聞きしたいのでぜひぜひご意見ください。