Hadoopは仮想化の流れに逆行するのか？

Shinpei Ohtani @shot6

@guutara まあそんなもんですが、Zenなら変わらない部分多いと思いますｗ

tamagawa ryuji @tamagawa_ryuji

@shot6 「科学が憎い」なら真田さん@ヤマト科学技術班ですが…w

Shinpei Ohtani @shot6

非常に同意です。その制約をいったりきたりです。 RT @guutara: @shot6 @tamagawa_ryuji...

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@shot6 仮想化技術ってさぁ、VM一個だけ、作って動かしたら、物理サーバの資源は、ふるに使える、って、のが、目指す単純な目標だと、おもうんでありますが、凡人は。。なかなか、難しいですよねぇ。。

tamagawa ryuji @tamagawa_ryuji

@Guutara それを究極的にめざしているのがGoogleさんですよね。んー。1980年頃のコンピュータ・サイエンスの理想でもあると思うんですが。「それはちょっと無理ポ」ってとこからスタートしている、ある意味現実路線を行っているのが最近のイノベーションってやつなのかなあと。

Masayoshi Hagiwara @masayh

これは逆で弱み。I/Oを効率的に使っていないと思います。@tamagawa_ryuji @okachimachiorz1 Hadoopって、物理I/O（ディスクやネットワーク）を使い切る仕組みが強みの1つだと思うんで、

Shinpei Ohtani @shot6

@guutara 難しいですねえ。しかしそのオーバヘッドを払っても、運用管理や状態の複製がしやすいなら有意義なソリューションだとは思います。物理層に近い部分を触れば触るほど特化するし、抽象度の高いリソースにすればするほど汎用的におおざっぱに多くのものを扱えます。一般的な話ですが。

チーフ データサイエンティスト@トレジャ @doryokujin

高度なHadoopを巡る談義TLを眺めている

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

@tamagawa_ryuji どうなんだろう？ 昔のGoogleはよくわからないなぁ。あ、最近は、わかりやすくなってる。w 飛んでったきり、かえってこない、と、おかしな人で、飛んでった後、帰ってきて、行動するのが、天才なんでしょうねぇ。どちらも、おなじなのは、高くとぶってこと。

Masayoshi Hagiwara @masayh

@tamagawa_ryuji いえいえ。MapReduceって可用性の保証を単純化するために余計なI/Oをいっぱいするでしょ。それにノード数が増えることで並列性は上げるけど、データ転送量の効率は下がるでしょう。いいアーキテクチャはノード数が少ないよ。たとえば、SFのPodとか。

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

Hadoopは、Stupid だから、とりあえず、はやってる？ w がんばれ！ みたいな。。

Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp @Guutara

分散処理フレームワーク界の "Keep it simple, stupid" Hadoop... 怒られそうだ。。ねよ。

tamagawa ryuji @tamagawa_ryuji

@masayh ああ、なるほど…数式で示せと言われると困りますが（苦笑）、感覚的には分かります。Hadoop/MRは「最善のアーキテクチャ」ではないけども、「これまでは不可能だったレベルの性能を、（使う側のスキルも含めて）現実的なレベルで達成できるシステム」って感じに思えます。

tamagawa ryuji @tamagawa_ryuji

いえいえ、言い得て妙じゃないですか。RT @Guutara: 分散処理フレームワーク界の "Keep it simple, stupid" Hadoop... 怒られそうだ。。ねよ。

Masayoshi Hagiwara @masayh

何かを単純化すれば、別に犠牲を払う必要がある。Hadoopだと可用性と開発の単純化のために、I/O効率を犠牲にしている。よって、必要なノード数が増えて運用管理がたいへんになるのをツールやプロトコルが補っている。それが合理的な問題領域なら使う価値はあるが、いずれ優れた技術に代わる

しみず @shimy_net

たしかに分散処理と仮想化は相反してる。でも常に物理リソースが潤沢にあるわけじゃないので、そんなこんなでAmazonEC2でクラスタ作ってHadoopをぶんまわしています。仮想化とクラウドは別物だろうし、EC2に至っては別次元のサービスな気がします。

Masayoshi Hagiwara @masayh

その点での貢献はとても大きいと思います。同意します。@tamagawa_ryuji 、「これまでは不可能だったレベルの性能を、（使う側のスキルも含めて）現実的なレベルで達成できるシステム」って感じに思えます。

tamagawa ryuji @tamagawa_ryuji

また新たなブレークスルーがきっとでてくるってことですよね。楽しみがつきないです。多少なりともその端っこくらいにはいたいものです。精進せねば。　@masayh それが合理的な問題領域なら使う価値はあるが、いずれ優れた技術に代わる

tamagawa ryuji @tamagawa_ryuji

@Guutara ブレークスルーって、やっぱりしがらみをバッサリきったところから出てくることが多いと思うんです。でも、ブレークスルーが一般に普及してくると、またどうしても別のしがらみがまとわりついてきてしまうのは、もうしかたないんだろうなと思いますねえ。

Kenichiro HAMANO @hamaken

Hadoopと仮想化の議論が盛り上がってるなぁ。まぁ、性能で不利なこともあるけど、収容設計の前提条件がなかなか成立しないので、相性はよくない。

Kenichiro HAMANO @hamaken

仮想化でI/O性能が5%違うとすると、1000台のクラスタで50台分、300台で15台分がロスになる。普通は許容されない。 でも、クラスタサイズが10台くらいなら、仮想化で得られる運用上の利便性のメリットの方が大きくなることもある。 結局はクラスタサイズとか用途によるって話。

Kenichiro HAMANO @hamaken

Hadoopをデータ蓄積プラットフォームとしても使いたいか、それとも比較的中小容量のデータ対するバッチ処理基盤として使いたいかにも寄る。 大容量データの蓄積をするなら、まず仮想化は都合が悪い。

Kenichiro HAMANO @hamaken

小規模Hadoopクラスタを仮想化上で構成する場合、よーく設計しないと可用性を大きく失う。多重故障に対する耐性が変わるので、当たり前だけど。

Kenichiro HAMANO @hamaken

そもそも、Hadoopってインテリジェントな仕組みというよりは、スマートなアイデアに基づいているものの、最後はパワーで押し切る仕組みなんだよね。

Shinpei Ohtani @shot6

同意。ということは、ボリュームにはフレキシビリティが必要とは思います。　RT @hamaken: そもそも、Hadoopってインテリジェントな仕組みというよりは、スマートなアイデアに基づいているものの、最後はパワーで押し切る仕組みなんだよね。