BT

Ruby on Railsのケーススタディ: ChangingThePresent.org

| 作者 Bruce Tate フォローする 0 人のフォロワー , 翻訳者 長部 広太 フォローする 0 人のフォロワー 投稿日 2008年8月11日. 推定読書時間: 20 分 |

ほんの5ヶ月前、私は忙しい男でした。半年間でRubyの本を二冊出した直後で、扱いきれない量の仕事であふれていました。このような状況のときに、私はArvato Systemsから連絡をもらいました。そしてArvato Systemsは、私に以下の環境を提供すると話してくれました。

  • 非常に目立ちそして重要なプロジェクトを導く事が出来ます。
  • 自分の好きなテクノロジーを使う事が出来ます。
  • 少なくとも、ある程度は自分が選んだ人と一緒に働くことが出来ます。

そして、彼らは、私が現実的な方法で世界を変えるだろうとも言ってくれました。以前私は誇大宣伝に騙された経験がありますが、今回の口説き文句に偽りはありませんでした。あらゆる点で正しかったです。本稿では、 この非凡なアイデアの背後にある技術的な詳細について話したいと思いますが、まず最初に私は読者であるあなたに、これから話すサイトの構想を知ってもらいたいと思っています。ChangingThePresent.org(リンク)には、単純ではあるが、説得力のある根拠があります。サイトが目指しているのは、我々が毎年贈り物に費やす費用のうち、2500億ドルを獲得することです。フルーツケーキをもう一つ贈ったり、毛の付いたスリッパをもう一組贈る代わりに、ChangingThePresentを通して、はるかに多くの影響力と意味のある贈り物を贈る事が出来ます。例えば、ガン研究者に一時間を与えたり、熱帯雨林の保護を行うなどです。献金のポータルサイトをもう一つ構築することによって、余分なお金を与えたり、生み出したりすることが一層便利になりますが、人々が物を与えるということについての考え方を変える機会を得て私は興奮しました。

昔からの問題


あなたの祖母が賞賛しないテクノロジーで一杯の非営利組織の世界を、もしあなたが知っているとすれば、これから話そうとしている構想がどこへ向うか既に分かることでしょう。ChangingThePresent(リンク)は、他の産業が人々を寄せ集めるのに使っているのと同じ技術即ちインターネットを利用しようとしています。今回に限ると、寄せ集めの対象となる人々は買い手と売り手ではなく、提供者と非営利団体です。Lance Armstrong基金、Save the Children、First Book、そしてSierra Clubなどが、約200のアドバイザーと380の非営利団体の見栄えがするリストの上位に並んでいて、事業開発が進行中です。しかし、ここでは、この物語の技術的な側面を話したいと思います。

本稿で、Ruby on Railsを使用してサイトを構築する方法を十分に伝えたいと思います。我々が使っている核となる機能や毎日使用している主要なプラグインも分かることでしょう。我々が使っている技術のほとんどは、そんなに驚くべきものではありませんが、我々の日々の活動を少しでも見て頂けたらと思います。私の狙いは、あなたに、開発チームがどのように行動しているか、またプロダクション環境で信頼して使っている技術、ツールを教え、そしてこれが、我々にとっては一番重要なことですが、Railsフレームワークに関して幅広い基礎知識を与えることです。各項目で詳細に立ち入ることはせずに、情報源へのリンクを貼りたいと思いますが、もしある部分に関して、もっと多くのことを知りたいと思ったら、コメントを残してください。この記事を読んで関心を持ってくれる人が沢山いたら、深く掘り下げるために別の記事を喜んで書きたいと思います。

基本

プロジェクト開始当初、私は独立した契約者且つリードプログラマーとしてチームに加わりました。発起人はスケーラビリティと安定性を望んでJavaを使う事を考慮しましたが、Javaを使うとプロジェクトがあまりに高額で複雑になってしまうので、最初の入札から計画はふりだしに戻ってしまいました。Ruby on Railsを使う事に決めたのは、Ruby on Railsは、高い生産性、クリーンなプログラミングモデルそしてリーズナブルなパフォーマンスという最高の組み合わせを与えてくれたからです。しかし、懸念なしで決まったわけではありませんでした。既存のポータルサイトと事業プランに基づき、毎日、数100万ヒットを処理出来なければならないと決めました。Ruby で構築したサイトの中には、そのような高いトラフィックを求められたサイトは、ほとんどありませんでしたが、アグレッシブなキャッシッグとシンプルなシェアードナッシングクラスタを使えば、そのようなスケーラビリティを提供出来ると思いました。確かにその当時我々の確信を支えてくれるサイトを見つけることは出来ませんでしたが。

9月がやって来て、そして過ぎ去ってしまいました。我々は非常に生産的で、毎週のデモで大きな進展を示しました。そして顧客は注目してくれて、私はサイトの構想に夢中だったので、11月にCTOとしてWellGood LLCに参加しました。12月に、サイトの最初のベータ版をリリースしました。我々のチームは、他の言語を使用した入札の5分の1の費用と、見積もり期間の6分の1でサイトの最初のバージョンを構築しました。Railsは、我々の生産性と成功に対してきわめて必要です。

最初のバージョンは、当初計画したものの5パーセントしか構築していなかったので、サイトの完成からはほど遠かったのですが、これから構築していく上での十分な土台となり事業計画の次のステップを開始することができました。我々は、いくつかのマイナーなベンチマーキングとプロファイリングを実施して、しかるべきときが来たら、大きな負荷を扱えることが出来るという確信を得たかったのですが、我々の現在のデプロイが、長期間推定した大量のリクエストを扱うことが出来ると確信するには至りませんでした。Railsで構築したサイトにそんな大量のリクエストを扱うサイトなどなかったからです。しかし、我々は以下のような高い確信を得るに至りました。:

  • 機能を構築し、十分にテストして、早く展開することが出来る。
  • 最小のハードウェアで高いボリュームに対してスケールする事が出来る。
  • ニーズに合わせて、透過的にハードウェアを追加することが出来る。
  • 我々のチームメンバー5人のスキルが向上して、サイトの開発と管理の両方が出来る。
  • 我々は、将来やってくるスケーラビリティとパフォーマンスの問題を解決出来る。

上記のリストの中で、我々にとって最も重要な事は、生産性です。私のチームは、十分生産的でなければならない。なぜなら顧客と投資家を安心させなくてはいけないからです。その一方で我々の競争相手より後れをとらないようにしています。残りの記事で、デプロイの詳細に関してもう少し細かく取り上げてみたいと思います。我々が使っているものに対して明確な説明を提供出来ない場合は、より多くの情報に辿り着けるようにリンクを張っておきます。

トポロジー

最初に、今一度基本原則の確認をしよう。Railsは、基本的にはLAMP(リンク)アーキテクチャを採用していて、我々はRailsをSunのハードウェア上にデプロイしています。またロードバランサーとしてBIG-IPを使っています。最近のRailsサイトの様に、Mongrel(リンク)をアプリケーションサーバに、静的コンテンツ用にlighttpd(リンク)、そしてMySQL(リンク)を選択しました。我々はデータベースを、フェイルオーバー、パフォーマンス及びスケーラビリティを求めて、マスター/マスター/スレーブ(リンク)構成で配置しました。

我々は、Text Driveを選択して、静的コンテンツのホスティングをしてもらいました。なぜならText DriveはRailsサイトのホスティング経験が豊富だからです。大部分のインターネットサイトのように、我々のサイトのトラフィックは、読み出し専用アクセスに偏っていますが、例外もあり、主な例外として、ソーシャルネットワーキングの個人化テンプレートと、そしてもちろんショッピングがあります。我々が望んでいるパフォーマンスの特質を得るために、プロファイリングをいくつか実施した結果、データベースへのリクエスト数を最小にするために、積極的な関連を持ったActiveRecordモデルのどこを最適化すれば良いかが分かりました。また同様にMemCacheに裏付けされたActs As Cacheableプラグインを使いキャッシング戦略を実装しています。キャッシング層を除き、我々のサイトの構成は、かなり標準的なRailsの構成です。

ところで寄付を行うときは、寄付を行う人の感情に訴えるものがなければいけません。通常感情に訴えるものとは、映りがよい写真が沢山あることを意味します。我々の非営利団体は、訪問者の興味を沢山起こさせる、映りが良い写真を選ぶという良い仕事をしています。写真があると具体的なテーマでの寄付の機会を強くします。従って寄付を行う人は、自身の寄付金がそれを最も必要としている人々のところへ直接届くということが分かります。しかし、イメージファイルのダウンロードは、典型的なRailsのセットアップにストレスを与えてしまう事があります。Mongrelは静的データをうまく対処しないので、我々はURL Rewritingを行い、特定のURLを静的なコンテンツの送信専用にしてイメージファイルの管理を行っています。またイメージアクセラレータとしてPanther Expressを使い始めてます。Panther Express(リンク)によって、世界中からキャッシュされたイメージファイルを供給することが出来ます。4月頃にそのサービスを始動させないといけないのです。

一部の人々、大部分はJavaや.NETの開発者そしてベンダーですが、Ruby on Railsでは、我々が必要としているスケーラビリティを得ることが出来ないと警告してきました。しかし私はあまり心配していません。IT業界に、Railsに類似した技術のノウハウが蓄積されたと確信しています。結局、Railsの基盤を形成するLAMP主義は、同様にWeb上で沢山の大規模サイトのバックボーンを形成しています。投資家、顧客、そして上司を安心させるのに十分な程早く機能を開発する必要があるということに対して一層気にかけています。この頃、より多くの時間を費やして、チーム、ツールそして実装のことを考えています。

プロセスとチーム

Railsは、「アジャイルで、幸せになるんだ」と言っています。我々はそれに対して対抗しません。アジャイルなアプローチは好きです。これらのアジャイルな原則をしっかりと受け入れています。

  • 我々は、短くてメリハリのある一週間のイテレーションのプロセスに集中します。そして少なくとも毎週デプロイします。
  • 強制的に品質を形式的なテストサイクルへ通過させてしまう代わりに、我々がコーディングしたように、テストケースを書く開発者を信頼しています。
  • リファクタリングを行う事が我々のビジネスの目的に適うのであれば恐れずにリファクタリングを行います。リファクタリングを行いコードの質を高め、そして要件に取り組み、柔軟性を高めます。
  • 週一回小さな要件を管理し、月一回大きな要件を管理します。
  • たとえば我々のチームが分けられたとしても、毎週のデモを通してビジネスユーザーとの堅いコミュニケーションを維持します。

Trac(リンク)とSVNを使用して、ソースコードを管理し、基本的な要件の進捗具合を追跡して基本的なリリース案を管理します。TracとSVNの堅い統合は、私にソースツリーで何が起きているかを迅速に理解するための便利な一覧を与えてくれます。重い自動化テストと軽い手動テストの後、我々はわずかな変更を直接商用環境へ押し込みます。そして大きな改訂に取り組むために、ステージング環境を持ったブランチを使用します。我々はtrunkを操作するのを好みます、そしてトラフィックや複雑なものによって、操作が出来なくなるまで操作し続けます。Railsプラットフォームで、修正の必要があるのは、比較的重要でないものが多いです。

我々の開発チームは3つの地域に分かれて配置されており、チームをより広く分けて配置する計画をしています。毎日率直な会話を心がけているので、質問に対して回答を直ぐに貰えます。新人採用を制限するよりむしろ、最高のRails開発者を求めて、長距離であっても情報交換をすることが出来ます。これまで、トレードオフは、良い成果をあげてきました。無駄な会議をしません。私のチームの開発者は、毎朝スタンドアップミーティングを行いますが、Skypeのチャットで行います。また毎週テクニカルミーティングをビジネス担当者と開き、優先順位を決め、毎週のリリースの予定を立てています。

Railsが複雑な解決策に対してあまりスケールしないと聞く事が時々ありますが、この件に関しては同意しかねます。Railsは他の技術よりもはるかに生産的であり、劇的な影響を開発プロセスに与え、そしてそれに続いて、チームを編成し管理出来るからです。使用している技術に鋭さがなければないほど、長時間イテレーションの間をいったり来たりしなくてはいけなくなります。チームの規模が大きくなればなるほど、管理とコミュニケーションに時間を費やさざる負えません。RubyとJavaのプロジェクトを両方経験した後、そのような考え方が一層強まりました。他の組織は10から15人規模のより大きな開発チームを作りましたが、我々はチームの規模を小さく保ち続けています。どんな状況におかれても、Rubyの開発者5人とHTML及びデザインを担当する人員を最高二人を持つに留まっています。開発チームを7人まで増やして快適でいられます。8人以上になると、2つ目の開発チームを作り、より複雑で高価なコードベースの孤立した要素に取り組んでもらっています。.

ツール

我々が使っているツールはどれも非常にシンプルです。Railsのテスティングスタックを使い、RCovを投入してテストカバレッジを行っています。Seleniumを使って統合テストを行っています。全てのテストとカバレッジツールの実行はRakeで行っています。テストケースのカバレッジは85%を保っています。定期的に目標としているテストカバレッジの85%を下回ることがありますが、90%以上になることもなければ79%以下になることもないです。何故ならカバレッジを追跡しているからです。ユーザーインタフェースがころころ変わるので、Selenium(リンク)を使ってテストした結果が上手くいくことはあまり多くありませんが、一旦ユーザインタフェースが固まれば、Seleniumによるテストは効率的だと思います。主にRails unitとfunctional testを使っていますが、他のテストツールがないかどうか探っています。

開発者のそれぞれが、コードを編集したいときは、どのツールを使っても良いとしています。今までのところ、誰もIDEを使っていません。ほとんどが、TextMateを使いソースを編集しています。ベンチマーキングとデバッグ用のRailsツールは、ロギングとテスティングが一緒になり、システムをデバッグするのに必要なものを全て与えてくれます。リファクタリングの中には、苦痛なものがあります。特にモデルを背後に持つデータベースを変更しなくてはいけないときです。だから一旦IDEが十分良いものであることをが分かったら、我々はそのIDEを使い始めることでしょう。経験上、我々のメンテナンスサイクルは、典型的なJavaのメンテナンスサイクルと比較して3倍速いです。もしかしたらもっと速いかもしれません。.

コアアーキテクチャ

我々は、企業が主要なソフトウェアプロジェクトを構築する方法を変更する急進的な運動の一部ですが、時代の流れは我々に適合しています。我々のコアアーキテクチャーは、基本的なRailsのアーキテクチャを遵守するものでした。migrationsを信頼しています。確かに改善の余地がありますが。データベースに関しては、我々はDHH(リンク)信奉者です。データベースに参照整合性のような制約を設けようとしませんでしたし、データベースのビューは使っていません。そして、テストの側から言うと、我々は第一に、Railsフレームワークを信頼しています。確かにテストケースが大きくなってきているので代わりとなるテスティングツールを探し始めてはいますが。まだ結論を下せないので、第一の哲学にこだわっています。しかし、結論に達したとしても、REST(リンク) WEBサービスを伴った典型的なRails MVCを使っているでしょう。主に強化した点を以下に記述します。

The Model

多くのソーシャルネットワーキングサイトのように、我々は読み取りのパフォーマンスをまず最適化しますが、比較的かなり多くのコンテンツが静的コンテンツで、変更はあっても1日に1回ぐらいです。我々の競争相手向けの統計に基づきますが、我々は高いボリュームを期待しました。だからUNICEFのような非営利組織、贈り物(目の見えない人を見えるようにしたり、ガン研究者へ一時間を送ったりなど)、世界平和や医学研究のような要因を含めて安定したコンテンツに関してはキャッシュすることに頼りました。これらのコンテンツは、あまり変わらないので、積極的にキャッシュしました。その目的を成し遂げるために、ActsAsCacheableプラグインを利用しました。キャッシュのバックエンドは、MemCacheというセカンドレベルの分散キャッシュサービスですが、実際上、一部の例外を除きActiveRecord APIを直接使用しています。

またサイトには、有効なワークフロー機能があります。非営利団体はコンテンツを登録することが可能で、ChangingThePresentの管理者が各々の改訂を承認したり編集を行います。どんなときでも贈り物の表示と非表示の切り替えが出来なくてはいけません。そして贈り物を非表示にするときは、該当するレコードをデータベースから物理削除することより、むしろ論理削除を行う方を好みます。このカスタマイズされたワークフローをサポートするために、ActsAsStateMachine(リンク)というプラグインを利用しています。そのプラグインを利用することによって、DSL言語を使いステート・マシーンを表すことが可能です。「Crossing Borders: Rails Plugins.」(リンク)で関連記事を読む事ができます。

ビジネスユーザとコミュニケーションを交わすまでは、そのようなDSLがどれ程効果があるか分かりませんでした。Ruth Ann Hacking女史が、我々のコンテンツの収集と管理を担当しています。彼女はプログラミング経験はありませんが、ワールドカップのフェンシング選手です。彼女は完璧に、サーベル(またはボールペンで)私を殺せるので、常に彼女を幸せな気分になるよう努めています。思いつきで、彼女にステート・マシーンのコードを送りました。彼女はアプリケーションを最初から最後まで使って、幾つかの重大なバグを発見する。Ruth Annは幸せな気分になり、彼女が幸せな気分になったので、私は生き延びました。しかしそれこそが、Railsライフです。不必要ながらくたの山が出ていって、フレームワークの中に隠れ、楽しいものを私に残してくれます。

ユーザインターフェース

我々のユーザインターフェースは、典型的なRailsのコントローラ、ビュー、そしてレイアウトを使用しています。新しいRailsのRESTfulコントローラをまだサポートしていませんが、新しいコントローラが、以前のコントローラを利用でき、新しいWebサイトの機能は新しいコントローラを使えることになるだろう。AJAXについて言うと限られた使い方をしています。例えばグリーティングカードウィザードの編集画面などです。しかし一般によりクリーンでシンプルなインターフェースを好みます。サイトをスケールするために、我々は次の事を実施しています。:

  • イメージファイルを出来るだけ最少化するように努めています。サイトの多くは、角丸であり、それらをJavaScriptライブラリを使用してレンダリングしています。Panther Expressが定着すれば、恐らくこの戦略を続けるだろう。
  • ページコンテンツを限定的にキャッシュしています。静的ページをキャッシュしていますが、ページフラグメントは、キャッシュの対象外です。このサイトには静的なページはほとんどありません。何故なら全てのページで、ユーザ毎にカスタマイズが可能だからです。我々は主にActiveRecordレベルにおいて、キャッシングを実装しており、イメージファイルのキャッシングは、PantherExpressを使用して行っています。
  • 当初ギフトを、ページ分割し尚かつアルファベット順に表示していました。しかし、ユーザは学習し、ギフトの名前をアルファベットのAから始まるようにしていることに直ぐに気がつきました。ギフトをアルファベット順に表示していましたが、ランダムに表示されるように変更し、その結果を毎日キャッシングしました。ビューで、この作業を行う事よりもむしろ、カスタムなファインダーをMySQLの乱数関数を使用して構築しただけでした。そして今日、今月、今年と決まりきった方法で乱数の種をまきました。

ゆくゆくは

新しい機能が、速やかに追加されます。初期コンテンツは、全ての顧客に向けていました。そして、我々は戻って来て、コンテンツを管理する能力を強化しました。また12月のサービス立ち上げ以降、沢山の機能を追加してきました。新しいコンソールを非営利団体の奉仕活動に対して追加し、非営利団体が、我々が行った変更を全てレビュー出来るようにしました。またコミュニティー機能を追加し、ユーザが独自の寄付活動を始められるようにしました。ホームページを改善し、会話に関して贈り物により多くのことをさせました。ブログを公開し、すぐに結婚式の登録を改善しました。

小さなそして地理的に離れたチームで、このプロジェクトを管理し続けることでしょう。我々は継続して、RailsとLAMPに投資していることでしょう。サイトが安定稼働した現在では、我々がコミュニティを確立したり、トラフィックをさばくのを補助する機能の構築を行っているのだと期待していてください。テクノロジーを構築する事は単に、全般的な問題の一部に過ぎないと理解しています。積極的にこのサイトに参加しようという非営利団体がの数が増え、ChangingThePresentブランドを確立する様を期待して下さい。

援助

Rubyコミュニティは素晴らしかったです。そして、至る所で我々を支えてくれました。全ての寄付金を目的の非営利団体へ手渡し、クレジットカードの手数料のみ頂いています。しかし、そのことはサポートを得るのに我々があなたのような人々に依存していることを意味します。もしあなたが援助を行いたいと思ったら、出来る事が沢山あります。:

  • サイトにログオンし、「Support Changing The Present.」というリンクをクリックしてください。
  • このサイト、好きな理由や募金活動をサポートしているブログにバナーを貼付けてください。
  • プロフィールを作り、サイトのことを知っている身近な人、5人に伝えて下さい。そしてその5人にサイトの存在を広めるようにお願いしてください。
  • もしコーディングを望むのであれば、ボランティアとしてデザイナ、フラッシュの開発者、Rubyのコーダーを募集しています。InfoQ経由で気軽に連絡してください。

好きな事が出来る仕事を得たり、人と一緒に楽しんだりすることは毎日ではありません。そして、いつもとは違った事を行っているんだと分かることでしょう。我々がサイトを構築するのを楽しんだのと同じくらいに、楽しんでこのサイトの話を読んでくれたことを望みます。

著者について

Bruce Tate氏は、二人の子供の父であり、マウンテンバイク乗りであり、カヤック乗りであり、そしてテキサス州オースチンに住んでいます。彼は、WellGood,LLC社のCTOで、ChangingThePresent.org(リンク)を計画、運営そして築の責任がある社会的な起業家です。Bruce氏は、9冊の本を著し、その中には、「From Java to Ruby」「Rails Up and Running」そして「Beyond Java」などがあります。

原文はこちらです:http://www.infoq.com/articles/changing-the-present-case-stud
(このArticleは2007年3月26日に原文が掲載されました)

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT