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

>> 0 >> 1 >> 2 >> 3 >> 4 >>

高トラフィックサイトをRuby on Railsで構築するための

Tips基礎編

沼田 一哉株式会社エストコスモ

プラットフォームワークショップ

>> 0 >> 1 >> 2 >> 3 >> 4 >>

いや、まずいかも、、、

タイトルが「札幌 Ruby会議」的ではない

>> 0 >> 1 >> 2 >> 3 >> 4 >>

そもそも、

他の講演者の面々が

ヤバすぎる ...

(特に稲作農家 )

>> 0 >> 1 >> 2 >> 3 >> 4 >>

というわけで、タイトル変更ちょっとアクセスの多いサイト

と

Railsと

私 沼田 一哉

株式会社エストコスモセキュリティワークショップ

>> 0 >> 1 >> 2 >> 3 >> 4 >>

私について名前 : 「ぬ」 ( 沼田 一哉 (33)) ( Kazuya NUMATA )Twitter @kaznum

生まれ : 北海道北見市

職業 : きっとプログラマ LOCAL正会員

北海道の某大学卒、修士中退

2001 年 札幌の (株 )エストコスモに入社

4年半札幌で勤務した後、 2005年米国ロサンゼルス近郊に駐在 (約 4年間 )

2009年 8 月に札幌復帰 現在に至る

Ruby

出会いは 2000年の春ごろ

仕事での本格利用は 2005年 9月から (Rails 0.13のころ )

>> 0 >> 1 >> 2 >> 3 >> 4 >>

L.A.について

残念ながら、シリコンバレーではない

映像系、アート系、マスメディア系の仕事が多いが、いろいろなビジネスがある

時刻がアヤシイ

ハリウッド、ラスベガスには車で行ける距離(シリコンバレー、 SFOも )

L.A.にも当然、 Ruby(LA-Ruby)のコミュニティがあります (今年は比較的活発な活動 )

>> 0 >> 1 >> 2 >> 3 >> 4 >>

>> 0 >> 1 >> 2 >> 3 >> 4 >>

米国での私

Railsや PHPでの請負開発をメインにした

コンサル

開発

サーバ導入

保守、管理

>> 0 >> 1 >> 2 >> 3 >> 4 >>

これくらいの規模のサイトを構築していました。

毎秒平均ページビュー 10 req/s

最大ページビュー 70 req/s

頻繁に参照、記録が行なわれるテーブルのレコー ド数 500,000

>> 0 >> 1 >> 2 >> 3 >> 4 >>

※これからのおはなしに登場する Webサーバは Ap

acheを前提にしています。

nginx、 lighttpd等については、詳しい人、お願いします。

それでは怒涛の勢いで紹介します

>> 0 >> 1 >> 2 >> 3 >> 4 >>

Cache

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: Cacheを積極的に利用

cacheに尽きる

認証等が無く、リアルタイム性が無いコンテンツであれば、 page cache

リンクの URLに .:format (.html)を忘れずに

Action cache, fragment cache、 ....

fragment_cache等の storeには memcached

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: Webサーバのキャッシュ機能を活用する

Railsまでアクセスさせない

Apacheの mod_disk_cacheを有効活用

htcachecleanを忘れずに

mod_mem_cacheは Expire後の挙動が不思議なので保留(今は ?)

ベーシック認証をしている場合はキャッシュが効かない

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: ブラウザのキャッシュも使う

更新の少ないコンテンツは、リクエストすら送らせない。Cache-Controlヘッダ

Expireヘッダ

Apacheなら、 mod_expiresで可能

>> 0 >> 1 >> 2 >> 3 >> 4 >>

Check: Load Balancing「サーバを追加するだけでスケーリングできるように」

リバースプロキシ型の導入

キャッシュ機能も有効利用(Poundはキャッシュ機能がない )

私は apache + mod_proxy_balancerを使っています。

Statefulなアプリケーションの問題

ユーザ情報、ファイル入出力がある場合は、データの共有が必要

しかも高パフォーマンスなものが必要

RESTfulを意識しよう

>> 0 >> 1 >> 2 >> 3 >> 4 >>

DB / Storage

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: まず DBでできること

View を使いましょう (>= MySQL5)

インデックス(上記の 2点をやったら、 30 → 秒 1秒 )

find_by_XXXではなく、 find_by_sql(“select * ...”)

method_missing is the last resort.

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: DBのスケール難しいですよね

MySQLクラスタ

マルチマスターで同期レプリケーションが可能。

ノード台数が少ないとパフォーマンスがかえって悪い

プロキシ型

MySQL Proxy

pgpool-II

結構有用かも (石田さんに聞いてください )

MySQLのレプリケーション

非同期レプリケーション

Acts-as-Readonlyable等により、上手に運用すれば有用

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: Storageの I/O

Webサーバの Load Averageは CPU使用率だけでは決まらない→ Diskの I/Oパフォーマンスの影響を受けていることが多い

NFSを使っている場合は DRBD + Heartbeat + NFS

SAS + RAID10

FC + Diskアレイ

>> 0 >> 1 >> 2 >> 3 >> 4 >>

Railsの機能

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: セッション

active_record_storeは使わないとにかく遅い

やっぱり memcached

セッションには最低限必要な値のみ入れるRails 2.3あたりから Sessionのサイズが膨大になる傾

向→ sessionの値を取得するだけでも膨大な時間がかかる (ログインユーザのオブジェクトではなく、 user_id)

>> 0 >> 1 >> 2 >> 3 >> 4 >>

Check: Helper

linkが大量にあるページで link_toを多用するとパフォーマンスに影響がでます。

やりすぎ厳禁

>> 0 >> 1 >> 2 >> 3 >> 4 >>

Webサーバ(Apache)

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: DoS攻撃への対応

腹立たしいが対策は必要mod_evasive一定時間内に同一 IPアドレスから同一 URLに対しアクセス可能な回数の閾値を指定し、それを越えると503 Service Temporary Unavailableヘッダを返すここまでは apache側で処理されるため、 Railsにはアクセスが来ない

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: Passengerの Poolサイズ高負荷をかけた状態で、

passenger-status コマンド

psコマンド

などを駆使し、インスタンスの利用具合を確認

とりあえず PassengerMaxPoolSizeを変更

RAMの空き具合、 CPUの使用率などとご相談

>> 0 >> 1 >> 2 >> 3 >> 4 >>

check: サブドメインを活用コンテンツの種類ごとにサブドメインを分割

img.example.com -> 画像ファイル

www.example.com -> メインのページ表示

static.example.com -> CSSファイルなど....

ブラウザの制限で 1つのドメイン名に対する同時コネクション数が制限されている→ わざと複数のサブドメインをつけることで、同時にコンテンツを取得できるようにする。

>> 0 >> 1 >> 2 >> 3 >> 4 >>

最後に80:20の法則

まずはパフォーマンステストをしてからチューニングしましょう (httperfなど )

Test::Unit 、 RSpec、 TDD、 BDD

パフォーマンスを上げるために、コードの変更が必要になることがあります。

monitで監視

眠れるように、障害時に WEBサーバの自動再起動

>> 0 >> 1 >> 2 >> 3 >> 4 >>

おすすめの情報High Performance Web Sites

(Souders /O'Reilly)

Advanced Rails(Brad Ediger / O'Reilly)

あとは Google it!

>> 0 >> 1 >> 2 >> 3 >> 4 >>

おしまい