こういう状況の話です
特定の時間にアクセスが集中して、サービスが遅くなる、あるいはつながらない。
集中には2つの型があります。
- 毎日繰り返す山 — 決まった時刻に利用が集中する。業務の性質上、その時間に使われることが決まっている
- 一度きりの大きな山 — リリース、CM 放映、メンテナンス明け、アップデートの配布開始
性質は違いますが、どちらも「いつ来るか」が分かっています。突発と呼ばれるものの多くは、実際には予測できる山です。ここが手の打ちどころになります。
詰まる場所は、だいたい決まっている
経験上、最初に詰まる場所はかなり絞られます。
- 配布物のダウンロードが集中する場合 — ネットワークが詰まる
- メモリが上限に当たる場合 — プロセスそのものが動作しなくなる
- それ以外 — 大半はデータベースです
メモリだけは出方が違います。ほかが「遅くなる」形で現れるのに対し、メモリはプロセスが落ちて止まる形で出ます。少しずつ重くなっていく兆候が無いまま、いきなり応答しなくなることがあります。
同じことは、コスト削減でインスタンスを小さくしすぎたときにも起きます（クラウドの請求額が上がってきたとき、削る前にやること）。上限に当たって止まるという点では、原因が集中でも削りすぎでも同じです。
アプリケーションの CPU が先に限界に来ることは、現在のハードウェア性能ではあまりありません。CPU がボトルネックになるのは、サービス系よりもレンダリングのようなバッチ処理のほうです。
増やしやすいところから増やしても効かないのは、詰まっているのがそこではないからです。
詰まりは、直すと次が出てくる
あるサービスの立ち上げ時に、こういう詰まり方が起きました。当社の案件ではなく、代表が過去に立ち会ったものです。
- 登録用の Web サイトに接続できない — ユーザー認証用データベースの負荷が原因
- 入口を絞り、通過した人だけ登録を進め、残りは待機画面に回す
- 登録できた人が、今度は次の初期設定の画面で重くなりエラーになる — サービス本体のデータベースの負荷が原因
- 初期設定が終わっても、サービス本体に入れない — サービス本体のデータベースの負荷が原因
- 入れたとしても、遅くて操作にならない — サービス本体のデータベースの負荷が原因
手前を直すと、次の段が詰まります。 利用者が先に進めるようになるほど、その先の負荷が顕在化するためです。最初の1箇所だけを見て「直った」と判断できません。
このときに採った手は、次の順でした。
- 入口で通す数を減らし、まず一つ一つの作業を最後まで終わらせる
- 並行して原因を特定し、徐々に改善していく
- リソースが不足していることが確認されたサーバーを追加する
全員を同時に速くしようとしない、というのが要点です。入口を絞るのは、一見サービスを止める行為に見えますが、実際には全員が中途半端に進んで誰も完了できない状態を避けるための判断です。中に入れた人が最後まで終われるなら、時間はかかりますが、待っている人にも順番が回ります。
サーバーを増やす前に、山そのものを崩せないか
ここが本題です。
インストールして使うタイプのゲームでは、アップデートパッチの配布開始時に極端なトラフィックが流れます。この事例も、先ほどと同じく当社の案件ではありません。 打った手は2種類ありました。
技術的な手
- CDN を使い、配信をサーバーから切り離す
技術ではない手
- ダウンロード自体は早めに開始できるようにし、サーバーのオープンは遅らせる
後者が効きます。同じ人数が来るとしても、全員が同じ瞬間に来なければ、山は低くなります。必要な規模はそのまま下がり、費用も下がります。
これは技術の問題ではなく、運用と告知の設計の問題です。いつ開けるか、いつから配り始めるか、どの順で案内するか。ここを動かせる場面は、思っているより多くあります。
集中は動かせない条件ではありません。 山の高さは、こちらの都合である程度決められます。
もちろん動かせない場合もあります。冒頭に挙げた「毎日繰り返す山」は、業務の時間そのものが決まっているため、時刻をずらすことはできません。その場合は正面から性能を改善します。動かせるかどうかを先に確かめる、という順番の話です。
どこまで備えるか
正直に言えば、どこまで備えるかは基本的に予算で決まります。どのようなビジネスでも、青天井には備えられません。
だからこそ、順番が必要です。
- 費用をかけずに仕組みで回避できないかを、可能な限り徹底する
- その上で、残った分に予算を当てる
逆にすると、お金をかけたのに山が想定を超えて落ちるか、山に備えて常時大きく構え、来ない日も費用が出続けるか、どちらかの失敗になります。
まず確認できること
- 自社のアクセスの山が、毎日繰り返す型か、一度きりの型かを見る
- その山がいつ来るかを調べる。「突発」と思っているものが、実は予測できないか確かめる
- その時刻を動かせないかを考える。告知の順、開始時刻、事前の配布など
- 詰まったとき最初に音を上げるのがどこか（たいていデータベース）に、平常時から見当をつけておく
- 入口で絞る仕組みがあるか。全員が中途半端に進む状態が、いちばん復旧しにくい
規模を拡大するのは、これらを終えたあとです。この順番を守ると、同じ予算で耐えられる山が高くなります。