*政治的な内容を含みます。ご注意を

3.23.2012

fgの様子がとても気にかかっています。

自分も模型ユーザとして参加してたのはもちろんのこと、web同業でもあり、企画やマネタイズ、大規模サイト運用という観点からも注目していました。
pixivという成功事例があったとはいえ、模型フィギュアSNSというニッチ市場を見事とらえて、数年で10万ユーザを集めたというのは、本当にすごいことだと思います。

 模型に関しては、私は個人ブログ巡回というのは余りやらない方で、その分fgでいろんなジャンルの作品をみるのを楽しみにしていただけに、早く復活して欲しいところです。
スレがたってたので眺めてると、予想通りかなり厳しく言われてますね、仕方ないけど。少し意外だったのが、「スター」とか「ランキング」へこだわる人も、思った以上にいるんだなということです。(もちろん怒りの原因はそこじゃないんだけど。)模型作り手の立場で見ると、たかがランキングを不正操作したところで、誰が見てもすごい作品と、そうじゃないものは一目瞭然なんだから、そこまで目くじら立てんでも、、と思うんですが。また同業者として考えると、(不具合を放置できないのは当たり前なんですが、)ランキングっていうのは実際にユーザインセンティブとして有効なんだなと、改めて考えさせられます。


 まったくもって余計なお世話なんですが、ケーススタディとして思ったことをメモしてみよう。

残念だけどやってはいけないことを、いくつか犯している。

運営がすこし表に出てきすぎた。
 引き継いでがんばるぞっていう気持ちはわかるんだけど、あまりよいやり方とは言えない。皆んなと仲良くしようとするその行為自体が、あるユーザにはうっとうしく見える場合もある。規模が小さいうちは有効でも、一定を超えると難しい。とくに前管理者が控えめだったし、新運営はあとから突然入ってきたというカタチなので、なお難しい。


ハードルを上げすぎた。
 「ユーザの(機能)要望を聞く」っていうのは、やってはいけないわけではないんだけど、現実にはかなり難しい。たぶん皆んなが日常使ってるサイトで、そういう事やってるところって無いんじゃないかな。ご要望の送信フォームを置いとくのはいいとしても、それを集計して公表したりするのは、無駄な束縛を自分にかすだけ。それよりも、運営が自分たちで必要だと信じたことをやったほうがいいし、あとで評判悪ければなくせばいい。

 リニューアルっていうのはたいてい「以前のほうが良かった」って言われるもの。(その声のほうが大きく響く。)
そのギャップを小さくするには、「期待値を下げる」ことがじつは有効。「 見ててよ見ててよ~ 行くよ行くよ~、どうだ!」っていうのはあまり上手くない。ましてや今回みたいに、「やっぱりダメでした」という状況になったときには、救いようが無くなる。
普通は、「ベータ版仮オープンして見ました。こっちのリンクから覗けます。」くらいで、一定期間現行サイトと同時稼動して、様子見する方がいい。(※ただしデータベースレイアウトまで変わる場合は、データ差分が発生するからいろいろ手間はある。)


本番サイトを完全停止してしまった!?
 個人的に、これが一番の謎。これはまずかった。ハードウェア損傷とか通信回線側の障害とか、どうにもならない停止というのはたしかに時として発生するんだけど、そうじゃない以上ウェブサイトを数日間も止めてしまうということは、ちょっと聞いたことがない。
開発用に手持ちの物理サーバが他になかったとしても、仮想化ソフト使えばPC上でサーバ環境作ることはべつに難しくない。

簡単に言えば、リニューアル予定なんてないしょにしといて(=むだに期待値を上げることなどせず)、PC開発ベースででも全部検証まで完了させてから、「以前からじつはちょっとリニューアルしてみようかと思ってたんです。」と様子をみながら公開することだって出来たはずなのに。
データ差分が発生しないように、完全に遮断して切り替え作業をしたとしても、DBのリストアでせいぜい数時間停止すれば済むはずなんだけど。


。。。
たんなるホール塞ぎや機能追加ならまだしも、本格的にマネタイズに向かうタイミングを図っているなら、ちょっと戦略に欠けているとしか言いようがない。
ちなみに僕は、有料化断固反対!だとかは、一切思いません。むしろweb屋さんとしては、どこか早くマネタイズの成功事例を作ってくれないかなと期待しています。実際flickrも有料利用してます。(だからってもちろん、新fgに無条件で有料申し込みするわけじゃないけど。)

ああと、「ポイント」ってシステムは、よく言われるんだけど、あまりよい印象はないなあ。いろいろと運用もシステムも複雑になるし。個人的な好き嫌いですが。


 どのくらいコストが掛かるものなのかを考えてみよう。

Alexa みてもトラフィックについてあんまり分からないし、構成も幾らでもパターンがあるから予測なんか無意味なので、もしうちでやるならどれくらいで行けそうか考えてみる。

・ひと
SE(プロジェクト統括)/企画担当/ウェブデザイナ/プログラマ/データベースエンジニア
ネットワークエンジニア/サーバエンジニア。。

よく書籍ではこんなふうに描いてるけど、当たり前だけどよほど大手でない限り、こんなに人間を投入することは不可能です。実際にはこれをこんな感じで3人でやります。(対顧客案件ならもう一人いる。)

ウェブデザイナ(プロモーション、企画的な部分も考える)
プログラマ(DBもやる。全体の設計もやってしまう)
サーバ管理者(サーバ全般、ハード、ネットワークをカバー)


・回線
 どれくらい帯域使ってるのか分かりませんが、うちで動画コンテンツ配信の状況から考えて、画像サービスだからそれよりは小さいだろうとすると、30Mbpsくらいかなあ。。夜間多い時間帯で50M。。まったく適当です。過少評価してたらすいません。
 ベストエフォート型の共有回線か帯域保証型の専用回線で、まったく費用が違ってくる。


・サーバ
 クラウドサービス使うそうだけど、もちろん構成次第(台数とかオープンソース系か商用ソフトかなど)で費用も全然違ってきます。レンタルサーバーとまあ同じですが、ちがいは課金が柔軟ということ。必要なときにわりかし簡単に追加削減ができて、使った分だけ払えばよいという仕組みが多い。よくクラウドが世界を変える!とか聞くけど、個人的にはただのアウトソーシングだと思う。。


Simple

 普通の構成。webサーバとDBとファイル(画像とか動画)サーバ。たいていの規模ならこれで足りるけど、fgくらいの規模になると、当然シングル構成では無理。あと登録データ数も膨大で、DBの検索負荷が大きくなるので、この部分の処理も大変です。













LoadBalancing

 負荷分散、複数サーバで並列処理するには、ロードバランサってアプライアンス(装置)があるんですが、これは普通に買うと、新車が変えたりするほど高価なものです。これがあるとなとでは大違いですが、「じゃあそのLB自体が壊れたらどうするの」ということまで考えると、冗長化というのは非常にコストが掛かります。
クラウドだとたぶん複数ユーザで仮想的に共用するから、だいぶ安く利用できるはず。
DBも似たように、クラスタ化ってやり方があります。(←このへんなるとちょっと弱い。。)















Virtual

 物理的に台数が増えてくると、色々大変だから、最近ではOSを仮想化するのが主流です。(個人的には実験レベルでやるのはいいんだけど、本番では不安もあるので、まだここまではやってません。そろそろやらないとという段階。)


本当は、もっとキャッシュサーバとかも立てたりすることもあります。このへんは、コストかければかけるほど、堅牢なサービス環境になるものですが、一体どこまでやるのかは難しいところです。



とにかく4月には元気に返ってきてほしいです。(じぶんの投稿はどうでもいいけど、お気に入り作品リストが無くなるのはつらい。。)