タイル系Webマッピングのキャッシュについて (@Magepa)
零度のウェブマッピング - Relevant, Timely, and Accurateについて @Magepa さんからコメントをいただくなかで、運用の話をいただいた。
@_hfu_ 運用するならDBキャッシュを巨大にとる方向、ということでしょうか。
— まげわっぱーさん (@Magepa) 1月 8, 2012私は、DBキャッシュというよりは、HTTPレスポンスのサーバ側キャッシュを大きく取る方法を選ぶ。
地図データの多くの部分は、例えばユーザが違っても同じものを返す。レスポンスの多様性が少ないことが多い。このような場合には、HTTPレスポンスそのものをサーバ側でキャッシュしてしまえばよいと思っている。実際に http://zero-degree.heroku.com/ で運用しているときにも、実はデータベースを切り離しており、零度のウェブマッピング - Relevant, Timely, and Accurateのプログラムを、haml した結果のコピーをファイルシステムに保存するように変更したものに対して、wgetで「全定義域の」HTTPリクエストを浴びせかけ、ファイルシステムに採取されたレスポンスを heroku に上げている。ファイルシステムに採取されたレスポンスをそのまま返す設定も Sinatra で書ける。
整理しなおすと、零度のウェブマッピング - Relevant, Timely, and Accurateにあるプログラムを運用する方法として、次の3つがあると考えている。
- サーバ側キャッシュを置かずに常にデータベースからレスポンスを作る方法。（これは、クライアント要求に対して常にデータベース負荷が発生する構成であり、GISのワークロードをサーバに集中させるだけであって、利点はない。少なくとも、Webの利点を全く生かしていない。要求ごとに返す地図データが異なるといった特殊な場合を除いて、この構成は適切ではない。）
- サーバ側キャッシュを生成する機構、利用する機構をともに置く方法。（これは、「手放し」で動いてくれるという意味で利点がある。データベースのデータを更新した場合に、そのデータが影響を及ぼすキャッシュを消去するようにしておけば、次にそのタイルにリクエストが来たときにキャッシュが生成される。実際には、データを編集してキャッシュを消去した直後にリクエストを浴びせてキャッシュを更新するのがよい場合が多いだろう。）
- Webサーバにはキャッシュを利用する機構のみを残し、キャッシュはオフラインで全数生成しておく方法。（キャッシュという言葉の定義に合わないのかもしれないが、この方法が最速でありまた最も安全な方法であって、一定量以上のリクエストが見込めるタイル系Webマッピングサービスでは、少なくとも当初はこの方法で始めるのが安全ではないかと思われる。）
