キャッシュ・同期

ウィキペディア小見出し辞書

キャッシュ・同期

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/05/18 12:09 UTC 版)

「ウェブアプリケーション」の記事における「キャッシュ・同期」の解説

Webアプリはクライアント・サーバーモデルを基本としており、サーバーへのリソースリクエストを高い頻度でおこなう。より高速な動作、ネットワーク途絶下での動作を目的に、リソースのコピーを提供するキャッシュが要件に合わせて用いられる。以下のように、キャッシュはクライアントからサーバーバックエンドまで様々な段階でおこなわれる。クライアントに近ければ近いほどネットワーク遅延は小さくオフライン動作に強く、一方で同期の難しさも発生する。 アプリ内キャッシュ client-side proxy: Service Worker API Cache ブラウザキャッシュ:HTTPキャッシュ（HTTP ETag） Web Proxyキャッシュ コンテンツデリバリネットワーク（CDN） BFFキャッシュ DB in-memoryキャッシュ キャッシュは原理上、同期の問題を常に抱える。なぜならキャッシュとは基本的にコピーされた時間的に古いリソースの提供だからである。ゆえに各Webアプリの要件に合わせた採用が求められる。またPOST時にキャッシュへまず書き込みその後にキャッシュとバックエンドを同期する方式もある。この場合でも同期・競合の問題は原理的に存在する。 同期の手法として差分同期（delta sync）がある。同期のもっともシンプルな方法はキャッシュのリフレッシュ、すなわちすべてのデータを再取得する方法である。充分な計算・通信リソースがあるならば全てのデータが最新であることを容易に保証できる。しかしリソースに制限がある場合、キャッシュと最新データの差分（delta）のみを更新することで制限を解決できる。delta sync方式では複数のクエリ、BaseQueryとDeltaQuery（+SubscriptionQuery）が存在する。BaseQueryはキャッシュリフレッシュに相当する全件取得であり、DeltaQueryはデータソースからの差分情報取得である。データソースは更新情報をデータとは別に持っておき、DeltaQueryに応じて更新情報Queueから情報を送り出す。これにより既存データへのアクセスリソースを抑えながら同期が可能になる。DeltaQueryは定期的なfetch実行によって実現でき、リアルタイム更新を求めるならWebSocket等を用いたsubscriptionによる差分情報購読によっても実現できる。 Delta Syncを実装するうえではBaseQueryとDeltaQueryの使い分け、オフライン対応が重要な問題になる。ネットワーク途絶が発生した場合はBaseQueryしなおす設計にするのか、DeltaQueryのリクエスト頻度はどう制御するのか（c.f. exponential backoff+jitter）、Subscriptionの再接続は誰が責任を持つのかなどである。またデータソース側でどう差分情報を生成し保持するのか（生成方法、保存期間・形式）なども重要である。