栞/#system
「データセンターを運営しているライブドアが、無償のサーバ監視サービスを開始」
データの分割方法いろいろ。開発プラットフォーム、「1つは新しくサービスを構築していくためのプラットフォーム、そしてもう1つは、個々のサービスのスケーラビリティを保つためのプラットフォーム」
Wassrのシステム。Tokyo Tyrant使ってるのか。「Wassrのような一般ユーザのアクセスが集中するサイトでは，このような機能縮小の方策を大胆に行う必要がある場合があります」
サーバ/インフラTech Meeting、発表資料。
「ディスクIOのコストは画像の変換にかかるCPUのコストよりも高いと考えています。」Squidをキャッシュとバランサに利用。
プロフィール画像の取り扱い。数がたくさんあって、アクセスもそれなりにある。
mixiエコーの裏側。Recent DB（全ユーザーの最新データ）、そこへのキューとしてのQ4Mの活用。
ロードバランサの基本。
最適化によって期待できる速度の上限を知っておくこと。
daemontoolsまわり。
はてなのシステムアーキテクチャの話。
サーバ/インフラ Tech Meeting。8/8 18:30-21:00。
S3が落ちてた件。
LinkedInはJavaで書かれてる。
Twitterのメッセージデータの扱い。
「ソフトウェア的な問題でインデックス領域を破壊されてしまった場合、物理的には何も問題は無く、RAIDの冗長化では破壊された状態がきっちり冗長化されるだけなので全く無力です。」
Googleのデータセンターの構成。
「スケーラビリティが問題になるようなケースでは、複雑であっても、データサイズに依存せず、極端に重い処理が発生しないアルゴリズムのほうがいいのかな」
Railsの実行環境いろいろ。nginx人気。
Twitterのようなタイムライン処理をどう実装するか。
友達のタイムライン取得処理をDB側でどう実装するか。登録でがんばる or 取得でがんばる。
TwitterのHomeのようなシステム考察。「最悪 n^2 件へのアクセスで抽出可能」「follower 毎に SQL 発行ができるので、memcached との相性が良さそう」「全ユーザー数が式に出てこないってことは、すなわちスケールアウトできる」
30days Albumのバックグラウンド構成。Gearman使用。
LVSとkeepalivedを使ったブローカーの構築。
ニコニコ大百科の裏側。「repcached(セッション保持用memcached、EeePCでLVS frontと一緒に動いている)」
最終ログイン時刻データの負荷分散。Tokyo Tyrant利用。
MySQLの構成、Facebookの場合。
MySQL Conference 2008、レポート。
Flickr/Facebook/YouTubeなどで使われてるMySQLのバージョンとか。
リバースプロキシとして利用できるVarnishの紹介とPHPで試してみた例。