事件直後の話はこのへんで切り上げて、その後の、あまりぱっとしなかったサービスの話をいくつかしていこう。

- Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた?

nowaってみんな知ってますかね…
ライブドア、新ブログサービス「nowa」の一般向け公開を開始 (2007年5月30日)

Six Apart の VOX という新ブログサービスを参考に、ブログと SNS と twitter と tumblr と irc を全部あわせたような様々な機能を備えた次世代ブログが nowa だった。

この頃は丁度、web2.0という言葉がもてはやされ、ライトユーザ間のゆるい繋がりや、リブログによる気軽なコンテンツ共有に的を絞ったサービスが多数生まれた頃だ。(Twitter がサービスを開始して注目を集めはじめたのもこのあたり、2006年後半から2007年前半にかけてだ。)



前の方の記事でもちらっと触れたけど、経営陣は一時これに社運を賭けるとまで宣言していた。ライブドア事件から一年余り、満を持して繰り出した、逆転の一手となるべき切り札だった。

しかし結果としては、ユーザ数が伸び悩み、早くも2年目には終了が決定される。
ライブドアの初心者向けブログ「nowa」終了 (2009年2月)

ついでに、お手本にしたVOXもまた、その翌年に力尽きた。
Six ApartのVoxが閉鎖へ (2010年9月)



そもそも nowa の社内での通称は「新ブログ」だった。
既に運用開始から5年余り経過し、システム的に老朽化していたライブドアブログの後継として、ゆくゆくは現行ブログユーザをまとめてその「新ブログ」へと移行させることまで踏まえて開発されていた。「初心者向けブログ」と紹介されることもあったけれど、もともとはライブドアブログの正統な跡継ぎでもあったのだ。

だけど結果的には nowa は終了し、退役するはずだった現行ブログシステムは、いまもこうして残っている。

なぜ nowa が終了したのかを語るためには、まず、なぜ現行のライブドアブログが残ったのかを話す必要があるだろう。



ブログのエンジンには大きく分けて二種類のタイプがある。あらかじめ記事を html ファイルに書き出しておいてそれを表示するだけの静的生成タイプと、リクエストがあるたびにデータベースから内容を読み出して表示する動的生成タイプだ。

後者の動的生成タイプは WordPressなど、比較的後発のモダンなシステムで一般的になってきた方式だ。ブログを世に広めた元祖ともいえる Movable Type の初期タイプは、静的書き出し専用だった。これをベースに設計されたライブドアブログもまた、同じく静的書き出し方式だった。

静的書き出し方式には
  • あらかじめレンダリング(html生成)を済ませているので、毎回データベースにアクセスする動的方式に比べて格段に表示が軽い (※1)

というメリットがある一方、
  • データベースとは別にレンダリング済みの htmlも保持するので、その分必要とする容量が多い

  • 過去の記事は、基本的には html に書き出された時点で「凍結」されてしまう。例えば、古いページの中に埋め込まれた「最新記事のリスト」はずっと古いまま更新されない

  • それを防ぐために、定期的に古い記事をまとめて「再構築」する必要がある。記事数が多ければ多いほどこの処理には時間がかかる。(結局、表示が軽いのはこの再構築の重さとトレードオフの関係にある)

…というデメリットがある。

もうすこし具体的に解説しよう。

1番目の容量の問題は、個人レベルではピンと来ないかもしれない。だけど、数百万IDを抱えるサービスとなると話は別だ。

分散ファイルストレージなどまだ一般的でなかった時代から運用されていたライブドアブログは、生成された html を商用の大型ネットワークストレージに保持していた。ネットワークストレージといってもそこらへんの電気屋に売ってる外付けHDDとは訳が違うよ。年間のリース費用が一千万円単位にもなるバケモノハードウェア。

ただの html だけでも数百万IDが集まれば合計容量はテラバイト級になる。しかも、小さな html ファイルばかりだから個数でいえば億単位。
これが百台超のサーバから同時にマウントされ、その全てから大量のランダムアクセスがやって来る
。それを悲鳴一つ上げずにさばくネットワークストレージが、長らくライブドアブログの生命線となっていた。しかし、その容量や性能 (あと、リースの更新期限) は日に日に限界に近づきつつあった。

2番目と3番目の問題は、こういうことだ。
例えばここに、1月1日と1月15日に書かれた記事がある。

BlogPaint
ブログには個別記事ページのほか、最新記事一覧、月別記事一覧、カテゴリ別記事一覧といった、いくつかの「一覧ページ」がある。この図ではとりあえず、1月1日と15日のふたつの個別ページと、1月分の記事一覧(月別アーカイブ)をだけを記した。

さて、少し間をおいて3月3日に次の記事を書いたとしよう。
このとき、ブログシステムが更新しないといけないのはこの3月3日分の個別記事ファイルだけじゃない

BlogPaint
  • 3月分の月別アーカイブを書き出さないといけない

  • 各記事のページ上部に、前のページと次のページへのリンクが載っていることに注意。3月3日の記事が書かれた時点で、ひとつ前の1月15日分のページも作り直す必要がある

  • 2月には一本も記事がない (=2月分の月別アーカイブページが存在しない) ことにも注意したい。サイドバーにカレンダーがあるなら、1月のカレンダーの「次の月」は3月に、3月の「前の月」は1月にリンクするようにしておきたい

  • そのほか、この図にはないけど、最新記事一覧ページや、記事の属するカテゴリやタグ一覧…等々、関連する修正は多数のページに及ぶ

これが、記事の順序の入れ替え (3月15日付の記事の日付を1月12日に変更する、など) ともなると、さらに複雑さが増す。

たったひとつの記事の追加・変更・削除が、これだけの範囲に影響を及ぼすのだ。これらのファイルをすべて同時に再構築しないと、様々な箇所でリンク切れや情報の不整合を引き起こす。



さて、2006年当時は、これらの複雑な連動書き換えが実装されていなかった。例えば上の例でいうと、3月3日の記事を書いたときに、ひとつ前の1月15日の記事は連動更新されなかったため、過去の記事から現在の記事への導線がしばしば不完全なままになっていた。
また、サイドバーにある1月のカレンダーの「次の月」リンクを押すと、存在しない2月分の月別アーカイブを参照して404エラーになった(※2)

これらの不整合を一挙に修正するために、「全ての記事を再構築」という最終兵器みたいなボタンがあったのだけど、これが曲者で、なにしろ今まで書いた全ての記事を全書き出しするので、負荷も待ち時間も馬鹿にならなかった。大量に記事を書き溜めている人はこのリンク修正のために何十分も待つ必要があった。また、野放しになっていたスパムブロガーが大量に再構築をかけるたび、他のユーザの再構築処理まで巻き添えを食らって遅れる、といった問題も頻発していた。



…というふうに、静的書き出しのブログの再構築方法については、どれだけ書いても書き足りないほどの苦労話があるのだけど、このへんにしておこう。

ユーザから見ればこの「再構築」がとにかく手間。

時間がかかるし、そもそも「再構築」の意味がよく分かんない。既に動的生成ベースのブログサービスも一般的になってきており、それらと比べると「気軽に投稿して、すぐ自分の投稿した記事が見られる」という感じはとてもしなかった。

しかし一方で、こまめに再構築をしなければブログ内での導線が非常に悪く(たとえば過去記事から最新記事へのリンクがないなど)、回遊率やSEO的に非常に不利な状況にあった。

他にも様々なシステム的な古さが指摘されていたが、「静的書き出し型のエンジンである」ということひとつとっても、ここまで致命的な問題が顕在化していた。そしてこれらは設計の根幹に由来するもので、いったん一から作り直すしか手はないように思われた。

折しも、Six Apart が投入してきた新しいタイプのブログサービス「VOX」に世間の (というか web2.0 な人達の) 注目が集まり始めていた。
そこで、
  • VOX を参考に、(動画や画像や商品紹介などの) 様々なメディアを簡単に投稿でき、SNSの要素も加えた次世代のブログを作る

  • ライブドア色は控えめで

  • 一から作り直すことで、ネットワークストレージの容量問題や再構築の問題などのシステム的な課題をまとめて解決する。またこの機会に、システム上追加がむずかしかった(SNSなどの)新機能を一挙に導入する

  • 将来的には現行ブログのユーザをまとめてその新ブログに移行し、旧ブログは退役させる

…というプランが持ち上がったわけだ。
ライブドア有賀氏、新ブログサービス「PRAC」で新たなユーザー層開拓を (2006年9月)

のちの nowa である。(つづく)

--

※1一時期、静的書き出し方式の Movable Type から WordPress に乗り換えたらサーバが劇重になって大変だった、といった例をいくつか見かけたけど、その原因がこれだ。

※2 さらに酷いことに、ライブドアブログの404エラーページは数秒後にライブドアトップに自動リダイレクトされる仕組みになっていた。何かの拍子にこういったデッドリンクを踏んでしまうと、強制的にポータルトップへ飛ばされる。しかもそれによってポータルトップのPVが何パーセントかかさ上げされていたため、頑張ってそれを直したら、ボータルのPVが無視できないレベルで減って、すっごい文句言われた。