Webサービスの障害対応を終えて、、、

f:id:boost-up:20180124130503j:plain

暫く更新が滞ってしまいました。

前回の記事で、SCDB JAPANに年末からBingクローラーのアクセスが急増し始めた事と、それによってRedisに障害が起きたことを書きました。

blog.boost-up.net

Redisの障害は正月のうちに何とか対応を終えたのですが、その後もBingクローラーのアクセスは増え続け、日に20万アクセスを超えるようになりました。

クローラーのアクセスが増えることは、将来的にサーチエンジン経由での流入に繋がる可能性が高いので、基本的に嬉しいのですが、 実は年明けにRedisの件の他にもう1件、原因不明の障害が発生し、つい先日まで対応にかかりきりになっていました。

今回の障害は2台で負荷分散しているWebサーバがほぼ同時に通信を受け付けなくなるというもので、 障害が発生するとhttpだけでなくsshも受け付けなくなります。 他方、pingは通りますし、サーバ自体は活きておき、クラウドサービスのコンソール経由ではログインも出来ます。 tcpコネクションやローカルポートの枯渇も疑いましたがこちらは問題なさそうです。

困ったのは各サービスのログにもOSのログにも、それらしいエラーが何も記録されていないことでした。

決して負荷が高くないときでも2台が同時に通信不能となることから、Webサーバ側ではなく、ネットワーク周りかバックエンドのDBサーバ側に問題がある可能性も疑われる状況です。

ただ、バックエンドのサーバの多くは上場企業サーチと共有しているのですが、その上場企業サーチにはまったく影響が出ていないため、バックエンド側の可能性は低いと思われました。

それでも一応一通り各サーバのログは調べたところ、障害発生時に一回だけ、DB側との接続が切れたログがありました。

そこで、SCDB JAPANと上場企業サーチのDB接続周りの設定を比べたところ、1箇所だけ異なる点が見つかりました。

上場企業サーチはDBサーバに直接繋ぎに行くようになっている一方、SCDB JAPANは冗長化を試行錯誤する過程で、仮想ルータのロードバランサを経由してDBに繋ぎ行くようになっているのですが、改めて見るとグローバルIPを指定してしまっています。 本来なら内部ロードバランスには仮想ルータのプライベートIPを指定すべきなのかもしれません。

そこで、上場企業サーチと同じように直接接続に戻して再起動をかけたところ、めでたく現象が発生しなくなりました。

上場企業サーチに影響が出なかった理由は継続調査中ですが、何とか年末から続いていたゴタゴタも収束しました。 怪我の功名でサービスの安定性も向上させることができ、ワンステージ上のトラフィックにも対応できる体制が整ったと信じています。

今年こそはサービスの成長と躍進に向けて進んでいきたいと思います。

日々勝負