Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Performance and Scalability of Web Service

4,588 views

Published on

Published in: Technology

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>

×