テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(akashic report) メタデータキャッシングv2

アカストは, BALによってbackendを抽象化している. backendによってはアカストにとって相性が悪く, 処理が異常に遅くなってしまうため, メタデータや認証用の情報などはメモリ上に保存してあげるということにしている. この前のベンチマークでは, 同一ファイルの並行GETで2ms/reqという性能を出していたが, メモリキャッシュを無効化するとこれが10ms以上になることはわかっている. ローカルファイルシステムでもそうなのだから, backendがリモートにある場合などは猛烈に遅くなる. 100ms/reqかかると言われたら, いくらS3は性能要件が緩いといっても誰も使わない.

現行のメタデータキャッシングv1では, backendから何かしらのユニークなKeyをもらえるのであればそれを使ってキャッシュするという仕組みだったが, このKeyの性質についてドキュメントを保持したくないため, 消しさることを考えている. 私は, 「遅すぎる」「複雑すぎる」ソフトウェアは何らかの設計上の誤りがあると思うので, 他人もきっとそう思う.

S3では上書きはほとんどない. 従って, 上書きを犠牲にしてどうにか出来ないかと考える. 現在考えているのは, ファイルのパス名とtimestamp(1秒粒度)を使うこと. この実装だと, 1秒以内に上書きがあるとキャッシュがバグってしまうケースがあるが, 1秒以内に上書きをするという稀なケースでは1秒待っていただくことにした. 複数スレッド, 複数ノードから同時に上書きや削除が実行された場合も救いようがないが, S3 APIがそのような使い方をされる可能性はほぼ0%なので棄てる. なぜ0%かというと, 通常, S3のバケットはオーナーに独占されるからである. 従って単一のオーナーが狂って同じファイルを複数ノードで上書きしまくるというご乱心を起こさなければ問題が起きない.

という, まぁまぁ妥当なアイデアを思いついて実装をしているのだが, 体調が悪く, バグがとれない.