WCSのキャッシュは夜ひらく

 みなさん、こんにちは。毎日寒い日が続きますね。大雪の被害にあわれた方々には、心よりお見舞い申し上げます。
東京も記録的な大雪でした。幸い週末にかかったため、大きな混乱はなかったようですが、未だ山間部では道路や線路が不通のところがあるようです。
※東京に山間部なんてあるのかよ!って方は一度、Googleマップなどで東京の奥多摩あたりをご覧になってください。ちなみに、最高峰は奥多摩の雲取山(標高2017m)です。(筆者も初めて知りました!)

 今回は、キャッシュのお話です。動的配信を行っている場合、キャッシュはクライアントからのアクセスに素早く反応したり、サーバの負荷を軽減するために非常に有効な手段ではありますが、その使い方を間違えると大変なことになります。
以下にキャッシュを使う上での問題点を挙げてみます。

1. ページのファーストアクセスが遅い問題
パブリッシュ時にキャッシュを再生成しない場合は、キャッシュの有効期限が切れたあと、最初のアクセスが発生した段階でキャッシュを生成することになります。つまり、アクセスする誰かがババを引くことになるのです。
もちろん、パフォーマンスとしての要件を満たすようページ出力に要する時間は、厳しくチェックされチューニングされていますが、それでもキャッシュが有効な場合に比べれば、時間がかかることには違いはありません。
一般的なWCSの動的配信の案件では、概ね3秒以内のレスポンスを目指してチューニングが行われていますが、それでもページの作り上、より時間がかかったり、コンマ数秒で表示されるキャッシュ有効時の表示よりは、はるかにレスポンスが遅い結果になります。

2. パブリッシュ終わらない問題
WCSではパブリッシュ時にキャッシュを自動再生成する機能があります。
これを使えば、パブリッシュした資材に関して関連するページのキャッシュを再生成することができます。
これを使えば、たまたまファーストアクセスに当ってしまう人もなく、すべての問題が解決できるのではないか?と一瞬思ってしまいますが、そこに落とし穴があります。

 キャッシュを再生成するには時間がかかるということです。自動で再生成するとはいえ、キャッシュを生成するにはそれなりの時間がかかります。
例えば、製品が数千あるサイトにて、製品を1つ追加したとします。その製品にたどり着くための中間的なカテゴリページに製品数の表示などがあったとしたら、製品を1つだけ追加したとしても、その中間経路のページの製品数の表示をすべて直さなければなりません。その経路自体が数百もあったとしたらどうでしょうか?
製品を1つだけパブリッシュしたのに、キャッシュの自動再生成に時間がかかりパブリッシュがいつまで経っても終わりません。そんな結果になってしまいます。

運用に合わせたキャッシュルールを考える!
 以上の問題を解決するためには、運用に合わせたキャッシュルールを策定する必要があります。
いくらパブリッシュが早くても、キャッシュ率の低いサイトはアクセスが遅くなりますし、いくらキャッシュ率が高くても、運用時間中のパブリッシュに時間がかかりすぎては運用に支障を来します。
例えば、サイトの構成、運用方法や要望、アクセスするクライアントの性質が以下の通りだったとします。

  • 製品情報の詳細は多数の経路を辿り表示され、それぞれの経路に配下の製品数やスペックの一部が表示される。
  • 運用時間は、概ね通常の勤務時間(9:00~18:00)。
  • サイトへのアクセスもB to Bのため、9:00~18:00の間のアクセスが殆どを占める。(夜間のアクセスが少ない)
  • 運用時間中は、製品情報の更新も頻繁に行う上、重要なお知らせが突発で入る場合もあるのでパブリッシュ時間はなるべく短くしたい。
  • キャッシュ率は極力100%に近づけたい。
  • 製品情報は特別な場合を除いて、次の日にすべての導線が繋がり、導線に表示される製品数なども表示されればよい。

以上の条件を踏まえ、以下のようなスケジュールを構築します。

運用スケジュール
製品ページツリー
 製品詳細に至る複数の経路のページ(製品中間A~E)のキャッシュを、アクセスの少ない夜間に再生成することによって、クライアントのアクセスの負担を軽減し、通常運用時のパブリッシュ時間を短縮し、キャッシュ率を極力高くすることを実現します。
 キャッシュはサイトへのアクセスを高速化する素晴らしい手段ですが、キャッシュは作らないと存在しない、作るためにはそれなりの時間がかかるということを忘れずに、サイト運用に則したキャッシュルールやスケジュールを策定することがWCSでの開発では非常に重要になります。

 今回のタイトルは…わかる方だけわかっていただければ幸いです。