トップ > 自社ブログサーバを落としてみた

自社ブログサーバを落としてみた

記事タイトルとURLをコピーする
自社のブログサーバを落とした舘岡です。
サーバを落とした翌日は社員の視線が刺さるような感覚がありましたが、最近では「ワイルド」という言葉自体が社内で浸透してきた感があります。
つまり、ほとぼりは冷めたという事です。
これは上級社会人の『問題を寝かせる』という高等技術が成せる業で、僕くらいの使い手になると
"問題があったかどうか思い出せない"までコントロールする事が可能になります。
ただ、術者の僕さえも思い出せなくなってしまいそうな気がしたので、当日に起きた事と対応(してくれた方ありがとう)を記録して今後について考えたいと思います。

起きたこと

当社技術ブログサーバへHTTPアクセスが集中し、高負荷で接続しづらい状態になった

当時の様子

H_Shinonomeさんが当時のTwitterでの様子をまとめて下さいました。

時系列

4月11日 15:20頃

技術ブログを書き終えてTwitterへブログを書いた旨を告知

同日 15:28

予想外のアクセス増
ブログサーバを監視しているサーバからhttp監視失敗(タイムアウト)の警告
同時間のLoadAverageは61を記録、Wordpressからレスポンスが超絶遅くなる

同日 15:40頃

m1.smallの限界を感じてm1.mediumへスケールアップ(32bitのため)
若干の改善は見られるが時間が経過するごとに次第にレスポンスが遅くなる

同日 16:00頃

外出の予定があったので舘岡は会社を離脱
その後、18:00頃までLoadAverageが10付近をうろちょろ

同日 19:00頃

アクセスが落ち着いてLoadAverageが1以下になる。
ページも正常に表示されたので復旧宣言。

原因

  1. 舘岡の影響力を会社側が甘く見積もっていた
  2. 自分の影響力を自分が甘く見積もっていた
  3. 想定を超えるアクセス数に準備が出来ていなかった
  4. Wordpress、及びミドルウェアのチューニングが甘かった

対応

僕がアワアワしたりタバコを吸っている間に色々と対応してくれました。
当社のエンジニアは手が早いです。

1. スケールアップ

ブログサーバはm1.small(32bit)で稼働していましたが、応答がなくなってすぐにm1.medium(32bit)にスケールアップしました。
しかし、それも時間の問題。
すぐに負荷が高まりレスポンスに時間がかかる状態に戻ってしまいました。

2. MySQL

MySQLはquery_cacheを有効にしました。
しかし、アクセスが多い時間帯に設定変更、反映をさせるのは怖いので少し落ち着いた時間帯に設定を変更しました。
変更した部分は以下。
$ diff -u /etc/my.cnf /etc/my.cnf.bk
--- /etc/my.cnf
+++ /etc/my.cnf.bk
-[mysqld]
-query_cache_limit=1M
-query_cache_min_res_unit=4k
-query_cache_size=24M
-query_cache_type=1
でも、そんなに効果はなかったみたいです。

3. PHP

PHPはapcを有効にしました。
$ diff -u php.ini php.ini.bk
--- php.ini
+++ php.ini.bk
-[apc]
-extension=apc.so

4. Apache

mod_cacheを有効にしました。
変更があまりない画像をキャッシュする事で表示を高速化しています。

5. Wordpress

キャッシュ等のプラグインが導入されていなかったので以下のプラグインを導入しました。
上記の対応でレスポンスがかなり改善されたようです。
残念な事に以前の環境でのレスポンスタイムを計測していなかったので劇的ビフォーアフターの数値は見れません。
ざっくりの数字だと、改善前はレスポンスが1秒〜2秒、改善後は1秒未満という感じです。
ココらへんの性能監視も追加しないといけないですね。

今後の対策

あたかも自分が全て設定したかのように書いていますが、僕は外出してたり、そのまま直帰して家でご飯食べて寝てたりしていたので何も手を動かしていません。
会社のみんなに僕の「カチャカチャカチャ…、ッターン！！」を見せられなかったのがちょっとだけ悔やまれます。
現状は一時的な対処なので、今後はMySQLをRDSに移行するとか、画像ファイルをS3やキャッシュサーバに持たせるとか、64bit化するとか、ELBを入れて容易にスケールアウト出来る構成にするとか、シンガポールで稼働しているので東京(近く)に引っ越すとか、なるべく費用をかけずに高負荷にも耐えられる構成を妄想して楽しんでいます。

まとめ

今回、アクセスを集めた事で会社から褒められるかと思いきやサーバが落ちてしまった事で会社としても「どんな顔をして良いか分からないの」という状態でした。
「笑えば良い思うよ」と喉まで出かかったのですが、上司からの「あなたがクビでも代わりはいるもの」という電波を受信したのでグッと堪えました。
という訳で、僕は半ばネタ担当になっているようなのでこれからもどんどんネタを出してブログサーバが悲鳴をあげる程アクセスを集めたいと思っています。
つまりまったく反省していません。
ウソです。ちょっと反省しています。
【お知らせ】

【AWS re:Invent 2024 をエンジニアブログで振り返ろう】

2024年12月2日 - 12月6日 | ラスベガス（米国）
世界最大の AWS カンファレンス・AWS re:Invent 2024の感動をエンジニアブログで振り返りましょう！

AWS re:Invent 2024のブログ記事を読む

serverworks

"; doc.innerHTML = entry_notice + doc.innerHTML; }
' } }) e.innerHTML = codeBlock; });