2007年04月05日
ブログサーチ顛末記2 サーバー構成 
昨日に引き続き、作成したブログ検索サイトについて。本日は、サーバー構成についてまとめておきます。
サーバーの構成は以下のとおり。
・Webサーバー兼リバースプロキシーサーバー×1
・アプリケーションサーバー×1
・DBサーバー×2（マスター×1、スレーブ×1）
・クローラー×1
という5台構成になっています。
現状、アクセスの負荷がないため、サービスインができる本当の最小構成です。
もう少し詳しく見ていきます。
ハードウェア
CPU：Pentium D 820（2.80GHz）
メモリ：Webサーバー、アプリケーションサーバーには1GB、
DBのマスターに2GB、スレーブに3GB、クローラーに2GB
ディスク：SATA 80GBのソフトウェアRAID
ソフトウェア
Webサーバー兼リバースプロキシーサーバー：Apache 2.2＋mod_proxy_balancer
アプリケーションサーバー：Apache 2.0、PHP5.1
DBマスター：MySQL 4.0.27
DBスレーブ：MySQL 4.0.27＋senna
クローラー：MySQL 4.1.20＋Plaggerベースのクローラー
※それぞれのバージョンの理由なんかは、また改めて述べます。
トラフィックが増えてきた場合に、アプリケーションサーバーとDBスレーブを増やしていけば対応できるような構成にしています。ここらへんは、はてなのシステム構成などを参考にしています。
まるごとPerl!の事例編や、Software Design 1月号の特集なんかが大変参考になります。
とまぁ、こんな感じのサーバー構成になっています。
次回はブログ検索サイトがどう動いているのかについてまとめてみます。
ブログのエントリーをどのようにして収集し、データベースに格納し、検索出来るようにしているのか、ということについてです。楽しみにしている人がいるかどうか分かりませんが、お楽しみに。
ついでのお話。
ブログ検索サイトとしてNAMAANを目標としたのはいいのですが、実際にNAMAANがどれくらいのデーターを収集しているのかが当初見当もつかず、またそういった情報を見つけ出すことも出来ませんでした。そのため、新たに作るとして、どれくらいのデーター量になるのか、サーバーを何台用意すればよいかが判断できずにおりました。
そこで、サーバーを用意する前に、まずは古いPCに開発環境を作成し、クローラーと簡単な検索インターフェイスを作成のうえ、ためしにブログのエントリーの収集を開始してみました。
そして、ある程度エントリーがたまったところで、いくつかのキーワードで返ってくる検索結果を元に、推測で必要なスペックを算出した次第です。
例えば10万件のエントリーを収集した時点で、“日本”というキーワードでヒットするエントリーが50件だとします。一方NAMAANでは、“日本”というキーワードでヒットするエントリーが5,000件あったとすると、その差は100倍。ならばNAMAANは1,000万件のエントリーを保存しているに違いない。などといった具合です（上記の数は適当な数値です）。
ひとつのキーワード自体では正確さに欠けますが、いくつものキーワードで探っていくと大体正解に近い数が導き出せるはずです。
上記で算出した値は、公開して良いものか分からないので伏せますが、今回作成したブログ検索サイトでは、毎日30万件程度の新着のブログエントリーを収集し、それを過去2週間分まで検索できるように、という仕様で作成しました。
投稿者 田中＠グリニッジ : 00:24 | コメント (0) | トラックバック
2007年04月04日
ブログサーチ顛末記 そもそものきっかけ 
昨年末より、ブログ検索のサイトを作ろうとしておりまして、技術的なことであれこれ格闘しておりました。行き詰っては調べて試行錯誤して、また調べて試行錯誤してを繰り返していたのですが、当初の想定していた性能を出せるくらいに作り上げることが出来ました。
あとはデザインを入れれば公開できるのですが、もともと技術面でのノウハウの習得がメインの目的だったこともあって、サービスを公開するという事自体はどうでも良くなっちゃった気もしていて、そんなことを考えているなか、知り合いから
「ブログ検索なんてたくさんあるじゃないですか」
なんて突っ込まれると、確かにいまさらブログ検索もなぁと思って、ちょっとモチベーションが低下中。
まぁ、いろいろなノウハウを習得できたこと、そして、それらを本業のほうにも生かせるであろう事から、良かったのではないかなと思うことにして。ちょうど本業のほうでの開発も調子が出てきたので、しばらくはそちらに注力することにして、このまま寝かせておいてまた考えます。
せっかくなので、ここ数ヶ月で学んだ事なんかを何回かに分けて書き残しておこうと思います。
そもそもは、blog検索エンジン「NAMAAN」の中身というブログエントリーをたまたま目にしたのがきっかけでした。
NAMAANでは、クローラーやインデックスサーバーなど、計12台のサーバーで構成されているとのこと。
もうちょっと少ないサーバー数で同等の性能を出そう、というのが目標です。
（論文が書かれた時点での話なので、現在のサーバー台数は知りません）
そんなわけで、とりあえず古いPCにCentOSをインストールし、基礎開発を行ってみたのが昨年末。その後、NAMAANの論文に書かれているサーバーと同等スペックのDELL SC430という格安サーバーを5台購入して本格的な試行錯誤がスタートしたわけでした。
サーバーが届いたのがちょうど今年の年明けぐらいだったと記憶しています。
ウノウラボにもこのDELLのサーバーを使っている写真が載っていたので、真似して、スチールラックにのっけてみたりなんかしちゃってます。
ちなみに現在、このDELLのサーバーは事務所に鎮座しております。非常に静かなサーバーで、騒音に悩まされることはありませんが、CPUがPentium Dプロセッサなので、結構発熱があり、また、UPSからもそこそこ発熱するので、結構ヒンシュクをかっています。
オフィスに置くには、Core2Duoサーバーがいいですね。
NAMAANとの性能比較は、同じキーワードを入れて検索をして、何件ヒットするか、最新エントリーの日時はどちらが新しいか、などを見比べて、この倍の性能を出さなきゃ、とかやっていたわけです。
NAMAANも「あなたのブログを最短1分で結果に反映」というのが売りのブログサーチですから、少ないサーバー数で対抗しようとするのは、なかなか手ごわかったです。
投稿者 田中＠グリニッジ : 00:54 | コメント (0) | トラックバック
2007年04月03日
フォーム認証のデザインパターン 
自社のASPサービスの認証部分を見直すついでに、あらためてフォームでのログイン認証をいろいろ調べておりました。
定期購読している WEB+DB PRESS Vol.34 のWebアプリ認証に関する特集が一番良くまとまっていたかな。
上記の特集や、あとは、いろいろなサイトにおける実装を見て回りましたが、現在以下の形での実装が一般的なデザインパターンとして採用されているようです。
・当然ながらHTTPS通信は必須
・パスワードは平文では保存しない
・パスワードを忘れた場合は、パスワードを直接メールで送信するのではなく、メールでパスワード再設定用のURLを送信
・送られてきたURLをクリックし、開いた画面にてパスワードを再設定
母親の旧姓など、あらかじめ設定しておいた質問に答えることで、パスワードを再設定出来るようにするといったパターンを採用しているサイトも見受けられました。これは、以前登録したメールアドレスを現在は使っていないなどの場合でも再設定できる反面、本人以外でも再設定できる可能性が残る点があまりよくない。
パスワード再設定用のURLを送信後、パスワードを再設定するまでの時間的なリミット(60分以内や一週間以内など)や、回数のリミット（同じURL経由では1回しか再設定できないなど）を設けている場合が多い。また、セッションを使って、違うブラウザからの再設定を禁じている例も多く見受けられた。
あとは、セッションID関連のセキュリティ（固定化や漏洩など）には注意すべし。
上記の調査を元に認証部分を作り直してみました。
＃osCommerceはここら辺の実装が微妙なとこありますね。
次は、シングルサインオンをどう実装しようかと思案しています。
Ohgakiさんのブログでシングルサインオンの模範解答がはやく公開されないかなーと待っていたりします。