アカウント名:
パスワード:
>もしDNSラウンドロビンを安易に提案してくるベンダがあったらかなりヤヴァイかと。
むしろ、安易にロードバランサを提案してくるベンダの方がヤヴァイですよ。 単に単価が高いもの売りたいだけっていうような場合もあります。 実際、ロードバランサを入れながらコケたサイトとかの情報を聞くと、サーバがコケるより前にロードバランサがコケたとかのマヌケな話も良く聞くし。 私としてはロードバランサの(コストも含めた)有効性というのは疑問ですね。
あなたはSIerですか? 要するに、高価なロードバランサ入れて、SIerに高い金払うぐらいなら、サーバ増強してDNSラウンドロビンした方が安く上がるという結論です。ウチでは。 サーバの順次増強ではなく、それだけの無駄金を払うぐらいなら、最初から無駄なパフォーマンスのサーバ入れておいた方が結局安く付くし、負荷の上限はネットワークの帯域で制限されるので、サーバもコケない。 上位で詰
見積を取ったのですが、Xeon×2+メモリ4Gのサーバ6台分ぐらいでした。
>L4スイッチが高いと感じる規模なら、他にやることがあるんだと思います。
だからロードバランサやめたの。 で、その分Xeon×2+メモリ4Gのサーバを4台増強しました。 コストは2/3で、サーバはみんな遊ん
>単一システムに対してロードバランサがんばれっていっても本領発揮できんっしょ。
それは発想が逆。 ロードバランサがいらないように、フロントエンドはWebサーバだけにわざとしてるの。 Webサーバの一部にDBサーバも同居させてフロントエンドの処理能力をアンバランスにしておいて、それを無理矢理動かすためにロードバランサを入れる
何だか、この一連の応答で「ロードバランサ必要
>構造が単純ならいらん(w
だからさ、「最初から構造が単純だからいらない」んじゃなくて、「サーバを沢山入れて単純な構造にすればロードバランサがいらなくなる」って言ってるだんって。 ロードバランサがいらないように単純な構造にしたんだから、「単純だからいらん」のはあたりまえ。
>DNSに頼るのは本当にしょうもないor身内しか使わないようなシ
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。 その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。 ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
本当にアクセス数なのかな? という疑い (スコア:1, 興味深い)
中身を見たことがあるのですが…アルゴリズムがアレすぎて仕様とは
違う結果をたたき出したり、有名な方法でクラッキングが出来たりと、
ひどい物でした。
また、この生茶のサイトに関して、少なくともDNSレベルでは、負荷を
分散しようとしている形跡は見えません。
そんなわけで、本当にこれ、サー
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
出来なくなる人が出てくるのが恐いんですよね。
というわけでDNSでは分散せず箱モノのロードバランサを
入れてやるところが殆どだと思いますよ。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
例えば、サーバがAとBの2台あるとして、
ロードバランサーならお互いの負荷を均等にできるけど、
DNSだとラウンドロビンで交互に割り振られるだけなので、
遅いクライアントが片方に集中してぶらさがったりすると、
結果として全体のパフォーマンスがガタガタになったりする。
つまり、パフォーマンスの見積もりができない。
本当に高負荷なシステムにはDNSラウンドロビンは使いませんね。
ロードバランサーはだてに高いわけじゃないんですよ。
もしDNSラウンドロビンを安易に提案してくるベンダがあったらかなりヤヴァイかと。
DNSに頼るのは本当にしょうもないor身内しか使わないようなシステムか、
本当に予算がない時だけですね。
Re:本当にアクセス数なのかな? という疑い (スコア:1, 参考になる)
やめた直接の原因はトラフィック増えてロードバランサが過負荷になったためですが、よりパフォーマンスの高いロードバランサに買い換えるぐらいなら、その金でサーバ増やして処理量自体を増やしてDNSラウンドロビンにした方がマシという結論になりました。
サーバ増やして処理量が増えれば、多少のアンバランスは問題無いですし、Xeon×2のサーバが何台も買えるような金出してロードバランサを入れても、結局処理量は増えないで、100%(に近く)処理できるようになるだけですから。
>もしDNSラウンドロビンを安易に提案してくるベンダがあったらかなりヤヴァイかと。
むしろ、安易にロードバランサを提案してくるベンダの方がヤヴァイですよ。
単に単価が高いもの売りたいだけっていうような場合もあります。
実際、ロードバランサを入れながらコケたサイトとかの情報を聞くと、サーバがコケるより前にロードバランサがコケたとかのマヌケな話も良く聞くし。
私としてはロードバランサの(コストも含めた)有効性というのは疑問ですね。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
正確に見積もっていればロードバランサーがこけるなんてありえないし、
そもそもサーバの性能がロードバランサーの性能を上回ってる時点で、
システム全体の性能設計が間違っていると思われます。
例えて言うと、
いくら駐車場を広くして入場待ちの人を減らしたとしても、
そこに繋がる道が細くて対向で行きかうのも困難な道なら、
駐車場は全く用を成さない(上に維持コストだけは高い)のと同じ、
って言うことかな?
最近、サーバの負荷分散の知識は広まってきているけど、
ネットワークの負荷分散の発想はまだまだ甘い人が多いと思う
Re:本当にアクセス数なのかな? という疑い (スコア:0)
あなたはSIerですか?
要するに、高価なロードバランサ入れて、SIerに高い金払うぐらいなら、サーバ増強してDNSラウンドロビンした方が安く上がるという結論です。ウチでは。
サーバの順次増強ではなく、それだけの無駄金を払うぐらいなら、最初から無駄なパフォーマンスのサーバ入れておいた方が結局安く付くし、負荷の上限はネットワークの帯域で制限されるので、サーバもコケない。
上位で詰
Re:本当にアクセス数なのかな? という疑い (スコア:0)
今やサーバなんて安い部類の機器なので、必要以上に入れて
冗長に動かしたり、予備として接続状態で待機させたりして。
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サーバの一部に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)
>ログインサーバありーのパッチサーバありーのゲームサーバありーのみたいなシステムなら
まず、何故そうやってサーバを分けなきゃいけないかを考えるべきです。
その単機能のサーバが一台だけって事はこの際無い事にして(一台だけならロードバランサなんていらんから)、複数台のフロントエンドに対応できるシステムで、他のサーバと別ける必要性は何なのかと。
ありがちな理由としては、「特定の機能は(他の機能に引きずられて)コケるとマズいから」というのがありますが、本
Re:本当にアクセス数なのかな? という疑い (スコア:0)
でも俺はベンダのせいじゃなくて、無理矢理予算を切りつめたウチの上司のせいだと思ってた。
ロードバランサが落ちるたびにベンダにゴルァ電かけるのが辛かったーよ。
それはさておき、俺も安易にロード
Re:本当にアクセス数なのかな? という疑い (スコア:0)
DNSラウンドロビンぐらいしか提案できないと思うし、お金が
あったとしても機材納期とかの問題が出てきそうな気がします。
均等にアクセスを分散させるだけだったら、
Linux Virtual Server [linuxvirtualserver.org]なんかがお勧めです。
Re:本当にアクセス数なのかな? という疑い (スコア:0)
ただ、お客さんに何の説明もなく勝手にこちらで判断して、
いきなりそれは問題だとも思います。
お客さんに対して、
導入するシステムを要求通りの仕様にするために何が必要なのか、
そして今のままの予算だとどれくらいの違いが出るのか、
これぐらいは提案できないと後で必ず問題になりますから。
その提案によってもしかしたら予算が増額されるかもしれませ