生物データベース論（スケーラビリティと可用性）

平成２３年度生命情報科学科

生物データベース論
スケーラビリティと可用性
(9/13)
笠原雅弘
mkasa＠cb.k.u-tokyo.ac.jp
東京大学大学院新領域創成科学研究科
情報生命科学専攻

公開版作成にあたって
• 以下の事項は仕様です。
– 音声はありません。
– 授業中に判明した typo 等は修正しました。
多少加筆しています。
– 字が細かいのは、この資料単独で自習できるように
授業中はスライドに書かず喋った部分などを追加し
ているからです。
– アニメーションを解除するために、パラパラ漫画的な
冗長なスライドが増えています。
• 間違い・提案・コメントなどがありましたらメール
やコメント欄で連絡を下さい。歓迎です。

Table of Contents
• スケールアップとスケールアウト
• スケールアウトに向けたいくつかの技術
– レプリケーション
– シャーディング
• CAP定理

スケールアップとスケールアウト
強力なサーバーに置き換えるデータベース
（スケールアップ；費用対効果イマイチ；
わりとどんな問題でも対応可）サーバー

クライアントクライアント
データベースクライアント
サーバークライアントクライアント

クライアント台数を増やして頑張る（スケールアウト；
比較的安いが対処できない問題も。）
クライアント
データベースデータベースデータベース
サーバーサーバーサーバー

クライアントクライアントクライアント
クライアント

スケールアップ個々のサーバーを
高く能力の高いものに置き
換える
スケールアウトサーバーの台数を増やして
全体として能力を高める

スケールアップとスケールアウト
強力なサーバーに置き換えるデータベース
（スケールアップ；費用対効果イマイチ；
わりとどんな問題でも対応可）サーバー

データベーススケールアップは「高いサーバー買い
クライアント
サーバーましょう」で終わってしまって３時間も
話せないのでスケールアウトの話を。

クライアント台数を増やして頑張る（スケールアウト；
比較的安いが対処できない問題も。）
クライアント
データベースデータベースデータベース
サーバーサーバーサーバー

クライアント

レプリケーション
• 同じデータを複数のサーバーにあらかじめ
複製しておき、ユーザーリクエストを捌く。
– スケールアウトの基本テクニック。
– n台のサーバーがあれば、おおむねn倍の数の
クライアントからの問い合わせに返事ができるだろう。
レプリケーション実際にはモノによる

データA データA データA



レプリケーションの例１
• アクセス数が非常に多いWebサーバー。
数日後、キャッシュサーバで
原発事故直後大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ

人人人
人人
人人人
人人人
アクセスまばら

人人人人
アクセス殺到でなかなか
繋がらない
※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化

ラウンドロビンDNSとロードバランサー
• 不特定の閲覧者を複数のWebサーバーに
割り振る仕組み。（Webでなくともよい。）
ラウンドロビンDNS ロードバランサー
www.example.com: Web Web Web
DNSサーバー
1.2.3.45 サーバサーバサーバ
1.2.3.46 １クエリ
1.2.3.47
毎に
1.2.3.48
1.2.3.49 回転
1.2.3.50
ロードバランサー
人

人人人人人人

レプリケーションで耐故障性もアップ
TEPCO TEPCO TEPCO
ホームページホームページホームページ

人人人人人人人人人
人人人人人人
人人人
人人人人人人人人人

あ、サーバー壊れた
TEPCO ハードディスク
ホームページ壊れた

人人人人人
人DNS/ロードバランサーを
人人人人操作して他のサーバー
人人
人人人人人人に行ってもらおう！

レプリケーションの例２
中身を返すだけでなくて
Google
検索
Google
検索
検索演算も行うので、
Google 単純なウェブサーバーより
検索
人人人人負荷は高い。
人人
www.google.co.jp の IP 引き結果
人人
人

アクセス元ＩＰから地域を割り出し近い地域
のサーバーのＩＰを返す。ラウンドロビンDNS
を駆使して何台ものロードバランサーに振り
分けている。多分ロードバランサーの裏側に
何百台ものウェブサーバーが居る。

Google が人によって違う答えを
「シュミレーション」で
返す理由
検索したら7,240,000 Google
件もあった！検索DB
コピーが終わったマスター

A えー、ぼくが検索する
と 6,800,000件しか無 Google
検索
いんだけど・・・。
B まだ最新データは
細かいことは人人コピー中
気にするなって！
誤差だよ誤差。シュミレーション 7,240,000
Google
A 検索
A コンピューターで
誤差ってなんだよ
誤差って！人人
B
Google 検索は、一貫性（Consistency）は保証していないので、シュミレーション 6,800,000
検索しにいったサーバーが違えば違う数字が出ることもある
B
外野

Eventual Consistency
Google
検索DB
レプリケーションしたコピーが終わったマスター

サーバー間でちょっと
ぐらいは違うデータを Google
検索
返すのは仕方ない。
どうせコピーが終わる
まだ最新データは
まで待てばいつかは人人コピー中
結果も同じになるし。
シュミレーション 7,240,000
Google
人検索
このような「待てばいつかは誰から見て
も同じデータになるよ。」というタイプの
一貫性のことを“Eventual Consistency” 人人
（結果整合性）と呼ぶ。
例には出したが Google が本当に Eventual Consistency を
満たしているかどうかは知らない。あくまで例である。人

レプリケーションの例３
• ヒトゲノムから疾患関連遺伝子を見つける。
遺伝病Xに
罹っている人 Shotgun
reads
DNAを抽出して
遺伝病Xにショットガン参照ゲノムに
罹っていない人シークエンシングアラインメント

遺伝病Xの原因
となった遺伝子
変異を見つける。

計算の一例
ヒトゲノムの resequencing 解析。Illumina GA で読んだ paired-end のデータから SNV を call。

Illumina GA Illumina GA
PE read 1 PE read 2

splitreads splitreads

rd1 1/3 rd1 2/3 rd1 3/3 rd2 1/3 rd2 2/3 rd2 3/3 Human Ref.
Genome
bwa bwa bwa bwa bwa bwa

sai1 1/3 sai1 2/3 sai1 3/3 sai2 1/3 sai2 2/3 sai2 3/3

bwa pe bwa pe bwa pe

sam 1/3 sam 2/3 sam 3/3

この先に本当はもっと長い計算パイプラインがあるが省略。

• リードをいくつかに分割してそれぞれ独立に
並列アラインメントしたい
– このような（何の工夫も要らない単純な）並列を
Embarrassingly Parallel (EP) と言う。

1G-Ethernet の速度ではヒトゲノム配列のコピーに30秒。
ファイルサーバーリードを100分割して100台のマシンでアラインメントすると
リード配列全体１時間近くがヒトゲノムのコピーに消費される。
ヒトゲノム配列
遅い遅い

計算ノード１計算ノード２計算ノード３
ヒトゲノム配列ヒトゲノム配列ヒトゲノム配列

リードの一部#1 リードの一部#2 リードの一部#3

アラインメント#1 アラインメント#2 アラインメント#3

※実際には圧縮してコピーするとか、もう少しマシな手がある。

ファイルサーバー
リード配列全体
n台で計算するとヒトゲノムのコピーがn回発生。
n が大きくネットワークが遅いときには致命的に。
ヒトゲノム配列
遅い遅い



レプリケーション無し
レプリケーション有りファイルサーバー1 ファイルサーバー2 ファイルサーバー3
リード配列全体リード配列全体リード配列全体
ヒトゲノム配列が
ショットガンリードを分割して
レプリカから読め
並列にアラインメントしたい。
るので高速に。



レプリケーションの例４
• Google File System, Gfarm, GlusterFS, Amazon S3 のような
ファイルシステムでは、ファイルをレプリケーションすること
でスループットの向上や耐故障性向上を狙っている。
レプリカは
２～４個が普通
ファイルサーバー1 ファイルサーバー2 ファイルサーバー3 ファイルサーバー4 ファイルサーバー5
ファイルA ファイルA ファイルA

ファイルB ファイルB ファイルB

ファイルC ファイルC ファイルC

ファイルD ファイルD ファイルD

故障
ファイルサーバー１計算ノード１
が壊れてるけど、使計算ノード2
わなければいいだけ。

レプリケーションの例４
• Google File System, Gfarm, GlusterFS, Amazon S3 のような
ファイルシステムでは、ファイルをレプリケーションすること
でスループットの向上や耐故障性向上を狙っている。

ファイルサーバー1 ファイルサーバー2 ファイルサーバー3 ファイルサーバー4 ファイルサーバー5
ファイルA ファイルA ファイルA ファイルA

ファイルB ファイルB ファイルB ファイルB

ファイルC ファイルC ファイルC

ファイルD ファイルD ファイルD ファイルD

故障
レプリカの数が足りなくなったら
ファイルを複製してファイルの数を
一定に保つように努力する。

シャーディング
• データを複数の範囲に分割して各々を別々の
サーバーで処理する。
– 「範囲」の決め方は様々
• ユーザーIDの範囲、日付の範囲、金額の範囲、
居住地域の範囲、組織の範囲、・・・ etc.

部門別にメールサーバーを X部門向け
メールサーバー
分割してシャーディング
メール
サーバー社員A 社員C
社員B

社員A 社員E
Y部門向け
社員B 社員D メールサーバー

社員C
社員D 社員E

シャーディングと
リレーショナルモデル
• シャーディングは水平パーティーションとも
呼ばれ、関係モデルを水平に分割する。

日付部門ID 購入ID 商品ID 数量合計価格

2007年担当 2007/1/18 181 01326141 26F-00132 2 15,800
サーバー
2007/2/28 181 01326188 27W-00101 5 8,000
2008年担当 2008/1/10 181 01341201 23C-00089 1 23,800
サーバー 2008/9/8 181 01349254 25F-00141 3 4,800
2009年担当 2009/5/4 181 01392164 23C-00089 1 20,800
サーバー 2009/11/19 181 01412004 27W-00101 3 4,800

シャーディングの例１
• DeNA社のモバゲータウン
（1日23億ページ・ビュー）

[もはや “タダ” が常識に？携帯電話ゲームに押し寄せる
無料化の波；日経 BP Net]

ユーザーIDのハッシュ値から
600台のMySQLサーバーから１台を
選んでアバター画像を問い合わせ。

ハッシュ値を使うことで600台のどの
Webサーバーからも同じMySQL
サーバーに問い合わせに行ける。
[600億PVもMySQLで！モバゲーのインフラ底力; @IT Special]

シャーディングの例２
• Gmail (Google社のe-メールサービス)
– シャーディングの単位はユーザーアカウント
• ユーザーIDが決まると使用するメールサーバー（群）が決まる
– レプリケーションと併用して耐故障性をアップ
• 図では３レプリカだが実際は４つだったかも？

メールサーバー1 メールサーバー2 メールサーバー3 メールサーバー4 メールサーバー5
ユーザーA ユーザーA ユーザーA

ユーザーB ユーザーB ユーザーB

ユーザーC ユーザーC ユーザーC

ユーザーD ユーザーD ユーザーD

※分散ファイルシステムの例と非常に似ているが、分散ファイルシステムは
ファイル単位のシャーディングとも見なせる。

こういうシステムを深く勉強したい人は [Baker et al., Megastore: Providing Scalable,
Highly Available Storage for Interactive Services, CIDR 2011] を読むべし。

CAP theorem
• 分散システムでは以下の３つを同時に満たす
ことはできないという定理（Brewerの定理）。
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように（部分的に）故障して任意の
ノード間の通信が壊れても動作が続けられること。

Consistency
全てのクライアントから同じものが見えること。

データA データA

データAをクライアントクライアント
データBに Aを貰った Aを貰った
更新 Aを貰った
Aを貰った

データB データB

Consistency クライアントクライアント
データの更新があっても全 Bを貰った
てのクライアントが同じ Bを貰った
データを見ることができる
こと。 Bを貰った
Bを貰った

Google が人によって違う答えを
返す理由
Google
「シュミレーション」で検索DB
コピーが終わったマスター
検索したら7,240,000
件もあった！
Google
Consistent 検索

でないえー、ぼくが検索するまだ最新データは
と 6,800,000件しか無人人コピー中
いんだけど・・・。
Google
細かいことは気にす人検索

るなって！誤差だよ
誤差。
人人
コンピューターで
Consistency
データの更新があっても全
誤差ってなんだよシュミレーション 6,800,000
てのクライアントが同じ誤差って！
データを見ることができる人
こと。

レプリケーションの例１（再）
原発事故直後
大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ

人人人
人人
人人人
人人人

人人人人
Availability
障害の無いノードにデータ
読出/書込要求が来たら
アクセス殺到でなかなか
有限の時間内に操作を完繋がらない
了して返事をすることがで
きること。 ※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化

レプリケーションの例１（再）
原発事故直後
大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ

人人人
人人
人人
人人人
人
故障
１台故障しても
人人人人
Availability ウェブページは
障害の無いノードにデータ
アクセス殺到でなかなか見られるので
読出/書込要求が来たら
有限の時間内に操作を完繋がらない Availabilityがある。
きること。 ※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化

シャーディングの例２（再）
• Gmail (Google社のe-メールサービス)
– シャーディングの単位はユーザーアカウント
• ユーザーIDが決まると使用するメールサーバー（群）が決まる
– レプリケーションと併用して耐故障性をアップ
• 図では３レプリケーションだが実際は確か４つ。

故障
メールサーバー1
故障
メールサーバー2 メールサーバー3 メールサーバー5
メールサーバー4




メール削除いける？
Availability
メール番号
障害の無いノードにデータレプリカが音信不通
読出/書込要求が来たら 1435132を
有限の時間内に操作を完なので今は無理です。
削除してよ！
きること。
人

CAP theorem
ことはできないという定理（Brewerの定理）
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
– Availability
ること。

Partition tolerance とは何か？
• 直感的ないくつかの説明
– システムをいくつかの部分に分割することができて、
クライアントからメッセージが届いたときに誤った返答
を返さないこと。
– Partition tolerance が無いシステムは部分的な故障
が許されていないか、または部分的な故障時に
クライアントに誤ったメッセージを返すことがある。

レプリケーションの例で
Partition Tolerance を説明
• アクセス数が非常に多いWebサーバー

故更新が無いとするとたとえば、
障レプリカ間のネットワークが
故障しても問題がない。
ノード間
ユーザーとの間のネットワーク
通信網が壊れたら問題だが、これは
どんなシステムでも明らかに
アクセス不能だし、定義中の
「任意のノード間」にユーザーと
Partition tolerance の間は含まれていない。
ネットワークがどのよう
に（部分的に）故障して
任意のノード間の通信
が壊れても動作が続
けられること。

シャーディングの例２（再）
ノード間
通信網
故障

メールサーバー1 メールサーバー2 メールサーバー3 メールサーバー4 メールサーバー5




メール削除いける？
Partition tolerance
ネットワークがどのようメール番号
に（部分的に）故障してレプリカが音信不通
1435132を
任意のノード間の通信なので今は無理です。
が壊れても動作が続
削除してよ！
けられること。
人

CAP theorem （復習）
ことはできないという定理（Brewerの定理）。
– Consistency
– Availability
ること。

CAP定理を背理法で証明
ノード間
通信網システムの通常動作は
データA データA このようになっている。
データちょうだい Aだよ Aだよデータちょうだい

ノード間
通信網 Partition tolerance &
デーA データA
Availability より返事できる
故障 Aだよデータちょうだい

ノード間
Partition tolerance & 通信網右のサーバーからは上の
Availability よりデータB データA ケースと区別が付かないが、
書き込みも可能 Consistency が壊れた■
データBを書いて B書いたよ故障 Aだよデータちょうだい

生物データベース論（スケーラビリティと可用性）

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 生物データベース論（スケーラビリティと可用性）

Similaire à 生物データベース論（スケーラビリティと可用性） (20)

Dernier

Dernier (7)

生物データベース論（スケーラビリティと可用性）