Gregg PollackとScaling Railsのハウツー

作者 Robert Bazinet , 翻訳者 編集部 投稿日 2009年5月22日

セクション

デベロップメント

トピック

Ruby ,

Ruby on Rails

タグ

Ruby on Rails ,

インタビュー ,

スケーラビリティ

原文(投稿日：2009/3/11)へのリンク

Ruby on Rails(リンク)は、わずか数年前の登場以来、よくがんばっていますが、必ずしもスケーリングでないと批判されています。開発者は、どんな問題の解決にも正しい 方法と間違った方法が必ずあることを知っていますが、Ruby on Railsのスケーリングでも事情はまったく同じです。

Rails Envy Podcast(リンク)とenvycastsのGregg Pollack氏は、New Relicと協力したScaling Railsというふさわしい名前のポッドキャストで、Ruby on Railsについて取り上げています。Pollack氏は、フロリダ州オーランドに住み、自身の会社Rails Envyで教育用メディアを製作しています。彼は、Orlando Techコミュニティにおいて非常に精力的に活動しており、BarCampOrlandoやOrlando Ruby Users Group、またオーランド初の公式コワーキングスペースであるCoLabの組織化を支援しています。

InfoQは、新しいスクリーンキャストと、それらがどのように開発者のRuby on Railsスケーリングを支援するかについて、Pollack氏と話す機会がありました。

Robert Bazinet (RB) ：スケーリングをテーマに始められたenvycastsシリーズの紹介を見ましたが、今度はScaling Railsという新しいシリーズ。これは偶然の一致ですか？

Gregg Pollack (GP) ：私は、Scaling Railsについてenvycastsを作りたいと数か月前に考えました。しかし、そこに到達するため、基本から始めてRubyについて考えるべきだと気づいたのです。それで、最初に"Scaling Ruby" envycastを出しました。それから、シリーズの次のenvycastは"Scaling Rails"になるはずでしたが、運良くNew Relicがスポンサーになってくれたので、それを無料で発表することができました。

RB：Scaling Railsシリーズを出そうと最終的に決定した理由は何ですか？

GP：理由はいくつかあります。

• 1つには、Railsアプリケーションをうまくスケーリングするために必要なすべての情報をRails開発者に与えること。 開発者は、これらの技術を使用する必要はないかもしれません。しかし、できれば、開発者がビデオを見て、何百万人の同時ユーザーを扱うRailsアプリケーションを作成できます、とクライアントに言える自信を持ってもらいたいのです。
• 2番目に、Railsアプリケーションをスケーリングすることがどれほど簡単かを、他の言語の開発者に示すこと。
• そして、できれば、いくつかの企業がいまだに持っている「Railsはスケーリングができない」という認識を改めること。今では、この状況にあるRails開発者は、Scaling Railsスクリーンキャストを指して、「Railsはスケーリングできますよ。こうするんです」と言うことができます。

RB：envycastsのアイデアや後のScaling Railsの件は、どうして出てきたのですか？

GP：私が非常に情熱を傾けていることの2つは、映画製作とウェブ開発です。envycastsは、私にこれらの2つの情熱を組み合わせて、ことによると子供を養うのに十分な利益を出す方法を与えてくれました。正直に言って、これらのビデオで大もうけはしていません。しっかりと請負仕事をしている方が、金にはなります。でも、言ったように、これが好きなんです。

envycastsの目的は、楽しい教育用ビデオを提供することです。

RB：New Relicは、Railsのスケーリングに興味を持っているようですね。あなたのシリーズは、彼らのRails Labの一部になっています。この関係について詳しく教えていただけますか？また、これらのスクリーンキャストについてもお願いします。

GP：New Relicは、Railsコミュニティの拡大を支援して、企業のRailsフレームワークの採用を促進しようと考えているのです。それは正しいやり方です。彼らは、顧客を増やそうとしているのですが、私たちのような小さなコミュニティと連携する方法の1つは、コミュニティ自体に投資することです。過去に、Engine Yardが、RubiniusプロジェクトやMerbプロジェクトに投資して、同じことをしています。

New Relicは、Rails Performanceのトピックに関するコンテンツを製作するために、Rails Labウェブサイトを立ち上げました。私のビデオのスポンサーになってくれたので、Rails Labで無料でそれらを公開できたのです。

RB：企業によるRails採用の未来は、どのようなものになりますか？これらのスクリーンキャストは、Railsがそこに至るのを支援できますか？

GP：大企業内部で、プロジェクトでRailsを使用するように経営者側を説得する若い開発者が、徐々に増えています。普通は、内部アプリケーションから始まり、ゆっくりと稼働環境へと進行します。来年にかけて、より多くの大企業が、稼働環境へ自身のRailsアプリケーションをリリースするのは確実だと考えています。

今は、特に経済性のためにも、Railsを使い始めるチャンスです。Railsを使えば、より少ないコードでより多くの成果を上げることができます。また、(少なくとも私の経験では)保守費は、他の言語やフレームワークよりはるかに少なくて済みます。このことに他の企業より早く気づいた大企業は、競争的優位を維持するのが比較的簡単になります。

そのあたりの開発者が、次のプロジェクトでRailsを使うようボスを説得するのに、これらのビデオを使ってもらいたいと思います。あくまでも希望ですが。

RB：Railsのスケーリングに関して、これからのRailsスクリーンキャストには、どのようなものが出てくるのですか？

GP：今の時点では正直言ってよくわかりません。今のところ、13のエピソードが出ています。

• エピソード#1 - ページの応答性
• エピソード#2 - ページのキャッシング
• エピソード#3 - キャッシュの有効期限
• エピソード#4 - New Relic RPM
• エピソード#5 - 高度なページのキャッシング
• エピソード#6 - アクションのキャッシング
• エピソード#7 - フラグメントのキャッシング
• エピソード#8 - memcached
• エピソード#9 - Taylor Weibleyとデータベース
• エピソード#10 - クライアントサイドのキャッシング
• エピソード#11 - 高度なHTTPキャッシング
• エピソード#12 - Jesse Newlandと配備
• エピソード#13 - Jim Gocheeと高度なRPM

RB：Railsがスケーリングできないという印象を持つ人がいるのは、なぜですか？

GP：スケーラビリティに関する悪評の大多数は、数年前のTwitterとTech Crunchが出所だと思います。Twitterは、おそらくご存じのように、毎秒何百万のリクエストを処理できる、メッセージングプラットフォームです。Railsは、twitterのようなメッセージングプラットフォームのフロントエンドに使えるかもしれませんが、バックエンドインフラストラクチャーは、スケーリングできる必要があるので、ほとんどのウェブフレームワークをそのまま扱うことができません。 twitterにはスケーリングの問題があったので、多くの人間が、これをRuby on Railsアプリケーション一般にスケーリングの問題があると解釈してしまったのです。明らかにそうではないのですが。

RB：企業でRailsアプリケーションの作成を始める開発者が、スケーラブルなRailsアプリケーションを作成するのに、どのようなアドバイスがありますか？

GP：私のScaling Railsスクリーンキャストをすべて見てください！これは自己宣伝です。

冗談はさておき、Railsに付属する多くのキャッシングメカニズムの利用方法を学習してください。稼働環境のアプリケーションをモニターできるように、New RelicのRPMのようなサーバーモニタリングツールをインストールしてください。この情報を利用して、アプリケーションが遅いところ、最適化すべきところを見つけます。

最近、memcachedに飛びつく企業があります。本当に時間をかけてデータベースクエリを最適化する前に、memcachedを使ってデータベースオブジェクトを格納し始めてはいけません。

最後に、プロジェクトの一番最初に、「アプリケーションを最適化する」ための時間を、稼働を始める前に作業計画で確保しておきます。その時間を誰かに奪われないようにしてください。

RB：あなたが作ったスクリーンキャスト以外に、開発者がスケーラブルなアプリケーションを作成するのに役立つリソースを推薦していただけますか？

GP：私の推薦は次の通りです。

• Cal Hendersonの「スケーラブルなウェブサイトの構築」に関する本を読む
• YSlowを使ってオールAを取る方法を学習する。
• Ruby開発者なら、"Ilya Grigorik's blog"(リンク)を読む。
• Rails開発者なら、"Caching with Rails guide"(リンク)を読む。

RB：企業の開発者には、RubyとRuby on Railsを使用する、どのような利点がありますか？

GP：そうですね…これは、私たちの話の範囲外なのですが、企業でRailsを使用する最大の利点は、プロジェクトの保守段階にあります。

• Railsアプリケーションを構築するのに一般的な方法が1つあります。 チームにメンバーを追加することができ、そのメンバーに予備知識を与える必要がないのです。 また、より安心感があります。Railsアプリケーションを構築してもらっている企業に何かあっても、簡単に引き揚げて、別の企業へ移すことができます。
• Rubyを使えば開発者は生産性を上げることが可能なので、より少ないコードを書いて、より多くのことができます。 つまり、バグが少なくなり、保守がはるかに簡単になります。 また、変更に必要な作業が少ないので、アジャイルであり続けることが簡単になります。
• Rubyのコードは非常に表現力があり、コードを読むのが簡単です。 別の人間のコードを理解するのにかかる時間が減るので、保守段階でコストを節約できます。

RB：本日はお忙しい中、お時間を頂き、ありがとうございました。

Gregg Pollack氏は、Rails Envyポッドキャストの共同ホストでありRails Activist Team(リンク)のメンバーです。Scaling Railsウェブサイト(リンク)でScaling Railsシリーズの13のエピソードをすべて見つけて、スクリーンキャストとコードのサンプルをダウンロードしてください。

• 次へ >