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

by gree_tech

Slide 1

Slide 1 text

株式会社ポケラボ覚張泰幸 1 © POKELABO, INC. 2019/9/5 SINoALICE -シノアリス- それは必死の「サーバー削減」

Slide 2

Slide 2 text

© POKELABO, INC. 2019/9/5 2 覚張泰幸 (Yasuyuki Kakuhari) 2013年ポケラボ入社から早6年、入社から今まで2タイトルのGvGを世に送る ● [GvG] 戦乱のサムライキングダム (2013年リリース) ● 新規アクションRPG (未リリース) ● [GvG] SINoALICE -シノアリス (2017年リリース) GvGで始まりGvGを作り続けるオトコ登壇者の紹介

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© POKELABO, INC. 2019/9/5 17 EBSの料金削減の為、データベース移行, 統合時に新しく作り直す • 一度広がった領域は縮小されない為、載せ替え複数のalterは一つにまとめる • 基本中の基本ではあるが、徹底 • 個々のデータ量が大きい為、まとめなかった場合は延長のリスク移行作業前のスケールアップ • dump, restoreの速度増加 (CPU, I/O, NICの性能向上を狙う) サーバー削減, 移行のテクニック

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© POKELABO, INC. 2019/9/5 19 RDSを利用している為、スケールダウンは定常メンテナンスで容易に実施出来るが、スケールインは深夜メンテナンスが必須である特に大量のデータを分散, 統合, 変更は膨大な時間を要するグラフで示すと盛り上がるので台数のグラフを出したが、実際はインスタンスのタイプ変更(スケールダウン)による削減も大きいそもそもスケールアウト, スケールインを小まめに実施する様なシステムは想定していなかったので、スケールアップ, スケールダウンで諸々対応したいまとめ

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© POKELABO, INC. 2019/9/5 22 移行に失敗し、翌日のコロシアムが出来ない (2017-10-12) • ユーザー関連のAuroraが移行中に異常 (import中なのにCPU負荷が下がっている, DMLレイテンシが異常に上昇 etc..) • 時間に間に合わない可能性が出たので、failover処理によるRead Replica切り替え • バッチによるマッチング処理が上記影響で中断され、翌朝のコロシアムが正常に開催されない • 神魔召喚のレコードが正しく登録されず、神魔が時間通りに発生しないトラブル発生しくじり事例 (2)

Slide 23

Slide 23 text

© 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)