![Q & A [email_address]](https://image.slidesharecdn.com/091106kofpublic-091108170852-phpapp02/85/Performance-and-Scalability-of-Web-Service-69-320.jpg)
![[AWSマイスターシリーズ] AWS Elastic Beanstalk](https://cdn.slidesharecdn.com/ss_thumbnails/20131009aws-meister-regenerate-elasticbeanstalk-public-131014212455-phpapp02-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (7)
Similar to Performance and Scalability of Web Service (20)
![[db tech showcase Tokyo 2015] D32:HPの全方位インメモリDB化に向けた取り組みとSAP HANAインメモリDB の効果を...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015d32in-memorysap-hanahp-150619092635-lva1-app6891-thumbnail.jpg?width=560&fit=bounds)
More from Shinji Tanaka (7)
Recently uploaded (6)
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. フロントエンドのパフォーマンス 含まれるページ要素の数 CSS Sprite により削減 画像リクエストを圧縮 レンダリング速度 広告の遅延ロード 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 proxy LVS 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/B Intel 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 性能の分散
- 45. 単体性能の向上例 SSD: Solid State Drive アクセス性能 良好なランダムアクセス性能 メモリ > SSD > HDD RAID-0/10 > HDD RAID-1 メモリほどではないが、十分に高速 Intel SSD X-25E/M 本番環境で稼働中
- 46. オンメモリ vs SSD 32G 16G + SSD IOwait は ほとんど発生せず 32GB … ほぼオンメモリ SSD … 大量の ioread SQL 処理性能は ほぼ同一
- 47. SSD のリスク まだリスクも .. 障害パターンが不明 昨年の秋口に購入した安価 SSD は半年で故障 Intel SSD は未故障 いつでも再構成可能な箇所で使用
- 48. その他の要素技術 ネットワーク 仮想化技术 カスタムエンジン 計算クラスタ グローバル対応
- 49. ネットワークの冗长化
- 50. ルータ用ハードウェア ちょっといい M/B ASUS/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
- 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]