【レポート】サーバーレスアーキテクチャ：30分で30連発 #reinvent #SRV213

原題と概要

Thirty Serverless Architectures in 30 Minutes

Don’t blink because in this session, we quickly show you thirty different architectural patterns that you can use with AWS Lambda to solve everything from basic infrastructure automation tasks to building chatbots. We cover the services that connect to AWS Lambda and help you create serverless applications that can respond to requests from many AWS services today. We will also discuss how to secure these serverless applications, deploy them, monitor them, and profile them for issues. By the end of this session, expect to have ideas on how serverless architecture can improve your life.

レポート

別の同題セッションで、30分スピーチ、30分ディスカッション形式のものがあったようです。私も当初そちらに参加する予定だったのですが、想定よりもあまりに人が多く入室しでず断念。別の時間枠で確保されていたこちらへ参加しました。

本セッション、前半30分は、基本的なものを含むサーバーレスアーキテクチャ30パターン、後半30分は、ディスカッションの代わりにサーバーレス環境への基本的なデプロイメントと運用に関する話でした。

サーバーレスアーキテクチャ30連発

前提：サーバーレスアプリケーションの定義

サーバーレスアプリケーションの流れは以下のようなものです。

1. データステートの変更やエンドポイントへのリクエストをきっかけとしたイベントソース
2. ファンクション
3. サービス

つまり、イベントソースを起点としてファンクションが起動し、ファンクションがサービスへリクエストします。本セッションではサーバーレスアプリケーションとはこのようなものを指します。

前提：Lambda Function の実行モデル

• 同期（プッシュ型）：APIゲートウェイのバックエンドなど
• 非同期（イベント型）：SNSやS3をトリガーにした処理
• ストリームベース：DynamoDBやKinesisの変更をストリームに流してLambdaで処理

1. S3 + Lambda

S3バケットにオブジェクトをPUTしたら、 Lambda Function が起動する構成です。

2. SNS + Lambda

SNS トピックにデータが PUSH されれると、 Lambda が起動する構成です。

3. SDK + Lambda

Invoke API を通して、SDK クライアントが直接 Lambda を起動する構成です。

4. CloudFront + Lambda@Edge

HTTP(S)リクエストが CloudFront にルーティングされたときに、 Lambda@Edge を起動します。

5. Step Functions + Lambda

Step Functions のワークフローが実行された際に、１つ以上の Lambda Function を起動します。

6. API Gateway + Lambda

API クライアントが API Gateway をコールし、その背後で Lambda Function を起動します。

7. API Gateway + Step Functions

API クライアントが API Gateway をコールし、その背後で Step Functions のワークフローを実行します。

8. API Gateway + Amazon Managed Services

API クライアントが API Gateway をコールし、その背後で S3やDynamoDBなど直接操作します。

9. SES + Lambda

エラーメールなどが SES へ飛ぶように設定し、そのメールを受けて SES が Lambda を起動します。

10. Cognito + Lambda

Amazon Cognito では以下の場合に Lambda を起動できます。

• IDプール で、ユーザーデータが同期されたとき(Sync イベントが発生したとき)
• ユーザープールの認証ライフサイクル。例えば、サインアップ前、認証後、確認後にそれぞれ Lambda を起動することができます。

参考：

• Amazon Cognito イベント - Amazon Cognito
• AWS Lambda トリガーを使用したユーザープールのワークフローのカスタマイズ - Amazon Cognito

11. Auto Scaling event + SNS + Lambda

Auto Scaling のイベントでライフサイクルフックによりSNSへメッセージが送信され、それをトリガーに Lambda 起動します。

12. Kinesis Stream + Lambda

データが Kinesis Stream にプッシュされます。Lambda がストリームをポーリングしており、データを取得することができ次第関数を実行します。

13. Kinesis Analytics + Lambda

※ この構成図は、スライドの画像ではなく、本ブログ記事投稿者がスライドの画像を見て再現したものです。

1. データが Kinesis Stream / Firehose にプッシュされます
2. ストリームデータが Kinesis Analytics に渡されます
3. Lambda がデータの事前処理用にコールされます
4. 処理済みのデータに対して、 SQL クエリを実行します
5. Analytics の結果 をストリームに流します
6. ストリームデータを Lambda が処理します

14. CodePipeline + Lambda

1. アプリケーションコードがバージョン管理システムに PUSH されます
2. CodePipelineが起動します
3. "Stage action" として Lambda が実行されます

15. CodeDeploy + Lambda

デプロイメントイベントが SNS トピックに送信され、SNSをトリガーとして Lambda が起動します。

16. CodeCommit + Lambda

アプリケーションコードが CodeCommit にイベントを発行し、それをきっかけとして CodeCommit が Lambda を起動します。

17. CloudFormation + Lambda

カスタムリソースが実行され、その中で Lambda 関数を実行します。

18. CloudTrail + Lambda

AWS API コールの ログが S3 へロギングされます。S3にログが追加されることで、 Lambda を起動します。

19. AWS Config + Lambda

AWS リソースに変更が適用された場合、それを AWS Config が検知して SNS トピックへメッセージを送ります。SNSへメッセージ配信をトリガーとして、Lambda が起動します。

20. AWS Config Rule + Lambda

AWS リソースの設定変更、または定期的な実行をイベントとして、Lambda Function を評価関数として実行することが可能です。AWS Config Rule の Lambda Function は、イベントから受け取ったデータと AWS Config API を利用してルールに準拠しているかどうかを評価するよう使います。

参考：

• AWS Config ルールの AWS Lambda 関数の例 (Node.js) - AWS Config

21. CloudWatch Events + Lambda ( event-based )

サービスのイベントか CloudWatch Events の API をコールすることで、イベントベースで Lambda を実行させることができます。

22. CloudWatch Events + Lambda ( time-based )

CoudWatch Events の スケジュールに従い、Lambda を定期的に実行させることができます。

23. CloudWatch + Lambda ( metrics )

CloudWatch により各種メトリクスが収集され、しきい値のアラームが発動した際に Lambda を起動できます。

24. CloudWatch + Lambda ( logs )

CloudWatch により各種ログが採取され、特定のログが渡された場合（エラーログなど）、Lambda を起動できます。

25. DynamoDB + Kinesis Stream + Lambda

1. DynamoDB のアイテムが 挿入または更新されます
2. DynamoDB によって、Kinesis Strema にイベントがプッシュされます
3. Lambda が Kinesis Strema をポーリングしており、データに応じて処理を行います

26. RDS ( Stored Procedure ) + Lambda

1. SQL クエリが実行されます
2. クエリに応じて、 Amazon Aurora または MySQL が Stored Procedure を実行します
3. Lambda Function が起動します

参考：

• Amazon Aurora Update – Call Lambda Functions From Stored Procedures; Load Data From S3 | AWS News Blog
• 【新機能】Amazon AuroraからLambdaを呼べるようになりました ｜ Developers.IO

27. Amazon Redshift + Lambda

1. Amazon Redshift のイベントが発生します
2. イベントが SNS トピックに送信されます
3. 2がトリガーとなり、Lambda が起動します

28. Amazon Lex + Lambda

ChatBot がフルフィルメントを必要とした場合に、 Amazon Lex が Lambda を起動します。

参考：

• Using Lambda Functions - Amazon Lex

29. Alexa + Lambda

Alexa 互換のデバイスに「Alexa、今日の天気は？」と話しかけます。 Alexa skill が Lambda Function を起動します。

30. AWS IoT + Lambda

IoTデバイスが AWS IoT にデータを送り、それをトリガーとして Lambda が起動します。

AWS Service Application Model (SAM) の紹介

サーバーレス向けに最適化された CloudFormation 拡張です。 CloudFormation で利用できるリソースタイプに加え、以下のリソースタイプを使うことができます。

• AWS::Serverless::Function
• AWS::Serverless::Api
• AWS::Serverless::SimpleTable

参考： serverless-application-model/2016-10-31.md at master · awslabs/serverless-application-model

また、 SAM Local といって、サーバーレスアプリケーションをローカルでテストするためのCLIツールがあります。オープンソースのdocker-lambdaを使うことで、 メモリ上限を始めとした Lambda Function の環境を再現することができます。

サーバーレスアプリケーションの運用について

CloudWatch メトリクスを活用しよう

主に、 Lambda と API Gateway での活用方法を説明します。

まず、 Lambda です。 CloudWatch メトリクスでは最初から Lambda に関する以下の項目を監視することができます：

• Invocation Count
• Invocation duration
• Invocation Errors
• Throttled Invocation
• Iterator Age
• DLQ Errors

Lambda Function から "put-metric-data" をコールすることでカスタムメトリクスを送信することができます。ぜひ活用してください。

次に、API Gateway です。 以下の項目を監視することができます：

• API Call Count
• Latency
• 4XX
• 5XX
• Integration Latency
• Cache Hit Count
• Cache Miss Count

エラーとキャッシュのメトリクスに関しては、平均値とパーセンタイルをサポートしています。こちらも活用してください。

CloudWatch Logs を活用しよう

• API Gateway の リクエストやボディコンテンツをロギングできます
• Lambda Function で 簡単に CloudWatch Logs へ任意のログを送信できます
• ログデータでメトリクスを作ることができます
• ログデータは、 ElastiCache や S3 へエクスポートできます

API Gateway でカスタムアクセスログを出力できるようになりました！

詳細はこちら。ぜひ使ってみてください。 Amazon API Gateway でアクセスログ記録をサポート

AWS X-Ray を活用しよう

• リクエストを追跡できます
• レコードを追跡できます
• サービスマップで追跡データを閲覧できます
• 異常を見つけて、問題をドリルダウンできます

どこがおかしいか、どうやって調べればいい？

1. まずは、 X-Ray を有効にしてください
   • X-Ray SDK を使ってアプリケーションでの AWS 呼び出しをラップしてみてください
2. Lambda でログを取ることを過小評価せず、ぜひ出力するようにしてください
   • "debug:in functionX" だけでも情報量があり、CloudWatch Log s で見つけられるようになります
3. 最も価値が高いメトリクスは、顧客／ユースケースに近い部分です
   • いくつの機器がこの Function をコール／生成／処理したのか、など

Lambda Dead Letter Queue を使おう

• Lambda を非同期実行するユースケースでは、必ず有効にしてください
• DLQ の SQS Queue length のメトリクスをとり、アラートを設定してください
• SNS を通して、永続性・信頼性のあるエンドポイントにメッセージを送信してください（例えば別のリージョンの Lambda Function などです）
• DLQは呼び出しイベント情報を保存できます

まとめ

Lambda をベースとした、サーバーレスアーキテクチャの構成例が基本から30個紹介されました。知っているものもありましたが、私はストアドプロシージャから Lambda Function をコールできることは知りませんでした。「Lambda ってどういうふうに呼べたっけ？」という疑問が湧いたときに、思い出すきっかけとして本セッションの内容はうってつけだと思います。

また、サーバーレスアプリケーションは、デプロイや運用の勝手が従来のサーバーアプリケーションを配備する場合と異なるシーンが多いため、デプロイ・運用は導入する際に苦労するポイントのひとつになるかと思います。本セッションでは、デプロイについては AWS SAM、運用については CloudWatch, CloudWatch Logs, AWS X-Ray, Lambda Dead Letter Queue を使うことを勧めています。いくつかの例も紹介されました。

サーバーレスアプリケーションはサービスを組み合わせることで様々なことができるようになります。このセッションで紹介されたパターンをさらにいくつか組み合わせることによって、より複雑な処理を行えるバックエンドを構築できるでしょう。今後もいろいろ組み合わせて試していきたいと思います。

サーバーレス構成のパターンについては、こちらの諏訪の記事（発表資料）もご参照ください。

• 【登壇資料】目的別、サーバーレスアーキテクチャの教科書！これのときはこう！【アーキテクチャ20連発】 #cm_osaka ｜ Developers.IO