データベースと応用システム：Google

Slide 1

Slide 1 text

(c)長岡技術科学大学電気系 1 データベースと応用システム Google 山本和英長岡技術科学大学電気系 Google、Google ロゴ、Google 検索ロゴ、Google 音声検索™、Google 音声検索ロゴは、Google Inc.の商標または登録商標です。

Slide 2

Slide 2 text

(c)長岡技術科学大学電気系 2 Googleの歴史 ● 1998年9月7日 – 創業。検索件数１万件／日 – ８台のパソコンと４０個以上のHDD ● 1999年9月 – 検索件数３００万件／日 ● 2000年 – 検索件数１８００万件／日 ● 2004年 – NASDAQに株式公開

Slide 3

Slide 3 text

(c)長岡技術科学大学電気系 3 Googleの基本的な考え方 ● ソフトウェアで信頼性を高める – UPSやハードウェアRAIDは使わない ● 機器の高性能化よりも負荷分散 – コストパフォーマンス ● 基本部分は独自技術で – GFS (Google File System) – Work Queue

Slide 4

Slide 4 text

(c)長岡技術科学大学電気系 4 検索エンジン

Slide 5

Slide 5 text

(c)長岡技術科学大学電気系 5 検索エンジンの仕組み ● 検索バックエンド – クローリング（Webデータ収集） – インデックスの作成 – 時間をかけて処理して構わない ● 検索サーバー – インデックスを参照して検索結果を返す – 可能な限り高速に処理する必要がある – 処理の分散化 – 検索キーはすべて数値化してインデックスを作成

Slide 6

Slide 6 text

(c)長岡技術科学大学電気系 6 クローリング：注意点 ● 特定サイトにアクセスが集中しすぎてはいけない – アクセスの分散 ● アクセスできないこともある – アクセスの再試行 ● １ページ１秒でも１日86,400ページしかアクセスできない – 並列処理、URLサーバーによる制御 ● ページを自動生成するサイトがある – ページ収集がいつまでも終わらない

Slide 7

Slide 7 text

(c)長岡技術科学大学電気系 7 インデックスの作成 ● Webページの構造解析 – 検索に必要なタイトル、テキスト、URL等を抽出 ● 単語情報の抽出 – ページID, 単語ID, 位置, サイズ, スタイル, … ● 転置インデックスの作成 – 単語IDからページIDへ ● リンク情報のインデックス作成 – ページAからページBへ ● ランキング情報のインデックス – PageRankの計算

Slide 8

Slide 8 text

(c)長岡技術科学大学電気系 8 実際の検索処理の流れ ● まとめ役(Google Web Server, GWS)が各インデックスサーバーに検索依頼 – インデックスサーバーは別個のページ集合を担当している。 ● 各インデックスサーバーが検索上位を返す – 検索要求があった時に全インデックスサーバーにランキング上位ページIDを提出する。 ● GWSが結果をまとめて上位ページを決定 ● GWSが関係するドキュメントサーバーに要約作成を依頼 ● ドキュメントサーバーは要約作成してGWSに返す

Slide 9

Slide 9 text

(c)長岡技術科学大学電気系 9 検索サーバー　その他の処理 ● 「もしかして」検索 ● 広告の選別、作成 ● キャッシングによる処理の高速化

Slide 10

Slide 10 text

(c)長岡技術科学大学電気系 10 ＧｏｏｇｌｅＦｉｌｅＳｙｓｔｅｍ（ＧＦＳ）

Slide 11

Slide 11 text

(c)長岡技術科学大学電気系 11 ＧＦＳの概要と特徴 ● 巨大なストレージを作り上げる技術 ● 全ファイルは常に３ヶ所に保存されている ● 大きなファイル(数百MB)の書き込みに適している ● 何度も書き込むことに向いていない ● ファイルをロックする機能がない

Slide 12

Slide 12 text

(c)長岡技術科学大学電気系 12 ＧＦＳの役割分担 ● マスタ – ＧＦＳ全体を管理。どのチャンクサーバーに何が保存されているかをすべて管理・制御する ● チャンクサーバー – ファイル置き場。ファイルの断片(64MB)が大量に保存されている。 – １ファイルは３チャンクサーバーに保存される。 ● クライアント – ファイルの読み書きをマスタに依頼する。

Slide 13

Slide 13 text

(c)長岡技術科学大学電気系 13 ＧＦＳの障害対策 ● チャンクの障害 – チェックサムの照合によって同一性を判断する – 「暇」な時にチェックサムを再確認する ● チャンクサーバの障害 – マスタとの交信によって障害や新規設置が分かる ● マスタの障害 – ＧＦＳ外部で常に監視し、異常の時は即時交代 – 更新ログを常に別の計算機にコピー – チャンクの情報はチャンクサーバが教えてくれる

Slide 14

Slide 14 text

(c)長岡技術科学大学電気系 14 ＧＦＳの復旧時間：実験結果 ● チャンクサーバ数：２００、各チャンクサーバーは 15,000程度のチャンク（=600GB） ● チャンクサーバ１台が故障 – 新しいコピーが作られるまで２３分 ● チャンクサーバ２台が故障 – ２６６チャンクがコピーなし状態になる – このようなチャンクは優先的にコピーされる – ２コピー以上の状態に復旧するまでの時間：２分 ● 結論：データの損失可能性は限りなく低い

Slide 15

Slide 15 text

(c)長岡技術科学大学電気系 15 Ｂｉｇｔａｂｌｅ

Slide 16

Slide 16 text

(c)長岡技術科学大学電気系 16 Ｂｉｇｔａｂｌｅ ● ＲＤＢでは扱えないほどの大量のデータにアクセスするための分散システム ● 列は行キーとコラムキーの２種類ある。コラムキーの数は行によって違っていても構わない。 ● 時間概念（タイムスタンプ）があり、行キーとコラムキーが同じでも時刻が異なる複数バージョンのデータがある。 ● 例：検索エンジンインデックス – 行キー：ページURL – コラムキー：リンク元ページ情報 – タイムスタンプ：ページ収集時間

Slide 17

Slide 17 text

(c)長岡技術科学大学電気系 17 Ｂｉｇｔａｂｌｅ：続き ● トランザクション処理がある。 ● テーブルはタブレット(tablet)という単位に分割され、複数のサーバで分散管理される。 ● 行キーはソートされ、タブレットには連続する行キーが含まれる。 ● タブレットはメタデータという形で管理される。メタデータはルートタブレットが管理し、ルートタブレットの場所はChubbyが保存する。 – 以上はB+木形式で管理されている。

Slide 18

Slide 18 text

(c)長岡技術科学大学電気系 18 高速アクセスの工夫 ● ファイルの圧縮 ● メタデータなどのオンメモリ化 ● 読み込みキャッシュ – スキャンキャッシュ：最近アクセスされたデータ – ブロックキャッシュ：「続き」のデータ ● 書き込みの工夫 – コミットログの一括処理 – コミットログの書き込み先を２つ用意

Slide 19

Slide 19 text

(c)長岡技術科学大学電気系 19 Ｃｈｕｂｂｙ

Slide 20

Slide 20 text

(c)長岡技術科学大学電気系 20 Ｃｈｕｂｂｙ ● 小さな分散ファイルシステム ● 以下の機能を持つ： – ファイルシステム – ロックサービス（排他制御） – イベント通知 ● 実データというよりも、データ・システム管理のための設定や情報を書き込む。Windowsのレジストリのようなものに近い。 ● ＤＮＳの代替としても使われる。各マシンがChubby に自分でアドレスを書き込む。

Slide 21

Slide 21 text

(c)長岡技術科学大学電気系 21 Ｃｈｕｂｂｙ：システム構成 ● １セット（Cell）は５台の計算機(レプリカ)からなる。うち１台をマスタと呼ぶ。 ● マスタとレプリカは全く同じ情報が書かれている。マスタの情報を変更すると直ちに４台のレプリカにコピーされる。 ● クライアント（他の計算機）との情報の読み書きはすべてマスタに対して行う。マスタが故障すると直ちにレプリカの１台がマスタになる。 ● レプリカが半数以上故障すると、セルは活動を停止する。

Slide 22

Slide 22 text

(c)長岡技術科学大学電気系 22 Ｃｈｕｂｂｙ：ファイルアクセス ● １つのファイルサイズは最大256KB ● ファイルやディレクトリは（読み込み、書き込み、変更）が可能なユーザを定義する。 ● ファイルは共有ロック、排他ロックが可能。これを使って外部資源（例えばＧＦＳ）のロックに使える。 ● 障害時対応のため、クライアントと定期的(10秒～ 60秒)に通信を行っており、通信がない場合は自動的にロック解除される。

Slide 23

Slide 23 text

(c)長岡技術科学大学電気系 23 イベント通知 ● ファイルの作成や内容変更時にクライアントに通知される。 ● 利用例１：サーバ監視 – サーバが一時ファイルに自分のアドレスを書いてマスタが監視。プロセス停止すると一時ファイルが自動削除されるので、起動中のサーバリストが得られる。 ● 利用例２：マスタ決定 – 各サーバは競争してマスタになろうとする。排他ロックできたプロセスだけが自分のアドレスを書き込むことができ、書き込まれた場合は監視しているサーバに通知される。

Slide 24

Slide 24 text

(c)長岡技術科学大学電気系 24 データセンター https://www.youtube.com/watch?v=7h3LtXxR55Y

Slide 25

Slide 25 text

(c)長岡技術科学大学電気系 25 http://www.google.com/about/datacenters/inside/locations/index.html

Slide 26

Slide 26 text

(c)長岡技術科学大学電気系 26

Slide 27

Slide 27 text

(c)長岡技術科学大学電気系 27 計算機 ● Google保有の計算機は2800万台(2019年6月)？ – https://news.netcraft.com/archives/2019/06/17/june-2019-web-server-survey.html ● 10万円 x 2800万台 = 2.8兆円 ● ５年で交換したとすると、毎年5600億円 – （ネパール、パラグアイ、リビアの国家予算に匹敵） ● 必ずしも高機能、高額な製品を使うわけではない。価格性能比の最も高い製品を選ぶ。

Slide 28

Slide 28 text

(c)長岡技術科学大学電気系 28 電気代 ● １kWhで10円、１台100Wとして、2800万台を終日稼働させると、年に2500億円 – （ブルネイ、ラオス、モザンビークの国家予算に匹敵） – （長岡市の今年度予算：2,185億円） ● ＣＰＵ性能の向上に伴って使用電力も向上傾向 ● 消費電力を削減する様々な工夫 – ＣＰＵのクロック周波数を落とす – ＰＣ電源を開発して電源効率を上げる – パワーキャッピングによるデータセンター電力の平準化

Slide 29

Slide 29 text

(c)長岡技術科学大学電気系 29 ハードディスクの故障 ● Ｇｏｏｇｌｅが2007年に１０万台以上のHDDドライブの故障傾向について調査 ● 結論 – 使い始めの頃はやや壊れやすい – 長く使うと壊れやすくなるわけではない – よく使うと壊れやすくなるとも限らない – 温度が高いほど壊れやすいということもない。３０～４０度に保つと最も故障率を低下させる。 – 結局、いつどこで作られたかが一番影響している？