fslashtのサアラたん日記

■第98回 カーネル読書会に参加してきました。 07:42

第98回カーネル読書会のおしらせ

日時：09月10日、18時半開場、19時ころ開始

お題：はてなでのハード性能の引出し方

発表者：田中さん（はてな）

内容:はてなでは、現在約500台のLinuxサーバを動作させています。

このような大量のサーバを漫然と使うのではなく、限界に近い性能を

引出すためのシステム・ハード・ノウハウを紹介します。具体的には、

自作サーバ、仮想化、ネットワーク最適化といったあたりを予定しています。

18:30頃、開場、LTないし自己紹介など

19:00頃、お題開始

20:00頃、懇親会開始

21:00頃、中締め、お開きへ

今日のお題は、はてなの中の人（田中さん）による、はてなのサーバ管理技術。

はてなでは、自社サービスのために５００台以上のサーバを独自に製造して運用しています

そのノウハウがいま明かされる・・・！

会場は楽天タワー

カーネル読書会のために大勢の受付スタッフが・・・

楽天タワー内部

会場到着

到着が遅れて19:20くらいからの参加でしたが予定をこえて20:30までやっていたので盛りだくさんの内容でした。

以下勉強会のメモ

■ 安定性

負荷を把握する

冗長性確保

・アプリケーションサーバーは冗長かしやすい（状態をもたない）が、データソースやネットワークは難しい。

安定性のトレードオフ

　安定性 vs 資源効率

　安定性 vs 速度

※活発に開発をおこなっているサービスでは余裕をもって

不安定要因

。機能追加

・メモリーリーク、地雷（特定のＵＲＬで無限ループになったり）

・ユーザーアクセスパターンの変動、(slashdottedなど）

・データ量増加

・外部連携の追加（広告でＡＭＡＺＯＮ　ＡＰＩ，ＹＡＨＯＯ　ＡＰＩ）※アマゾンが落ちるとはてながおちるということがあった→現在は対策した

・ハードウェア障害（メモリ、ＣＰＵ，ＮＩＣ）は日常的に故障する

ロバストなおシステムにするために

・状態をもつプロセスをへらして、ＤＢに集約する(中間データ以外はローカルＦＳにもたない）

・状態を再構成でいるようにする（一次データ、２時データをきりわける）

・冗長度をたかめる

↓

冗長化と効率を両立するために仮想化技術を活用（ＺＥＮ）

※特にコストパフォーマンスを重視

・ＩＰＭＩの代替

・ハードウェアリソースの利用率を向上

　同じ傾向、負荷が高い機能の同居はさけるべし

仮想化サーバの例

　Ｗｅｂサーバのあいているところにキャッシュサーバ

　ＤＢのＩＯがあいているところに別のサーバ

サーバ管理ツールで、どのサーバに仮想ＯＳがきているか管理手キル用になっている。

物理的なリソース市ロース制約からの解放、ソフトレベルでの橋梁な経過

■　性能を引き出す

システムを安価に構築

・できるだけソフトでがんばる

（ＮＡＳ，ＳＡＮ，ルータは普通のＰＣサーバ、ルータで実現する）

　全部で５０ＴくらいのＳＡＮを構築しているがすべてＰＣサーバで実現している。

　例）ＧｏｏｇｌｅでもＥＣＣメモリは使用するがＲＡＩＤは使わないなど割り切って

低コストを実現するには

　ハードウェアの性能はムーアの法則で向上するためそれをみこして投資

　メモリ、ＨＤＤは３年前にくらべ１０分の１ていどの

（サラロフ氏作成のグラフで解説）

　４コア８Gbyteサーバを標準としている

　更新頻度：２年前のCore2duoサーバは引退、Quadにどんどんおきかえていく。（出消費電力あたりのパフォーマンスを最大化するため）

　はてなで使用しているサーバはすべて自作している。

（デスクトップ用パーツ（M/B,CPU）をつかって、オリジナル１Ｕサーバ筐体にいれいてる（電源は１Ｕサーバ用）。ＮＯ　ＥＣＣ，ＮＯ　ＲＡＩＤ。ＨＤＤはリムーバブルにしたがなんか性能がおちるので）

　古い機材は秋葉原などで中古でパーツ売りしている

　仮想化を前提としてハードウェアを構築

　最小限の管理機能、他コアＣＰＵ、大量メモリ

　ＩＯについては用途によって最適なものにしている。

ハード特性の利用

・データをメモリーに載せる（ＭｙＳＱＬ，ＴｏｋｙｏＴｉｒａｎｔ）

・データ量にメモリをあわせることも重要（16G vs 32Gで、16GではIO WAITが頻発しパフォーマンス低下につながっている。）→恩メモリーで処理できることが重要

　※常にパフォーマンスを計測して改善することが重要

ＩＯ性能の向上

・ＳＳＤを利用する（最近は採用をはじめた）※ＭＬＣを採用している

性能；っ目折＞ＳＳＤ＞ＨＤＤ　ＲＡＩＤ０/１０＞ＲＡＩＤ１

。32Gオンメモリー(DELL 1U 30万くらい） vs 16G+SSD（内製1Uサーバ 12万円くらい） では、16GはIO R/Wは多く発生しているがIO Waitが少なく性能が同じくらいになる

※　ただし、まだＳＳＤの障害パターンがわからないのでリスクがある。去年買った安物は半年で故障したので、Intel SSDを採用している（ただし、まだ故障したことがないのでどういう壊れ方をするのか不明）

※ IntelのSSD ファームアップデートはなるべくかけている。S.M.A.R.Tはあんまりみてないｗ

※ 主に検索用サーバに採用している。運用開始してから半年くらい。

（マスターデータはＨＤＤ，キャッシュ（スレーブ）としてＳＳＤを使用している。壊れたら捨てる。データが化ける故障は怖い）

ネットワークの冗長化

・昔は１サブネットだった。ただ１サブネットに６００台いれるとＡｒｐテーブルがあふれる！

・現状は１サブネットに１００台程度の構成にした

・この規模でもＰＣルータを活用している。

　→昔は１台でやっていたが、ボトルネックになるので複数化した

ハード（内製）

・ちょといいＭ/Ｂ

・ＥＣＣを採用

・ＮＩＣは２つ

● PCルータ

　はてなのボーダールータは、すべてＰＣルータ

　インバウンドが300Mbpsぐらいで頭打ちなようなので、限界性能を具体的に知るために良い機材がないか探した

測定方法

　クライアント（はてなで現在統一している構成をほぼおなじ） Core2Quad/4G CentOD

　ＰＣルータ(旧)：上記＋NIC ※Xen上で動いている

　↓

　ＰＣルータ(新)：オンボードに2NICあるAsusのM/B ※Xen廃止

特定手順

　はてなのインバウンドトラフィックを実際にしらべて、MTUを変更

　MTU 152（TCPペイロード100byteくらい）

　netperfを4つは知らせる

　120秒間測定の平均

　片道 200Kbpsくらいだった。

　Xen上ではオーバーヘッドで半分くらいになってる！

　nicの違いで2割くらい速度がかわた→M/B変えた

考察

・パケットロスはほとんどない

・CPUは100%にならないことも（NICがボトルネックの場合）

・負荷がかかっているときはCPU0のSoftInerruptが高くなる（ボトルネックはＮＩＣの場合？）

　※hiはCPU0に割り込みがかかるようだ→その後スケジューリングするが実行するＣＰＵが固定される？irgバランス

・ethertoolって信頼できる？

HardInterrupt

※ topコマンドでhiで表示されるもの

・デバイスの割り込みハンドラ（ソフトの割り込みはSoftInterrupt)

・できる限り速やかな処理が必要（割り込みが多いとＣＰＵがユーザーランドに移らなくなる）

　上記の計測では、20kHz程度で割り込みがおこっていた

SoftInterrupt

※ topコマンドでsiで表示されるもの

・デバイスからパケットを受け取るドライバ部分

・ネットワークスタック部分

・日また時はカーネル内の適当なところで割り込みが発生する(HIの最後など）が、忙しいときはksoftirqdカーネルスレッドから呼ばれる

NAPIの仕組みが普及してからは、デバイスドライバからのパケットをうけとるのがhiからsiになった。

高負荷時にもレスポンスが悪くならない。

ブロードキャストストームでも割り込みハンドラが呼ばれまくってユーザープロセスがまったく動かなくなることを防げる

（NetBSD方面では高負荷対応の場合、割り込みではなくポーリングでやることがあるとのこと）

最近のNIC

・interrupt coalescing

　派毛とｔが何個かたまってから割り込み→割り込みによるコンテキストスイッチが減少

・TCP Segmentation Offloading (TSO)

　

失敗談

・netperf の -m オプションでパケットサイズを変えても反映しない。

　→Nagleアルゴリズムの効果で、ひとまとめにされていた。TCP_NODELAYも利かない（MTUをしぼったら反映した）

・netpref　１つだけうごかしても１コアしか回っていない感じ

・クライアントがボトルネックになりやすい（システムコールとＴＣＰスタックまで処理するよりルータよりも負荷が高い） vs ルータはルーティングがカーネルで完結するので速いのかも

・M/BはSuperMicro X7SBL-LN2に交換したら 400Kbpsぐらいと旧ＰＣルータの２倍の性能が出た

　※サーバ用のＮＩＣはバッファなどがぜんぜんんちがうので速いと会場から

将来

・Xen3.2からのI/O-MMUで高速化ｄけいるかも

・siキューはCPUごとに独立していてスケジューリングしたCPUに縛られるので、特定のＣＰＵに負荷が集中するので、その際別ＣＰＵへバランスする機能があったら速くなるかも

・hiを複数コアに文才しても並列度があがらない（ＣＰＵ負荷が１００％にならない）。→ＢＳＤでは１００％まで使いきれるようなのでがんばってみる

はてなでは

・Xen使うとネットワークi/oが遅くなる

・SSHがつかえないときかんりできるようXenをつかっているという事情もあるので、仮想化しないでM/BのIPMI付のサーバ用M/B（値段的に３倍程度なので）にしていく

・Xen3.2でも再検証

・OSはCentOS

まとめ

はてなのシステム

・ハードは安価に

　・ソフトでがんばる

　・性能はできるだけ引き出す

・自作サーバの細かいはないしゃ、自作サーバカンファレンスで！（pixivさん、セレボさんとでカンファレンスを企画したい→会場でこまってる→楽天でよければ）

Ｑ＆Ａ

・世界記録では9Gbpsくらいでてるのでもっとパフォーマンスあがるのでは？

・IP tableのF/が２０〜３０かかってるので、負荷が高い

・CentOSをカジュアルにつかっている

・カーネルオプションは変えていない

・カーネルのバージョンをあげるべきでは？→社内的には嫌がらる（カーネルバージョンはすべて統一したい。ＲＡＩＤのドライバとかではまりたくない）

/

懇親会のピザ＆ビールパーティ

乾杯！

社是！

打倒アマゾン！

楽天は仮面ライダーアマゾン打倒を目指す悪の秘密結社だったのだ！

対アマゾン兵器

/

勉強会のあとは、有志による２次会。

大変濃いメンバーがあつまりました。

乾杯

宴の後