soutaroにっき このページをアンテナに追加

2012-02-10

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

01:59 |

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

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


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

f:id:soutaro:20120211011617p:image

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

その直後。

f:id:soutaro:20120211011619p:image

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

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

さてどうしたものか。

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

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

Twitter

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

ちなみにこの辺りで、ちょっと勢いで注文したうまい棒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を確認したところ、売上データに問題はなかった模様。まあ、今後、お客様から指摘されることがあるかもしれないので、まだまだ不安な時間は続きますが。


あとまあ、こんな

f:id:soutaro:20120211015747p:image

感じ

f:id:soutaro:20120211015748p:image

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


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

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

uu59uu59 2012/02/11 05:44 http://blog.uu59.org/2012-02-11-ubiregi-optimize.html
対応お疲れ様でした。
後の祭り感はありますが、Apacheの設定で気になったとこがあったのでまとめてみました。
お暇な時にでも参考にしていただければ幸いです。

mekkoomekkoo 2012/02/11 06:49 https://www.cloudflare.com/ このCloudFlareのような無料のCDNを挟むとよかったかもしれませんね。サイト本体のコンテンツを自動でキャッシュし、再配信してくれます。

トラックバック - http://d.hatena.ne.jp/soutaro/20120210/1328893174