Download as PDF, PPTX
Data Center As A Computer 2章前半
- 1. The Datacenter asa Computer 2章1節～3節 2009/12/06 id:marqs 吉田晃典
- 2. 2章 ● Workloads and Software Instracture – 負荷とソフトウェアインフラストラクチャ ● WSCs環境のアプリケーションはシステム設計 に影響を与える – 大規模インターネットサービスにおけるソフトウェ ア – 構築のためのシステムソフトウェアとツール
- 3. 用語 ● WSC環境下での3つのソフトウェアレイヤ – プラットフォームレベルソフトウェア ● ファームウェア、カーネル、OS、ライブラリなど1台の サーバのハードウェア群を抽象化するソフトウェア – クラスターレベルインフラストラクチャ ● クラスタレベルでのリソース管理をしたりサービス提供 するソフトウェアの集合体 ● データセンターにおけるOS – 分散ファイルシステム/スケジューラ/RPC/プログラミングモデ ル(ex. MapReduce,hadoop,Sawzall,BigTable,Dynamo など） – アプリケーションレベルソフトウェア ● 実際のサービスに使われるソフトウェア ● オンライン: GoogleMaps,Gmail ● オフライン: 大規模データ解析/処理（インデックス作 成、画像処理）
- 4. データセンター vs デスクトップ ● ソフトウェア開発の四つの相違点 – 並列処理 – 負荷が変化しやすい – プラットフォームが共通（均一、均質） – Fault free 運用
- 5. 並列処理 ● データ並列処理 – ウェブページやログなど大量の互いに独立なデータ セットによる – 通信や同期のオーバーヘッドをなくすため、計算を 必要とする ● リクエストレベルの並列処理 – 大量のユーザアクセス – 例 ● 検索リクエストは独立 & リードオンリーDBでOK – 計算はリクエスト内でも、別のリクエストの間でも分けやす い？？ ● メールユーザデータを変更するが、処理はユーザ毎に独 立
- 6. 負荷が変化しやすい ● デプロイサイクルが早い – 週単位 vs 年単位 – システム設計者はベンチマークを取りにくい ● 人気が出てユーザが増えると、すぐ負荷が増大 する – ハードウェアアーキテクトは一つのコードでよいパ フォーマンスを出す必要がない （デプロイサイク ル早いから） – しかし、新しいハードウェアの特徴を生かすための ソフトウェア書き直しが求められる
- 7. プラットフォームが均質 ● ソフトウェアのデプロイ対象としては、データ センターは均一である ● 不均一性 – コスト効率のよいハードが出てきたときに出現 ● スケジューリングと負荷分散が単純になる ● プラットフォームレベルソフトウェア (driver,firmware etc)のメンテナンスの苦し みが少ない ● サプライチェーンと修理の効率化 ● 種類少ない方が修理楽 ● デスクトップは何百万ものハード構成がありサ ポートが大変
- 8. データセンター vs. デスクトップ まとめ ● Helpful – 並列処理 – プラットフォームの均一性 – 単純 ● Not Helpful – スケール – ハードウェア故障 – 負荷変動のスピード
- 9. Performance and Availabilitytoolbox ● いくつかのプログラミングコンセプト – インフラレベル、アプリケーションレベル両方で – ハイパフォーマンス、高可用性においての適用性が 広いため ● 一般的な概念 – レプリケーション – 分割 – 負荷分散 – ヘルスチェックとウォッチドック – 整合性チェック – 特定用途圧縮 – 結果整合性
- 10. performance Availability レプリケー ○ ○ ション 分割 ○ ○ 負荷分散 ○ ヘルスチェッ ○ ク 整合性チェッ ○ ク 用途特化圧縮 ○ 結果整合性 ○ ○
- 11. レプリケーション ● パフォーマンスにも可用性にも ● あまり変更されないデータで特に威力を発揮
- 12. 分割 ● データを分割して、多数のノードに分配 ● オペレーションは各ノードで行われて、結果は 統合される ● 分割ポリシーはいろいろ – パフォーマンス重視 – 容量重視 ● 細かく分割されたデータ断片のリカバリは大き いデータより早い
- 13. 負荷分散 ● 一番遅いレスポンダが支配的 – レスポンスタイムの分散を少なくすることが重要 ● 負荷分散は各サーバあたりのWorkを同じにす る分割ポリシーを加えることによって到達 ● レプリが動いてる環境 – ロードバランサがどのサーバにリクエストを投げる か動的に調整する – 完全なロードバランスは難しい
- 14. ヘルスチェックとウォッチドッグタイマ ● 遅いサーバや不達のサーバを早く発見し、リク エストを飛ばさないように ● RPCはタイムアウト値を設定
- 15. 整合性チェック ● 失敗はデータ破損によってもおこる ● 頻度は低いがおきる – ハードウェアチェックやソフトウェアチェックでは 見つけられない ● データ欠損はさらなるソフトウェアチェックで 減らせる – 潜在的なエンコードを変更する – 信頼性の高い整合性チェックをする
- 16. 用途特化圧縮 ● 最近のデータセンターでの機器コストの大部分 はストレージレイヤにある ● 高スループットのサービスではデータの大部分 をDRAMに置くことが重要 ● それゆえ、圧縮技術が重要になってくる ● CPUで展開するオーバーヘッドは、データが ディスクに乗ってしまうことに比べれば、相当 小さい ● 一般的な圧縮アルゴリズムは結構いい ● でも用途特化した圧縮は、もっとよい
- 17. 結果整合性 ● レプリをいっぱいふやす – 複雑さが増える – パフォーマンスに影響 – 分散アプリの可用性を減らす
- 18. ● 大規模並行アプリケーションのレスポンスタイ ムは高信頼性計算テクニックで改善できる – 一つの遅いワーカで、大規模並行タスクのレスポン スタイムが決定する – そういう遅いワーカを別のワーカで代替する
- 19. クラスタレベルの基盤ソフトウェア ● OSが、1台のコンピュータの、リソースマネジ メントと基本サービスを提供するように、多数 のコンピュータ、ネットワーク機器、ストレー ジのある環境でも、OSに類似した機能を提供 するソフトウェアが必要である。 ● これをクラスタレベルの基盤と呼ぶ ● クラスタレベルの基盤をなす、4つの大きなグ ループを解説する
- 20. 1.リソース管理 ● 不可欠 ● ユーザタスクをハードウェアに割り当てる ● 優先度と上限をつける ● タスクマネジメント ● 一番単純な形 – ハードウェアをユーザやジョブに割り当てる
- 21. 2.ハードウェア抽象化 ● 大規模分散アプリケーションは、いくつかの基 本機能が必要 ● 分散ストレージ、メッセージパッシング、同期 ● 大規模システムでこれらをパフォーマンスと可 用性を保ちつつ実現するのは複雑で難しい ● 各アプリケーションで実装するのは賢くない ● 共通モジュール/サービスをつくるべし ● GFS、Dynamo、Chubby、など
- 22. 3.デプロイとメンテナンス ● 監視重要 – 小規模デプロイでのマニュアル実行は大規模システ ムでは適切なインフラが必要 – ソフトウェアイメージ配布と構成管理、パフォーマ ンスと品質の監視、緊急事態のトリアージ ● 例: Autopiot system from Microsoft – ハードウェア監視、自動診断、自動修理 ● 例: GoogleのSystem Health Infrastructure – パフォーマンスデバッグと最適化 ● 例: X-Trace by UCBerkley 監視インフラ
- 23. 4.プログラミングフレームワーク ● これまで述べたのはハードウェアのデプロイと 効率的な利用 ● プログラマにとっての複雑さは隠蔽できてない ● プラグラマの視点から – メモリ/ストレージの階層が複雑 – 故障しがち – メモリ、ネットワークバンド幅が少ない – 不均質 ● 一部はプログラミングフレームワークをつくる ことで解決 – MapReduce,BigTable,Dynamo – データ分割、配布、耐障害性を自動的に処理
- 24. Fault free 運用 ● 何千台もサーバがあると数時間に一回は故障す る ● MTBFが1年はPCレベルではリーズナブルで も、データセンターレベルのサービスではこれ は嘘 ● 故障は日常的 ● クラスターレベルシステムソフトウェアはアプ リケーションソフトウェアからそういったのを 隠さないといけない – 全部のアプリに対してそれを実現するのは難しい