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

Transcript

1. 1.

   同期について本気出して 考えてみた 2015/1/15 potatotips #13 @Gazyu

2. 2.

   About me twitter : @Gazyu Work : Sansan, Inc. Eight

   dev Hobby : Something make Android developer 2
3. 3.

   今日話したいこと みんな同期どうやってる？ 3

4. 4.

   クラウドサービス時代の端末アプリ辛い • サービスは複数端末、複数PFで見れて当たり前 • 1ユーザーが複数端末保持も結構ある • プライマリデータはサーバにある • 複数箇所で同時にデータ変更される可能性も •

   意外とまだ貧弱な無線通信網 4
5. 5.

   データの同期 • そもそもローカルにデータとかなくていいよ派 ◦ メリット ▪ 仕組みが簡単 ▪ 基本的にユーザーは意識せず最新のデータを見れる ▪

   端末の容量を食わない ◦ デメリット ▪ 通信網内にいないと死ぬ ▪ 通信速度が遅いと死ぬ ▪ サーバが死んでると死ぬ 5
6. 6.

   データの同期 • ローカルにキャッシュデータが有った方が良いよ派 ◦ メリット ▪ ローカルのデータはいつでも見れる ▪ データ表示スピードが早い ◦

   デメリット ▪ データを同期する機構が必要←意外と大変 ▪ 端末容量をくう ▪ 同期機構がちゃんとしてないとユーザークレーム 6
7. 7.

   日常使いユーテリティ系は • ローカルデータ保持 • 適切なサーバ同期 が良い気がする！ (※ただしアプリの設計による) 7

8. 8.

   Eightの場合 • 昔はローカルデータ持ってなかった • 今は端末にローカルデータを持っている ◦ SQLiteで持ってる ◦ 持ってるデータは自分が見えるデータのほぼすべて •

   差分同期してます ◦ 適当なタイミングでサーバと通信してる ◦ 仕組みはオリジナル 8
9. 9.

   Eightの同期の大まかな仕組み 1. サーバからとりあえず最新のデータ一式貰う 2. 適当なタイミングで差分が有るかサーバに問合せ 3. 差分があったらその分のデータを貰ってローカル のデータを更新 4. 2～3を繰り返す

   9
10. 10.

    1.サーバから最新のデータ一式貰う • サーバからその時点での自分の閲覧権限 の有るデータ全てもらう • サーバからのデータエクスポートの関係上 時間がかかる • データ形式は特殊 •

    タイミングはログインした時とユーザー操 作によって 10
11. 11.

    2.差分が有るかサーバに問合せ • サーバに更新チェックに行くタイミングはアプリの 起動中は頻度高めに • アプリが起動してなくても1日1回程度はチェック • いわゆるポーリング動作(間隔に重み付け有) 11

12. 12.

    安直な実装 それでも意外とそれっぽく動きますｗ 12

13. 13.

    更新チェックタイミングの検討 ◦ 一定時間毎、いわゆるポーリング ▪ メリット:実装簡単 ▪ デメリット:遅延、簡単だけどちゃんとしないといけない、iOSは最近 までアプリが起動してない時同期できない ◦ サーバからのプッシュ通知(GCM,APNS)が来たら

    ▪ メリット:実装簡単、そこそこリアルタイム、端末電力消費 ▪ デメリット:激しく遅延することあり、そもそも信用性？ ◦ サーバとセッションを開きっぱ（Websocket,Comet） ▪ メリット:リアルタイム ▪ デメリット:実装大変、サーバ負荷、端末電力消費高 ◦ ユーザー操作only(FB,twitter,タイムライン系？) ▪ メリット:実装簡単 ▪ デメリット:ユーザーからの理解 13
14. 14.

    なんでポーリング？ • ターゲット層の関係で自動で更新されるのは必須 • サービスの特性上そんなに更新は激しくない ◦ ≒同時に複数箇所での更新はあまりない • 設計時Push通知の信頼性が低かった ◦

    そもそもGCMじゃなくてC2DMとかの時代 • サーバの基本設計時に同期は考えられてなかった≒凝ったこと すると大規模改修が必要 • その時の工数が・・・（ゲフンゲフン 14
15. 15.

    3.差分があったらローカルのデータを更新 • ユーザーごとにデータの更新がされたタイミングでサーバ側で イベントと呼ばれているデータを生成 • イベントには、発生時刻と変更されたデータの種別が入ってい る • 更新されたデータの種別ごとに対応したデータ取得APIをコー ルする

    15
16. 16.

    イベントデータに含まれるデータの検討 ◦ 更新があったという情報のみ ▪ メリット:実装簡単 ▪ デメリット:データ取得でサーバへのアクセス回数増 ◦ 更新されたデータの実体 ▪

    メリット:1回のアクセスで全部取れる ▪ デメリット:更新データ量、更新情報の生成コスト ◦ ローカルSQLiteDB用のSQL ▪ メリット:端末側楽 ▪ デメリット:端末側のDBの設計自由度がなくなる 16
17. 17.

    なんで更新情報だけ？ • イベントが発生した時のサーバ負荷が小さい • 端末のDB設計を固定化するのが怖い • そもそもiOSとAndroidでDB構造が違う • サーバの基本設計時に同期は考えられてなかった≒凝ったこと すると大規模改修が必要

    • その時の工数が・・・（ゲフンゲフン 17
18. 18.

    まとめ • Eightの同期は変更イベントの蓄積とポーリング • ポーリングも捨てたもんじゃない • 同期を本気で考えると色々と面倒！ • 他のサービスってどうやってるの？（本題） 18

19. 19.

    余談SyncAdapterは？ • SyncAdapter使ってる？ ◦ Androidシステム標準の同期のための機構 ◦ なんか色々と便利にやってくれるっぽい ◦ Eightでは使ってない ▪

    設計時に情報が少なかった ▪ AccountManager+ContentProviderを使ってないシ ステムでどうなの？ ▪ ユーザーに端末設定→アカウント→詳細→同期って わかりやすいのかな？？ ▪ AlermManager+IntentServiceでダメな理由？ • AlermMangerにもファニーなタイミングでの呼び出し有るよね 19
20. 20.

    ご静聴ありがとうございました 20