# Watch(状態変更通知) ## 定義 Watch(watch abstraction)とは、コンシューマ(watcher)がストレージシステムのあるキー範囲・トランザクションバージョン以降の変更を購読し、変更イベント(onEvent)・進捗イベント(onProgress)・再同期イベント(onResync)の 3 種のコールバックで通知を受け取る抽象化である。追加のハード状態(ストレージ)を必要とせず、既存の永続ストアの上にレイヤーとして実装できる点が pubsub の内蔵メッセージログと本質的に異なる。Kubernetes API server(watchable な etcd ストア)と Spanner(Change Data Streams)がこの抽象化を普及させた。(Source: [[@2025__HOTOS__Understanding the limitations of pubsub systems]]) pubsub がメッセージング抽象化とハード状態のストレージ層を一体化(bundle)しているのに対し、watch はストレージを明示的に露出させたうえで、その変更を通知するだけの薄いレイヤーとして設計される。これにより、コンシューマは pubsub システムそのものではなく、監視対象のストア(producer storage または ingestion storage)に対する end-to-end 保証を受け取れる。(Source: [[@2025__HOTOS__Understanding the limitations of pubsub systems]]) ## 横断的知見 - **SONiCのRedis Pub/Subは、本conceptの原典が批判する「pubsubのbundle問題」をそのまま体現する実例である**: 原典は、pubsubがメッセージング抽象化とハード状態のストレージ層を一体化(bundle)している点を限界として指摘し、watchはストレージを明示的に露出したうえで変更通知だけを提供する薄いレイヤーとして設計すべきだと主張する。これに対し『実践SONiC入門』第8章が説明するSONiCの連携モデルは、Redis(ストレージ)がそれ自体でsubscribe機能(メッセージング)を内蔵しており、モジュールはRedisというひとつのシステムに対して読み書きと購読の両方を行う——原典の言葉で言えば、まさに「一体化した」pubsub型の設計である。SONiCはこの一体化を欠点ではなく前提として設計されており(モジュールはRedis以外の別ストアを持たない)、原典が指摘するbundle問題への対処(ストレージとメッセージングの分離)は行っていない。(Source: [[@2025__HOTOS__Understanding the limitations of pubsub systems]], [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ch.8 §8.1, §8.2) - **原典がKubernetes API server(watchable な etcd)を watch の代表例として挙げるのに対し、SONiCはetcdではなくRedisという別のストレージ層の上に類似の購読機構を実装しており、「watch相当の機能をどう実装するか」の設計選択肢が複数存在することを示す**: 原典はwatchを「追加のハード状態を必要とせず既存の永続ストアの上にレイヤーとして実装できる」抽象化として定義する。SONiCのRedis subscribeは、この定義に部分的に合致する(既存のRedisの上に追加のストレージなしで通知機能を実装している)が、原典が理想とする「ストレージを明示的に露出したうえで通知だけを提供する薄いレイヤー」とは異なり、Redis自身がストレージと通知を一体で提供する。同じ「既存ストアの上に通知機構を足す」という発想でも、実装がストレージシステム自身の機能(Redis pubsub)に依存するか、ストレージとは独立したレイヤー(原典が提案するWatchable API)として設計されるかで、疎結合の度合いが異なることがわかる。(Source: [[@2025__HOTOS__Understanding the limitations of pubsub systems]], ch.8 §8.1) ## 未解決の問い - Watch システムがメモリを超えるデータ構造を保持するために使う独自ストレージは「ソフト状態」とされ削除されても回復可能とされるが、実際の回復レイテンシ・データ量はどの程度になるか(著者ら自身が Snappy の性能評価をまだ示していない)。 - 複数 watcher の知識領域(knowledge region)を組み合わせて広いスケールでスナップショット一貫性のあるクエリを提供する具体的なプロトコル・データ構造は、著者ら自身が「今後の研究課題」として未解決のまま残している。 - watch ベースの異種ストレージシステム間レプリケーションが、Spanner の read-only replica のような同種展開で実現済みのスナップショット意味論・低レイテンシに実際に到達できるか(著者ら自身が「まだ多くの作業が必要」と認めている)。 - pubsub の consumer group・free consumer との移行コスト(既存 pubsub ベースシステムを watch ベースへ移行する際の互換性・段階的移行パス)は本論文では論じられていない。 - SONiCのようにストレージとメッセージングが一体化したシステム(Redis)を土台にすでに大規模に運用されている実例に対し、原典が提案する「ストレージを明示的に露出する薄いwatchレイヤー」への移行は、どの程度の設計変更コストを伴うか。両ソースを比較する限りでは論じられていない。 ## 関連 - [[@2025__HOTOS__Understanding the limitations of pubsub systems]] — Consumer API(`Watchable.watch()`)・Ingester API(`append()`/`progress()`)の仕様を提示した原典。 - [[Spanner]] — Change Data Streams という built-in watch の実例。 - [[分散メッセージブローカ]] — watch が代替しようとする pubsub の実装群(Kafka 等)。 - [[エンドツーエンド論]] — watch がコンシューマにストアへの end-to-end 保証を提供する設計根拠。 - [[変更データキャプチャ(CDC)]] — watch の Ingester API は CDC のレプリケーションログ公開と類似の役割を持つが、CDC がログベースメッセージブローカ経由の非同期配送に依存するのに対し、watch はキー範囲スコープの progress イベントで完全性を明示する点が異なる。 - [[分散キャッシュ]] — watch は動的シャーディング下でもスナップショット一貫性のあるキャッシュを実現する手段として提案されている。 - [[データベースを介した疎結合なモジュール連携]] — SONiCのRedis Pub/Subによるモジュール間連携。ストレージとメッセージングを一体化したまま疎結合を実現する対照的な設計。 - [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] — Redis subscribeがpubsubのbundle問題を体現する実例。 ## 出典 - [[@2025__HOTOS__Understanding the limitations of pubsub systems]](Atul Adya, Phil Bogle, Colin Meek、HOTOS 25) - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第8章 §8.1, §8.2.