AWS Lambda / Amazon API Gateway Deep Dive

1. AWS Lambda / Amazon API Gateway Deep Dive Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K.

2. Profile Keisuke Nishitani Solutions Architect, Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ AWSのソリューションアーキテクト ✤ Webサービス系 ✤ モバイル系 ✤ クラウドを使ったアプリ開発とかモバイル開発の話しをよくしています ✤ モバイルニンジャ1号機 ✤ RESTおじさん ✤ Lambda Wizards ✤ 餃⼦の王将エヴァンジェリスト（⾃称） Keisuke69 Keisuke69Keisuke69x

3. 今⽇お話すること

4. 今⽇お話すること ✤ AWS Lambdaを中⼼に ✤ ⼀般的な使われ⽅ ✤ Tips ✤ よくある質問

5. 今⽇お話しないこと

6. 今⽇お話しないこと ✤ AWS Lambda / Amazon API Gatewayの概要 ✤ AWS Lambda / Amazon API Gatewayの基本的な使い⽅

7. AWS Lambdaの利⽤パターン

8. 利⽤パターン① : Data Processing ✤ リアルタイムファイル処理 ✤ S3＋Lambda ✤ カスタマ ✤ Seattle Times, PlayOn Sports ✤ ユースケース ✤ PDFの透かし埋め込み ✤ イメージのサムネイル⽣成や変換 ✤ ドキュメントのメタデータをインデックス化 ✤ ログの集約とフィルタリング ✤ RSSフィードの処理 ✤ メディアコンテンツのバリデーション ✤ ポリシーエンジン（CloudTrailとの組み合わせ）

9. 利⽤パターン① : Data Processing ✤ データロード/DBトリガー ✤ DynamoDB＋Lambda ✤ カスタマ ✤ Localytics ✤ ユースケース ✤ データバリデーション ✤ バックアップ ✤ 分析

10. 利⽤パターン① : Data Processing ✤ リアルタイムストリーム処理 ✤ Kinesis＋Lambda ✤ カスタマ ✤ Major League Baseball ✤ ユースケース ✤ クライアントのアクティビティトラッキング ✤ メトリクス⽣成 ✤ データクレンジング ✤ ログフィルタリング ✤ インデクシングや検索 ✤ ログルーティング ✤ IoTバックエンド

11. 利⽤パターン② : バックエンド ✤ APIバックエンド ✤ カスタマ ✤ Vidroll ✤ ユースケース ✤ CRUD処理のバックエンド、バリデーション、ワークフローのトリガ ✤ 多様なコミュニティベースのフレームワーク（Serverless, Zappa, APEX） ✤ IOTバックエンド ✤ ユースケース ✤ デバイスのロジック、データ同期 ✤ サーバサイドのエクステンションとして ✤ Alexa Skills ✤ モバイルバックエンド ✤ Twilio/Slackのエクステンション

12. 利⽤パターン③ : Workers ✤ Pub-Subのハンドラ ✤ ユースケース ✤ SNS経由のCloudWatchのアラーム ✤ イベントブリッジとしてのSNS ✤ モバイルデバイスへの通知 ✤ AWSサービスの拡張として ✤ SWF– ワークフローのアクションとして ✤ CloudFormation - プロビジョニング時のカスタムリソース ✤ SES – インバウンドメールに対するカスタムレスポンス ✤ CodePipeline - デプロイ時のカスタムトリガー

13. AWS Lambda Tips

14. カラースキームの変更 ✤ Lambdaのブラウザエディタは実はカラースキームが変更できます ✤ 5種類 ✤ ブラウザ単位 ✤ DefaultはDawn

15. Solarized Dark Monokai Cobalt Eclipse

16. コンテナの再利⽤ ✤ Lambdaファンクションはコンテナ（Sandbox）内で実⾏される ✤ ファンクション単位で隔離 ✤ ファンクション作成後、もしくはコードや設定更新後の初回実⾏時は新たにコンテナが作成され、ファンクション⽤のコードがコンテナ内にロードされる ✤ ハンドラが最初に呼び出される前に初期化処理がコンテナの⽣成ごとに⼀度だけ実⾏される ✤ ファンクションが終了し、ある程度時間が経過したのち再度実⾏される場合は再度、コンテナの⽣成が⾏われる ✤ コードの変更がなく前回の実⾏から時間が⽴っていない場合はコンテナを再利⽤する ✤ 初期化処理をスキップするためパフォーマンス上のアドバンテージがある ✤ 再利⽤された場合、最後に/tmpに書き込んだ内容も残っている（ただし、あてにはしないこと） ✤ エイリアスを使っていて付け替えた場合もエイリアスの作成先となるコンテナを可能であれば再利⽤する

17. パフォーマンス ✤ グローバル変数について ✤ ハンドラ外部で初期化することでコンテナ再利⽤時のコストをごくわずかに改善することも可能 ✤ ただし、グローバル変数なのでコンテナ再利⽤時には前回のステータスが残っているので使える局⾯はごくわずか ✤ メモリとCPUの関係について ✤ AWS Lambdaではメモリサイズのみ指定ができてCPU能⼒については指定ができませんが、CPU能⼒はメモリサイズに⽐例する ✤ 例えば128MBを割り当てた場合と256MBを割り当てた場合とでは後者は前者の約2倍のCPU能⼒が割り当てられる

18. VPCアクセス関連 ✤ 設定をしたタイミングからインターネットアクセスは不可となる ✤ 必要な場合はNATインスタンスを⽤意すること ✤ 充分な数の ENI またはサブネット IP がない場合は、リクエスト数が増えた場合に失敗する ✤ このエラーについては現在のところCloudWatch Logsには記録されない ✤ Lambdaファンクションの失敗数と対応するCloudWatch Logsのエントリ有無で判断する必要あり ✤ コンソールで実⾏するなど、同期実⾏することでエラー応答は取得できる ✤ 必要なENIのキャパシティは以下の計算式でざっくりと計算可能 Projected peak concurrent executions * (Memory in GB / 1.5GB)

19. VPCアクセス関連 ✤ AZごとにサブネットを指定しておくのがおすすめ ✤ 障害時やIP枯渇時に別AZでLambdaファンクションの実⾏が可能になるため ✤ ファンクションに割り当てるIAM Role に”AWSLambdaVPCAccessExecutionRole”というポリシーをアタッチしておくこと ✤ もしくは以下のアクションを許可したポリシーを割り当てたIAM Roleを⽤意すること ✤ logs:CreateLogGroup ✤ logs:CreateLogStream ✤ logs:PutLogEvents ✤ ec2:CreateNetworkInterface ✤ ec2:DescribeNetworkInterfaces ✤ ec2:DeleteNetworkInterface

20. スケジュール実⾏ ✤ rate(Value Unit)形式での指定時はValueが2以上ならばUnitも複数形にすること ✤ 例 ✤ 5分ごとに実⾏ => rate(5 minites) ✤ 1時間ごとに実⾏ => rate(1 hour) ✤ 7⽇ごとに実⾏ => rate(7 days) ✤ cron(Minutes Hours Day-of-month Month Day-of-week Year)形式での指定時、タイムゾーンはUTCのみ

21. Idempotency ✤ 冪等性はお客様のコードで確保する必要がある ✤ AWS Lambdaで保証しているのは最低1回実⾏することであり1回しか実⾏しないことではない ✤ 同⼀イベントで同⼀Lambdaファンクションが2回起動されることがまれに発⽣する ✤ DynamoDBを利⽤するなどして冪等性を担保する実装を⾏うこと

22. リトライまとめイベントソース（呼び出し元）イベントモデルイベントタイプエラー時のリトライ S3 Push ⾮同期あり（合計3回） Kinesis Pull ⾮同期データ期限切れまでリトライ DynamoDB Pull ⾮同期データ期限切れまでリトライ Amazon SNS Push ⾮同期あり（合計3回） Alexa Push 同期なし CloudWatch Logs Push 同期なし CloudFormation Push 同期なし Cognito Push 同期なし AWS IoT Push ⾮同期あり（合計3回） Scheduled Event Push ⾮同期あり（合計3回） API Gateway Push 同期なし SES Push ⾮同期あり（合計3回）カスタムイベント（RequestResponse） Push 同期なしカスタムイベント（Event） Push ⾮同期あり（合計3回）

23. 同時実⾏数の考え⽅ ✤ イベントソースがAmazon Kinesis / DynamoDBの場合、シャード数と等しい ✤ ストリームのシャードごとに同時に実⾏されるため ✤ 例：100シャードのAmazon Kinesis ストリームの場合、同時実⾏数はどの時点でも最⼤ 100 件。そのうちアクティブなシャードが10個だった場合、実際の同時実⾏数は10となる。 ✤ それ以外は、（1 秒あたりのリクエスト数 * 関数の実⾏時間）となる。たとえば、関数が 1 秒あたりのリクエストが10 件で平均実⾏数が3秒の場合、同時実⾏数は 30となる 1s 2s 3s 4s 5s 10 req/sec Avg 3s / exec “同時”に実⾏されているタイミング

24. 同時実⾏数を越えた場合 ✤ 同時実⾏数を越えた場合（スロットリングされた場合）の挙動はファンクションの呼び出し⽅によって異なる ✤ 同期の場合 ✤ 呼び出し元には429エラーがレスポンスされる ✤ RequestResponseでのカスタムイベントやAPI Gatewayのバックエンドの場合、呼び出し元で429を受け取ってリトライ処理を実装する ✤ ⾮同期の場合 ✤ スロットルされたイベントは最⼤ 6 時間再試⾏される ✤ S3のイベントの場合はこの6時間のリトライが失敗すると最⼤24時間までイベントを再送する ✤ 15〜30 分程度は、トラフィックの急激な上昇によるものとして許容される ✤ イベントソースがKinesisもしくはDynamoDBの場合 ✤ データの有効期限が切れるまで (Amazon Kinesisの場合は最⼤ 7 ⽇間)、スロットルされたイベントが再試⾏される ✤ スロットルされたリクエストはブロックとして扱われ、そのレコードのバッチの有効期限が切れるか処理が成功するまで、ストリームから新しいレコードの読み込みが⾏われない

25. AWS LambdaにまつわるFAQ

26. AWS Lambda FAQ ✤ Lambdaファンクションに環境変数のように実⾏時に値を渡したい ✤ そういった機能はないがエイリアスを使うことで対応可能な場合があります。 Lambdaファンクション内部から呼び出しに使われた⾃⾝のエイリアスを取得可能なので、エイリアスとして渡したい値をセットすることで似たようなことが実現可能です ✤ 新規コードがアップロードされたとき何がおきるか ✤ アップロード後、数秒は新旧両⽅のコードが実⾏され（混在する）、その後は新規のコードのみが実⾏されます。また、実⾏中のものはそのまま継続実⾏され、コードの⼊れ替えに伴うダウンタイムは発⽣しません

27. Photo credit: Matthew Wilkinson via Visual Hunt / CC BY-ND AWS Lambda FAQ ✤ VPCアクセス利⽤時、プライベートIPアドレスを固定することは可能？ ✤ ENIはLambdaによって作成・削除が⾃動的に⾏われるため、任意のアドレスの指定は不可 ✤ グローバルIPアドレスを固定することは可能？ ✤ VPCアクセスを有効にした場合はManaged Nat Gatewayや独⾃のNATインスタンスを利⽤することでインターネット通信およびグローバルIPアドレスを固定することが可能

28. AWS Lambda FAQ ✤ アクセス元として特定Lambdaファンクションのみ許可したい ✤ VPCアクセスを利⽤すれば可能。ファンクションに割り当てたセキュリティグループをソースとする許可ルールをアクセス先リソースのセキュリティグループに追加することで実現できます ✤ オンプレミスにあるリソースへアクセスしたい ✤ VPCアクセスを利⽤すればDirectConnectやVPN経由でアクセスすることが可能です。

29. AWS Lambda FAQ ✤ VPCアクセス時のレイテンシへの影響は？ ✤ Lambdaファンクションへの初回アクセス時などENIの作成を伴う場合は10秒〜 60秒程度の時間を必要とします ✤ VPCアクセス時ENIはLambdaファンクションごとに作成されるのか？ ✤ ENIは複数のLambdaファンクションから共⽤されます

30. AWS Lambda FAQ ✤ 初期化処理に時間がかかるのを何とかしたい ✤ 対象のLambdaファンクションに対してポーリングすることで軽減可能です。また、ポーリングは別ファンクションからスケジュール実⾏するのがいいです。あとは⾔語の特性としてJavaは初期化処理に時間がかかってしまうのでJava以外を選ぶのも⼿です。 ✤ ポーリングはどのようにすればいいですか？⽅法や間隔など ✤ API Gatewayなどのエンドポイントに対して⾏うのでもいいですし、Lambda ファンクションの内部からAWS SDKを利⽤して直接Invokeすることも可能です。ただし、間隔については利⽤状況（ファンクションのメモリ、実⾏時間、リクエストなど）にもよるため残念ながらこれと⾔った御案内可能な数値がないため、お客様にて実際に試⾏して調整をお願いしますmm

31. Amazon API Gateway

32. Amazon API Gateway FAQ ✤ AWS WAFを使いたい ✤ API GatewayをオリジンとしてCloudFrontを使⽤することで利⽤可能です。ただし、POPが2段になるためレイテンシを考慮する必要があります。 ✤ カスタムドメイン⽤にAWS Certificate Managerを使いたい ✤ 現時点ではAPI GatewayはACMで発⾏する証明書に対応していません。ただし、 API GatewayをオリジンとしてCloudFrontを使⽤することで利⽤可能です。ただし、POPが2段になるため（ry

33. Amazon API Gateway FAQ ✤ エンドポイントへのアクセスに地域による制限をかけたい ✤ API Gateway⾃⾝には機能はないですがバックエンド側のロジックでチェックをして弾く、もしくはAPI GatewayをオリジンとしてCloudFrontを使⽤すること（ry ✤ API Gatewayのエンドポイントをサブドメインで振り分けて提供したい（api.example.com, img.example.comのように） ✤ API GatewayをオリジンとしてCloudFrontを（ry ✤ HTTPでリクエストを受けたい ✤ API Gatewayをオリジン（ry

34. API Gatewayの⼿前にCloudFrontを利⽤する ✤ API Gateway⾃⾝もCloudFrontを利⽤してディストリビューションされていますが、CloudFrontの設定は変更不可となっています ✤ API Gatewayでの利⽤はDDoSプロテクション（L7, L3およびSyn flood）が⽬的 ✤ CloudFrontをAPI Gatewayの前段で利⽤することでCloudFrontの持つ機能を活かすことが可能となります ✤ ただし、API GatewayのPOPに加えて2段階となるため多少とはいえレイテンシを考慮する必要はあります POP POP （API Gatewayが利⽤）

35. CloudFront利⽤時における設定のポイント ✤ オリジンとしてAPI Gatewayのエンドポイントを登録 ✤ API GatewayのInvoke URLのホスト部分だけを登録する例 : a0ro61xxxx.execute-api.us-east-1.amazonaws.com ✤ HTTPで受けたい場合はViewer Protocol Policyを”HTTP and HTTPS” もしくは“Redirect HTTP to HTTPS”に ✤ Origin Protocol Policyは”HTTPS Only“に ✤ HOSTヘッダは転送しないこと

36. Amazon API Gateway FAQ ✤ カスタムドメインの証明書更新はできますか？ ✤ 可能だがカスタムドメインの再作成をする必要あり（ダウンタイムが発⽣）。 CloudFrontを利⽤すればCloudFront側で更新が可能。ただし、API Gatewayの APIマッピングが利⽤できなくなること、CloudFrontが⼆重になることのレイテンシに注意 ✤ スループットが500rpsあたりで頭打ちする ✤ API Gatewayのスループットはデフォルトでは500rpsで制限されています ✤ 実は当初からそうなんですが最近ようやく情報が公開されました ✤ スロットリングを有効にしている場合、デフォルトでは1000rpsまでバーストを許可 ✤ 必要に応じて制限緩和を

37. Amazon API Gateway FAQ ✤ レスポンスヘッダの値を動的にセットしたい ✤ Integration ResponseのHeader Mappingsで任意のResponse Headerを設定し、その値としてintegration.response.body.fieldを指定する（fieldの部分は任意の値） ✤ ヘッダとして指定したい値をバックエンドからのレスポンスに含める ✤ 上記におけるfield相当のキーで値を設定する ✤ この値をAPIのレスポンスとして⾒せたくない場合はMapping Templatesでフィルタする ✤ リダイレクトを動的にコントロールしたい ✤ 上記、レスポンスヘッダの値を動的にセットする⽅法にてLocationヘッダに任意の値をマッピング ✤ デフォルトのレスポンスとして301もしくは302を設定しておく

38. Amazon API Gateway FAQ ✤ HTTPProxyとして利⽤する際、バックエンドへのアクセス元を限定したい ✤ バックエンドがPublicな物であればAWS Lambdaを挟むことでVPCサポートとNATを組み合わせて対応可能です。バックエンドがVPC内のプライベートなものであれば同様にAWS LambdaのVPCサポートとセキュリティグループで対応することが可能です。この場合、API GatewayのバックエンドはAWS Lambdaとし、Lambdaファンクションから実際に利⽤したいバックエンドのWebシステムへとリクエストを⾏います。 ✤ クライアントSSLによる認証を⾏う。正しい証明書を持つリクエスト以外をバックエンド側で弾く ✤ バックエンドへのタイムアウトが短い、もう少し伸ばして欲しい ✤ Webの世界で1つのリクエストが数分かかるというのは⼀般的ではありません。⾮同期処理にするなどアーキテクチャ、APIデザインの⾒直しをおすすめします。 ✤ ドキュメント上はまだですが実は29秒に延びました！なのでバックエンドがLambda でVPCを使っていてもタイムアウトすることはほとんどないと思います