(mt) weblog: We apologize

(mt) Media Temple would like to apologize to our (gs) Grid-Service customers for the series of issues relating to the (gs) system in the past few months. As an appreciation for your patience, we have applied 2 months free credit to your account. This credit has been issued automatically and is reflected in the billing area of your AccountCenter. We appreciate your continued business.

お詫びに2か月分タダにします、とのこと。

BlueArc 製ストレージのファームウェアに問題があって、そのアップグレードがうまく行かなくて、さらにロールバックにも問題が生じたんだとか。まあなんと言ったらいいのか…担当の方は体に気をつけてがんばってください。

正直言って今回ばかりは頭にきていたので今度こそ乗り換えようかとも思ってたんですが、まあ、対処に手を尽くしているようだし、CEO もあやまってるわけだから、もうちょっとだけ我慢してつき合ってみよう。結局、コスト面では今のところ Media Temple がベストに近いわけで、トラブルさえ出し切ってくれれば、いつかは良くなると信じて…。

Update (2008/01/17): 公平を期すために、というわけでもないんですが、

TechCrunch Japanese: ZFSファイルシステムのバグでJoyent、長時間ダウンを余儀なくされる

新しい技術を積極的に取り入れているところはどこにしてもトラブルは付き物だという話、か。がんばれ Media Temple。まけるな Joyent。

昨年末にこのブログを Grid-Service に移して、それ以降 Montastic から送られてくる unreachable のメールが月に何回あったか、というのをカウントしてみたのが下のグラフです（横軸が月、縦軸が回数）。

開始からほぼ3日に1回のペースだったのが、ここ2ヶ月は2週間に1回程度まで落ちついてきているのがわかります。あまり参考になるデータではないですが体感的には、改善されてきているな、という実感があります。

6月に急に回数が減っているんですが、その頃ちょうど SmartPool の導入が進められていたのでその効果じゃないかと思います。MySQL を使うアプリケーションに 64MB のメモリ使用を保証するというもので、追加費用なしに全ユーザに適用されるようになりました。

個人的にはトータルでみてけっして劣るサービスではないと思ってます。

半年ぐらい前にこのブログで書いた話では、Grid-Service は「機能性とコストパフォーマンスについては素敵きわまりないが、安定性に欠けるのが玉に瑕。でもまだ始まったばかりのサービスだから、しばらく大目に見て今後の改善に期待したい」というようなことで、150キロ投げるノーコン高校生、ぐらいの扱いだったわけですが、あれから半年経過していろいろとアップグレードされたようですが、当初と状況はあまり変わりありません。相変わらず150キロ投げますがノーコン大学生です。

今日じつは、Grid-Service のファームウェアをアップデートするとかで、日本時間の 16:00 から 19:00 までの間でメンテナンスするので短時間接続不能になるかもしれませんよ、と、Media Temple からメールがきていたのですよ。

This maintenance action will require that parts of the Grid be briefly taken offline. A very short period of downtime may occur, customers should prepare for a brief disruption of services such as web, email, and ftp. It is likely that only a small portion of the maintenance window will actually be needed.

17:10 ごろ、つながらなくなったのを確認して、ああ、メンテナンスの日だったな、と思い出したのですが、それから、つながらない状態のまま秒針は回り続け、まわりつづけ、分針もよっこらしょと1回転、2回転、ようやく回復したのが 19:10 ごろです。”A very short period” ってあんがい長いんですね。

まあ前にも同じパターンが一度あったので、今回は驚きませんでしたが。

追記: 正確な記録のために書いておくと、Rails Container が復旧したのはさらにさらに遅れて、翌 03:30 ごろでした。

そんなこんなで、アップグレードは結構なことなんですが、かなり電撃戦的にアップグレードしてくれるのでこちらとしてはハラハラもんです。面白いサービスではあるので個人的な用途(このブログとか)では使い続けようと思っていますが、ビジネス用途ではちょっと考え直した方がいいかもしれない、なんて思えてきました。ついていけません。

Dedicated-Virtual という Grid-Service より上位クラスのサービスもあるんですが、こういうメンテナンスをされるとどのサービスでも心配な気がするな。

それでビジネス用途で使いまわしのきくホスティングサービスをまた探しているところなんですが、国内のホスティング業界の Ruby on Rails 対応はあいかわらずですね。けっきょく TextDrive あたりが妥当だろうか。買収した Joyent によるブランド再編が進んだようなので、1年前に使っていた頃とは勝手がちがうようですが。

またいろいろと試してみるか。

Ruby-GetText-Package を使おうとしたわけです。これはおもに UI のローカライゼーションに使われる gettext の Ruby 版です。いま使っている Ruby on Rails 1.2.2 に対応しているのは Ruby-GetText-Package 1.9.0 で、1.8.0 以前のはうまく動きません。

ローカル PC 上の development 環境に Ruby-GetText-Package 1.9.0 の gem をインストールして、正常に日本語化できるのを確認しました。それでいざ、Grid-Server の production 環境に展開してみたらさっぱり動かんわけです。mtr start して mongrel を起動する段階でこけてしまう。

mongrel.log を見るとこんなエラーが出てました(一部伏字と改行挿入)。

** Starting Mongrel listening at 0.0.0.0:****
** Starting Rails with production environment...
/home/****/data/rubygems/gems/gems/activesupport-1.4.1/lib/active_support/\
    dependencies.rb:263:in `load_missing_constant': \
    uninitialized constant Locale::System (NameError)
from /home/****/data/rubygems/gems/gems/activesupport-1.4.1/lib/\
    active_support/dependencies.rb:452:in `const_missing'
from /home/****/data/rubygems/gems/gems/gettext-1.9.0/lib/gettext/\
    locale_posix.rb:17
from /home/****/data/rubygems/local/lib/site_ruby/1.8/rubygems/\
    custom_require.rb:27:in `require'
from /home/****/data/rubygems/gems/gems/activesupport-1.4.1/lib/\
    active_support/dependencies.rb:495:in `require'
from /home/****/data/rubygems/gems/gems/activesupport-1.4.1/lib/\
    active_support/dependencies.rb:342:in `new_constants_in'
from /home/****/data/rubygems/gems/gems/activesupport-1.4.1/lib/\
    active_support/dependencies.rb:495:in `require'
from /home/****/data/rubygems/gems/gems/gettext-1.9.0/lib/gettext/\
    locale.rb:40
from /home/****/data/rubygems/local/lib/site_ruby/1.8/rubygems/\
    custom_require.rb:27:in `require'
... 25 levels...
from /home/****/data/rubygems/gems/gems/mongrel-1.0.1-i386-linux/bin/\
    mongrel_rails:83:in `run'
from /home/****/data/rubygems/gems/gems/mongrel-1.0.1-i386-linux/lib/\
    mongrel/command.rb:211:in `run'
from /home/****/data/rubygems/gems/gems/mongrel-1.0.1-i386-linux/bin/\
    mongrel_rails:243
from /home/****/data/rubygems/gems/bin/mongrel_rails:16

僕はいろいろ試行錯誤したあげく理由がわからず、結局そのときは Rails 1.1.6 と gettext 1.8.0 を使うという回避策(この組み合わせなら動いた) に逃げたわけですが、後になってわかってみたら単純なことでした。

Grid-Server の Ruby on Rails Container 環境では C の拡張を含むタイプの gem が正常に動かない場合があります。Ruby-GetText-Package や RMagick がそれに該当するようです。Media Temple ではそれらの gem を使えるようにするために、コンパイル済みの特注 gem を用意して自社のリポジトリで公開しています。

もし必要な gem がまだなければサポートにリクエストをあげればコンパイルしてリポジトリに追加してくれます。Ruby-GetText-Package の 1.9.0 の gem はまだなかったので、サポートに連絡して追加をお願いしたところすぐに追加してくれ、これで正常に動作するようになりました。

うまくいかないときは思い出してみるといいかもしれません。

Ruby on Rails の Acts as Attachment というプラグインを使ってみました。これはアップロードされた画像ファイルの管理を楽にしてくれるもので、ちょっとした設定で、画像をデータベースに保存したり、ファイルシステム上に保存したり、サムネイルを作ってくれたりと、基本的なことはひととおり面倒を見てくれます。手軽で便利なので気に入っています。

さて、このプラグインは中から RMagick の gem を require するんですが(画像のサイズを測ったりサムネイルを作ったりする際に必要になるため)、Grid-Server の Ruby on Rails Container で RMagick を使う場合にはひとつ注意点があります、ということを今週教わりました。

RMagick の gem は、Ruby on Rails Container 専用の特注品が用意されているのでそれを使います。

gem install RMagick --source=http://gems.mediatemple.net/

しかしそれでも rake migrate の際にエラーが返ってきました。RMagick が関係しているっぽいです。

$ rake migrate RAILS_ENV=production --trace
...
rake aborted!
uninitialized constant Enum
/home/xxxx/data/rubygems/gems/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:123:in `const_missing'
/home/xxxx/data/rubygems/gems/gems/rmagick-1.13.0-i386-linux/lib/RMagick.rb:28
...

Google で探してみると同じような話が詳しく書いてありました。Mongrel のウェブサーバにシェアードライブラリのパスを持たせてないのが原因、というような話で、よくわかりませんが今回のケースもそれと関係あるんじゃないかと思いました。

それで Media Temple のサポートに問い合わせてみたんですが、半日待たずに返事がありまして、ナレッジベースの記事を教えてくれました。どうも問い合わせたちょうどその日に公開された記事のようです。それによると RMagick の gem を require するときに発生する例外を受け流すようにコードを付け足す必要があるということ。

Acts as Attachment の場合は vendor/plugins/acts_as_attachment/init.rb を次のように、

begin
  require 'RMagick'
rescue LoadError
  # boo hoo no rmagick
rescue NameError
  # RMagick didn't load right
end
...

これで解決。どんぴしゃです。

そんなわけで Media Temple のナレッジベースが徐々に充実してきています。

海外のホスティングサービスでは珍しくないですが (gs) でも subversion のリポジトリを置くことができます。けっこう重宝しますが、いまのところ svn+ssh でのアクセスしかサポートしていません。それでクライアント側の設定でかなり悩みました。(gs) の情報はまだ少ないのでこういうとき困ります。最終的にこの辺(コメントがとても役に立った) 見てなんとか成功しました。

…

まあ、そんなこんなで、年の瀬でなにかと忙しそうにしていてブログの更新も滞ってきましたが、元気にやっています。ひさしぶりだと文章の書き方も忘れますね。

先月は以前から虫の息だった炊飯器が壊れ、テレビは何も映さなくなりました。見れなきゃ見れないで別にどうってことはないんですが、逃亡者おりんが見れなくなったのが唯一残念です。

Ruby on Rails Container というのは Rails アプリケーションのために特別に設けられた環境で、ユーザのその他の環境とは切り離されて管理されます。メモリも専用の割り当てが与えられ、デフォルトでのバンドルが 64MB、さらに月額の追加料金を払えば 256MB($25)、1GB($75) に増強できます。

1アカウントに対して 1コンテナまでしか使えませんが、1コンテナのなかで複数の Rails を動作させられます。ただ Rails アプリケーション1個あたりで最低でも 20MB 程度食うようなので、64MB のコンテナだと2個程度が限度だろうと思います。

割り当て上限を超えてメモリを消費しようとした場合は、コンテナで動いているアプリケーションのひとつをランダムで選んで終了させるそうなので、あらかじめ余裕を持たせておいたほうが良さそうです。メモリ消費が上限近くになるとアラートが上がるように設定できます。

HTTP サーバは Mongrel が使われます。アプリケーションごとに Mongrel のプロセスと、個別のプライベート IP アドレスとポート番号が割り当てられ、外側でアクセスを受ける Apache からその Mongrel のポートにリダイレクトされる形になります。

コンソールから gem install コマンドで自由に RubyGems をインストールできるようになっていて、影響範囲はコンテナ内に限られるので好きな Gems を入れて使うことができます。Rails や MySQL、Postgres、Mongrel などの主要な Gems については動作確認済みのバージョンが Media Temple のリポジトリから配布されていて、そちらを使うことが推奨されています。

SSH のコマンドインタフェイスから rails や rake などのコマンドを実行できるほか、アプリケーションのストップ/スタートなどは mtr (Media Temple Container control program) というスクリプトで管理が簡単にできるようになっています。

新たに Rails アプリケーションを動かすまでの基本的な流れとしては、

1. $HOME/../../containers/rails ディレクトリに Rails アプリケーションをコピー
2. mtr コマンドでコンテナにアプリケーションを追加
   専用のプライベート IP アドレスとポート番号が割り当てられる。
3. アプリケーションの public/.htaccess を書き換え
   先に割り当てられたポートに全接続がリダイレクト (リライト) されるようにする。書き換えは mtr コマンドが自動的に行なう。
4. $HOME/domains/(domain)/html からアプリケーションの public ディレクトリへのシンボリックリンクを張る
   これも mtr コマンドで行なわれる。
5. mtr コマンドでアプリケーションをスタート

こんな感じです。

アプリケーションの log ディレクトリに mongrel のプロセス ID ファイル (mongrel.pid) が作られるので、アプリケーションを新バージョンに移行する場合はこれも忘れずにコピーすることが必要です。バージョンの移行に関わる一連の作業を僕はスクリプト書いて実行してますが、svn が使えるので containers/rails に作業コピーを展開するというのも楽かも知れません。

とりあえずそんな感じで prairied.org は動いているわけですが、なにかほかに知りたいことあります?

コントロールパネルは期待通りの洗練された UI で、「いいものを使っている」感がたっぷりあります。

Bandwidth Usage Report とか Disk Usage Report なんかはリアルタイムで使用量を見ることができるのですが、「Bandwidth Limit: 1024000.00 MB」とか「Disk total: 102400.00 MB」なんて数字を見ると少しめまいがしてきます。これが当たり前の時代が来るのか!

1契約で 100ドメインまで管理できることになっていますが、Ruby on Rails を動かすための Container は1契約で 1個までしか使えないようです。ということは Rails アプリをたくさん動かすことはできないのかな。後日たしかめることになると思います。

SSH での接続は可能なはずなんですが、マニュアルどおりに設定してやっても認証ではねられます。これは現在調査中。

Update: 認証の際に challenge/response to log in (keyboard-interactive) を選択するとよいようです。(10/26)

マニュアルは一応あって、それなり丁寧に書いてはあるのですが、いまいちかゆいところに手が届きません。ここはちょっと不満。情報の多さ、という点では TextDrive が非常に優れていて安心でした。Media Temple にも頑張ってほしい。

それから、コントロールパネルの反応が重たいのもちょっと不満。公開された直後のサービスだから一時的に混乱しているだけならいいけど。Urchin のアクセス解析がバンドルされてるから Google Analytics 要らないね、と先日書きましたが、これも重たいので再々見る気にならない。けっきょく Google Analytics に戻ることにしました。

Google Analytics のトラッキングコードの埋め込みで満足のいく方法がほかに見つからなかったので、WordPress 用のプラグインを自分で作りました。このブログにも導入済みです。よければ使ってください。

それで接続自体の安定性というのは、じっさいこれが一番重要なんですが、3日程度の間に2度ほど unreachable のアラートが上がり、それほど深刻にも受け止めていないですがそれなりに、やっぱり月20ドルで万事バラ色ってわけにはいかんのだな、というちょっとがっかりな感覚。でもこれもしばらく経ってみないと、やはりサービス開始直後の混乱もあるかもしれないので。

でもやっぱりこれで月20ドルってのは、すごいことだと思いますけどね。

すぐこれが当たり前の時代になるんだろうなあ。だんだん日本って遅れてる気がしてきた。