More Related Content Similar to 生物データベース論(スケーラビリティと可用性)
Similar to 生物データベース論(スケーラビリティと可用性) (20) 生物データベース論(スケーラビリティと可用性)2. 公開版作成にあたって
• 以下の事項は仕様です。
– 音声はありません。
– 授業中に判明した typo 等は修正しました。
多少加筆しています。
– 字が細かいのは、この資料単独で自習できるように
授業中はスライドに書かず喋った部分などを追加し
ているからです。
– アニメーションを解除するために、パラパラ漫画的な
冗長なスライドが増えています。
• 間違い・提案・コメントなどがありましたらメール
やコメント欄で連絡を下さい。歓迎です。
5. スケールアップとスケールアウト
強力なサーバーに置き換える データベース
(スケールアップ;費用対効果イマイチ;
わりとどんな問題でも対応可) サーバー
クライアント クライアント
データベース クライアント
サーバー クライアント クライアント
クライアント 台数を増やして頑張る(スケールアウト;
比較的安いが対処できない問題も。)
クライアント
データベース データベース データベース
サーバー サーバー サーバー
クライアント クライアント クライアント
クライアント
クライアント クライアント
7. スケールアップとスケールアウト
強力なサーバーに置き換える データベース
(スケールアップ;費用対効果イマイチ;
わりとどんな問題でも対応可) サーバー
クライアント クライアント
データベース スケールアップは「高いサーバー買い
クライアント
サーバー ましょう」で終わってしまって3時間も
クライアント クライアント
話せないのでスケールアウトの話を。
クライアント 台数を増やして頑張る(スケールアウト;
比較的安いが対処できない問題も。)
クライアント
データベース データベース データベース
サーバー サーバー サーバー
クライアント クライアント クライアント
クライアント
クライアント クライアント
9. レプリケーション
• 同じデータを複数のサーバーにあらかじめ
複製しておき、ユーザーリクエストを捌く。
– スケールアウトの基本テクニック。
– n台のサーバーがあれば、おおむねn倍の数の
クライアントからの問い合わせに返事ができるだろう。
レプリケーション 実際にはモノによる
データA データA データA
クライアント クライアント クライアント
クライアント クライアント クライアント
10. レプリケーションの例1
• アクセス数が非常に多いWebサーバー。
数日後、キャッシュサーバで
原発事故直後 大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ
人 人 人
人 人
人 人 人
人 人 人
アクセスまばら
人 人 人 人
アクセス殺到でなかなか
繋がらない
※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化
11. ラウンドロビンDNSとロードバランサー
• 不特定の閲覧者を複数のWebサーバーに
割り振る仕組み。(Webでなくともよい。)
ラウンドロビンDNS ロードバランサー
www.example.com: Web Web Web
DNSサーバー
1.2.3.45 サーバ サーバ サーバ
1.2.3.46 1クエリ
1.2.3.47
毎に
1.2.3.48
1.2.3.49 回転
1.2.3.50
ロードバランサー
人
人 人 人 人 人 人
12. レプリケーションで耐故障性もアップ
TEPCO TEPCO TEPCO
ホームページ ホームページ ホームページ
人 人 人 人 人 人 人 人 人
人 人 人 人 人 人
人 人 人
人 人 人 人 人 人 人 人 人
あ、サーバー壊れた
TEPCO ハードディスク
ホームページ 壊れた
人 人 人 人 人
人DNS/ロードバランサーを
人 人 人 人 操作して他のサーバー
人 人
人 人 人 人 人 人 に行ってもらおう!
13. レプリケーションの例2
• アクセス数が非常に多いWebサーバー。
中身を返すだけでなくて
Google
検索
Google
検索
検索演算も行うので、
Google 単純なウェブサーバーより
検索
人 人 人 人 負荷は高い。
人 人
www.google.co.jp の IP 引き結果
人 人
人
アクセス元IPから地域を割り出し近い地域
のサーバーのIPを返す。ラウンドロビンDNS
を駆使して何台ものロードバランサーに振り
分けている。多分ロードバランサーの裏側に
何百台ものウェブサーバーが居る。
14. 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
外野
15. Eventual Consistency
Google
検索DB
レプリケーションした コピーが終わった マスター
サーバー間でちょっと
ぐらいは違うデータを Google
検索
返すのは仕方ない。
どうせコピーが終わる
まだ最新データは
まで待てばいつかは 人 人 コピー中
結果も同じになるし。
シュミレーション 7,240,000
Google
人 検索
このような「待てばいつかは誰から見て
も同じデータになるよ。」というタイプの
一貫性のことを“Eventual Consistency” 人 人
(結果整合性)と呼ぶ。
シュミレーション 6,800,000
例には出したが Google が本当に Eventual Consistency を
満たしているかどうかは知らない。あくまで例である。 人
17. 計算の一例
ヒトゲノムの 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
この先に本当はもっと長い計算パイプラインがあるが省略。
18. • リードをいくつかに分割してそれぞれ独立に
並列アラインメントしたい
– このような(何の工夫も要らない単純な)並列を
Embarrassingly Parallel (EP) と言う。
1G-Ethernet の速度ではヒトゲノム配列のコピーに30秒。
ファイルサーバー リードを100分割して100台のマシンでアラインメントすると
リード配列全体 1時間近くがヒトゲノムのコピーに消費される。
ヒトゲノム配列
遅い 遅い
計算ノード1 計算ノード2 計算ノード3
ヒトゲノム配列 ヒトゲノム配列 ヒトゲノム配列
リードの一部#1 リードの一部#2 リードの一部#3
アラインメント#1 アラインメント#2 アラインメント#3
※実際には圧縮してコピーするとか、もう少しマシな手がある。
19. ファイルサーバー
リード配列全体
n台で計算するとヒトゲノムのコピーがn回発生。
n が大きくネットワークが遅いときには致命的に。
ヒトゲノム配列
遅い 遅い
計算ノード1 計算ノード2 計算ノード3
ヒトゲノム配列 ヒトゲノム配列 ヒトゲノム配列
リードの一部#1 リードの一部#2 リードの一部#3
アラインメント#1 アラインメント#2 アラインメント#3
レプリケーション無し
レプリケーション有り ファイルサーバー1 ファイルサーバー2 ファイルサーバー3
リード配列全体 リード配列全体 リード配列全体
ヒトゲノム配列が
ショットガンリードを分割して
ヒトゲノム配列 ヒトゲノム配列 ヒトゲノム配列
レプリカから読め
並列にアラインメントしたい。
るので高速に。
計算ノード1 計算ノード2 計算ノード3
ヒトゲノム配列 ヒトゲノム配列 ヒトゲノム配列
リードの一部#1 リードの一部#2 リードの一部#3
アラインメント#1 アラインメント#2 アラインメント#3
20. レプリケーションの例4
• Google File System, Gfarm, GlusterFS, Amazon S3 のような
ファイルシステムでは、ファイルをレプリケーションすること
でスループットの向上や耐故障性向上を狙っている。
レプリカは
2~4個が普通
ファイルサーバー1 ファイルサーバー2 ファイルサーバー3 ファイルサーバー4 ファイルサーバー5
ファイルA ファイルA ファイルA
ファイルB ファイルB ファイルB
ファイルC ファイルC ファイルC
ファイルD ファイルD ファイルD
故障
ファイルサーバー1 計算ノード1
が壊れてるけど、使 計算ノード2
わなければいいだけ。
21. レプリケーションの例4
• 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
故障
レプリカの数が足りなくなったら
ファイルを複製してファイルの数を
一定に保つように努力する。
23. シャーディング
• データを複数の範囲に分割して各々を別々の
サーバーで処理する。
– 「範囲」の決め方は様々
• ユーザーIDの範囲、日付の範囲、金額の範囲、
居住地域の範囲、組織の範囲、・・・ etc.
部門別にメールサーバーを X部門向け
メールサーバー
分割してシャーディング
メール
サーバー 社員A 社員C
社員B
社員A 社員E
Y部門向け
社員B 社員D メールサーバー
社員C
社員D 社員E
24. シャーディングと
リレーショナルモデル
• シャーディングは水平パーティーションとも
呼ばれ、関係モデルを水平に分割する。
日付 部門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
25. シャーディングの例1
• DeNA社のモバゲータウン
(1日23億ページ・ビュー)
[もはや “タダ” が常識に?携帯電話ゲームに押し寄せる
無料化の波;日経 BP Net]
ユーザーIDのハッシュ値から
600台のMySQLサーバーから1台を
選んでアバター画像を問い合わせ。
ハッシュ値を使うことで600台のどの
Webサーバーからも同じMySQL
サーバーに問い合わせに行ける。
[600億PVもMySQLで! モバゲーのインフラ底力; @IT Special]
26. シャーディングの例2
• Gmail (Google社のe-メールサービス)
– シャーディングの単位はユーザーアカウント
• ユーザーIDが決まると使用するメールサーバー(群)が決まる
– レプリケーションと併用して耐故障性をアップ
• 図では3レプリカだが実際は4つだったかも?
メールサーバー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] を読むべし。
29. CAP theorem
• 分散システムでは以下の3つを同時に満たす
ことはできないという定理(Brewerの定理)。
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように(部分的に)故障して任意の
ノード間の通信が壊れても動作が続けられること。
30. CAP theorem
• 分散システムでは以下の3つを同時に満たす
ことはできないという定理(Brewerの定理)。
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように(部分的に)故障して任意の
ノード間の通信が壊れても動作が続けられること。
31. Consistency
全てのクライアントから同じものが見えること。
レプリケーション
データA データA
データAを クライアント クライアント
データBに Aを貰った Aを貰った
クライアント クライアント
更新 Aを貰った
Aを貰った
データB データB
Consistency クライアント クライアント
データの更新があっても全 Bを貰った
てのクライアントが同じ Bを貰った
データを見ることができる
クライアント クライアント
こと。 Bを貰った
Bを貰った
32. Google が人によって違う答えを
返す理由
Google
「シュミレーション」で 検索DB
コピーが終わった マスター
検索したら7,240,000
件もあった!
Google
Consistent 検索
でない えー、ぼくが検索する まだ最新データは
と 6,800,000件しか無 人 人 コピー中
いんだけど・・・。
シュミレーション 7,240,000
Google
細かいことは気にす 人 検索
るなって!誤差だよ
誤差。
人 人
コンピューターで
Consistency
データの更新があっても全
誤差ってなんだよ シュミレーション 6,800,000
てのクライアントが同じ 誤差って!
データを見ることができる 人
こと。
33. CAP theorem
• 分散システムでは以下の3つを同時に満たす
ことはできないという定理(Brewerの定理)。
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように(部分的に)故障して任意の
ノード間の通信が壊れても動作が続けられること。
34. レプリケーションの例1(再)
• アクセス数が非常に多いWebサーバー。
数日後、キャッシュサーバで
原発事故直後
大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ
人 人 人
人 人
人 人 人
人 人 人
アクセスまばら
人 人 人 人
Availability
障害の無いノードにデータ
読出/書込要求が来たら
アクセス殺到でなかなか
有限の時間内に操作を完 繋がらない
了して返事をすることがで
きること。 ※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化
35. レプリケーションの例1 (再)
• アクセス数が非常に多いWebサーバー。
数日後、キャッシュサーバで
原発事故直後
大規模レプリケーションを実施
平常時
TEPCO
ホームページ
TEPCO
ホームページ
人 人 人
人 人
人 人
人 人 人
人
故障
アクセスまばら
1台故障しても
人 人 人 人
Availability ウェブページは
障害の無いノードにデータ
アクセス殺到でなかなか 見られるので
読出/書込要求が来たら
有限の時間内に操作を完 繋がらない Availabilityがある。
了して返事をすることがで
きること。 ※本当はAkamaiでもっと複雑なことをやっていたが説明のために超簡略化
36. シャーディングの例2(再)
• Gmail (Google社のe-メールサービス)
– シャーディングの単位はユーザーアカウント
• ユーザーIDが決まると使用するメールサーバー(群)が決まる
– レプリケーションと併用して耐故障性をアップ
• 図では3レプリケーションだが実際は確か4つ。
故障
メールサーバー1
故障
メールサーバー2 メールサーバー3 メールサーバー5
メールサーバー4
ユーザーA ユーザーA ユーザーA
ユーザーB ユーザーB ユーザーB
ユーザーC ユーザーC ユーザーC
ユーザーD ユーザーD ユーザーD
メール削除いける?
Availability
メール番号
障害の無いノードにデータ レプリカが音信不通
読出/書込要求が来たら 1435132を
有限の時間内に操作を完 なので今は無理です。
了して返事をすることがで
削除してよ!
きること。
人
37. CAP theorem
• 分散システムでは以下の3つを同時に満たす
ことはできないという定理(Brewerの定理)
証明したのは Seth Gilbert & Nancy Lynch だけどね・・・。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように(部分的に)故障して任意の
ノード間の通信が壊れても動作が続けられること。
38. Partition tolerance とは何か?
• 直感的ないくつかの説明
– システムをいくつかの部分に分割することができて、
クライアントからメッセージが届いたときに誤った返答
を返さないこと。
– Partition tolerance が無いシステムは部分的な故障
が許されていないか、または部分的な故障時に
クライアントに誤ったメッセージを返すことがある。
39. レプリケーションの例で
Partition Tolerance を説明
• アクセス数が非常に多いWebサーバー
故 更新が無いとするとたとえば、
障 レプリカ間のネットワークが
故障しても問題がない。
ノード間
ユーザーとの間のネットワーク
通信網 が壊れたら問題だが、これは
どんなシステムでも明らかに
アクセス不能だし、定義中の
「任意のノード間」にユーザーと
Partition tolerance の間は含まれていない。
ネットワークがどのよう
に(部分的に)故障して
任意のノード間の通信
が壊れても動作が続
けられること。
40. シャーディングの例2(再)
ノード間
通信網
故障
メールサーバー1 メールサーバー2 メールサーバー3 メールサーバー4 メールサーバー5
ユーザーA ユーザーA ユーザーA
ユーザーB ユーザーB ユーザーB
ユーザーC ユーザーC ユーザーC
ユーザーD ユーザーD ユーザーD
メール削除いける?
Partition tolerance
ネットワークがどのよう メール番号
に(部分的に)故障して レプリカが音信不通
1435132を
任意のノード間の通信 なので今は無理です。
が壊れても動作が続
削除してよ!
けられること。
人
41. CAP theorem (復習)
• 分散システムでは以下の3つを同時に満たす
ことはできないという定理(Brewerの定理)。
– Consistency
• データの更新があっても全てのクライアントが同じ
データを見ることができること。
– Availability
• 障害の無いノードにデータ読出/書込要求が来たら
有限の時間内に操作を完了して返事をすることができ
ること。
– Partition tolerance
• ネットワークがどのように(部分的に)故障して任意の
ノード間の通信が壊れても動作が続けられること。
42. CAP定理を背理法で証明
レプリケーション
ノード間
通信網 システムの通常動作は
データA データA このようになっている。
データちょうだい Aだよ Aだよ データちょうだい
クライアント クライアント
ノード間
通信網 Partition tolerance &
デーA データA
Availability より返事できる
故障 Aだよ データちょうだい
クライアント クライアント
ノード間
Partition tolerance & 通信網 右のサーバーからは上の
Availability より データB データA ケースと区別が付かないが、
書き込みも可能 Consistency が壊れた■
データBを書いて B書いたよ 故障 Aだよ データちょうだい
クライアント クライアント