要点: SearchはDerived Read Modelであり、Freshness、Deletion、Rebuildを説明できなければなりません。
課題
同期IndexingはWriteを遅くし、Shared IndexはTenant漏洩Risk、Schema変更は大規模Rebuildを必要とします。
単純な対策だけでは不十分な理由
許容LagとDB FallbackをProductで定義します。
Tenant FilterはTrusted Wrapperで強制します。
処理フロー
Source DB
Authoritative Change→Outbox・CDC
Durable Event→Indexer
Version Transform→Search Index
Tenant Read Model
Authoritative Change→Outbox・CDC
Durable Event→Indexer
Version Transform→Search Index
Tenant Read Model
アーキテクチャ上の判断
Versioned Document
遅延Eventの上書きを防ぎます。
SchemaとAlias分離
Immutable Index Versionを使います。
Offline・Online評価
Precision、Recall、成功Outcomeを測ります。
さらに深く考える
DeletionをFirst-class化
Primary、Index、Cache、BackupをPolicy通り処理します。
Rebuild CapacityがResilience
Recovery Objective内でFull Rebuildを試験します。
実装手順
- Commit済みChangeをOutbox・CDCで取得します。
- Document VersionとServer Tenant IDを使います。
- 新Indexを検証後AliasでAtomic切替します。
技術例: Alias-based Reindex
create index products_v3(mapping_v3)
bulk index snapshot with sourceVersion
consume changes after snapshot watermark
compare counts, samples and query set
atomic alias products_read: v2 -> v3Rollback Window中は旧IndexもFeedします。
想定すべき障害パターン
- 遅延Updateが削除Dataを復活させます。
- Tenant Filter漏れが越境します。
- ReindexがSource DBを飽和させます。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| Index Lag | Freshnessを測ります。 |
| Stale Version Reject | Out-of-order封じ込めです。 |
| Zero-result・Success率 | User OutcomeでRelevanceを測ります。 |
設計の検証方法
- Update・Delete Eventを遅延・逆順にします。
- Cross-tenant Negative Queryを実行します。
- Write中にFull Reindexします。
安全なRollout計画
既存IndexへDurable EventとVersionを導入し、新Mappingを並行比較後、少数TenantからAlias切替します。
本番前チェックリスト
- SearchをTransactionのSource of Truthにしません。
- Delete Propagationを測ります。
- 固定Query SetでRelevanceを評価します。
まとめ
信頼できるSearchには再構築可能Flow、Freshness、計測Relevanceが必要です。