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