Datacenter as a Computer (2.4 ~ 2.6) 2009/12/06 id:shiumachi
Agenda <ul><li>2.4 アプリケーションレベルのソフトウェア </li><ul><li>Web 検索
論文類似性スコアリング処理 </li></ul><li>2.5 監視インフラ </li><ul><li>サービスレベル・ダッシュボード
パフォーマンス・デバッギング・ツール
プラットフォームレベルでの監視 </li></ul><li>2.6 買うか作るか </li></ul>
2.4 アプリケーションレベルのソフトウェア
情報爆発とサービスの変化 <ul><li>90年代半ばにWebコンテンツが爆発的に増加
家庭向け・ビジネス向けにもネットへの接続速度が増加 </li></ul> ->多くの新しいサービスが増加 ネットの海
データセンタの要件 <ul><li>特化型コンピュータは×! 汎用性が高いことが必須 </li></ul><ul><ul><li> 新しいアプリケーションはどんどん増えるので、特化型にしてもその恩恵を受けるソフトの割合は少なくなっていく
プログラマが既存のアプリケーションを速いスパンで書き直していくと、特化型はすぐに役に立たなくなる </li></ul></ul>
オンライン型:Web検索 <ul><li>“needle in a haystack” 問題 </li><ul><li>「干し草の山から一本の針を探す」 </li></ul><li>基本的な流れ </li><ul><li>Webサーバからクエリ...
ヒットしたドキュメントIDのリストをランク順に返す
IDリストを再度投げて詳細情報(タイトル・本文など)を受け取る </li></ul></ul>
インデックスの分散 <ul><li>インデックスが巨大すぎるので、分散配置
各ローカルで検索・ランクづけして上位のサーバに渡す </li></ul>数千ノード 上位サーバ インデックスサーバ
文書データの取得 <ul><li>ヒットした文書 ID をドキュメントサーバに投げて、文書情報を取得する
各サーバでの処理は独立してる ( 後でマージすればいい )
だから文書 ID 単位でデータを分けた方がいい </li></ul>明記してないけど多分 インデックスサーバとは別 Web サーバ ドキュメントサーバ
オフライン型 論文類似性スコアリング処理 <ul><li>Google Scholar では論文の類似性を共引用(co-citation)されている論文の数で判断している </li><ul><li>共引用とは、2つ以上の論文が1つの論文から引用...
Upcoming SlideShare
Loading in …5
×

Decotai Shiumachi 091206

1,107 views

Published on

Reading "Datacenter as a Computer" 2.4 - 2.6(written in Japanese)

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

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

No notes for slide

Decotai Shiumachi 091206

  1. 1. Datacenter as a Computer (2.4 ~ 2.6) 2009/12/06 id:shiumachi
  2. 2. Agenda <ul><li>2.4 アプリケーションレベルのソフトウェア </li><ul><li>Web 検索
  3. 3. 論文類似性スコアリング処理 </li></ul><li>2.5 監視インフラ </li><ul><li>サービスレベル・ダッシュボード
  4. 4. パフォーマンス・デバッギング・ツール
  5. 5. プラットフォームレベルでの監視 </li></ul><li>2.6 買うか作るか </li></ul>
  6. 6. 2.4 アプリケーションレベルのソフトウェア
  7. 7. 情報爆発とサービスの変化 <ul><li>90年代半ばにWebコンテンツが爆発的に増加
  8. 8. 家庭向け・ビジネス向けにもネットへの接続速度が増加 </li></ul> ->多くの新しいサービスが増加 ネットの海
  9. 9. データセンタの要件 <ul><li>特化型コンピュータは×! 汎用性が高いことが必須 </li></ul><ul><ul><li> 新しいアプリケーションはどんどん増えるので、特化型にしてもその恩恵を受けるソフトの割合は少なくなっていく
  10. 10. プログラマが既存のアプリケーションを速いスパンで書き直していくと、特化型はすぐに役に立たなくなる </li></ul></ul>
  11. 11. オンライン型:Web検索 <ul><li>“needle in a haystack” 問題 </li><ul><li>「干し草の山から一本の針を探す」 </li></ul><li>基本的な流れ </li><ul><li>Webサーバからクエリを投げる
  12. 12. ヒットしたドキュメントIDのリストをランク順に返す
  13. 13. IDリストを再度投げて詳細情報(タイトル・本文など)を受け取る </li></ul></ul>
  14. 14. インデックスの分散 <ul><li>インデックスが巨大すぎるので、分散配置
  15. 15. 各ローカルで検索・ランクづけして上位のサーバに渡す </li></ul>数千ノード 上位サーバ インデックスサーバ
  16. 16. 文書データの取得 <ul><li>ヒットした文書 ID をドキュメントサーバに投げて、文書情報を取得する
  17. 17. 各サーバでの処理は独立してる ( 後でマージすればいい )
  18. 18. だから文書 ID 単位でデータを分けた方がいい </li></ul>明記してないけど多分 インデックスサーバとは別 Web サーバ ドキュメントサーバ
  19. 19. オフライン型 論文類似性スコアリング処理 <ul><li>Google Scholar では論文の類似性を共引用(co-citation)されている論文の数で判断している </li><ul><li>共引用とは、2つ以上の論文が1つの論文から引用されていること </li></ul></ul>スコア1 スコア2 スコア2 論文A1 論文A2 論文B1 論文B2 論文B3
  20. 20. Google の手法 <ul><li>Google は MapReduce を使ってこの処理を行う </li><ul><li>Map: 全論文の引用リストを作り、リスト内の全論文のペアを作る </li><ul><li>この段階で共引用のない論文は削られるので、データ量はそれほど爆発的には増大しない </li></ul><li>Reduce: 論文のペアの共引用の数をカウントする </li></ul></ul>
  21. 21. <ul><li>2.5 監視インフラ </li></ul>
  22. 22. サービスレベル・ダッシュボード <ul><li>大量のノードをリアルタイムで監視する必要がある </li><ul><li>シグナルだけでなくシグナル送信時間も監視できること
  23. 23. レイテンシやスループット以外にもサービス固有のパラメータも監視できること
  24. 24. オペレータが派生パラメータを作りやすいシンプルな言語であること
  25. 25. 自動通報機能を備えていること </li><ul><li>通報機能の適切なチューニングは大変…… </li></ul></ul></ul>
  26. 26. パフォーマンス・デバッギング・ツール <ul><li>サービスレベル・ダッシュボードとの違い </li><ul><li>リアルタイム性は不要
  27. 27. どこがボトルネックか分析できることが第一 </li></ul></ul>
  28. 28. パフォーマンスの測定方法 <ul><li>測定方法は2通り </li><ul><li>ブラックボックスモニタリング </li><ul><li>トラフィック分析とか
  29. 29. WAP5, Sherlock </li></ul><li>ツールベースのトレース </li><ul><li>Pip, Magpie, X-trace, Dapper( from Google) </li></ul></ul></ul>
  30. 30. プラットフォームレベル監視 <ul><li>高可用性を維持するためには前述の2つのソフトだけでは不足
  31. 31. ハード・ソフト障害を分析し、プラットフォーム全体の状態を監視する必要あり
  32. 32. 詳細は6章にて </li></ul>
  33. 33. 2.6 買うか作るか
  34. 34. 自分で作った方がいい理由(1) <ul><li>サードパーティのパッケージはラージスケールのインターネットサービスには不適 </li><ul><li>柔軟性がない </li><ul><li>バグが見つかってもすぐに適用できない </li></ul><li>問題の発見に時間がかかる </li><ul><li>ネットワークの問題も、RPCライブラリレベルなら発見しやすい </li></ul></ul></ul>
  35. 35. 自分で作った方がいい理由(2) <ul><li>充分なテストやチューニングができない
  36. 36. 自社のサービスに不要な機能が含まれている </li><ul><ul><li>BigTable : 既存のSQLよりも機能を減らしている
  37. 37. GFS : POSIX 準拠していない </li></ul></ul></ul>
  38. 38. Thank you !

×