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

1,422 views

Published on

東京大学理学部生物情報科学科平成23年度生物データベース論(スケーラビリティと可用性)のスライド。

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,422
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

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

×