SlideShare a Scribd company logo
モバイル✕API Gateway
ときどきLambda
NRIネットコム株式会社 
佐々木拓郎
2015/9/8JAWS-UG 千葉支部 Vol.5
∼秋のAWS Lambda & API Gateway 祭り!!∼
佐々木拓郎
AWSの事業推進の他に
モバイルチームと
データ解析チームの
マネジメントをしています
blog: http://blog.takuros.net
twitter: @dkfj
自己紹介
もう1つ宣伝
Amazon Web Services
パターン別構築・運用ガイド
一番大切な知識と技術が身につく
http://amzn.to/1BLiYcO
AWSの一番分厚い本
(大容量480ページ)
もうちょっと宣伝
WEB+DB PRESS Vol.88
モバイル開発最前線 ――
ビルドもテストもデプロイも
クラウドで加速!
http://amzn.to/1QhqBl7
DeviceFarmの話も少し載せています
まだまだ宣伝
Rubyによるクローラー開発技法
巡回・解析機能の実装と21の運用例
http://amzn.to/1lsJ5id
2014年 ジュンク堂書店 
コンピュータ書 年間総合ランキング14位
NRIネットコム
Web周りのビジネスを専門としている会社
• Webシステムの企画・設計・開発・運用
• 24時間365日の運用体制
• デザインを重視し、ディレクター/デザイナーが多数在籍
• スマホ/タブレットも得意
• AWSをはじめとするクラウドにも力を入れている
• 最近のトレンドは、デジタルマーケティング
会社の紹介
こんな会社です
新しいもの好き
2015年6月
Pepper部長
入社
たまに頭を抱えています
NAOもいます
モバイル✕API Gateway
ときどきLambda
アンケート
アプリケーションエンジニアとしての経験ある人?
インフラエンジニアとしての経験ある人?
Webサイトのシステム開発したことがある人?
モバイルアプリを開発したことがある人?
AWSを使ったことがある人?
Lambda使ったことある人?
API Gateway使ったことがある人
今日の目的
モバイルアプリの開発の実際と
AWSの本気さを実感してください
モバイル・アプリとは?
ネイティブアプリ
スマホアプリ
Webアプリ
スマホアプリ側にアプリを実装
サーバと連携することが多い
サーバ側にアプリを実装
WebViewでアプリに表示する
モバイル サーバ
json,xml等
アプリの
実体
モバイル サーバ
HTML/CSS等
アプリの
実体
実際は、両者を組み合わせた
ハイブリッドが多い
モバイル・アプリ開発の課題
アクセス急増(バースト)時のサーバサイドのスケーラビ
リティの問題
OSのバージョンアップ並びに端末の多様化の問題
開発期間の短期化の問題
長年、開発・運用していると幾つもの課題が顕在化
プッシュ通知によるアクセス急増(バースト)
プッシュ通知に対して、ユーザは即時にレスポンス傾向が
強い
メルマガ配信より、負荷が集中しやすい
サーバサイドの負荷集中の問題が発生しやすい
多様化するデバイス iOS
2011年 2012年 2013年 2014年
Version 5.0 6.0 7.0 8.0
Device
iPhone4s
iPad 3rd
iPhone5
iPad 4th
iPad mini
iPhone5S
iPhone5C
iPad Air
iPad mini 2
iPhone6
iPhone6 plus
iPad Air2
iPad mini 3
多様化するデバイス Android
2011年 2012年 2013年 2014年
Version 2.3 - 4.0 4.1 - 4.3 4.4 5.0
Device
Galaxy S2
Regza Phone
Arrows X
MEDIAS LTE
Xperia NX
Galaxy Note
Xperia SX
Arrows A
AQUOS Phone EX
Galaxy note3
Nexus5
Xperia Z3
Android Wear
Nexus6
Nexus9
開発期間の短期化
2013/05 ver1.0.0 リリース ファースト
2014/02 ver1.1.0 リリース iOS7対応
2014/10 ver2.0.0 リリース デザインリニューアル
2015/02 ver2.2.0 リリース iOS8対応
開発サイクル例
間に9回リリース
間に4回リリース
間に2回リリース
ビジネス的な要件(機能追加etc)以外に、
外的要因(OSバージョンアップ、端末追加)が多く
リリース頻度が多くなり、開発期間も短期化の傾向
モバイル・アプリ開発のまとめ
モバイル・アプリの開発は、2つの課題に集約される
サーバサイドの開発・運用・スケーラビリティ
サーバサイドの開発・運用コスト
アクセス集中時のスケーラビリティの問題
アプリ開発の工数増大と短期化との戦い
OS/端末の多様化による開発・テスト工数の増大
短いリリース周期に対応する必要性
AWSを利用すると
何が解決されるのか?
AWSのモバイル向けサービスの歴史(一部)
Amazon Cognito 2014年7月発表
認証・認可のサービス
Amazon Lambda 2014年11月発表
イベント・ドリブンなコンピュートエンジン
AWS Device Farm 2015年7月発表
クラウド上でモバイルアプリを実機でテスト
Amazon APIGateway 2015年7月発表
API作成サービス
API GatewayのWebnierを受講した時の感想
クラウドファーストから
クラウドネイティブへ
AWSの標語(たぶん)
或いは、点から線へ 線から面へ
API GatewayのMock機能を利用して
モバイルアプリ開発に役立てる
スタブAPIの作成(Before API Gateway)
S3のWebホスティング機能を利用
{ JSON }
JSONファイルの
アップロード
リクエスト
レスポンス
それなりに便利。一方で、
レスポンスを変える為に、都度アップロードは面倒
レスポンスコードが、変えられない
Client
モバイル
S3 Web
スタブAPIの作成(After API Gateway)
API Gatewayのモック機能を利用
{ JSON }
管理コンソールから
JSONファイルの
入力
リクエスト
レスポンス
簡単・便利
Mock機能で静的JSONを返すAPIを簡単につくれる
レスポンスコードも変えられる
詳細は、こちら
APIGateway - Amazon API GatewayでMockを定義してみる - Qiita
http://qiita.com/Keisuke69/items/0852d536110b2fa6e087
モバイル
API Gateway
AWS Management
Console
API Gateway モック機能の使い方 デモ
API Gateway モック機能の使い方 1/12
APIの作成
適当な名前を入力
作成
API Gateway モック機能の使い方 2/12
リソース(Resource)の作成
Create Resourceを
クリック
リソース名( URL Path)
の決定
API Gateway モック機能の使い方 3/12
メソッド(Method)の作成 1
①Create Methodを
クリック
②Methodの種類を
選択
③保存
API Gateway モック機能の使い方 4/12
メソッド(Method)の作成 2
Mock Integrationを
選択して「Save」
API Gateway モック機能の使い方 5/12
メソッド(Method)の作成 3
Integration Responseを
クリック
API Gateway モック機能の使い方 6/12
メソッド(Method)の作成 4
①ここを選択
②更にMapping Templatesを選択
API Gateway モック機能の使い方 7/12
メソッド(Method)の作成 5
①application/jsonを
クリック
②Output passthrough
横の鉛筆印をクリック
API Gateway モック機能の使い方 8/12
メソッド(Method)の作成 6
①Mapping templateを
選択して保存
②任意のJSONを
貼り付けて「Save」
API Gateway モック機能の使い方 9/12
テスト
①TESTをクリック
API Gateway モック機能の使い方 10/12
テスト
①TESTをクリック
②想定のStatusで
想定のレスポンスがあればO.K.
API Gateway モック機能の使い方 11/12
デプロイ
①Deploy APIをクリック
Stage nameを記入して
Deploy
API Gateway モック機能の使い方 12/12
デプロイ
URL/Stage名/リソース名でアクセス可能
Lambdaと組み合わせて
APIの遅延を再現
API Gateway+LambdaでSlow Mock
レスポンスの遅いSlow Mockを作ることでUXの調整
リクエスト
N秒後に
レスポンス
Slow Mockの意義
実際のAPIのレスポンスは、遅い場合もある
レスポンスの速いMockだけでUXを検討すると、後工
程で困る場合がある
数秒、数十秒の遅延を与えて、UXを調整していく
モバイル API Gateway
リクエスト
レスポンス
Sleep処理
Lambda
API Gateway+LambdaでSlow Mock
Slow Mockの作り方
console.log('Loading function');
exports.handler = function(event, context) {
console.log('before =', new Date().getTime());
var time = 3000;
var d1 = new Date().getTime();
var d2 = new Date().getTime();
while (d2 < d1 + time) {
d2 = new Date().getTime();
}
console.log('after =', new Date().getTime());
context.succeed("Success");
};
簡単に作るのであれば、LambdaでSleepするだけ。
API GatewayでMockを返す。
真面目に作るのであれば、引数・返却値を返すようにする
既存サービスを
API Gatewayを利用して
置き換えてみた
とあるサービス
http://www.nri-net.com/mobileconf/
https://www.youtube.com/watch?v=7Rk2pL3PAXc
とあるサービス
サーバサイドに資料をおいて、iPadで共有・同期
データ・処理の流れ
Webサーバ データベース
会議システム
参照ページの通知
初回ダウンロード
参照ページの同期
処理を簡略化すると、次のような流れになっている
サーバ側のお守りは、それなりに手間が掛かる
AWSのサービスだけ利用して構築
IAM Role
DynamoDB
(NoSQL DBサービス)
Cognito
(認証・権限管理サービス)
S3
(ストレージサービス)
JavaScript
SDK
DynamoDBのスループットの設定で、
システムのキャパシティを向上できる
サーバレスで楽ちん
資料のダウンロード
参照ページの通知・同期
AWS利用権限の付与
Before API Gateway
API Gatewayを利用して作ると
DynamoDB
S3
クライアント側は、全くAWSを意識せず作れる
API Gateway
Lambda
ページ番号の
参照・保存
資料の
ダウンロード
WebSocketで
ページ同期
ページの通知
各種APIの呼び出し
Mapping Template
(最初の難関)
Mapping Templateの利用 リクエスト編
①Method Requestで、
Modelの作成
②Integration Requestで、
Mapping Templateの作成
Mapping Templateの利用 リクエスト編
Modelの作成
{
"operation": "update",
"conference_id": 1,
"page_number": 4
} {
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "SyncSlide",
"type": "object",
"properties": {
"operation": { "type": "string" },
"conference_id": { "type": "number" },
"page_number": { "type": "number" }
}
}
元のJSON
Model
詳細は、こちら
Working with Models and Mapping Templates in Amazon API Gateway
http://docs.aws.amazon.com/apigateway/latest/developerguide/models-mappings.html
Mapping Templateの利用 リクエスト編
Mapping Templateで引数を利用
{
"operation": "update",
"conference_id": "1",
"page_number": $input.json('$.page_number')
}
$input.json( $.項目名 )で、JSONの値を代入
$input.json( $ )で、JSON全体を渡すことも
QueryStringの場合は、$input.params('foo')
その他、変数が幾つかある
詳細は、こちら
API Gateway Mapping Template Reference
http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-
reference.html
Mapping Templateの利用 レスポンス編
レスポンスの加工も、基本的には同じ
②Integration Responseで、
Model等を利用して整形
①Method Responseで、
Contents-Type等の定義
JSON XMLに変換
#set($root = $input.path("$"))
<xml>
<id>
$root.id
</id>
<title>
$root.title
</title>
</xml>
{
"id": 1,
"name": "hoge"
}
元のJSON
Mapping Template
出力されたXML
JSON HTMLに変換
その気になれば、HTMLも直接出力できる
#set($root = $input.path("$"))
<html>
<body>
ID=$root.id<br/>
Name=$root.name<br/>
</body>
</html>
{
"id": 1,
"name": "hoge"
}
元のJSON
Mapping Template
まったくお勧めしません
API Gatewayを利用してみて
個人的な感想
基本的には、簡単便利
Getメソッドは簡単。Postメソッドは悩む
Postの最初の難関は、Modelとのマッピング
CORSなど、呼出側を考慮した情報が少ない
AWS Proxyは、まだ解らないところだらけ
管理コンソールのUIは良く出来てるが、だんだん面
倒くさくなる。 CLIに挑戦予定。そのうちFluctか?
認証周りについては、いろいろ検討中
1年後には、これしか使っていないような気がする
JSONじゃないレスポンスも返すようになるのか?
ご静聴、ありがとうございました。

More Related Content

Jawsug chiba API Gateway