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

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日
講師役：近棟稔

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で
配布されています。

相手にするマシン数を考えてみる
 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。

日本の大規模データセンターの例
 さくらインターネットの大規模データセンター：60万台規模

単純計算でのメモリー、HDD容量の皮算用
 Googleが2003年頃に用いていた1ノードあたりの能力はそれほど高くなく、以下のよ
うなものだったようです。当時の高性能サーバーはメモリ64GB程を載せていたようで
すので、かなり安めのサーバーを使っていたようです。
– CPU Xeon 2GHz x 2個 ← Xeonはスパコンでもよく用いられるCPU
– メモリー 2GB
– HDD 80GB
 Googleの「小規模データセンター」:数千台
– メモリー数TB
– HDD 数百TB
 Googleの「大規模データセンター」:数十万台
– メモリー数百TB
– HDD 数十PB
たとえば、この広大なメモリー空間を使って何が出来るかを考えてみてください。
普通のデータ規模なら、すべてのデータをメモリーに乗せてしまうことも可能で
す！

アーキテクチャを考える上での前提知識

C10K問題 (クライアント1万台問題)がクラスタの上限を決める
 C10K問題というのは、1台のサーバーマシンは、ソフトウエア側の制限によっ
て、おおよそ1万台程度のクライアントまでしか捌けないという問題です。
なお、大抵のハードウエアは1万台以上の接続に耐えられるようです。
 C10K問題とデータセンターとの関係
– 小規模データセンターで数千台、大規模データセンターで数十万台のマシンがある
として、それらをうまく協調させるための中心となるサーバーマシンを置くとすると、
このC10K問題が関係してきます。
中心となるサーバーと接続を持つマシン達の上限が1万台という制約を持つと、小
規模データセンターでは大丈夫ですが、大規模データセンターではうまくハンドリン
グできなくなって来ます。
１つのクラスタは、おおよそ1万台まで
ただし、上記のように中心となるマシンが居ない構成も考えられ、その場合はこの制約を超えられます。
たとえばCassandraはこのような構成になっています。Googleの場合、このような構成は取っていません。
マスター
クラスタ

マシンが大量にあると、どれか壊れる
 １台あたりの稼働率が99%のマシンを大量に使った想定で、全部が問題なく
動作する稼働率をグラフにすると・・・。数十万台なら？
全
体
の
稼
働
率
（％
）
マシン台数
つまり、どれかのマシンは
大抵壊れている。

パオーマンスを引き出す原則
 [原則１]読み取りスピードを上げるには複製を作る
マスター系データのようにデータが変化しにくいものに関しては、複数台マシ
ンにデータのコピーを作ると、読み取りパフォーマンスが向上します。
 [原則２]一過性のコピーを可能な限り排除(目指せ「ゼロ・コピー」)
処理のたびにコピーをすると、コピーそのものに非常に時間がかかり、パフォ
ーマンスが出ません。理想的には処理の際には「ゼロ・コピー」を目指します。
[コピーの典型例]
・DBからプログラム側にデータを持ってくる際に発生するコピー
・DAO層とロジック層間など、層をまたぐ際に行うBeanのコピー
 [原則３]データはメモリー上に置く
Oracleのキャッシュヒット率は90％以上を保つことが目安であることからも分
かるとおり、十分なパフォーマンスを得るためにはデータがメモリーに乗ってい
る事が必要です。
 [番外]適切なデータ構造とアルゴリズムを使用する
アーキテクチャの話からそれますが、やはりデータ構造とアルゴリズムの選択
がパフォーマンスを大きく左右します。

Googleのアーキテクチャ

取り上げる技術
 この勉強会では書籍で紹介のあった以下の技術を取り上げます。
 上記のすべての仕組みはC10K問題の範囲内での動作が前提です。
 すべてのアーキテクチャは多重化されています。
名前分類内容規模
Chubby
LOCK
EVENT
DISK
分散ロックサービス
5台構成のサーバーで1
万台のクライアントを扱え
る
GFS (Google File
System)
DISK 分散ファイルシステム
数百台のクライアント
数千台のサーバー
ペタバイト規模
MapReduce CPU 分散処理のための基盤技術数千台のサーバー
Bigtable DB
構造データのための分散スト
レージ
数百台のクライアント
数千台のサーバー
ペタバイト規模

全体アーキテクチャ
 アーキテクチャの全体構成を以下に示します。
Chubby
Bigtable+MapReduce GFS+MapReduce
利用
各種ロック, 同期とり
DNS代わり
各マシンの生死確認
巨大な分散DB＋
分散バッチ処理
巨大なディスクスペース＋
ファイル操作型の分散バッチ処理
DB Disk
Lock

Chubby
 分散ロックサービス
 イベント通知
 (Hadoopには該当サービスは無い)
Chubby: 「まるぽちゃの」の意味

Chubbyとは
 Chubbyは本質的には1台のサーバーによって提供されるリモートディスクです。
リモートディスク上にファイルを作ることでロックを実現します。
 ロック対象を監視しているマシンたちは、ロック対象の状態が変化したといった
イベント通知を受け取ることも可能です。
 Chubbyは、冗長性を考慮しなければ、かなり単純な機構で実現可能です。仕
組み上はTCP/IPを用いたチャットシステムなんかに似た機構で実現可能です。
たとえば、TCP/IP接続を1万台まで受け付けるようにサーバーを構築し、クライ
アントはサーバーに接続しっぱなしの状態を作ります。あとはロック対象の資源
をクライアント側で操作可能し、状態の変更通知をクライアント側に戻せるように
作れば良さそうです。
C10Kの1万台までChubby
ロック対象
ロックを取得したいマシンたち

Chubbyの使われ方
 BigtableやGFSはファイルのロックやレコードロックの仕組みを持っていない
ため、これを補完する目的で用いられます。ファイルのロックやレコードロック
の代わりに、Chubbyの資源をロックする事で代替とします。
(ただしパフォーマンスが出なくなるため、このようなロックは避けます)
 Chubby上のロックを取り合うことで、冗長化されたマシンのどれが動くかを決
めることができます。現在動作中のマシンが止まるとロックが解除され、待機
していたマシン達がロックを取り合います。最初にロックを取ったマシンが成り
代わります。
 Chubbyの一時ファイル機能を用いると、マシンの生死確認が可能です。各
マシンはChubby上に自分が生きている事を示す一時ファイルを作成し、自
分のIPアドレスを記入しておきます。もしも一時ファイルを作成したマシンが停
止した場合、一時ファイルはChubby上から自動的に削除されるため、この変
更通知がフォルダーを監視しているマシンに即座に通知されます。
 高速にIPアドレス変更が可能なDNSとして動作可能です。たとえばマシン名
をChubby上のロックオブジェクト名とし、これにIPアドレスを記入しておきま
す。もしも障害復帰等の目的でIPアドレス変更をする場合は、このロックオブ
ジェクトの内容を変更します。そうすると、この変更はイベントとして伝播し、素
早くIPアドレス変更が通知されます。

Chubbyが耐障害性のためにやっていること
 Chubbyは実際には5台のマシンから構成されます。この5台のマシンを
「Chubbyセル」と呼びます。この中の1台がマスターで、このマシンが健在の
間はすべてのリクエストをこのマスター1台で処理します。他の4台は、いつで
もマスターに成り代わることのできるバックアップマシンです。更に、Chubby
セルの5台のうち1台は、必ず別のデータセンターのマシンが選ばれます。
 マスターを選ぶ際には、Paxosというコンセンサスアルゴリズムを用います。
初回起動時や障害発生時は、生きているマシン達は投票によって誰が次のマ
スターになるかを決めます。
マスターがすべて対処
どれか1台は別のデー
タセンターに配置

GFS (Google File System)
 ペタバイト規模の分散ファイルシステム
 HadoopではHDFSが該当

GFSとは
 GFSはログのような末尾追記型の書き込みと、大量の読み出し要求に応えることに特
化した分散ファイルシステムです。
GFSが得意なこと
大量の読み出し要求に応えられる。マシンの台数によってスケールする。
設定によって1つのデータのコピーを多く作ることによって、更に性能を上げられる。
大量の書き込み要求に対しても、書き込みファイルが別々ならスケールする。
サイズの大きなファイル(最低でも数百MB)を扱うことが得意。
「追記」なら複数同時書き込みが可能。
「スナップショット」というコピー機能で、ファイルの大きさによらず一瞬でコピー可能。(SVNのコピーと同じ)
GFSが苦手なこと
小さなファイルは苦手。おそらくオーバーヘッドが非常に大きくなる。
ランダムな場所への書き込み。複数クライアントから単一ファイルにこれをやるとファイルが壊れる。
ファイルをロックする機能が無い(やりたければChubbyを使う)
追記データが重複する場合があり、利用者側が重複を除去する必要がある。
GFS
クライアントクライアント

GFSのアーキテクチャ
 以下にGFSのアーキテクチャを示します。
Chubbyのロックの取り合い
によって複数台のマスタ候補
からマスタは選択される。
1つのファイルは64MBずつの「チャンク」に分けられて保存されます。これはTCPの「パ
ケット分割」に似ています。少し違うのは、1対1通信のTCPとは違い、GFSの場合は1つ
のファイルに対して複数クライアントからの読み書きがあることです。
マスタはどのデータがどの
チャンクサーバで管理されて
いるかを知っている。クライア
ントからの問い合わせには、
チャンクの場所を教えるのみ。
クライアントは読みたいデータの場所をマ
スタに問い合わせ、その後、それぞれの
チャンクサーバにデータを取りに行く。
実データはチャンクサーバ
と直接やりとりするため、
帯域幅を有効に生かせる。
マスタはメモリー中にディレクトリ階層をす
べて持つ。また、ファイルの中身がどの
チャンク達に書かれているかを知っている。

追記処理の挙動
 GFSでは追記の一塊のデータを「レコード」と呼びます。1レコードは16MB以下である
必要があります。書き込まれるレコードは一旦メモリーに貯められ、順次チャンクに追
記されます。
 どこかでエラーが発生すると、一部のディスク書き込み(チャンク追記)に成功している
場合であっても全体としてはエラーとし、書き込み処理をリトライします。チャンクにゴミ
が残りますが、データ書き込みの際に付加するチェックサムやシリアル番号を読み取
り時に確認し、壊れたデータや重複データをより分けます。
1. クライアントはマスターにどのチャンクサーバーに書き込
めばいいのか問い合わせる。
2. マスターは少なくとも3台のマシンを書き込み先と決め、
その一台をプライマリ、それ以外をセカンダリのチャンク
サーバと決める。
3. クライアントは最寄りのチャンクサーバにデータを渡す。
データはチャンクサーバから別のチャンクサーバへチェ
ーンされ、データが渡る。データはまだ各チャンクサーバ
のメモリー内にある。
4. クライアントからプライマリに書き込み要求をする。プライ
マリはチャンクにデータを追記する。ディスク書き込み。
5. セカンダリにも書き込み要求をチェーン。
6. 書き込み成功をプライマリに通知。
7. 書き込み成功をクライアントに通知。

読み取り処理の挙動
 GFS上の１つのファイルは64MBずつのチャンク(パケット)に分割され、保存されていま
す。また、１つ１つのチャンクは最低３つの別のチャンクサーバーにコピーされています。
よって、読み取り操作は、この3つ以上あるコピーのうち、自分に近いサーバーからデー
タを持ってくるだけです。ただし、書き込み時に生じている可能性のあるゴミデータはより
分ける必要があります。データの複製の数をデフォルトの3以上に増やすと、書き込み性
能は犠牲になりますが、読み取り性能は高めることが出来ます。

Bigtable
 構造データのための分散ストレージ
 HadoopではHBaseという名前で提供

前提知識：分散KVSについて
 スケールアウトが容易にできる「分散KVS(NoSQL)」が、クラウドの世界では必須の
ものとなりつつあります。分散KVSは数千台のマシンを束ねて1つの巨大なハッシュマ
ップのような物として利用可能にするものです。
KVSというと、memcachedのような簡単なキャッシュ用途のものが思い浮かぶかも
しれませんが、クラウドでの分散KVSはメインのDBです。
なお、KVSのKeyの扱いに関しては、ハッシュ値を使った方式を使うか、Keyでソート
して探索するsorted mapにするなどの選択肢があります。sorted mapの場合は範
囲検索が可能だという利点があります。
通常、アトミックな操作は１度のKey,Value操作のみです。
 分散KVSの典型的なアーキテクチャ
マスター
実際のデータを保管するサーバー。
データは基本的にはディスク上に保管される。
キャッシュに乗せる量がマシン台数次第でとても
大きくできるため、高性能化しやすい。
クライアント
Key, Value →
Key値によって適切な保管サーバーを決定。
この決定アルゴリズムとして有名なのは
Consistent Hashingです。このような特殊なア
ルゴリズムを使うと、サーバーを追加したり削除
したりする事が容易に行えます。

GFSは分散KVSの一種
 GFSはKVSの一種です。Keyの構造が特殊で、テーブルのような論理データ構造を扱
えるようになっています。
 通常のKVSではKey,Valueのペアをバラバラのサーバー群に保存しようとしますが、
それだと1レコードを取り出す操作が遅い
です。Bigtableの場合は行キーでまとめた
レコードを1つのまとまりとします。アト
ミック操作も1レコード操作内になります。
 複数レコードをまとめた物を「タブレット」と
呼び、このタブレットをタブレットサーバーで
管理します。よって、１つのテーブルは
複数のタブレットサーバーによって
管理されます。データはGFSに置かれます。
Key
(3つの複
合キー)
・行キー(PK)
・コラムキー
・タイムスタンプ
Value ・BLOB
1タブレット：100～200MB程度

タブレットの読み書き方法
 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に保
存していない)情報と、全体のインデック
ス情報の２つのデータを保持。
タブレットサーバーはローカルディスクを使いません。
おそらくGFSとの同居も可能です。
2重化しない

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)
– トラフィック解析ツール
バックエンド向けからエンドユーザー向けまで幅
広く利用可能

MapReduce
 分散処理のための基盤技術
 HadoopでもMapReduceという名前で提供

MapReduceとは
 大量のCPUがある環境で簡単に分散処理を動かす時の考え方として、計算ノードに
IDを付け、その計算ノードにプログラムとデータを送りつけるというものがあります。
 MapReduceでは、計算ノードのIDをKey、データをValueと位置づけます。
 それに加えて、MapReduceは計算の流れを「Map」処理と「Reduce」処理に緩く定義
しました。
 このMapReduceは、完全にバッチ処理向けの仕組みになります。

コピー処理が無い方がパフォーマンスが出る
 MapReduceはGFSのデータでもBigtableのデータでも動作します。GFSもBigtable
も、元々データを分散保持しているため、MapReduceのKey値をうまくデータを保持
しているサーバーに結び付けられれば処理はローカル処理に出来ます。なお、
Bigtableが対象データの場合、GFS上のSSTableを直接読み込む事もしているよう
です。
GFS
Bigtable
GFS
Bigtable

おしまい

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

Similaire à 「Googleを支える技術」の解説 2010.08.23 (10)

Plus de Minoru Chikamune

Plus de Minoru Chikamune (8)

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