I ♥ WordPress

[24svr-TechMTG]感想
2008/08/09 00:34 posted by kunkichi

ということで感想。

この本を書いたわけ(ひろせさん@KLab)

・こういう本を待ってました。
・情報発信することで横のつながりができる。やっぱりアウトプット重要。

Linuxカーネルの読み方(naoyaさん@はてな)

・「根拠のない対処療法」ってところにグッときた。
・GNU Global、App::Ack あとで試す。
・『linuxカーネル解析入門』チェックする。
・Linux Kernel Hack Japan ブクマ
・『本を読む本』
・やっぱりC重要。gcc拡張とか遠いけどがんばる。
・CPUというかハードウェアも勉強しないと。
・『64ビットがわかる』『初めて読む〜』
・writing a simple file system ブクマ
・理論的に攻めたい。

DSASのこれから(安井さん@KLab)

・tomcatなのか。
・悔しさオリエンテッド。なんとかしたいというモチベーション重要。
・たくさんの懸念はのためにやるべきことをすこしづつやっていく。

はてなのインフラ、いまむかし(田中さん@はてな)

・やっぱり少しずつ改善・成長が重要。
・MySQLマルチマスタ化は気になる。
・ディスクレス・オンメモリで疎結合。やらなきゃ。
・Hadoopはまだちょっと難しすぎると思ってたけど、確かにログ解析で悩み中。
・capistrano、puppet、seleniumもやりたい!
・PXEとか独自RPMレポジトリならCobbleもいいよ、とか言ってみる
 Xenならkoanもあるし。っとドキュメント翻訳がんばらないと。
・「体力勝負」っていう「根性論」はなしとはおもうけど、「気合い」とか「男気」とか
 っていうモチベーションとかチームの結束という意味での「根性論」は必要な気がする。

naoyaさんも言っていたけど、先人の苦労や工夫がこういう形で公開されることはほんとうにありがたいことです。いつかそっちの立場になって少しでも貢献できるようになりたい。

ということで、今から読みます。しかし、本を買ってその勉強会でまた買わなきゃいけない本が増えるとは、笑。でも楽しい。

[24svr-TechMTG]まとめ
2008/08/08 23:55 posted by kunkichi

ほぼリアルタイムで追っかけてみる→失敗、orz

この本を書いたわけ(ひろせさん@KLab)

・見逃した。
 →ustreamあとで見れるの知りませんでした。
・本を作った訳
 ※会社返りに買ってきた!今から読む。
・mod_cidr_lookup

Linuxカーネルの読み方(naoyaさん@はてな)

過去の対応
・負荷が高いとき
・apacheアクセス過多
・IO高い

・ググってみる
・変えてみる
→根拠のない対処療法

ソースを読んで根拠に基づいて統計から原因を特定
・『BINARY HACKS』とか『詳解Linuxカーネル』とか
・当初難しいと思っていた→ そうでもないよ

俺流読み方
・ツールで効率よく読む
 ・gnu global - ソースコードタグシステム
  emacsで関数の定義場所と呼び出し場所を行き来できる
 ・app::ack
  perlモジュール、grepよりも検索しやすい、コマンドでできる
 ・書籍
  同じテーマで別の書籍を読む
  『linuxカーネル解析入門』
 ・紙/ペン
  コールスタックが深いと迷子になるので処理フローをメモ
 ・Linux Kernel Hack Japan(サイト)

コツ
 ・読む対象を絞る
  隅々までよまない、テーマを決めて読む
 ・いきなり読まない
  全体把握から。本の目次と同じ。
  『本を読む本』
 ・概観を知った上で読む
  本とかで概要をあらかじめ押さえてから読む。
 ・重要なデータ構造を把握しておく
  プロセスとかよく出てくる構造体などのデータ構造は先にざっくり把握
  しておくと楽。
 ・テストプログラムを活用
  実際の動きを確認するために。

読んでわかった必要な知識
 ・C言語。gcc拡張部分とか。
 ・GNU開発ツール。libcとか。
 ・CPUの機能(x86)。CPUの細かい機能。01を計算してるだけじゃないよ。
  『64ビットがわかる』『初めて読む〜』
 ・オブジェクト指向、template method とかかんたんなやつ
  ”writing a simple file system”(サイト)
 ・手を動かしてみる。カーネルモジュール開発。

まとめ
 ・読むコツをつかむ
 ・カーネルソース読むと負荷(分散)に強くなる
 ・OSの動作原理を知ることができる

その他
 ・知りたい動機が大切。
 ・次の興味は?→自然言語処理。  

DSASのこれから(安井さん@KLab)

・DSASの紹介
 動的にサイトごとのサーバ台数の割当を変更できる
・工夫
 - 全サーバの構成は同じ。
 - tomcat。
 - ファイルの更新は専用ツールで一括転送。rsyncはNW/IO負荷高。
  そのうち公開予定。
・ダイナミック→自動的、自立的
 自動で故障対応とか増設とかやってくれる→わけない、悔しい。
 ↓
 なんとかしたい!
・自動で追加するには?I
 サイトごとのトラフィック推移を記録しないといけない
 追加時にtomcat再起動しないといけない
 →PVSモジュールを作る
・でもたくさんの懸念
 →やるべきことをすこしずつやっていく
 → そのためにカーネル読んだり、モジュール書いてみたり、
・DRBDとの出会い
・インフラ楽しー

はてなのインフラ、いまむかし(田中さん@はてな)

・1000万UU/月、6000万PV/日
 サーバ350台、仮想化して500台。14ラック。240Mbps。
・インフラ初期(2001〜2002年)
 P3自作PC、apache+PostgreSQL、PerlCGI、オールインワン。
 → CGI重い→mod_perl入れる→mod_perl負荷高い→
 →リバースプロキシ入れる→以下、略
 こういうのの繰り返し
・インフラ拡大(2002年)
 サーバケース自作、レプリケーション、mod_proxyでLB
・はてなダイアリー(2003年)
・東京移転(2004年2月)
 mod_proxy_balancer
・サービスラッシュ(2005年)
 はてなブックマーク、RSSとかマップとか。問題多し。
 - SPOF多数、体力勝負
 - 回線飽和
 - 電力不足
・インフラ2.0(2006~2007年)
 KLabとの出会い、LVSとの出会い
 →SPOFの解消
 →運用の効率化
・さくらiDCへ(2007年)
 回線・電力の問題解決
 インフラチーム発足
 期間ネットワーク見直し→LVS+keepalived
 OS更新、64Bit
・2007年半ば
 - LVS三層構造
 - 商用サーバ一部利用
 - 64ビット→メモリ4GBの壁を突破
 - キャッシュ→I/O負荷の低減
 - MySQLマルチマスタ化
  お互いにslave/slave、active/backup、keepalived
・2008/8現在
 - インフラは足腰
 - 仮想化(Xen)500台中150台
 - 仮想→別ハードに移動可能、xenの移動機能は使わずddで。
 - xenディスクレスサーバ、中央ファイルサーバ→オンメモリ上に展開して。
  ファイルサーバに依存しない。
 - Hadoopで分散ファイルシステム、並列クラスタ→ログ解析
 - サーバ管理ツールは独自。他ツールと連携。Nagios、capistrano、IRC
 - セットアップの簡略化、PXE、Puppet、独自RPMレポジトリ、Capistrano、
 - selenium検討中
・課題
 - 微妙に壊れるパターンはやっかい
 - 日々のトレードオフを踏まえた上での適切な方策
・より強固なインフラを目指して
 - インフラはクリエイティブ!

結論としては「インフラはクリエイティブで楽しい!」だな。
感想は別のエントリで。

[24svr-TechMTG]Ustreamはじまった
2008/08/08 18:59 posted by kunkichi

大阪なのでUstreamで。

くっそ、仕事が遅くなったのでDSASひろせさんのセッション見逃した、、、orz

スケジュールはこんな感じ。

18:30~18:35 オープニング
18:35~18:40 (5分休憩)
18:40~19:00 この本を書いたわけ ……ひろせまさあき(KLab㈱)
19:00~19:05 (5分休憩)

今この辺。

19:05~19:35 Linuxカーネルの読み方 ……伊藤直也(㈱はてな)
19:35~19:40 (5分休憩)
19:40~20:10 DSASのこれから ……安井真伸(KLab㈱)
20:10~20:15 (5分休憩)
20:15~20:45 はてなのインフラ,いまむかし ……田中慎司(㈱はてな)
20:45~20:55 Q&A
20:55~21:00 クロージング

このページの先頭へ