アカウント名:
パスワード:
見積を取ったのですが、Xeon×2+メモリ4Gのサーバ6台分ぐらいでした。
>L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
だからロードバランサやめたの。 で、その分Xeon×2+メモリ4Gのサーバを4台増強しました。 コストは2/3で、サーバはみんな遊ん
>単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
それは発想が逆。 ロードバランサがいらないように、フロントエンドはWebサーバだけにわざとしてるの。 Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、それを無理矢理動かすためにロードバランサを入れる
何だか、この一連の応答で「ロードバランサ必要
>構造が単純ならいらん(w
だからさ、「最初から構造が単純だからいらない」んじゃなくて、「サーバを沢山入れて単純な構造にすればロードバランサがいらなくなる」って言ってるだんって。 ロードバランサがいらないように単純な構造にしたんだから、「単純だからいらん」のはあたりまえ。
>DNSに頼るのは本当にしょうもないor身内しか使わないようなシ
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。 その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。 ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本当に死守しなくてはいけないのが10も20もあるって事はありえません。 せいぜい一つか2つ。それなら、それだけを別にDNSラウンドロビンで回せばいい。 何もDNSラウンドロビンでは1つに全部まとめなきゃいけないというキマリがある訳じゃない。ただむやみとたくさんグループを作ると、管理が煩雑になるというだけ。 別の理由としては「SSL対応の場合、全台にSSL入れて契約するだけのコストがかけられない」というのもありますが、これも上と一緒。 っていうか、ロードバランサよりはSSLの方が安い場合が多い。 あと「多くのサーバにインストールするのはインストールや管理が大変」というのもありますが、個別に設定の違うサーバを何種類も管理するよりは、何でもできる同じ設定のサーバをコピーした方が、実は管理が楽だったりします。 残る理由は「レガシーな理由により、動いているものを触りたくない」というのもあるかもしれませんが、まぁそりゃ勝手にやってくれって感じですね。 管理できない/管理したくないのを金で解決するのであれば、ロードバランサもいいでしょう。
>それは私じゃないからどーでもいいが、予算があるときは導入してもいいんじゃない? >おもちゃ増えたほうが楽しいっしょ(w
クリティカルポイントが増えるのはヤダ それに設計時よりも必要帯域が増えて行くとボトルネックになってくる。 上の方で「設計が悪いんだ」というような話も出てるが、Webサイトへのトラフィックというのは、時と共に増加して行くものなので、何年先まで見込んで設計するかによって、必要なコストが桁違いに変わってくる。 で、実際動き始めてみたら、3年先まで大丈夫だったはずが半年で溢れたりというのは日常茶飯な話で、まさにこのトピの話題である「アクセスの予測」なんて全くアテにならない。 アテにならないものを元に設計しておいて、コケないようにするには、不必要に高機能なものを入れるしかない。 サーバのように並列に動作するものは、2倍の性能が欲しければ、2倍のコストで済むけど、ロードバランサで2倍の性能にするには、2乗のコストがかかる。 O(n)とO(n*n)のものがあれば、O(n*n)を極小化するのが最適である事は明らかでしょ。 どうせ予算が余ってておもちゃにするんなら、使わないサーバがあった方が遊びがいがありますよ。 そのおもちゃの値段で価値が決まると考える人は、せいぜい高くて遊びがいの無いおもちゃを買ってください:-D
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
本当にアクセス数なのかな? という疑い (スコア:1, 興味深い)
中身を見たことがあるのですが…アルゴリズムがアレすぎて仕様とは
違う結果をたたき出したり、有名な方法でクラッキングが出来たりと、
ひどい物でした。
また、この生茶のサイトに関して、少なくともDNSレベルでは、負荷を
分散しようとしている形跡は見えません。
そんなわけで、本当にこれ、サー
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
出来なくなる人が出てくるのが恐いんですよね。
というわけでDNSでは分散せず箱モノのロードバランサを
入れてやるところが殆どだと思いますよ。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
例えば、サーバがAとBの2台あるとして、
ロードバランサーならお互いの負荷を均等にできるけど、
DNSだとラウンドロビンで交互に割り振られるだけなので、
遅いクライアントが片方に集中してぶらさがったりすると、
結果として全体のパフォーマンスがガタガタになったりする。
つまり、パフォーマンスの見積もりができない。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
やめた直接の原因はトラフィック増えてロードバランサが過負荷になったためですが、よりパフォーマンスの高いロードバランサに買い換えるぐらいなら、その金でサーバ増やして処理量自体を増やしてDNSラウンドロビンにした方がマシという結論になりました。
サーバ増やして処理量が増えれば、多少のアンバランスは問題無いですし、Xeon×2のサーバが何台も買えるような金出してロードバランサを入れても、結局処理量は増えないで、100%(に近く)処理できるようになるだけですから。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
うーん、L4スイッチって高いかなぁ?
L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
>サーバがコケるより前にロードバランサがコケたとかのマヌケな話も良く聞くし。
そりは、ロードバランサがまぬけなんじゃ
Re:本当にアクセス数なのかな? という疑い (スコア:0)
見積を取ったのですが、Xeon×2+メモリ4Gのサーバ6台分ぐらいでした。
>L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
だからロードバランサやめたの。
で、その分Xeon×2+メモリ4Gのサーバを4台増強しました。
コストは2/3で、サーバはみんな遊ん
Re:本当にアクセス数なのかな? という疑い (スコア:0)
だとしたら、ロードバランサなんか検討するだけ無駄なのは当たり前だと思うけど。
私や#359783のACさんが想定している状況では話が噛み合わん(w
Re:本当にアクセス数なのかな? という疑い (スコア:0)
Re:本当にアクセス数なのかな? という疑い (スコア:0)
しかなくっても、サーバごとで別々のシステムだったりすればまた別だけど、
単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
それは発想が逆。
ロードバランサがいらないように、フロントエンドはWebサーバだけにわざとしてるの。
Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、それを無理矢理動かすためにロードバランサを入れる
Re:本当にアクセス数なのかな? という疑い (スコア:0)
「Webサーバしか」ってのは「ロードバランシングの対象が」って意味です。
中途半端な書き方ですんません。
これで誤解解けるかな?
Re:本当にアクセス数なのかな? という疑い (スコア:0)
想定しているものが違うって言うのなら、あなたが想定しているものが何なのか書かないと話にならないでしょ。
って言うか、一般的な話をする上で、レアなアプリケーションを持ち出して「ロードバランサは絶対必要だ」って言っても全然説得力無いんですが。
特別なものには特別な仕掛けが必要。それだけでしょ。
トラフィックの分散という話の中で一般的に主要なアプリケーションとなるhttpではロードバランサは不要。
これがウチの結論。
何だか、この一連の応答で「ロードバランサ必要
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>あなたが想定しているものが何なのか書かないと話にならないでしょ。
あなたの会社のネットワークは外部とhttpでしか通信しないんですか?
それはともかく、同じhttpにしても複数のシステムがロードバランサの配下にあったり、
ストリーミングサーバがあったりで、ぶっちゃけていえば通信全部ですかね。
>トラフィックの分散という話の中で一般的に主要なアプリケーションとなるhttp
想定している状況が違うっぽいって書いてるのに。
あなたが分散したいのはhttpだけなのかもしれないけど、(他のACさん
Re:本当にアクセス数なのかな? という疑い (スコア:0)
話にならん。
>構造が単純ならいらん(w
だからさ、「最初から構造が単純だからいらない」んじゃなくて、「サーバを沢山入れて単純な構造にすればロードバランサがいらなくなる」って言ってるだんって。
ロードバランサがいらないように単純な構造にしたんだから、「単純だからいらん」のはあたりまえ。
>DNSに頼るのは本当にしょうもないor身内しか使わないようなシ
Re:本当にアクセス数なのかな? という疑い (スコア:0)
Webでないもの「も」って言って欲しかったなぁ、まあいいや。
あなたのいうようなフロントが1タイプしかないシステムであればいいですが、
ログインサーバありーのパッチサーバありーのゲームサーバありーのみたいなシステムなら
L4スイッチを導入したほうが融通がききます。
もっとも、拠点分散せーやって方が早いですが。
もちろん、L4スイッチなしでやってもでき
Re:本当にアクセス数なのかな? という疑い (スコア:0)
>ログインサーバありーのパッチサーバありーのゲームサーバありーのみたいなシステムなら
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。
その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。
ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本当に死守しなくてはいけないのが10も20もあるって事はありえません。
せいぜい一つか2つ。それなら、それだけを別にDNSラウンドロビンで回せばいい。
何もDNSラウンドロビンでは1つに全部まとめなきゃいけないというキマリがある訳じゃない。ただむやみとたくさんグループを作ると、管理が煩雑になるというだけ。
別の理由としては「SSL対応の場合、全台にSSL入れて契約するだけのコストがかけられない」というのもありますが、これも上と一緒。
っていうか、ロードバランサよりはSSLの方が安い場合が多い。
あと「多くのサーバにインストールするのはインストールや管理が大変」というのもありますが、個別に設定の違うサーバを何種類も管理するよりは、何でもできる同じ設定のサーバをコピーした方が、実は管理が楽だったりします。
残る理由は「レガシーな理由により、動いているものを触りたくない」というのもあるかもしれませんが、まぁそりゃ勝手にやってくれって感じですね。
管理できない/管理したくないのを金で解決するのであれば、ロードバランサもいいでしょう。
>それは私じゃないからどーでもいいが、予算があるときは導入してもいいんじゃない?
>おもちゃ増えたほうが楽しいっしょ(w
クリティカルポイントが増えるのはヤダ
それに設計時よりも必要帯域が増えて行くとボトルネックになってくる。
上の方で「設計が悪いんだ」というような話も出てるが、Webサイトへのトラフィックというのは、時と共に増加して行くものなので、何年先まで見込んで設計するかによって、必要なコストが桁違いに変わってくる。
で、実際動き始めてみたら、3年先まで大丈夫だったはずが半年で溢れたりというのは日常茶飯な話で、まさにこのトピの話題である「アクセスの予測」なんて全くアテにならない。
アテにならないものを元に設計しておいて、コケないようにするには、不必要に高機能なものを入れるしかない。
サーバのように並列に動作するものは、2倍の性能が欲しければ、2倍のコストで済むけど、ロードバランサで2倍の性能にするには、2乗のコストがかかる。
O(n)とO(n*n)のものがあれば、O(n*n)を極小化するのが最適である事は明らかでしょ。
どうせ予算が余ってておもちゃにするんなら、使わないサーバがあった方が遊びがいがありますよ。
そのおもちゃの値段で価値が決まると考える人は、せいぜい高くて遊びがいの無いおもちゃを買ってください:-D