高トラフィックサイトをRailsで構築するためのTips基礎編

22,333 views
22,021 views

Published on

アクセス数の多いサイトをRailsで運用する場合にやっておきたい設定

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

No Downloads
Views
Total views
22,333
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
82
Comments
0
Likes
56
Embeds 0
No embeds

No notes for slide

高トラフィックサイトをRailsで構築するためのTips基礎編

  1. 1. 高トラフィックサイトを Ruby on Rails で構築するための Tips 基礎編 沼田 一哉 株式会社エストコスモ プラットフォームワークショップ
  2. 2. いや、まずいかも、、、 タイトルが 「札幌Ruby会議」的ではない
  3. 3. そもそも、 他の講演者の面々が ヤバすぎる... (特に稲作農家)
  4. 4. というわけで、タイトル変更 ちょっとアクセスの多いサイト と Rails と 私 沼田 一哉 株式会社エストコスモ セキュリティワークショップ
  5. 5. 私について <ul><li>名前 : 「ぬ」 ( 沼田 一哉 (33)) ( Kazuya NUMATA ) Twitter @kaznum
  6. 6. 生まれ : 北海道北見市
  7. 7. 職業 : きっとプログラマ LOCAL 正会員
  8. 8. 北海道の某大学卒、修士中退
  9. 9. 2001 年 札幌の ( 株 ) エストコスモに入社
  10. 10. 4 年半札幌で勤務した後、 2005 年米国ロサンゼルス近郊に駐在 ( 約 4 年間 )
  11. 11. 2009 年 8 月に札幌復帰 現在に至る
  12. 12. Ruby </li><ul><li>出会いは 2000 年の春ごろ
  13. 13. 仕事での本格利用は 2005 年 9 月から (Rails 0.13 のころ ) </li></ul></ul>
  14. 14. L.A.について <ul><li>残念ながら、シリコンバレーではない
  15. 15. 映像系、アート系、マスメディア系の仕事が多いが、いろいろなビジネスがある
  16. 16. 時刻がアヤシイ
  17. 17. ハリウッド、ラスベガスには車で行ける距離 (シリコンバレー、SFOも)
  18. 18. L.A.にも当然、Ruby(LA-Ruby)のコミュニティがあります(今年は比較的活発な活動) </li></ul>
  19. 20. 米国での私 <ul><li>Rails や PHP での請負開発をメインにした </li><ul><li>コンサル
  20. 21. 開発
  21. 22. サーバ導入
  22. 23. 保守、管理 </li></ul></ul>
  23. 24. これくらいの規模のサイトを構築していました。 <ul><li>毎秒平均ページビュー10 req/s
  24. 25. 最大ページビュー70 req/s
  25. 26. 頻繁に参照、記録が行なわれるテーブルのレコード数 500,000 </li></ul>
  26. 27. ※ <ul><li>これからのおはなしに登場するWebサーバはApacheを前提にしています。
  27. 28. nginx、lighttpd等については、詳しい人、お願いします。
  28. 29. それでは怒涛の勢いで紹介します </li></ul>
  29. 30. Cache
  30. 31. check: Cacheを積極的に利用 <ul><li>cacheに尽きる
  31. 32. 認証等が無く、リアルタイム性が無いコンテンツであれば、 page cache </li><ul><li>リンクのURLに.:format (.html)を忘れずに </li></ul><li>Action cache, fragment cache、....
  32. 33. fragment_cache等のstoreにはmemcached </li></ul>
  33. 34. check: Web サーバのキャッシュ機能を活用する <ul><li>Rails までアクセスさせない
  34. 35. Apache の mod_disk_cache を有効活用 </li><ul><li>htcacheclean を忘れずに
  35. 36. mod_mem_cache は Expire 後の挙動が不思議なので保留 ( 今は ?)
  36. 37. ベーシック認証をしている場合はキャッシュが効かない </li></ul></ul>
  37. 38. check: ブラウザのキャッシュも使う <ul><li>更新の少ないコンテンツは、リクエストすら送らせない。 </li><ul><li>Cache-Controlヘッダ
  38. 39. Expireヘッダ
  39. 40. Apacheなら、mod_expiresで可能 </li></ul></ul>
  40. 41. Check: Load Balancing <ul><li>「サーバを追加するだけでスケーリングできるように」 </li><ul><li>リバースプロキシ型の導入 </li><ul><li>キャッシュ機能も有効利用 (Pound はキャッシュ機能がない )
  41. 42. 私は apache + mod_proxy_balancer を使っています。 </li></ul></ul><li>Stateful なアプリケーションの問題 </li><ul><li>ユーザ情報、ファイル入出力がある場合は、データの共有が必要 </li><ul><li>しかも高パフォーマンスなものが必要 </li></ul><li>RESTful を意識しよう </li></ul></ul>
  42. 43. DB / Storage
  43. 44. check: まずDBでできること <ul><li>View を使いましょう (>= MySQL5)
  44. 45. インデックス (上記の2点をやったら、30秒 -> 1秒)
  45. 46. find_by_XXXではなく、find_by_sql(“select * ...”) </li><ul><li>method_missing is the last resort. </li></ul></ul>
  46. 47. check: DBのスケール <ul><li>難しいですよね
  47. 48. MySQL クラスタ </li><ul><li>マルチマスターで同期レプリケーションが可能。
  48. 49. ノード台数が少ないとパフォーマンスがかえって悪い </li></ul><li>プロキシ型 </li><ul><li>MySQL Proxy
  49. 50. pgpool-II </li><ul><li>結構有用かも ( 石田さんに聞いてください ) </li></ul></ul><li>MySQL のレプリケーション </li><ul><li>非同期レプリケーション </li><ul><li>Acts-as-Readonlyable 等により、上手に運用すれば有用 </li></ul></ul></ul>
  50. 51. check: Storage の I/O <ul><li>Web サーバの Load Average は CPU 使用率だけでは決まらない -> Disk の I/O パフォーマンスの影響を受けていることが多い
  51. 52. NFS を使っている場合は DRBD + Heartbeat + NFS
  52. 53. SAS + RAID10
  53. 54. FC + Disk アレイ </li></ul>
  54. 55. Railsの機能
  55. 56. check: セッション <ul><li>active_record_storeは使わない </li><ul><li>とにかく遅い </li></ul><li>やっぱりmemcached
  56. 57. セッションには最低限必要な値のみ入れる </li><ul><li>Rails 2.3あたりからSessionのサイズが膨大になる傾向 ->sessionの値を取得するだけでも膨大な時間がかかる(ログインユーザのオブジェクトではなく、user_id) </li></ul></ul>
  57. 58. Check: Helper <ul><li>linkが大量にあるページでlink_toを多用するとパフォーマンスに影響がでます。
  58. 59. やりすぎ厳禁 </li></ul>
  59. 60. Webサーバ (Apache)
  60. 61. check: DoS攻撃への対応 <ul><li>腹立たしいが対策は必要
  61. 62. mod_evasive </li><ul><li>一定時間内に同一IPアドレスから同一URLに対しアクセス可能な回数の閾値を指定し、それを越えると503 Service Temporary Unavailableヘッダを返す </li><ul><li>ここまではapache側で処理されるため、Railsにはアクセスが来ない </li></ul></ul></ul>
  62. 63. check: PassengerのPoolサイズ <ul><li>高負荷をかけた状態で、 </li><ul><li>passenger-status コマンド
  63. 64. ps コマンド </li></ul><li>などを駆使し、インスタンスの利用具合を確認
  64. 65. とりあえず PassengerMaxPoolSize を変更
  65. 66. RAM の空き具合、 CPU の使用率などとご相談 </li></ul>
  66. 67. check: サブドメインを活用 <ul><li>コンテンツの種類ごとにサブドメインを分割 </li><ul><li>img.example.com -> 画像ファイル
  67. 68. w ww.example.com -> メインのページ表示
  68. 69. static.example.com -> CSS ファイルなど
  69. 70. .... </li></ul><li>ブラウザの制限で 1 つのドメイン名に対する同時コネクション数が制限されている -> わざと複数のサブドメインをつけることで、同時にコンテンツを取得できるようにする。 </li></ul>
  70. 71. 最後に <ul><li>80:20 の法則 </li><ul><li>まずはパフォーマンステストをしてからチューニングしましょう (httperf など ) </li></ul><li>Test::Unit 、 RSpec 、 TDD 、 BDD </li><ul><li>パフォーマンスを上げるために、コードの変更が必要になることがあります。 </li></ul><li>monit で監視 </li><ul><li>眠れるように、障害時に WEB サーバの自動再起動 </li></ul></ul>
  71. 72. おすすめの情報 <ul><li>High Performance Web Sites (Souders /O'Reilly)
  72. 73. Advanced Rails (Brad Ediger / O'Reilly)
  73. 74. あとは Google it! </li></ul>
  74. 75. おしまい

×