wired raven

文字通りの日記。主に思ったことやガジェットについて

ゲームインフラ勉強会のメモ

覚書

概要

ゲームのインフラ中心の勉強会。

今回はAWSとデータベースの話が主だった、はず。

配信

https://youtu.be/OUMiFlgq3os

資料

メモ

  • 会場でとったメモ。内容に誤りがあるかもしれないのであしからず。

失敗から学ぶ大規模環境におけるRuby on Rails on AWSの最適化事例

  • キャンペーン開始とともに予想以上のアクセスにより障害が連発。
  • DBのスケールアップは限界までやったがダメ。4倍のReshardingを実施。
  • それによる速度低下が……。
  • AWS Sumit Tokyo 2018で発表した内容を再編した内容になる。
  • モバイルゲームにおけるサーバサイドの役割と課題
    • APIサーバとして動作している
      • クライアントへのゲームデータの返却
      • ゲームロジックの計算
      • ユーザデータの管理
      • ユーザが何かアクションするたびにサーバサイドにアクセスが発生する
    • モバイルゲーム運用中頻出のアクセススパイク
      • イベント開始に発生する。大変
    • ユーザーデータが膨大である
      • ユーザの持つキャラクタ数百体・育成状態
      • イベント数百個のクリア状態など
    • ロジックが複雑である
    • Write intensiveな特性である
      • 逐一書き込みがはっせいするのでキャッシュを並べてスケールアウトしにくい
  • システム構成
    • RoR
      • 高い生産性と柔軟性をもつ
      • 大規模環境向けではないと言われる
    • インフラ構成
      • ReadonlyのデータはRead Replicaを増やしていける
      • User DBは水平分割、Write intensiveな特性
      • Cashe
        • 垂直・水平分割
        • 用途別キャッシュクラスタ
        • コンシステントハッシュなんとか
      • 数十万から百数十万rpmのアクセス
      • トップクラスのサーバなどを組み合わせている
  • とある日のバージョンアップでの負債返済
    • バージョンアップでレスポンスタイムが200msから100msに
    • 高速化1　ミドルウェア部分の実行時間短縮
      • コネクション管理を改善した
      • コネクションが切れる可能性は低い
        • 30秒ごとに疎通確認するようにした
      • 実装の関係上、すべてのDBにpingを送ってしまう
        • 数ms*数百台で50ms秒縮んだ
    • 高速化2 ActiveRecordの実行時間短縮
      • AWSデザインパターンとして対障害性を担保するため、複数AZにインスタンスを配置することが推奨されている
      • 異なるAZ間のRTTは同一AZ内のものより数倍大きい
      • 同一AZへの優先的なクエリ発行（縮退時）
      • 実施したResharding
        • まるっとコピーしている
        • 重複しているデータを消すには数日かかってしまう
        • オンラインで消すと間違った時に修復不可能になってしまう
      • DBのゴミ掃除
        • 更新可能なスレーブを用意して、重複したエントリをバックグラウンドで削除
        • 削除が完了したらSlaveからMasterへ昇格して、MulutiAZ化して既存DBにした
    • 100msの最適化でEC2の台数が2/3になり、数千万円単位でコスト削減につながった

これで怖くない！？　大規模環境で体験するDB負荷対策

第1章

2015年5月、DBサーバを分割することになった。

テーブル単位で分割するのを垂直分割。

水平分割？

垂直分割で負荷を流していた。

2018年1月、テーブルの肥大化が進んで参照クエリのレイテンシが顕著に増加

Slaveを追加し、対応したがデータの増加量に懸念があった

検討時間があったので水平分割も視野にいれて対策を考えた。

垂直構成だと1ユーザの処理が1つのトランザクションにまとまらない。

垂直と水平が混在すると、厄介なことになる。

最終的に水平に一本化することに。

第2章

  • 移行の課題
    • 何をキーにするか
    • 分割数をどうするか
    • 失敗時のリカバリは？
  • 何をキーにするのか？
    • ユーザID
  • 分割数は？
    • 今回の分割作業で最後にしたいので、今までの実績から考えて20分割
  • 移行方法
    • 案1　AWS DMSを利用する
    • 案2　ログデータを利用する
      • アプリケーションから吐かれたlogをkinesisで送りlambdaもしくは取り込み専用サーバを用意してデータを取り込む
    • 案1を採用した
      • ダウンタイムを減らせる
      • ログデータだとDBとの乖離の可能性があるので
    • ダウンタイムは？
      • 数時間
    • 失敗した場合の切り戻しは？

最終章

  • どうやって移行を実現したのか
    • 移行プロセス
      • スケジュールの策定
        • 3周年の負荷を想定して7月までにした
        • 移行準備期間は4ヶ月ほど
      • DMSによる移行方法の確立
        • すべてのテーブルの精査と再設計をした
        • DMSのタスクとは
      • 移行手順は
    • DMSのソースフィルタは関数をサポートしていないので専用のカラムを追加した
      • FastDDLによる絡む追加を検討し、数十億レコードのテーブルでも1秒で済んだ
      • 追加カラムに分割IDを追加
    • 負荷試験の実施
      • 本番そっくりものにした
      • 負荷試験ツールを使って、本番同様のシナリオを実行・対応を繰り返して改善した
      • CDCレイテンシ？
    • 整合性の確認
      • DMSでは制約上難しい
      • checksum tableを使って検証した
    • 障害テスト
      • ダブルライト方式？
    • 本番移行作業
      • 後日の整合性確認で切り戻し環境でデータ不整合が見つかった
        • 移行後DBと切り戻しDB環境
        • タイムアウトの時間が短すぎた。時間を長くして、再び移行処理を行なって対処した

AWSゲームインフラ経験談

  • キャラものは大変
  • アクセスが増えると大変
  • CMとかあるともっと大変
    • CM直後のアクセス増加に備えて待機したこともある。ただ、杞憂
  • チャット複数やっているとごくまれに誤爆する
  • 通勤中にトラブルが発生した
    • 特急でMongoDBの環境を構築したが……
    • Slackで問い合わせがあったので連絡
    • すぐに降りて近くの公園で暫定対応
    • 出社後に本対応
  • まとめ
    • ゲームインフラは大変だけどめちゃくちゃ楽しい

AWSの話

  • 今まではオンプレ的に使っていた
  • Code4兄弟を活用してみよう
  • masterからbranchにマージしてリリースできるようになった
    • チャットでマージ確認したりはする
  • UIテストのパイプラインに挟みたい（願望）

低予算でもソシャゲで金儲けがしたい

  • 前例を参考にしよう
    • ひとりぼっち惑星
    • ハクレイフロンティア
  • 開発者にあってみた
    • 出費の管理がシビア
    • 人間力が高い
      • 腰が低い
      • 人への嗅覚はすごい
    • 程よい自信
  • 踏まえた提案
    • インフラ業界の今
      • 超買手市場
      • インフラ屋さんは優しくて優秀
        • 会社間の連携はよい
        • 嫌な顔せずに相手にしてくれる
  • 無料でやりたい
    • mobile backendというサービスもある
      • 個人でも利用しやすい

AWSのクイズ大会

  • AWSの中の人より

Fargateの勘所

  • Fargateの運用上のポイント
  • サーバレスのコンテナ管理サービス
  • インフラを用意しなくてすむ
  • ブルーグリーンデプロイ
  • 容易なオートスケール設定
  • 運用ポイント1 -　1コンテナあたりのリソースが小さい -　カーネルパラメータのチューニングはほとんどできない -　root権限はほとんどない -　ログインの概念もない -　小さなコンテナで起動し、大きくスケールするという運用アプローチが求められる
  • 運用ポイント2
    • ログの管理
    • CloudWatchLiogsで管理する
    • CLIを使いこなした方がよい
    • トライ&エラーを繰り返すのは難しいので工夫がいる

ゲームのインフラ6年やっててよく聞かれること

  • どのアプリ担当ですか？
    • インフラ担当は少ないので、ぜんぶのアプリに縦断して関わっている
  • 障害発生してないときは暇ですか？
    • だといいですね。障害を出さないように監視体制の見直しなどをしている
  • 仕事は何をされているんですか？
    • 他業種の人から聞かれると、ゲーム作ってます、とざっくり答えている
  • 6年経っても楽しいよ

追記

  • 主催の株式会社アカツキさんのカレー、美味でした