Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

3年にわたる大規模システム開発・運用から得た教訓――「誰ガ為のアルケミスト」開発の歩み【デブサミ2018 福岡】

【B-2】福岡発Node.jsで支える大規模システム!~「誰ガ為のアルケミスト」と歩んだ三年

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2019/01/18 11:00

目次

大規模システムの運用においては、負荷試験が極めて重要になる

 では、ゲームのリリース後からは、いったいどのような課題に直面してきたのだろうか。

 まずリリース時の第一関門として、「DLCが遅い」という事態に見舞われた。DLCを動的に作成して配信するAssetSeverが高負荷になってしまったのだ。生成すべきコンテンツの組み合わせの種類が開発チームの想定以上となってしまい、CDNによるキャッシュヒットの効率が悪くなってしまったという。

 「当然ながらサービスを維持できず、メンテナンスに突入しました。事象を解決するため、いくつかの対応をとりました」

 まずAssetServerを増強し、400台まで増やした。キャッシュヒットの効率が悪い問題についても、想定される組み合わせのリクエストをあらかじめ投げておき、キャッシュを積んでおくことで解決。そして再リリースを行い、問題なくDLCが配信されるようになった。かかったメンテナンス時間は9時間半ほどになったという。

 この経験をもとに、的野氏は2つ目の教訓を語った。「負荷試験をする際に専任の担当者をつけること」そして、「テストケースの検討を複数名で行うこと」だ。その工程を経て洗い出されたテストパターンや実施された負荷試験の結果は、リリース時に必要なリソースの参考値として信用に足るものになる。

リリース当初の「誰ガ為のアルケミスト」サーバー構成
リリース当初の「誰ガ為のアルケミスト」サーバー構成

 次の大きな試練は、「誰ガ為のアルケミスト」が1周年を迎えたタイミングで訪れた。ゲームの大規模な改修が行われたのだ。負荷試験を実施し、AppServerもスケールアウトして準備は万端と思われたが、そうはならなかった。リリース後、徐々にアクセスができなくなっていく障害が発生したのだ。

 原因はAppServerのスケールアウトの仕方にあった。サーバーを増やしすぎたため、RDSへのコネクション数の上限に達してしまい、それ以上接続できなくなってしまったのだ。これは、Node.jsの持つ特性に起因している。Node.jsはノンブロッキングI/Oの仕組みを用いているため、後続サーバーの受信可否にかかわらずリクエストを投げすぎてしまうのだ。

 この事象を解決するため、「スケールアウトしたAppServerの台数を減らす」「RDS応答速度を上げるためAttributeを指定する」「リクエストピーク時のBatch処理を抑止する」などの対応をとり、障害を収束させた。

運用を改善し続けた結果、現在はこのようなサーバー構成となっている
運用を改善し続けた結果、現在はこのようなサーバー構成となっている

 この経験をもとに、的野氏は3つ目の教訓を語った。

 「大規模な改修があった場合は、必ず負荷試験をしましょう。そして、その結果を信じましょう」

 また、本番環境においてどれくらいのレコード件数をデータベースから取得しているのか調べることも重要だ。2年目ともなると、ユーザー数も多くなり、アイテム数なども増加してくる。本番環境と同等のデータ量で負荷試験をしておかなければ、発生し得る問題を検出できなくなってしまう。

 「そして、データ取得の際にはAttributeを指定して不要な項目を取得しないこと、キャッシュを有効活用してI/O負荷を減らしていくことなどを心がけてください」

 「誰ガ為のアルケミスト」の3年の歩みにおいて、開発チームはいくつもの失敗を経験してきた。そして、その過程で数多くのノウハウを学びながら、運用を改善し続けてきたのだ。彼らの姿勢はまさに、「First to Try, First to Fail, First to Recover(誰よりも早く挑戦し、失敗し、そして復活する)」という同社の行動指針を体現していた。

お問い合わせ

 株式会社gumi



  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:【デブサミ2018 福岡】セッションレポート
All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5