Herokuの準備不要なRailsアプリケーションホスティングは革新的

作者 Obie Fernandez , 翻訳者 南 伸二 投稿日 2009年5月28日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

クラウドコンピューティング ,

Ruby

タグ

Ruby on Rails ,

スケーラビリティ

原文(投稿日：2009/5/6)へのリンク

Herokuは先週、1年以上続いた無料のベータステージを終えて、そのRailsホスティングソリューションの商用バージョンをデビューさせた。彼らはそのサービスを "準備不要なデプロイ環境" と表現している。なぜなら、それはまったくシステム管理作業なしで運用でき、自動的にスケールするからだ。代替ソリューションよりも高価であるし、（今のところは）Amazon EC2をベースにしておりそのサービス内容合意書の制限が付随するが、彼らは手応えがありさらに試してみる価値があるものを提供していると私たちは考えている。

 

先週、数人のエンジニアと私がHerokuの共同設立者であるJames Lindebaum氏と話して、そのサービスについての考えを聞いた。彼は楽しそうに彼の会社のことを"Ruby好き"の集団と呼んだ。1年半と少し前、YCombinatorの支援のもと、James氏と二人のパートナーであるAdam Wiggins氏、Orion Henry氏は、Railsアプリケーションのデプロイを非常にシンプルにするサービスに関する作業を始めた。彼らが成し遂げたことはまさに革新的と言えるだろう。

 

Herokuを使うことで、スクラッチからつくられた真新しいRubyウェブアプリケーションのデプロイは、端末からのごくわずかのコマンドだけで完了してしまう。電子メールも電話もサポートチケットも不要だ。私たちはHashrocketで内部でのテスト環境をホストするために彼らのサービスを使い続けているが、これまでのどんなデプロイ体験とも異なるものだと確実に言える。CapistranoセットアップとデプロイはHerokuによって過去のものとなった。彼らのサービスに登録し、Herokuクラウド上にコマンドラインツールを利用して新しいアプリケーションインスタンスを作成しさえすれば、デプロイは"git push heroku master"とタイプするだけという簡単さだ。

 

そのpushコマンドをトリガーとして、アプリケーションはHerokuにおいて“slug”と呼ばれる自己完結型で読み取り専用のインスタンスにコンパイルされる。実際に起動することを確かめるテストが自動的に行われ、gemの依存パッケージも自動的にインストールされる。gemの依存パッケージはアプリケーションのルートディレクトリにある.gemマニフェストファイルによって管理されるが、それだけが一般的なRailsアプリケーションとのごくわずかな違いの一つである。MerbやSinatra（そして実際のところ、どんなRackの）アプリケーションもサポートされていることも特筆すべきことだろう。

 

いったんpushコマンドが成功すれば、slugは特別にデザインされたグリッドコンピューティング環境の1つまたは複数のスロットでインスタンス化される。そこではデータベースとキャッシュ情報へのアクセスが与えられて、slugは命を吹き込まれる。サポートされている唯一の主要なデータベースはPostgresである。James氏によれば、MySQLにはDDLトランザクション処理がないので、Herokuは現状MySQLをサポートしていないとのことだ。

 

slugが活性化すると、“dyno”と呼ばれる完全な機能を備えたウェブアプリケーションになる。 各dynoはグリッド内で動く1つのプロセスであり、 アプリケーションのコード、フレームワーク、ミドルウェア、Rackアプリケーションサーバ、Ruby仮想マシン、POSIX環境のユニークコピーを含んでいる。dynoで使われているアプリケーションサーバは少し修正されたバージョンのThinであり、250 MBのメモリを必要とする。

 

Herokuのインテリジェントインフラストラクチャは、需要が変化するのに応じて、完全に独立したdynoをグリッドの新しい場所に追加的に立ち上げたり、アイドル状態にあるdynoをシャットダウンしたりすることが可能である。新しいdynoを起動するのに必要な時間は2秒未満であり、そのことによってHerokuプラットフォームは前例のないレベルのダイナミズムを実現している。実際には高い需要に合わせるために新しいdynoインスタンスが起動する間、カスタムルーティングシステムにより要求を"保留"することができる。dynoは4インスタンスで一般的な環境におけるサーバ1インスタンスと同等の演算能力を持つ。

 

Herokuグリッド自体も強固なクラウドコンピューティングインフラストラクチャの上に構築されていて、それによって、多くの異なるアプリケーションが必要とする数多くのdynoを供給できるように、要求に応じて拡張したり収縮したりすることができる。そのグリッド上では洗練され高度に並列化されたルーティングメッシュがあり、複数のdynoに要求を割り振っている。さらなる要素としてHTTPキャッシュとメモリキャッシュがあり、それぞれdynoやデータベースへのリクエストを削減している。

 

James氏によれば、このルーティングメッシュはプロプライエタリなものであり、Herokuの革新の重要な一部分であるという。このシステムの初期のバージョンはNginx C-modulesとして実装され、およそ10,000アプリケーションがデプロイされるまではうまく動いたが、パフォーマンスに問題が出始めた。ルーティングシステムの第2のバージョンはErlangで書かれ、今でもとてもよく機能している。

 

Heroku自体はextra-large EC2インスタンスプールにホストされている。 私はJames氏にEC2を直接使うことで彼が支払っているプレミアムはいくらなのか尋ねたが、その質問に答えるのは難しいようだった。Herokuは完全なシステムアーキテクチャを含んでおり、1つのアプリケーションを複製するのにEC2インスタンスが6、7個必要となる場合があるので、2つのサービス間で妥当な価格比較を行うことが難しいのだ。その一方で、新しいHeroku dynoを活性化、非活性化することが簡単にできるため、注意深く消費量を管理するコストを通常のEC2デプロイよりも容易に削減できるのだ。

 

Herokuの価格モデルはユーザが使ったリソースの分だけ課金するように設計されていて、どんなレベルのユーザにも適合するようになっている。大きなアプリケーションを持ち1ヶ月に何百万ものヒットがあるようなエンタープライズレベルユーザから、エントリーレベルのユーザにいたるまで、すべての人に合うようにするためのさまざまなのレベルがある。価格レンジは、1ヶ月何千ドルというレベルから数百ドル以下というレベルまであり、さらにはサービスのテストやラピッドプロトタイピング（素早い試作）にぴったりの無料提供のものもある。上に述べたとおり、私たちはその無料提供環境を内部でのテスト環境のデプロイに利用し続けており、非常によく機能している。

 

Herokuのサービスは、延長されたベータ期間において、23,000以上の異なった開発者によって25,000以上のRubyアプリケーションがデプロイされるという過酷な試練に耐えてきた。控えめに見積もったとしても、Herokuのプラットフォームはその次に人気のあるデプロイ環境プロバイダに比べて10倍以上の規模がある。商用環境の提供は始まったばかりだが、James氏は、最初から有料顧客を得ており、かつ投資家からのサポートによって新たな顧客を強く継続的に獲得する準備が出来ている、と語った。(2008年5月にHerokuはRedpoint Venturesから300万ドルのシリーズA資金を調達している)

 

• 次へ >