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

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