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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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