2016年3月12日のJAWSDAYSでお話した資料です。

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. Retries on Errors
Event Source Model Invocation Type Retries on Errors
Amazon S3 Non-stream Async Up to 3 times.
Amazon Kinesis Streams Stream-based Sync Until data expires.
Amazon DynamoDB Stream-based Sync Until data expires.
Amazon Simple Notification Service Non-stream Async Up to 3 times.
Amazon Echo (Alexa) Non-stream Sync Return 429 error.
Amazon CloudWatch Logs Non-stream Async Up to 3 times.
AWS CloudFormation Non-stream Async Up to 3 times.
Amazon Cognito Non-stream Sync Return 429 error.
AWS IoT Non-stream Async Up to 3 times.
Amazon CloudWatch Events Non-stream Async Up to 3 times.
Scheduled Event Non-stream Async Up to 3 times.
Amazon API Gateway Non-stream Sync Return 429 error.
Amazon Simple Email Service Non-stream Async Up to 3 times.
AWS Config Non-stream Async Up to 3 times.
Custom Event Non-stream Sync/Async Return 429 error / Up to 3 times.

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. AWS Lambda FAQ
✤ VPCのリソースにアクセスできない
✤ LambdaというよりNWの問題であることが多いため、まずはVPC周りの設定確認を。
ルートテーブル、セキュリティグループ、ネットワークACL、ENIの作成権限あたりの
設定を⾒なおしてください。問題特定および切り分けのため同⼀サブネット上でEC2
インスタンスを起動して各種調査を⾏うことも有効です。なお、LambdaではTCP以外
の通信およびtraceroute等のコマンド実⾏は許可されていません
✤ イベントソースで正しくイベントが発⽣したか確認したい
✤ 現状ではサポートに問合せ頂くことで確認可能な場合があります。サポートに問合せ
頂く際はイベント発⽣の元となったリクエストのリクエストIDは最低限必要となりま
す。また、それ以外の情報も状況に応じて必要となります。なお、S3に関しては2種
類のリクエストIDが必要となり、通常アクセスログ等には出⼒されないため、クライ
アント側での取得および記録が必要となります。

32. Amazon API Gateway

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

34. 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

35. 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が利⽤）

36. 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ヘッダは転送しないこと

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

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

39. 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を使っていてもタイムアウトすることはほとんどないと思います