Webサービスを運営するときの負荷分散・冗長化のススメ

アクセスは急増してからでは打ち手が限られる

Webサイトというものはアクセスが直線的に伸びていくものではなく、何かをトリガーにしてアクセス数が急増するときがあります。 その急増は一時的なバーストであることもあれば、恒常的にアクセスが増える転機になることもあります。

私が運営する上場企業データベース | 上場企業サーチは、以前に一度だけYahoo! JAPANのトップニュースに関連リンクされたことがあるのですが、 前日以前と比べて数十倍~百倍近いアクセスが半日以上継続し、サービスがダウンする寸前まで追い込まれたことがあります。

ユーザのアクセスが増えることはもちろん嬉しいことですし、特にこの時などは、「ついにYahoo! JAPANに露出した!!!」と正直かなりテンションが上がりましたが、肝心のサービスが維持できなければ元も子もありませんし、期待してアクセスしてくれたユーザにもご迷惑となります。

この時の上場企業サーチは、WebAPサーバとDBサーバを分けていたくらいで、それぞれ1台ずつの構成だったことから、 スケールアウトはその繋ぎ目の設定から始めなければならず、無停止での対応は不可能な状況でした。

そのため、無停止でできるスケールアップの方法でCPU、メモリを増強し、何とかサービスダウンは免れましたが、 高負荷からレスポンスが大きく悪化した状態が続き、かなりのユーザが直前で離脱してしまったものと推測します。

この時の教訓として「アクセスが急増してからでは打ち手が限られる」ということを痛感しました。

インフラ設計はサービスインまでが最初の勝負

実はこの一件が起きる前から、このようなリスクは一応認識はしていたのですが、 インフラの冗長化はシステム設計の中核であり、Webサービスは一旦稼働させてしまうと長時間止めることが難しいことから、 対応を先送りしている間に事が起きてしまった形となります。

一方で、今年の2月から立ち上げたもう一つのサービスであるソーシャル時代の法人情報メディア Social Corporate Data Bank JAPAN | SCDB JAPANは、最初からシステム設計段階での冗長化、柔軟性を強く意識し、 サーバは細かく機能分割し、各機能はクラスタ化したりロードバランサを挟んだりして、スケールアウトしやすい設計を心がけています。 上場企業サーチ.comの一件以来、それまで以上に先行投資を行って対応を進めており、まだ何カ所かSPOF(単一障害点)があるのですが、近いうちにこれらも解消させたいと考えています。

ちなみに、SCDB JAPANを構成するサーバ群は現時点で以下のように「無駄」に11台構成となっています。

  • WebAPサーバ x 2
  • バッチサーバ兼WebAPサーバスタンバイ機 x 1
  • RBDサーバ x 1
  • NoSQLサーバ x 3
  • 検索サーバ x 3
  • 機械学習サーバ x 1

一部を除き、基本的に機能間にはロードバランサを挟んでおり、機能単位でも冗長化・クラスタリングを意識した設計をしています。 また、各サーバのリソース自体も平時でも十分余裕があるように割り当てていますので、おそらくアクセスが100倍になるくらいまではこの構成で耐えられると思っています。

人に言うと笑われるくらい、「超」が付くほどの過剰投資をしていますが、自分のサービスとして運営する以上、メジャーなサイトにしたいという大志もありますし、 個人的な知識欲としても、世の大規模サイトの裏側はどうなっているのだろうかと気になって仕方がないところがありますので、ほとんど趣味の領域です。

おかげで今のところ、2つのWebサービスから入ってくる収入のほとんどはサーバ維持費に消えてしまっていますが、いつか来るであろう(来てほしい)「その日」に備え、インフラだけでなくサービス自体も日々改善・強化していきます。

皆様の訪問、心よりお待ちしております!!