ゲームやニュース、小説、SNS（Social Networking Service）機能などを提供する携帯電話向け総合ポータルサイト「モバゲータウン」（以下モバゲー）。2009年夏にサービスインしたゲームが人気を集め、システム担当者としては『綱渡り』のような毎日が続いた。
前回，機器の変更などを行う際の事前準備について説明した。細心の注意を払って準備していたが，それでもアクシデントは起こった。今回はネットワークスイッチのコンフィグレーションを変更する際に直面したトラブルの模様を説明する。
無停止でスイッチのコンフィグレーションを変更
2010年1月12日。この日はスイッチのコンフィグレーションを変更する作業の日であった。一連の増強策によりネットワークパスのバランスが悪くなっていたので，VLANの設定を変えてバランスを整える（図1、図2）。
サービスを停止して作業すれば比較的簡単だが、今回はサービスを停止することなくパスを変更する。具体的には、パスの重みを変更することで、特定のパスにパケットが流れないようにして物理的な配線を変更する、といった作業を繰り返す。こうした作業のうち，一時的にネットワークパスが1本になるときがあり，その時間帯がトラフィックの比較的少ない15時ごろになるよう計画を立てていた。
「ロードバランサーがフェイルオーバーした」
現場担当者は4人で，朝の9時から作業に当たっていた。筆者は、現場を担当者に任せて外出していた。「そろそろ作業も終盤だな」と思った矢先、アラートメールが届いた。17時35分のことだ。運用監視ツールから自動発信されたメールで、しきい値を超えていることを知らせる内容だった。「スイッチの負荷が急激に重くなった」ことを知らせてきた。
続けてメールが届いた。「ロードバランサーがフェイルオーバーした」との内容だ。さらに、続けて同じ内容のメールが届いた。フェイルオーバーを2回したことになる。作業で何か問題が発生したのは間違いない。悪い予感を抱きながら、筆者は作業中の現場担当者に連絡を入れた。
現場は一時的に混乱していたようだが、電話をしたときは落ち着きを取り戻していた。「（全部で5ステップある作業のうち）4ステップ目の作業を行った直後、突然スイッチの負荷が重くなった」という。予期しないことだった。ただ、「今は正常な状態です」とのこと。どうやら、スイッチは一度ダウンして再起動し、正常な状態に戻ったようである。
スイッチが高負荷になったということは、一時的に通信が途絶えたかパケットをフォワードするのに通常よりも時間がかかった可能性がある。ロードバランサーはこのスイッチと直接つながっている。ロードバランサーはポートのアップリンクポート数を基にコスト値を計算してマスター昇格を決める設定になっているので、コアスイッチの異常によりリンクダウンが検出された結果、フェイルオーバーが起こった。
フェイルオーバーはうまく機能したが、スイッチの高負荷が解消されたタイミングでポートのリンク状態が正常に戻り2度目のフェイルオーバーになった(元のマスター側に戻った)。2度目のフェイルオーバーが完了した時点でこの問題は収束した。こう考えるとつじつまが合う。
この間、サービスが一時的に接続しづらい状況になってしまったが、数秒のことで影響を受けた利用者は一部に限られた。避けなければならないことだが、最小限の影響で済んだのは不幸中の幸いだった。
「このまま続けてはいけない。元に戻そう」
問題はこの後だった。スイッチはクラスタリング構成を取っており、先にスタンバイ側の機器のコンフィグレーションを変更し、その後、アクティブ側の機器のコンフィグレーションを変更する。先のトラブルはスタンバイ側のコンフィグレーションを変更したときに起こっており、正常に戻ったとはいえ、このままの状態で運用するわけにはいかない。
このとき、スイッチが異常な状態になった原因は不明である。アクティブ側でも同じことが発生するかもしれないし、スタンバイ側の機器だけの問題とも考えられる。だが、VLANのバランス調整はいずれ実施しなければならない。そうしなければ、負荷に耐えられなくなる。リスクは小さくないが、作業の続行を決断した。アクティブ側のコンフィグレーションも変更することにした。
いざコンフィグレーションの変更を行うと、スタンバイと同じことが起こってしまった。スイッチの負荷が異常に高まり、ロードバランサーにも影響が及んだ。症状も同じだった。スタンバイ機だけの問題ではなく、問題の再現性を確認できたことになる。「このまま続けてはいけない。元に戻そう」と指示を出した。
アクセスピークの前に作業を終えなければ…
元に戻すのは時間との闘いだった。このとき18時ごろで、アクセス数が徐々に増えてくる時間である。ピークの時間に不具合が発生すると影響が大きくなるので、その時間には作業をしないルールにしている。
アクセスピークは21時～24時。急がねばならない。作業を1段階戻した。だが、この状態はパスが最も少ない状態で、ピークに耐えられない。さらにもう1段階戻すことにした。2段階戻したパスの状態でピークを乗り越えられることを確認し、作業を中断した。
残りはアクセスピークを過ぎた後の作業になる。担当者は自宅に戻ることもできず、ピークを過ぎた午前2時ごろ、元に戻す作業を再開し、午前3時ごろ最初の状態に戻すことに成功した。
息をつく間もなく、スイッチメーカーに原因を問い合わせた。すでに日は変わり1月13日になっている。その翌々日の15日、回答があった。「似たような症状が報告されています。おそらく、これかと思われます」とのことだった。
その症状の原因は、スイッチのファームウェアのバグ。パスの数が一定数以上になると発生するとのことだ。確かに、今回問題が起こった作業は、パスの数が一番多くなる作業であった。
ファームウェアを変更するには30分くらいのサービス停止が必要になる。できるだけサービスを停止したくない。迷ったあげく、ファームウェアのバージョンアップはしないことにした。問題が発生しないパス数になるよう再設計した。
これで、当面のトラフィックは乗り切れるはずである。新たなパス設計に基づいて作業手順を見直し、1月25日、作業を行った。問題は起こらなかった。すべての問題はクリアしていないが、当面の危機は去った。
ディー・エヌ・エー システム統括本部 IT基盤部 部長
