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 で配信

まとめ ウェブサービスのパフォーマンス

バックエンドとフロントエンド 両方の改善が必須

システムのスケーラビリティ ウェブサービスの特性 負荷と効率と安定性 ハードウェア

良パフォーマンス・高スケーラビリティ・安定

Q&Astanaka@hatena.ne.jp