Webサイトへのアクセスの予測 106
ストーリー by wakatono
リロードがさらに拍車をかける 部門より
リロードがさらに拍車をかける 部門より
mpls 曰く、 "今、キリンの生茶を買うと、インターネット限定で生茶パンダをプレゼントして
くれるというサイトへのアクセスコードがついてきます。
実はこのサイト、この二、三日稼動していません。
予想を上回るアクセスがあったため、と説明していますが、この「予想」ってなんなんでしょうね？
/.J を読んでいる方にも、Webサイトの構築をされている方がおられると思いますが、どのような「予想」を元に回線やサーバの性能を決めていますか？"
過去には Playstation.comが、現在もまさに生茶のサイト以外にも電子国土ポータルがこの状態だ。最近は予測以外にも「必要に応じた」リソースの動的追加という手段もとられているが、サービス提供側もそうしなければならない状態になったら「よもやこんなとは…」と感じることはあるだろう。実際どうすればいいのだろうか…
これは成功例 (スコア:4, 参考になる)
>どのような「予想」を元に回線やサーバの性能を決めていますか？
正直、掛け算ですね。もちろん、経験からくる数字をかけますが。
具体的な数字はあげられないけど、予想10万人で100Mbps x 3、
サーバ3台をロードバランシングとか。（数字はあえてテキトーです）
ところで、この生茶って失敗例じゃなくて、成功例だと思いますよ。
回線の充分（ネットワークは問題なく繋がってる）だし、
アプリも、にっちもさっちもいかなくなる前に「混んでます」画面出すし。
アクセスしてみるとわけるけど、ユーザ登録画面は結構待ちがなく進むのですよ。
つまり、マーケティングはかなりの高得点で成功しているわけ。
とまあ、そこまでわかっておきながら、パンダ欲しさに罠にはまる俺。
Re:これは成功例 (スコア:1)
どうやって10万人を予想したかが知りたいのです。企業秘密でしょうか？(^^；
というか、そこのところの予想がこのストーリーの肝なんじゃないかと思ったり。
予想アクセス数 (スコア:3, 興味深い)
これが一番予算も出やすくて妥当なところだと思うんですが、
もちろん客の理想以上にアクセスが有ることもあるでしょう。
そんな時のために、
「理想以上のアクセスがあったら止まっちゃうかもしれませんが、
目標達成するわけですから御の字でしょう。そうなってから考えましょう。」
と笑顔で打ち合わせして、見積もりにも表記しときます。
＃絶対こんなサイト、アクセスこねーよ。客は１０万アクセスって言ってるけど、
＃５万くらいで考えとこう、ということもある、か・・・な？
Re:予想アクセス数＠ウチの場合 (スコア:2, 参考になる)
お客さんが予想アクセス数を持ってきた時には、それに耐えうる構築をします。
方法はロードバランシングに然り、サーバー自体のパフォーマンスモニタリングに然り。
勿論帯域チェックやらパケットキャプチャ型アクセス解析ソフトによる過去の履歴から算出します。
ただ、あまりにもアレなところもありますね。
予想される規模のでかさをわかってないまま、こちらに構築依頼をされたりとか。
もしくは仕組みを分かってないまま、お客さん自身が適当な機械を馴れ合い会社から
購入しちゃって「これで組んで」みたいなパターン。
ストリーミングサーバー用意してても、そこに接続するための認証サーバーが1機とか。
WebはLBされてるのに、DBがクラスタリングされてないとか。
完全二重化といいながら、上位のルートが1本とか。
でも最後にはお金ですよね。。
Re:予想アクセス数 (スコア:1, 興味深い)
WEBの負荷の見積りって、 明らかに少ない場合は「月間」とかで考えても 「あ、余裕あるな」で終わっちゃうけれど、 それなりの負荷がかかる場合、 当然ピークタイムで予想しないといけないよね。
特に、キャンペーンとかメールマガジンからくるとか、 ピークタイムに特殊なパターンがある場合。
厳密にやる場合：
1時間あたりの最大ページビュー数予想して、
1秒あたりのヒット数になおして負荷計算。
でやってるけど、それでいいの？ 教えてエライ人。
Re:予想アクセス数 (スコア:2, 参考になる)
>1時間あたりの最大ページビュー数予想して、
>1秒あたりのヒット数になおして負荷計算。
>
>でやってるけど、それでいいの？ 教えてエライ人。
最終的には「実際のアクセスに耐えられることを望む」システム
のオーナーさんと、「実際に予測を打ち立てる」ところと、その
予測をまっとうするシステムインテグレータとかがあるわけなん
ですが、そのまんなかの「予測を出して保証する」といったこと
がないのが、問題だと思うんですよ。
# 絶対安全圏みたいなことでむちゃくちゃな見積が出てきたり、
# リソース不足でふっとぶちゃちな見積がでてきたり...
自社製品の社外向け販売WebPageを作った時、危機的状況になって
調べてみて、ことの他、社員からのアクセスが多かったりする。
で、社内に対して「社員さんとかは、社員向けのページを使って
ちょうだいな」ってなアナウンスをしたりするわけです。敵はど
こにいるかわかったもんでもない...(^^,,
実はボクも… (スコア:2, 興味深い)
こんなのじゃきっと誰もエントリーすらできないんだろうなと思っているとそうでもないみたい。 [yahoo.co.jp]
ま、そんなことはどうでもいいが生茶の前回のキャンペーンが期間にある程度の余裕があった（？）のに対し、今回は１ヶ月ほど。さらにリプトン、サントリーも同じような（同じなんだろうけど）14桁のシリアルナンバーでエントリーするキャンペーンを行ってこの方法の認知度が上がったこと、でもって、当選品（以外も）
が結構な高値で売買 [yahoo.co.jp]されてることに気づいて応募者殺到って感じですね。
さらに付け加えるなら「おしりを噛んでほしい」人、多数なのかも。
＃ボクはパペットマペットのまねがしたいだけです。
売却するなら (スコア:1)
>が結構な高値で売買 [yahoo.co.jp]されてることに気づいて応募者殺到って感じですね。
オフトピですが
売却するのであれば賞品 [yahoo.co.jp]よりも
応募シール [yahoo.co.jp]のほうが割が良いような気がします。
当選確率にもよるのだろうけど
そりゃ当然 (スコア:2, 興味深い)
提示された予算の中で入手できる分だけ。
いや、マジで「〇〇円で作って」ってで、「予測される負荷」から金額を積み上げていないものばっか。
(そう言えば最近も厚生省が作った「過労チェック」なるものを外郭団体のWEBで公開したらアクセスが集中してサーバーが過労でダウン、なんてのがありましたなあ)
釘は刺さなくても平気か？ (スコア:1, すばらしい洞察)
これ自体はまっとうなんだけどさ。
下にもあるけど、具体的な限度を積算書や契約書に明記しておかないと責任の所在が不明確になって、後々トラブルに繋がるぞ。
Re:釘は刺さなくても平気か？ (スコア:2, 興味深い)
分間何千件のアクセスを受け付けて、受注を分間何件受け付けるか？とか、
結構具体的に取り決めしていたりするのですが、それでも客が後になって
「あれ変えられないか？もっとアクセスあるかもしれないだろ」とか言い出
してもめるケースもあったりしますね。釘を刺しても、相手は釘に思わない
ケースもあったりして、トラブルはなかなか...
そもそも、コンテンツやらコンテンツへの希求といった社会的状況を調べも
せずに、アクセス件数を予測してシステムを構築するってことが元でトラブル
を招くケースもあるわけなんですよ。
# コンピュータ側に余裕はあったけど、ロードバランサーがこけたってのも
# あったりするわけで...
サーバ・クライアントのアクセス速度の対称性 (スコア:2, すばらしい洞察)
今までの常識で考えると、サーバ側には大容量の回線を用意し、多数の(ナローバンドな)クライアントからのリクエストに耐えるという設計にするのでしょうけど、実際のインターネットはそうではなくなってきてると。
それを解決するのが P2P ネットワークだと思うんだけどなぁ。なんだか、きな臭い話しか聞こえてきませんね。P2P技術が悪いんじゃなくて、その有名な応用例が問題視されてるわけですが……。根底を支えるP2P技術の研究・開発も一緒につぶされると困ります。
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:2, 興味深い)
現状ってのは、コンピュータの、というかＰＣの爆発的な性能向上で、
あり余る処理能力を持って肥満しまくった飢鬼ども(クライアント)が
相対的にはるかに貧弱なバックボーン回線に群がって
一生懸命甘い汁を吸ってるモデルだから、
回線の能力を増やしていってもクライアント側は問題なくついてきてしまう。
よって、みんな寄ってたかってサーバの処理能力を喰い潰していって、
とんでもないことになるわけだ。
本来なら、サーバで処理すべき処理能力の一部を
これらパワーのあり余ったクライアントに効果的に分散すれば、
現状の回線能力でも、かなりの帯域圧縮効果があると思うんだけど、
詰まる所、やっぱセキュリティがね…。
基本的にP2Pは送信能力を負荷分散するテクノロジだけど、
本来ならグリッドコンピューティングの要素も採り入れて、
サーバが集中してやってる処理そのものも、分散すべきなんだ。
本来ならJavaがそういう言語として設計されたはずなのだけど、
その能力は十分に活かされていると言い難いのが残念だな。
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1, 参考になる)
また、Webアプリなんかだと、P2Pに向かないように思えますが、そこいらはいかがでしょうか？
・データのトランザクションはどう保障し、分散効果はどのくらい出ますか？
・アプリのアルゴリズムの同一性をどのように保障しますか？
・データの盗聴対策は？
くらいは考えないと、電波に見えてしまいますよ^^;;
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1)
おっと失礼。よくよく考えてみたら、この件では特に
・クライアントからアクセスコードを入力(数十バイト?)
・サーバから結果を返答
というシステムだから、データ量だけ考えると、実は大したことなさそう。見積もるべき(思案すべき)はデータ転送量ではなく、むしろページビューによるサーバ側負荷だったのか。
>・データのトランザクションはどう保障し、分散効果はどのくらい出ますか？
>・アプリのアルゴリズムの同一性をどのように保障しますか？
>・データの盗聴対策は？
P2P技術が進歩し、こういう問題点を考えねばならなくなるような時代がくることを切に願うばかりです。
# ……で、その問題点の解決策については、
# 当方あいにく持ち合わせておりません。教えてエライ人。
Re:サーバ・クライアントのアクセス速度の対称性 (スコア:1, 参考になる)
はやくWebのセッションを開放してくれるからありがたいことが多いな。
Webサーバのプロセス数は有限のリソースですからねぇ。。
#ストリーム系は話が別でしょうね。
どこの負荷かなぁ (スコア:2, 興味深い)
テスト用の環境をいくら用意してても、ロードバランサなどのネットワーク構成、サーバ性能、OSの設定値とかが違っていれば全然当てにならないわけです。MaxConnectionCount数をApacheとTOMCATでそれぞれどう設定するか～みたいな微妙な問題もあるとききますし。
＃実際のところStrutsとかVelocityの負荷もよく分からんのよね
最初に見切り発車したら、負荷の少ない深夜帯に負荷テストを『本番環境で』実施する羽目になるわけです（苦笑
結論：サイトが死にかかってようやく意識する
---- 何ぃ！ザシャー
Re:どこの負荷かなぁ (スコア:1)
＞それは「テスト環境」ではありません。
はげしく理想論！でも涙とともに同意！
さらに、上記についてまったく同じ構成でものを作ってたとしても、それをどう外のネットワークとつなげるかという点で必ずしも同一条件にできない、という問題が。
手っ取り早く言うと、テスト系は外から見えるようにはできないということね。あとはそれにコスト問題がからんできて、本番系はデータセンターに置くけどテスト系は社内LANにつなぐとか（当然負荷テストなんかもイントラ内からしかできん）、コストといえばひどい場合は本番系では別々の、DBサーバとアプリサーバをいっしょにしたテスト系とか。あと他システムと共通の課金システムに課金データを送信するような設計の場合は、原則テスト系から課金を発生させてはならないとかね。だが、
＞＞ロードバランサなどのネットワーク構成、サーバ性能、OSの設定値とかが違っていれば
＞それは「テスト環境」ではありません。
とは、そういったこと抜きにしても声を大にして言いたいセリフであるなあ。
Re:どこの負荷かなぁ (スコア:1)
ん、なんじゃこりゃ、途中からネットワーク構成とは関係無い話になっているじゃないか。支離滅裂ですみません。
Re:どこの負荷かなぁ (スコア:1)
＞＞それは「テスト環境」ではありません。
＞とは、そういったこと抜きにしても声を大にして言いたいセリフであるなあ。
こっちも非常に言いたいんですよ（苦笑
takmakiさんも仰ってますが、ネットワーク的に（具体的に言うとIPAddressやルーティングが）再現できないのです。
＃社内ＬＡＮからはINET経由じゃなく社内proxy経由で接続されてたりするのがさらに厄介かと
サービスごとに異なる各開発会社にデータセンターの構成を全て再現させる、なんてのは理想論じゃ片付かないのでしてね・・・（完璧なstabが作れれば別ですがそんなこと現実的じゃないでしょ）
まぁ、OSの設定値やサーバ性能などというのは愚問でしたね。反省。
---- 何ぃ！ザシャー
playstation.comの場合。 (スコア:2, 興味深い)
システムの一部がダウン。その後手直しをして再度スタートしたが、ピーク時は1分間に
40～50万ヒットを記録しており、これまでにない記録的なこととなった」だそうで。
http://pc.watch.impress.co.jp/docs/article/20000218/ps2_2.htm
ブロードバンドが高嶺の花だった当時、これだけのアクセスを予測することは無理だった
んではないでしょうか。
ソースが見つからないんですが、IBMの人もこれ以上のものは作れなかったらしいです。
サーバー増強したのはそれからずっと後の事。
…まぁトップページのFlashが500KBもあったのが原因という話もありますが。:-P
Re:playstation.comの場合。 (スコア:1)
わたしがアクセスしてみたときは、画像の request だけがいきなりコケてました。画像だけ一回 reload を試みたらすぐ表示されましたけど。
根気よく (スコア:1)
（もっとも、その所為で負荷かかってんだろうけど）
3回やって、3回ともはずれた。パンダ欲しいわぁ。
で、ゲーム中にもタイムアウトしたりするけど、
次にアクセスしてもセッションがちゃんと残ってる。
逆に怖いけどね。
May the source be with you... always.
Re:根気よく (スコア:2)
間違っている様に思うんですけどね。不精・お手軽
ちゃっちゃとでけへんと、客は離れていっちゃうみ
たいですよ。いくつか例外はありますが、コンテンツ
の良さやユニークさでそういったアクセス不良を招い
ていても客がくるサイトもありますが、他に類例があ
れば、そっちに客が逃げちゃうね。
今回みたいに「ここでなければ出来ない」ってことで
酷いことになるケースもあるし、「他でできないのだ
から我慢してろ」ってな傲慢な態度だと、その商品に
対しての購入意欲を失わせてしまって、最終的には損失
になると思いますが...
Re:根気よく (スコア:1, おもしろおかしい)
散歩でもしてこよう。
Re:根気よく (スコア:2, おもしろおかしい)
「並んでまで見るサイトじゃなかった。」
Re:根気よく (スコア:1)
Re:例えば(Re:根気よく) (スコア:1)
どうせなら整理券もらったら後は自動で……とか考えるわけですが、
普通の人が端末あげっぱなしってのも少ないだろうし、
勝手に電源入って動いたらそれもヤダなーと思う人もいるだろうし、
なかなか上手い解がないような気がします。
HTTPでない手法を作った方がいいような気もしますけどねぇ。
どうなんだろう。
本当かい♪本当かい♪
Re:例えば(Re:根気よく) (スコア:1)
「今日のhogefugaページはIPアドレス末尾が偶数の方、偶数の方のみアクセスいただけます……」
# 電話ではよくあった手法ですが、ダメですかね
Re:例えば(Re:根気よく) (スコア:1)
# これこそ根気ですね。数打ちゃ当たる。
main(){printf("Hello World\n");}
Re:例えば(Re:根気よく) (スコア:1)
有効期限はあるだろうけど、有効開始時刻も指定出来れば良さそう。
まぁ、整理券配り自体が忙しかったり、整理券持ってないのに何回も来る人がいたり、挙句の果てには係員ともめて(略
実効性はともかく、楽しそうではある。
# Kerberosは横で見てただけなのでよく知らない。
Re:例えば(Re:根気よく) (スコア:1)
Kerberos(V5)には先の日付から有効になるチケット(現在はinvalid) [ipa.go.jp]というのは存在しますですよ。
# 某アニメが流行る前から「ケロちゃん」と呼んでた
Re:例えば(Re:根気よく) (スコア:1)
自分がよく知らない物を引き合いに出してはいけませんね(^^;
Re:例えば(Re:根気よく) (スコア:1, 参考になる)
これって根気か？ (スコア:1)
同じアクセスコード方式のキリンの缶コーヒー『ファイア』
のサイトで5回やって、3回当選しました。
なんでしょうね。これって運じゃないですか？
PCにECC Registeredメモリの利用を推奨します。
本当にアクセス数なのかな？ という疑い (スコア:1, 興味深い)
中身を見たことがあるのですが…アルゴリズムがアレすぎて仕様とは
違う結果をたたき出したり、有名な方法でクラッキングが出来たりと、
ひどい物でした。
また、この生茶のサイトに関して、少なくともDNSレベルでは、負荷を
分散しようとしている形跡は見えません。
そんなわけで、本当にこれ、サーバ過負荷での話しなのか、少し疑いの
目を持って見てるのですが…どうなのでしょうね。
これに対して、cyberjapanの方はDNSレベルから負荷を分散しようと
しているので、裏のつくりはともかくも、少なくとも、本当に過負荷
っぽいぞっということはわかりますね。
…まぁ当然ですか（笑
Re:本当にアクセス数なのかな？ という疑い (スコア:1, 参考になる)
出来なくなる人が出てくるのが恐いんですよね。
というわけでDNSでは分散せず箱モノのロードバランサを
入れてやるところが殆どだと思いますよ。
Re:本当にアクセス数なのかな？ という疑い (スコア:1, 参考になる)
例えば、サーバがAとBの2台あるとして、
ロードバランサーならお互いの負荷を均等にできるけど、
DNSだとラウンドロビンで交互に割り振られるだけなので、
遅いクライアントが片方に集中してぶらさがったりすると、
結果として全体のパフォーマンスがガタガタになったりする。
つまり、パフォーマンスの見積もりができない。
本当に高負荷なシステムにはDNSラウンドロビンは使いませんね。
ロードバランサーはだてに高いわけじゃないんですよ。
もしDNSラウンドロビンを安易に提案してくるベンダがあったらかなりヤヴァイかと。
DNSに頼るのは本当にしょうもないor身内しか使わないようなシステムか、
本当に予算がない時だけですね。
Re:本当にアクセス数なのかな？ という疑い (スコア:1, 参考になる)
やめた直接の原因はトラフィック増えてロードバランサが過負荷になったためですが、よりパフォーマンスの高いロードバランサに買い換えるぐらいなら、その金でサーバ増やして処理量自体を増やしてDNSラウンドロビンにした方がマシという結論になりました。
サーバ増やして処理量が増えれば、多少のアンバランスは問題無いですし、Xeon×2のサーバが何台も買えるような金出してロードバランサを入れても、結局処理量は増えないで、100%（に近く）処理できるようになるだけですから。
＞もしDNSラウンドロビンを安易に提案してくるベンダがあったらかなりヤヴァイかと。
むしろ、安易にロードバランサを提案してくるベンダの方がヤヴァイですよ。
単に単価が高いもの売りたいだけっていうような場合もあります。
実際、ロードバランサを入れながらコケたサイトとかの情報を聞くと、サーバがコケるより前にロードバランサがコケたとかのマヌケな話も良く聞くし。
私としてはロードバランサの（コストも含めた）有効性というのは疑問ですね。
Re:本当にアクセス数なのかな？ という疑い (スコア:1, おもしろおかしい)
表示データの削減で対応 (スコア:1, 興味深い)
Playstation.comとかが落ちた時に素人なりに 考えたのですが、一ページ当たりに表示されるデータを 減らす事で、負荷が減るのではないですか。
落ちるのが予想されたりする場合は、画像とかFlashを ばしばし使うのをやめて、テキスト主体で作っておくと、 良いと思ったのですが。
Re:表示データの削減で対応 (スコア:1)
Flashで登録シーケンス全部作ってゆっくり書かせて、バックエンドで待ち行列制御しつつ適度に送る(P2Pソフトとかであるやつ）ようにすれば、設計値通りのアクセスしか発生しないし、待ち行列の数見て適切増強できる。最初のFlashはCDN業者使って処置。
なんてのはダメ？
ダメだ、呑み直そう。
Re:表示データの削減で対応 (スコア:1)
IMG タグやら OBJECT タグやらがあるたびにクエリーを飛ばす HTML ページよりは、意外と Flash だけで作っちゃったページの方が負荷は減るのかもしれません。
ほんとうにテキストだけにしちゃうのが一番軽いんでしょうけどね。
むらちより/あい/をこめて。
Re:表示データの削減で対応 (スコア:1, 参考になる)
9.11の時、cnn.comがトップページを一時的にテキストオンリーに切り替えましたよね（確か）。
緊急時は、案外こういう単純な方法の方が良いのかもしれない。
Re:表示データの削減で対応 (スコア:1, 参考になる)
思いますが、これを静的なファイルに切り替えればそれだけで
10-100倍はいけます。それでも来るなら（まだしてなかったと
して）画像だけ外に配置して、本体コンテンツはテキスト
オンリーにすればさらに-10倍（どれくらい画像を使っていたか
次第）、で、これで情報の伝達だけは少なくともできるはず。
後は同時並行的にサーバー（と設置場所）増やしたり、DNS設定
追加したり…でしょうか。激しく外した場合は台数だとか
回線とかの物理資源が完全にボトルネックになるので手当てできる
体制がなければ途中でお手上げでしょうね。
受付系だとどうしてもダイナミックにせざるをえませんが、
それもリアルタイムで処理しないでファイルシステム上に
作った臨時キューとかに生リクエストをひたすら貯めるだけに
して、「受け付けただけ - 結果は後日」状態にするように
簡略化してしまえば臨時対策でも結構持ちます。
しかし問題はこれをするかどうかの政治的判断で、CNNの場合は
即断できる人がいたか体制が整っていたのかなと思われます。
以前 CNN の人が発表した 9/11 の時のレポートのソースを
なくしてしまいましたが、聞いていた人のレポート [clock.org]が資料として参考になります。アクセスが殺到し始めて8万ヒット、そして倍倍で記録更新を重ねて111万ヒット／分というのは凄すぎる…
シールの枚数は限られているんでしょ？ (スコア:1)
出荷している「シールの枚数」は限られていますよね。
同様の過去のキャンペーンでの実績値もあるだろうし、大まかに
どのくらいのアクセスが見込まれるのか、くらいは算出できそうな
気がするんですが…。
Re:シールの枚数は限られているんでしょ？ (スコア:1)
アクセスするかが予想できないところでは？
#集めた個人情報は売るのかな？ :-P
slashdotted (スコア:1)
日本に限定するとにちゃんねるで祭られたとかなんでしょうかね。
サーバ管理者の皆様、ご苦労様です。。。
邪推 (スコア:1)
ニュースサイトなんかで、タダで宣伝してもらえるし
かつて某大手ゲーム機器メーカーが自社製品の販売で散々使った手口だよね…焦らし
＃ 爆言のち漏電中… ：D
予測よりも善後策？ (スコア:1)