cafe chantant blog

[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検討中
・課題
　- 微妙に壊れるパターンはやっかい
　- 日々のトレードオフを踏まえた上での適切な方策
・より強固なインフラを目指して
　- インフラはクリエイティブ！

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

Category: 24svr-TechMTG, Server | コメント＆トラックバック（0）

[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 クロージング

Category: 24svr-TechMTG, Server | コメント＆トラックバック（0）

08/09シーズンの海外サッカー放送予定局まとめ
2008/08/04 19:17 posted by kunkichi

さて、8月に入り、そろそろ08/09シーズンの開幕が近づいてきました。
ということで、各国リーグの放送予定局を調べてみた、2008/8/4時点のまとめ。主にCS中心。内容無保証。

プレミアリーグ
昨シーズンに引き続き、J SPORTS。試合はライブ・録画含めて週５試合程度、毎週土曜のプレビュー＆毎週月曜のハイライト、そして、西岡さんのE.N.G. と去年とほぼ同じ。

スコットランド・プレミアリーグ
こちらも昨シーズン同様、J SPORTS。ま、リーグっていうか毎週のセルティック戦のみってところも、昨年と同じ。

リーガエスパニョーラ
昨シーズン同様、WOWOW。WOWOW見れないので詳細不明。バルサに限っては、引き続き J SPORTS でバルサTVあるけど、カップ戦中心だったと。

ブンデスリーガ
あー、J SPORTS でやってた頃が懐かしい、泣。
とりあえず、昨シーズンに引き続き、CSフジで日本人所属チームの毎週1試合とその週のハイライト。CSフジ見れないので詳細不明。
あと、GAORA がバイエルン・ミュンヘンのクラブTV放映権を獲得したようで、バイエルンの試合は全試合（とりあえずリーグ戦のみはそうっぽい）、あと、情報番組として「バイエルン・ミュンヘンTVマガジン」というのがあるっぽい。

リーグ・アン
残念ながらJ SPORTSでの放送は無くなった様子。

その他
J SPORTS の Foot! は8/15からスタート。今年も特集というかロケ中心の様子で、初回は昨シーズンに引き続いて倉敷さん海外ロケでオランダらしい！
そいや、J SPORTS は MLS も多少あったような気がするけど、今年はどうなのかな？
あと、南米系はリーグ戦は相変わらず放送なしっぽい。唯一、昨シーズンはG+でコパ・リベルタドーレスあったけど、今年はどうなのかなぁ、とりあえず8月中は昨シーズンの再放送あるみたいだけど。
その他のリーグについては元々放送ないし、あと CL とかは省略。

しかし一時期に比べると寂しいラインナップだなぁ。セリエAないし。

とりあえず、直前のどんでん返しとか今年はなさそうな感じ。

Category: Soccer | コメント＆トラックバック（0）

今回のDNSキャッシュポイズニングの脆弱性対策について
2008/08/04 00:31 posted by kunkichi

騒ぎもちょっと落ち着いたようなので（というかある程度詳細がわかって、世の中の対応もそれなりに進んだみたいなので、という意味）、もし対応を迷っている管理者の方（今でもいるんだろうか、、、）向けに、既に対応した管理者としての感想。

キャッシュサーバ使ってなければ全く気にする必要なし。
今回の場合「バージョンアップしない」っていう選択肢はないと思っていいと思う。例えば大手ISPの○○は対応してないからうちもやらない、っていうのはちょっと無理があるかと。大手は金も物も持ってるからね、実は見えない部分で台数かけて分散してたりして、台数ある分だけやられる確率低くなるていう意味ですぐに対応してない場合もありえる。
bindの場合、対策版（P1）にバージョンアップするとLoad Average上がります。とある環境ではざっくり1.5倍程度。なんとなくレスポンスもちょっと遅くなった気が。
上記P1のパフォーマンス改善版（P2）が出たみたいなので、今からだったらこっちにすべし。まだ試せてないけどP1に比べてどの程度負荷が下がるんだろう？
ってことで、もし日頃の負荷がある程度高い状態だったら、バージョンアップすると限界迎えるケースもありえる。その場合、スケールアウトはすぐにはできないだろうから、せめてスケールアップできるように準備しておいた方がいいと思う。

今回思ったんだけど、DNS のキャッシュサーバの性能測定って難しい。queryperf 使うにしても、再起問い合わせの部分をどうシミュレートすればよいのか。インターネットに実際に流す訳にはいかないし、やっぱり自前ネットワークでrootサーバから構築するとかしないといけないのだろうか。

Category: UNIX, Server | コメント＆トラックバック（3）