新しいことをしよう
皆さんは「Hadoop」をご存じでしょうか。Googleの大規模分散処理技術を模したオープンソースソフトウエアで、安価なPCサーバーを連ねて数テラ～数ペタバイトのデータを解析できます。既に米国では、米Visaや米JPMorgan Chaseのような大手金融機関もHadoopを大規模に利用し始めています。2009年11月には日本にも「Hadoopユーザー会」が発足しました。 記者は2009年11月16日に開催された「Hadoop Conference Japan 2009」で、「データセンター視点で考えてみるHadoop」という簡単なスピーチをさせてもらいました。その内容が意外に好評だったので、本欄でスピーチを「誌面再現」してみたいと思います。なお、同イベントの他の発表については、記者が執筆した記事をご覧ください（関連記事：分散処理ソフト「Hadoop」のユーザー会が日本で発足、企業の導入が
United States Patent: 7650331
Barroso, L.A., et al., "Web Search for a Planet: The Google Cluster Architecture," IEEE Micro, 23(2):22-28, Apr. 2003. cited by other . Ghemawat, S., et al., "The Google File System," 19th Symposium on Operating Systems Principles, pp. 29-43, Lake George, New York, 2003. cited by other . Rabin, M.O., "Efficient Dispersal of Information for Security, Load Balancing and Fault Tolerance," Journal of
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 （この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題」の続きです） キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に（友人たちの）情報を集めることがで
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題
Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）～800億枚の写真データとPHPのスケーラビリティ問題 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の巨大なシステムは、3つのデータセンターにある約3万台のサーバと、PHP、C++、Memcache、MySQLなどのソフトウェア群によって支えられています（同社のデータセンターの巨大さは、記事「3億のユーザーを抱えるFacebookのデータセンター。移動は自転車、希望は100Gbイーサネット 」を参照）。 同社の技術担当バイスプレジデント Jeff Rothschild氏は、Facebookが実現している大規模なスケーラビリティを、いかにしてこれらのソフトウェアで実現しているのか、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Mas
優良企業はなぜHadoopに走るのか
ちなみに、この分析のために必要とされるMapReduceのコードであるが、そのサイズはわずか20ステップだという。Yahoo!のプレゼンテーターである、エリック・バルデシュバイラー氏によると、たとえ経験の浅いエンジニアであっても、MapReduceによるプログラミングは可能であるとされる。 また、VISAのジョー・カニンガム氏からも、貴重なデータが提供されていたので以下に紹介する。同社では、1日に1億トランザクションが発生するため、2年間で700億強のトランザクションログが蓄積され、そのデータ量は36テラバイトに至るという。こうしたスケールのデータを、従来のRDBを用いて分析するには、約1カ月の時間が必要とされてきたが、Hadoopを用いることで13分に短縮されたという。 これまでは、Yahoo!にしろVISAにしろ、膨大なデータをRDBに押し込むほかに方法はなく、その分析に数十日を要する
BrewersCapTheorem - ブリュワーの CAP 定理
BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日本語訳です. http://www.julianbrowne.com/article/view
Fast Paxos recovery - Google Patent Search
What is claimed is:1. A method for resolving conflicts in a distributed computer system implementing distributed fault-tolerant consensus algorithms, the method comprising:performing a distributed fault-tolerant consensus process in the distributed computer system comprising a plurality of devices, wherein each device votes for proposals received directly from a client and generates vote messages
SOSP 2009適当まとめ - moratorium
SOSP 2009適当まとめ 2009-08-24 (Mon) 4:39 Uncategorized システム系では最高峰の学会SOSPの最新の論文が公開されていたのを見つけたので、適当に流し読みしてみました。 SOSP 2009: Technical Programs 主に僕の興味の有るやつになります。無いのはリストにすら入ってないので、ご注意を。特にセキュリティ周りとか。しかしHadoopを利用した論文が結構多い。MapReduce流行り過ぎ。 - FAWN: A Fast Array of Wimpy Nodes 遅いCPUとFlashドライブを並べて低消費電力なストレージを作るというアーキテクチャ「FAWN」を提案。この上に「FAWN-KV」と呼ばれるKey-Value Storeを作成し、実験を行った。Chain-Replication、ノード追加時のプロトコル等が詳しく載って
Bigtableの内部構造 - スティルハウスの書庫の書庫
Bigtableの概要 Bigtableとは 構造化データを管理するための分散化ストレージ 膨大な数の汎用サーバーをつなげてペタバイト規模のデータを扱えるよう設計されている Bigtableの歴史 およそ7人年の開発作業を経て、2005年4月からプロダクション利用を開始 2006年時点では、Googleの60以上のプロジェクトがBigtableを利用 検索, Analytics, Finance, Orkut, Earth, YouTube, Mapなど Bigtableが動くサーバーの構成 ＜Googleの典型的なクラスターノード構成：引用元＞ 個々のノードの基本構成 Intelベースの安いPC Linux OS Schedulerスレーブ Schedulerマスターの指示に従ってノード上に各種サービスをデプロイする GFSチャンクサーバー GFSのチャンク（データ）を保存する タブレッ
memcachedを超える成果も、Interopで若手技術者がクラウドを支える技術を競う
「日本でゼロからクラウドを生み出すムーブメントを作り出したい」（実行委員長 門林雄基氏）---“クラウドを支える技術”の開発力を競う「クラウドコンピューティングコンペティション」が2009年6月11日、Interop 2009の会場で開催された（写真1）。企業や大学・大学院の研究者、そして高校生を含む若手エンジニアが、新しいアイディアと技術力で作り上げたクラウドコンピューティングの基盤ソフトウエアを披露した。 クラウドコンピューティングコンペティションは、奈良先端科学技術大学院大学の門林雄基准教授らの呼びかけで実現したイベント。若手のエンジニアがP2P（ピア・ツー・ピア）技術や分散データ処理技術といったクラウドコンピューティングの基盤技術を開発し、その成果を競う。検証環境として、情報通信研究機構（NICT）が運用するクラスタ環境「StarBED」のコンピュータを最大1000台まで使用可能で
Google Wave アーキテクチャ
原文(投稿日：2009/6/1)へのリンク Google Waveは3つの要素で成り立っている: ツール、プラットフォーム、そしてプロトコルである。そのアーキテクチャの核は、並行制御をサポートするための理論的フレームワーク、オペレーショナルトランスフォーメーション（OT=Operational Transformation）である。 まず最初に定義が必要だろう。Google Waveとは: （ウェーブと呼ばれる）ホストされたXMLドキュメントをベースとした、並行に行われる変更と遅延の少ない更新をサポートする、新しいコミュニケーションとコラボレーションのプラットフォームである。 ツール Google Waveは「電子メールプログラム＋インスタントメッセンジャー＋協調的な文書共有と編集ツール」である。クライアントサイドではJavaScriptとHTML5を使っており、Chrome、Firefo
開発チームが明かす、Google Waveの実装概要 － ＠IT
2009/06/01 グーグルが発表した新しいコミュニケーションプラットフォームの「Google Wave」が大きな反響を呼んでいる。技術的な詳細がかなり明らかにされているので、何が可能かはだいたい予想ができそうだが（だからこそ発表時に会場を埋めていた4000人あまりの聴衆は興奮のあまり立ち上がって喝采を送ったのだが）、誰も想像できなかったようなキラーアプリケーションが登場するのかどうか、あるいはWave自体がキラーアプリケーションなのか、それはまだ誰にも分からない。 レポート記事（【詳報】Google Waveとは何なのか？）への反響を見ると、さまざまな疑問を感じている人がいる。そこでここでは、直接Waveのプロジェクトリーダーに話を聞いたり、別セッションで開発チームが行った説明、およびオンラインドキュメントから読み取れたことなど、いくつか追加情報をまとめたい。ちなみに、Google I
クラウドの一貫性って - noopな日々
CAP定理というのは、 Consistency Availability Partitions という状態の2つまでしか達成できない。３つすべてを達成することはできないという定理である。例えばConsistency（一貫性）とAvailability(可用性)を同時に満足させるとPartitions(分散)を達成するのをあきらめるしかない。可用性と分散性を同時に満足させるにはConsistency（一貫性）をあきらめる。すなわちEventually Consistentな状態を受け入れる。 そーゆー状態を受け入れるとスケーラビリティを達成できるようになるので、巨大なデータセンターの中に安いPCサーバーを大量においてCAPのCを若干犠牲にしつつ、高速なデータ処理を行う。そのような計算モデルである。 クラウド時代の計算パラダイムがRDBMSが30年間研究開発していたACIDパラダイムからCAP
Lessons from Internet Services: ACID vs. BASE Dr. Eric A. Brewer UC Berkeley Inktomi Corporation
Dr. Eric A. Brewer UC Berkeley Inktomi Corporation 11/15/98 Click here to start
Willkommen auf monoceres.uberspace.de!
Willkommen auf monoceres.uberspace.de! Welcome on monoceres.uberspace.de! Diese Domain kennen wir leider nicht. Sadly, we do not have this domain in our records. Sollte sie dir gehören, kannst du die Domain, wie im Manual beschrieben, auf deinen Uberspace aufschalten. In case it is yours, take a look at the manual to add it to your account.
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(
yohei-y:weblog: CAPのCとACIDのC
CAP 定理と BASE の概念を考えたのは UCB の Brewer 先生で、彼は inktomi の偉い人だったというのは前回述べた。 当時のinktomiはYahoo!や Microsoft、それにgooにも検索エンジンを提供していて、1億以上のWebページ(テラバイト級のデータ)を扱っていたようだ。 手元のWEB+DB PRESS Vol.49 のはてなブックマークリニューアル記事によると、現在のはてなブックマークは1160万URLと100GBのHTMLデータ(圧縮済み)を扱っているらしいので、ざっくりいって98年の時点でinktomi は現在のはてブの10倍のデータを扱っていたといってもいい。inktomiで使っていたコンピュータの性能は現在のPCサ ーバに比べれば1/10程度の性能なので、システム全体でみると現在のはてブの100倍の規模になるだろうか。 結果的には、inktom
RubyでHadoopをラップ、分散処理ツールキットが登場 － ＠IT
2009/05/12 米新聞社大手のニューヨーク・タイムズは5月11日、Rubyによる大規模分散処理のツールキット「Map/Reduce Toolkit」（MRToolkit）をGPLv3の下にオープンソースで公開したと発表した。MRToolkitは、すでに稼働しているクラスタ上のHadoopと合わせて使うことでRubyで容易にMap/Reduce処理を記述することができる一種のラッパー。処理自体はHadoopが行う。すでにHadoopを使っているユーザーであれば、中小規模のプロジェクトに対して、すぐにMRToolkitを適用可能としている。 デフォルトで有用なMap、Reduceの処理モジュールが含まれていて、数行のRubyスクリプトを書くだけで、例えば膨大なApacheのログからIPアドレス別の閲覧履歴をまとめるといった処理が可能という。独自にMapやReduceの処理を定義することも
yohei-y:weblog: CAP と BASE について調べたこと
時系列で 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る CAPとBASEの基礎ができる http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/ 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表 CAP は Brewer 予測として知られるようになる この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化 ここで Brewer の CAP が晴れて定理となった この間、よくわからず 2007年-: eBay の
Eventually Consistent - Revisited
Eventually Consistent - RevisitedDecember 23, 2008 • 3261 words I wrote a first version of this posting on consistency models about a year ago, but I was never happy with it as it was written in haste and the topic is important enough to receive a more thorough treatment. ACM Queue asked me to revise it for use in their magazine and I took the opportunity to improve the article. This is that new v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
