その後、現行レプリカサーバーの停止、新プロキシサーバーへの切り替えという作業も行う計画だった。しかし、この間もユーザーのEメールの送受信は行われており、移行途中の段階で現行プロキシサーバーが現行レプリカサーバーにユーザー認証の問い合わせを行った際に、マスターサーバーとユーザー情報が一致せず、一部ユーザーのメール利用でエラーが返ってきた(1回目の障害)。

この時、手順書に記載されたコマンドに誤りがあり、現行レプリカサーバーが新マスターサーバーに接続する状態にあったという。このコマンドのミスによって、ユーザー情報が一部欠損し、新ユーザーサーバーと現行レプリカサーバーの情報が一致しなくなってしまっていた。ただ、この時点ではその原因は判明しておらず、新マスターサーバーへの移行、新レプリカサーバーへの接続でエラーが発生しなくなったため、その移行作業を続行し、最初の障害は復旧した。

手順書のコマンドが誤っており、最初の障害が発生

その後新マスターサーバー、新レプリカサーバーへの移行を終え、プロキシサーバーを新規設備に切り替えていた際に、作業途中でタイムアウトエラーが発生。このエラーは予期していなかったため、新バージョンへの移行を中止し、現行サーバーへ戻すことにした。ただ、1回目の障害で現行レプリカサーバーの情報不一致が発生していたため、現行マスターサーバーに切り戻しを行おうとした。

しかし、その作業中に新レプリカサーバーのディスクコントローラーの障害が発生してサーバーが停止。作業時は2重化されていた新レプリカサーバーだったが、ハードウェア障害のダウンによって過負荷となり、もう一方もダウンしてしまう事態に陥った(2回目の障害)。これが4月16日の8時8分だった。

2重化していた新ユーザー認証サーバーが、ハードウェア障害と高負荷で両系ともダウンした

これに対応するため、接続先を現行マスターサーバーへ変更して接続するために、メールBOXサーバーを再起動した。これが13時29分で、この障害からは復旧した。

この時再起動されたメールBOXサーバーは62台。順次再起動が行われ、送受信できなくなっていたEメールの処理が行われていった。当初38台まで順調に処理が行われていたが、残る24台のメールBOXサーバーがメール処理で高負荷の状態になり、さらにiOS端末からのアクセスも急増したため、メール送受信がしづらい状態に陥った(3回目の障害)。

これが13時29分で、当初高負荷サーバーの停止やメモリ割り当て変更などの対応を続けた。だが問題は解消されず、18日ごろには、端末からメールBOXへのトラフィックを調整しはじめた。これによって高負荷状態が解消され、最終的には19日2時54分に障害は復旧したかたちだ。

ハードウェアの古い方の24台のメールBOXサーバーで高負荷状態が続いた

障害の原因と対策

最初の障害は、そもそも手順書に記載されていた作業に問題があった。さらに、机上試験、実験環境での試験も実施していたが、その時には問題が発見できなかった。実際には、本来接続するはずがない現行レプリカサーバーと新マスターサーバーが接続するという事態が発生しており、しかもその問題が把握できなかった。

今後実施する、または実施済みの対策

これについて嶋谷氏は、手順書の記載ミスと事前検証試験の不足を指摘。こうした作業はKDDIとサーバーのベンダーが共同で行うが、お互いの作業チェックの強化に加え、事前検証試験も強化する考え。従来は新環境のみの試験だったが、関連する設備のログを確認するなど、試験対象の範囲を広げる方針だ。今後改めて実施する新ユーザー認証サーバーへの移行に向けてこれらの対策を4月末までに実施する。さらに5月中に社内の全システムに同様の取り組みを実施していくとしている。

2回目の障害は、新レプリカサーバーのハードウェア障害が直接のきっかけだった。本来、レプリカサーバーは4重化して安全性を確保しているが、今回はそのうちの2つでバージョンアップのための作業を実施。2重化しておけば、一方に障害が起きても、もう一方でカバーできると判断していた。

しかし、最初の障害で作業が遅れ、深夜の利用者の少ない時間帯に移行が完了せず、朝8時を回ってしまった。さらに、予想よりも多いトラフィックによって、残るもう一方のレプリカサーバーだけでは処理しきれなくなった。