Performance and Scalability of Web Service

4,405 views
4,315 views

Published on

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

No Downloads
Views
Total views
4,405
On SlideShare
0
From Embeds
0
Number of Embeds
1,115
Actions
Shares
0
Downloads
72
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Performance and Scalability of Web Service

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

×