グリッドを使った100万人用のゲームサーバ 40
ストーリー by Oliver
PS3先取り 部門より
PS3先取り 部門より
otiak曰く、"PCwatchによると米IBMと米Butterfly.netがSCEIと PS2向けのツールとミドルウェアに関する契約を締結したそうだ。 IBMのニュースリリースによると、Dual－Xeonのブレードサーバを14枚搭載し、グリッドシステムによって100万人以上の同時プレーヤーをサポートするそうだ。 サーバを動的に再構成することによって負荷を分散したり、ゲームを中断せずにメンテナンスをおこなったりできるとのことなので、 「サーバが重い」「メンテナンスの時間が苦痛だ」などど思うヘビーゲーマーにが 朗報ではないだろうか。"
よーし (スコア:2, おもしろおかしい)
オブジェクトも動的だから、稼働しながらメンテできちゃいますよ。
まさにゲーム向け?
値渡しと参照渡し (スコア:1)
Re:よーし (スコア:0)
Java とかでも十分動的再構成出来ますがな。C でもプロセスをうまく分けとけばいけそう。
Re:よーし (スコア:1)
志を低く持てば、Javaでも出来るぞCでも出来るぞという議論も可能ですが、
どうせならもっと気前よく行きましょう。他にも色々メリット有るんだから。
ただまあ、Lispそのものが最高の解なのかどうかは俺は何とも言いませんが。候補の無い昔はともかく今ならrubyやsmalltalkでも良いのでは？ってのも有るんで。
うーん。やっぱり動的度の高い言語のほうが色々ゴリヤクが多いような気がする。CやJavaは足回りにだけご登場願うっつーことで。
Re:よーし (スコア:1)
LISP、はよく分からんですが、例えば ruby や Smalltalk、これらは確かに高い動的度を持っておるでしょう。しかし、それは他のものを犠牲にして得られたものではあるまいか？
例えば ruby の thread は、(native 化しようという動きはあれど) 基本的にユーザランドスレッドであり、お手軽な反面、より高機能なハードウェア (マルチプロセッサな環境など) をうまく利用することが出来ないでしょう。Smalltalk や LISP の現存する処理系も、多かれ少なかれそういう面を抱えているのではないですか？
「普通のやつらの上を行け」、確かにおっしゃることはごもっともな面もありますが、プログラミング言語というのは、その「言語」としてのポテンシャル以外に、どのような「実装」が現存するのか、というのも重要な判断基準でありましょう。どんなに優れた言語であっても、優れた実装が提供されない限り、宝の持ち腐れではないですか？
「言語」の持つポテンシャルと、現存する「実装」のクオリティ、それらが高いレベルでバランスしているプログラミング言語こそ、「最もパワフル」と呼ばれるに相応しい言語であると、僕は思います。
で、すなわちそれは Java であると！
// …あ、石投げないで～。
ところで Java は動的度高いと思いますよ。VM 動作させたままクラス定義入れ換えられるし。インターフェイス合わせとけば新旧のクラスが混在するような環境でも問題ナシです。ポイントはクラスローダですな。
Only Jav^Hpanese available :-)
Re:よーし (スコア:1)
データの再編成を行うように自分自身のロジックをロジックで再編成できると。
…でよかったよね?>LISPのえらいひと
Javaは…早くテンプレート実装してください～
あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
変わっちゃうのも大変かもしれない。
C++使いには「自分で解放するから手を出すなっ」と叫びたくなることもたま～にあるが(笑
でも、言語的にはおもしろいですよ。
kusanagi shin
Re:よーし (スコア:1)
今のノイマン型コンピュータではどんな言語を使おうがプログラムとデータは等価なのではあるまいか？…なんて原則論をゆってもしょうがないっすね。確かに LISP のその特徴はシンプル、かつ非常に強力な点でありますな。設定ファイルを LISP で書ける環境だと、値を設定すべきところに式が書けたりしてめちゃめちゃ便利ですよねぇ。
> Javaは…早くテンプレート実装してください～
なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないんですけど、Java でも便利ですかね？異なるクラスに対して同一の操作を行うような method を作りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら？しかし複数のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な気もしますが…。
> あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
> 変わっちゃうのも大変かもしれない。
むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったのか教えていただけたりしませんか？ダメ？
> C++使いには「自分で解放するから手を出すなっ」と叫びたくなることもたま～にあるが(笑
参照が残ってる限り GC は手を出さないと思うんですが…って、そんな基本的なことじゃない？あこりゃ失礼しました～。
Only Jav^Hpanese available :-)
Re:よーし (スコア:2, 参考になる)
> なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないん
> ですけど、Java でも便利ですかね？異なるクラスに対して同一の操作を行うような method を作
> りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティ
> ブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら？しかし複数
> のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な
> 気もしますが…。
正確にはJ2SE 1.5 から入ります。
JCP(Java の標準団体) の JSR (Javaの仕様案) では JSR 14 Generic Types [jcp.org] です。
提唱者による実装はすでに公開 [unisa.edu.au]されています。
Generic Type は主として、コレクションクラスの高速化と安全性のために導入されます。
現行のコレクションクラスが Object を基底としているため、コレクションから取り出してきた値を使用する前に narrow cast を行う必要があります。これが不要になるぶん高速化されます。
また、Object 型を基底とするコレクションクラスにはどんなオブジェクトで入れることができるという問題がありましたが、ユーザーが指定したクラス(例えば MyClass) にパラメタライズされたコレクションには、MyClass とその導出型以外のものが入りません。その分、安心して使えますし、余分なチェックが不要になります。
あと、入れ物のクラス毎にコレクションクラスが複製されるので、JIT コンパイルが効きやすくなったり、Digitune さんが挙げているようにprimitive 型のコレクションに対するナイーブな実装ができる点が有利なポイントですね。
> > あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
> > 変わっちゃうのも大変かもしれない。
>
> むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わると
> がらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったの
> か教えていただけたりしませんか？ダメ？
第3者ですが。
SUN J2SE の HotSpot VM の 1.4.0 で 1.4.1 の間でボコボコに挙動が変わっている例を一つ。
できるだけ way 数の大きい SMP マシンで、-XX:+AggressiveHeap を付けた時の挙動を確かめてみてください。天地の差があると思います。
細かい違いはまだまだ色々あって、困っているのですが。。。
＃ 変えるなら、変えると、ちゃんと言って欲しいよ > SUN
コンタミは発見の母
Re:よーし (スコア:1)
「同一の」じゃないから厄介なんですよね。「同様の」なんです。templateなるものが欲しくなる場面ってのは。
コンテナ型がよく引き合いに出されますね。Hoge型のデータを格納するFuga型コンテナ、みたいな。
Fuga型の仕組みはHogeが何だろうとそうそう変わるわけじゃないけど、一方でFuga型は
Hoge型とそれ以外とを差別化したくて、しかもHoge型に使いたい型の候補は1つじゃないと来たもんだ、
というケースですね。「型を作る」ときに他の型(とか)で修飾(?)したくなるという状況。
そう。「型を作る」なんですよね、問題は。
Hogeに相当する型を取っかえひっかえして色々なFuga型ファミリーを作りたい、という。
で、俺としては、いいかげん面倒だから、全部動的にしちゃえ、と思っているわけです(笑)。
ただまあ、JavaのGenericの方向性は、C++みたいなドロドロしたものにはならずに済むと聞いてる
(C++のtemplateは導入によって理解が難しくなる(笑)が、GenericなJavaはむしろすんなり理解できる)
んで、まあ有っても良いかなとは思ってますし、必要に迫られりゃ俺も使うでしょうね。
>この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。
出来れば(出来るだけ)、GCの「挙動」なんかに関わらずに済ませたいものです。
Re:よーし (スコア:1)
低いじゃないですか。それが証拠にrubyでいうところのmethod_missingメソッドが無い(笑)。
有るか無いか判らないメソッドを呼ぶ、ってのを、javaは普通の構文で書けないっすよね。
動的にも出来るけど、あくまでそれは特定のクラス(要するにjava.lang.refrect.*ですが)の機能を経由して
はじめて使えるものであって、普通のソースの記述と地続きにはならないでしょ。
つまり動的な要素も秘めてるけどあくまで秘めているというか、静的言語の文法で拘束してしまっている。
#method_missing使いまくりのコードをrubyからjavaに移植したが、
#えらくみっともなくしかならなかった。鬱。
>しかし、それは他のものを犠牲にして得られたものではあるまいか？
>例えば ruby の thread は、(native 化しようという動きはあれど) 基本的にユーザランドスレッドであり、
無関係です。rubyはたまたまユーザースレッドですが、別に動的言語の宿命でもなんでもなく、
OS提供のスレッドを直接使ってる言語はいっぱいあるはず。
とりあえず、Gauche(Schemeの実装。作者は日本人)をWin32に移植しようとしてる某氏の
Threadまわりも含めた奮闘記は、Gauche作者氏のWikiサイト「WiLiKi」で、ただいま好評連載中(違
つまり(?)もともとGaucheはNativeスレッド使うらしいです。
あと…あれ？Pythonってどっちでしたっけ？
勿論、スレッドに限らず広く一般にあらゆるものを失わずに済む、なんてなことは有り得ないでしょうね。
でもそれを言ったらjavaだって何かを失いながら存在しているわけですから。程度問題です。
>「普通のやつらの上を行け」、確かにおっしゃることはごもっともな面もありますが、プログラミング言語というのは、
>その「言語」としてのポテンシャル以外に、どのような「実装」が現存するのか、というのも重要な判断基準でありましょう。
>どんなに優れた言語であっても、優れた実装が提供されない限り、宝の持ち腐れではないですか？
1:「現存するか」じゃなく「現存し得るか」が重要ですね。原理的に無理(＆無理でないにしても超困難)かどうかが重要。そうでないなら頑張って実装すれば済むことですから。
1.5:それどころか実在すらするわけで、そこから先は単に知識(実在を知ってるかどうかという)の問題。
2:「言語の優れた機能」が、しもじも(笑)のOSやハードのNativeなパワーを引き出すことと、イコールとは限らないでしょう。例えばNativeスレッドを使えても本物の末尾再帰を使えなければ、そのScheme実装はSchemeとして失格(=優れてない)なわけで。
>「言語」の持つポテンシャルと、現存する「実装」のクオリティ、それらが高いレベルでバランスしているプログラミング言語こそ
俺的には、Javaの静的っぷりが既に、言語のポテンシャルの低さとして重大な足枷に感じられるんで…。
なんせ最近ご執心なのはPrototypeOOPだもんな。Classすら邪魔だと感じてるところ。
>// …あ、石投げないで～。
意思(発言)は投げておくことにします(藁
>ところで Java は動的度高いと思いますよ。VM 動作させたままクラス定義入れ換えられるし。インターフェイス合わせとけば新旧
「VMは」動的度が高いかも知れませんね。俺も正しい知識はまだ仕入れてないんでよく判ってませんが、
JVM(バイトコード)を使うJava以外の言語実装(つまりその言語のコンパイラがJavaバイトコードを吐く)
は無数に有るようです。その中にはそれこそ動的言語もいっぱいありますから、
きっと動的言語を作る際にも困らないだけの仕組みは持っている(あるいは邪魔物を持っていない？)のでしょう。
で、それはJava「言語」とは別問題。むしろJava言語はJVMの機能を全て引き出していないとも言えるのかも？
動的再構築ねぇ。。。 (スコア:1)
--rena
Re:動的再構築ねぇ。。。 (スコア:3, すばらしい洞察)
これから人的そして経済的 resourceを投入することで、使える未来が開けることでしょう。 将来的には高いレベルで必要とされる物の１つではありますし。
# もしくは使えない未来が確定するか。
userの needsがある程度見込めるって前提で考えれば、結構いいとこいくんじゃないかなと思います。 はやく enduserとして試せる段階に来て欲しいですね。
Re:動的再構築ねぇ。。。 (スコア:2, 参考になる)
「ウチのサーバもDRできるようになりましたよ！」
「すいません、OSのバグがありました。まだ使っちゃダメです。」
「OSのバグが直りましたよ！」
「すいません、USのみです。日本では保守対象外です。」
「今度は大丈夫です！」
「すいません、実はこれこれこういう制限がありまして。。。」
「今度こそ使っていいですよ！」
「すいません、DRはゴールドプラチナスペシャルメニューの
保守加入が前提で、保守費はこれくらいになります。」
なーんてのが繰り返されてきた過去を思い起こすと、まだこの
技術は時間がかかりそうな気がしないでもなかったり。
--rena
Re:動的再構築ねぇ。。。 (スコア:1, 興味深い)
使えた試しがないということ自体は、将来もできないという根拠にはなりえないので心配しなくてもいいかと。
これから人的そして資金を投入することで、使える未来が開けることでしょう。 将来的には高いレベルで必要とされる物の１つではありますし。
# もしくは使えない未来が確定するか。
利用者の需要がある程度見込めるって前提で考えれば、結構いいとこいくんじゃないかなと思います。 はやく一利用者として試せる段階に来て欲しいですね。
Re:動的再構築ねぇ。。。 (スコア:0)
PS3 も DR ちっくですよねぇ。。
PS3 (スコア:0)
グリッドコンピューティングだかなんだか言ってるけど、
クタちゃんの放言をあんまり真に受けないほうがいいよ。
PS2のときも、アナログ回線やISDNでちんたらやるつもりはない、
2001年にはCATVベースの自前ブロードバンド網を構築する、
とかぶちあげておきながら、その後音沙汰なし。
気づいてみれば世の中ADSLブロードバンド真っ盛りで、
Hyper Threading の効果 (スコア:1)
# でも、音うるさい ...
Re:Hyper Threading の効果 (スコア:2, 参考になる)
OSの誤認識？ 発注ミス？ とりあえず、中を確認してみよう。と発注担当の人と一緒に開けてみて、謎が解けました(^^;)。
重くなるかどうかは別問題の様な？ (スコア:1)
無限大の処理能力と帯域幅なんぞ有りはしないのだから
ま、メンテ落ちがなくなるのはいいことだが
Re:重くなるかどうかは別問題の様な？ (スコア:2, 参考になる)
また、需要が読み難いシステムこそグリッドコンピューティングが効いて来るのを考えると、ネットゲームに適用するって良い選択だろうと思うのです。
の
Re:重くなるかどうかは別問題の様な？ (スコア:1)
動的メンテナンスを用いて、軽くなるかどうかはひとえに運営のやり方次第ですね
Re:重くなるかどうかは別問題の様な？ (スコア:1)
こんな感じなら多少読み違えても重くはならないってことでないかな。
もちろん、全てのリソースがこういうわけにはいかないので「運営のやり方」も重要だとは思いますが。
Re:重くなるかどうかは別問題の様な？ (スコア:1)
「今後、IBMが提供するマシンはすべてセル対応になります。また、追加契約により、
お客様が当座は御使用にならない分のCPUパワーをセルのノードとして利用させていた
だき、必要な電力・通信費を基本使用量より差し引くことが可能になります」
とか、こういう方向性ならば、おもしろそうですが。
＃通信帯域に問題なければ、皆契約せんかな？
Re:重くなるかどうかは別問題の様な？ (スコア:1)
その為のグリッドでしょう。
ユーザ一万人を見込んでサーバを立てました。
ユーザが二万人でした。
メンテナンス無しに、サーバを動的に再構成して処理能力を倍にしました。
これが可能になる。と言ってるのでは？
Re:重くなるかどうかは別問題の様な？ (スコア:1)
それに動的っても、稼動中のメンテナンスが可能ってだけで、自己増殖の機械生物じゃないんだから（んなもんあるわけないが）、上限を超えたら結局アウトっしょ
別に動的再構成を否定なんかしてません
動的再構成＝軽いってのが、楽観的意見だって書いてるだけですが？、重くなったら増やそうが無限大に続くわけないと思うんですが？
Re:重くなるかどうかは別問題の様な？ (スコア:0)
だから上限を越えないようにするために再構成や負荷分散をするんでしょうが。無茶苦茶言ってるなぁ。
「無限大に続く」なん
Re:重くなるかどうかは別問題の様な？ (スコア:1)
マシンパワーを二倍になるように構成すればまだなんとかなるんじゃないか？
とも思えるんですが、これがたとえば、一万のユーザを見込んで、
十万のユーザが押しかけたら、動的に構成しなおして十倍の処理能力を持たせればいいか？
と言うとちょっと違う。ただ、そんな的外れな予想をする運営は問題が多そうですけどね。
Re:重くなるかどうかは別問題の様な？ (スコア:0)
いずれにせよ、見込み以上だから増強だぁっても、そんな簡単に予算増やせるのかなぁ
動的再構成で、実際
Re:重くなるかどうかは別問題の様な？ (スコア:1)
Re:重くなるかどうかは別問題の様な？ (スコア:1)
そうそう、来期の予算に盛り込むからそれまで待てとかありそう。
14枚のブレード使い切ったら次はシャーシーを増やさないといけない。
見込んで予算つむくらいなら最初っから買うだろうし。
Re:重くなるかどうかは別問題の様な？ (スコア:0)
Re:重くなるかどうかは別問題の様な？ (スコア:1)
Re:重くなるかどうかは別問題の様な？ (スコア:0)
これならば・・・・・ (スコア:1)
ザ・ワールド (スコア:0)
これはこれで・・・ (スコア:1)
はなんとかなりませんかね～PS2ネトゲ。
Re:これはこれで・・・ (スコア:0)
PS2 本体が３万円、BBUnit が１万８千円っすから、合計４万８千円でとりあえず OK、後 FFXI するためにはキーボードがほぼ必須であることを考えるとそれを加えても５万円ちょっとでネトゲ環境が整うっすよね。
// プロバイダは対応したとこに
Re:これはこれで・・・ (スコア:1)
http://www.zdnet.co.jp/games/gsnews/0302/19/news10.html
なので対応プロバイダに加入しなくても良くなります。
尚、FF11そのものは対応プロバイダは関係ありません。
現状では、BBUを買うためにプロバイダに加入する必要があります。
FF11を例に出します。 (スコア:1)
http://www.playonline.com/polnews/ffxi/list_mnt.shtml
障害復旧には使えないんですよね？
さらに、月1のペースでVerUpがあり、
メンテナンスもその時にやるようです。
バージョンの整合性が取れなくなりそうですし、
整合性を取るのにも費用かかるでしょう。
上のURIで見ると障害多いようですが、サーバのハード的限界ではなく、
VerUp時のバグのようです。
方向性としては「サーバを動的に再構成」とかそういう方向ではなく、
いかにバグを減らすか？にかかってるようです。
Re:FF11を例に出します。 (スコア:1, 興味深い)
サーバ運営側の立場から言えば定期メンテナンスは必須、という認識が一般化してくれると嬉しいなぁ。ソコ以外は絶対止めないように頑張るからさ。