Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SINoALICE -シノアリス- それは必死の「サーバー削減」

gree_tech
September 12, 2019

SINoALICE -シノアリス- それは必死の「サーバー削減」

CEDEC 2019 にて発表された資料です
https://cedec.cesa.or.jp/2019/session/detail/s5ca04ea19f15b

gree_tech

September 12, 2019
Tweet

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. © POKELABO, INC. 2019/9/5 2 覚張 泰幸 (Yasuyuki Kakuhari) 2013年ポケラボ入社から早6年、入社から今まで2タイトルのGvGを世に送る

    • [GvG] 戦乱のサムライキングダム (2013年リリース) • 新規アクションRPG (未リリース) • [GvG] SINoALICE -シノアリス (2017年リリース) GvGで始まりGvGを作り続けるオトコ 登壇者の紹介
  2. © POKELABO, INC. 2019/9/5 9 1. 削減の軌跡 2. 削減 3.

    SINoALICEにおけるサーバー削減, 移行の留意点 4. サーバー削減, 移行のテクニック SINoALICE -シノアリス- それは必死の「サーバー削減」
  3. © POKELABO, INC. 2019/9/5 10 EC2 650台 • APP, mysql,

    memcached, マルチ通信システムで利用 • RDSと比較すると費用は安いが、台数が多い RDS 200台 • 広げすぎたAurora • 費用的にもインパクトが大きいので、徹底削減 削れる所から削る 削減の軌跡
  4. © POKELABO, INC. 2019/9/5 15 簡単なモノは定常メンテナンスで実施 • ElastiCacheやRead Replicaの削減, スケールダウンに関しては、時間

    を要さないので定常メンテナンスで対応 大掛かりな作業は深夜メンテナンスを実施 • データベースの統合, 分散に関しては、時間を要するので深夜メンテナン スで対応 削減
  5. © POKELABO, INC. 2019/9/5 16 膨大なデータ量 • 当初の想定を大幅に上回る10倍の人数を抱えている為、Log, Data周り の退避,

    分散がそもそも適正ではない 様々なバッチ処理 • ゲームからデータベースを切り離してもバッチ処理は続けなければならな い SINoALICEにおけるサーバー削減, 移行の留意点
  6. © POKELABO, INC. 2019/9/5 17 EBSの料金削減の為、データベース移行, 統合時に新しく作り直す • 一度広がった領域は縮小されない為、載せ替え 複数のalterは一つにまとめる

    • 基本中の基本ではあるが、徹底 • 個々のデータ量が大きい為、まとめなかった場合は延長のリスク 移行作業前のスケールアップ • dump, restoreの速度増加 (CPU, I/O, NICの性能向上を狙う) サーバー削減, 移行のテクニック
  7. © POKELABO, INC. 2019/9/5 18 ゲームを止めずにsharding化 • 初回shardingテーブルに対し、selectを発行 • データがあればそのまま利用し、データがなければ未shardingのテーブ

    ルにselectを発行 • 未shardingのテーブルにselectが走った場合、shardingテーブルに対し insertを発行 サーバー削減, 移行のテクニック
  8. © POKELABO, INC. 2019/9/5 19 RDSを利用している為、スケールダウンは定常メンテナンスで容易に実施出 来るが、スケールインは深夜メンテナンスが必須である 特に大量のデータを分散, 統合, 変更は膨大な時間を要する

    グラフで示すと盛り上がるので台数のグラフを出したが、実際はインスタンス のタイプ変更(スケールダウン)による削減も大きい そもそもスケールアウト, スケールインを小まめに実施する様なシステムは 想定していなかったので、スケールアップ, スケールダウンで諸々対応した い まとめ
  9. © POKELABO, INC. 2019/9/5 21 想定通りに進まず、メンテナンスを延長 (2017-10-12) • 事前にシミュレーションを行なっていたが、予定を大幅に超えてしまい、メ ンテナンス終了に間に合わなくなってしまった

    • 結果、45分メンテナンス延長 • ギリギリ朝のコロシアム時間には間に合ったが.. シミュレーション通りに行かない しくじり事例
  10. © POKELABO, INC. 2019/9/5 22 移行に失敗し、翌日のコロシアムが出来ない (2017-10-12) • ユーザー関連のAuroraが移行中に異常 (import中なのにCPU負荷が下

    がっている, DMLレイテンシが異常に上昇 etc..) • 時間に間に合わない可能性が出たので、failover処理によるRead Replica切り替 え • バッチによるマッチング処理が上記影響で中断され、翌朝のコロシアムが正常に 開催されない • 神魔召喚のレコードが正しく登録されず、神魔が時間通りに発生しない トラブル発生 しくじり事例 (2)
  11. © POKELABO, INC. 2019/9/5 23 移行による費用増加 (2019-07-05) • モノガタリ, コロシアムで利用しているデータベースをEC2(mysql)から

    RDS(Aurora)に載せ替え • EC2のI/Oアクセスを元に費用を見積もったが、設定が異なり見積もりが 役に立たず • EC2ではinnodb_flush_log_at_trx_commitの値を2で利用していた • RDSではデフォルト値を使用する様に設定していたが、EBS(I/O)へのアクセスが 想定以上に増え、予算を遥かに上回る請求が来た 見積もり誤り しくじり事例 (3)
  12. © POKELABO, INC. 2019/9/5 25 APPサーバーに関しては、台数を並べて対応 • オートスケーリンググループを利用し、台数を調整 データベースに関しては、スケールアップで対応 •

    スケールアウト, スケールインは準備がとても大変 • スケールアップでなるべく対応する 複数の施策が重なると、通常の2倍以上に増えるコトも..!! 大規模マーケティング時のサーバー増設
  13. © POKELABO, INC. 2019/9/5 27 分析 • New Relicを利用し、効率の悪いAPIを抽出, 改善

    最適化 • 24時間を通して細かくオートスケーリンググループを設定し、常に最適な 台数でシステムを運用 • クライアント側の効率化 (ローカルストレージの更なる有効活用) The 当たり前 SINoALICEにおけるAPPサーバーの削減