■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1

**FOX ★** · 05/01/07 03:19:00

■　新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!?

巨大Live専用サーバの構築

live系のサーバは台数投入したところで、ほとんど遊んでいる
サーバ + 一台の負荷が高くてアクセスできないサーバという
悲惨な状況になっちゃうので、複数のサーバを巨大な一台と見立てて
なんとかならんものなのかを模索するー。

【Step1】四台のbananaサーバで現 live8/live16/live18 を全部収容する。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:19:16

　　　　　　 |三|
　　　　　／■ ＼
　　　　　 |´∀｀　 |　ｵﾆｷﾞﾘｭｷﾀﾞﾙﾏｶﾞ2ｹﾞﾄ
　　 ★ 　ヽ＿＿ノ　 ★
　　　＼ミ≡≡彡／
　　　　/　　　巛　ヽ
　　　 |　　　　　　 |
　　　丶　　　　ﾉ
　　　　　＼＿＿_／
⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒⌒

**その他 ★** · 05/01/07 03:19:27

乙

**南アルプス** ◆98YENoslbU · 05/01/07 03:20:14

今ここに醜い自演を見た。

**ひろゆき＠どうやら管理人 ★** · 05/01/07 03:20:37

mysqlがクラスタリングのモデルだしましたけど、
あれはどうなんでしょう？

**その他 ★** · 05/01/07 03:22:19

汎用は所詮汎用だと思うなぁ、、、

**動け動けウゴウゴ２ちゃんねる** · NG

(n‘∀‘)η

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:26:35

誰も言ってあげないみたいだから言ってあげよう。

>>1乙

**じじぃ その４** ◆HETAREzfq. · 05/01/07 03:28:06

とりあえずbbs.cgiのsubject関係とdat関係の処理を明示的に分離しるんけ？
ようﾜｶﾗﾝけんども

**root▲ ★** · 05/01/07 03:28:46

いきなり第一ステップから「全部収容」すかぁ。
さて、どの持ち駒をどう使っていこうかなと。

>>3
さすが、流行に敏感。

**マァヴ ★** · 05/01/07 03:31:43

あー、３年くらい前に構造を色々考えたことがあった気がする(^_^;)
あの頃とはかなり様相が変わったんだよね・・・・
能力を分割するとしたら
・bbs.cgi
・disk I/O
・read.cgi
の３つかな？

**その他 ★** · 05/01/07 03:34:35

banana227 を bqckend にして
live14/live18 あたりを front にしてbasicなものを組んで
試行錯誤してみようかな、、

banana227 の root pw を明日になったら送りまーす >>10
banana386 と
banana613 は最初は単に virtualhost 作ってラウンドロビンしてみよう

**マァヴ ★** · 05/01/07 03:37:07

bサーバ、dサーバ、rサーバと仮に名前をつけると味気ないので
弘法・聖徳・空海と名づけるとしよう(^_^;)

まず聖徳の仕事
　弘法から投げられた書き込みをひたすらメモリーに書き込む
　空海から呼びだしを受けたら、どんどんdatを投げる
　1000に達したスレッドはガンガンディスクに書き込んで、メモリ上から消す

こんなかんじ？

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:39:27

cgiはそれぞれのサーバーに
datは4台のサーバーにRAID5(6?)の様な感じで格納ってなるの?
>>1を見るだけでは良く分からないけど

って書いていたら>>11-13が書き込まれたけど....俺の脳みそではヨクワカラン

**root▲ ★** · 05/01/07 03:40:58

基本コンセプトは
「読み手担当と書き手担当を完全に分離することにより、効率をアップする」です。
すべては、ここから。

>>12
了解。

**マァヴ ★** · 05/01/07 03:43:38

弘法の仕事(^_^;)
　ラウンドロビンでたくさんたてて、どこに書き込みが来ても適切な聖徳に渡す
　やってきた書き込みが正当かどうかのチェックをする（聖徳は書き込む以外やらないですむように）

空海の仕事
　ラウンドロビンでたくさん立てて、どこに読み出しが来ても適切な聖徳からdatを取得する
　読み出しの要求に対して、聖徳からdatを引っ張ってきて、htmlに変換して吐き出す
　一定時間（10秒程度？）はキャッシュして、聖徳への呼びだし回数を減らす

こんな感じ？(^_^;)

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:44:11

root ★ﾀﾝの説明は分かりやすいなぁ

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:45:18

>>17
ありゃ▲抜けてた。

**マァヴ ★** · 05/01/07 03:45:29

>15
bbs.cgiとread.cgiの分割だけでも充分かもしれないですね(^_^;)
弘法と聖徳は一体化・・・・
ただ、そうするとbbs.cgiにスケールメリットが取れなくなるけど

**root▲ ★** · 05/01/07 03:47:09

で、読み手担当は、read.cgiサービスと、datファイル直読みサービスを提供します。
bbs.cgiのフロントエンド(と仮に名づけよう)も、担当するかな。
つまり、お客さんの相手に専念する。

で、bbs.cgiフロントエンドは、いろんなチェックしたら、
datファイルやらリモホ情報やらを、書き手担当に何らかの方法で通信して伝えます。

書き手担当は、ひたすらI/Oする。
datちょうだい、と読み手担当に言われれば渡すし、
これ処理しといて、と読み手担当に言われたら、たんたんと処理する。
でも、お客さんの相手は基本的にしない。

削除とか芋堀とか、いわゆる保守系は、書き手担当が受け付けるのかな。
あくまで、保守系だけね。お客さんは受付へどうぞ。

**マァヴ ★** · 05/01/07 03:50:45

>20
read.cgiとbbs.cgiだと、負荷総量ではreadのほうが圧倒的にでかいんじゃなかったっけ？(^_^;)
readを分離したほうがいいと思うんだけど。

**▲ 某ソレ511** · 05/01/07 03:53:56

live系だとbbs.cgiのほうの負荷で重い場合が多いんですよね、、たしか。
ラピュタの時は読み込みが多くてだったけど。

**じじぃ その４** ◆HETAREzfq. · 05/01/07 03:55:48

負荷がたかくなるとsubject.txtがまず壊れる場合が多いんじゃが
read.cgiサービスとbbs.cgiサービスを分けることでコレは改善しるのけ？

ようﾜｶﾗﾝなりにおらが理解してたのでは
agesageの処理もかなりきつかったような気がしるんじゃが

**マァヴ ★** · 05/01/07 03:56:49

>23
改善はしないと思う(^_^;)

**マァヴ ★** · 05/01/07 03:57:39

http://kobodaishi.xrea.jp/
ふはははは(^_^;)

**root▲ ★** · 05/01/07 03:57:46

>>21
bbs.cgiの方が圧倒的にでかいですね。
特にread.cgiはdso化して起動コストがなくなったので。

bbs.cgi(のフロントエンド)ができるだけブロックしないようにしたいですね。
重い処理(ディスクI/O関連)を、後ろに回すのが、たぶん第一段階の最初かと。

で、後ろに回した処理がボトルネックになるようなら、最初は成功。
あとは、後ろ側の処理の効率を上げる方向で、チューニングしていくと。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 03:58:50

>>13
弘法と空海は同一人物では・・・

**root▲ ★** · 05/01/07 03:59:41

もちろん、前と後ろの通信をうまくやってできるだけブロックしないようにするとか、
そういう方向でのプログラミング的手法も、必要になりそうかな。

いずれにせよ、またお風呂にでも入りながら、
ちょっと脳内で絵を描いてみようかと。

**マァヴ ★** · 05/01/07 04:00:19

>26
なるほど(^_^;)
まずはbbs.cgiの分離ですね

**通行人** · 05/01/07 04:06:28

実況系はagesageの処理を無くしてもいいんじゃないかと思ったり・・・

**その他 ★** · 05/01/07 04:07:54

1) 机上の空論
2) それに基づいた絵
3) 絵を描く
4) 実験する
5) 1)が合っていたかどうかの検証

これをひたすら繰り返すと、

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:11:11

コレを機会に負荷が高くなった時に起きる不可視やら板とびやらの
主だった仕組み（原因）をご教授願いたいものじゃ

datを更新しました⇒（伝達）⇒subjectを書き換えます
のどっちかが溢れてしまうからこういうことになるんじゃとおもうんじゃが
どっちが溢れることが多いんじゃ？

subject生成の工程に伝わった時点でそこが溢れておるのか、
dat更新の段階で溢れてしまってsubjec生成tの工程に伝わってないのか、

**その他 ★** · 05/01/07 04:11:44

んで
現状は bbs.cgi が律速であると解かっている

bbs.cgi を動かすサーバを二台にしてみる
ただしdatは一箇所に書かなきゃ意味が無いので
backendにdat処理用一台と、

これでやって、　subject.txt や規制系やその他もろもろが
使い物になるのかどうか、、、
特に規制系はsambaにしても連投規制にしても、かなり手ごわいかと、
あきらめるのも一手ですが、

**ひろゆき＠どうやら管理人 ★** · 05/01/07 04:12:49

readがいくらでも分散できるのは
blackgoatで証明済みなような。

**その他 ★** · 05/01/07 04:13:02

>>32
「壊れてもいいや直せば」という前提で
ファルロックを一切行っていない、つまり排他制御していない

なので壊れるのです。

**FOX ★** · 05/01/07 04:15:04

>>34

そですねぇ
delay値をどれくらいにすれば体感上違和感がなくなるか、
それとトラフィックのボリューム(頻度?)との兼ね合い、せめぎあい
なのかなぁと

**root▲ ★** · 05/01/07 04:15:29

で、最近のことをちょっと書いておくと、、、。

特にlive16とかはread.cgiやdat直読みの人が待たないようにするために、
ほんとはもっとhttpdの数を増やしたいわけです。

しかし昔は、起動数をむげに増やすと、「どーん」とbbs.cgiが同時に100個以上
起動された時に(例: 西部警察で導火線爆弾が出る等)、もう即死するしかなかった。

で、昨年bbs.cgiをSpeedyCGIにすることで、
最大並列処理数(バックエンドの最大起動数)を制限することができるようになり、
即死のリスクをとても減少させることができました。

でもこの場合、bbs.cgiの実際の処理をしている人がおなかいっぱいになると、
こんどはフロントエンドがバックエンドの処理終了を待ってしまって、
結局httpdを埋めていってしまうことになります。
つまり、流入は制限されるのですが、「終了に時間がかかって、窓口人員が不足がちになる」
ことに変わりはないわけです。

また、バルスとかマツケンサンバとか、超人気番組の場合、
おそろしい勢いで読み手が攻めてきて、httpdが売り切れになってしまい、
サーバは負荷が低いのに、誰も書き込みができないし、
読むのも難しい、という状態になったりします。
これも、窓口の人手が足りない状態。

ということで、
・窓口の人手を増やして
・お客をできるだけ待たせないようにしながら
・でも、サーバにはやさしい方法で処理する

ような手法はないだろうか、というのが、今回の試みなのではないかなと。

**マァヴ ★** · 05/01/07 04:17:25

>33
sambaや連投規制は、frontendが今まで通りにやればいいんでないかな？(^_^;)
ラウンドロビンしてるとはいえ、短期的には同じサーバにアクセスするわけだし。

ほかにどういう規制があるんだろう・・・・
まずそのリストアップしないと(^_^;)

**root▲ ★** · 05/01/07 04:17:35

>>34
そうですね。読ませるほうは、比較的楽なのですよ。
Apacheのリバースプロキシとか、blackgoatみたいにsquid使うとか、
結構いろいろな手法があります。

問題は、書かせるほうをいかに処理するか。
従来の、bbs.cgiによる簡便なインタフェースをできるだけ残しつつ、
いかに中身をうまく効率化するか、なのかなと。

**FOX ★** · 05/01/07 04:22:41

ラウンドロビン　(←弱そうな名前であまり好きでないのだが)
を使うのであれば、

Samba24 は、うまく行くか、
連投規制は、どうなるかな?
スレ立て規制は元々スレ立てやすい設定だから
あんまり気にする事無いか、トカゲの尻尾もあるし
あと・・・　何あったっけ?

**root▲ ★** · 05/01/07 04:24:42

個人的には、NFS経由での書き込みはあまり使いたくないな、
と思っています。トラブルの元。

読むほうでのNFSの利用は、うまくやればありかもですね。

**root▲ ★** · 05/01/07 04:26:36

datは、キャッシングかなと思っているです。
フロントにもdatプールみたいなのを作って、キャッシュできないかなと。

で、どっかで話が出ましたが、SolarisだとCacheFSという仕組みがあって、
このへんが結構うまく動くです。
FreeBSDでは、どうするか。フロント側でもsquidみたいなの使ってみるかなぁ。

**マァヴ ★** · 05/01/07 04:26:37

http://info.2ch.net/wiki/pukiwiki.php?%BD%F1%A4%AD%B9%FE%A4%E1%A4%CA%A4%A4%BB%FE%A4%CE%C1%E1%B8%AB%C9%BD

アクセス規制・プロキシ－規制・Rock54
　BBQなど外部問い合わせ型は問題なし
　内部問い合わせ型も、それぞれがテーブルを持っていれば問題なし
　（つまり従来通り）

samba24・二重書き込み・連続投稿
　フロントエンド単位で規制。
　ラウンドロビンしていても、短期的には同じサーバで書き込みチェックを行うので。
　（つまり従来どおり）

ブラウザ情報規制
　従来通り

スレ立て規制
　これは微妙(^_^;)どうやればいいんだ
　あるいは別な手法を考える？
　バーボンハウスって同じ機能？

**マァヴ ★** · 05/01/07 04:28:30

お茶飲み規制・落ち着け規制・とかげの尻尾
　仕組みがよーわからん(^_^;)

その他
　従来通り

**FOX ★** · 05/01/07 04:29:58

お茶飲み規制・落ち着け規制 <- 現在これらはないはず
とかげの尻尾 <- BBQ のように外部経由です

**root▲ ★** · 05/01/07 04:32:11

最初の段階でのイメージとしては、bbs.cgi(フロント)が、バックにあるbbs-back.cgi(仮称)を叩く、
という、きわめて単純なイメージを考えています。

dat書き込み、リモホ記録といった「書き込み系」をbbs-back.cgiがやると。

で、書いたデータを読みたい時(例えばSambaとか)は、
例えば一番どろくさいやり方するなら、単純にNFSのread onlyで
フロントのbbs.cgiがバックのファイルを直読みするかんじかなと。

かしこいやり方するなら、プロセス間通信でやるとか、
あるいはmysqlみたいなのを使うとか、そういうかんじですかね。
（これらは第2段階以降だと思っています)

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:32:40

live系の即死はほぼ一律じゃしねぃ

>>35
そうかー

**マァヴ ★** · 05/01/07 04:33:45

スレ立て規制以外の規制は、同じ機能をほとんどいじらずに使えそうですな(^_^;)
＞samba24・二重書き込み・連続投稿
　ラウンドロビンでサーバが切り替わるタイミング（DNSのTTL単位かな？）ごとに
　新しいフロントエンドサーバに割り当て直しが起こるので
　今までより多少甘くなるかも・・・・

＞スレたて規制
　BBQみたいな仕組みに置き換え？
　あるいは廃止？
　あるいは全然別の仕組み？

**root▲ ★** · 05/01/07 04:36:35

>>48
そうはならないようにしたいなと、思っていたりします。
つまり、別のフロントエンドサーバにあたっても、従来通りそのへんは効くようにしたいなと。

**root▲ ★** · 05/01/07 04:38:54

なんにせよ、明日以降まずは土地を整地して、
器の構築をやるです。

I/O屋さんに仕立て上げる方向で。
blackgoatみたいにccdを使ってみるか。

**マァヴ ★** · 05/01/07 04:39:30

>49
つまり「samba24・二重書き込み・連続投稿」は要改良という方向で(^_^;)
どれも（スレたて規制もふくめて）トカゲの尻尾にまとめちゃうっていう手はあるなぁ・・・・

**じじぃ その４** ◆HETAREzfq. · 05/01/07 04:39:34

ん？
規制といえば
SETTING.TXTで定める値が必然的に各板共通になるのけ？

**マァヴ ★** · 05/01/07 04:40:47

subcakはbackendのお仕事になるのかな？(^_^;)やはり

**マァヴ ★** · 05/01/07 04:41:37

subbackじゃないや(^_^;)subjectだ

**root▲ ★** · 05/01/07 04:43:19

>>53
subject.txt / subback.html は、後ろの仕事になるですね。たぶん。

さすがにねむいす。そろそろまけぐみへと。

**マァヴ ★** · 05/01/07 04:49:16

おつかれさまです(^_^;)おやすみなさい
おいらもそろそろ寝る～

**ひろゆき＠どうやら管理人 ★** · NG

ディスクI/Oの分散化じゃないすかね？
dat番号で保存するサーバを切り分けるとか。

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 05:38:24

>>27
read.cgiのサーバとbbs.cgiのサーバは同一にするという計画だったんだよ！
な、なんだってー＞ΩΩ Ω

桶屋 · 05/01/07 08:15:26

>>37 >>57
これを読むと、それはありかもしれない。
datの末尾番号で保存サーバを振り分けるようにするとか。

Googleのようにデータを分散化してもつ考えですね。

**FOX ★** · 05/01/07 13:44:12

うーん　逆なんだけどなぁ
フロント複数で datサーバは一台でとうぶん間に合うんだけど、
たぶん　一台で 1,000万post/day くらい処理できそうなんだが、

**root▲ ★** · 05/01/07 14:13:19

私も、そう思ってますです。
datのマスターを管理するのは、1台でいけるんではないかと。

フロントエンドがdatファイルをキャッシュするイメージを想定しています。
で、read.cgiは、そのキャッシュを読む。
そのあたりにおいて、携帯サーバとは、ちょっとだけ路線が違うのかなと。

1000万posts/dayという値は例の「おじさんの動物的直感(これが意外とあてになるんだ)」としても、
当面の路線として「必要以上には処理を複雑にしない」で、できるだけいきたいなと。

**root▲ ★** · 05/01/07 14:19:44

>>61 のキャッシュは、ライブdatはメモリディスク利用かな。
で、過去ログ(●)はNFS経由か、バックエンドに丸投げ。

Sambaはあのディレクトリをフロントエンドで共有すればいいはずだから、NFSなんじゃないかなぁ。
削除系はバックエンド直叩きすね。

bbs.cgiは最初は単純に後ろに渡すだけのシンプルなもので、いいかも。

**FOX ★** · 05/01/07 14:26:44

>>62
banana227 の情報メールしましたー

**FOX ★** · 05/01/07 14:33:59

bbs-back.cgi は bbs-back.so でやりますんで
dso 化お願いします < banana227

**root▲ ★** · 05/01/07 14:39:19

>>63
受け取り&確認しました。
今夜あたりからぼちぼちと。

**root▲ ★** · 05/01/07 14:39:35

>>64
Ack.

**FOX ★** · 05/01/07 14:40:52

banana227.maido3.com
liveb1.2ch.net
ch2b1

んで　私が遊ぶとこ作ってくださいー

**動け動けウゴウゴ２ちゃんねる** · 05/01/07 15:11:40

http://www.sankei.co.jp/news/050107/sha048.htm
「雪まつり」の作業も本格化
運用開始目標は2月7日という感じでしょうか

**root▲ ★** · 05/01/07 15:41:23

OS上げて整地してごそごそして、、、。
週末作業ってかんじで。