『シノアリス』リリース当初に発生した“あの連続メンテナンス”の裏で行われていたこととは？【CEDEC2018】

『シノアリス』連続メンテナンスの裏側 2018年8月22日より開催されている、ゲーム開発者向けカンファレンス“CEDEC 2018”。 ここでは、本イベントにて講演されたポケラボによるセッション“SINoALICE -シノアリス- それは最高の「未曾有アクセス」”のリポートを行っていく。 問題となった5つの事象 本講演で登壇したのは、株式会社ポケラボの覚張泰幸氏。覚張氏は2013年の入社から、エンジニアとして『戦乱の侍キングダム』や未リリースの新規アクションRPGなどに参画。今回の公演で扱うタイトルの『SINoALICE ―シノアリス―』（以下、『シノアリス』）にも、エンジニアリーダーとして携わっているという。 覚張氏はまず、大きな話題ともなった『シノアリス』リリース当時に発生した連続メンテナンスについて、対応に当たった当事者として説明を行った。 なお、連続メンテナンスの概要はつぎの通りである。『シノアリス』はリリース後間もなく緊急メンテナンスを開始。翌日には一時的にメンテナンスから脱するも、数時間後には再度メンテナンスに入るという状態が1週間も近く続いていた。 覚張氏はこうした当時の様子をより具体的に紹介するため、メンテナンスが行われたスケジュール表を公開。その内容はというと、ほとんどがメンテナンスを示す赤色になっており、これには思わず来場者からも笑い声が溢れた。 こうした連続メンテナンスを引き起こした要因には、未曽有のアクセスがあったということだが、ではその裏ではエンジニアたちは何を行っていたのだろう？ 覚張氏は続けてこの部分を語ってくれた。曰く、ポイントとなる事象は“見積り”、“CDN Quota”、“Varnish導入”、“AWS instance”、“追加 Sharding”の5つだという。 見積りを大きく上回る同時接続 ひとつ目の“見積り”という事象については、そもそもこの未曽有のアクセスが完全に想定外の出来事であったことに由来する。開発チームは、過去にリリースしてきたタイトルの事前登録者数とリリース時の流入量という知見をもとに、『シノアリス』も初日は10万人ほどの同時接続数と予想していたとのことだが、配信開始時の同接数はその10倍であり、これがサーバーダウンを引き起こした最大の要因であったという。 このときのDAU（デイリー・アクティブ・ユーザー数）は、リセマラのアカウントを除いて約120万。『シノアリス』はリセマラを行いやすい仕様となっていたこともあり、動いていないアカウントも含めると、その数はさらに大きくなるそうだ。こうして数字を明らかにされると、異常なアクセス数だったことが伺える。 このように、サーバーダウンの原因ははっきりしていたため、リリース日である6月6日に行われた最初のメンテナンスでは、サーバーの増設が行われたそうだ。具体的には、サーバーの共通基幹システムを担う、コア数を一気に20倍に増強したとのこと。これが、初日に行われたメンテナンスでの第一の対策であったと氏は当時を振り返った。 その後、氏はリリース時のアクセスの状態をrps（毎秒ごとの回転数）で表すグラフを公開。それによると、ピーク時のrpsは約5万5000。裏で動いていたものを合わせると約9万にも登っていた。大きな山と谷があるのが特徴的なグラフとなっているが、これはメンテナンス時とそうでないときとでアクセス量にハッキリとした差が生まれているためだ。しかしよく見ると、谷となっている部分でも約500rpsの数値を示しており、メンテナンス中にも関わらずくり返し接続が行われていたことが確認できる。 リセマラが招いたCDUの上限オーバー ふたつ目の事象は“CDN Quota”。ゲーム開始直後のチュートリアルの段階で10連ガチャを引けるリセマラ特化の仕様のため、大量のリセマラによってデータを大量に転送するネットワークの割当量CDN Quotaが上限に達してしまい、これもまたメンテナンスを招く結果となってしまったという。 リセマラをするユーザーが増えることは開発当初から想定していたことであり、そのため最初の10連ガチャまで手軽に到達できるよう、ユーザーの初回ダウンロードアセット30mdps程度に抑えていたのだが、これも予想以上の流入によって想定が崩れ、リソースが枯れてしまい、問題が発生してしまったそうだ。 この問題も、先ほどのメンテナンスと同じタイミングでQuotaを引き上げることで対応。帯域幅を拡張し、問題を解決したという。 独自開発システムの見えづらいエラー 3つ目のポイントとして挙げられたのは“Varnish導入”。 『シノアリス』はほとんどの部分でマルチプレイシステムを採用しており、それを実現するためにJAVAを利用した独自開発システムを採用しているという。しかし、そのJAVAを使ったシステム自体が想定とは異なる動きをし、それがまた問題発生を引き起こしていたそうだ。このポイントは技術的な話が色濃く出てしまうため詳細は割愛するが、簡潔に纏めると、負荷が分散されずに一極集中してしまったため、クラウドが不具合を起こしたという話になる。 この問題は、クラウドというシステムの都合上、見えづらい箇所に原因があったため、発見するまでに一苦労を要したとのこと。ちなみに、対策となったのが上述の“Varnish導入”。コードでの対応では解決に至らなかったため、Varnishを用いて、Proxy側で交代する方針に切り換えを行い、解決に至ったという。 EC2とRDSなどのサーバーは合計1000以上にも 続いて紹介された、4つ目のポイントは“AWS instance”。メンテナンスに奔走していた当初、ネットワークが障害となり思い通りの性能が出ないことから、対策メンバーは仮想サーバーの増設を決定。増やしに増やした結果、EC2（アマゾンが提供している仮想サーバー）が650台、RDS（データベース）は200台にもなったという。これは、ふつうのアプリ運用では到底考えられない量である。 当時は、ただ単にアクセスが多いという状態だと認識されていた状態だったので、上司から「とりあえずコスト無視でいいから」と言われ、こうしてサーバーを立て続けたのだという。しかし、あまりにも増やしすぎたため、別方面から「流石に立てすぎなのでシステムを見直してください」という通達が来てしまったと、覚張氏は苦い顔で振り返っていた。 ちなみに、どれだけのペースで仮想サーバーを増設したのかを見せるため“EC2の650台の軌跡”というグラフも紹介された。ここでも 、通常ではあり得ない動きをしているグラフを見た参加者から笑いが飛び出すという場面が。リリース日には300台にも満たなかった仮想サーバーが日に日に増加を続け、ピークでは先述の通り650台に到達してしまっていることが、ここからも確認できる。 データベースの推移についても、同じようにリリース日から増加の一途をたどっており、最終的に200台に到達。覚張氏は「とりあえず積むしかなかった」と、当時は本当にどうしようもない状態だったことを明かした。また、この他にElastiCacheというサービスも利用していたため、ピークのときには1000台を超えるサーバーを動かしていた時期もあったそうだ。 バトルコアDB・非バトルコアDBをさらに分割 最後のポイントは“追加 Sharding”。リリース前からDB（データベース）はいくつかのテーブルに分散させていたが、未曽有のアクセスに起因し、対策チームはデータベースの再分割と新規分割を急遽実行。非バトルコアDBは当初10台だったものが40台に、バトルコアDBは10台だったものが段々と増えていき、最終的には80台にまでなった。 ここへの対策を行った6月10日には、連日の作業疲れからデータを2度も飛ばしてしまうというアクシデントも発生。当時は前田プロデューサーと覚張氏にふたりだけが会社に残る日が続き、前田氏が確認をしながら、覚張氏がひたすら作業を続けるという状態だったとのこと。 その当時、ふたりの疲れは割り算ができなくなるレベルにまで蓄積し「最終的には割り算ひとつをExcelで行う状態だった」と覚張氏は当時の様子を笑い半分に振り返った。 最後の決め手はエンジニアのモチベーション 以上の5つの点が、未曽有のアクセスが発生した際に起こった現象と、それぞれに対して行った対策の紹介になる。 講演の最後に覚張氏は“メンバーのモチベーションの保ち方”というポイントを紹介。これは、メンテナンス続きで泊まり込みの日々を過ごした覚張氏が、当時モチベーションに繋がったポイントをまとめたものだ。 ここで、届く差し入れはもちろんのこと、チャットグループで意見交換をしているときに社長から発せられた「ピザ届いたよ」という言葉ひとつで気持ちと場が和んだこともあったと氏は当時を振り返る。また、会社付近のホテルを利用して休息を取れるだけで大きく気分が変わったとも語っていた。 モチベーションはやはりどのような職種であれ大事なポイント。とくに大きな問題に直面したとき、ここをどのように維持していくかが重要なのだ。 また続けて氏は「リリースから苦しい日々を送ったが、上司による命令や苦言などは一切なく、それが逆に信頼されているという意識に変わり、モチベーションを保てた」と、当時の心境を語ってくれた。 こうした連続メンテナンスという事態から得られた経験は氏の中に大きく蓄積され、その経験は以降のアプリ運用にも活用されているという。 覚張氏が『シノアリス』で学んだことは“どれだけ予測を立てても、それを上回る事象が起きる可能性がある”ということ。その事態に対応できるためにも、エンジニアにリソースを最適に割り振り、問題が発生した際に対応できる準備を整えることが大切だとまとめ、本セッションを締めくくった。

対応機種	iOS／Android／ブラウザ
価格	無料（アプリ内課金あり）

ジャンル	RPG
メーカー	スクウェア・エニックス／ポケラボ
公式サイト	http://sinoalice.jp/
公式Twitter	https://twitter.com/sinoalice_jp
配信日	配信終了
コピーライト	© 2017-2023 Pokelabo Inc./SQUARE ENIX CO., LTD. All Rights Reserved.