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での開発では非常に重要になります。

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


WebCenter Sites案件に携わって

 これまでに複数のWebCenter Sites案件に携わり、感じたことをお話したいと思います。

 WebCenter Sites(以下 WCS)は、Webサイトのコンテント管理だけを行う単純なCMS(Content Management System)のみならず、エンドユーザーのWeb体験全体を管理できるWeb Experience Management(WEM)としての機能を有する高機能な製品です。
今回は、弊社のこれまでの導入実績として多かった、Webサイトを構築する開発案件についてお話します。(WEMのお話は、また別の機会に。)

 その導入の目的はサイトを閲覧するユーザに対して快適で見やすい環境を提供することと、その運用を行うクライアント様に対して、快適に運用できる環境を提供することです。
どちらか一方でも十分に実現できないということは絶対に避けなければなりません。

 WCSは、さまざまなニーズに応える高いポテンシャルがありますが、それを使いこなすための多くの準備が必要になります。
その作業はクライアント様と、我々開発ベンダーとの緻密な共同作業になります。

 まずは、従来行っていた製品や商品の管理方法、サイトへの出力方法を理解した上で、WCSを導入することで、何が変わるか?何が便利になるか?を十分整理し、説明します。
WCSの案件が他のサイト構築案件に比べ、要件定義に多くの時間を費やすのは、このように従来の業務を整理し、新しい業務体系を提案するところから始まるからです。
時にはクライアント様の職場にお邪魔して実際に1日でどのような業務が発生しているのか、その流れがどのようになっているのか見学させていただくこともありました。

 開発手法としては、従来型のウォーターフォールモデルを基本にしますが、特に製品や商品の登録、管理、出力部分に関しては、プロトタイプを先行して作成し、クライアント様に成果物を確認していただきながら部分的に反復して進めるアジャイル開発風の手法を使うことが効果的だということがわかってきました。
早めに入力のUIや、出力パフォーマンスなどを確認していただき、問題点があれば解決します。
それに合わせて、要件達成のゴールイメージ、スコープを明確にしておくことも重要になります。

development_process

 製品や商品を扱うページの表示ロジックは複雑になりがちです。
多くのデータがリレーションを行い表示されるため、表示速度など出力パフォーマンスは重要な課題となります。
WCSには高性能なキャッシュの仕組みがありますが、基本的な表示ロジックが高速でないと、キャッシュの生成に膨大な時間がかかる結果になり、ユーザビリティの低下に繋がります。
複雑なロジックを伴う部分に関しては、とりあえず作ってみた的な開発の進め方は多くの手戻りが発生するため、 運用方法と、その運用頻度と、閲覧する側のユーザビリティのバランスを考え、適切なパフォーマンスが得られるように設計段階から十分に考慮する必要があります。
パフォーマンス向上のための施策は、このようにそのサイトやコンテンツの運用方法、閲覧側の要求に則したものを実現しなくてはいけません。

 通常の案件に比べ、大規模な構築になるので時間もかかり苦労も多いですが、構築したサイトが様々なところで事例紹介されていたり、クライアント様から「掲載している製品や商品に関する問合せが増えた」「運用が楽になった」「良いサイトが出来上がった」とお言葉をいただいたりすることが、我々開発ベンダーの次への原動力になっています。

 余談ですが、WCSは旧製品名をFatWire Content Serverといいます。
WCS案件に携わる度に何故かFatになっていく自分をなんとかすることが目下の最重要課題です。