聞きながら書いてたので抜けてたり誤字とか多いと思う。各々の資料はあとで公開されるはず。Twitter のハッシュタグは #ゲームサーバ勉強会
なお、会場内からも発表されてましたが、第二回の開催も検討とのことです。
皆さまご来場ありがとうございました。懇親会で話しましたが、好評いただいたので、第2回やる方向で検討します。次回予告イメージとしては、10月頃、負荷試験、うどんの会による自家製うどん。 #ゲームサーバ勉強会
— 元イカ2 (@seizans) August 3, 2018
アカツキ: 失敗から学ぶ・大規模環境における Ruby on Rails on AWS の最適化
めっちゃ鳥肌
— 紫苑 (@grwth1009) 2018年8月3日
これ、正月かな......#ゲームサーバ勉強会 pic.twitter.com/RKARkr3F5f
Rubyはsmallスタートむき#ゲームサーバ勉強会 pic.twitter.com/DplEw5zrWx
— 紫苑 (@grwth1009) 2018年8月3日
インフラ構成 #ゲームサーバ勉強会 pic.twitter.com/7b5M8nh0zg
— 野生の社長＠金曜る-14b (@yasei_no_otoko) 2018年8月3日
- キャンペーン開始後数日後のリクエスト数とエラー数
- 予想以上のアクセスがあり障害連発
- リシャーディングして DB を 4 倍に増やした
- 実施したリシャーディング
- 既存の DB インスタンスをコピーして 4 倍のリシャーディング
- 6/1 の AWS Summit に裏話を加えた LT となってる
- 自己紹介
- モバイルゲームにおけるサーバサイドの役割
- API サーバとして動作
- クライアントへのゲームデータを返す
- ゲームロジックの計算
- ユーザデータの管理
- ユーザがアクションするたびにリクエスト数が膨大になる
- API サーバとして動作
- モバイルゲーム運用中頻出のアクセススパイク
- キャンペーンがあるたびに発生する
- 技術的課題
- ユーザデータが大量にある
- ロジックが複雑である
- Write Insentive な特性がある
- キャッシュ並べてスケールアウトする戦略が採りづらい
- システム構成
- Ruby on Rails
- 大規模環境向けではないが、AWS で大規模にスケールアウトする話を説明
- Ruby on Rails
- インフラ構成
- RDB + memcached + Redis
- マスター: ゲームデータ
- Aurora MySQL: Read intensive なので Read Replica を増やしてスケールアウト
- r4.8xlarge * 数台
- ユーザ: ユーザ個々のデータ
- Multi-AZ: Write intensive なので水平分割、異なる種類のデータを join
- r4.4xlarge * 数十台
- memcached: セッションとレスポンスキャッシュ
- ElastiCache: 水平、垂直分割して用途別キャッシュクラスタ、Consistent-Hash 法で分散
- m4.2xlarge * 数十台
- redis: ランキングや永続化したいデータ
- とある日のバージョンアップでの負債返却
- Middleware 部分の実行時間短縮
- DB の死活監視が原因...
- Rails における DB コネクション管理
- コネクションプールを使ってる
- プールからは生きたコネクションを返却するために ping が疎通するか確認する
- 大規模環境では Octopus というライブラリを使ってる
- なのだが、実装の問題で数十台分の ping を送ってた
- リシャーディングによりオーバーヘッドが膨れ上がってた
- ちなみに Spotify や Groupon でも課題になってるようだった
- ActiveRecord の実行時間短縮
- 異なる AZ 間の通信距離
- AWS デザインパターンにより耐障害性のために複数 AZ に配置すること推奨
- しかし複数 AZ の RTT は大きい
- できるだけ同一 AZ に優先的にクエリを発行するようにする
- ただし縮退時はランダムでインスタンスを選ぶ
- Middleware 部分の実行時間短縮
- 上記のりシャーディングが起因で応答時間が悪化してた
- データ量が膨大で重複エントリ削除に数日かかるレベル
- DB のゴミ掃除に更新可能なスレーブを用意してバックグラウンドで削除
- あとは地道なアプリケーションの最適化で応答時間を改善
- 最終的には年間数千万の経費削減に成功した
ディライトワークス: これで怖くない！？大規模環境で体験する DB 負荷対策 〜垂直から水平の彼方〜
#ゲームサーバ勉強会 FGOのDB構成だそうな。 pic.twitter.com/5xI0qs9khA
— Fine Lagusaz (@sesuna) 2018年8月3日
#ゲームサーバ勉強会
— 野生の社長＠金曜る-14b (@yasei_no_otoko) 2018年8月3日
移行後のサーバ構成 pic.twitter.com/q8MPSpg4Mk
- なぜいま垂直分割から水平分割なのか？
- 2016/5 これまで1台だった DB を分割することにした
- データが肥大化したインデックスがメモリにのらなくなったことが起因
- 十分な検討時間がなかったので垂直分割をした (4/5/6 分割)
- テーブル分割で当座をしのいだ日々
- 2018/1 テーブルの肥大化がすすみ、参照のレイテンシが顕著に増加した
- slave を追加したが
- MySQL 5.6
- db.r4.16xlarge x18 (master x6 slave x12)
- Redis 2.8
- cache.r3.4xlarge x2
- memcached
- cache.r3.2xlarge
- 今回は十分な考える時間があったので振り返った
- 垂直と水平が混在すると移行が必要になり複雑になる
- 結局として水平分割に一本化することになった
- 2016/5 これまで1台だった DB を分割することにした
- 水平分割の移行課題
- 何をキーとして分割するか
- ユーザID
- データ不整合対策のため
- ユーザID
- 何分割するか
- 20分割
- 今回の分割作業で最後にしたいという思い
- 20分割
- 移行どうするか
- 1. AWS DMS
- 2. ログデータを使う
- 今回 1. を使うことにした
- ダウンタイムを減らす、2. のログと DB の差異が発生するリスクを避けた
- 今回 1. を使うことにした
- ダウンタイムどうするか
- 数時間
- ライブマイグレーション後の切り替え作業の時間を想定
- 数時間
- 切り戻しは？
- ダブルライト方式とリカバリ環境を DMS で準備
- または XA トランザクション
- パフォーマンス面で影響が出る可能性があるため断念
- 何をキーとして分割するか
- どのように移行したか？
- 移行プロセス
- スケジュール
- DMS による移行方法の確率
- 負荷試験の実施
- リハーサル
- 本番環境実施
- スケジュール
- 2018/7 をターゲットに決定
- 準備期間は 2018/3-2018/7
- 移行方法の確率
- 全てのテーブルを精査、再設計を実施
- DMS のタスクによる移行を実施
- DMS のタスクとは
- 既存のデータを全ロード (FullLoad)
- キャッシュされた変更の適用
- 継続的なレプリケーション (CDC)
- 以下の二案
- DB -> Dump -> Restore -> CDC
- AWS DMS を使うには
- レプリケーションサーバを作成
- ソースエンドエンドポイントとターゲットエンドポイントを作成
- 1つ以上の移行タスクを作成
- 最終的には - DB schema (-index) -> FullLoad -> +index -> CDC
- スキーマだけ流すとあとは DMS がやってくれる
- DMS のタスクで移行を行うにあたって
- ユーザID % 20
- 想定外としてソースエンドで関数がサポートされてなかったためフィルタ用のカラムを追加することに
- FastDDL (lab mode) でカラムを追加した
- ただし本番環境での使用は推奨せず十分検証が必要
- メンテ時に一時的に利用
- 追加カラムに分割IDを挿入すえうため時間をかけて追加
- 負荷試験の実施
- 本番環境同様の環境を準備
- サーバアプリの全APIを検証
- 後述の負荷試験ツールにより早期に問題を発見して開発期間の短縮と信頼性を担保
- リハーサルはレプリカを使ったが高負荷かけたらCDCレイテンシ増加した
- 原因は複数のタスクで binlog スレッド複数起動して mutex の奪い合い
- 最終的的には負荷かけない環境で各ソースのバイナリログ期間を長くした
- 整合性確認は利用せず
- dbcompare で比較しようとしたが高負荷になる
- 結果的には checksum table を利用
- メンテスケジュール
- 夜間の計画メンテ実施
- DMS による移行を実施
- ダブルライト方式に切り替え
- 後日整合性確認
- 切り戻しにデータ不整合があり、データ移行漏れがあった
- wait_timeout 60s と短すぎたので 28800s に変更
- ダブルライト停止して移行作業完了させた
- 移行プロセス
LT 枠
f_prg: AWS ゲームインフラ経験談
- 経歴紹介
- PHP/Obj-C のアプリ開発してたが途中から AWS インフラ担当するようになった
- 苦労話
- 〜がからむといろいろ大変
- トラブル
- 通勤中にトラブル
spre55: はじめての AWS code4 兄弟の自動デプロイ
- 去年11月新規タイトルにアサインされた
- 意識高い人に AWS をすすめられた
- AWS コンソール複雑あるある
- 今まで AWS をオンプレとして使ってたがデプロイ自動化を実施する試みをした
- デプロイ自動化によりいままでは git => merge => gulp => ansible でデプロイ
- いまは PR マージで完了
- 今後の展望として UI テストも pipeline にはさみたい
clown_kage: 低予算でもソシャゲで金儲けがしたい〜成功者を見て気づいたこと〜
- 以下の二人を参考にしてみる
- ところにょり氏
- ひとりぼっと惑星
- したっぱ氏
- ハクレイフロンティア
- ところにょり氏
- 以下の共通点
- お金にシビア
- 人間力が高い
- 程よい自信
yuto_komai: 東京リージョンに Fargate が来たぞ！ ECS から移行したった！！
- 自己紹介
- デジタルアバターがある
- (x) ECS から (o) Fargate を運用する上で気をつけること
- Fargate とは？
- サーバレスコンテナ管理サービス
- 1ノードに対する考え方を一新する必要がある
- 1ノードをチューニングしてスケールアウトするアプローチ
- 一方で Fargate は割当されるリソースが小さい
- 加えてカーネルパラメータのチューニングがほとんどできない
- privilege モードもサポートされていない
- 小さなコンテナで起動して大きくスケールする運用が求められる
- ログ管理
- 一般的にはログをどっかに出力する
- 一方で Fargate は CloudWatchLogs をサポートする
- トライアンドエラーが厳しいのでデバッグ環境
- ボリュームアタッチ
- 時間切れ
yu_nishimura_961: 約6年ゲームアプリのインフラをやってきたお話
- 自己紹介
- いまは applibot の人
- 最初の職はラスト半年はひたすらシュレッダーをかける仕事をしてたらしい...
- AWS/GCP でサーバ作って壊す
- どんなアプリ担当してるの
- 全部、人員が少ないことによる
- 障害発生しないときは暇してるの？
- だといいですね ()
- 運用とかいろいろ
- だといいですね ()
- お仕事何されてるんですか？（主に親戚から聞かれる質問）
- ゲーム作ってます！
voluntas: 負荷テスト周りの話
資料は公開されてる記事で。今回は補足
- 珍しいパターンの負荷試験
- 本番環境にあるデータを使う
- DW にあるソースコードを読まずに実装