TAKESAKO @ Yet another Cybozu Labs

■第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に圧縮ゲートウェイを入れちまえ

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

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

■第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のスレーブ

→質疑応答でいろいろ

■最後に記念撮影

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

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