The Datacenter as a Computer2章1節～3節　

2009/12/06id:marqs吉田晃典

2章● Workloads and Software Instracture

– 負荷とソフトウェアインフラストラクチャ

● WSCs環境のアプリケーションはシステム設計に影響を与える

– 大規模インターネットサービスにおけるソフトウェア

– 構築のためのシステムソフトウェアとツール

用語● WSC環境下での3つのソフトウェアレイヤ

– プラットフォームレベルソフトウェア● ファームウェア、カーネル、OS、ライブラリなど1台のサーバのハードウェア群を抽象化するソフトウェア

– クラスターレベルインフラストラクチャ● クラスタレベルでのリソース管理をしたりサービス提供するソフトウェアの集合体

● データセンターにおけるOS– 分散ファイルシステム/スケジューラ/RPC/プログラミングモデル(ex. MapReduce,hadoop,Sawzall,BigTable,Dynamo など）

– アプリケーションレベルソフトウェア● 実際のサービスに使われるソフトウェア● オンライン: GoogleMaps,Gmail● オフライン: 大規模データ解析/処理（インデックス作成、画像処理）

データセンター vs　デスクトップ

● ソフトウェア開発の四つの相違点

– 並列処理

– 負荷が変化しやすい

– プラットフォームが共通（均一、均質）

– Fault free 運用

並列処理● データ並列処理

– ウェブページやログなど大量の互いに独立なデータセットによる

– 通信や同期のオーバーヘッドをなくすため、計算を必要とする

● リクエストレベルの並列処理

– 大量のユーザアクセス

– 例● 検索リクエストは独立 & リードオンリーDBでOK

– 計算はリクエスト内でも、別のリクエストの間でも分けやすい？？

● メールユーザデータを変更するが、処理はユーザ毎に独立

負荷が変化しやすい● デプロイサイクルが早い

– 週単位　vs 年単位

– システム設計者はベンチマークを取りにくい

● 人気が出てユーザが増えると、すぐ負荷が増大する

– ハードウェアアーキテクトは一つのコードでよいパフォーマンスを出す必要がない　（デプロイサイクル早いから）

– しかし、新しいハードウェアの特徴を生かすためのソフトウェア書き直しが求められる

プラットフォームが均質● ソフトウェアのデプロイ対象としては、データセンターは均一である

● 不均一性

– コスト効率のよいハードが出てきたときに出現

● スケジューリングと負荷分散が単純になる

● プラットフォームレベルソフトウェア(driver,firmware etc)のメンテナンスの苦しみが少ない

● サプライチェーンと修理の効率化● 種類少ない方が修理楽

● デスクトップは何百万ものハード構成がありサポートが大変

データセンター vs. デスクトップまとめ

● Helpful

– 並列処理

– プラットフォームの均一性

– 単純

● Not Helpful

– スケール

– ハードウェア故障

– 負荷変動のスピード

Performance and Availability toolbox● いくつかのプログラミングコンセプト

– インフラレベル、アプリケーションレベル両方で

– ハイパフォーマンス、高可用性においての適用性が広いため

● 一般的な概念

– レプリケーション

– 分割

– 負荷分散

– ヘルスチェックとウォッチドック

– 整合性チェック

– 特定用途圧縮

– 結果整合性

performance Availability

レプリケーション

○ ○

分割 ○ ○

負荷分散 ○

ヘルスチェック

○

整合性チェック

○

用途特化圧縮 ○

結果整合性 ○ ○

レプリケーション● パフォーマンスにも可用性にも

● あまり変更されないデータで特に威力を発揮

分割● データを分割して、多数のノードに分配

● オペレーションは各ノードで行われて、結果は統合される

● 分割ポリシーはいろいろ

– パフォーマンス重視

– 容量重視

● 細かく分割されたデータ断片のリカバリは大きいデータより早い

負荷分散● 一番遅いレスポンダが支配的

– レスポンスタイムの分散を少なくすることが重要

● 負荷分散は各サーバあたりのWorkを同じにする分割ポリシーを加えることによって到達

● レプリが動いてる環境

– ロードバランサがどのサーバにリクエストを投げるか動的に調整する

– 完全なロードバランスは難しい

ヘルスチェックとウォッチドッグタイマ● 遅いサーバや不達のサーバを早く発見し、リクエストを飛ばさないように

● RPCはタイムアウト値を設定

整合性チェック● 失敗はデータ破損によってもおこる

● 頻度は低いがおきる

– ハードウェアチェックやソフトウェアチェックでは見つけられない

● データ欠損はさらなるソフトウェアチェックで減らせる

– 潜在的なエンコードを変更する

– 信頼性の高い整合性チェックをする

用途特化圧縮● 最近のデータセンターでの機器コストの大部分はストレージレイヤにある

● 高スループットのサービスではデータの大部分をDRAMに置くことが重要

● それゆえ、圧縮技術が重要になってくる

● CPUで展開するオーバーヘッドは、データがディスクに乗ってしまうことに比べれば、相当小さい

● 一般的な圧縮アルゴリズムは結構いい

● でも用途特化した圧縮は、もっとよい

結果整合性● レプリをいっぱいふやす

– 複雑さが増える

– パフォーマンスに影響

– 分散アプリの可用性を減らす

● 大規模並行アプリケーションのレスポンスタイムは高信頼性計算テクニックで改善できる

– 一つの遅いワーカで、大規模並行タスクのレスポンスタイムが決定する

– そういう遅いワーカを別のワーカで代替する

クラスタレベルの基盤ソフトウェア● OSが、1台のコンピュータの、リソースマネジメントと基本サービスを提供するように、多数のコンピュータ、ネットワーク機器、ストレージのある環境でも、OSに類似した機能を提供するソフトウェアが必要である。

● これをクラスタレベルの基盤と呼ぶ

● クラスタレベルの基盤をなす、4つの大きなグループを解説する

1.リソース管理● 不可欠

● ユーザタスクをハードウェアに割り当てる

● 優先度と上限をつける

● タスクマネジメント

● 一番単純な形

– ハードウェアをユーザやジョブに割り当てる

2.ハードウェア抽象化● 大規模分散アプリケーションは、いくつかの基本機能が必要

● 分散ストレージ、メッセージパッシング、同期

● 大規模システムでこれらをパフォーマンスと可用性を保ちつつ実現するのは複雑で難しい

● 各アプリケーションで実装するのは賢くない

● 共通モジュール/サービスをつくるべし

● GFS、Dynamo、Chubby、など

3.デプロイとメンテナンス

● 監視重要

– 小規模デプロイでのマニュアル実行は大規模システムでは適切なインフラが必要

– ソフトウェアイメージ配布と構成管理、パフォーマンスと品質の監視、緊急事態のトリアージ

● 例: Autopiot system from Microsoft

– ハードウェア監視、自動診断、自動修理● 例: GoogleのSystem Health Infrastructure

– パフォーマンスデバッグと最適化● 例: X-Trace by UCBerkley 監視インフラ

4.プログラミングフレームワーク● これまで述べたのはハードウェアのデプロイと効率的な利用

● プログラマにとっての複雑さは隠蔽できてない

● プラグラマの視点から

– メモリ/ストレージの階層が複雑

– 故障しがち

– メモリ、ネットワークバンド幅が少ない

– 不均質

● 一部はプログラミングフレームワークをつくることで解決

– MapReduce,BigTable,Dynamo

– データ分割、配布、耐障害性を自動的に処理

Fault free 運用● 何千台もサーバがあると数時間に一回は故障する

● MTBFが1年はPCレベルではリーズナブルでも、データセンターレベルのサービスではこれは嘘

● 故障は日常的

● クラスターレベルシステムソフトウェアはアプリケーションソフトウェアからそういったのを隠さないといけない

– 全部のアプリに対してそれを実現するのは難しい