2ch type bbs（開発コードich）に搭載する負荷分散周りの仕組みを考えてみた。まあ実際に使うことはないだろうけど、思考実験としては面白いんで。

• クライアントからのDATファイル直読みはできない。またhtmlファイル直読みもできない。必ずcgi（phpを使うつもりだけど）を経由させ、アクセスコントロールできるようにする。
• HEADリクエストによって、Last-Modified情報をはじめ、現在のレス数などの比較的詳しい情報を取得できるようにしておく。
• HEADリクエストで得た情報を元に、DATファイル（もちろん実際のデータ形式は2chとは異なる）レベルでのデータ差分取得に対応させる（後述するキャッシュサーバー用CGIからのみ）。
• ある程度転送量が多い板については、cgiへの読み込み系GETリクエストが来た段階で、アクセスを負荷分散用キャッシュサーバーに転送する（書き込み、検索などは本サーバー側で直接受け取る）。
  • 負荷分散用キャッシュサーバーが指定された板のデータは、クライアントから本サーバーに直接読みに行くことはできない（本サーバーのcgiはリダイレクトするだけになる）。
  • 負荷分散用キャッシュサーバーのみ、直接本サーバーにアクセス（HEADリクエスト）し、必要な場合はDATファイルレベルでの差分情報を取りに行く。
  • 本サーバーから得た各スレッドの情報は、キャッシュサーバー上にDATファイルとして保存しておき、基本的にはその情報を元に整形した結果をクライアントに返す。
  • キャッシュサーバーから本サーバーへのアクセス頻度（最低アクセス間隔）を適宜設定することで、本サーバーの負荷・転送量を調整することができる。
• gzip圧縮に対応したブラウザに対しては、できるだけgzip圧縮されたデータを返す
  • 要求があるたびに毎回gzip圧縮を行っていたのでは、負荷コストがバカにならないので、読み込み・書き込みのタイミングではgzip圧縮しない。
  • cronで定期的にスレッドの状態を監視し、一定期間以上書き込みがなかったスレッドは、HTML化（HTMLキャッシュがなかった場合）＋それをgzip圧縮したデータの二つを用意する。
  • スレッドへの読み込みリクエストが来た場合、すでにHTML化されたデータがあった場合は、それをそのまま返す。gzip圧縮対応ブラウザからのリクエストだった場合は、gzip圧縮されたデータを返す。HTML化されたデータがなければ、その場でHTML化してキャッシュとして保存しつつ、クライアントに返す。
  • 新規書き込みがあった場合、HTMLキャッシュファイルとそれをgzip圧縮したデータは削除する。

って感じにすることで、ずいぶんと負荷低減＆分散ができるような気がする。どうせ負荷のほとんどは読み込み周りなんだろうから、読み込み用の専用キャッシュサーバーと連携できるような仕組みさえあれば、それでだいたい対処できるんじゃないかな。

ただ、まだ検索周りについては、自分の頭の中でうまく負荷分散と利便性のバランスを保った解決策が思いついていないんだよな。Namazuのインデックス作りは結構負荷がでかいんで、そのあたりをどうするのがいいか。

とか考えていると、どんどん構想だけがでかくなっていって、実際に作り始めることができなくなっちゃいそうだな。まあそれはそれで趣味的には楽しいんだけど。良くできた仕様を思いつけたらそれだけで十分と言えなくもない。実証テストの楽しさというのももちろんあるんだけど、このくらいでかいシステムになっちゃうと（労力対楽しさの）コストパフォーマンスが割に合わなくなっちゃうからな。