Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Gazyu
January 15, 2015

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

Gazyu

January 15, 2015
Tweet

Other Decks in Programming

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. 安直な実装
    それでも意外とそれっぽく動きますw
    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