夜中に突然サービスの負荷が3倍になっても飛び起きなくても済むにはどうすればいいのか談義

GETはキャッシュで対処。POST系のリクエストが増えたらどうすればいいいんでしょう。
28
Sadayuki Furuhashi @frsyuki

SlashdottedとYahooスパイクとか、ブログだと炎上とか、アクセス数が突然急増することはあると思うのだけども、急増したのだけども、こういうケースに対応できるインフラを組むために必要なことは何なのだろうか。

2013-09-21 04:44:26
Sadayuki Furuhashi @frsyuki

負荷の揺らぎを平滑化するのにキューはかなり便利で、監視もしやすい。キューが伸び始めたらマズイのでサーバを足すという運用も分かりやすい。でも伸び始めたらすぐに足さないとマズイから、夜中に起きないといけなくなると思うのだけども、それは防げるんだろうかなぁ。

2013-09-21 04:46:17
Sadayuki Furuhashi @frsyuki

サーバのオートスケールというか自動的な追加って、みんなやってるのかな。

2013-09-21 04:48:27
Sadayuki Furuhashi @frsyuki

30秒くらいでに負荷が一気に3倍になっても夜中に起きないで済む技術。

2013-09-21 04:53:25
MtK @kenei_mtk

@frsyuki いわゆるspikeなトラフィックには、オートスケールとかでは対応できないですね。30秒で一気に3倍だとまず間に合わない。

2013-09-21 04:57:42
Sadayuki Furuhashi @frsyuki

@tagomoris サーバの自動的な追加ってやってます?

2013-09-21 05:02:26
MtK @kenei_mtk

@frsyuki で、HTTPに限って言えば、エッジ キャッシングのプロダクトとそのチューニング方法がそこそここなれているので、spikeなやつにはキャッシュされた静的なファイルをじゃんじゃか返す。

2013-09-21 05:02:52
Sadayuki Furuhashi @frsyuki

静的ファイルを返すとかでなくて、写真をアップロードされた後にサムネイルを作る的な作業の部分の負荷だと、多少遅れてもいいから30秒で3倍になっても大惨事にはならないのだけども、とは言えサーバを足さないことにはキューに入ってくる速度をさばけない

2013-09-21 05:05:01
MtK @kenei_mtk

@frsyuki で、動的サイトなんかも、裏側すべてRESTful にしとけは、エッジキャッシュの技術で、裏側のAPIの返答をまるっとキャッシュする。TTL30秒とかキャッシュするだけでも、負荷がかなり違う。BtoCとかだとそんくらいのタイムラグは許されるし。

2013-09-21 05:06:57
Sadayuki Furuhashi @frsyuki

@kenei_mtk なるほど。キャッシュが入っているとスケーラビリティは増しますね。POSTとか、データを変更する類のAPIだったらどうします? そもそもリミッターをかける?

2013-09-21 05:07:32
MtK @kenei_mtk

@frsyuki あるところで、POSTがyahoodされた例があるけど、そこはすぐに取り出さなくてもいいところだったので、とりあえずQUEですね。POSTしたデータは、本人にはすぐ表示、他の人には順次タイムラグさせてもOKかと(BtoCというかSNS系特有かもしれませんが)

2013-09-21 05:12:53
MtK @kenei_mtk

@frsyuki 自分以外は、わざと遅延させるというのは、割とやってる気がしますね。

2013-09-21 05:14:21
Sadayuki Furuhashi @frsyuki

@kenei_mtk ふむ、なるほど。とりあえずキューに突っ込みますよね。ただキューに対する挿入速度が3倍になると、キューの処理速度が追いつかなくってキューが伸び続ける状況になり、ラグがだんだん増えていく状況になると思いますが、

2013-09-21 05:14:31
Sadayuki Furuhashi @frsyuki

@kenei_mtk ラグが大きくても良いタスクと、小さくないとマズイタスクを分けた、優先順位付きキューを作る感じなんですかね。そうすれば夜中に起きなくても翌朝対応でも大丈夫…? 3倍だとツライ気がしないでも無いですね…

2013-09-21 05:15:33
Sadayuki Furuhashi @frsyuki

@kenei_mtk と言うのも、ラグが小さくないとマズイタスク(例えば本人に表示するための方)の処理速度も追いつかなくなって、おそらく5時間もするとラグが30分とかになると思うので…

2013-09-21 05:17:29
Sadayuki Furuhashi @frsyuki

優先順位付きのキューにするのは良いアイディアかもしれない。

2013-09-21 05:18:48
Sadayuki Furuhashi @frsyuki

workerの挙動としては、優先キューにタスクがない場合にのみ、他方のキューを処理する。これはいいな。スケーラビリティは変わらないけども、一気に3倍というようなイレギュラーなケースが非優先キューで起こった場合に、優先キューに影響を与えないメリットがある。

2013-09-21 05:20:09
Sadayuki Furuhashi @frsyuki

そして優先キューの方に問題が起こるんだろうなー。その場合は影響範囲の切り分けが必要か。キュー自体をユーザーIDで分割する感じ。キュー1で性能問題が起こっても、キュー2に割り振られるユーザーには影響が出ない。ただコレをやるとスケーラビリティは落ちる。

2013-09-21 05:21:42
Sadayuki Furuhashi @frsyuki

キュー2のworkerがヒマしていてもキュー1のヘルプができないから。ただ問題発生時の対応は若干楽になるかな。キュー2のworkerをキュー1の処理に切り替えるのは、おそらく新しいサーバを追加するよりも迅速にできる。

2013-09-21 05:23:05
MtK @kenei_mtk

@frsyuki どういったシステムにによって、やり方はいろいろかと。 金にモノを言わせて、CPU50%使用率以上になったら、つねに増強するという方針で凌ぐ場合もありで、そうすると2倍までのキャパシティが埋まる前にautoscaleが間に合う時間をつくれたり。

2013-09-21 05:23:42
Sadayuki Furuhashi @frsyuki

@kenei_mtk それ結構現実的ですよね。スケーラブルな仕組みを作り込むコストよりも安い!という判断で。

2013-09-21 05:24:31
MtK @kenei_mtk

@frsyuki 実際、某レシピサイトはそうなってるはずw

2013-09-21 05:24:56
MtK @kenei_mtk

@frsyuki 結局は、ぎりぎりで運用するな!は、鉄則かと思います。AKB砲とか、Pefume砲とか打たれてる身からすると:-p

2013-09-21 05:28:23
Sadayuki Furuhashi @frsyuki

@kenei_mtk なるほど。マージンを増やすほどコストがかさむわけですが、そうすると突然3倍というのは厳しい。残る手段は、スパイクを検出したらサーバを自動的に追加するか、レアケースだから夜中に起きて人手で足すかの方法しか思いつかないのですが、ここは皆さん後者なんですかね。

2013-09-21 05:29:59
最速配信研究会山崎大輔 制約理論及び待ち行列理論による技術経営コンサルとエンジニア起業相談やってます @yamaz

ヤフー砲は明らかに人災で、かつ技術的には100%いつくるか事前把握可能なので、ヤフートピック担当者は事前通知システムを提供すべき。

2013-09-21 06:22:19