Cognito・SNS・Kinesisとモバイル開発のtips Gunosy  Inc. 2016.9

2 ©Gunosy  Inc. Agenda モバイル開発がなぜサーバレスに⾄至ったか l これまでのサーバの責務とモバイルの区分 l 上記状態での課題 l Lambdaに始まるサーバレスの時代とモバイルの役割 Cognito・SNS・Kinesisを使ったモバイル開発 l Cognito、SNS、Kinesisの紹介 l 如何に組み合わせたか、解決したかった課題とは 幾つかの罠とtips l Cognitoとユーザーライフサイクルや l CognitoとLambdaのhookの関係 l AWS  SNSで考えるべきこと これまでのサーバレスな開発における歴史とtipsを共有します。

3 ©Gunosy  Inc. ⾃自⼰己紹介 n Gunosy  Inc. – 新規事業開発室 執⾏行行役員 n 業務 – 開発全般のマネジメント – Go⾔言語布教係 – パフォーマンスチューニング – ISUCONとか好きです n 担当 – 右⼿手でiOS、左⼿手でAndroid – Web – Infrastructure(AWSのみ) n 最近の興味 – VR/AR/MR 松本 勇気 @y_̲matsuwitter

4 ©Gunosy  Inc. 株式会社Gunosy  – 「情報を世界中の⼈人に最適に届ける」 Gunosyは 情報キュレーションサービス「グノシー」と 2016年年6⽉月1⽇日にKDDI株式会社と共同でリリースした 無料料ニュース配信アプリ「ニュースパス」を提供する 会社です。「情報を世界中の⼈人に最適に届ける」を ビジョンに活動しています。 ネット上に存在するさまざまな情報を、 独⾃自のアルゴリズムで収集、評価付けを⾏行行い ユーザーに届けます。 情報キュレーションサービス 「グノシー」 200媒体以上のニュースソースをベースに、 新たに開発した情報解析・配信技術を⽤用いて⾃自動的に 選定したニュースや情報をユーザーに届けます。 無料料ニュース配信アプリ 「ニュースパス」

5 ©Gunosy  Inc. 最近の社内サーバレス事例例 新規開発にて多くの部分にサーバレスを適⽤用しています n ニュースパス – システム間の糊付け的部分 – AWS  Mobile  SDK活⽤用でのサーバレス n 監視 – LambdaからSlackへの通知系 n インターン企画 – ハッカソンの評価システムをLambdaで 構成 ニュースパスの開発や、監視、インターン企画などにて活⽤用中。

6 ©Gunosy  Inc. 今⽇日の話のスコープ 話すこと 話さないこと n クライアントサイドからみたサーバレ スの話 n AWS  Mobile SDKからのAWS利利⽤用を 中⼼心とした具体事例例 n そこから得られた知⾒見見 n インフラ管理理の効率率率化 n Lambdaを使ってのサーバ側実装の具 体事例例 n APIゲートウェイを使ってのWebサー バ開発など サーバレスアーキテクチャをクライアント視点で体験した話になります。

7 ©Gunosy  Inc. モバイル開発がなぜサーバレスに⾄至ったか

8 ©Gunosy  Inc. これまでのサーバの責務とモバイルの区分 クライアントはあくまでViewとしての役割。殆どのロジックはサーバサイド で担保していた。 バックエンド クライアントアプリ データの永続化 認証・認可 ビジネス ロジック ユーザーイベン トの受け取り データ API送付 ログストリーム の処理理 通知配信 データ配信 データ API送付 ログ分析 データの キャッシュ

9 ©Gunosy  Inc. 課題 100台のサーバ vs 1000万台のモバイルの世界での適切切なリソース運⽤用課題 CPU・メモリリソース １ サブシステムの認証認可問題 ３ プラットフォーム間の差分の吸収 ２ n ログの加⼯工処理理など多くのCPUを要する処理理がサーバサイドで⾏行行われている n 処理理⾃自体はそれほど複雑ではなく、とにかく分散したい処理理 n 概念念としては共通だが、インターフェースがiOSとAndroidで異異なるものの扱い。 n 例例としてPush通知のトークンの扱いなど n マイクロサービスとなってくるとどこのリソースにアクセス可能にするかの管理理が 必要 クライアントの種類・台数のスケールの難しさを吸収し、 端末のマシンリソースを活⽤用したい

10 ©Gunosy  Inc. サーバレスの始まりとモバイルの役割の変化 SDKを通じて、クライアントサイドのマシンリソース・ロジック実装の活⽤用 n クライアントから直接扱える領領域の拡⼤大 – 認証認可 – ログ配送 – Etc… n ロジックをクライアントで吸収する – プラットフォームの差を吸収して通知を 実現する n クライアントのリソースを活⽤用する – 画像処理理やデータ加⼯工など 多くの「よくあるビジネスロジック」を肩代わりするツールの登場。 Amazon   Kinesis Amazon Cognito Amazon SNS クライアントアプリ

11 ©Gunosy  Inc. グノシーとニュースパスの責務の持ち⽅方⽐比較 多くのロジックの配置がクライアントに置かれる実装へ。 ほぼ同じ⽬目的のサービスで、ニュースパスはサーバレスを活⽤用した責務配分に。 ログ配送 ログ集計 ニュース 配信 ニュース 推薦 通知管理理 UI 通知配信 AWSへの 認可 ログ配送 ログ集計 ニュース 配信 ニュース 推薦 通知管理理 UI 通知配信 AWSへの 認可 グノシー ニュースパス 水色が クライアントの責務

12 ©Gunosy  Inc. Cognito・SNS・Kinesisを使ったモバイル開発

13 ©Gunosy  Inc. AWS Cognito 全てのAWS SDK内認証・認可の基盤として利利⽤用。 n ユーザーのAWSリソースへの安全なアクセス の確保 – 内部で利利⽤用しているKinesisやSNSへの アクセスをIAM  Roleで絞ることができ る n CognitoSyncとLambdaを組み合わせて設定 値をElasticsearchに保存 – SNS・SQSを組み合わせて更更に多くの処 理理を同時実⾏行行可能 n 利利⽤用していないが、メールアドレスによる登 録とDB管理理も可能 AWSサービスへの認証認可・及びremoteとsync可能なkey-‐‑‒value  store. Cognito Idenitity Sync Lambda 設定値の保存 AWSリソースに 対して認証

14 ©Gunosy  Inc. AWS SNS サービス改善の要をAWSを通じてプラットフォームを気にせず運⽤用できる。 n iOS/Androidのトークンの扱いの違いや配信 ⽅方法の違いを吸収 – 最終的にSNS Endpointに変換して利利⽤用 している n 通知の配信サイドもSNS  Endpointの扱いの みで済む – ⼀一部、追加のペイロードなどは配信側責 務で対応必要 プラットフォームの間の差異異をクライアントで吸収し扱う。 Amazon SNS iOS Android APNSのトークンを SNS  Endpointへ GCMのトークンを SNS  Endpointへ バックエンド SNS  Endpointとして 送信・保存する SNSに対して通知送付

15 ©Gunosy  Inc. AWS Kinesis スケーラブルで扱いやすいログ収集をKinesisで。 n 全てのアクションをログ定義してクライアン トから直接Kinesisへ配送 – ⾃自前のサーバを介すことはない n 集計はKinesisからLambdaとS3を通じて Prestoに導いている n ログの再送・Bufferingは外部ライブラリで 担保 – Cookpad/pureeを利利⽤用 アプリ内、すべてのイベント収集に利利⽤用。 Amazon   Kinesis AWS Lambda ログ用S3 Amazon  EMR Spark  Streaming Amazon RDS Prestoへ

16 ©Gunosy  Inc. 結局サーバレス以前の課題は 解決できたのか？

17 ©Gunosy  Inc. 多くの部分でYES しかし新たな問題と戦う必要はある

18 ©Gunosy  Inc. これまで遭遇した幾つかの罠とtips （主にCognito周辺）

19 ©Gunosy  Inc. AWS Cognitoを扱う上で考えるべきこと AWSの提供機能と⾃自前で持つ部分の間で、データを重複させない。 n Cognitoは多くの機能を提供している – 認証 – ユーザー管理理 (User  Pool) – 認可（IAM role） – 設定値補完（Cognito Sync) n ⾃自前でユーザーを持つのか、全てを任せるの かの線引 – ⼆二重管理理を始める管理理フローが複雑化 n 必要とする機能を⾒見見極める事が必要 AWSへの認可を求めるのか、アカウント管理理を求めるのか判断する。 Amazon Cognito バックエンド ・AWSへの認可管理 ・サインイン サービス上の ユーザー これらはどう関係するか？

20 ©Gunosy  Inc. ユーザーの単位 １ その他のライフサイクル ３ SNSログイン ２ AWS Cognitoとアカウントライフサイクル n CognitoにおけるUnauthorized  Userはデバイス単位 – アンインストールでも同じユーザーが維持される n 匿匿名の利利⽤用者に対してUnauthorized  UserのCognitoIDを認証に使うか？ n Cognito Identityは⼀一つのアカウントに複数のユーザーをひも付け可能 – 同じSNSアカウントを起点に複数のCognitoIDをマージすることもできる n 1SNSアカウント =  1ユーザーかどうか、ユーザーをひも付け変更更可能か n インストール・アンインストールの扱い – ⾃自サービスは再インストールのユーザーを如何に扱うべきか ユーザーライフサイクルについては、⾃自サービスと⼗十分に⽐比較すること。 サービスの求めるライフサイクルと⼀一致しない場合の扱いを考えよう。

21 ©Gunosy  Inc. AWS Cognitoの認可と各SDKの利利⽤用順序 SDKの裏裏にある処理理の依存に気をつけ、どういった順序で扱うべきか考える n データを持たないユーザーを発⾒見見 – KinesisやSNSのSDKを同時に初期化し ていた – 認証が複数回叩かれ、同時にいくつもユ ーザーが⽣生成される n 認証・認可の裏裏側での挙動を意識識してクライ アントを実装する – Cognitoのユーザー⽣生成が完了了してから 各種SDKの初期化を開始 認証・認可は⾒見見かけ上同期のインターフェースだが、⾮非同期。 Cognito AWS  SDK User①作成 初期化1回目 2回目 User②作成 ローカルには User②が残る

22 ©Gunosy  Inc. AWS Cognito Syncの競合解決 Cognito Syncに複雑なデータをもたせ過ぎないことも必要。 n CognitoSyncはデータセットがsynchronize された際、競合する変更更があればsyncさせな い n 適切切にハンドラを実装しローカル、リモート どちらの値を優先するのか、マージするのか 、その処理理を実装する 複数端末でSyncする際はデータセットの競合解決ロジックに責任を持つ。 CognitoSync Amazon Cognito Dataset 同じユーザー +  別な端末 別々にsynchronize コンフリクト！！

23 ©Gunosy  Inc. AWS Cognito SyncとLambdaフックの頻度度 Cognitoに限らず、隠れているhook含めて頻度度を設計する n アプリ起動時などにsynchronizeすると容易易 にLambdaの呼び出しが跳ねる – サービス規模によってはThrottlingが発 ⽣生し、hookが失敗する n 適切切なタイミングでsynchronizeを呼び出し ましょう CognitoSyncは変化があれば必ずLambda hookを呼び出す。 CognitoSync Amazon Cognito Dataset 多数のsynchronize AWS Lambda 毎度Invoke

24 ©Gunosy  Inc. AWS SNS、古いEndpointの扱い 通知の配送は時間がかかりやすいため、可能な限り無駄を減らす n 通知に必要なトークンは変化しうる – 特にAndroidはGCMトークンの変化が激 しく、簡単に死んだEndpointが発⽣生し ていく n クライアントサイドで古いトークンに対応す るEndpointを削除する SNSの運⽤用の⾯面倒はクライアントで解消すると楽 Amazon SNS バックエンド 新しいEndoint 古いEndpoint 無効なリクエスト 新しいトークン の受け取り 古いEndpointの削除 Endpointの作成

25 ©Gunosy  Inc. まとめ

26 ©Gunosy  Inc. まとめ n モバイルで分担できるロジックの領領域が増⼤大している – AWS Mobile  SDKなどを使って多くの責務をクライアントでも 担当可能になってきた – ユーザーのCPUも含めてスケールしていく n AWSの活⽤用について – ニュースパスでは、SNS・Kinesis・Cognitoを主に活⽤用 – ログ配送やデータの保存などの領領域はクライアントから直接実 施可能 n 当然ですが、サーバレスも銀の弾丸ではない – 利利⽤用するサービスの仕様、そこから陥りうるであろうポイント を⾒見見つけていく必要がある – もっと知⾒見見共有し合いましょう！！！ 塩梅のいいところまで組み合わせましょう、過度度の適⽤用は厳禁。

27 ©Gunosy  Inc. 新しいアーキテクチャに⼀一緒に挑戦する 仲間を募集しています！！