1.
Lambda & API Gateway
Amazon Web Services Japan
Shinpei Ohtani(ohtani@)

2.
クラウドネイティブの基本

3.
クラウドは新しい常識と
なりつつあります

4.
今やほとんどのアプリケーションが
クラウド上で稼働します

5.
クラウドを使う事＝差別化要因
から
クラウドを使わない事＝決定的な
技術的選択のミス・遅れ
へ変わる⽇も近い

6.
クラウドを使う
と
クラウドをうまく使う
の差

7.
クラウドプラットフォームの進化
EC2
RDS
Docker
ECS
Lambda
仮想マシン コンテナ ファンクション
仮想化ベース
・数分で起動
・長期間動く
コンテナベース
・数秒で起動
・数分から数時間動く
イベントベース
・ミリ秒で起動
・数秒動く
API Gateway

8.
この新しい常識の
パターン
とはどういったものか

9.
クラウドファーストから
クラウドネイティブへ

10.
クラウドネイティブとは（広義）
• クラウド上での稼働を前提に構築するシステムおよ
びアプリケーション
• クラウドの良さであるスケーラビリティ、ダイナ
ミックに可変可能な点、⾃動化、レジリエンシを中
⼼に構築
– ⼀般的にはDevOpsな運⽤体制を取る事が多い
• ビジネスの差別化ポイントへの集中
– 究極的にはビジネスに直結するアプリケーションの開発、管理のみ

11.
クラウドネイティブとは（狭義）
• AWSクラウド上で運⽤負荷が極端に低く、デフォ
ルトが低コストで実施可能なアプリケーション
• AWSが出しているマネージドサービスをフル活⽤
することで、開発のみに集中する
• AWSクラウド上で動く事を⼤前提にすることで、
無駄な部分を削ぎ落としていく
– ロックインは悪い事じゃなく、むしろ正しくロックインされる

12.
Less ops, more code

13.
Lambda API Gateway

14.
API GatewayLambda

15.
AWS Lambda
• インフラを⼀切気にすることなくアプリケー
ションコードを実⾏できるコンピュートサービ
ス
– 実⾏基盤は全てAWSが管理
– AWSサービスと連携させることで簡単にイベントドリブンなア
プリケーションを実装可能
– コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い

16.
AWS Lambda
• インフラを⼀切気にすることなくアプリケー
ションコードを実⾏できるコンピュートサービ
ス
– 実⾏基盤は全てAWSが管理
– AWSサービスと連携させることで簡単にイベントドリブンなア
プリケーションを実装可能
– コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い
やりたいこと
だけに集中できる

17.
AWS Lambda
• インフラを⼀切気にすることなくアプリケー
ションコードを実⾏できるコンピュートサービ
ス
– 実⾏基盤は全てAWSが管理
– AWSサービスと連携させることで簡単にイベントドリブンなア
プリケーションを実装可能
– コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い
ビジネスロジック
だけに集中できる

18.
例えば、
S3のバケットに画像が保存
されたらサムネイルイメー
ジを⽤意したい

19.
例えば、
DynamoDBに保存されるアドレス
が全て正しい形式かチェックしたい

20.
AWS Lambda以前

21.
解決⽅法は複雑
• クラウド側に問い合わせをして状態変
更を検知するアプリケーションを実装
• アプリケーションを稼働させるサーバ
群を⽤意
– OSの設定や⾔語環境の構築
– パッチ適⽤や更新をし続ける必要も
• 予測困難なリクエスト数に対し、ス
ケールや耐障害性を⾼める仕組みを⾃
⾝で構成
• キャパシティや状態、セキュリティな
どを24時間365⽇モニタリング

22.
AWS Lambda以降

23.
サムネイルの⽣成やリサイズ
• S3に画像がアップロードされたときにサムネイ
ルの⽣成やリサイズを実⾏
AWS LambdaAmazon S3 Bucket イベント
元画像 サムネイル画
像
1
2
3

24.
値チェックや別テーブルへのコピー
• DynamoDBへの書き込みに応じて値チェックを
し、別テーブルの更新やプッシュ通知を実⾏
AWS Lambda
Amazon DynamoDB
Table and Stream
プッシュ通知
別テーブルを更新

25.
S3にデータがアップロードされたら
DynamoDBにメタデータを同時に
追加したい

26.
S3イベントからバケット情報が
渡ってくる
そのままDynamoDBに保存

27.
「何をするか」
を書くだけでいい

28.
「何をするか」
を書くだけでいい
All you need is code.

29.
AWS Lambdaのお客様

30.
Lambdaの事例： FireEye

31.
AWS Lambda Updates
VPC Support (間もなく)
• VPC内のリソースへインターネットを経由せずにアクセス可能（RDS, ElastiCache etc)
• Lambdaファンクション作成時にVPCサブネット、セキュリティグループを選択
• AWSリソースへの接続元は選択したサブネット内のIPが動的に割り当てられる
バージョニングとエイリアス
• 特定のファンクションに対して、コードをアップロードすると⾃動でバージョン番号を割
当て
• 名前付きのエイリアスもサポートされ、バージョンやエイリアスを指定することが可能に
例）arn:aws:lambda:us-west-2:123456789012:function:PyFunc1:prod
Python 2.7のサポート
• LambdaファンクションをPython2.7で記述可能に
http://aws.typepad.com/aws_japan/2015/10/aws-lambda-update-python-vpc-increased-function-duration-
scheduling-and-more.html

32.
AWS Lambda Updates
タイムアウト時間の延⻑
• 最⼤300秒に延⻑
Scheduled Events
• Lambdaファンクションのスケジュール実⾏が可能に
• イベントソースとしてインターバルもしくはCron形式での指定
• 現在は最短インターバルは5分
• コンソールからの設定のみ
新しいデータソース
• Amazon SES inbound mail
• Amazon CloudWatch Logs
• Amazon Connected Home (Preview)
• AWS IoT

33.
Lambda API Gateway

34.
Amazon API Gateway
提供するAPIのバージョン管理
API利⽤状況のモニタ、管理とマネタイズ
APIに対する認証とアクセス権の管理
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス

35.
Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
リクエスト時におけるAWS SigV4の利⽤
リクエストのスロットリングとモニタリング
バックエンドとしてAWS Lambdaが利⽤可能

36.
AWS Lambda

37.
Amazon API Gateway
レスポンスをキャッシュ可能
CloudFrontを利⽤したレイテンシの軽減とDDoS対策
iOS、AndroidとJavaScript向けSDKの⾃動⽣成
Swaggerのサポート
Request / Responseにおけるデータ変換

38.
従来のアーキテクチャ
・認証API
・データ保存API
Web DB
LB

39.
クラウドネイティブなアーキテクチャ
Lambda
（ロジック）
API Gateway
DynamoDB
（データ保存）

40.
サーバレスで
全部できます

41.
サーバレスで
全部できます
やりたいこと
だけに集中できる

42.
サーバレスで
全部できます
ビジネスロジック
だけに集中できる

43.
Amazon API Gatewayの動作

44.
APIコールの流れ
Internet
Mobile Apps
Websites
Services
API
Gateway
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2 /
Amazon
Elastic
Beanstalk
Any other publicly
accessible endpoint
Amazon
CloudWatch
Monitoring

45.
API作成の流れ
1. 新規APIセットを作成
2. リソースおよびメソッドを定義
– メソッドを作成した時点でテスト可能となる
– 外部に公開はまだされていない状態
3. ステージへのデプロイ
– ステージは本番、開発といったデプロイ環境の管理を楽にしてくれる概念
– 各ステージごとにロギング、スロットリング、モニタリング、キャッシュの設定が可能
4. クローン
– 既存のものをクローンして新規バージョンとしてデプロイすることが可能
5. ロールバック
– 各ステージごとに300回分のデプロイ履歴を保持しており、いつでも過去バージョンに戻す
ことが可能

46.
API詳細
• API⾃⾝を最上位とした階層構造になっている
• API内にリソースを定義
– 複数定義
– リソース名がURLのパスの⼀部となる
– ネストすることも可能 ex) /pets/{petId}
• 各リソースにメソッドを定義
– メソッドはリソース＋HTTPメソッドで構成される
– スタンダードな7つのHTTPメソッドをサポート
Pet Store
/pets
/pets/{petId}
• GET
• POST
• PUT

47.
APIのデプロイ
• APIはステージにデプロイされる
• ステージはそれぞれ個別の環境を表す
• ステージ名はURIの⼀部となる
– 例:
Dev (e.g. awsapigateway.com/dev)
Beta (e.g. awsapigateway.com/beta)
Prod (e.g. awsapigateway.com/prod)
Pet Store
dev
beta
gamma
prod

48.
事例

49.
まとめ

50.
API GatewayとLambdaの活かし⽅

51.
Microservices
モノシリック
アプリケーション

52.
Cloud “glue”

53.
External interface wrapper
外部サービス
利用システム
外部サービスA
外部サービスB
外部サービスC
利用システムからは
サービス詳細を隠蔽
自システムでの
細かいコントロール

54.
Cloud “Servlet container” without EC2
Sync
invocation
Async
invocation
・msec単位での起動
・Node/Java/Pythonで作成可能
PC
モバイル

55.
APIfy(何でもAPI化)
EC2上で稼働する
既存アプリケーション
Beanstalk上で稼働する
既存アプリケーション
シンプルなものなら
API Gatewayのみで
多少の変換が必要なら
Lambdaもあわせて

56.
M2M interface
APIのみで人間を介さずに
システム間連携

57.
API Gateway x Lambdaで可能になった世界
• API Gateway x Lambdaはアプリ開発者のため
のAWSの新しいプラットフォーム
• API Gatewayによって・・・
– APIドリブンな開発の敷居が⼤きく下がった
– Amazonのように、APIビジネスを始めやすくなった
• Lambdaによって・・・
– クラウドの更に新しいプラットフォームとしてミリ病単位で
稼働できるプラットフォームが誰もが使えるようになった
– クラウド上のリソースの変化をキャッチできるようになった

58.
Lambda hack
console.log('Loading function');
exports.handler = function(event, context) {
var child_process = require('child_process');
child_process.exec("ls -latr /var/runtime/node_modules/awslambda/bin/", function(err, stdout, stderr) {
if (!err) {
console.log(stdout);
console.log(stderr);
} else {
console.log(err);
}
context.done();
});
};