del.icio.usに学ぶサイト運営術

del.icio.usの中の人がアプリケーションの開発や運用に関することを述べている資料を和訳されているページがあって、非常に勉強になるなぁと前から関心していたんだけど、当社にとってはすごく重要な部分もあれば、そのまま当てはまらない部分もあるので、一部紹介しながら自分なりに再検討してみました。(要閲覧 > 社内)

参考:"Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点":http://d.hatena.ne.jp/koyachi/20060211/1139644433

早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。

Nagios じゃSQLプロファイリングは無理だろ。とツッコミいれたくなりましたが、"原文":http://simon.incutio.com/notes/2006/summit/schachter.txt には"Nagios or similar for monitoring."とありました。TagClickでは稼働監視にNagiosをパフォーマンス分析に"Cacti":http://cacti.net/ を使っています。余談ですが、Cactiではカスタムレポートを簡単につくれるので、ユーザーやコンテンツの推移もラクに追えて便利。Cactiお勧め。

SQLに関しては主にMySQLでスロークエリログを取ってから、EXPLAINで原因を探るという「問題発生してから後で対応アプローチ」です。スコープ最優先ということで。

タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。

タグとSQLに関しては日本語特有の問題もある。"Tagclick Blog":http://blog.tagclick.net/2006/10/mysql.html にタグとSQLに関連する話題を書いてあります。

Apacheを学ぼう。チューニングによってかなりの高速化が可能。特にヘッダ、mod_rewrite.フロントエンドにはPerlbalのようなProxyを設置する。

TagClickではApacheの"mod_proxy_balancer":http://httpd.apache.org/docs/2.2/ja/mod/mod_proxy_balancer.html をフロントに置いて、バックエンドは lighttpd + FastCGI で組んでいるんですが、いまいち思ったようなパフォーマンスが出ません(体感的に)。アプリケーション側にはログを見る限り原因なさそうなので、このあたりをもうちょっと調べて追いたいところです(主にヘッダまわり)。

ユニークID(php?id=1等)を晒さない。scrapingが助長されてしまう。del.icio.usでlinkにMD5ハッシュを採用しているのはこれが理由である。

これはまさにおっしゃる通り。TagClickでもリニューアルの際に、管理画面を除いてIDはオモテに晒さないように修正しました。

"Spamは注目泥棒"。del.icio.usでTop 10を採用しないのはこれが原因。これは魅力的だが同時に厄介者である。

spam行為者を発見しても彼等に知らせずにPOSTは許可し、システム側でそれを黙って廃棄する。

ソーシャルなアプリケーションにスパムはつきもの。特にランキングには彼等を引きつける魅力があるみたい。アカウントを無効化するのが効果的だけど、知らせないのは無駄な揉め事抱えないため?

機能を持たないことも機能である。他のシステムで代用可能ならその機能は不要である。メールやメッセージング機能はdel.icio.usには不要である。

シンプルさを保つのは言うまでもなく重要ですが、ユーザーからのリクエストを聞きながらそれを維持するのは大変。「他のシステムで代用可能ならその機能は不要」というのは、ひとつの指針として有効。

集約されたデータ(最新、注目等)は注目を浴びるが、利用者の増加と共に偏見が生まれる。コミュニティのオリジナルメンバーにとってはdel.icio.us/popularはそれ程面白くない。注意が異なるエリアに向くように解決する。

いわゆる、はてブ衆愚論みたいなハナシでしょうか?そんなハナシは別にして、すでにそうなりつつあるけどデータが増えればリンク解析や協調フィルタリングなどによって解決する方向にすすんでいくはず。もうすぐ、この分野もテクノロジーで競争力に差がつく時代になるのでは?

Taggingはユーザインターフェースの大事な部分。利用者はタグを元に情報を思い出す。思いだしやすく、発見できるもの。見つけられないものは意味がない。自動Tagging機能はユーザがどこに保存したかわからなくなってしまう。del.icio.usの"add to del.icio.us"バッジでtagサジェストしないのはこれが理由。del.icio.usの特徴は"attention"。自動Taggingはこれを無効化する。

コメントやタグはユーザーの意志を反映させる重要な部分。TagClickでは一部自動タギングを導入しているけれど、これはブログを書く手間とタグを付ける2度手間の心理的負担を減らすためで、ブログの投稿時にタグ付けできるようになったら外すつもり。絶対やる。

タグのサジェスト機能については、del.icio.usにもついている覚えがあるし、全部手入力してもらうのは無理があるので必要。ただ、ユーザーを偏った方向に導きかねないので注意も必要。セレンディピティを失わずに省力化できたらスゴイ。

あと、タグが普及するためにはUIの進化が必須。タグクラウドの次になにが出るのかに注目しています。でたらすぐにパクられそうだけど。

設置可能ならどこでもRSSを設置する。del.icio.usではHTMLやAPIよりもアクセスが多い。

RSSではフロー情報しか得られないので、データを収集する側としてはストック用の別フォーマットが欲しい。OPMLで良いから早く普及して。APIは面倒。

“del.icio.us最悪”という評価はユーザを獲得できないことよりも恐ろしいもの。不要な機能は付けない。

完全にウチには当てはまらないのが最後のコレ。すでに充分なアテンションを得られているdel.icio.usならともかく、多くの中小サイトにとっては悪評でもアテンションが得られる場合はプラスの可能性がある。賛否両論なら大成功。無視されるのは最悪。ナイーブな人は向かないかも。

Bookmark and Share