KOF2009ウェブサービスのパフォーマンスとスケーラビリティ
はてな 田中 慎司stanaka @ hatena.ne.jp
http://d.hatena.ne.jp/stanaka/http://twitter.com/stanaka/
アジェンダ ウェブサービスのパフォーマンス
バックエンドとフロントエンド システムのスケーラビリティ
ウェブサービスの特性 負荷と効率と安定性 ハードウェア
はてなのサービス群
サービス規模 登録ユーザ数 : 120 万 月間ユニークユーザ数 : 1200 万
ウェブサービスのパフォーマンス 基本 : Firebug で計測
パフォーマンスモデル
レスポンス HTML ページ ページ要素取得
レンダリング完了
主要要素 HTML ページの返却時間 含まれるページ要素の時間 含まれるページ要素の数 レンダリング速度
時間
主にバックエンド
主にフロントエンド
フロントエンドのパフォーマンス 含まれるページ要素の数
CSS Sprite により削減 画像リクエストを圧縮
レンダリング速度 広告の遅延ロード
Adsense を後回し
Firefox 拡張 Google .. Page Speed Yahoo .. YSlow
バックエンドのパフォーマンス HTML ページのレスポンス時間 含まれるページ要素のレスポンス時間
パフォーマンスの向上 スケーラビリティの確保
含まれるページ要素の数 ヘッダを適切に
ETag, Cache-Control, Last-Modified など→ そもそもリクエストされないようにする
レスポンス時間の計測 計測方法
特定の URL を叩いて、その時間を計測 生アクセスログから収集
生アクセスログを分析 Hadoop クラスタ
Core2Quad サーバ 10 台 はてなダイアリーのログ 4GB → 10 分程度で処理
分布をグラフ化
レスポンス時間の分布グラフ
良好なレスポンスの例
キャッシュによる影響
システムの基本構造
proxy proxy
LVS
LVS
mod_perl mod_perl mod_perl mod_perl
LVS
MySQL MySQL
LVS
LVS
LVS
リバースプロキシ
アプリケーションサーバ
データベースサーバ
ロードバランサ
はてなブックマークの場合
アプリ( ユーザ )
DBcontent
アプリ(bot)
DBentry
DBhtml
DBkeyword
memcached
hadoop
searchersquid
worker関連文書
カテゴライズ
計数十台ロード
バランサリバースプロキシ
アプリ(image)
サーバ 500 台強 → 仮想化して約 1150台
はてなのサーバ台数
Web サービスの 3 つの指標 スケーラビリティ
大量のリクエスト 個々のリクエストは比較的単純 サービスの成長の予想が難しい
高可用性 24/365
コストパフォーマンス 1 リクエストの処理にかけられるコストは低
い 処理のほとんどは非クリティカル
1. スケーラビリティ 多くのサービスはサーバ 1 台で動く
はてな標準サーバ 4 core CPU, 8GB RAM ピーク性能は、数千リクエスト /分
そこそこのサーバ 4 core CPU x 2, 32GB RAM
大規模サービスはサーバ 1 台では動かない 100 万 PV/ 月程度が今の限界
→ はてなでは、数億 PV/ 月
レイヤごとのスケーラビリティ アプリケーションサーバー
構成が同一で状態を持たない → 容易 データソース (DB, ファイルサーバ etc)
read の分散 → 比較的容易 メモリを一杯載せる、とか
write の分散 → 難しい
負荷の把握 負荷の把握
サーバー管理ツール (http://servers.hatena.ne.jp/) 状態の監視
負荷を可視化して、ボトルネックや異常を把握可能に
OS の動作原理を知り、性能を正しく引出す
スケーラビリティとソフトウェア開発 開発の前提
大量の PV が発生すること 大規模なデータが蓄積されること
僅かな負荷の増大が予想外の影響を起すことも… 発行する SQL が変化 参照するデータソースが増加
2. 高可用性 24/365 耐障害性
冗長化 フェイルオーバ
安定したインフラ 過度なリソース消費の回避 適切なバッファの維持
安定性 24 時間 365日 100% の稼働率要求 SPOF (Single Point of Failure) の除去
冗長性の確保
冗長性確保の実際 アプーケーションサーバは冗長化しやすい
状態を持たない データソースは冗長化が難しい
状態の複製・同期 基幹部分のネットワークは冗長化が比較的
難しい
安定させるために トレードオフ
安定性 ←→ 資源効率 安定性 ←→ 速度
ギリギリまでメモリをチューニング メモリ消費が増える → 性能低下 → 障害
ギリギリまで CPU を使う 1 台落ちる → キャパシティオーバー → 障害
環境の不安定要因 アプリケーション
機能追加 メモリリーク・地雷 ユーザアクセスパターンの変動 データ量の増加 外部連携の追加
ハードウェア メモリ・ HDD・ NIC障害
負荷増大
能力低下
ロバストなシステムに 状態を持つプロセスを減らす
基本 DB に集約する 状態を再構成できるようにする
失なわれて困らないようにする 局所的な障害の影響を抑える
冗長度を高めて障害による負荷の集中・増大を抑える
冗長性 安いハードで高信頼 マルチマスタ 無停止メンテナンス
マスターDB
マスターDB
アプリケーションサーバ
X
相互にレプリケーション
無停止メンテナンス 無停止での DB メンテナンス
ローリング・アップデート 条件
メンテ前後で矛盾しないこと 1 台で耐えられること
マスターDB
マスターDB
アプリケーションサーバ
マスターDB
マスターDB
アプリケーションサーバ
メンテナンス
3. コストパフォーマンス 1 台のハードで多くのリクエストを処理
リソース効率
1 台の単価を下げる ハードコスト
運用コストを下げる 一人あたりのハード数
低コストを実現する技術 #1
指数的に性能が向上するハードウェア ムーアの法則
「集積回路上のトランジスタ数は 18 か月ごとに倍になる」
出典 : http://www.intel.co.jp/jp/intel/museum/processor/index.htm
低コストを実現する技術 #1
メモリ・ HDD も急速に安価になっている 3年前 .. 2GB で 30,000円
8GB で 120,000円 現在 .. 2GB x 2 で 5,000円程度
8GB で 10,000円
4コア 8GB のサーバが 3年前 数十万円 現在 8万円
メモリ・ HDD価格の推移
出典 : http://www2s.biglobe.ne.jp/~sakharov/research/pfo_main.html
メモリ HDD
低コストを実現する技術 #2
コモディティ化・オープン化するソフトウェア
オープンソース OS(Linux) 言語 (C, C++, Perl, Ruby, …) データベース (MySQL, PostgreSQL, …) ウェブサーバ (Apache, Lighttpd) フレームワーク (Ruby on Rails, Catalyst, …) 大規模コンピューティング (Hadoop)
システムを安価に構築 ソフトウェアで頑張れるところは頑張る
NAS・ SAN → 普通の PC サーバ + MogileFS
箱物ルータ → 普通の PC ルータ
参考 : Google ECC メモリは使用 RAID は使用せず
ハードウェアへの要求仕様 CPU → それなりに高速 メモリ → 8G 程度 ストレージ → 2.5”HDD or SSD
ホットスワップはしたい NIC → 基本 1 ポートで十分 遠隔管理機能 → あまりいらない 電源冗長化 → ほとんど不要
欲しい仕様があまり世の中にない
仮想化を前提としたハードウェア 安価なハードの有効利用
最小限の管理機能 多コアの CPU 大量のメモリ フレキシブルな IO 性能
Diskless ハードウェア RAID-10 SSD RAID-0
管理用のハードコンソールを不要にする IPMI \1〜2万 /サーバ → Intel AMT
独自ハードウェア 小回り 集積密度の向上 新規パーツの調達
独自ハードウェア
独自ハードウェア デスクトップ用 M/B
Intel AMT デスクトップ用 CPU ネットワークポート x 1 ECC なしメモリ RAID なし or Software RAID
独自ハードウェア
参考 : Google のサーバ
出典 : http://news.cnet.com/8301-1001_3-10209580-92.html
独自ハードウェア 新旧
ハードウェアの性能を引出す 安価なハードを構築 ハード特性の利用
データをメモリに載せる MySQL, TokyoTyrant とか
IO 性能の分散
データ量にメモリ量を合わせる32G 16G
単体性能の向上例 SSD: Solid State Drive アクセス性能
良好なランダムアクセス性能 メモリ > SSD > HDD RAID-0/10 > HDD
RAID-1 メモリほどではないが、十分に高速
Intel SSD X-25E/M 本番環境で稼働中
オンメモリ vs SSD
32G 16G + SSD
IOwait はほとんど発生せず
32GB … ほぼオンメモリSSD … 大量の ioread
SQL 処理性能はほぼ同一
SSD のリスク まだリスクも ..
障害パターンが不明 昨年の秋口に購入した安価 SSD は半年で故障 Intel SSD は未故障
いつでも再構成可能な箇所で使用
その他の要素技術 ネットワーク 仮想化技術 カスタムエンジン 計算クラスタ グローバル対応
ネットワークの冗長化
ルータ用ハードウェア ちょっといい M/B
ASUS/SuperMicro デスクトップ用 CPU ネットワークポート x 2 ECC メモリ IPMI
仮想化技術
仮想化技術への期待 スケーラビリティ
オーバーヘッドの最小化 コストパフォーマンス
リソースの消費効率の向上 運用の柔軟さ
環境の単純化 高可用性
環境の隔離
仮想化技術のメリット IPMI の代替としてのハイパーバイザ 環境の抽象化
ハード差分の吸収 リソース消費の制御
過負荷のアラート 負荷の調整
自律制御 monit*1 との組み合わせ
*1: リソース監視ツール http://mmonit.com/monit/
仮想化技術のメリット IPMI の代替としてのハイパーバイザ 環境の抽象化
ハード差分の吸収 準仮想化 (ParaVirtualization)を使用
vs 完全仮想化 (FullVirtualization) リソース消費の制御
過負荷のアラート 負荷の調整
monit*1 との組み合わせ
*1: リソース監視ツール http://mmonit.com/monit/
仮想化サーバの構築ポリシー ハードウェアリソースの利用率の向上
空いているリソースを主に利用する DomU を投入
CPU が空いている → ウェブサーバ IO が空いている → DB サーバ メモリが空いている → キャッシュサーバ
同居を避ける組み合わせ 同じ傾向、かつ、負荷の高い用途同士
別サーバのウェブサーバ同士など .. 中央ストレージは使用しない
ハードウェア
仮想化サーバ ウェブサーバ
ウェブサーバ
メモリ量 : 4GBDom0: 0.5GBウェブサーバ 3.5GB
ハードウェア
ウェブサーバ
メモリ量 : 8GBDom0: 0.5GBウェブサーバ 5.5GBキャッシュサーバ 2GB
キャッシュサーバ主に CPU-bound
主にメモリを消費
CPU は消費しない
仮想化サーバ データベースサーバ
ハードウェア
DB サーバ
メモリ量 : 4GBDom0: 0.5GBDB サーバ 3.5GB
ハードウェア
DB サーバ
メモリ量 : 8GBDom0: 0.5GBDB サーバ 3.5GBウェブサーバ 4GB
ウェブサーバ主に IO-bound
主に CPU-bound
サーバ管理ツールあるラックに含まれるサーバの構成を負荷とともに一
覧
サーバ管理ツール 仮想化対応
サーバの親子関係と、子サーバの負荷を一覧
仮想化によって得られるもの 物理的なリソース制約からの解放
リソースの動的な変更 VM のマイグレーション・複製
ソフトレベルの強力なホスト制御 異常動作時の局所化 ホストの制御が容易となる
容易なサーバ増設 → スケーラビリティ
ハードコスト・運用コスト低下 → コストパフォーマンス・高可用性
カスタムエンジン RDBMS ではパフォーマンス的に厳しい用途
類似記事検索 カテゴリ判定 転置インデックスによる検索
ある程度の規模のデータ コンパクトなデータ形式 3000 万エントリ x 100 words → 3.5GB
独自のアルゴリズムで高速処理
計算クラスタ MapReduce
出典 : MapReduce: Simplified Data Processing on Large Clusters, Jeffrey Dean and Sanjay Ghemawat
Hadoop
Apache project による MapReduce の実装 MapReduce HDFS (Hadoop Distributed File System) Java
Facebook, Yahoo! Inc. (& はてな ) で採用
グローバル展開
グローバル配信 太平洋を越えるのは相当なオーバーヘッド
6MB のメディアファイル
太平洋越え → 30秒程度 CDN → 5秒程度
グローバル配信 CDN を使用
Amazon Cloudfront
Amazon Cloudfront
オリジナルのデータは日本の DC 参照頻度の高いファイルを Amazon S3 に
アップロード Amazon Cloudfront で配信
まとめ ウェブサービスのパフォーマンス
バックエンドとフロントエンド 両方の改善が必須
システムのスケーラビリティ ウェブサービスの特性 負荷と効率と安定性 ハードウェア
良パフォーマンス・高スケーラビリティ・安定
Top Related