前回、元データとキャッシュが１：１で対応するときのコツを書いた。今回は全体を集計した結果のキャッシュの話をする。難易度が1段上がる。

まずどのようなキャッシュが該当するか考えよう。月ごとの売上を合計して画面に表示するプログラムがあったとしよう。このようなSQLになる。

select month , sum(price) as month_sum from sales group by month;

売上件数が多ければ結構な時間がかかってしまう。そこで、別テーブルに集計しておき、次回はそこからデータをとってくることにした。

create table cache_month_sales as select month , sum(price) as month_sum from sales group by month;

この場合、salesテーブルのどの行がキャッシュテーブルのどの行に対応するか明確に決まっていない。このキャッシュは元データ全体に対するキャッシュだ。

このキャッシュの難しさは以下の二点だ

元データのどこが変更されたらキャッシュのどこを更新しないといけないか一概にいえなくなる
別の処理がキャッシュに依存している

１は、先述の例は簡単すぎたが、もっと複雑な集計をすることもある。例えば各月のランクもキャッシュしていたなら、salesテーブルを1行変えただけで順位の入れ代わりを計算することになる。

２は、元データからすぐに集計結果を出せるわけではないので、キャッシュが存在しなければ元データからデータを取り出そうという実装ができない。

では、このようなキャッシュを作るうえで気をつけたいことを挙げる。まず、元データに更新がかかったらキャッシュを全部作り直すか部分的に更新するか決めよう。先の例であれば、部分的に更新するSQLはこうだ。

insert into sales values( ? , ? );
update  cache_month_sales set month_sum + ? where month = ?;

全部一気に更新するならこうだ。

drop table if exists cache_month_sales;

create table cache_month_sales as select month , sum(price) as month_sum from sales group by month;

これらは主に読み込みと書き込みの頻度を元に決める。書き込みが頻繁なら部分アップデートをしなければいけないがたまにしか書き込まれないなら全体を洗いがえてもいい。部分を更新するほうを選ぶときは、それなりに覚悟を持って。次に、どちらを選ぶにせよ全部一気に更新する方法を用意しよう。最後に、前回も話したが全部一気に更新する間違えにくいUIを用意しておこう。あなたが一番あせってるときに間違えないUIだ。

補足

PostgreSQLを使っている場合、Materialized Viewというそのまんまの機能があるのでそっちを使おう。

正規化したTableとキャッシュ用のテーブルの区別がつくように、キャッシュ用のテーブルにはすべてcache_やmareriarized_などのPrefixをつけよう。

全部一気に更新するときにdrop tableしてから create tableしたが、truncateからのinsert selectのほうがいいかも。

create tableしたら alter add indexをしたほうがいい場合があるので忘れないように。

2017-10-25

元データとキャッシュデータが1:1で対応する時のコツ

元データとキャッシュデータが1:1で対応するとは、キャッシュ層に元データの一部を置いてある状態である。この場合、キャッシュのデータは元データのどの部分かはっきりしている。例えば、47都道府県の市町村リストがあり、その中で茨城と島根のデータをローカルにキャッシュしてあるような状況を想像してほしい。このようなキャッシュは、元データが変更されたらキャッシュデータの何を更新しないといけないかわかりやすい。比較的難易度が低いキャッシュと言える。

では、どのようにキャッシュを使おうか考えよう。

まずキャッシュがあってもなくても同じ動きになるようにしよう。get()メソッドの中で

String get(String id) {
  if (cache.hasCache(id)) {
    return cache.get(id);
  } else {
    return httpHandler.get(id);
  }
}

のように自動的にキャッシュを使うかどうか判断してくれるとありがたい。こうしておけばいざという時はキャッシュを全部消せば良いので心配が減る。ただ、このライブラリが自動でキャッシュを使うということがライブラリ利用者側伝わりづらくトラブルの元になりかねない。意味もなくuseCacheをtrueにさせるという一手間をかけさせると「あ、キャッシュするんだな」と伝わって良い。たとえfalseという選択肢がなかったとしても。

class Api {
  Api({bool useCache: true}) {
    if (!useCache) {
      throw "そんな選択肢はない！";
    }
  }
}

void main() {
  var api = new API(useCache: true);
}

次に、元データ管理層からキャッシュの更新か破棄を指示できるようにしておこう。キャッシュ層が自分の管理するサーバー内にあるならそれようのプロトコルを作っておこう。WebシステムならURLの末尾にタイムスタンプをつけておくとCDNと併用できて手軽だ。

var modificateAt = <?php print $modificateAt; ?>;
$.ajax("/resources.json?" + modificateAt);

最後に、キャッシュを手動で破棄する方法を用意しよう。管理画面にデカデカとキャッシュクリアボタンを用意しておくと良い。いついかなる理由でキャッシュをクリアしなければいけないか未知なので必ず設けよう。だいたいキャッシュをクリアしたい時は超絶焦っている時だ。「SSH接続してこのファイルを削除ー」とかはやめよう。

2017-10-24

キャッシュを設計する時に考えること

キャッシュは難しい。そこで安全な設計ができるように考えるべきことをまとめた。

まず、キャッシュにはどのようなものがあるか。

前回のHTTPリクエストの結果をローカルに保存しておき、次回はそこから結果を返す
HDDに書き込んだデータをメモリにも保存しておき次回はそこから読み込む
RDBで時間がかかるクエリを高頻度で実行する時、あらかじめ別テーブルに集計結果を入れておく
数学のアルゴリズムを書く際に、CPU負荷の高い平方根を先に済ませて結果を連想配列に入れておく

このようなものが挙げられるだろう。

本題に入る前にいろいろなタイプのキャッシュを分類をしたい。キャッシュは二種類に分けられる。一つは元データとキャッシュデータが一対一で対応するものだ。キャッシュデータが元データのどの部分をキャッシュしているか明確に答えらえるものとも言える。例えば1万ファイルの中で数ファイルをメモリにも持っているようなキャッシュだ。これは、キャッシュしたファイルがHDD上のどのファイルかはっきりしている。もう一つは、元データの集計結果に対するキャッシュだ。例えば、１年間の売り上げが全てDBに入っているとしよう。その総売上金額をメモリにキャッシュしているとする。そのキャッシュデータは売り上げデータ全体に対するキャッシュだ。逆に言えば元データのどこか個別の場所のキャッシュではない。この違いによってキャッシュ設計で考えるべきことが変わってくるのできちんと区別しよう。

次にキャッシュの難しさについて考えたい。なぜキャッシュは難しいのか。そもそも真実は一箇所に管理していた方が都合がいい。同じデータを複数の場所に保存しているとデータに更新をかけたい時どこを書き換えればいいかわからないくなる。また、元データでなくキャッシュの計算式が変わる場合もある。税込みの売上データをキャッシュしていたらある日消費税率が変わったりする。その時キャッシュデータをどう更新しなければいけないのかが難しい。このように、キャッシュはデータやシステムに変更があったら正確にキャッシュを更新しなければ不整合が起こることが難しい。

では、どのような心構えで挑めばいいだろうか。まず、不整合とは何かはっきりさせたい。一つは元データが更新されたのにキャッシュデータが更新されていない状態だ。次に、キャッシュの計算式を変えた時は、キャッシュを更新するまで全てのキャッシュが不整合な状態になる。さらに、今キャッシュされているデータが整合しているか自信がない時も不整合と同じである。例えばDBの一箇所を手動でUpdateしたが、このUpdateはキャッシュとの間に不整合を起こすかわからなかったとしよう。心配になってる時点で不整合が起きていると一緒だ。

そこで、何が正になるデータかはっきりさせよう。HDDのデータをメモリにも持つならHDDが正だ。RDBで正規化したテーブルとパフォーマンスのために結合結果を保存してあるテーブルがあれば正規化したテーブルの方が正だ。正のデータはキャッシュのデータに依存してはいけない。存在を知っていてもいけない。キャッシュ管理層は正のデータを取りに行っていいが、反対に正のデータ管理層はキャッシュデータに触らなければ整合性を維持できない状態になってはいけない。また、キャッシュデータは知っているけど正のデータは知らない情報があってもいけない（ただし、キャッシュの作成時刻のようなメタデータはOK）。このようにレイヤーを意識して依存関係が複雑にならないようにするといい。

次に、どんな時にキャッシュのどの部分を更新するかきちんと洗い出そう。決定事項はReadme.mdなどにきちんと書き出して管理しておくことをお勧めする。この部分は特に「ソースコードが正解」という事態は避けた方がいい。

そして、不整合はいつか起きるものだと思っておこう。起こらないようにするより大事なことだ。

では、ここからいいキャッシュのためどんな作戦を立てればいいかを考えよう。

まず、元データとキャッシュが１対１で対応するようなキャッシュではここに気をつけたい

キャッシュはあってもなくても同じ動きになるようにしたい
あった方が速いがなくてもいいという状態が最善
元データ管理層がキャッシュのクリアを指示できるように
キャッシュがおかしくなったらとりあえずキャッシュをクリアすればいいようにしておきたい
キャッシュを簡単に削除できるように

逆に、全体に対するキャッシュの場合は

キャッシュを簡単い作り直せるように

を気をつけよう。

具体例は次回以降に話したい。

2017-10-23

バッチ処理には必ずドライラン機能をつけよう

バッチ処理の負債化は早い。理由はよくわからない。想像するに、普段ほとんど意識しないからどんな機能があるか忘れる、外部のシステムとつながっているので手動テストすらし辛い、処理が長い、などの理由がありそうだ。

バッチ処理は簡単に動作を再現できることが重要だ。もちろん、開発環境は用意してあるだろう。そこで本番に近しい結果を得ることはできるかもしれない。しかし、今動いている本番サーバーがどんな動きをするか簡単に確認出来てほしい。

例えば、一日に一回１週間ログインしていない人にメールを送るとする。そうであれば、今バッチ処理が実行されたら誰にどんなメールが送られるか確認できるようにしてほしい。出力形式はWebの画面でもCSVでもなんでもいい。このようにテスタブルにすることで微修正を重ねやすくなりソースの腐敗が防がれる。

これが実現可能であるということこそ、これまでこのブログで支持してきた副作用を抑えるプログラミングスタイルのメリットの一つである。

blog.isyumi.net

例えば先述のメールのバッチ処理の場合

DBにQueryを発行する
１件ずつFetchし、メール送信対象者ならメールを送る

というバッチ処理ではドライラン機能をつけるのが難しい。しかし

DBにQueryを発行する
１件ずつFetchし、メール送信対象者なら「メールを送る人配列」に追加していく
まとめてメールを送る

というように書いておけば最後の3番をIF文で切り替えて「メールを送る人配列」をCSVに出力するだけで簡単にドライランが実装できる。

追記

本当に配列に入れちゃうとパフォーマンスとかヤバそうな場合あるので、その言語のイベントストリーム機能を調べよう。例えばGoならchannelの受信先を挿げ替えるだけで同じことが実現できる。

2017-10-22

複数の言語で開発する時は定数を一元管理できるようにしよう

一つのシステムを複数の言語で開発することがある。例えばサーバーをJavaで開発しクライアントをTypeScriptで開発する、などだ。こんな時、定数の一覧をYAMLなどでファイル化しよう。そして、YAMLから各言語の定数ファイルを自動生成するものも作ろう。すると、サーバーとクライアントのやりとりでtypoによるエラーがなくなって便利だ。例えばプロフィール入力画面があったとする。そこで入力する性別がman/womanとmale/femaleのどちらにしようか、また大文字か小文字か間違えないようにしたい。こんなYAMLを作ろう。

MALE: MALE
FEMALE: FEMALE

そこから生成したGoとTypeScriptはこんな感じだ。

const (
  MALE = "MALE"
  FEMALE = "FEMALE"
)

const  MALE = "MALE",
FEMALE = "FEMALE";

TSXからこんな感じに使える

return <select>
    <option value={MALE}>{MALE}</option>
    <option value={FEMALE}>{FEMALE}</option>
</select>

サーバーサイドはこんな風に描ける

func PutGender(userid , gender string) {
  if gender != MALE && gender != FEMALE  {
    panic(gender)
  }
  
  db.put(userid , gender)
  
}

このようにサーバークライアント通じて安全にプログラミングができて便利だ。

Swaggerなど関連する便利なツールもあるので利用していきたい。

2017-10-21

VからCにメッセージを送る時は最小限のデータにしよう

いろんなMVCがあると思う。特定の実装に依存する話じゃない。

RoR的なサーバー・クライアントモデル
ReactやAngularを使ってクライアントサイドMVCを構築する
CLI

など、色々ある。大雑把に話の前提を揃えよう。Mは様々なデータを管理している。VはMを加工して画面に表示する。Vでクライアントからの入力を受け付けてCがそれを処理する。VはMからデータを取り出すことができる。今日の問題提起だが、なぜかVからCに送るデータが肥大化しがちと言うことである。例えば、

画面がありそこに価格が書いてある
それを押すとサーバーで課金システムが動く

というシステムだとしよう。ここでクリックされた時にサーバーに送られるデータは商品IDだけであるべきだ。価格は省いて送信するべきだ。Cは自分でMから商品の料金を参照するべきだ。

なぜか。一つにセキュリティの問題だ。そして変更に弱くなる。しかし、もう一つ大きな理由としてメンタルモデルをあげたい。「システムの様々な場所に点在するデータは、最終的にMを正にする」と思い込んでいる。その中で、CがVから必要ないデータを受け取っていたら、「これ何かに使うのかな？」と言う気がしてくる。

2017-10-20

急遽個別対応するときはコンパイルエラーを出しながら元に戻せるようにしよう

あなたはショッピングサイトを運営していたとする。ある日急に担当者から「来週からセールを始めるので13:00になったらこの告知バナーを表示してほしい」と依頼された。しかし、既存のシステムにはセール時にバナーを差し込むようなレイヤーは用意していない。そこで、少々お行儀は悪いがテンプレートに直接<img>タグを差し込むことにした。

void topPage(HttpResponse res) {
  // ここからセール対応　セールが終わったら消し忘れないで><
  var isSale = new DateTime.now().isAfter(new DateTime(2017, 10, 21, 13));
  var saleTag = isSale ? "<img src='sale.png'/>" : "";
  // ここまでセール対応

  res.write("""
  <div>
  <h1>●●ショップへようこそ</h1>
  ${saleTag}
  </div>
  """);
}

その後担当者から追加の依頼があった。「商品一覧画面にも出して＞＜！」

void productListPage(HttpResponse res) {
  // ここからセール対応　セールが終わったら消し忘れないで><
  var isSale = new DateTime.now().isAfter(new DateTime(2017, 10, 21, 13));
  var saleTag = isSale ? "<img src='sale.png'/>" : "";
  // ここまでセール対応

  res.write("""
  <div>
  ${saleTag}
 <h1>防寒具一覧</h1>
  </div>
  """);
}

さらにその後担当者から依頼があった。「マイページにも出して(:3_ヽ)_」

void myPage(HttpResponse res) {
  // ここからセール対応　セールが終わったら消し忘れないで><
  var isSale = new DateTime.now().isAfter(new DateTime(2017, 10, 21, 13));
  var saleTag = isSale ? "<img src='sale.png'/>" : "";
  // ここまでセール対応

  res.write("""
  <div>
  ${saleTag}
  <h1>購買履歴</h1>
  </div>
  """);
}

さてあなたはここで不安になる。自分はセールが終わったときに正しくすべての個別対応を除去できるだろうか。消し忘れたら恥ずかしい。あなたにはいくつかの選択肢がある。

忘れないうちにスプレッドシートに一覧を作っておく
あとでgitのlogを見る
grepする

これらも間違ってはいないと思うが、もう少し便利な方法を紹介したい。元に戻すときにすべての該当箇所にコンパイルエラーが出せるようにしておこう。方法はたくさんあるが一番手軽な方法として、セールが始まっているかどうか判定する関数を一個作っておこう。そして個別対応した場所はすべてその関数を参照するようにしよう。

bool isSale() {
  return new DateTime.now().isAfter(new DateTime(2017, 10, 21, 13));
}

void myPage(HttpResponse res) {
  // ここからセール対応　セールが終わったら消し忘れないで><
  var saleTag = isSale() ? "<img src='sale.png'/>" : "";
  // ここまでセール対応

  res.write("""
  <div>
  ${saleTag}
  <h1>購買履歴</h1>
  </div>
  """);
}

今回はisSaleという関数を定義し、myPageやその他バナーを張ったページから呼び出している。

すると、セールが終わった後にisSale関数を削除するとこのようにコンパイルエラーが出る。

f:id:isyumi-net:20171020202125p:plain — 赤い波線が出てわかりやすい

f:id:isyumi-net:20171020202317p:plain — IDEでコンパイルエラー一覧を見れる

isyumi_netブログ

isyumi_netがプログラミングのこととかを書くブログ

全体を集計した結果のキャッシュ

補足