The Art of Capacity Plaining

昨日、パソナテック10周年記念　PTカンファレンスVol.6 インフラエンジニア討論会2008 ～インフラエンジニア進化論～に行ってきた。自称インフラエンジニアとしては、なかなか刺激のあるイベントであったが、その中で mizzy さんが「The Art of Capacity Plaining」という本を最近読んでいると聞いたので、調べてみた。

この本は、Book review などの情報源がたくさんあって、Flickr のオペレーションエンジニアの John Allspaw 氏が書いたいわゆるサーバの増強計画をどのように行うかについて書かれた本であるとのこと。

最近、仕事でも急にサーバを増やすように言われて四苦八苦している僕にとっては、かなりタイムリーな本だ。O’Reilly で紹介されている記事から含まれているトピックスを訳すと、次のような内容が含まれている。

• 計測、デプロイツールを評価する方法
• ストレージ、データベース、アプリケーションサーバへのキャパシティ解析とその予測
• 簡単に（サーバを）追加できるアーキテクチャーのデザイン方法、キャパシティの計測方法
• 突発的なアクセスへの対処方法
• 急上昇と爆発的な成長の予測
• EC2 のようなクラウドサービスは、どのような内部的なキャパシティストレージに合うか（ちょっと意味不明）

どのような紹介が highscalability.com にも紹介されていた。highscalability.com は、ずっと購読していたが RSS の URL が変わったようでまったく更新をチェックしていなかった。。。インフラまわりをやっている人は、highscalability.com をチェックすることは必須であると思う。このサイトは、大規模なサイトがどのような技術を使っているかの情報源をまとめた貴重なサイトです。

John Allspan 氏は、1999 年からニュースマガジンや SNS のサイトを担当してきた経歴の持ち主らしいので、かなり勉強になりそう。John Allspan 氏のブログは、Kichen Soap として公開されている。同氏は、昨年の MySQL コンファレンス 2007 や Web 2.0 Expo や Velocity でも講演していた。これらのスライドは、すでに公開されていて、チェックするのを忘れていたので、メモしておく。

まずは、MySQL Conf 2007 の「Capacity planning for LAMP」から。スライドは、PPT あるいは PDF で公開されている。PDF の方は、スライドの他にもメモが書いてあるので、PDF の方をチェックするといいと思います。

• 自分のサービスには、どのくらいのデータベースサーバ、ウェブサーバサーバ、共通ストレージ、スイッチなどが必要かついて問い正している
• Flickr の数字が公開されていて、squid キャッシュに合計 35M（この M はミニオンという意味かな…）とすると 3,500 万枚くらいの写真があって、squid のメモリに 2M くらいの写真があって、470M くらいの写真がそれぞれ 4 〜 5 くらいのサイズあって、38k req/sec くらいの memcached にアクセスがあって 12M くらいのオブジェクトをもっている、2PB(!) の物理的なストレージがある
• このプレゼンでは、MySQL、squid、memcached について焦点をあてて話すとのこと
• サーバのキャパシティを考えるにあたって、計画（何を？なぜ？いつ？）、デプロイ（インストール、設定、管理）、計測（グラフ化）の3つの主パートについて考えてみる
• MySQL は disk I/O、squid は disk I/O あるいは CPU、memcached は CPU あるいはネットワークの上限をを把握することが重要
• Flickr では、Ganglia を使っている、貴重なスクリーンショットが公開されている
• Ganglia で、iostat で計測した結果をグラフにするためのシェルスクリプトが公開されている
• memcached の Gets/sec もグラフにしている、スライドで紹介されていた addon のページ http://wtf.ath.cx/ はデッドリンクだったが、別のものがあった
• GraphClick という 8 ドルの MRTG グラフを解析するためも OSX 用のシェアウェアが便利
• Flickr の MySQL サーバで使っている、DELL Power Edge 2950に 6 個のディスク 15K RPM の SCSI、RAID10、16GB RAM、クアッドコアCPU、というスペックの MySQL のクエリーグラフが公開されている、グラフをみると秒間 1.3K くらいの SELECT クエリーを捌けているが、CPU は 2% までいかないとのこと
• 次に MySQL Disk IO のグラフが公開されている、グラフをみると iowait が 10% くらいになっているが日々変わるのでよく監視している
• Squid へのリクエストとヒット数やヒット率、LPU の reference age、レスポンスタイムを ganglia のグラフにしている、80% くらい squid キャッシュにヒットしていて、レスポンスタイムは 50ms 以内くらい
• OSS のデプロイツールとして、SystemImager/SystemConfigurator、CVSup、Subconが紹介されている

かなり勉強になった、昨日でも mixi や楽天はなんでもグラフ化していると言っていたが、Flickr でも ganglia でさまざまなものをグラフ化している、僕も ganglia を使っているけれど MySQL とか memcached などのカスタムグラフは追加していないでやらないとけないと思った。レスポンスタイムもかなり重要なので、僕が管理しているサービスのレスポンスタイムもグラフに出してみたいと思った。Subcon は便利そうだと思ったがまだ開発中っぽい。

次に web 2.0 expo での「Capacity Planning for Web Operations」の資料に目を通してみた。Slideshare でも同じ内容が公開されていた。

• あるクリスマスの Yahoo! トップページの爆発的なトラフィックのグラフが紹介されていた
• 同氏の来年何台のサーバが必要かについてファイナンス部と相談した
• どのくらいサーバ必要か判断するには、計測することが重要
• 前と同様に ganglia での Flickr でメール経由で1分あたりどのくらいの写真がアップロードされているかを示すグラフが公開されていた、グラフをみると1分あたりメールで40から50くらい写真がアップロードされていた！
• 写真がアップロードされてからの写真の処理枚数や処理時間（おそらくリサイズの処理だと思われる）のグラフが公開されていた
• ベンチマークをとって、上限を見つけることが重要、そのときにはできるだけ本番のデータを使うこと
• サーバごとにどの部分が重要か示されている、ロードバランサーは前後のネットワーク、ウェブサーバは CPU とメモリとディスク使用量と disk I/O
• ベンチマークツールとして、Siege、httperf/autobench、sysbenchが紹介されている
• 67台の CPU のコア数 2 のウェブサーバを 18台の 8 コアに交換したときのロードアベレージのグラフが公開されている、グラフをみるとロードアベレージが半分くらいまで下がっている！さらにさまざまな数字の比較も公開されていて、消費電力が 70% 削減されて、49U のラックスペースが開いたのこと！でかつ負荷も半分になったと！！！
• 最後に Flickr の数字が紹介されちえる、ピーク時で 1 秒あたり 32,000 枚の写真が保存されている！、1日あたり 6-8TB のディスクを使用する！、Yahoo! Photos から統合に 1 日あたり 34TB くらいのディスクを使っている、1日あたり 3M のアップロードがあって、ピーク時に 1 秒あたり 60 枚の写真のアップロードがある！

ここで紹介されたベンチマークが使ったことがないので試してみる。httperf や sysbench が便利そう。コア数の多い CPU にリプレイスする意味は充分になることが分かった。僕の管理しているサーバの CPU は、全部 4 コアなので、すでに稼働している 2 コアのサーバは半分の台数で 8 コアのサーバとして充分に置き換え可能なことが分かった。

最後に Velocity での「Capacity Management」の資料に目を通してみた。正確なタイトルは、Capacity Management for Web Operations。

• キャパシティとパフォーマンスは、別の意味
• ベンチマークをとて限界を見つけることの重要性を強調している
• MySQL のレプリケーション遅延のグラフ(mysql_slave_secs)を公開して、あるとき 50 秒くらいのレプリケーション遅延が行ったことで、データベースの上限を見つける例として紹介している、さらにそのときの disk iowait(diskio_iowait)のグラフを示して disk I/O wait が 40% くらいになるとレプリケーション遅延が発生しているとのこと
• ウェブサーバの CPU グラフを紹介て、85% くらいまでを安全な上限としてみるのがいいとのこと
• キャパシティ状態の数字が公開されいて、12,628 の nagios による死活監視、1314 台のホスト、6 つのデータセンター、4 つの farms（おそらく、flickr の写真の URL にある farmX.flickr.com の数）、farm は東西に二つのデータセンターがある
• Squid のリクエストで下限あるいは上限でアラートを設定している
• 写真の変換処理を行っていた DELL PowerEdge 860s を HP DL140 G3s に置き換えた（CPU のコア数は 4 から 8 にした）が、CPU の使用率は変わらなかったが1分あたり処理できる写真の数の上限が 45 から 140 にくらいなったというピーク時のグラフが紹介されている！
• そのときの数字として、サーバの台数が 23 台から 8 台、消費電力が三分の一、75% くらい高速化した、23U から 8U のラックでよくなった
• dshという複数台のサーバに同時にコマンドを実行するツールが紹介されている

これもかなりためになった。写真の加工などいわゆる CPU を使うサーバはコア数を倍にすると、なんと三分の一で済んでしまうことが分かった。CPU の使用率はそのまだけれど、パフォーマンスが向上することも分かった。

あと、さまざまなグラフを一つのツールで統合して、そのグラフからシステムのパフォーマンスの上限を見極める重要さを実感できた。

ということで、かなりためになるので、思い切って本を購入してみた。初めての技術洋書になるけれども、ゆっくりでもいいから頑張って読んでみようと思う。

Tags: flickr server