テクロスにおけるAWS活用の歩み
ソーシャルゲーム運用とデータレイクについて
AWS SUMMIT TOKYO 2019
自己紹介
髙橋 北斗（たかはし ほくと）
● 株式会社テクロス システム開発部マネージャー
● 経歴
○ インフラチームリーダー
■ ソーシャルゲームのインフラ基盤の開発・運用
■ 各種ツール、サービスの導入、管理
■ データ分析基盤の設計、導入
○ 現在は神姫プロジェクトのエンジニアマネージャー
About us
株式会社テクロス Techcross inc.
2009年 設立
2012年 ソーシャルゲーム開発開始
2018年～ UNITIA - 神託の使徒 × 終焉の女神 - リリース 2016年 神姫PROJECT リリース
目次
● はじめに
● テクロスにおける AWS 活用の取り組み
○ 神姫 PROJECT の事例
○ UNITIA の事例
● データレイク導入について
○ データレイク導入までの課題
○ データレイク構築について
● 最後に
はじめに
テクロスのインフラの3年前の状況は、
● AWS未使用、AWSの知見も社内にほとんどなし
● インフラ構築はすべて手動
● マネージドサービスもほとんど使わず
● ログの分析基盤もなく、バラバラなログ管理
な感じでした ……
はじめに
そんな状況から、この３年でテクロスのインフラが、
どう変わっていったか、どう変えていったかを
お話したいと思います。
神姫プロジェクトの事例
神姫PROJECTの事例
神姫PROJECT
● 2016年3月末リリース
● ターン制RPG
● DMM GamesにてWebブラウザ版
● iOS, Androidのネイティブアプリをリリース
● 2019年4月に登録者数500万人を突破
神姫PROJECTの事例
リリース直後、別のクラウドベンダーを利用していた
その中で、大きな課題が２つあった。
● インスタンスが不安定
● データベースが不安定、性能が出ない。
神姫PROJECTの事例
リリース直後（主要部）
神姫PROJECTの事例
インスタンスが不安定
● 当時利用していたVMにおいて、CPUのStealが発生
● 対策として
○ アプリケーション動作に必要以上のメモリを確保する
■ 必要以上のお金がかかる
○ 専有ホストを用意してもらう
■ どの専有ホストにどのVMを入れるかのパズルが発生
● VM単体の安定性も低く、メンテナンスも多かった。
神姫PROJECTの事例
データベースが不安定、性能が出ない
● 当時メインデータベースにMySQL Clusterを使用していた
● アーキテクチャ的にVMと相性が悪いミドルウェア
○ 巨大クラスタ組んでも中々性能が出ない
● 突然落ちる、原因は不明
● 運用も煩雑で、データのリストアの取り回しも悪い 性能、安定性、運用コストに課題があった。
神姫PROJECTの事例
リリース2ヶ月後、MySQL Clusterが落ちてしまう事件。
復旧しきれず、３日のメンテナンスを入れてロールバック。
根本的な対策を行わないと無理と判断。
アマゾン ウェブ サービス (AWS) への移行を決断。
神姫PROJECTの事例
AWSを選んだ理由
● クラウドサービスとして最大手で安心感があった。
● VMの安定性も高い
● Amazon Auroraのパフォーマンスが高い
● 問い合わせ後のサポート体制、契約までのスピード感が非常に良 かった。
AWSへの移行を決めたものの、当時、社内のAWSのナレッジは、ほぼ 存在しなかった。
神姫PROJECTの事例
移行スケジュール
AWSのナレッジが社内にない状態ながら、サービスの安定性が危機的 な状況だったので、急いで移行する必要があった。
目標は5ヶ月。
神姫PROJECTの事例
AWS環境設計と構成管理ツールの見直し
マネージドサービスを積極的に導入することで、運用コストの軽減を目 指す。
VMで管理するミドルウェアが大幅に減るのもあり、構成管理ツール
（Chef）の見直し、修正も行っていった。
神姫PROJECTの事例
移行前の構成（主要部）
神姫PROJECTの事例
移行後の構成（主要部）
神姫PROJECTの事例
負荷試験
● AWS環境の負荷試験を行った
○ Amazon Auroraのパフォーマンスがボトルネックになったので、
チューニングを行う
○ クエリの見直し、外部キーの変更など
○ PHPの持続的接続の導入など、AWS 技術サポートの方にアド バイスをいただいた
● チューニングの結果、なんとか負荷目標を達成
○ 移行後に負荷の問題が再び顕在化したので、最終的に、データ ベースの分割を行った
神姫PROJECTの事例
AWSへの移行
● MySQL ClusterからAmazon Auroraにレプリケーションを貼るのが 困難だったため、mysqldumpを並列して取り、Auroraに入れる素朴 なやり方を取った
○ レコードのチェックスクリプトも合わせて作成
● 24時間のダウンタイムをビジネス側に許容してもらった
● 移行試験を行い、手順の確認
● 移行本番も、滞りなく進行できた。
神姫PROJECTの事例
移行してよかったこと
● インスタンスの安定度が格段に増した
○ Stealで悩まされなくなった。
○ VMも全然落ちなくなった。落ちても自動復帰
● マネージドサービス導入により運用負荷が格段に下がった
○ 特にAmazon Auroraは運用が非常に楽
● APIを利用したインフラ構築の自動化ができるようになった
神姫PROJECTの事例
移行してよかったこと
その後も起きる負荷対策、不具合対応についても、AWS技術サポート、
ソリューションアーキテクトの方々に非常に助けてもらっている。
AWSの一番良いサービスは何かと聞かれたらサポートと答える。
開発・運用タイトル『UNITIA - 神託の使徒 × 終焉の女神 - 』
UNITIAの事例
UNITIA 神託の使徒×終焉の女神
● 2018年7月末リリース
● セミオートバトルRPG
● プレイヤー同士で戦えるアリーナモード搭載
● DMM GamesにてWebブラウザ版
● iOS, Androidのネイティブアプリをリリース
UNITIAの事例
構成（主要部）
UNITIAの事例
構成は神姫と殆ど変わってません。
何が変わったのか？
構成をコード管理するようにしました。
UNITIAの事例
神姫PROJECT運用時に発生していた課題
基本的にマネジメントコンソールで手動でリソースの追加、変更を行って いた。
● 運用上、新しいリソースの追加が必要になったとき、複数ある環境 に全部導入していくのが運用上コスト
● 手動でやっているので設定漏れ、設定違いが起きる
○ 事故の元に
UNITIAの事例
Terraformの導入
冪等性を保った上で、宣言的にインフラをコードで管理するツールがほ しい。
Hashicorp Terraformの導入を検討することに。
● Hashicorp社が手がけるOSS
● インフラ構築や設定をコード（DSL）で宣言的に記述する
● 様々なクラウドベンダーをサポート
UNITIAの事例
Terraformの導入の障壁
● Terraformを本番環境で使うことについては議論、懸念があった
● メンバー間の温度差もあった
○ コード管理した方が事故りやすいのでは？
○ コード管理など理想論にすぎない、というベテランからの意見も あった
UNITIAの事例
Infrastructure as Codeの読書会実施
毎週、読書会の時間を取り、半年ほどかけて、オライリー・ジャパンの
『Infrastructure as Code』のほぼ全ての章をインフラチーム全員で読ん だ。
概念の理解、達成したい理想形の共有 現在運用中の自社サービスとのギャップ の洗い出しを行っていった。
UNITIAの事例
Infrastructure as Codeの読書会を実施
この取組で、
● チームにおける共通言語、共通概念の獲得
● Infrastructure as Codeに対するチームの認識の統一 が図れるようになった。
懸念を表明していたベテランが一番Terraform導入に前向きに。
UNITIAの事例
Terraformの構成
本番環境、ステージング環境、デバッグ環境で同じコードベースでの Terraform管理を実現
Workspace機能を利用
UNITIAの事例
Terraformの構成
実行範囲を分割
UNITIAの事例
個人用開発環境のセルフサービス化
UNITIAの事例
Terraformの導入結果
Terraform導入により、
● 複数ある同等環境への変更の適用が格段に楽になった
● 変更内容、タイミングの管理がやりやすくなった
● 開発環境と本番環境の意図せぬ差異がなくなり、事故要因を減らせ た
データレイク導入について
データレイク導入までの課題
ソーシャルゲーム運用には様々なログが必要
● ユーザー行動ログ
● APIアクセスログ
● アプリケーションのエラーログ
● 課金、ガチャ結果などのログ
● データベースのログ（スロークエリログなど）
etc...
データレイク導入までの課題
ログは様々な用途に使う
● KPI分析
● CS対応
● 不具合調査
● 不正アクセス検知（不正ユーザやBOTユーザ検知）
etc...
データレイク導入までの課題
このような様々なログを
昔はどのように扱っていたかというと・・・
データレイク導入までの課題
etc…
ログの保存箇所、形式がバラバラ！
データレイク導入までの課題
ログの保存箇所、形式がバラバラ
● ログを組み合わせて分析するのが難しい
● ログの管理コストが高い
● ログを閲覧するインターフェイスが違い、学習コストが高い
○ DBクライアント＋SQL
○ Kibana＋クエリ
○ コンソール＋シェルのコマンド 他にも問題点が・・・
データレイク導入までの課題
ログの量が多くて辛い
● ログの量は1日あたり数百GB over
● Elasticsearchはログ単価が高いので長期保存に適さない
● MySQLはテーブルにデータを溜めすぎるとパフォーマンスが出なく
なる。容量の限界がある
● ログを一定期間経過後捨てると、数ヶ月〜年単位で古いログを見る 必要があったときに困る
データレイク導入までの課題
保守が大変
● ログデータを直に入れているとMySQLやElasticsearchインスタンス の障害時欠損する可能性がある
● 容量、スペックの管理も必要
● ログ構造、テーブル構造の変更に弱い
● 保守作業をサービスのメンテナンスと合わせる必要がある
データレイク構築について
データレイク構築について
やりたいこと
● いろんなログを一つの基盤に集約したい
● 全部のログを長期間保存したい
● 保守がしやすい形にしたい
データレイク構築について
どうしよう … 🤔
考えた結果は
データレイク構築について
全部ログは Amazon S3 + Amazon Athena に集約
＋
データレイク構築について
S3+Athenaのいいところ
● S3のデータ保存単価が安い
○ 東京リージョンのS3標準ストレージ月額料金:0.023USD/GB〜
● Athenaはクエリ実行時にのみ、料金が発生
● AthenaはPresto互換の強力な分析用SQLが使える
● Amazon Kinesis Data Firehoseでマネージドでデータを放り込める
○ 加工は別途必要、AWS Glueを使う
データレイク構築について
Amazon S3+Amazon Athena に全部集約するために
変えていく
データレイク構築について
行動ログ
データレイク構築について
行動ログ
様々な種類の行動ログを送信：
データレイク構築について
行動ログ
行動ログ種別に分割
データレイク構築について
行動ログ
重複排除とParquetに変換 テーブルスキーマは自動判別
データレイク構築について
DB保存のログデータ
データレイク構築について
DB保存のログデータ
別AWSアカウントにリストア
ログ取得後、開発やCS用途にも使う
データレイク構築について
DB保存のログデータ
テーブルにクエリを投げ、Json化してS3へ保存 日毎型：その日のテーブルデータすべてを保存 追記型：前日との差分のみ保存
データレイク構築について
DB保存のログデータ
重複排除とParquetに 変換
APIログ、エラーログ
データレイク構築について
データレイク構築について
Amazon S3 ＋ Amazon Athena に全部集約していく
データレイク構築について
Redash経由でのアクセス
● RedashからAthenaに対し接続、SQL発行
● プランナーやマーケットチームにクエリを書いてもらうことでKPI分析 をスムーズに
● ダッシュボードで見える化
● Alert機能を使ってAPI速度やエラー件数のアラートをSlackに
データレイク構築について
データレイク構築について
今後の課題
● より運用コストを最適化するための取り組みをしていきたい
○ ログ形式の自動判別機能の整理、強化
○ DB保存ログ追加の手作業の撲滅
● 分析基盤の活用強化を行っていきたい
○ RedashのKPIデータダッシュボードの充実
○ CSチームが使いやすいインターフェイスの準備
○ より本格的なデータ分析への活用
最後に
最後に
ここまでで紹介した以外に、様々なツールやサービスを導入して きた。どれも 3 年前にはなかったもの。
https://stackshare.io/techcross-inc
最後に
大事にしている価値観
● 新しいツールやサービスを積極的に検証、導入する
○ 最も技術の進歩が激しい、新しいものがどんどん出てくるので、
もたもたしてるとあっという間にレガシーになる
○ 逆に新興、中小でもサービスをうまく使えば追いつける
● その上でベストプラクティスを大事にする
○ ツールやサービスの正しい使い方を心がける
■ 当初は良くても途中で方向性がずれてくる
■ 正しい使い方はサービスの中の人が知っている
最後に
