インターネットちょっと舐めてたわ

こういうことがありました。つまりYahoo!のトップページにユビレジへのリンクを含む記事が掲載されたということです(当初リンクがありましたが、サーバに全くアクセスできなくなって、消されました)。これはめでたい!でもめでたくない!なぜならサーバが落ちるから!やべえ!!!

というわけで、当時、つながらないubiregi.com、頻出する謎の鳥の裏でどうなってたのかという話をちょっとしたいと思います。


第一報は11時過ぎだったと思います。社長の木戸からLingrにこんなメッセージが。

あれー変だなー。でも昨日もなんかロードアベレージすごい上がってたんだよなーさくらのVPSなんだけどクラウドに続いてハードウェアとかやばいのかなーまいったなーとか思いながら、確認します。うん。表示されない。

その直後。

とりあえずSkypeしましょうか。という流れ。まあSkypeしてもしょうがないのですが。状況の確認。電話ってお客さんからの苦情かなーとか。

ひとまず、Apacheをstopしてから、$ cap production deploy:web:disableとかやって、これ以上状況が悪化するのを防ぎます。無事siableできた直後にenable。ちょうど直前にassets pipelineが上手くいかない原因を探るためSSH繋いでいたのですが、多分、良かった(今後、SSHできなくなったりする状況が断続的に発生します)。

さてどうしたものか。

ひとまず、メンテナンス画面にはTwitterへ誘導するリンクが付けてあるので、そちらにアクセス過多でダウンしている旨を書き込みます。

現在アクセスが集中しており、サーバの動作が不安定になっております。ご迷惑をおかけしますが、ご了承ください。

Welcome to Twitter - Login or Sign up

慌てていたので気づきませんでしたが、これ真っ赤な嘘です。「不安定」どころの話じゃなくて、アクセスできません。

ちなみにこの辺りで、ちょっと勢いで注文したうまい棒3000円分が届いていました。さすがに荷物をあらためてる余裕なんかなくて(昼飯も食べてない)、やることが無かったデザイナの子に受け取ってもらっていたので、何が届いたのか知ったのはちょっと落ちついた午後4時くらいの時点でした。ものすごいタイミングだった。


次に考えなくてはいけないのは3つです。

  1. Yahoo!を見てubiregi.comにアクセスする人をどうするのか
  2. 売上を確認しようとしてユビレジにアクセスしてきた人をどうするのか
  3. ユビレジアプリが送信しようとしている売上データをどうするのか

1についてなのですが、Herokuかどこかに急いでWebサーバをデプロイすればなんとかなりそうです。すぐやってみる。

2については、もうちょっとどうしようもないので諦めてもらう。

3については、クライアントにキャッシュしておく機能があるので、そこまで深刻な問題ではないけど、キャッシュ機能がそこまで信用できるものではないこともまた我々は知っており。できるだけ早く回復しないといけません。

ではまず1から。

Ubiregi.comへのアクセスを、急遽Herokuにデプロイしたアプリに誘導するという案を考えました。これで、サインアップ・ログインのときだけubiregi.comに戻すという案。Yahoo!からのアクセスが来るURLはわかっていたので(https://ubiregi.com/ja)そこへのアクセスをmod_rewriteとかで転送してあげれば良いでしょう。Go!

→ db:migrateに失敗して、assets pipelineの設定に失敗して、とにかく上手くいきませんでしたorz


まあそんなこんなで(めんどくさくなった)いろいろ試しました。

ちなみに通常一桁前半のロードアベレージは一時期100を越えましたし、Apache2のプロセスは50くらいいましたし、SSHで接続すらできずにVPSの管理コンソールからリセットを3回くらいやりましたし*1MySQLに接続できずにエラーメールが3000通くらい届きました(事態が収束したあと)。


結局、効果があったであろう物として、次のような対処を行いました。

  1. Apache2のプロセスが多すぎるので、MaxClientsをデフォルトの150から50に減らして、オペレーションが継続できるようにする(ちなみにApacheの終了に10分くらいかかっていたのが、このときです。)
  2. API経由のアクセスはURLでわかるので、そこだけ有効にする(mod_rewriteを使います)
  3. /jaへのアクセスは、Twitterアカウントへ転送する

これが上手くいったので、次にログイン、サインアップの機能を有効化します。

  1. $ cap production deploy:web:enableする

これで、急増したアクセスの殆どを占めるであろうトップページへのアクセスはTwitterへ逃がしつつ、通常のWebアプリの機能は復活します。→やってみたら上手くいきました。

じゃあと調子にのって/jaからの転送を止めると、またSSHログインができなくなる……ちなみに、この方法を確立(?)してからの流れは、収束するまでこれの繰り返しです。

ちなみに落ち着いたのは、午後6時すぎくらいでした。

まとめというか教訓というか

  • さっさとHerokuとかモダンなクラウド環境に移行するべき
  • 「利用者の増加は緩やか」という予測を持っていたとしても、こういう突発的なアクセス増があることを理解しておくべき
  • Wordpressはよくできてる

1番目はまあ良いと思います。はやくやろう。

2番目は、これが甘かった点で、ユビレジというのはサービスの性質上、利用者の増加は緩やかであると推測していましたし、ここまでのところそうでした。緩やかというのは、ローンチ直後から何万というユーザーを集める必要がないという意味です。利用者がじわじわ増えていくなかで、適当なタイミングでスケールアップなりなんなりの対策を打てば良いと思っていた。こういう急激なアクセス増があるというのは想定していませんでした。インターネットの恐しさを知りました。

3番目については、まあ余談。せめてアクセスを減らそうと、これまで同じサーバで運用していたWordpressのブログを、途中で別のサーバに移しました。これが、まったく効果なし(苦笑)。Wordpress良くできてるわーと実感しました。


ちなみに不安だったiPadアプリのキャッシュ機能についてですが、ざっとlogを確認したところ、売上データに問題はなかった模様。まあ、今後、お客様から指摘されることがあるかもしれないので、まだまだ不安な時間は続きますが。


あとまあ、こんな

感じ

だったので、まあちょっと自慢気な気分ではあります。サーバにはアクセスできなかったけど。


いやー、数時間ですけど興奮してたので、とても疲れました。夕方以降、俺なんも仕事してないわ。

*1:topしておいた端末がなんか静かだなーと思ったら固まってたりしました