【レポート】560万+ダウンロードのスマフォゲームインフラをAWSへ移行させたSREチームの工夫について #AWSSummit

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

水曜よりより開催されています AWS Summit Tokyo 2019。こちらで開催された株式会社サムザップ様によるパートナーセッション L3-01 をレポートします。

  • あるSREチームの挑戦 運用6年目の大規模ゲームをAWS移設後に安定運用するための技術と今後の展望

「戦国炎舞 -KIZNA-」はサービスの立ち上げから約6年間に渡ってオンプレミス環境で運用しており、以下のような課題がありました。
・肥大化したデータとログ
・1日に3回あるゲーム内イベントの時間に大幅に増量するリクエストへの柔軟な対応
・自動化しづらい構成と環境
これらの問題を解決するためのAWS移設でしたが、レスポンス速度の改善、コスト低減、運用効率の改善など多くの成果を上げることができました。移設の目標と共に、どう課題解決したかと今後の展望についてをご紹介します。

資料

(後日公開されるとのことです)

内容

  • 自己紹介
    • 石原 裕之 SREチームマネージャ
      • 好きなサービス : Aurora 性能が良い、管理が楽
    • 吉岡 賢 TechLead
      • 好きなサービス : Route53 SLA100%
  • サムザップのSREチーム
    • インフラチームから名称変更
    • ゲームサービス
    • 機能開発は行わないが、安定性の向上やパフォーマンス改善などに繋がる開発は行う
  • サムザップの事業内容

戦国炎舞 -KIZNA-

  • 戦国炎舞 -KIZNA- | 株式会社サムザップ
    • 560万ダウンロード
    • プライベートクラウドからAWSへ 2月
    • 200+インスタンス
    • 23000req/sec
    • 合戦というリアルタイムイベントが一日 3 回
  • 「合戦」にアクセスが集中
    • 平時の10倍〜20倍
    • これが毎日3回発生
  • 構成
    • 以前はプライベートクラウドで構築していた
    • AWS
      • Web EC2
      • 課金情報などはAurora
      • memcacheクエリキャッシュ
      • redis合戦中の行動に必要なポイント情報など
      • 画像はCloudFront
  • 移設の背景 なぜプライベートクラウドから移設することになったか
    • プライベートクラウドの一部提供終了がきっかけ
    • AWSを選んだ理由 = Auroraがあるから
      • 多数のDBサーバのトラブルを減らしたかった
      • 旧環境で苦労
      • 他にもマネージドサービスがあったりコストの問題も

旧環境での課題と解決方法

旧環境での課題1

  • 合戦前後で柔軟なサーバ増減させたい
    • 旧環境では事情があってできなかった(APIエラー増大等
  • AWSでは
    • CloudWatch Eventsで時限トリガー
    • Step Functionsを呼び出すLambdaが実行される
    • 合戦用のASGに増設・停止をスケジューリング
    • slackへ増設の開始を通知
    • 自動でインスタンス増設・サービスイン(ELB参加など
  • 費用比較は単純ではないが、常時起動よりは1/3程度になっている
  • 副次的効果
    • マシン性能が上がり応答速度がアップした
      • レスポンスタイムが1/3 <- C5
      • インスタンスタイプを柔軟に変更できるのも良い
  • 今後
    • SpotInstanceの導入を検証中、来月には検証完了予定
      • 試算だとさらに50%下がる

旧環境での課題2

  • 肥大化したデータとログ
  • DBサーバの運用、管理に疲弊 -> DB性能5倍、複数DBを集約
    • 78台 -> 10クラスタ 20インスタンスにできそう
    • ディスク容量 -> 64TBまでいける
    • トラブル時の対応 -> 自動でfailover
  • Auroraへのデータ移行はDMSを選択
  • 検証中に苦労したポイント
    • 動作検証チャンスは1日1回
      • 退社前にタスクをセット、翌朝確認
    • レプリケーションインスタンス台数とスペックの調整
      • CloudWatchを見ながら(地道
      • 最終的にr4.8xlarge x20
    • DSM分割数の調整
      • 6億レコードをひとつだと、1日で移行が終わらない
      • 1億件ごとにタスクを分割(8hに収まるように計算)
  • 手間のかかるアプリログの調査
    • gzipで36GB/day
    • 調査に数十分〜数時間
    • 移設後はS3に保存、Athenaで調査
      • ダウンロード不要に
      • 調査は数秒〜
      • 提携調査は社内ツールを整備

旧環境での課題3

  • 自動化しづらい構成と環境
  • なぜ自動化したいのか?
    • NoOpsを実現するため
      • トイルをなくして安定稼働させるための改善に使う時間を確保
  • 旧環境:自動化しづらい構成と環境
    • 外部サービスとの連携がしづらい
    • ロール管理ができない、効率の悪いdeploy対象管理
    • マーケティング用分析基盤の扱いが職人化した
  • やったこと
    • デプロイ自動化
    • 画像のデプロイ自動化
    • アプリケーションソースデプロイ
    • 分析基盤

デプロイ自動化

  • デプロイしたいファイル:アセットバンドル、画像、ソースコード
  • 「アセットバンドル」とは
    • ランタイムに読み込むデータのアーカイブのこと
      • モデル、テクスチャ、オーディオデータ …
    • 移設前
      • アプリケーションバージョンとアセットバージョンの対応情報をソースで管理
      • 移設後は自動でアップデートされるようにした
    • buildシーケンスの管理はJenkins
    • S3アップロードをトリガーにLambdaをキックしてDBにバージョン情報をインサート
    • アプリケーションが対応のバージョンを起動時に確認してCDN経由でダウンロード
      • アセットバンドルだけ管理すれば良くなった

画像のデプロイ自動化

  • パスのハッシュかが必要
    • 新しく配信する画像のパス(URL)を予想させないため
    • 動的に配信していた
      • CDNでキャッシュ、オリジンはEC2 -> DB
      • オリジンサーバの保守管理が大変
    • 移設後は静的に変更
      • あらかじめハッシュ化された名前で画像ファイルを置いておく(S3
      • git pushをトリガーにCI runnerがS3へアップロード
        • リネームしてオリジン用に置き直す(Lambda

アプリケーションソースデプロイ

  • 移設前と比べて最大 1/9に短縮
  • 6年続いているゲームサービスなのでレガシーが残っていた
    • scp, rsync
  • 移設後は並列pull型、タグによる自動判別
  • ロールのタグさえ付け間違えなければ運用管理可能になった
  • ソースコードに依存していたmemcache接続情報
    • AWS移行後はAPIから読み出してマッピング
    • consistemnt hashingなので障害時でもメンテ不要
    • AWS APIでクラスタ情報を読む際に、APIのRate Limitを超えないようにRedisにキャッシュ
    • webサーバのローカルキャッシュにも持つ

分析基盤

  • 数億レコードのテーブルを複雑な手順でコピーしていた
  • 数時間かけて複雑な処理
  • 数十億レコードを毎晩コピー
  • 移行後
    • 必要なテーブルに絞る
    • サーバレスで構成
    • 15分程度で終了するようになった

その他移設で工夫したところ

  • 単一ゾーン構成
    • 全リソースを単一AZに
    • 数百ミリ秒では遅いと言われる世界 = ユーザの体感を考えてシングルAZで
  • AWSインフラストラクチャイベントマネジメント
    • 重要な時期に偽ダンスやリアルタイムサポートを受けることができる
    • 毎週定例、技術相談にのってもらった

今後展望

  • ドメイン管理
    • 本番もRoute53に移行
    • メリット
      • DNS failoverm管理の手間を減らす
  • Redis
    • 現在500ポート 用途としては5種類
    • SPOFを排除
  • エラーバジェットによるリスク管理
    • SLI = 指標
    • SLO = SLI + 億票
    • SLA

まとめ

  • オンプレからAWSへ移設
    • 平均レスポンス、コストが1/3
    • 運用効率化の改善
  • 今後
    • Ruoute53、Redisなどの既存問題を解決
    • エラーバジェット
    • 開発チームと連携して安定稼働にとりくむ