2010年1月アーカイブ

もっと詳しい方のフォロー募集です

アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。

memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。

$ memcached-tool localhost stats|grep threads
threads           4

スレッドが4つで起動しています。

負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23)

Tasks:  77 total,   1 running,  76 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  3.0%us,  5.7%sy,  0.0%ni, 75.3%id,  0.0%wa,  7.7%hi,  8.3%si,  0.0%st
Cpu2  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                            
3692 nobody    20   0 10.9g  10g  716 S   10 44.0  10253:09 memcached

＊メモリの行は削除しています。

CPUは4つ認識されていますが、CPU1しか使用されていないのがわかると思います。おそらく、CPU1のアイドルがなくなった時点で他のCPUに空きがあってもそれ以上の処理ができなくなります。なぜCPU1しか使われないかは「/proc/interrupts」をみるとなんとなくわかります。NICはBroadcom BCM5722です。

$ cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3 
  0:      10569          0      10460          0   IO-APIC-edge      timer
 16:        301        301        302     303161   IO-APIC-fasteoi   aerdrv, aerdrv, aerdrv, ioc0, eth0
 17:          8 3570118309          7          7   IO-APIC-fasteoi   eth1

memcachedの通信は主にeth1で行われるのですが、このeth1に関する割り込み処理がCPU1でしか行われていません。ソフトウェア割り込みはハードウェア割り込みが行われたCPUでしか行われないのもこの傾向を強めます。

マルチコアCPUの性能を活かすために考えられることは、ネットワークの割り込み処理を複数のCPUに分散することだと思うのですが、最新のNICにはRX/TX Multiple Queue(正式名称がわからない。Receive Side ScalingとかScalable I/O？)機能が備わっています。もともとRX/TX Multiple Queueは10GbpsのNICなどに備わっていた機能で、複数の割り込みチャンネルを持つことでネットワーク処理の分散を実現しています。最近のIntelやBroadcomの1GbpsのNICにも同じ機能があります。

以下はBroadcomのBCM5709を搭載しているマシンのinterrupts。(CentOS 5.3)

           CPU0       CPU1       CPU2 ..  CPUy      CPUz
  0:  342688765          0          0         0          0    IO-APIC-edge  timer
114:         55         34      19613     39212         11       PCI-MSI-X  eth0
122:         23          0        145       193          0       PCI-MSI-X  eth0
130:        243          0         75       138          0       PCI-MSI-X  eth0
138:         24         12      10423     35836          6       PCI-MSI-X  eth0
146:       2141          0        110       556          0       PCI-MSI-X  eth0
154:         21          4      12802     17806          7       PCI-MSI-X  eth0
162:        561          0        216        72          0       PCI-MSI-X  eth0
186:         72         76      97076    137548     197952       PCI-MSI-X  eth1
194:         24      45478     100337    140189     554148       PCI-MSI-X  eth1
202:         24     527452      94677     87876     305476       PCI-MSI-X  eth1
210:         23     220400     175792     56390     205521       PCI-MSI-X  eth1
218:         24      37023      30778      6169      11788       PCI-MSI-X  eth1
226:         21     349792      48599     91969          0       PCI-MSI-X  eth1
234:         23     206063       5911     43536          4       PCI-MSI-X  eth1

＊加工済み

こんな感じで、割り込み処理用のチャンネルが複数個存在して、CPU間で分散ができています。

まとめると、マルチコアCPU、SSDの普及によってハードウェアの性能があがり、epoll/kqueue/event portsによって大量のコネクションをさばけるようになると、こういった複数のCPUに分散できない処理がボトルネックになってくるので、最新のハードウェアとか対応しているカーネルを利用しようということです。

WEB+DB PRESS Vol.51の連載で、サーバRFPを設定してそれに基づいて購入していると書きましたが、来年度(2010年度)ぐらいのRFPになりそうな主流となるサーバを考えてみました。

まず、共通していること、前提など

• CPUのコア数はHTなどによる論理コア含む計算
• ネットワークインターフェイスは1Gbpsを2つ以上。RX/TX MultiQueueをサポートしていること
• SSDはIntel X25-M 160GBもしくは同等製品

サーバは主に4タイプあります。

■Utility Server

小規模DB、Q4MやGearmanなどのJobQueue/Workerサーバ、memcachedやSquid/Varnishなどのキャッシュサーバに利用するサーバ。目的に応じてHDDをSSDに換装して利用できることが必要となります。

• CPU 8コア以上 * 1
• Memory 16GB
• HDD SAS 15krpm 146GB
• SSDに換装可能

■Application Server

アプリケーションサーバやリバースプロキシーに使う。おそらく最もCPU(ユーザ)の負荷が高い。性能の高く、コア数が多いCPUでぶん回して全体のサーバ台数は減らしたい。

• CPU 8コア以上 * 2
• Memory 16GB
• HDD SAS 15krpm 300GB

■High Memory DB

中負荷〜高負荷DBとして利用。SSDについて入れ替えではなく追加としてしているのはデータベースのデータ部分をSSD、バイナリログをHDDとそれぞれの特性に応じて使い分けるためになります。メモリについては後述します。

• CPU 6コア以上 * 2
• Memory 48〜64GB
• HDD SAS 15krpm 146GB
• SSDを追加可能

■Large Data DB

メモリにすべてのデータが乗り切らないデータ蓄積型、大規模なDB用。

• CPU 6コア以上 * 2
• Memory 48〜64GB
• HDD SAS 15krpm 300GB * 6本以上
• RAID5

48〜64GBとしたメモリに関して、64GBを積むためには1本8GBのものを買わないとならなく、4GBと比べると3倍程度するのが悩みどころ。メモリの値段は上がってきている中で8GBの値下がりするのか注目。また、今年の後半(前半？)には、Westmere-EPが出て、6コア/12スレッドになるので、また少し状況が変る可能性がありますね。こちらも注目

奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。

奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。

ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。

• The Art of モバゲー Capacity Planning
• The Art of Mixi-mobile-appli Capacity Planning

最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖い

1,000万PV/Dayとなると、ピークのリクエスト数が平均の2倍として秒間に230リクエストとなります。

( 10,000,000 pv / 86400 sec/day ) * 2 = 231.481481

奥一穂さんの試算であれば、クアッドコアのサーバで秒間40回の処理が可能なので、6台程度のアプリケーションサーバがあれば、1日1,000万PV、月に3億PVがさばけることになります。冗長性や安全をとるためにサーバを増やしたり、またクアッドコアを2つ搭載するマシンを採用することも考えられますが、この数字は自分の経験と比べても大きなずれはない数字です。

さて、ここからが本題で、1,000万PV/Day（秒間230 req/sec)には何台のデータベースが必要となるのでしょうか。Shardingを行ってデータベースの分散を行い多くのデータベースサーバを運用する必要があるのでしょうか。

1リクエストにつき、SQLを8回発行した場合、秒間のクエリー数の最大は1840query/sec

230 req/sec * 8 = 1840 query/sec

このうち、5%程度が更新系のクエリーだったとしたら、更新系クエリは92 query/secとなり、

1840 query/sec * 0.05 = 92 query/sec

残りが参照クエリとなり、1748 query/secとなります。1リクエストあたりのSQL数や更新回数はアプリケーションにより大きく変動しますが、この程度のクエリー数の場合、MySQLであれば1台で処理することは可能です。冗長性やバックアップのためのSLAVEサーバも追加して1組2台あれば安定稼働できます。

多くのSQLをさばくためには、クアッドコア以上のCPUや十分なメモリー、最適なデータベースサーバの設定や、効率のよいスキーマとSQLの設計が必要です。Blogサービス等でなければデータをあまり蓄積しないのも重要です。MySQLであれば次の書籍が非常に参考になります。

もし、アプリケーションがもっと多くのクエリーを発行していたり、負荷が大きな場合には、安くなったSSDを使ったり、SLAVEサーバを追加して参照クエリーを分散を行ったり、memcachedを利用して参照クエリを減らしたり、また、更新が多いテーブルだけを別のMySQLサーバに移動したり、データが単純なkey-valueであればTokyo TyrantやRedisなどを利用すれば、データベースサーバを最小限にとどめることができます。

2010年代は手軽に購入できるようになった高性能なハードウェアでスケールアップし、OSやミドルウェアのチューニングを行うことで、アプリケーションサーバ、データベースサーバを最小限に食い止め、サービスの収益率を改善してお給料を増やしてもらうのがよいのだろうと思う。

あけおめ！ことよろ！今年は耐えた感じです！

プライベートでは、昨年は子供が生まれ生活ががらりと変わった一年でした。仕事の方に目を向けると、前回に続いてのYAPC::Asiaでの発表、mixiアプリの開始による変化への対応、また、技術評論社様のWEB+DB PRESSで連載をさせて頂くなど新しいチャレンジもできました。

今年は息子が保育園に入る予定があるなどなどまだまだ激動は続きそう。そして6月には0x20歳。仕事も去年の激動の余波が残っていますが、2011年、2012年と何を目指すのかも自分なりに考えていたいなぁと思っています。

ってことで今年もよろしくお願いします。