大規模システムの運用においては、負荷試験が極めて重要になる
では、ゲームのリリース後からは、いったいどのような課題に直面してきたのだろうか。
まずリリース時の第一関門として、「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
