Serverless Conf Tokyoにて。
Serverless with a native application for newspassGunosy Inc.2016.10
View Slide
2©Gunosy Inc.Agendaモバイル開発がなぜサーバレスに⾄至ったかl これまでのサーバの責務とモバイルの区分l 上記状態での課題l Lambdaに始まるサーバレスの時代とモバイルの役割Cognito・SNS・Kinesisを使ったモバイル開発l Cognito、SNS、Kinesisの紹介l 如何に組み合わせたか、解決したかった課題とは幾つかの罠とtipsl Cognitoとユーザーライフサイクルやl CognitoとLambdaのhookの関係l AWS SNSで考えるべきことニュースパスの開発におけるモバイル開発とサーバレスの関わりについて。
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で構成– 40⼈人以上の参加者が使うベンチマーカーがたった $3!!ニュースパスの開発や、監視、インターン企画などにて活⽤用中。
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 KinesisAmazonCognitoAmazonSNSクライアントアプリ
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.CognitoIdenitity SyncLambda設定値の保存AWSリソースに対して認証
14©Gunosy Inc.Cognitoを使ったピタゴラスイッチ設定値を配信⽤用のElasticsearchに保存する流流れをサーバレスに実現。AmazonCognitoMobile Client設定値Push: 有効トークン: aaaa…Push SystemCognitoSyncでLocalとAWS上を同期AWSLambdaQueueOn SQSAmazonSNSSyncイベントをフック Pushシステム側でDequeue => DB登録Amazon ElasticsearchServiceAmazonSNSMobile PuhSNSのエンドポイント登録無効なトークンの削除AmazonSNSMobile PuhPushをSNS経由で配信
15©Gunosy Inc.AWS SNSサービス改善の要をAWSを通じてプラットフォームを気にせず運⽤用できる。n iOS/Androidのトークンの扱いの違いや配信⽅方法の違いを吸収– 最終的にSNS Endpointに変換して利利⽤用しているn 通知の配信サイドもSNS Endpointの扱いのみで済む– ⼀一部、追加のペイロードなどは配信側責務で対応必要プラットフォームの間の差異異をクライアントで吸収し扱う。AmazonSNSiOS AndroidAPNSのトークンをSNS EndpointへGCMのトークンをSNS EndpointへバックエンドSNS Endpointとして送信・保存するSNSに対して通知送付
16©Gunosy Inc.AWS Kinesisスケーラブルで扱いやすいログ収集をKinesisで。n 全てのアクションをログ定義してクライアントから直接Kinesisへ配送– ⾃自前のサーバを介すことはないn ストリーム集計は、KinesisからSpark Streamingを介して集計。– （Tokyo RegionにKinesis analytics欲しいです…）n バッチ集計はKinesisからLambdaとS3を通じてPrestoに導いているアプリ内、すべてのイベント収集に利利⽤用。Amazon KinesisAWSLambdaログ用S3Amazon EMRSpark StreamingAmazonRDSPrestoへ
17©Gunosy Inc.AWS Kinesis with Puree再送設定やバッファリングなど必須機能をKinesisとともに簡易易に導⼊入。n iOS/Android双⽅方向けにライブラリありn クライアントサイド向けログコレクタ– fluentdと似た機構をもち、イベントを適宜バッファリングしつつ⾮非同期送信n ⾃自⾝身でOutputPluginを書く– Google Analyticsなどツールへの送信– 指定のログごとに違うストラテジでログを送ることが可能Cookpad社製のクライアント向けログコレクタを利利⽤用し、ログを効率率率的に運⽤用。event event eventPureeKinesisFilterBufferingfailRetry
18©Gunosy Inc.結局サーバレス以前の課題は解決できたのか？
19©Gunosy Inc.過去と今過去 現在リソース運⽤用Platform差分運⽤用認証・認可n ログコレクタを⽤用意し、APIから⼤大量量のログを配送、管理理n サーバ側で都度度ロジックを実装し、Platformの変化に追随n Gatewayやその裏裏のシステムが認証基盤とやり取りし制御n クライアントサイドで直接ログの加⼯工や配送など実施– Cognito + AWS Kinesisn それぞれのPlatform上で差分を吸収し、サーバとやり取り– AWS SNSなどの利利⽤用n Cognitoを利利⽤用し、IAM Roleと合わせてクライアントとAWSが直接実施多くの部分で課題が前に進んでいるAWSのツール群の利利⽤用で様々な運⽤用に変化。
20©Gunosy Inc.ただし、Server”less”とはいえど時には雲の上のことも考えよう
21©Gunosy Inc.これまで遭遇した幾つかの罠とtips（主にCognito周辺）
22©Gunosy Inc.AWS Cognitoを扱う上で考えるべきことAWSの提供機能と⾃自前で持つ部分の間で、データを重複させない。n Cognitoは多くの機能を提供している– 認証– ユーザー管理理 (User Pool)– 認可（IAM role）– 設定値補完（Cognito Sync)n ⾃自前でユーザーを持つのか、全てを任せるのかの線引– ⼆二重管理理を始める管理理フローが複雑化n 必要とする機能を⾒見見極める事が必要AWSへの認可を求めるのか、アカウント管理理を求めるのか判断する。AmazonCognitoバックエンド・AWSへの認可管理・サインインサービス上のユーザーこれらはどう関係するか？
23©Gunosy Inc.ユーザーの単位１その他のライフサイクル３SNSログイン２AWS Cognitoとアカウントライフサイクルn CognitoにおけるUnauthorized Userはデバイス単位– アンインストールでも同じユーザーが維持されるn 匿匿名の利利⽤用者に対してUnauthorized UserのCognitoIDを認証に使うか？n Cognito Identityは⼀一つのアカウントに複数のユーザーをひも付け可能– 同じSNSアカウントを起点に複数のCognitoIDをマージすることもできるn 1SNSアカウント = 1ユーザーかどうか、ユーザーをひも付け変更更可能かn インストール・アンインストールの扱い– ⾃自サービスは再インストールのユーザーを如何に扱うべきかユーザーライフサイクルについては、⾃自サービスと⼗十分に⽐比較すること。サービスの求めるライフサイクルと⼀一致しない場合の扱いを考えよう。
24©Gunosy Inc.AWS Cognitoの認可と各SDKの利利⽤用順序SDKの裏裏にある処理理の依存に気をつけ、どういった順序で扱うべきか考えるn データを持たないユーザーを発⾒見見– KinesisやSNSのSDKを同時に初期化していた– 認証が複数回叩かれ、同時にいくつもユーザーが⽣生成されるn 認証・認可の裏裏側での挙動を意識識してクライアントを実装する– Cognitoのユーザー⽣生成が完了了してから各種SDKの初期化を開始認証・認可は⾒見見かけ上同期のインターフェースだが、⾮非同期。CognitoAWS SDKUser①作成初期化1回目2回目User②作成ローカルにはUser②が残る
25©Gunosy Inc.AWS Cognito Syncの競合解決Cognito Syncに複雑なデータをもたせ過ぎないことも必要。n CognitoSyncはデータセットがsynchronizeされた際、競合する変更更があればsyncさせないn 適切切にハンドラを実装しローカル、リモートどちらの値を優先するのか、マージするのか、その処理理を実装する複数端末でSyncする際はデータセットの競合解決ロジックに責任を持つ。CognitoSyncAmazonCognitoDataset同じユーザー+ 別な端末別々にsynchronizeコンフリクト！！
26©Gunosy Inc.AWS Cognito SyncとLambdaフックの頻度度Cognitoに限らず、隠れているhook含めて頻度度を設計するn アプリ起動時などにsynchronizeすると容易易にLambdaの呼び出しが跳ねる– サービス規模によってはThrottlingが発⽣生し、hookが失敗するn 適切切なタイミングでsynchronizeを呼び出しましょうCognitoSyncは変化があれば必ずLambda hookを呼び出す。CognitoSyncAmazonCognitoDataset多数のsynchronizeAWSLambda毎度Invoke
27©Gunosy Inc.AWS SNS、古いEndpointの扱い通知の配送は時間がかかりやすいため、可能な限り無駄を減らすn 通知に必要なトークンは変化しうる– 特にAndroidはGCMトークンの変化が激しく、簡単に死んだEndpointが発⽣生していくn クライアントサイドで古いトークンに対応するEndpointを削除するSNSの運⽤用の⾯面倒はクライアントで解消すると楽AmazonSNSバックエンド新しいEndoint古いEndpoint無効なリクエスト新しいトークンの受け取り古いEndpointの削除Endpointの作成
28©Gunosy Inc.まとめ
29©Gunosy Inc.まとめn モバイルで分担できるロジックの領領域が増⼤大している– AWS Mobile SDKなどを使って多くの責務をクライアントでも担当可能になってきた– ユーザーのCPUも含めてスケールしていくn AWSの活⽤用について– ニュースパスでは、SNS・Kinesis・Cognitoを主に活⽤用– ログ配送やデータの保存などの領領域はクライアントから直接実施可能n 当然ですが、サーバレスも銀の弾丸ではない– 利利⽤用するサービスの仕様、そこから陥りうるであろうポイントを⾒見見つけていく必要がある– もっと知⾒見見共有し合いましょう！！！塩梅のいいところまで組み合わせましょう、過度度の適⽤用は厳禁。
30©Gunosy Inc.Gunosyでは新しいアーキテクチャに挑戦しつづける仲間を募集しています！！
ymatsuwitter
atinfinity
niftycorp
pocopota
pospome
ivanova1991
l2hyunwoo
varu3
uhooi
misatokii
kasacchiful
mtakeda15
mojombo
kevinliebholz
akosma
tanoku
jlugia
garrettdimon
tammielis
jonrohan
chrislema
panda_program
denniskardys
keavy