遅い API にキャッシュをいれて速くしたい。サーバ側の話。

Tracing 結果をながめながら Bigtable の速度に感心する。Read が速い。Write もまあまあ速い。遅いのは Spanner. Spanner が遅いのは仕方ないから、こいつをストレージに使っているバックエンド API の結果は適当にキャッシュして速くしたい。Bigtable を HBase, Spanner を MySQL かなにかに読み替えてもらえばだいたい気分はわかるはず。

自分はサーバサイド要素技術の知識が 10 年前くらいで止まっているけれど、当時の LAMP スタックだとデータはぜんぶ MySQL などの RDB に入れ、遅い部分は memcached や Redis にキャッシュしておくのが定石だったと思う。キャッシュの validity を保つのが面倒だった。

Bigtable/HBase はだいたい十分に速いから、その上にキャッシュがほしくなることは少ない気がする。キャッシュを持ち込む複雑さを受け入れてまで 10ms を 5ms にしたいほど速度に厳しいシステムや API はそれほど多くないだろう。でも 100ms が 10ms になるなら頑張りたい人はいるに違いない。（数字はてきとうです。）

Bigtable/HBase のような速いストレージに RDB ほどの柔軟性はない。けれど一応 the source of the truth ではあるからキャッシュにともなう面倒もない。Caveat: replication の遅延とかで完全な consistency はない。Eventual のみ。

"RDB + Cache" モデルに対するこの "速い KVS(?) + 遅い RDB" モデルは、非正規化したスキーマを考える面倒なんかはあるにせよトータルな面倒量の差分は昔思ってたよりも少ない気がしてくる。特に速いものを作りたいと思っているのなら速いストレージを使うのはありだよな。たぶん。HBase はさておき Redis を HA 構成で動かしつつキャッシュ以外も色々保存している人々はそういう判断なのかもしれない。

でかいシステムのデザインを自分でイチから考える日は来なかろうとシステム構成の話題は無視しながら暮らしてきたけれど、少しはわかった方がいいよなあ。どうしたらわかるようになるのかわからないけれど、Netflix あたりのモダンなシステムの話を読むくらいはすべきなのかね。

なお自分がさわっているシステムのコードはだいぶ古めなので、以上の記述は勤務先の標準的な構成を示唆するものではない。とおもう。