アインシュタインの電話番号
2011.05.07
HerokuでWebアプリ開発を始めるなら知っておきたいこと(9) Heroku以外の選択肢

「HerokuでWebアプリ開発を始めるなら知っておきたいこと」シリーズの第9回では、Herokuはとても便利だけど依存しすぎてしまうとちょっと危険だよ、という実体験について書きます。このシリーズのまとめページはこちら。

4月21日に起こったAWSの大規模障害

ほんの2週間ほど前に、Amazon Web Services(AWS)に大規模障害が起きました。Twitter上でも結構ツイートされ、IT系のメディアでも大きく取り上げられたので、ご存じの方も多いと思います。

Amazon Web Servicesの障害はなぜ起こったのか － ＠IT Amazonクラウドの大規模障害を経て、これからは「データセンターはいつか落ちる」ことがサービス設計の前提となる － Publickey Amazon、EC2の大規模障害について正式に謝罪　10日分のサービスクレジットを提供

Herokuのプラットフォームは、AWSのEC2およびEBSを利用したサービスだったため、この大規模障害の影響をモロに食らってしまいました。

4月21日にリリースした「はてなスターカウンター」

私が個人で作っているWebアプリの最新作はてなスターカウンターは、奇しくも大規模障害の起こった4月21日にリリースしました。

はてなスターの総数を表示できる「はてなスターカウンター」を作ってみた

4月21日の午前中に公開して、昼過ぎあたりに@func09さんや@deeekiさんにリツイートしてもらえてそこからRTが徐々に広がっていき、夕方にははてな社長の@jkondoさんの目にも止まってさらにRTが広がり、順調にはてブ数も増えていき、その日の23時頃にはホッテントリの一番下に載りました。この時点（公開後10時間経過）でのはてブ数は約80、カウンター利用数は約70サイトでした。

この流れは、Nekostagramが一気に広がった時よりは劣るものの、そのときと良く似た拡散の仕方で、これはイケるかもとちょっと浮かれてました。しかし… その時、事件が起こったのです！

言うまでもありませんが、前述のAWS障害発生によりHerokuが落ちました。これからさらに多くの人に見てもらえて、使ってもらえるかもしれないと期待したまさにその時、はてなスターカウンターのサイトにまったく繋がらなくなったのでした。

そして公開後2週間以上が経過した現在は、はてブ数が約110、カウンター利用数は約80サイトに留まっています。一番大事なタイミングでサイトが落ちてしまい、完全復旧したのは約3日後だったこともあり、その後まったく広がりを見せず、はてブ数や利用者数も伸びず、とても残念な感じになってしまいました。

利用する側の立場になって考えれば当たり前のことで、公開当日にサイトが落ちて数日間繋がらなくなったカウンターサービスなど自分だったら使いたくありません…ｗ その原因がなんであれ、このタイミングで訪問してくれた人・利用してくれた人には「不安定なWebサービス」としか映らなかったはずです。そんな状態に陥ったにも関わらず、現在もはてなスターカウンターを利用してくれているブロガーさんがいることには本当にありがたく思っています。

何が起きたか、どう感じたか、今後どうすべきか

4年に1度クラスの大規模障害が起きたプラットフォームで、その障害の当日にWebアプリをリリースしたという経験は結構貴重だと思うので、この時に何が起きて、どう感じたか、そして今後どうすれば良いと思ったか、について備忘録を兼ねて書きます。引用している自分のツイートの中には若干愚痴っぽくなっていて見苦しいところもありますが、その時のリアルな感情・感想ということでご容赦ください。

まずは、何が起きたかとどう感じたかを時系列でざっくりとまとめます。

  • 障害当日の11時頃に「はてなスターカウンター」をリリースしました。ここからホッテントリに一瞬入るまでの拡散の仕方は前述の通りです。

  • Herokuの障害発生について知ったのはTwitterで、AWSに障害が起きたっぽいこと、Herokuアプリ（サイト）に接続しづらくなっていること、などHerokuユーザーのツイートが自分のタイムラインに流れてきました。この時点で、自分が公開・運用していた4つのHerokuアプリはどれも正常動作しているように見え、少なくとも各HerokuアプリのWebサイトへはすべて接続できました。なので、障害は一部の環境だけに起きているものではないかとこの時は思っていました。

  • 自分が公開しているHerokuアプリ、特に公開初日の「はてなスターカウンター」のサイトを結構な頻度でチェックしていましたが、この時間帯になって接続しづらくなりました。アクセスできたとしてもHTMLはなんとか読み込めるけど、画像が最後まで読み込まれないような状態が続きました。このときはまだ、herokuコマンドによるアクセスは可能で、DBファイルのダウンロードなどは可能でした。

  • はてなスターカウンター以外の自分のHerokuアプリ（サイト）にも接続しづらいことを確認し、さらにherokuコマンドによるデプロイやDBへの接続に失敗するようになったことで、それがAWSの障害によるアクセス不能であることをちゃんと理解しました。ここに至るまではすぐ直るだろうと想像していました。

  • 自分のHerokuアプリへの接続がしづらくなってから3時間ほど経過しました。接続しづらいというより、ほとんど出来ないに近かったです。この時点で既に「障害時間が長い」と感じていました。まさかこれの約20倍の障害時間になるとはこの時知る由もなかったのです…

  • 前述のとおり、ホッテントリ入りしたこの時間帯には、はてなスターカウンターのサイトへの接続は不可能になっていました。

  • Twitterのエゴサーチで、はてなスターカウンターサイトの接続不能への不満の声を目撃したのはこのあたりでした。ちなみに「思い」は「重い」の誤字です。

  • 全く改善しそうにもなかったので、改めてTwitter上で謝罪しました。 自分の[ブログ記事](/2011/04/21/hatenastar-counter)にもその旨の謝罪文を掲載しました。

  • 翌日早朝、まだ直ってないことにガッカリして、別のPaaSへの乗り換え検討の愚痴をこぼしたり。

  • さらに愚痴っぽいツイート。「無料で使わせてもらってるから贅沢は言えない」と言っていた障害発生初期の頃の余裕はもう微塵も残っていませんでしたｗ HerokuをHeorkuと打ち間違えている辺りにも余裕の無さが伺えます。

  • ここでようやくサイトへの接続の方は復旧への兆しを見せはじめました。ただし、herokuコマンドによるデプロイやDBへの接続はまだ不可能でした。

  • その日の夜になっても、herokuコマンドによるデプロイやDBへの接続はまだ不可能でした。

  • 自分のHeroku製Twitter Botが障害の影響で動いてなかったことにこの時気づきました。

  • 日付が24日に変わっても、herokuコマンドによるデプロイやDBへの接続はまだ不安定でした。

独自ドメインの重要性

今回遭遇した障害によって経験したことを顧みて「今後どうすべきか」を1つだけ挙げるとしたら、可能性のあるWebアプリなら独自ドメインで運用しておくことだと現時点では思います。この「可能性」は複数の意味を含みます。個人で作った小物Webアプリで、収入の目処も無いのであれば、独自ドメインでの運用はなかなか難しく、実際自分は今までの4つはすべてHerokuのサブドメインのままで公開しています。

ただ、もし独自ドメインで運用していれば、今回の大規模障害により止まってしまった自分のWebアプリを、もっと早く復旧させる方法・選択肢は生まれていました。独自ドメインで運用していなかったので、手も足も出ない状態になったのです。

もし独自ドメインであれば、他のPaaSやVPSに環境をそっくりコピーすることが出来て、DNSの向きをサッと変えることが出来れば、自分のWebアプリを復旧させることが出来たかもしれませんでした。が、独自ドメインで無かったばっかりに、その第1歩でこれらの可能性がすべて潰れました。

また、今回の障害に限らず、アクセスが殺到する可能性があったり、長期的に運用する可能性があるWebアプリの場合は、独自ドメインで運用しておいたほうが、後々何かの対応をするときに、かなり楽になるのではないかと思いました。

例えば自分のWebアプリで言えば、今回のはてなスターカウンターがそれに該当しますが、これは利用してもらうブロガーさんに、はてなスターカウンターへのバナー(URL)を自分のブログに埋め込んでもらう仕組みです。この場合、既にHerokuのサブドメインで運用してしまっていて、利用してもらっているブログにはそのHerouのサブドメインが埋め込まれているので、もうプラットフォームを変えることが出来ません。これがもし独自ドメインで運用してあれば、プラットフォームを変えることもできるという選択肢が生まれます。

考えてみれば当たり前のことですが、今回の障害が発生して色々と振り返ってみてから、自分はこの点について気づきました。

Heroku以外の選択肢

ここでやっと、タイトルにも含まれている「Heroku以外の選択肢」という話に入ります。上述の独自ドメインにする主な理由が、プラットフォームを容易に変更できるようにするためです。ただしこれは、それほどネガティブな意味ではありません。もちろん今回のAWSの大規模障害は利用者にとっては残念な出来事でしたが、これによってクラウドが万能で無いことを気づかせてくれましたし、そのための備えをする意味合いで、他のPaaSにも目を向けるキッカケを与えてくれました。

PaaSに限らず何でもそうですが、1つの環境に依存しすぎてしまうことは、結構リスキーなことなんですよね。例えば、普段使っているネットサービスがGoogleに依存しすぎてしまっていたり、使えるOSがWindows/Macのどちらか一方だけだったり、Adobe製品を使わないと何も作り出せなくなっていたりと、思い当たるフシがいくつもあります。

で、AWSの障害が引き金になったかどうかはわかりませんが、最近やたら他のPaaSの話題を聞くようになりました。前述の引用ツイートの中でも触れているCloud Foundryをはじめ、他にもたとえばDuostackやDotCloudなどです。それ以外にもNode.js用やPHP用のPaaSなども見かけましたが、今挙げた3つはすべてRubyで利用可能です。中でも、Duostackの操作体系はかなりHerokuに似ていて、Herokuユーザーが利用するのはおそらく簡単だろうと@jishihaさんに教えてもらいました。

自分はまだHerokuにドップリ依存していて、他のPaaSもVPSも触ったことがありません。少し前に上述のPaaSへの登録を済ませて、これから触ってみようという段階です。これらを障害対策として考える場合は、そのPaaSが利用しているサービスがAWSかどうかなども考慮する必要がありますが、とりあえずは色々触ってみて使いやすさで考えてみたいですね。今後試したらこのブログにその過程を備忘録していくつもりです。

まとめ

今回のシリーズを通して力説してきたとおり、Herokuはとても便利で魅力的ですが、それしか使えないのは、障害や何かしらの問題が起きたときに対応できる選択肢が無いに等しいことになります。これはHerokuが良い悪いの話ではなく、使う側の問題です。これからHerokuでWebアプリ開発を始めよう、という段階であればまだ意識する必要はありませんが、今回の大規模障害があったことからもわかるように、他の選択肢を考慮することはいずれ考えなければならないことです。Herokuを使うことでPaaSというものをある程度理解できたら、他のPaaSやPaaS以外の環境も触ってみて、できれば障害時の対策まで出来るようになるといいなぁという自戒を込めたエントリーでした。

今回は、Herokuはとても便利だけど依存しすぎてしまうとちょっと危険だよ、という実体験と、その対策として他のPaaSも視野に入れたいことについて書きました。次回は最終回、自分がこれまでのHerokuアプリを作成した上で参考になったサイトやページのリンク集を載せたいと思います。