Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
ULS Copyright © 2010 UL Systems, Inc.
社内勉強会
「Googleを支える技術」の解説
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems...
ULS Copyright © 2010 UL Systems, Inc. 1
書籍紹介
 「Googleを支える技術」という書籍を取り上げます。
 2008/3/28に出た書籍です。Google App
Engineが出る数ヶ月前に、Go...
ULS Copyright © 2010 UL Systems, Inc. 2
相手にするマシン数を考えてみる
 Googleの「小規模データセンター」
– 数千台のマシン規模のものを「小規模」と呼びます。
 Googleの「大規模データセ...
ULS Copyright © 2010 UL Systems, Inc. 3
日本の大規模データセンターの例
 さくらインターネットの大規模データセンター:60万台規模
ULS Copyright © 2010 UL Systems, Inc. 4
単純計算でのメモリー、HDD容量の皮算用
 Googleが2003年頃に用いていた1ノードあたりの能力はそれほど高くなく、以下のよ
うなものだったようです。当時の...
ULS Copyright © 2010 UL Systems, Inc. 5
アーキテクチャを考える上での前提知識
ULS Copyright © 2010 UL Systems, Inc. 6
C10K問題 (クライアント1万台問題)がクラスタの上限を決める
 C10K問題というのは、1台のサーバーマシンは、ソフトウエア側の制限によっ
て、おおよそ1万台...
ULS Copyright © 2010 UL Systems, Inc. 7
マシンが大量にあると、どれか壊れる
 1台あたりの稼働率が99%のマシンを大量に使った想定で、全部が問題なく
動作する稼働率をグラフにすると・・・。数十万台なら?...
ULS Copyright © 2010 UL Systems, Inc. 8
パオーマンスを引き出す原則
 [原則1]読み取りスピードを上げるには複製を作る
マスター系データのようにデータが変化しにくいものに関しては、複数台マシ
ンにデータ...
ULS Copyright © 2010 UL Systems, Inc. 9
Googleのアーキテクチャ
ULS Copyright © 2010 UL Systems, Inc. 10
取り上げる技術
 この勉強会では書籍で紹介のあった以下の技術を取り上げます。
 上記のすべての仕組みはC10K問題の範囲内での動作が前提です。
 すべてのア...
ULS Copyright © 2010 UL Systems, Inc. 11
全体アーキテクチャ
 アーキテクチャの全体構成を以下に示します。
Chubby
Bigtable+MapReduce GFS+MapReduce
利用
各種ロッ...
ULS Copyright © 2010 UL Systems, Inc. 12
Chubby
 分散ロックサービス
 イベント通知
 (Hadoopには該当サービスは無い)
Chubby: 「まるぽちゃの」の意味
ULS Copyright © 2010 UL Systems, Inc. 13
Chubbyとは
 Chubbyは本質的には1台のサーバーによって提供されるリモートディスクです。
リモートディスク上にファイルを作ることでロックを実現します。...
ULS Copyright © 2010 UL Systems, Inc. 14
Chubbyの使われ方
 BigtableやGFSはファイルのロックやレコードロックの仕組みを持っていない
ため、これを補完する目的で用いられます。ファイルのロ...
ULS Copyright © 2010 UL Systems, Inc. 15
Chubbyが耐障害性のためにやっていること
 Chubbyは実際には5台のマシンから構成されます。この5台のマシンを
「Chubbyセル」と呼びます。この中の...
ULS Copyright © 2010 UL Systems, Inc. 16
GFS (Google File System)
 ペタバイト規模の分散ファイルシステム
 HadoopではHDFSが該当
ULS Copyright © 2010 UL Systems, Inc. 17
GFSとは
 GFSはログのような末尾追記型の書き込みと、大量の読み出し要求に応えることに特
化した分散ファイルシステムです。
GFSが得意なこと
大量の読み...
ULS Copyright © 2010 UL Systems, Inc. 18
GFSのアーキテクチャ
 以下にGFSのアーキテクチャを示します。
Chubbyのロックの取り合い
によって複数台のマスタ候補
からマスタは選択される。
1つの...
ULS Copyright © 2010 UL Systems, Inc. 19
追記処理の挙動
 GFSでは追記の一塊のデータを「レコード」と呼びます。1レコードは16MB以下である
必要があります。書き込まれるレコードは一旦メモリーに貯め...
ULS Copyright © 2010 UL Systems, Inc. 20
読み取り処理の挙動
 GFS上の1つのファイルは64MBずつのチャンク(パケット)に分割され、保存されていま
す。また、1つ1つのチャンクは最低3つの別のチャン...
ULS Copyright © 2010 UL Systems, Inc. 21
Bigtable
 構造データのための分散ストレージ
 HadoopではHBaseという名前で提供
ULS Copyright © 2010 UL Systems, Inc. 22
前提知識:分散KVSについて
 スケールアウトが容易にできる「分散KVS(NoSQL)」が、クラウドの世界では必須の
ものとなりつつあります。分散KVSは数千台...
ULS Copyright © 2010 UL Systems, Inc. 23
GFSは分散KVSの一種
 GFSはKVSの一種です。Keyの構造が特殊で、テーブルのような論理データ構造を扱
えるようになっています。
 通常のKVSではK...
ULS Copyright © 2010 UL Systems, Inc. 24
タブレットの読み書き方法
 Bigtableの読み書きの基本はタブレット操作です。以下に処理内容を説明し
ます。
 書き込み方法
書き込みはコミットログに内容...
ULS Copyright © 2010 UL Systems, Inc. 25
Bigtableを利用しているシステム
 Googleのクローラ
– クロールしたhtmlデータを保存するために使っているそうです。
 Google Maps...
ULS Copyright © 2010 UL Systems, Inc. 26
MapReduce
 分散処理のための基盤技術
 HadoopでもMapReduceという名前で提供
ULS Copyright © 2010 UL Systems, Inc. 27
MapReduceとは
 大量のCPUがある環境で簡単に分散処理を動かす時の考え方として、計算ノードに
IDを付け、その計算ノードにプログラムとデータを送りつけ...
ULS Copyright © 2010 UL Systems, Inc. 28
コピー処理が無い方がパフォーマンスが出る
 MapReduceはGFSのデータでもBigtableのデータでも動作します。GFSもBigtable
も、元々デー...
ULS Copyright © 2010 UL Systems, Inc. 29
おしまい
Nächste SlideShare
Wird geladen in …5
×

「Googleを支える技術」の解説 2010.08.23

2.097 Aufrufe

Veröffentlicht am

Googleの技術を紹介した貴重な書籍として、「Googleを支える技術」という書籍があります。Googleが公開している特許情報や論文などを元に、日本人の著者がその全体像をまとめた本です。

今回の勉強会では、この書籍をベースとして「クラウド技術」と呼ばれている技術の中身を紹介します。

Veröffentlicht in: Software

「Googleを支える技術」の解説 2010.08.23

  1. 1. ULS Copyright © 2010 UL Systems, Inc. 社内勉強会 「Googleを支える技術」の解説 ウルシステムズ株式会社 http://www.ulsystems.co.jp mailto:info@ulsystems.co.jp Tel: 03-6220-1420 Fax: 03-6220-1402 2010年8月23日 講師役:近棟 稔
  2. 2. ULS Copyright © 2010 UL Systems, Inc. 1 書籍紹介  「Googleを支える技術」という書籍を取り上げます。  2008/3/28に出た書籍です。Google App Engineが出る数ヶ月前に、Googleが公開し ている論文等を元に西田 圭介という日本人に よって書き下ろされた本です。  内容は、Googleの開発してきたアーキテクチ ャの紹介を含んでいます。この本の著者が参 考にしている情報を元に、Hadoopも作られて います。 http://research.google.com/pubs/papers.html このサイトに論文がPDFで 配布されています。
  3. 3. ULS Copyright © 2010 UL Systems, Inc. 2 相手にするマシン数を考えてみる  Googleの「小規模データセンター」 – 数千台のマシン規模のものを「小規模」と呼びます。  Googleの「大規模データセンター」 – 数十万台のマシン規模のものを「大規模」と呼びます。 (「小規模データセンター」の100倍のマシン数に相当)  規模感を感じるために、現在のスーパーコンピュータの規模を考えてみると・・ (単純比較は危険だけど) 日本の「地球シミュレータ」 8CPUの計算ノードを160台繋げたもの。 計1,280CPUで動作。 世界第2位 アメリカの「Roadrunner」 6,912個のAMD Opteronプロセッサと PowerXCell 8i 12,960個で動作。 世界第1位 アメリカの「Jaguar」 224,256個のAMD Opteron プロセッサコアで動作。 OSはLinux。 最近10位以内に入っているスパコンのCPUは、AMDの Opteronか、IntelのXeonか、IBMのPowerが使われて いる。OSは、ほとんどLinux。
  4. 4. ULS Copyright © 2010 UL Systems, Inc. 3 日本の大規模データセンターの例  さくらインターネットの大規模データセンター:60万台規模
  5. 5. ULS Copyright © 2010 UL Systems, Inc. 4 単純計算でのメモリー、HDD容量の皮算用  Googleが2003年頃に用いていた1ノードあたりの能力はそれほど高くなく、以下のよ うなものだったようです。当時の高性能サーバーはメモリ64GB程を載せていたようで すので、かなり安めのサーバーを使っていたようです。 – CPU Xeon 2GHz x 2個 ← Xeonはスパコンでもよく用いられるCPU – メモリー 2GB – HDD 80GB  Googleの「小規模データセンター」:数千台 – メモリー 数TB – HDD 数百TB  Googleの「大規模データセンター」:数十万台 – メモリー 数百TB – HDD 数十PB たとえば、この広大なメモリー空間を使って何が出来るかを考えてみてください。 普通のデータ規模なら、すべてのデータをメモリーに乗せてしまうことも可能で す!
  6. 6. ULS Copyright © 2010 UL Systems, Inc. 5 アーキテクチャを考える上での前提知識
  7. 7. ULS Copyright © 2010 UL Systems, Inc. 6 C10K問題 (クライアント1万台問題)がクラスタの上限を決める  C10K問題というのは、1台のサーバーマシンは、ソフトウエア側の制限によっ て、おおよそ1万台程度のクライアントまでしか捌けないという問題です。 なお、大抵のハードウエアは1万台以上の接続に耐えられるようです。  C10K問題とデータセンターとの関係 – 小規模データセンターで数千台、大規模データセンターで数十万台のマシンがある として、それらをうまく協調させるための中心となるサーバーマシンを置くとすると、 このC10K問題が関係してきます。 中心となるサーバーと接続を持つマシン達の上限が1万台という制約を持つと、小 規模データセンターでは大丈夫ですが、大規模データセンターではうまくハンドリン グできなくなって来ます。 1つのクラスタは、おおよそ1万台まで ただし、上記のように中心となるマシンが居ない構成も考えられ、その場合はこの制約を超えられます。 たとえばCassandraはこのような構成になっています。Googleの場合、このような構成は取っていません。 マスター クラスタ
  8. 8. ULS Copyright © 2010 UL Systems, Inc. 7 マシンが大量にあると、どれか壊れる  1台あたりの稼働率が99%のマシンを大量に使った想定で、全部が問題なく 動作する稼働率をグラフにすると・・・。数十万台なら? 全 体 の 稼 働 率 (% ) マシン台数 つまり、どれかのマシンは 大抵壊れている。
  9. 9. ULS Copyright © 2010 UL Systems, Inc. 8 パオーマンスを引き出す原則  [原則1]読み取りスピードを上げるには複製を作る マスター系データのようにデータが変化しにくいものに関しては、複数台マシ ンにデータのコピーを作ると、読み取りパフォーマンスが向上します。  [原則2]一過性のコピーを可能な限り排除(目指せ「ゼロ・コピー」) 処理のたびにコピーをすると、コピーそのものに非常に時間がかかり、パフォ ーマンスが出ません。理想的には処理の際には「ゼロ・コピー」を目指します。 [コピーの典型例] ・DBからプログラム側にデータを持ってくる際に発生するコピー ・DAO層とロジック層間など、層をまたぐ際に行うBeanのコピー  [原則3]データはメモリー上に置く Oracleのキャッシュヒット率は90%以上を保つことが目安であることからも分 かるとおり、十分なパフォーマンスを得るためにはデータがメモリーに乗ってい る事が必要です。  [番外]適切なデータ構造とアルゴリズムを使用する アーキテクチャの話からそれますが、やはりデータ構造とアルゴリズムの選択 がパフォーマンスを大きく左右します。
  10. 10. ULS Copyright © 2010 UL Systems, Inc. 9 Googleのアーキテクチャ
  11. 11. ULS Copyright © 2010 UL Systems, Inc. 10 取り上げる技術  この勉強会では書籍で紹介のあった以下の技術を取り上げます。  上記のすべての仕組みはC10K問題の範囲内での動作が前提です。  すべてのアーキテクチャは多重化されています。 名前 分類 内容 規模 Chubby LOCK EVENT DISK 分散ロックサービス 5台構成のサーバーで1 万台のクライアントを扱え る GFS (Google File System) DISK 分散ファイルシステム 数百台のクライアント 数千台のサーバー ペタバイト規模 MapReduce CPU 分散処理のための基盤技術 数千台のサーバー Bigtable DB 構造データのための分散スト レージ 数百台のクライアント 数千台のサーバー ペタバイト規模
  12. 12. ULS Copyright © 2010 UL Systems, Inc. 11 全体アーキテクチャ  アーキテクチャの全体構成を以下に示します。 Chubby Bigtable+MapReduce GFS+MapReduce 利用 各種ロック, 同期とり DNS代わり 各マシンの生死確認 巨大な分散DB+ 分散バッチ処理 巨大なディスクスペース+ ファイル操作型の分散バッチ処理 DB Disk Lock
  13. 13. ULS Copyright © 2010 UL Systems, Inc. 12 Chubby  分散ロックサービス  イベント通知  (Hadoopには該当サービスは無い) Chubby: 「まるぽちゃの」の意味
  14. 14. ULS Copyright © 2010 UL Systems, Inc. 13 Chubbyとは  Chubbyは本質的には1台のサーバーによって提供されるリモートディスクです。 リモートディスク上にファイルを作ることでロックを実現します。  ロック対象を監視しているマシンたちは、ロック対象の状態が変化したといった イベント通知を受け取ることも可能です。  Chubbyは、冗長性を考慮しなければ、かなり単純な機構で実現可能です。仕 組み上はTCP/IPを用いたチャットシステムなんかに似た機構で実現可能です。 たとえば、TCP/IP接続を1万台まで受け付けるようにサーバーを構築し、クライ アントはサーバーに接続しっぱなしの状態を作ります。あとはロック対象の資源 をクライアント側で操作可能し、状態の変更通知をクライアント側に戻せるように 作れば良さそうです。 C10Kの1万台までChubby ロック対象 ロックを取得したいマシンたち
  15. 15. ULS Copyright © 2010 UL Systems, Inc. 14 Chubbyの使われ方  BigtableやGFSはファイルのロックやレコードロックの仕組みを持っていない ため、これを補完する目的で用いられます。ファイルのロックやレコードロック の代わりに、Chubbyの資源をロックする事で代替とします。 (ただしパフォーマンスが出なくなるため、このようなロックは避けます)  Chubby上のロックを取り合うことで、冗長化されたマシンのどれが動くかを決 めることができます。現在動作中のマシンが止まるとロックが解除され、待機 していたマシン達がロックを取り合います。最初にロックを取ったマシンが成り 代わります。  Chubbyの一時ファイル機能を用いると、マシンの生死確認が可能です。各 マシンはChubby上に自分が生きている事を示す一時ファイルを作成し、自 分のIPアドレスを記入しておきます。もしも一時ファイルを作成したマシンが停 止した場合、一時ファイルはChubby上から自動的に削除されるため、この変 更通知がフォルダーを監視しているマシンに即座に通知されます。  高速にIPアドレス変更が可能なDNSとして動作可能です。たとえばマシン名 をChubby上のロックオブジェクト名とし、これにIPアドレスを記入しておきま す。もしも障害復帰等の目的でIPアドレス変更をする場合は、このロックオブ ジェクトの内容を変更します。そうすると、この変更はイベントとして伝播し、素 早くIPアドレス変更が通知されます。
  16. 16. ULS Copyright © 2010 UL Systems, Inc. 15 Chubbyが耐障害性のためにやっていること  Chubbyは実際には5台のマシンから構成されます。この5台のマシンを 「Chubbyセル」と呼びます。この中の1台がマスターで、このマシンが健在の 間はすべてのリクエストをこのマスター1台で処理します。他の4台は、いつで もマスターに成り代わることのできるバックアップマシンです。更に、Chubby セルの5台のうち1台は、必ず別のデータセンターのマシンが選ばれます。  マスターを選ぶ際には、Paxosというコンセンサスアルゴリズムを用います。 初回起動時や障害発生時は、生きているマシン達は投票によって誰が次のマ スターになるかを決めます。 マスターがすべて対処 どれか1台は別のデー タセンターに配置
  17. 17. ULS Copyright © 2010 UL Systems, Inc. 16 GFS (Google File System)  ペタバイト規模の分散ファイルシステム  HadoopではHDFSが該当
  18. 18. ULS Copyright © 2010 UL Systems, Inc. 17 GFSとは  GFSはログのような末尾追記型の書き込みと、大量の読み出し要求に応えることに特 化した分散ファイルシステムです。 GFSが得意なこと 大量の読み出し要求に応えられる。マシンの台数によってスケールする。 設定によって1つのデータのコピーを多く作ることによって、更に性能を上げられる。 大量の書き込み要求に対しても、書き込みファイルが別々ならスケールする。 サイズの大きなファイル(最低でも数百MB)を扱うことが得意。 「追記」なら複数同時書き込みが可能。 「スナップショット」というコピー機能で、ファイルの大きさによらず一瞬でコピー可能。(SVNのコピーと同じ) GFSが苦手なこと 小さなファイルは苦手。おそらくオーバーヘッドが非常に大きくなる。 ランダムな場所への書き込み。複数クライアントから単一ファイルにこれをやるとファイルが壊れる。 ファイルをロックする機能が無い(やりたければChubbyを使う) 追記データが重複する場合があり、利用者側が重複を除去する必要がある。 GFS クライアント クライアント
  19. 19. ULS Copyright © 2010 UL Systems, Inc. 18 GFSのアーキテクチャ  以下にGFSのアーキテクチャを示します。 Chubbyのロックの取り合い によって複数台のマスタ候補 からマスタは選択される。 1つのファイルは64MBずつの「チャンク」に分けられて保存されます。これはTCPの「パ ケット分割」に似ています。少し違うのは、1対1通信のTCPとは違い、GFSの場合は1つ のファイルに対して複数クライアントからの読み書きがあることです。 マスタはどのデータがどの チャンクサーバで管理されて いるかを知っている。クライア ントからの問い合わせには、 チャンクの場所を教えるのみ。 クライアントは読みたいデータの場所をマ スタに問い合わせ、その後、それぞれの チャンクサーバにデータを取りに行く。 実データはチャンクサーバ と直接やりとりするため、 帯域幅を有効に生かせる。 マスタはメモリー中にディレクトリ階層をす べて持つ。また、ファイルの中身がどの チャンク達に書かれているかを知っている。
  20. 20. ULS Copyright © 2010 UL Systems, Inc. 19 追記処理の挙動  GFSでは追記の一塊のデータを「レコード」と呼びます。1レコードは16MB以下である 必要があります。書き込まれるレコードは一旦メモリーに貯められ、順次チャンクに追 記されます。  どこかでエラーが発生すると、一部のディスク書き込み(チャンク追記)に成功している 場合であっても全体としてはエラーとし、書き込み処理をリトライします。チャンクにゴミ が残りますが、データ書き込みの際に付加するチェックサムやシリアル番号を読み取 り時に確認し、壊れたデータや重複データをより分けます。 1. クライアントはマスターにどのチャンクサーバーに書き込 めばいいのか問い合わせる。 2. マスターは少なくとも3台のマシンを書き込み先と決め、 その一台をプライマリ、それ以外をセカンダリのチャンク サーバと決める。 3. クライアントは最寄りのチャンクサーバにデータを渡す。 データはチャンクサーバから別のチャンクサーバへチェ ーンされ、データが渡る。データはまだ各チャンクサーバ のメモリー内にある。 4. クライアントからプライマリに書き込み要求をする。プライ マリはチャンクにデータを追記する。ディスク書き込み。 5. セカンダリにも書き込み要求をチェーン。 6. 書き込み成功をプライマリに通知。 7. 書き込み成功をクライアントに通知。
  21. 21. ULS Copyright © 2010 UL Systems, Inc. 20 読み取り処理の挙動  GFS上の1つのファイルは64MBずつのチャンク(パケット)に分割され、保存されていま す。また、1つ1つのチャンクは最低3つの別のチャンクサーバーにコピーされています。 よって、読み取り操作は、この3つ以上あるコピーのうち、自分に近いサーバーからデー タを持ってくるだけです。ただし、書き込み時に生じている可能性のあるゴミデータはより 分ける必要があります。データの複製の数をデフォルトの3以上に増やすと、書き込み性 能は犠牲になりますが、読み取り性能は高めることが出来ます。
  22. 22. ULS Copyright © 2010 UL Systems, Inc. 21 Bigtable  構造データのための分散ストレージ  HadoopではHBaseという名前で提供
  23. 23. ULS Copyright © 2010 UL Systems, Inc. 22 前提知識:分散KVSについて  スケールアウトが容易にできる「分散KVS(NoSQL)」が、クラウドの世界では必須の ものとなりつつあります。分散KVSは数千台のマシンを束ねて1つの巨大なハッシュマ ップのような物として利用可能にするものです。 KVSというと、memcachedのような簡単なキャッシュ用途のものが思い浮かぶかも しれませんが、クラウドでの分散KVSはメインのDBです。 なお、KVSのKeyの扱いに関しては、ハッシュ値を使った方式を使うか、Keyでソート して探索するsorted mapにするなどの選択肢があります。sorted mapの場合は範 囲検索が可能だという利点があります。 通常、アトミックな操作は1度のKey,Value操作のみです。  分散KVSの典型的なアーキテクチャ マスター 実際のデータを保管するサーバー。 データは基本的にはディスク上に保管される。 キャッシュに乗せる量がマシン台数次第でとても 大きくできるため、高性能化しやすい。 クライアント Key, Value → Key値によって適切な保管サーバーを決定。 この決定アルゴリズムとして有名なのは Consistent Hashingです。このような特殊なア ルゴリズムを使うと、サーバーを追加したり削除 したりする事が容易に行えます。
  24. 24. ULS Copyright © 2010 UL Systems, Inc. 23 GFSは分散KVSの一種  GFSはKVSの一種です。Keyの構造が特殊で、テーブルのような論理データ構造を扱 えるようになっています。  通常のKVSではKey,Valueのペアをバラバラのサーバー群に保存しようとしますが、 それだと1レコードを取り出す操作が遅い です。Bigtableの場合は行キーでまとめた レコードを1つのまとまりとします。アト ミック操作も1レコード操作内になります。  複数レコードをまとめた物を「タブレット」と 呼び、このタブレットをタブレットサーバーで 管理します。よって、1つのテーブルは 複数のタブレットサーバーによって 管理されます。データはGFSに置かれます。 Key (3つの複 合キー) ・行キー(PK) ・コラムキー ・タイムスタンプ Value ・BLOB 1タブレット:100~200MB程度
  25. 25. ULS Copyright © 2010 UL Systems, Inc. 24 タブレットの読み書き方法  Bigtableの読み書きの基本はタブレット操作です。以下に処理内容を説明し ます。  書き込み方法 書き込みはコミットログに内容を書き、memtable上に値を 保持して完了。memtableが溢れた場合、データをまとめて SSTableに書き出し、コミットログをクリアする。  読み込み方法 直近の書き込みデータはオンメモリにあるため、それを 返して終わり。値がGFSのファイル中のデータを指して いる場合は、そのデータをGFSから取得して返す。もちろんタブレットサーバにキャッシ ュがあればそれを使う。 value1 value2 ・・・・・・ ・・・・・・ ・・・・・・ インデックス SSTable key1 value1へのポインタ key2 value2へのポインタ key3 value3そのもの ・・・ ・・・ memtable(オンメモリインデックス) memtableへの操作 ログ(追記) SSTableには未反映 コミットログ GFS value1 value2 ・・・・・・ ・・・・・・ ・・・・・・ インデックス value1 value2 ・・・・・・ ・・・・・・ ・・・・・・ インデックス value1 value2 ・・・・・・ ・・・・・・ ・・・・・・ インデックス クライアント タブレットサーバ(オンメモリ処理) GFSの得意な追記と、 複数ファイル並行読取 をうまく使っている。 読み書き オンメモリに直近の(まだSSTableに保 存していない)情報と、全体のインデック ス情報の2つのデータを保持。 タブレットサーバーはローカルディスクを使いません。 おそらくGFSとの同居も可能です。 2重化しない
  26. 26. ULS Copyright © 2010 UL Systems, Inc. 25 Bigtableを利用しているシステム  Googleのクローラ – クロールしたhtmlデータを保存するために使っているそうです。  Google Maps, Earth (maps.google.com, earth.google.com) – 地図情報の置き場などに利用  Orkut (www.orkut.com)  Personalized Search (www.google.com/psearch)  Google Finance (www.google.com/finance)  Google Analytics (analytics.google.com) – トラフィック解析ツール バックエンド向けからエンドユーザー向けまで幅 広く利用可能
  27. 27. ULS Copyright © 2010 UL Systems, Inc. 26 MapReduce  分散処理のための基盤技術  HadoopでもMapReduceという名前で提供
  28. 28. ULS Copyright © 2010 UL Systems, Inc. 27 MapReduceとは  大量のCPUがある環境で簡単に分散処理を動かす時の考え方として、計算ノードに IDを付け、その計算ノードにプログラムとデータを送りつけるというものがあります。  MapReduceでは、計算ノードのIDをKey、データをValueと位置づけます。  それに加えて、MapReduceは計算の流れを「Map」処理と「Reduce」処理に緩く定義 しました。  このMapReduceは、完全にバッチ処理向けの仕組みになります。
  29. 29. ULS Copyright © 2010 UL Systems, Inc. 28 コピー処理が無い方がパフォーマンスが出る  MapReduceはGFSのデータでもBigtableのデータでも動作します。GFSもBigtable も、元々データを分散保持しているため、MapReduceのKey値をうまくデータを保持 しているサーバーに結び付けられれば処理はローカル処理に出来ます。なお、 Bigtableが対象データの場合、GFS上のSSTableを直接読み込む事もしているよう です。 GFS Bigtable GFS Bigtable
  30. 30. ULS Copyright © 2010 UL Systems, Inc. 29 おしまい

×