同期について本気出して考えてみた

1. 同期について本気出して 考えてみた 2015/1/15 potatotips #13 @Gazyu
2. About me twitter : @Gazyu Work : Sansan, Inc. Eight dev Hobby : Something make Android developer 2
3. 今日話したいこと みんな同期どうやってる？ 3
4. クラウドサービス時代の端末アプリ辛い • サービスは複数端末、複数PFで見れて当たり前 • 1ユーザーが複数端末保持も結構ある • プライマリデータはサーバにある • 複数箇所で同時にデータ変更される可能性も • 意外とまだ貧弱な無線通信網 4
5. データの同期 • そもそもローカルにデータとかなくていいよ派 ◦ メリット ▪ 仕組みが簡単 ▪ 基本的にユーザーは意識せず最新のデータを見れる ▪ 端末の容量を食わない ◦ デメリット ▪ 通信網内にいないと死ぬ ▪ 通信速度が遅いと死ぬ ▪ サーバが死んでると死ぬ 5
6. データの同期 • ローカルにキャッシュデータが有った方が良いよ派 ◦ メリット ▪ ローカルのデータはいつでも見れる ▪ データ表示スピードが早い ◦ デメリット ▪ データを同期する機構が必要←意外と大変 ▪ 端末容量をくう ▪ 同期機構がちゃんとしてないとユーザークレーム 6
7. 日常使いユーテリティ系は • ローカルデータ保持 • 適切なサーバ同期 が良い気がする！ (※ただしアプリの設計による) 7
8. Eightの場合 • 昔はローカルデータ持ってなかった • 今は端末にローカルデータを持っている ◦ SQLiteで持ってる ◦ 持ってるデータは自分が見えるデータのほぼすべて • 差分同期してます ◦ 適当なタイミングでサーバと通信してる ◦ 仕組みはオリジナル 8
9. Eightの同期の大まかな仕組み 1. サーバからとりあえず最新のデータ一式貰う 2. 適当なタイミングで差分が有るかサーバに問合せ 3. 差分があったらその分のデータを貰ってローカル のデータを更新 4. 2～3を繰り返す 9
10. 1.サーバから最新のデータ一式貰う • サーバからその時点での自分の閲覧権限 の有るデータ全てもらう • サーバからのデータエクスポートの関係上 時間がかかる • データ形式は特殊 • タイミングはログインした時とユーザー操 作によって 10
11. 2.差分が有るかサーバに問合せ • サーバに更新チェックに行くタイミングはアプリの 起動中は頻度高めに • アプリが起動してなくても1日1回程度はチェック • いわゆるポーリング動作(間隔に重み付け有) 11
12. 安直な実装 それでも意外とそれっぽく動きますｗ 12
13. 更新チェックタイミングの検討 ◦ 一定時間毎、いわゆるポーリング ▪ メリット:実装簡単 ▪ デメリット:遅延、簡単だけどちゃんとしないといけない、iOSは最近 までアプリが起動してない時同期できない ◦ サーバからのプッシュ通知(GCM,APNS)が来たら ▪ メリット:実装簡単、そこそこリアルタイム、端末電力消費 ▪ デメリット:激しく遅延することあり、そもそも信用性？ ◦ サーバとセッションを開きっぱ（Websocket,Comet） ▪ メリット:リアルタイム ▪ デメリット:実装大変、サーバ負荷、端末電力消費高 ◦ ユーザー操作only(FB,twitter,タイムライン系？) ▪ メリット:実装簡単 ▪ デメリット:ユーザーからの理解 13
14. なんでポーリング？ • ターゲット層の関係で自動で更新されるのは必須 • サービスの特性上そんなに更新は激しくない ◦ ≒同時に複数箇所での更新はあまりない • 設計時Push通知の信頼性が低かった ◦ そもそもGCMじゃなくてC2DMとかの時代 • サーバの基本設計時に同期は考えられてなかった≒凝ったこと すると大規模改修が必要 • その時の工数が・・・（ゲフンゲフン 14
15. 3.差分があったらローカルのデータを更新 • ユーザーごとにデータの更新がされたタイミングでサーバ側で イベントと呼ばれているデータを生成 • イベントには、発生時刻と変更されたデータの種別が入ってい る • 更新されたデータの種別ごとに対応したデータ取得APIをコー ルする 15
16. イベントデータに含まれるデータの検討 ◦ 更新があったという情報のみ ▪ メリット:実装簡単 ▪ デメリット:データ取得でサーバへのアクセス回数増 ◦ 更新されたデータの実体 ▪ メリット:1回のアクセスで全部取れる ▪ デメリット:更新データ量、更新情報の生成コスト ◦ ローカルSQLiteDB用のSQL ▪ メリット:端末側楽 ▪ デメリット:端末側のDBの設計自由度がなくなる 16
17. なんで更新情報だけ？ • イベントが発生した時のサーバ負荷が小さい • 端末のDB設計を固定化するのが怖い • そもそもiOSとAndroidでDB構造が違う • サーバの基本設計時に同期は考えられてなかった≒凝ったこと すると大規模改修が必要 • その時の工数が・・・（ゲフンゲフン 17
18. まとめ • Eightの同期は変更イベントの蓄積とポーリング • ポーリングも捨てたもんじゃない • 同期を本気で考えると色々と面倒！ • 他のサービスってどうやってるの？（本題） 18
19. 余談SyncAdapterは？ • SyncAdapter使ってる？ ◦ Androidシステム標準の同期のための機構 ◦ なんか色々と便利にやってくれるっぽい ◦ Eightでは使ってない ▪ 設計時に情報が少なかった ▪ AccountManager+ContentProviderを使ってないシ ステムでどうなの？ ▪ ユーザーに端末設定→アカウント→詳細→同期って わかりやすいのかな？？ ▪ AlermManager+IntentServiceでダメな理由？ • AlermMangerにもファニーなタイミングでの呼び出し有るよね 19
20. ご静聴ありがとうございました 20