【楽をしてサイト構築をするためのウンチクノート】
第７回（最終回）
データベース参照構造
次に動的にコンテンツを配信するCMSを考えてみよう。
常にデータを参照する
静的にコンテンツを配信する方法では、どのファイルを更新すべきかという問題が常に付きまとう。その一方で動的にコンテンツを配信する場合、常にデータを参照しながらコンテンツを配信するので、ファイルを更新という概念がない。むしろ更新するのはデータのみで、テンプレートにはどんなデータを取り出し、どのように配置するのかしかない。ユーザの処理はデータを追加するだけであり、機械が行う処理もデータの更新だけである。作業時間は確実に性的にコンテンツを配信するときよりも短い。ところが、この動的にコンテンツを配信する方法は常にデータを取り出しにいく傾向がつよい。それでは負荷がかかってしまう。
これを打開するため、キャッシュという考え方がある。コンピュータのCPUにも搭載されているものであり、使ったファイルは次も使われる可能性が高いので、それデータをためておく。すると、このためたデータがもういちど使われれば、処理は時間はそのためておいた結果を返せばよいので処理時間は短縮できる。DNSも同様である。
DNSは大きな分散データベースであり、マスタという本当のデータを持つものと、キャッシュというデータをコピーしたものを保有するものがあります。本来であればマスタのデータを使ったほうが正しいデータが得られますが、それをするとマスタには強い負荷がかかります。そこで、キャッシュを使うことで、確からしいと設定されている時間中はその情報を保存します。そのため、www.nifty.comに過去に行ったことがあれば、nifty.comのマスタのDNSサーバに聞きにいかなくても、キャッシュが保存している情報を返しますので、返答が大変高速になります。
必要なファイルの更新から適時更新へ
図1 IEのオプション
図2 キャッシュ選択
これにより、静的にコンテンツを生むCMSのように必要なファイルはすべて更新するという考え方から、必要に応じて静的なファイルを作成するという方法が考えられるようになります。つまり、都度更新という方法です。
例をあげます。トップページに更新情報を載せていたとします。ある日、ユーザがトップページにアクセスすると、あらかじめ以前誰かが訪問したことによって作成されたキャッシュが表示されます。次の日、サイトを更新したのでサイト更新情報がかかれたデータファイルにデータを追加します。キャッシュファイルはそのままです。しかし、その後、ユーザがアクセスすると、データの更新日とキャッシュの更新日が合わないため、更新する必要があるという判断にいたり、ユーザには動的に生成したコンテンツを見せつつ、キャッシュを作成するという手段をとります。キャッシュができてしまえば、後はそれを要求があるたびに見せればよいということになります。
このキャッシュという考え方は非常に重要です。プロキシサーバもこの機能があります。データベースサーバーの多くが搭載している機能です。もっち身近な例であなたが今使っているブラウザもそれを備えています。あなたがWindowsユーザであれば、Internet Explorer を使っていると思います。ツール(T)をおし、インターネットオプション(O)を選択すると、図1の画面がでるでしょう。ここのインターネット一時ファイルというのがキャッシュです。ここの設定(S)を押してください。すると、そこには4つの選択ができるようになっています。これがいつ本当のファイルを取りにいくかということです。上へ行くほど本当のファイルをとりにいきすくなり、下へ行くほどとりにいきにくくなります。
問題は、いつキャッシュ切れと判断するかです。よく、会社でウェブブラウジングをして見つけたページが、家に帰ったらURLは正しいのに表示されなかったという経験がないでしょうか。それは、キュッシュが悪さをしています。ブラウザの設定でいえば、常にとりにいっていては時間がかかって仕方がありません。それではキュッシャの意味がないです。ところが、まったく取りにいくことがないのも問題で、この場合は古いデータが参照されてしまい、新しい情報が取得できていない確率が濃くなります。データファイルから新しい正しい情報を取り出してほしいのに、データが取り出されないのでは本末転倒ですよね。
需要と供給
表1 シミュレート表
図3 動的と静的
図4 動的と静的の差
いずれにしても、動的にコンテンツをすみだすということは、スクリプトを走行させることには間違いありません。キャッシュの有効期限を確かめる必要がありますし、有効期限外なら一時的なキャッシュファイルを更新する必要があります。CGIスクリプト集の多くは動的にコンテンツを生み出しますが、なんでも動的にコンテンツを生み出そうというのは考えたほうがよいでしょう。
ここで、ひとつの指針として需要と供給を考えます。この2つは、需要が高く供給が低いと値段は高騰し、供給が多く需要が低いと値段が下がる、という義務教育の社会の話で使う話で出てくる用語ですので、いまさら説明する必要はないでしょうが、話をわかりやすくするため、需要はウェブサイトを閲覧してくる単位時間のユーザ数、供給はユーザへ提供される単位時間での処理できるユーザ数、値段は入手の難易度だと考えてください。もちろん、単位は人ではなくバイトでもかまいません。
一般的にサーバの供給は無限大と思われがちですが、そうではありません。サーバの供給はいつも決定しており、頭打ちとなる数値があります。ただし、静的なコンテンツと動的なコンテンツではその数値に違いがあります。その差は、サーバによって異なります。ただし、静的コンテンツのほうが動的コンテンツよりもこの値は高くなります。多くのサーバでは過度なCGIの使用や動的コンテンツの使用を避けるようにいっているのは、このためであると考えることが可能です。特に、レンタルサーバや無料ウェブスペースサービスはこの傾向があります。
よってここで、供給量が頭打ちされる値があるということは、さきほどの値段にあたる部分は需要に決定されるという仮定が成立します。ここで、「需要が高い場合、価格にあたる部分は同じように高くなるので結果は同じではないか」という意見があるでしょう。確かにそうですが、ここに頭打ちの話が出てきます。より話をわかりやすくするため、例として入手の難易度を 需要/供給量としましょう。1以下ならその情報は得やすくなり、1以上ならその情報は入手困難となります。さらに供給量は、静的コンテンツを100、動的コンテンツを85としておきます。
これをもとにして計算してみますと、表1のようになります。これを、動的と静的の数値でグラフ化したものが図3です。確かに、どちらも急激に増加していきますので一見どちらでもかまわないという結論も可能です。しかし、図4ではどうでしょう。差も右肩上がりになっていることがわかります。このことから、いくら動的と静的も需要が高くなれば情報が得づらい状態となるのですが、需要が高くなるにつれて静的と動的との差は大きくなることがわかります。
サイトの特性を理解せよ
ここで考えるべきことが、自分のサイトが果たしてどれほどのヒット数を稼ぐかと、もうひとつ、更新と変動がどれくらいのサイクルで発生するかということです。ヒット数が高いサイトでは、需要の数値があがります。その一方で更新と変動のサイクルが早い場合は、需要の数値が上がる前に情報が更新されて数値が事実上リセットになる場合があります。ひとつの例として、訪問があるたびに数値を変化させていくアクセスカウンタは、変動と更新のサイクルが短い例といえるでしょう。
動的にコンテンツを配信する場合、この更新と変動のサイクルが激しい場合か、実験的なものや一部で利用したいという人数が制限されている場合、そして重要な機構の部分（特にセキュリティがかかわる部分）がよいと思われます。ただし、利用する場合もページすべてを生成する必要はなく、パーツとして組み込んで使う方法もありますので視野に入れておくとよいでしょう。パーツとして組み込んで使う場合とページ全体を生成する場合では、その処理量も排出量も大きく違いが出るからです。パーツとしての排出はページ全体を生成するよりも量もすくないので供給量をあげることにもなりますし、それほど高い負荷をかけずにすみます。
逆をいえば、全体の更新サイクルが低い場合は静的なコンテンツに置き換えることも検討してください。筆者はどちらの方法によるコンテンツの生成ができるものを望みますが、なかなかそうもいかないと思いますが、動的から静的への置き換えはとりあえずページの保存やソースの丸写しでできますので、一度考えてみると良いでしょう。
すべてを動的にすべきではないという面では、あるコーナだけはCMSに頼り、一部は自分で作るという方法もありかもしれません。そういう意味では、逆に利用したいと思っているシステムが、自分のスタイルにあっているのかを検討することは大変重要なことであるといえるでしょう。
関連コラム
- シリーズ 【楽をしてサイト構築をするためのウンチクノート】
- 第１回 - サイトのファイルの依存性を理解する
- 第２回 - サイト運営・設計を楽にする機能
- 第３回 - CMSのコンテンツ生成と結合
- 第４回 - 埋め込みコンテンツとその活用
- 第５回 - ツリー構造
- 第６回 - メッシュ構造
- 嫌にならない更新のために
- サイト運営って、どうやってるの？