クラウドコンピューティングと Map/Reduce 自己紹介（１） • 大阪市立大学大学院 創造都市研究科の学生です – １８年間続けたサラリーマンをやめて学生からやり直し • 儲かるネタを探しに言ったとも言う • もともとはＯＳ屋（正確にはUNIXカーネル屋）でした – ２００６年春に修士号を取得 • でも儲かるネタは掴めず・・・やむなく学生を続行 – 現在博士課程の３回生です • 生活に追われＤになってから論文を書いてない • Ｄ６で修了を目指すつもり・・・学生生活は十分満喫したい – 研究テーマは「構造化オーバレイ」です。 • アルゴリズムよりも応用を考えています • 修士時代は“Ｐ２ＰＤＢ”とか言ってました • ２００７年初頭に「Ｐ２Ｐでサーチエンジン」みたいな提案を書いた 自己紹介（２） • IIJ Innovation Institute の研究員です – 指導教官にハメ ^H ^H 強く勧められました • さっきの提案で応募したら・・・受かっちゃった • 「２年で起業」・・・どのみち起業するつもりだったんだけど – で・・・さっきの提案を実現しなければならなくなった – というわけで Map/Reduce なわけです • サーチエンジンを実現するフレームワークですからね • 構造化オーバーレイ技術を導入するとしたらココ • 事業化するとしたらソリューションもいるよね – というわけで公開実験とか開始しています • 現在α公開中 β公開には今しばらく掛かりそう • 詳細は最後で紹介します Map/Reduceに対する僕の立場 • 原則的に丸山先生と同じです – 事業化を目指さなければならないのでちょっとズレるけど・・・ – もともと構造化オーバーレイの応用対象としてGoogleのアーキテ クチュアは勉強していました（２００６年～２００７年前半） – 当初は中のほうに関心があった（GFSとか、Chubbyとか） – Map/Reduceを始めたのは割と最近 – 今は Hadoop でやってます （またまた Java かよ・・・） • 現在、公開実験をネタに営業回りしています – Map/Reduce をフロントにした提案をせざえず・・・ – 散々な目にあってます（これ本当） – ようやく今日のお題に辿りつきました CaseStudy1: 某社営業への説明 • ＳＩ事業の可能性を求めてグループ内外の各社にコンタクト – 親会社の営業部隊は土管屋さんなので・・・ • Map/Reduceをフロントにしたプレゼンを行う – 営業さんなのでちゃんと話を最後まで聞いてくれる – Map/Reduceの核心になってくると「？？？」の様子 • ひと通り説明が終わったところで古参の営業マンが一言 – 「いやぁ、僕は昔から思うんですけど・・・ クラスタで動く分散UNIXみたいなものがあれば 一気に問題解決じゃないですか？」 • 「そんなことが実現可能なら今頃 CMU の Mach microkernel が市場を席巻してる！！」と心でつぶやく CaseStudy2: 某ＩＳＰの運用部隊 • 事業性の高いアプリケーションのネタを探してコンタクト – 既に Hadoop を使っているとのことなので プレゼンは大幅にカット・・・そのままディスカッション – テクニカルには非常に有益なコメントをもらえる • 僕が Map/Reduce というキーワードを連呼しすぎたの で・・・ – ポロっと一言「なんでそんなに Map/Reduce に拘るんですか？」 – 続けて一言「 Map/Reduce に書き直すコストを考えると・・・」 • 思わず・・・ – 「コスト・セービングの手段でしかないと考えてる？」と言いそうに なって言葉を飲み込む – あとで「そんなこと言ってるから先細りなんだ」と心で毒づく CaseStudy3: 某大学の大先生 • データベース方面の展開を目論んでその道の大家にコンタクト • プレゼンの冒頭で Map/Reduce といった途端・・・ – いきなり顔が険しくなって・・・ – 途中で話をさえぎり唐突にブチ切れて・・・ 「そんなことは２５年前からやっている」 「今どきそんな間抜けな研究をやっている奴はいない」 – その後「単純化されすぎたインターフェース」とか 「どうしようもなく信頼性が低い」・・・などなど突っ込みまくられ • 部屋を追い出される寸前までいったところで・・・ – 「そもそもSOSPでの研究発表で」って言うから 「僕は元々カーネル屋です」って言ったら 「それなら理解できる」と急に機嫌が直った • 狐につままれたような心持で、そのまま早々に退散 みんな、なんか勘違いしてんじゃねぇ か？ • 多くの人が「クラウド」の名の下にかつての「分散ＯＳ」の 幻想を追っているようにしか僕には見えません – みんな９０年代以降の分散システムの研究者の七転八倒ぶりを 知らんの？ – 知りたければ ACM Symposium on Operating Systems Principles (SOSP) のホームページを見るといい (http://sosp.org/) • 最も端的な事例は・・・ – この分野での権威であるタネンバウム先生の著作「分散オペ レーティング・システム」は、さりげなく「分散システム」に改題され て、 さらにさりげなく Web システムの解説を載せたりしてます – 未だに「分散オペレーティング・システム」の翻訳本を販売してい る日本の出版社の良識を疑っちゃうよね 分散オペレーティングシステムの幻想 • 分散ＯＳは１９９０年～１９９３年あたりのブームです – 商用化の最有力候補は CMU Mach Operating System でした – UNIX War の片割れ OSF の標準カーネルに採用され 巨額の開発資金を投入して文字通りガリガリ開発してた – 某国産メーカーにいた３０歳の僕はCMUのビジターとして その周辺をウロウロしていました • が・・・伏兵 Windows 3.1 の登場により総崩れ – – – – – 世間では UNIX War の終焉ばかりが注目されてたけど・・・ もちろん CMU Mach はちゃんと動いてました でも・・・遅い、とてつもなく遅い CMU のハッカー集団がよってたかってチューニングしたけど・・・ どうにもならないくらい遅い（UNIXコマンドは普通に動いたけど） 分散ファイルシステムの割り切り • 分散ファイルシステムは２０年前から実用化されてました – やはり NFS は偉大です。特にその割り切り方が。 – ファイルシステムとしては問題アリアリなんですけどね – 当時の（今も？）ユーザーニーズの大多数に答える 理想的な商用プロダクトでありました – この成功で過信した Sun はその後大失敗をしましたが・・・ • でもグローバル・ファイルシステムになると・・・ – – – – インターネットを覆う分散ファイルシステムのアイデアです CMU も Andrew Filesystem を開発してました ユーザーのホームディレクトリも AFS の下にありました 遅さに根を上げたユーザーはローカル・ディスクで作業してました ここだけにしておいて欲しい僕の本音 • ISPに養われている身分で言うのもなんですが・・・ – 当時の分散ＯＳ屋の失敗はTCP/IP を信用しすぎたこと • 結局 TCP/IP は・・・ – サルみたいに deploy するしか脳のないネットワークである – それをさも意味ありげに仕立てたのは Berners-Lee の功績 • でも信頼できるネットワークを作ろうとすると・・・破綻する – Open Systems Interconnection (OSI) とかありましたよね？ – ８０年代のキャリアは「最終的にはＯＳＩに集約」とか言ってました • 教訓から得られる分散システム設計の今日的なアプローチは・・・ – 全てのニーズの解決は考えずに大多数の（金になる）ニーズだけを キッチリ満たす・・・という割り切りが大事 僕が構造化オーバーレイに執着する理由 • ネットワーク経由のデータ・アクセスを確率論的な視点で 理解しようとしているように見えるから – TCP/IP はデータ・アクセスをヒューリスティックにしてしまう – ならば・・・想定外事象の発生の確率をレアケースにできる程度 にデータ自体を deploy してしまえば良い – 確率論的な量として性能を保証することができる？ • 最大のデメリットはセキュリティ – ここは暗号化アルゴリズムの研究者に頑張ってもらう • 解決すべき課題は – オーバーレイ・ネットワークを構成するノードの上位に来る何かを あきらかするモデルの定義・・・だと思ったり • 性能評価の指標として確率論を導入するのが割り切り – 数値化できないと安心できない人が多いからねぇ 僕がMap/Reduceに執着する理由 • 並列実行環境でのJobの概念をシンプルに定義できてる ように見えるから – そもそも Process はタイム・シェアリングのために生まれた概念 – 現在の Process Context はノード（とそのローカルストレージ） に対しての依存性が大きすぎる → だからMachのプロセス・マイグレーションは破綻した – 並列実行を前提にするなら処理実行に関するモデルを組み立て なおすべきなのでは？（あくまでも仮説ですよ。仮説） • Map/Reduceのモデルはブレークスルーに繋がる？ – 今のところはなんとなくそう思っているだけ・・・ • 少なくとも・・・ – ドライバを書いてるだけがカーネル屋の仕事ではないよね！！ クラウドとMap/Reduceは関連するの？ • 僕の個人的な見解は・・・ – そう考えないと僕らがクラウドに手を出せる余地がない • Google は技術を手段と割切っている会社です – 事業的な優位性を確保するためなら どんどん新しい技術に乗り換えるでしょう – だから Google が Map/Reduce を公開しないのは当然 • 仮想サーバーを実現するクラウドのアプローチは遠から ず破綻すると思う – Amazon が分散ストレージを提供する限りは事業性はある – それ以上のリッチな環境の実現を目論むと破綻するのは過去の 分散システム研究からの教訓より明らか・・・だと思う Map/Reduceが生み出すソリューション • データベース分野は直近の事業化ネタはなさそう – 信頼性に関する技術的進展がないと案件で揉めることは必定 – 当面は丸山先生の啓蒙活動に期待するしかないです • 情報検索系分野は需要があるみたいですねぇ – Hadoop 周辺でオープンソース実装が多数存在します – 現時点でどの程度の事業量が見込めるのかは掴んでません • 稼働情報解析分野は潜在的需要があります – ログ解析とかね・・・処理の高速化がニーズになっています – 親会社にアタックしてますが通信事業者の約款に阻まれ敗退続き – 誰か紹介して・・・ Map/Reduce(Hadoop)の性能 • 並列実行により処理の高速化が有意な領域 • 実際に並列処理の効果が上がるのはどういう条件？ • Hadoop を使ってベンチマークをしてみました – RandomWriterでランダムデータを生成 – Sortでランダムデータをソート – 条件 • NameNode+JobTracker+Slave*18 • データサイズ：１ＭＢ～１００ＧＢ • データ分割数：１６ – 処理時間を計測（Sortが表示する時間） • 結果：データサイズが１ＧＢ以上なら効果あり？ Map/Reduce(Hadoop)の性能 データサイズと処理時間の関係 SO R T SA 多項式 (SA ) 多項式 (SO R T) 4000 3500 処理時間（秒） 3000 2500 2000 1500 1000 500 0 1 10 100 1000 データサイズ（ＭＢ） 10000 100000 Map/Reduce(Hadoop)の性能 データサイズと処理時間の関係（拡大） SO RT SA 多項式 (S A ) 多項式 (S O R T) 600 500 処理時間（秒） 400 300 200 100 0 10 100 1000 データサイズ（ＭＢ） 10000 Map/Reduce(Hadoop)の性能 データサイズと処理時間（データ転送時間付き） SO R T SA G ET 多項式 (SA ) 多項式 (SO R T) 多項式 (G ET) 12000 10000 処理時間（秒） 8000 6000 4000 2000 0 1 10 100 1000 データサイズ（ＭＢ） 10000 100000 まとめ • というか僕の勝手な思い込みなんですが・・・ – 確かに一定のデータサイズ以上であれば Map/Reduce を使うと 高速化される – でも、そのデータを転送するコストは比較にならないほど大きい → 単純な並列実行エンジン・サービスの事業性は？ – 事業化では並列実行の高速性が生かせて データ転送コストが問題にならないシステムが必要 → システム・インテグレータのビジネスチャンス？ • そのあたりに構造化オーバーレイをうまく生かせない か？画策している最中です・・・詳細はまた今度。
© Copyright 2024 ExpyDoc
