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

Transcript

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

   View Slide

2. About me
   twitter : @Gazyu
   Work : Sansan, Inc. Eight dev
   Hobby : Something make
   Android developer
   2
   

   View Slide

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

   View Slide

4. クラウドサービス時代の端末アプリ辛い
   ● サービスは複数端末、複数PFで見れて当たり前
   ● 1ユーザーが複数端末保持も結構ある
   ● プライマリデータはサーバにある
   ● 複数箇所で同時にデータ変更される可能性も
   ● 意外とまだ貧弱な無線通信網
   4
   

   View Slide

5. データの同期
   ● そもそもローカルにデータとかなくていいよ派
   ○ メリット
   ■ 仕組みが簡単
   ■ 基本的にユーザーは意識せず最新のデータを見れる
   ■ 端末の容量を食わない
   ○ デメリット
   ■ 通信網内にいないと死ぬ
   ■ 通信速度が遅いと死ぬ
   ■ サーバが死んでると死ぬ
   5
   

   View Slide

6. データの同期
   ● ローカルにキャッシュデータが有った方が良いよ派
   ○ メリット
   ■ ローカルのデータはいつでも見れる
   ■ データ表示スピードが早い
   ○ デメリット
   ■ データを同期する機構が必要←意外と大変
   ■ 端末容量をくう
   ■ 同期機構がちゃんとしてないとユーザークレーム
   6
   

   View Slide

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

   View Slide

8. Eightの場合
   ● 昔はローカルデータ持ってなかった
   ● 今は端末にローカルデータを持っている
   ○ SQLiteで持ってる
   ○ 持ってるデータは自分が見えるデータのほぼすべて
   ● 差分同期してます
   ○ 適当なタイミングでサーバと通信してる
   ○ 仕組みはオリジナル
   8
   

   View Slide

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

   View Slide

10. 1.サーバから最新のデータ一式貰う
    ● サーバからその時点での自分の閲覧権限
    の有るデータ全てもらう
    ● サーバからのデータエクスポートの関係上
    時間がかかる
    ● データ形式は特殊
    ● タイミングはログインした時とユーザー操
    作によって
    10
    

    View Slide

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

    View Slide

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

    View Slide

13. 更新チェックタイミングの検討
    ○ 一定時間毎、いわゆるポーリング
    ■ メリット:実装簡単
    ■ デメリット:遅延、簡単だけどちゃんとしないといけない、iOSは最近
    までアプリが起動してない時同期できない
    ○ サーバからのプッシュ通知(GCM,APNS)が来たら
    ■ メリット:実装簡単、そこそこリアルタイム、端末電力消費
    ■ デメリット:激しく遅延することあり、そもそも信用性？
    ○ サーバとセッションを開きっぱ（Websocket,Comet）
    ■ メリット:リアルタイム
    ■ デメリット:実装大変、サーバ負荷、端末電力消費高
    ○ ユーザー操作only(FB,twitter,タイムライン系？)
    ■ メリット:実装簡単
    ■ デメリット:ユーザーからの理解
    13
    

    View Slide

14. なんでポーリング？
    ● ターゲット層の関係で自動で更新されるのは必須
    ● サービスの特性上そんなに更新は激しくない
    ○ ≒同時に複数箇所での更新はあまりない
    ● 設計時Push通知の信頼性が低かった
    ○ そもそもGCMじゃなくてC2DMとかの時代
    ● サーバの基本設計時に同期は考えられてなかった≒凝ったこと
    すると大規模改修が必要
    ● その時の工数が・・・（ゲフンゲフン
    14
    

    View Slide

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

    View Slide

16. イベントデータに含まれるデータの検討
    ○ 更新があったという情報のみ
    ■ メリット:実装簡単
    ■ デメリット:データ取得でサーバへのアクセス回数増
    ○ 更新されたデータの実体
    ■ メリット:1回のアクセスで全部取れる
    ■ デメリット:更新データ量、更新情報の生成コスト
    ○ ローカルSQLiteDB用のSQL
    ■ メリット:端末側楽
    ■ デメリット:端末側のDBの設計自由度がなくなる
    16
    

    View Slide

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

    View Slide

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

    View Slide

19. 余談SyncAdapterは？
    ● SyncAdapter使ってる？
    ○ Androidシステム標準の同期のための機構
    ○ なんか色々と便利にやってくれるっぽい
    ○ Eightでは使ってない
    ■ 設計時に情報が少なかった
    ■ AccountManager+ContentProviderを使ってないシ
    ステムでどうなの？
    ■ ユーザーに端末設定→アカウント→詳細→同期って
    わかりやすいのかな？？
    ■ AlermManager+IntentServiceでダメな理由？
    ● AlermMangerにもファニーなタイミングでの呼び出し有るよね
    19
    

    View Slide

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

    View Slide