(レポート) MBL302: モバイルやIoTのバックエンドをスケーラブルでサーバーレスに構築する #reinvent

2015.10.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Build Scalable, Serverless Mobile & IoT Back Ends with AWS Lambda

この記事は AWS re:Invent 2015、MBL302 - Building Scalable, Serverless Mobile and Internet of Things Back Endsのレポートです。

[slideshare id=53665179&doc=mbl302-151007201836-lva1-app6891]

スピーカーは Amazon Web Services の Ajay Nair、Olivier Klein、Easy Ten の Vasily Sochinsky、Kirill Potekhin です。

IMG_3818

スクリーンの調子が悪く、半分くらいのスライドが表示されない不具合に見舞われてしまいましたが、スピーカーの方々が上手くつないでいました。

このセッションで学べること

  • Lambda の概要
  • Cognito と Mobile Analytics の使いかた
  • API Gateway + Lambda + DynamoDB の CRUD バックエンドの作り方
  • Lambda のイベントドリブンなモバイルバックエンドとしてのパワーのレベレージ
  • SNS を通したモバイルに向けたプッシュとアラート
  • Easy Ten の取り組み

Lambda概要

  • イベントドリブンなコンピュートサービス
  1. サーバーレス
  2. イベントドリブンなスケール
  3. 秒以下の単位での請求

- Lambda の機能 - コードの持ち込み - パワーレベルの制御 - フレキシブルな連係 - 細かいパーミッション制御 - Lambda を使うには 1. 実装 2. 設定 3. デプロイ 4. ログ、モニタリング - さまざまなサービスをトリガとして動作可能 - Amazon Echo skills - Amazon S3 triggers - Amazon SWF tasks - Costomized notifications with Amazon SNS - Amazon Cognito triggers - Microservices with API Gateway - Amazon Dynamo DB triggers - Amazon Kinesis processors - AWS CloudFormation custom resources - 今後も増えていく

モバイルアプリのバックエンドのウィッシュリスト

何が必要か

  • User auth
  • Content storage
  • Push
  • Analyze
  • Custom app logic

どのように動作するか

  • Cost follow usage
  • Minimal undifferentiated heavy lifting
  • Iteratable development
  • Reduced time to market
  • Instant scale
  • Relietable

アーキテクチャ

  • Auth & Sync : Cognito
  • Analyse : Mobile Analytics
  • Run bisiness logic : Lambda
  • Store content : S3
  • Push : SNS
  • Store data : Dynamo DB

IMG_0200

サンプルアプリ "Find-a-Like"

サンプルアプリとして、位置情報を使ったアプリケーションの作り方を題材に解説。以下の機能を想定。

  • "興味"のプロフィールをアップロード
  • 継続的に位置情報をトラック
  • 同じ"興味"を持っている人に通知
  • アプリ上での行動履歴をログ&分析

使用するサービス

  1. プロフィール作成、コンテンツのアップロード、利用履歴のトラック : Cognito, MA, S3
  2. 位置情報と"興味"のトラック : API Gateway, DynamoDB, Lambda
  3. マッチングと通知 : SNS, Lambda

1. プロフィール作成、コンテンツのアップロード、利用履歴のトラック

ユーザー認証 : Cognito

  • 一時的な AWS Credential の付与と有効期間の制限
  • 3rd party の認証プロバイダの利用
  • 複数のデバイス利用時のユーザーのユニーク性
  • 匿名ユーザ
  • セキュリティのベストプラクティス

プロフィール作成 : Cognito Sync

  • ローカルのデータストアに保存
  • 他のデバイスとデータを同期
  • キーバリューで保存

プロフィール写真の投稿 : S3 Transfer Utility

  • データをS3に直接保存
  • アプリがバックグラウンドでも動作
  • バイナリデータのアップロード

利用履歴のトラック : Mobile Analytics

  • アプリの仕様統計をCollect, Visualize, Understandできる
  • 1日十億単位のイベントをスケーラブル・シームレスに送信
  • データを自由にコントロール可能

2. 位置情報と"興味"のトラック

  • 基本的な構成としては、バックエンドロジック組んでDBに保存
  • AWSではAPIGateway, Lambda, DynamoDBで実現可能
  • reportLocation()location-table に位置情報を保存
  • createInterest()interest-table に"興味"へのいいね!を保存
  • likeInterest() で"興味"へのいいね!を取得
  • listInterest() で"興味"の取得
  • GeohashをDynamoDBに保存
  • 位置情報をGeohash、つまり文字列に変換
  • 前方一致で検索可能
  • Javaのライブラリで利用可能 (https://github.com/awslabs/dynamodb-geo)

API Gateway

  • RESTfulなAPIゲートウェイサービス
  • CDNで動作
  • DDoSアタック対策、スロットリング
  • 各ステージ環境を定義可能
  • ダイレクトに DynamoDB に書き込まない理由
  • API Gateway を使うことで、モバイルからの送信〜ロジック、データ保存までの間にレイヤーを追加できる
  • 裏で動作する処理(Lambda function)の入れ替え
  • スロットリング
  • DDoSアタック対策
  • キャッシュレイヤー

3. マッチングと通知

  • Lambda を使ったイベントドリブンなコンピュートを活用
  • DynamoDB Stream で位置情報の更新がトリガーとなる
  • Cognito Event でプロフィールの作成がトリガーとなる
  • S3 event notification でプロフィール画像のアップロードがトリガーとなる
  • "興味"のマッチを探すアーキテクチャ
  • interest-table または location-table の更新で findMatch() が走る
  • findMatch() では interest-table の中でマッチしているアイテムを探す
  • マッチしているユーザーの Cognito Sync の中身を更新する

IMG_0220

SNS

  • クロスプラットフォーム向けのモバイルプッシュ
  • 1,000万規模のスケール
  • Topic の使用
  • Geo単位、興味単位、利用パターン単位など
  • findMatch() でマッチしたユーザーにPush!

最終的なアーキテクチャ

最終的なアーキテクチャがこちらです。

final-archtecture

まとめ

モバイル向けのサービスをうまく活用したサンプルアプリを通して、具体的にどのように構成すればいいのか、とても参考になるセッションでした。

ところで、IoT が出てきませんでした。…?