Cache Stampede
キャッシュが有効期限切れや削除によって参照できなかったとき、DB などにアクセスが集中して負荷が高まる問題のこと
例えばクライアントが同時に 1000 req してくる場合にはキャッシュが切れていたら1000req分 DB にアクセスロジックが入る。
これを解消するにはそのロジックを通る処理を一つに限定するようにしてやればいい。
例えば
- memory access
- 外部 メモリサーバアクセス
- DB アクセス
- set cache
というように組んでおけば、キャシュがない処理が正常終了したあとに memory access からデータを返すことができる
Thundering Herd など類義語はある
cache library
-
groupcache
- context が使えないかつメンテがもう滞っているが star 数や実績ともに十分そうに思える
- 最近だと orlic が似たような感じだと思う
- こっちの fork をつかってもよさそう
- このライブラリ自体が thundering herd 対策を備えている模様なので確かめてみたい
- comes with a cache filling mechanism. Whereas memcached just says "Sorry, cache miss", often resulting in a thundering herd of database (or whatever) loads from an unbounded number of clients (which has resulted in several fun outages), groupcache coordinates cache fills such that only one load in one process of an entire replicated set of processes populates the cache, then multiplexes the loaded value to all callers.
単純にmemory cache で速さを求めるなら ristretto が良さそう。
この記事 で詳細に書いてある。
TTL もあるし、一通りのやりたいことはできそうに思えた。
pprof data 収集
こんなやり方 もあるらしい。
pprof に接続する口をpublic にしたり認証つけるのも面倒そうだったのでどこかにストアできるのはありがたい。
本番で内部の状態見たいことはありがちなので、data-dog とかまだ未導入のときにパッと仕込んでみるのはよさそう。
S3 になげて athena で見るまでやってみたい。
CQRS
blog より
使い所としては、システム全体ではなく、bounded context のような局所的に導入すべきと書いてある。
スループットが求められる場合は利点があるが、それは Read用にデータを最適化して永続化する仕組みを整えればよいのではと書いてあった。
ReportingDatabase と呼ばれている。
DDD の同人誌には usecase で service 作って、その service 経由で usecase に適したデータを取得するという手段もあるということが書いてあったが、安易に導入すると複雑さが増すということは心にとめておく。
基本はパフォーマンスの壁に当たるまでは集約単位などで読み込んでデータを整形すればよさそう。