Hatena::ブログ(Diary)

kazuhoのメモ置き場

2009-12-26

ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない

タイトルは煽り入ってますが。

仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の2倍とする。

そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、

4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon

と、約5,000万PV/月を1台で捌けることになる。

CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は

4 core * 10 = 40

程度あればいいことになる。実際には、安全係数を2倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、

100 MB/conn * 80 conn = 8GB

程度のメモリがあればいいってことだから、ちゃんとメモリを積んでやれば CPU の前にメモリがサチるってことはない。

つまり、約5,000万PV/月くらいのサイトまでなら、アプリケーションサーバ1台で捌ける、という机上の計算が成り立つ。

API系のアクセスがどんどん増えていかない限り、アプリケーションサーバを複数台で構成する、ってのは、大規模なサービス以外では不要になるんだろうな、と思った。

2010/01/12追記: ↑は煽っているので、もっとマトモな説明は ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場

通りすがり通りすがり 2009/12/27 07:31 均等間隔のアクセスならね。実業務ではありえないでしょ。

kazuhookukazuhooku 2009/12/27 09:08 最大負荷が平均の何倍になるかは、サービスの種類によりますよね。

上の例では小さな2倍という値で読んでますが、このオーダーが変わって数十倍に上るようなサイトの場合どうするか。サーバ資源の9割以上が遊んじゃうようなゴージャスな運用をするんですか? それだったら Google AppEngine みたいな PaaS 使おうぜ、ってことになってくんじゃないすかね。

zicoxzicox 2009/12/27 09:31 ピーク時で見ておかないと厳しいでしょ。あと、障害対応として最低2台は無いとサービスが継続出来ない。

kazuhookukazuhooku 2009/12/27 10:02 zicoxさん、ありがとうございます。

本文でもピーク考えてますよ。あるいは2つめのコメントをご覧ください。可用性の観点から冗長性が必要というのは、もちろんおっしゃるとおりだと思います (が、論旨は規模感にあってHAの話ではないのでネグってます)。

oyktoykt 2009/12/27 10:32 「サーバ資源の9割以上が遊んじゃうようなゴージャスな運用」のための増分コストと、ピーク時のアクセスを捌ききれない事による機会損失を比較して判断した上で「ゴージャスな運用」が是か非か考えるんでしょうけどね。

kazuhookukazuhooku 2009/12/27 11:05 oyktさん、ありがとうございます。

繰り返しになりますが、ピークと平均ロードの差が大きいサービスの場合はクラウドって言うかユーティリティコンピューティングを使うことでコストパフォーマンスが高められるよね、という話が現実的になってきているわけで (EC2はDB層をピークロードで設計する必要があるけど)。

今後数年を考えたときに「ゴージャスな運用」が有効な選択肢でありつづけるのか気になります。

norinori 2009/12/27 14:57 その分、ゴージャスなコンテンツがうまれるでしょうね。1ユーザー1CPUぐらいのとか。

doubletopdoubletop 2009/12/28 13:32 NIC性能をもっと考慮しないと駄目では?
MMORPG系のサーバー構成は大量リクエストを処理する為にNICのI/Oがボトルネックになるので横並びが基本です。
実際の通信ピークはCPUリソースだけで語るのには無理ありますよー

kazuhookukazuhooku 2009/12/28 13:59 doubletopさん、ウェブアプリケーションサーバではNICがボトルネックになることは少ないと思います (例えば写真や動画をアプリケーションサーバから送出していれば別かもしれませんが、そういった処理を委譲するための技術は色々あるので)。

たとえば、上の計算例においてコンテンツの平均サイズを100KBとすると、平均ビットレートは32Mbpsです。

nippondanjinippondanji 2010/01/12 16:49 Mixiのトップページ(ログイン後)をロードすると2MB以上ある件。Mixiは画像が多いからでしょうかね?画像ならばアプリケーションサーバーの負荷としてはカウントしなくて良いかも知れませんが、AJAXによるデータ転送も結構データ量の増加に貢献しているような気がします。モノによってはネットワークの負荷はもうちょっと多めに見積もった方が良いかも知れません。

kazuhookukazuhooku 2010/01/12 22:59 nippondanjiさん、ありがとうございます。

一般論としては賛成ですが、ここで見積もっているような <100 reqs./sec. クラスのアプリケーションサーバでネットワーク負荷が問題になることはないと思います。

そんな非効率なアプリケーション書くなよ、という気もするんですが、それくらいの重さでも1台に収まるケースがどんどん増えてきているんだと思います。

nippondanjinippondanji 2010/01/13 09:31 確かに多少非効率でも一台でなんとかなるケースが増えそうですね。そりゃあ箱屋が潰れるわけですw

ayatoyayatoy 2010/01/17 18:40 江島さんの記事と合わせて読んだのですが、凄く勉強になりました。ありがとうございます。

通りすがり通りすがり 2010/03/07 18:50 >API系のアクセスがどんどん増えていかない限り、アプリケーションサーバを複数台で構成する、ってのは、大規模なサービス以外では不要になるんだろうな、と思った。

条件が限定的すぎ。
むしろ、冗長性や可用性が要求されないサービスでWeb/APサーバ複数台構成をとるのか?

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証