ライブドア次世代テクノロジーセミナー第1弾

六本木ヒルズで開催されたライブドア次世代テクノロジーセミナーに、会社の同僚の秋元さんと一緒に行って来ました。

livedoor_seminar.jpg

当社は長い受託ビジネスやWEB開発から蓄積した、膨大な経験と実績を使い、現在UU14,336千人、月間約22億PVというポータルサイト 「livedoor」を構築するまでになりました。そこには飽くなきローコストへの挑戦と、多くの優秀なエンジニア、更には膨大なインフラを支えるネットワークエンジニアによる日々の汗と苦労の結晶です。今回は、それらの技術面及びインフラ面のノウハウの一端を、皆様の成功の鍵にしていただきたく紹介をさせていただきます。

定員50名の募集に対して、告知後数時間で150名超の申し込みがあった
いわば選ばれた者だけが参加できた貴重なセミナーでした。

■参加者のレポート

[システム運用] ライブドア 次世代テクノロジーセミナー
http://pmakino.jp/tdiary/20051213.html#p01

ライブドアの次世代テクノロジーセミナーに行ってきた
http://d.hatena.ne.jp/a666666/20051214

てくのーと2.0 : 六本木ヒルズ初上陸
http://blog.kan.vc/1134571006.html

どこまで公開してよいかわからないけど、当日の個人のメモを公開してみます。
(一部やばそうな内容は削除しています)

■第1部「ポータルサイト<livedoor>の裏側」
 ネットワーク事業部 執行役員 伊勢 幸一

ライブドア、AMD Opteronプロセッサの採用を発表(後日追記)
http://www.amd.com/jp-ja/Corporate/VirtualPressRoom/0,,51_104_543~103315,00.html

AMD 64bit CPU
シャーシから独自設計
1Uの1/3 後ろから前から
1ラック60台まで搭載可能 3kVA(すごい!)

保守性を高めるためにディスクレス

ストレージの仮想化
 ヘテロジニアスストレージシステム
 iSCSIクラスター

トランジットとIXのハイブリッドアップリンク
 BGP4によるTEには限界がある
 根本的な解決は?

配信と同時にリアルタイムに圧縮できない?
 ポータルだけで4000台以上
 JPEG,GIFには効果なし

自力でデータ圧縮することに

URL、サフィックス単位で圧縮ナビゲーション
 Squidに圧縮ゲートウェイを入れちまえ

これってCDNの仕組みと一緒ジャン
 Bind/Tenbin改造してCDNナビゲータ

まとめ: レイヤー0から頑張ってますよ。

■第2部「コストパフォーマンス抜群のWEBアプリケーション構築」
 ネットサービス事業部 テクニカルディレクター 谷口 公一

ライブドアってそんなオープンソース使ってたの?
 OS は主に FreeBSD 4.11 (1割程度は TurboLinux)
 Web Server は主に Apache 1.3.x (mod_perl)
 RDBMS は MySQL 4.0系 (95%以上)
 開発言語は主に Perl 5.8系
  延べ13人の CPAN Author を輩出しています
  現役 3人 (汗)

株式会社オン・ザ・エッジ
 受託Webサイト構築が主軸事業(対法人向け)
業務から生まれたオープンソースProject
 Sledge (http://sl.edge.jp)
 GPL or Artisticライセンス
開発効率の向上(人的コストの削減・より働けるようになった)

ポータルサイト livedoor の誕生 (2003年11月)
 ポータルサイトは後発不利
 当初は泣かず飛ばず

アクセス大杉
まさに
想定外

トラフィックとスケール
Apache/mod_perl
 適切なチューニングとスケール化でここがボトルネックになるケースは稀
MySQL
 Masterのパフォーマンス劣化は免れない

コスト無視の施策
・商用RDBMSの採用
  お金さえあれば何でも買えますから

商用RDBMSについて改めて考える
・メリット
 高い信頼性、高い安定性、豊富なストレージ
・デメリット
 割高なコスト(ハード、ソフト、サポート)
 運用ノウハウの不足
 本当に満足のいくサポートが受けられるか
 「アジャイル開発」には不向き

Webアプリケーションとコスト
・結局、悩まされ続けたのは「DBへの負荷と障害」

ハイエンド機1発+商用RDBMSより
IA機数機+MySQLの構成

MySQL Cluster? 信頼できる実績がまだ見えない
アプリケーションレベルでの付加分散・冗長化

livedoor DBCluster (仮)
livedoor Blog, livedoor FrePa にて実装
cluster化によって障害発生時の影響範囲を最小限に抑えられる
cluster化しないデータとするデータ
Class::DBI like な cluster 用 O/R mapper
memcached との併用

→2005年の成果?

ライブドアの今後の開発スタイルは…
・Web 2.0!
 ・Ajax!
 ・Webサービス!
・Sledge 2.0
 ・現行版の不満点を解消
  ・12 Things I dislike with Sledge
  ・Sledge で気になるとこ
 ・Catalyst や Rails のおいしいとこ
 ・mod_perl 2 対応
 ・下位互換はどうしようかなと・・・

はてなキーワード「ライブドア入りたい!」はまだ健在。

■第3部「大規模システムを構築する秘訣」 →「Inside livedoor Blog’s Backend」
 ネットサービス事業部 テクニカルマネージャー 池邉 智洋

・ユーザ数100万人を超えるブログサービス
・アクティブユーザ数は27万人程度(月間)

TurboLinux 10/FreeBSD
Apache 1.3.x
Sledge on mod_perl
Squid
memcached
pure-ftpd

Appサーバ約120台
WWWサーバ約150台
DBサーバ約250台
その他サーバ約20台(バッチ)
NASサーバ

2003/11~ サービススタート
1台構成
開発期間は2週間程度で最小限の機能
ユーザ向けページ/管理ページはVirtualHost
MySQLも同一サーバで稼動
→現在からは課投げられない構成

2004/02 複数台構成
機能毎にサーバを分割
管理ページ
ユーザのブログページ
RDBMS(MySQL)

2004/05 MySQLレプリケーション
・単純なPVの増加にはサーバの追加を行なうことで対応
・管理ページの使用頻度の増加によるMySQL I/Oの増加
・Read/Writeの分割による負荷分散

2004/08 商用DBの導入
・某商用DBを導入する
・SQLの方言に対応するための書き直し
・静的データへのアクセスもボトルネック化
・記事データの配置を変更することで対応
 → mod_rewrite
・画像データをSquidでキャッシュ

2004/10 memcachedの導入
・商用DBで思ったようなパフォーマンスが出ない
・調べてみると記事データ(lob)のI/Oがボトルネック
・メモリ>>>>>>ディスク
・一度取得した記事データをメモリにキャッシュ

2005/06 BlogNGプロジェクト
半年程の安定運用の後・・・
商用DBは運用、機能追加が面倒
ビジネスのスピードアップが必要
再度 MySQL を採用する
アプリケーションサーバだけ追加してもパフォーマンスはあがらない
マシンさえ用意すればスケールする構成に

大規模環境でのMySQLの利用
・Blog毎に記事、コメント、トラックバックを保存するDBを変更
・あるデータがどのDBに保存されているかを指し示すテーブルを用意する
・各セット毎に Master-Slave構成
・テーブルタイプは
 InnoDB(更新系)、MyISAM(カテゴリ、ユーザなどSELECT重視)混在
・mod_perlから持続的接続はしない
 TCP接続は速いのでリクエスト毎に切断した方が効率が良い
Class::DBIでちょっとハック

MySQLへの移行
・移行プログラムを用意して順番に処理
・商用DBからSELECTしてMySQLに分散させながらINSERT
・データの再書き出しを含め予想以上に時間がかかる

ホスト名を分割しての運用
・用途毎にホスト名を分けて運用する
・障害発生時の切り分けが用意に
・サーバ追加のプランを迅速に立てる
・バックアップ用にMySQLのスレーブ

→質疑応答でいろいろ

■最後に記念撮影

livedoor_takesako.jpg

その後の飲み会ではいろいろな方とお話しできて楽しかったです。

第2弾はid:naoyaさんが講演される予定だとか。次回も期待してます。

コメントは受け付けていません。