FogBugz On Demand
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2007年7月9日 月曜
FogBugz On Demandサービスが利用できるようになったとお伝えできるのが嬉しい。これは以前はダウンロード版のみが提供されていたFogBugz 5.0のホスティング版だ。
Webソフトウェアを売っているというのはFog Creekの商売のちょっと奇妙な一面だった。FogBugzはWebベースのプロジェクト管理ツールであるというのに、どうしてユーザはダウンロードして自分のサーバにインストールしなければならないのか?
そうしていたのは、私たちの会社が小さかったからだ。社員は一握りしかおらず、ユーザがミッションクリティカルなデータを安心して預けられる信頼性の高いサービスプロバイダをやれるだけのリソースがなかったのだ。
FogBugz On Demandの準備のために、この一年というもの私たちはすごく働いた。
まずシステム管理の専門家を雇った。彼はホスティングのためのインフラを細部にいたるまで調べ、パッチを当てたりテストしたり、あらゆる部分の信頼性を改善した。NetBSDサーバはすべてLinuxにアップグレードし、新しいハードウェアをたくさん設置し、自動モニタリングを山ほど仕込んだ。
私たちはホスティングには基本的にハイエンドのコンポーネントを使うことにした。SCSI RAIDのDell PowerEdge 2950、Windows Server 2003、それにSQL Server 2005。まあ、確かに高く付く方法だ。FogBugzはLAMP (Linux / Apache / MySQL / PHP)で問題なく動かせるわけだから、ずっと安いハードウェアを買い、フリーソフトだけ使えば、ある程度の頭痛と引き替えに金を節約することもできた。ホスティングサービスはほとんどの場合LAMP上に構築するのが正しいと思う。しかし私たちの場合、Microsoftのライセンス料や極めて信頼性の高いDellのサーバのコストはたくさんの有料顧客にうすく広げることができるので、顧客当たりのコストの違いは取るに足らないものとなる。それに私たちはIISとMicrosoft SQL Serverを6年間データを失うことなく走らせてきた経験があり、熟知し信頼しているのだ。ただ正直なところを言えば、新しいサーバを同時に10台ラックに積むことがあれば、そのときはLAMPに切り替えると思う。その場合でも相変わらずDellのサーバとSCSIハードディスクにするつもりだが、安い無印のハードウェアに比べ余計にかかる幾ばくかのコストは、信頼性の部分で十分引き合うものだからだ。
マルチホスト環境下でうまく動作するようにFogBugzのコードベース自体に変更を加えた。私にとって一番の驚きは、それぞれのユーザがいろいろなものを自分のタイムゾーンで見られるようにするのにいかに手間がかかったかということだ。それと料金請求のためのシステムにも手をかけた(FogBugz On Demandは月21ドルだ)。データベースと連携するDNSシステムを作って、On Demandの顧客がそれぞれ自分のドメイン(you.fogbugz.com)を使えるようにしている。
今回の変化で一番大きいのは第2のデータセンタを立ち上げたことだ。顧客のミッションクリティカルなデータに責任を持つということがどれほど怖いことなのかは言葉にもできない。だからどれほど強固にする必要があろうと、けっして障害を出したくなかった。
私たちの最初のデータセンタはPeer 1 Networkを使っていて、ニューヨークの金融街の中にある。Peer 1はカナダのバックボーンプロバイダで、私たちは2003年以来使っている。彼らのバックボーンのアドバンテージを生かすため、第2のデータセンタはロサンゼルスに新しくできたPeer 1の施設を使うことにした。この新しいデータセンタはニューヨークにあるものの正確なレプリカになっている。
2番目の設備にもPeer 1を使うというのは、卵をすべて1つのバックボーンに置くことになるわけだが、Peer 1はまったくもって信頼性の高いバックボーンであり、優良な企業だ。私たちは実際他のコロケーションプロバイダもいくつか調べてみて、(名前は挙げないが)シカゴのプロバイダを試してもみた。しかしローンチの直前に6時間の停電があった。その後彼らのネットワーク接続性は不十分なもので、信頼性のあるシステムを構築するというときの「信頼性」の定義も私たちとは違っていることが分った。だから彼らを使うのはやめにして、サーバをすべてシカゴからロスに移し、実証済みのPeer 1でいくことにしたのだ。
ロサンゼルスはただのバックアップにするのでなく、完全にライブにすることにした。ユーザの半分はロサンゼルスで、半分はニューヨークでホストされることになる。そうすることで、大きな障害が起きたときになってバックアップデータセンタに問題があることに気付くのでなく、どちらのデータセンタも稼働し、正しく構成されていることを確認できる。
データベースのバックアップは両方の都市で維持されていて、それぞれが相手のウォームバックアップとして働く。ニューヨークのデータセンタが完全に消滅すると、それが復帰しないことを確認した後、DNSレコードを変更してユーザをロサンゼルスのウォームバックアップに移す。このフェイルオーバーは即時に行われるわけではなく、ユーザは2つのことを待つ必要がある。データセンタが一時的にオフラインになったのでなくて本当にポシャッたのだということを確認する必要があり、またDNSの変更が波及するのには長くて15分ほどかかる。もっともこれはデータセンタがまるごと吹き飛ぶという一生に一度くらいの話であって、停電なんかでたびたび起きることではない。それぞれのデータセンタは高いバックボーンとの接続性、UPS、非常用のディーゼル発電機といったものを備えている(2003年夏の大規模な停電で多くのプロバイダが落ちたときにもPeer 1は持ちこたえたのだ)。
このウォームバックアップ機能を実現するために、私はトランザクションログシッピングをするSQLミラーリングアプリケーションを書いた。これは基本的に、一方の都市でインクリメンタルなバックアップを取り、圧縮し、他方の都市に送り、解凍し、ウォームバックアップデータベースに適用、ということをする。現在のところはログ転送を日に2回行っているので、一方のデータセンタが吹き飛ぶと1日分の作業が消える可能性があるが、2週間以内にもっと継続的なバックアップシステムを実装して、ウォームバックアップに15分以上のずれが出ないようにしようと思っている。
FogBugz On Demandは実は4月以来ベータテストをしており、FogBugzのトライアル版のホスティングは2000年以来行っていて、データを失ったことは一度もない。(信じるかどうか知らないが、最初のFogBugz 1.0トライアルサーバはオフィスのT1につないだディスプレイの壊れたThinkpadだった!) だから私たちの小さな会社にFogBugzのホスティングが非常に良くこなせるだろうことには自信を持っている。
(オリジナル: Announcing FogBugz On Demand)
