AWS Lambda Updates

AWS Lambda Updates
Keisuke Nishitani (@Keisuke69)
Amazon Web Services Japan K.K.

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

他プラットフォームと⽐較すると
✤ EC2
✤ スケールの単位はインスタンス（仮想マシン）
✤ ハードウェアを抽象化
✤ コンテナ（Docker, ECS）
✤ スケール単位はアプリケーション
✤ OSを抽象化
✤ AWS Lambda
✤ スケール単位はファンクション
✤ ⾔語のランタイムを抽象化

どれを選ぶべきか？
✤ EC2
✤ OS、ネットワーク、ストレージのレベルで構成を制御したい
✤ 好みのOSを利⽤したい
✤ OS以上の全てを⾃分でコントロールしたい
✤ コンテナ（Docker, ECS）
✤ サーバを⾃分で構成して実⾏したい
✤ アプリケーションの構成を制御したい
✤ スケールを⾃分でコントロールしたい
✤ AWS Lambda
✤ 必要なときだけコードの実⾏を⾏いたい
✤ インフラの構成・管理を⾏いたくない

AWS Lambdaの利⽤パターン

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

✤ データロード/DBトリガー
✤ DynamoDB＋Lambda
✤ カスタマ
✤ Localytics
✤ データバリデーション
✤ バックアップ
✤ 分析

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

利⽤パターン② : バックエンド
✤ APIバックエンド
✤ カスタマ
✤ Vidroll
✤ CRUD処理のバックエンド、バリデーション、ワークフローのトリガ
✤ 多様なコミュニティベースのフレームワーク（Serverless, Zappa, APEX）
✤ いわゆるサーバレスなWebアプリケーション・アーキテクチャ
✤ IOTバックエンド
✤ デバイスのロジック、データ同期

利⽤パターン③ : その他
✤ CloudWatchのアラームをSNS経由で受けとってイベントドリブンなインフラ
管理
✤ 定期処理の実⾏
✤ Alexa AppsとSlackの組み合わせでサーバレスな⾳声認識bot
✤ モバイルバックエンド
✤ AWSサービスの拡張として
✤ SWF– ワークフローのアクションとして
✤ CloudFormation - プロビジョニング時のカスタムリソース
✤ SES – インバウンドメールに対するカスタムレスポンス
✤ CodePipeline - デプロイ時のカスタムトリガー

AWS Lambda Updates
✤ Blueprint
✤ Python 2.7 サポート
✤ スケジュール実⾏
✤ バージョンとエイリアス
✤ VPCアクセス
✤ Node.js 4.3 サポート

Blueprint
✤ Lambdaファンクションの新規作成時に利⽤可能なサンプル集
✤ ユースケースに応じたイベントソースの設定と実際に動くコードが提
供されている
✤ Slack連携⽤のものもある
✤ 2016年3⽉2⽇現在、40種類を提供
✤ Node.jsとPythonのみ
✤ 必要に応じてカスタマイズして利⽤

Blueprint
ユースケースを選択

Blueprint
必要に応じて修正

Python 2.7のサポート
✤ LambdaファンクションをPython2.7で記述可能に
✤ Mobile SDKを含む全てのSDKで利⽤可能
✤ CLIから利⽤可能
✤ マネージメントコンソール（インラインエディタも利⽤可）
✤ Blueprintも利⽤可能

プログラミングモデル – handler –
✤ event
ファンクションに渡される情報。ディクショナリ型。
✤ context
ランタイム情報を格納。ファンクション内部から参照可能。
✤ 戻り値
呼び出しタイプに応じて異なる
✤ RequestResponse （同期）
関数の戻り値がLambdaファンクション呼び出し元へと返される。
✤ Event（⾮同期）
関数の戻り値がセットされていたとしても値は破棄される
✤ 何も返さない場合、nullという⽂字列が返される
def handler_name(event, context):
...
return some_value

プログラミングモデル – Context –
✤ ランタイムに関する情報が含まれ、contextオブジェクト（2番⽬のパラメータ）経由で関数内部からアクセ
ス可能
✤ メソッド
✤ get_remaining_time_in_millis()：関数終了までの残り時間
✤ アトリビュート
✤ function_name：実⾏中のファクション名
✤ function_version：実⾏中ファンクションのバージョン。エイリアスを使⽤した場合、エイリアスが指すバージョン
✤ invoked_function_arn：呼び出しに使われたARN。ファンクションのARNもしくはエイリアスのARN
✤ memory_limit_in_mb：設定されたメモリサイズ
✤ aws_request_id：AWSリクエス ID。invoke メソッドを呼び出したクライアントに返される ID
✤ log_group_name：CloudWatch ロググループ名
✤ log_stream_name：CloudWatch ログストリーム名
✤ Identity：Amazon Cognitoに関する情報（Mobile SDKで呼び出した場合のみ）
✤ client_context：クライアントのアプリケーションやデバイスに関する情報（Mobile SDKで呼び出した場合のみ）

プログラミングモデル – Logging –
✤ 次のどちらかでログ出⼒し、いずれもCloudWatch Logsに出⼒される
✤ printステートメント
✤ loggingモジュールのLogger関数
✤ loggingモジュールを利⽤した場合、ログエントリにタイムスタンプや
ログレベルなどの情報が追加される

プログラミングモデル – 例外処理 –
✤ 関数内で例外が発⽣した場合、例外情報がJSON形式にシリアライズして出⼒される
✤ 呼び出しがRequestResponseの場合は呼び出し元に戻り値として返されるが、Eventの
場合はCloudWatch Logsに記録されるのみとなる
def lambda_handler(event, context):
raise Exception('failed')
{
"stackTrace": [
[
"/var/task/lambda_function.py",
14,
"lambda_handler",
"raise Exception('failed')" ]
],
"errorType": "Exception",
"errorMessage": "failed”
}
■ファンクションサンプル ■エラーレスポンスサンプル

スケジュール実⾏
✤ 特定時刻または繰り返しによるファンクション実⾏をサポート
✤ 最短は1分インターバル
✤ 設定はイベントソースから
✤ 「CloudWatch Events – Schedule」を選択
✤ Cron形式の指定もサポート
✤ Lambda側からはコンソールでの設定のみ
✤ CLIとSDKからの設定はCloudWatch Eventのものを利⽤する

スケジュール指定⽅法
✤ rate(Value Unit)
✤ インターバル実⾏する場合の指定⽅法
✤ Value：正の整数を指定
✤ Unit：分、時、⽇を指定
✤ 例
✤ 5分ごとに実⾏ => rate(5 minites)
✤ 1時間ごとに実⾏ => rate(1 hour)
✤ 7⽇ごとに実⾏ => rate(7 days)
✤ Valueが単数じゃない場合はUnitも複数形にすること

スケジュール指定⽅法
✤ cron(Minutes Hours Day-of-month Month Day-of-week Year)
✤ 全フィールドが必須
✤ タイムゾーンはUTCのみ
✤ ワイルドカードも利⽤可
✤ 例
✤ 毎⽇午前 10:00 実⾏ => cron(0 10 * * ? *)
✤ 毎⽉曜〜⾦曜の午後 06:00に実⾏ => cron(0 18 ? * MON-FRI *)
✤ 毎⽉最初の⽇の午前 8:00に実⾏ => cron(0 8 1 * ? *)
✤ ⽉曜〜⾦曜の 10 分ごとに実⾏ => cron(0/10 * ? * MON-FRI *)
✤ ⽉曜〜⾦曜の午前 8:00 〜午後 5:55の間5分ごとに実⾏
=> cron(0/5 8-17 ? * MON-FRI *)

Cron形式で利⽤可能なワイルドカード
⽂字定義例
/ 増分を指定します minutes フィールドの0/15は、15分ごとに実⾏が発⽣するように指定し
ます。
L "最後" を指定します Day-of-month フィールドに使⽤された場合、その⽉の末⽇が指定されま
す。Day-of-week フィールドに使⽤された場合、週の最後の曜⽇ (⼟曜
⽇) が指定されます。
W 平⽇を指定します⽇付とともに使⽤した場合（5/W など）、その⽉の 5 ⽇に最も近い平⽇
が指定されます。5 ⽇が⼟曜⽇の場合、実⾏は⾦曜⽇に発⽣します。5 ⽇
が⽇曜⽇の場合、実⾏は⽉曜⽇に発⽣します。
# その⽉の n 番⽬の⽇を指定します 3#2 は、⽉の第 2 ⽕曜⽇を意味します（⽕曜⽇は週 7 ⽇の 3 番⽬の曜⽇
です）。
* すべての値を指定します Day-of-month フィールドで使⽤した場合、⽉のすべて⽇を意味します。
? 値を指定しません指定した別の値とともに使⽤されます。たとえば、特定の⽇付を指定した
が、その⽇が何曜⽇であってもかまわない場合です。
- 範囲を指定します 10-12 は 10、11、および 12 を意味します
, 追加の値を指定します SUN, MON, TUE は、⽇曜⽇、⽉曜⽇、および⽕曜⽇を意味します
/ 増分を指定します 5/10 は、5、15、25、35 などを意味します

バージョンとエイリアス

バージョニング
✤ ある⼀時点のLambdaファンクションをバージョンとして管理可能
✤ 新しいバージョンはいつでも発⾏可能
✤ Lambdaファンクションの作成/更新時にpublishパラメータを追加する
✤ PublishVersionを実⾏することで明⽰的に発⾏することも可能
✤ バージョンの発⾏をするまでは$LATESTが唯⼀のバージョンとなる
✤ ⼀度発⾏すると構成も含めて⼀切変更不可
✤ 単純にバージョン番号がインクリメントする
exports.handler =
function(event,context)
{context.succeed(“bye”);}
exports.handler =
function(event,context)
{context.succeed(“hi”);}
Version:1
Version:2

エイリアス
✤ 特定バージョンに対するポインタのようなもの
✤ エイリアスを作成することでバージョン番号を把握していなくても指
定バージョンを呼び出せる
✤ いつでも付け替え可能
Version: 1
Arias: Prod
Version: $LATEST
Arias: Dev
Version: 1 Version: $LATEST
Arias: Dev
Version: 2
Arias: Prod
変更前
変更後
（新規バージョン発⾏後）
Prodというエイリアスを
1から2へ付け替え

ファンクションの指定⽅法
✤ バージョン発⾏前、最新バージョンを指定する場合:
FunctionName
FunctionName:$LATEST
✤ 特定バージョンを指定する場合
FunctionName:1
FunctionName:2
✤ エイリアスで指定する場合:
FunctionName:production
FunctionName:v1_2_3_4

その他アップデート
✤ タイムアウトの最⼤が60秒から300秒に
✤ CloudWatch Eventsとの連携
✤ コードストレージが1.5GBから75GBに

VPCアクセス
Photo credit: Matthew Wilkinson via Visual Hunt / CC BY-ND

VPCアクセス
✤ VPC内のリソースへインターネットを経由せずにアクセス可能
✤ Amazon Elasticache / Amazon RDS
✤ Private EC2 endpoints
✤ その他全てのVPC内リソース
✤ VPC内リソースにアクセスさせたいLambdaファンクションに対してVPCサブ
ネットおよびセキュリティグループを指定
✤ 新規作成時だけでなく既存のものを後から変更することも可能
✤ AZごとにサブネットを指定しておくのがおすすめ
✤ Elastic Network Interface(ENI)を利⽤して実現
✤ 作成・削除はLambdaによって完全にコントロールされる
✤ Lambdaファンクションへの初回アクセス時などENIの作成を伴う場合、最⼤60秒程度必要
✤ ENIには指定したサブネットのIPがDHCPで動的に割り当てられる
✤ ファンクションに割り当てるIAM Roleに”AWSLambdaVPCAccessExecutionRole”というポリ
シーをアタッチしておくこと

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

Photo credit: Tiberiu Ana via Visualhunt.com / CC BY
Node.js 4.3 サポート

Node.js 4.3のサポート
✤ 利⽤可能なNode.jsに4.3.2を追加
✤ 0.10も継続利⽤可能
✤ 2016年10⽉までは0.10での新規作成もサポート
✤ Node.js v4の特徴
✤ Node.jsとio.jsが統合。io.jsがv1〜v3までリリースされていたためv0.12からv4
に
✤ ES6（ECMAScript 2015、ES2015）のサポート範囲が拡⼤
✤ Allow関数
✤ “ let ”と “ const ”
✤ Promise

プログラミングモデルの変更
✤ コールバックモデルの導⼊
✤ context.done(), context.succeed(), context.fail()の3つのメソッドの代わりにコー
ルバックを利⽤
✤ contextオブジェクトのメソッドは継続して利⽤可能だが今後はコールバックモ
デルが推奨
✤ v0.10では利⽤不可
'use strict';
exports.handler = (event, context, callback) => {
console.log('value1 =', event.key1);
callback(null, event.key1);
};

コールバック
✤ Lambdaファンクションの返り値を定義する新しいオプション
✤ 何も指定されていない場合はファンクションの結果としてnullが返る
✤ contextオブジェクトに追加されたcallbackWaitsForEmptyEventLoop というプロパティで動作を制
御可能
✤ デフォルトはtrueになっており、全ての⾮同期処理の完了待ってレスポンス
✤ falseにするとコールバックがコールされると即座にフリーズ（v0.10と同じ）
callback(Error error, Object result);
シンタックス
✤ errorはファンクションの実⾏が失敗したときの結果を受け取るためのオプショナルパラメータ
✤ ファンクションが成功した場合はnullになる
✤ resultはファンクションの実⾏が成功したときに返す結果になる
✤ 実⾏が失敗した場合はerrorにその情報が格納され、このパラメータは無視される

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

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

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.

同時実⾏数の考え⽅
✤ イベントソースが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
“同時”に実⾏されているタイミング

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

VidRoll
✤ 課題
✤ EC2の管理が難しくなりつつあっ
た
✤ ITインフラではなくビジネスへの
フォーカスが必要
✤ 解決⽅法
✤ プレイヤーがAPI Gateway経由で
Lambdaを実⾏
✤ 動画のリアルタイム変換にも利⽤
✤ ベネフィット
✤ ⽣産性が向上し、収益が10倍に
なっても、エンジニアの追加なし

easy ten
Mobile app thathelps you learn
10 new,foreign words a day
Users have learned
170 000 000+
new words
• Featured in 85+ countries
• Top 5 grossing apps overall(Russia)
• Top 8 grossing apps overall(Brazil)
1 200 000+
downloads

これまでのアプローチ
✤ モノリシックなアプリを複数のEC2インスタンス上で稼働
✤ 複雑なデプロイ。⼀⾏の変更でも全体の再デプロイが必要
✤ スケーラビリティ/俊敏性と新機能のバランスを取る必要があり頻繁
なリリースができない

Lambda consumer
S3
Mobile
Analytics
DynamoDB
SQS
Amazon
EMR
Amazon
Cognito
Amazon
Kinesis
Mobile app
Amazon
Redshift
Lambda interface
S3 dump
DynamoDB log
Microservice Core

AWS Lambda Updates

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to AWS Lambda Updates

Similar to AWS Lambda Updates (20)

More from Keisuke Nishitani

More from Keisuke Nishitani (7)

Recently uploaded

Recently uploaded (8)

AWS Lambda Updates