VANA'DIEL』。VANA’DIEL”と題し、『FFXI』の開発に携わった方や、他社クリエイターも含めた関係者のさまざまな証言が映像等で公開された。それらは取材内容のほんの一部にすぎない。ここでは、関係者それぞれが語る“『FFXI』20年の軌跡”を、改めてインタビュー形式でお届けしていこう。その第1回は、『FFXI』や『プレイオンライン』開発時におけるネットワークシステムを統括した伊勢幸一さんへのインタビュー。このパート3では、いよいよ正式サービスを迎えた『FFXI』に降りかかった“初日の大きなトラブル”について、伊勢さんの言葉から詳細をうかがうことができた。当時現場では、どのようなことが起きていたのだろうか。伊勢幸一ネットワーク方面に精通するエンジニア。1996年にスクウェア(当時)に入社し、スクウェアUSAのホノルル・スタジオの立ち上げなどに参加したのち、技術情報部のシニアマネージャーおよびプレイオンラインのサーバーシステムディレクターとして、『FFXI』のネットワークシステムの構築を担当する。2016年より、さくらインターネット株式会社の取締役に就任。『FFXI』は家庭用ゲーム機向けの初の本格的なMMO(多人数同時参加型オンライン)RPGだったので、一般のプレイヤーだけでなく、ISP(インターネットサービスプロバイダー。通信事業社)やインターネット業界の専門家の方々も注目していました。『FFXI』のβテストに触れた彼らが、口々に「インターネットって、こういった使いかたもできたんだ!」、「こういう仮想世界がインターネット上に存在するんだ!」と感動していました。その話を聞いて、私自身も深く感動したのを覚えています。2002年、ついに『FFXI』の正式サービスが開始されます。伊勢あのときは、もう“想定外の連続”でしたね。2002年5月16日、12時のサービス開始直後、2~3時間くらいでまず会員登録ができなくなるという障害が発生しました。この部分のシステムは、スクウェア(当時)の運営事務局が発注した外注メーカーが開発を担当していましたが、認識の齟齬があって組み込みに難航していたのです。そこで、途中から私のほうで引き取ったのですが、開発部分はもうほぼ完了していたので、運用する前に「負荷テストだけは絶対やって!」とだけお願いしました。実際に負荷テストを実施したところ、「1分間に何千件ものトランザクション(※)が可能というデータが出ました」という報告を受けて、「それならOKかな」と思っていたのですが、まずそこが落ちたのです。※トランザクションとは、分割できない作業を集めた処理のこと。ネットショップでの購入時に一部の処理でエラーが発生した場合は、金銭だけが引き落とされることがないように、“失敗時に購入前の状態にすべて戻す処理”を組み入れる。“実際のクレジット会社の決済回線を使い、相手のサーバーにトランザクションを届ける”というシミュレーションができていませんでした。クレジット会社からは「実機を使った負荷テストは、ほかの店舗に迷惑がかかるのでできません」と言われてしまって......。そのため、ダミーのレスポンダー(※)を社内で作成して、リクエストを送ったらすぐOKと返す、そんな簡易的なシミュレーターで負荷試験をしていたのです。※ここでのレスポンダーとは、クレジットカード会社のサーバーを模したテスト用の社内ツールのこと。送信したトランザクションに対して、あらかじめ想定した応答を返す。そこだけは実機でのテストではなかったのですね。それで、正式サービス開始後、実際にクレジットカード会社側のデータベースにトランザクションを登録する処理を実行したときに、処理時間が想定以上にかかり、まずクレジットカード会社側で処理が詰まってしまいました。受信側で詰まってしまったので、私たちのほうで用意していたキューイングシステム(※)側も詰まってしまい、応答不能になってしまったというわけです。※キューイングシステムとは、処理を順番に実行するための待ち行列を、ソフトウェアで実現するシステム。通常は待機していれば徐々に処理が進むが、クレジットカード会社側で処理が滞るとタイムアウトになり、処理がキャンセルされてしまう。待ち行列の長さが設定した上限を超えてしまうと、処理自体を受け付けることができなくなる。結果、サービス開始翌日にあたる5月17日の15時にサービスをいったん停止するというアナウンスがありました。伊勢じつは、登録処理の部分を修正して再開したところ、登録自体はスムーズに進むようになっていました。同時接続が5000人くらいになったときに、今度はゲームサーバーが落ちてしまったのです。それでサービスをいったん停止したのですが、理由はその時点ではまったくわかっていませんでした。ゲームサーバーが最初に落ちたのは、サービスを停止する13時間前、5月17日の深夜2時ごろだったようですね。伊勢データセンターまで行って、サーバーの状態をコンソール(※)につなげて調べたところ、サーバー自身がインターフェース(※)を落としているということがわかりました。して根本原因はわからず、全サーバーをとりあえず再起動させましたが、また数時間で落ちたのです。※コンソールとは、サーバーにつながっているディスプレイのこと。通常はスクウェア社内からリモートで状況を確認できるが、インターフェースが落ちていたため通信ができず、現地のサーバーの状態を直接確認する必要があったと思われる。※インターフェースとは、サーバーのネットワーク機能またはネットワーク関連のパーツのこと。インタフェースが落ちるということは、そのインターフェースを使った通信がまったくできなくなることを意味する。サービス開始から3日目の朝、5月18日の全国紙の朝刊には、謝罪広告も掲載されました。この時点で、最初のゲームサーバー停止から40時間近くが経過していた形になります。私はまた現地に飛んで、データセンター部隊とオフィス部隊で原因を調べていたのですが、やはりわからなくて......。そのときに、サーバーのメインプログラマーだった木村(木村正明氏。元『FFXI』エリアサーバープログラマー)がやって来て、彼に「伊勢さんね、βテストでは同時接続5000人でちゃんと動いていた」、「本番環境で落ちているのも、だいたい5000人くらい。βテストから本番で何か変えたことありますか?」と言われたのです。そこでメンバーと顔を見合わせて「あーっ!」と気づいたんですね。直接の原因は何だったのでしょうか。伊勢じつは、βテストから本番環境に移す前に、セキュリティー強化のため、スイッチ(※)のアクセスフィルター(※)のリストを増やしていました。ゲームの通信とそれ以外のWebやサポート関連の通信を別々のアウトゴーイング(※)から出ていくように設定変更して、ゲームのトラフィックに影響を及ぼさないように変更していたのです。※スイッチとは、サーバーなどと接続し、通信を司るネットワーク機器のこと。※アクセスフィルターとは、送信元、送信先や通信の内容により、通信を許可または遮断するネットワーク機器の機能のこと。スイッチにもCPUが搭載されており、設定量が多いとCPUに負荷がかかる。※アウトゴーイングとは、外向き(この場合は『FFXI』のシステム外へ)の通信経路のこと。重要度が高いシステムほど、用途に応じて通信経路を細かく設計する傾向にある。特定の通信が予期せず多量になった場合に、通信経路を分けておくことで他の通信への影響を軽減することができる。具体的にはそれがどう作用したのでしょうか。伊勢アクセスリストを多量につけて、負荷が高くなり処理しきれなくなったスイッチが、“自分で自分を再起動する”ということをしていました。スイッチは落ちたら落ちたままになっていれば問題なかったのですが、当時のスイッチは落ちたら再起動して、待機系になっていた状態から正系(※)に戻ろうとする動きをしたんですね。再起動をしても根本的な原因が解決していないので、また再起動して、復帰して、また再起動して......をくり返してしまっていました。その結果、サーバー側がスイッチと再接続するために、ARPプロトコル(※)のパケットを数百台のサーバーから出していて、それをくり返したのでストーム(※)が発生していたのです。ストームが発生すると莫大なパケットがネットワーク内を流れるため、サーバーの処理負荷が非常に高まり、サーバーが自分自身でインターフェースをダウンして、サーバー全体が落ちる、という動作になっていました。それが2回目のダウンでやっと判明した、というわけです。※正系とは、現在サービスを提供している機材一式のことを示す。正系と同様の構成の予備機材が待機系として一式以上あり、問題があった時に正系と切り替えることで、短い時間でサービスを再開することができる。それが「落ちたら落ちたままになっていれば問題ない」の理由でもある。※ARP(アープ)プロトコルとは、ほかの機器との通信に必要な情報を、同じネットワーク内の機器すべてに確認する動きをする処理。※ストームとは、ブロードキャストストームという現象のこと。ネットワークの不適切な設定や接続等で発生する場合があり、大量の通信パケットがネットワーク内に発生する。ネットワークが不安定になり、サーバーやネットワーク機器などが予期せぬ動作をすることがあるため、システムにとって危険な状態である。サービス開始から50時間近く経過して、やっと光が見えてきたのですね。根本原因がはっきりしたので、設定をもとに戻しつつ、アクセスリストの処理を1台で行うのではなく、複数の段階に分けて負荷を分散する設定に変更して、再度稼働することができました。いまでも覚えているのですが、サービス開始から稼働し始めるまで65時間(※)かかっているんですね。このあいだはもう、ほぼ地獄でしたね。私も座りながら寝ている状態で、布団の上ではいっさい寝られなかったですし、もちろん家にも帰れませんでした。テーブルに座っての食事もできなかった時間帯が65時間続き、これはまさに想定外でしたね......。※断続的に続いたメンテナンスは、サービス開始からじつに80時間が経過した5月19日の20時に完了する。未明に発生した、予期せぬ全サーバー停止を起点としているとみられる。注目作のサービス開始直後におけるトラブルは、あってはならないものですが、さまざまなオンラインサービスを経験している現在のプレイヤーにとっては、「そういうこともある」と把握している部分もあるかと思います。『FFXI』のときはプレイヤーや開発者、ネットワーク管理者にとって、初めての経験だったのではないでしょうか。伊勢でも怪我の功名といいますか、あの“65時間の死闘”を経験したことで、オンラインサービスにおけるシステム設計や運用のノウハウなどを一気に会得しました。それ以降、少なくとも私が『FFXI』のネットワークを統括していたあいだは、大きなトラブルは起こしていません。『FFXI』は2003年に北米版が発売されていますが、そのときも問題はありませんでしたか?伊勢はい。日本で正式サービスを開始したときは、その日時をキッチリと決めていたのが大混雑を招く一因となっていました。北米版のサービス開始時は、「北米向けにパッケージの販売を開始します」というアナウンスだけを行って、実際にパッケージを手に取った人から順次ログインしてもらう形式にしたのです。このおかげで、システムに極端に大きな負担を掛けずに済みました。スケールアウトしやすい構成にしていましたし、集約スイッチやボーダールータも冗長構成(※)を採っていたため、基本的にはサービスをほぼ停止することなく拡張できた形になります。※冗長構成とは、ひとつのシステムを正系と待機系で構成し、片方が停止してもサービスに影響を及ぼさないようにすること。ハードウェアの増強などは機器を停止して実施することが多いため、正系と待機系を切り替え、サービスを止めずに段階的に作業を進めることが一般的である。伊勢さんは、プレイオンラインの最大同時接続者数を25万人で想定していたとおっしゃられていました(パート2参照)。『FFXI』の最多同接続者数は約20万人とのことなので、この部分もおおむね想定内だったというわけですね。正式サービスの開始直後を除けば、『FFXI』は“初めてのMMORPG”だったわりに、比較的スムーズにネットワークシステムを構築できました。その後も大規模アップデートを行ったり、老朽化したデバイスを切り替えたりといった対応を行いつつ、ユーザー数の拡大などに応じて順調にスケールアップさせていきました。想定外の作業もそれほど発生しなかったので、その後にプレイオンラインの対応タイトルが順次追加されるときも、順調に作業できたと思います。