View
13.066
Download
0
Category
Preview:
Citation preview
モバイル✕API Gateway ときどきLambda
NRIネットコム株式会社 佐々木拓郎
2015/9/8JAWS-UG 千葉支部 Vol.5 ～秋のAWS Lambda & API Gateway 祭り！！～
佐々木拓郎
AWSの事業推進の他に モバイルチームと データ解析チームの マネジメントをしています
blog: http://blog.takuros.net twitter: @dkfj
自己紹介
もう１つ宣伝
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のバージョンアップ並びに端末の多様化の問題 開発期間の短期化の問題
長年、開発・運用していると幾つもの課題が顕在化
プッシュ通知によるアクセス急増（バースト）
プッシュ通知に対して、ユーザは即時にレスポンス傾向が強い メルマガ配信より、負荷が集中しやすい サーバサイドの負荷集中の問題が発生しやすい
多様化するデバイス iOS2011年 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
多様化するデバイス Android2011年 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バージョンアップ、端末追加）が多く リリース頻度が多くなり、開発期間も短期化の傾向
モバイル・アプリ開発のまとめモバイル・アプリの開発は、２つの課題に集約される
サーバサイドの開発・運用・スケーラビリティ サーバサイドの開発・運用コスト アクセス集中時のスケーラビリティの問題
アプリ開発の工数増大と短期化との戦い 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/12APIの作成
適当な名前を入力
作成
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 MockSlow 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じゃないレスポンスも返すようになるのか？
ご静聴、ありがとうございました。
Recommended