[レポート] 【Gunosy様登壇】AWS を使ったモバイルアプリの設計と実装 #AWSSummit

aws-summit-tokyo-2016

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

AWS を使ったモバイルアプリの設計と実装

6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016Develoeprs Confrence のセッション「AWS を使ったモバイルアプリの設計と実装」を聴講しました。本記事はそのレポートです。

AWS のモバイル開発向けサービスは急速に進化を続けており、mBaaS の利用とは違う新しい形でモバイルアプリ開発をトータルにサポートしています。適切に活用していただくことで、プロダクトの開発スピード向上や運用コスト減に大きく寄与できる AWS モバイルサービス群。具体的なユースケースと最新情報を交えて、モバイルアプリエンジニアの方、バックエンドシステムのエンジニアの方に実践的な使い方をご紹介します。

スピーカーは 塚田 朗弘 氏(アマゾン ウェブ サービス ジャパン株式会社 技術本部 メディア・エンターテインメント部 ソリューションアーキテクト)です。

また、ゲストスピーカーは 松本 勇気 氏(株式会社Gunosy 開発本部執行役員)です。

セッション

自己紹介

塚田さんの自己紹介です。

  • ソリューションアーキテクト
  • 技術のご支援、ご相談
  • モバイルやスタートアップを担当
  • Ruby, iOS, Android などを使う
  • 専用線とかの低レイヤーも
  • 個人的なバックグラウンドはモバイル

セッションについて

  • AWS のモバイルサービス全般の解説
  • 開発者からの視点で話
  • アーキテクチャの分類
  • アプリ側の実装
  • ケーススタディ

本セッションの対象者

  • モバイルネイティブアプリのエンジニア
    • Swift とか Java とかで開発している人をイメージしてます
  • バックエンドシステムを触っているサーバーサイドエンジニアの方

パターンを知り、イメージし、コストを減らしてビジネスにフォーカスすることを目指しましょう。

AWS のモバイルサービス

AWS Management Console を開くとズラッとアイコンが並んでいます。その中でもモバイル特化したサービスがいくつかあります。

  • 紫はモバイル特化 (Cognito, SNS, Mobile Analytics, Device Farm, ...)
  • それ以外はモバイルに最適化されたもの (DynamoDB, S3, CloudFront, ...)

これらをトータルを使っていくことでモバイルアプリを構築できます。

AWS Mobile SDK

  • 全てのサービスに共通の認証機構
  • オフライン時の挙動は SDK が自動で処理
  • オフラインキャッシュを最大限

アーキテクチャ分類

一般 Web、サーバーレス、2-Tier という3つに分類し、それぞれの特徴とメリット・デメリットが紹介されました。

一般 Web

  • JSON on HTTP
  • スタンダードなパターンの1つ
  • ELB - EC2 - RDS
メリット
  • 非常に良くある一般的な構成
  • 非常に枯れた構成
  • JSONで通信は良くあり、これまで通り普通にやることができる
  • カスタマイズ性が高く、何でもできる
デメリット
  • メンテコストは低いが、インフラ面のことを気にしなければいけない
  • 運用、監視が付きもの

サーバーレス

  • conf開かれたり活発
  • API GW 使って RESTful な API を作る
  • JSONでやり取り
  • APIGW - Lambda - DDB
メリット
  • クライアント実装はそのまま活かせる
  • SDK が自動生成
  • コスト効率が高い (イベントドリブンなので、アイドル時にかからない)

2-Tier

  • サーバーレスの一形態
  • EC2 とかはない
  • AWS SDK を使って、API を直接呼ぶ
  • Lambda なり DDB なり、そのまま叩けば良い
メリット
  • インフラ運用、スケールは AWS が勝手にやってくれる (緩和申請が必要な場合が有る)
  • Cognito でセキュアなアクセス制御ができる
  • コスト効率が高い
デメリット
  • 枯れていない
  • AWS リソースに依存する
  • マネージドな部分がカスタマイズしづらい
  • 把握する必要がある
    • Mobile Hub を使うとプロビジョニングが楽になる

どのアーキテクチャを採用するか?

  • 三者一択ではなく、メリット・デメリットを見て組み合わせる
  • ここだけ API GW とかいう使い方でも全然OK

横断的アーキテクチャ

  • CF-S3でコンテンツ配信、アクセス制御は Cognito でも良いし Pre-Signed URL でも良い
  • User Pools でユーザー作成、MFA、サインアップ、サインインなどを楽に実装
  • 位置情報送信は Kinesis Stream 使ったり
  • Mobile Analytics でイベント送信、ダッシュボード化
    • マネタイズイベントを別に取っていて、売り上げとかもすぐに計上できる
  • Device Farm でテスト

アプリ側の実装

  1. Cognito Identity で Credentials を取得
  2. Device Token を取得して SNS に登録
  3. Cognito User Pools でサインアップ
  4. Lambda の Invoke

という流れの一連のサンプルコードを見ながら解説していただきました。

ケーススタディ

ここで、Gunosy の松本様から最新事例をご紹介いただきました。

自己紹介

  • 執行役員
  • 技術課題の解決を担当
  • iOS/Android/サーバーサイド

原稿ブロジェクト

  • ニュースパスをリリース
  • KDDI と連携
  • 「顧客視点」「多様なコンテンツ」×「配信ロジック」「運営ノウハウ」

ニュースパスについては、下記を参考してください。

今回の課題

  • 小さいチームで進めた
  • 迅速に意思決定
  • 少数精鋭
  • 4か月
  • 短期間にも関わらず高い安定性が求められている
  • 依存システムも多い
  • AWS を活用

どう活用したか

  • 一般 Web, サーバーレス, 2-Tier 全部組み合わせ
クライアントへの処理移譲
  • クライアントにロジック載せる
  • 認証、認可は Cognito Identity
  • 設定値保存は Cognito Sync
  • トークン管理は SNS
  • ログ配送は Kinesis Stream

部分的適用

  • 全てサーバーレスではダメ
  • コアな価値がなくなってしまう
  • データを推薦する仕組みは自分たちのロジックで
  • 非同期で、運用可能なものほど向いている
    • 設定値管理
    • ログ配送
  • 今までのシステムに混ぜていく

Tips

設定値とターゲッティング
  • 設定値の管理は Cognito Sync でクラウドに同期する
  • Cognito Event で Lambda フックで Elasticseatch に登録している
  • SNS に投げる
  • SQS にキューイング
  • プッシュシステムに入れる
  • Elasticsearch に突っ込む、対象者にクエリ投げる
Kinesis ログフロー
  • 中継するリソースを持たない
  • 再送ポリシーはクライアントで担保する
  • モバイルクライアントはバッファに貯める、バルクで送信
  • 通信が多すぎると電池消耗が激しいので、注意が必要
  • Lambda と Spark Streaming で RDS に保存
    • Hive Presto でバッチ集計

まとめ

  • モバイルアプリ開発時は AWS を柔軟に活用。いろいろなものを組み合わせる。必要なところに必要な量だけ。
  • フロントからバックエンドまで
  • SDK を使うとクライアント実装もバッチリ
  • モバイルスケーラブルでコスト効率が高いバックエンドを!

(Appendix) mBaaS との違い

  • mBaaS はバックエンドが基本的にブラックボックス
  • カスタマイズに限界がある
  • スタートダッシュには向いているが、成長後にはスケール不足になりがち
  • Parse.com から AWS に移行する相談が、非常に多い

感想

これまでの AWS のモバイル向けサービスのまとめのようなセッションで、初学者も経験者も非常に有益なセッションだったと思います。

ニュースパスの事例のアーキテクチャはかなり挑戦的で刺激的でした。早速アプリをインストールして使ってみたいと思います。