第1回　CGMサイト構築で悩む負荷対策と拡張性の確保

　最近、Ruby on Rails（RoR）で構築されているCGM（Consumer Generated Media）サイトやコミュニティサイトが確実に増えてきている。例を挙げるまでもないが、Twitter、食べログ、iknowなどだ。

　RoRの採用の理由として、

• 実験的なプロジェクトとして。最近評判のRoRを次期言語・フレームワークとして評価するため
• 人材採用のためのコマーシャル
• 開発リーダーやマネージャが純粋にRuby好き

など、会社レベルから個人レベルまでさまざまな採用理由が存在する。

　われわれの会社（Cuon）でも、「ライフパレット」という、患者さん・患者家族のためのコミュニティサイトのα版を2008年3月10日にリリースした。開発に着手したのは2007年12月で、3カ月間で本格的にRoRを使いシステムを構築した。

　ライフパレットの機能には、病気体験記（本のように闘病記を作り、閲覧できる機能）、ブログ、Q＆A、タグなどがあり、CGMサイトとしてユーザーの投稿を促進するものを中心にサイトが設計されている。そして現在も鋭意開発・運営中である。

　本連載では、RoRで実際にCGMサイトを企画・構築・運営した経験を基に、アプリケーションアーキテクチャや、インフラアーキテクチャについて紹介したいと思う。

CGMサイト構築の初期段階で考えること

　CGMサイトを構築する初期段階では、サイトが成長することを考慮して「将来、高負荷に耐えられるアプリケーション、インフラ設計をする必要があるが、サイトの成長に合わせて成長させることで、ビジネス上のリスク（費用）を最小限に抑えたい。そのために、初期は最小構成で」という設計をする必要がある。

　そもそも、「RoRのインフラは最小構成（サーバ1台）の小規模サイト向きなのでは」という声もあるかと思う。しかし、冒頭で挙げた事例のように、成功しているCGMサイトになると、1000万PV（Page Views）/月というトラフィックを支える必要がある。

　将来、このような中〜大規模サイトになることを想定している場合、初期段階から「負荷対策」を反映した設計をする必要がある。

　しかし、ユーザーが少ない段階からインフラに投資できるほど、予算的に余裕のあるプロジェクトであればうらやましいが、通常はなるべく最小構成でスタートして、徐々にサーバを増やしていけるようにという考えが働く。そこで「拡張性」が必要となる。

　特に、CGMサイトという特性上、ユーザー投稿データが多くなり、データ量に比例してサーバやデータセンターの利用代金が掛かり、インフラの維持費が増えてくる。そこで、なるべく初期段階から良いアーキテクチャ設計をして、その維持費を最小にするような負荷対策と拡張性の確保を考えたい。

　最近では一般的になってきたが、CGMサイト構築における負荷対策と拡張性の実例を紹介しよう。RoRにかかわる部分は次回よりソースコードとともに紹介する予定なので、今回はポイントのみのサマリーとする。

アプリケーションレイヤにおける対策

1. HTTPロードバランサによるロードバランス

　まず、インターネットからのアクセスをHTTPロードバランサに集約する。HTTPロードバランサ内でApacheモジュール「mod_proxy_balancer」を稼働させ、複数台のWebアプリケーションサーバに処理を振り分けることにより、自動的に負荷分散を実現することができる。

　また、Webアプリケーションサーバ（アプリケーションレイヤ）にユーザーデータを保有しない限り、Webアプリケーションサーバのスケールアウトが可能であり拡張性が確保できる。

　さらに、特定のWebアプリケーションサーバに障害が発生した場合、mod_proxy_balancerがそれを自動的に検知し、処理を障害が発生していないWebアプリケーションサーバに振り分ける。これにより冗長性が実現する。

図1　HTTPロードバランサーによる負荷分散と冗長化

2. 大容量データの扱い

　ユーザーが投稿する画像や動画などの大容量データの取り扱いが、CGMサイト構築上の大きな悩みである。「高額なストレージを使って一発解決！」というのもいいが、通常は、予算も限られており、なるべく価格が安いサーバでスケールアウトが一般的だろう。それ故、初めからスケールアウトができる設計にしておかないと、後で大変なことになってしまう。

　各サイトでさまざまな方法が試されているが、本連載ではUNIXコマンドのrsyncを利用して大容量データ保存用サーバに転送する例を紹介する。

　ユーザー投稿データ（ライフパレットでは現在、画像のみを扱っているが、将来的には動画にも対応する予定だ）のような大容量データを、各WebアプリケーションサーバにあるRoRからUNIXのファイル転送プログラムのrsyncを利用して大容量データ保存用のContentsサーバにデータ転送して保存させる。

　転送した先のコンテンツサーバのパスをDBサーバに保存し、RailsでHTML作成時にそのパスをHTML内に埋め込んで、配信ブラウザからのそのパスへのアクセス時に、ロードバランサにより自動的にコンテンツサーバへ振り分けられる。

　rsyncとは、UNIXのファイル転送プログラムで、遠隔にあるファイルとの同期を最速で実現する方法である。初めから両方のファイルがリンクの最後まで一致することを必要とせず、リンクを横断してファイルの相違部分だけを転送する。転送にrsh、sshまたはダイレクト・ソケットを使うことができる。なお、ライフパレットではFTPを利用せず、よりセキュアなssh通信を利用することができる点でもrsyncを採用した。

　ほかの手段としてNFSによるファイル共有が考えられる。NFSのメリットは、別サーバにあるHDDをRoRが動作しているアプリケーションサーバのHDDのように扱えるため利用が容易であることだ。

　しかし、Webアプリケーションサーバの台数×Contentsサーバの台数分のマウントが必要になるため、単純なスケールアウトが難しくなってしまう。このデメリットも考慮してrsync方式を採用した。

1/3

Index
CGMサイト構築で悩む負荷対策と拡張性の確保
	Page1 CGMサイト構築の初期段階で考えること アプリケーションレイヤにおける対策 　1. HTTPロードバランサによるロードバランス 　2. 大容量データの扱い
	Page2 アプリケーションレイヤにおける対策（続き） 　3. キャッシュを効果的に利用する 　4. スループットの向上策
	Page3 データベースレイヤにおける対策 　1. DBロードバランサによるデータベースのロードバランス 　2. mysql_clusterによる拡張性・冗長性の確保 クッキーとセッション管理

RoRでCGMサイト構築虎の巻

	プログラミングは人生だ まつもと ゆきひろのコーディング天国　ときにプログラミングはスポーツであり、ときにプログラミングは創造である。楽しいプログラミングは人生をより実りあるものにしてくれる
	生産性を向上させるRuby向け統合開発環境カタログ Ruby on Rails 2.0も強力サポート　生産性が高いと評判のプログラミング言語「Ruby」。統合開発環境を整えることで、さらに効率的なプログラミングが可能になる
	かんたんAjax開発をするためのRailsの基礎知識 Ruby on RailsのRJSでかんたんAjax開発（前編）　実はAjaxアプリケーション開発はあなたが思うよりも簡単です。まずはRuby on Railsの基礎知識から学びましょう
	Praggerとnetpbmで作る画像→AA変換ツール Rubyを使って何か面白いものを作ってみよう！　一般的な画像をアスキーアートに変換するツールを作ってみる。さらに出力にバリエーションを持たせてみよう
	コードリーディングを始めよう Railsコードリーディング〜scaffoldのその先へ〜（1）　優れたプログラマはコードを書くのと同じくらい、読みこなす。優れたコードを読むことで自身のスキルも上達するのだ
	more

　　Coding Edgeフォーラムフィード　 2.0／1.0／0.91