AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例インスタンスが不安定...

テクロスにおける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万人を突破


リリース直後、別のクラウドベンダーを利用していた

その中で、大きな課題が２つあった。

● インスタンスが不安定● データベースが不安定、性能が出ない。


リリース直後（主要部）


インスタンスが不安定

● 当時利用していたVMにおいて、CPUのStealが発生● 対策として

○ アプリケーション動作に必要以上のメモリを確保する■ 必要以上のお金がかかる

○ 専有ホストを用意してもらう■ どの専有ホストにどのVMを入れるかのパズルが発生

● VM単体の安定性も低く、メンテナンスも多かった。


データベースが不安定、性能が出ない

● 当時メインデータベースにMySQL Clusterを使用していた● アーキテクチャ的にVMと相性が悪いミドルウェア

○ 巨大クラスタ組んでも中々性能が出ない● 突然落ちる、原因は不明● 運用も煩雑で、データのリストアの取り回しも悪い

性能、安定性、運用コストに課題があった。


リリース2ヶ月後、MySQL Clusterが落ちてしまう事件。

復旧しきれず、３日のメンテナンスを入れてロールバック。

根本的な対策を行わないと無理と判断。

アマゾンウェブサービス (AWS) への移行を決断。


AWSを選んだ理由

● クラウドサービスとして最大手で安心感があった。● VMの安定性も高い● Amazon Auroraのパフォーマンスが高い● 問い合わせ後のサポート体制、契約までのスピード感が非常に良

かった。

AWSへの移行を決めたものの、当時、社内のAWSのナレッジは、ほぼ存在しなかった。


移行スケジュール

AWSのナレッジが社内にない状態ながら、サービスの安定性が危機的な状況だったので、急いで移行する必要があった。

目標は5ヶ月。


AWS環境設計と構成管理ツールの見直し

マネージドサービスを積極的に導入することで、運用コストの軽減を目指す。

VMで管理するミドルウェアが大幅に減るのもあり、構成管理ツール（Chef）の見直し、修正も行っていった。


移行前の構成（主要部）


移行後の構成（主要部）


負荷試験

● AWS環境の負荷試験を行った○ Amazon Auroraのパフォーマンスがボトルネックになったので、

チューニングを行う○ クエリの見直し、外部キーの変更など○ PHPの持続的接続の導入など、AWS 技術サポートの方にアド

バイスをいただいた● チューニングの結果、なんとか負荷目標を達成

○ 移行後に負荷の問題が再び顕在化したので、最終的に、データベースの分割を行った


AWSへの移行

● MySQL ClusterからAmazon Auroraにレプリケーションを貼るのが困難だったため、mysqldumpを並列して取り、Auroraに入れる素朴なやり方を取った○ レコードのチェックスクリプトも合わせて作成

● 24時間のダウンタイムをビジネス側に許容してもらった● 移行試験を行い、手順の確認● 移行本番も、滞りなく進行できた。


移行してよかったこと

● インスタンスの安定度が格段に増した○ Stealで悩まされなくなった。○ VMも全然落ちなくなった。落ちても自動復帰

● マネージドサービス導入により運用負荷が格段に下がった○ 特にAmazon Auroraは運用が非常に楽

● APIを利用したインフラ構築の自動化ができるようになった


移行してよかったこと

その後も起きる負荷対策、不具合対応についても、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保存のログデータ



別AWSアカウントにリストアログ取得後、開発やCS用途にも使う



テーブルにクエリを投げ、 Json化してS3へ保存日毎型：その日のテーブルデータすべてを保存追記型：前日との差分のみ保存



重複排除とParquetに変換

APIログ、エラーログ



Amazon S3＋Amazon Athenaに全部集約していく


Redash経由でのアクセス

● RedashからAthenaに対し接続、SQL発行● プランナーやマーケットチームにクエリを書いてもらうことでKPI分析

をスムーズに● ダッシュボードで見える化● Alert機能を使ってAPI速度やエラー件数のアラートをSlackに


今後の課題

● より運用コストを最適化するための取り組みをしていきたい○ ログ形式の自動判別機能の整理、強化○ DB保存ログ追加の手作業の撲滅

● 分析基盤の活用強化を行っていきたい○ RedashのKPIデータダッシュボードの充実○ CSチームが使いやすいインターフェイスの準備○ より本格的なデータ分析への活用

最後に

最後に

ここまでで紹介した以外に、様々なツールやサービスを導入してきた。どれも3年前にはなかったもの。

https://stackshare.io/techcross-inc

https://stackshare.io/techcross-inc

最後に

大事にしている価値観

● 新しいツールやサービスを積極的に検証、導入する○ 最も技術の進歩が激しい、新しいものがどんどん出てくるので、

もたもたしてるとあっという間にレガシーになる○ 逆に新興、中小でもサービスをうまく使えば追いつける

● その上でベストプラクティスを大事にする○ ツールやサービスの正しい使い方を心がける

■ 当初は良くても途中で方向性がずれてくる■ 正しい使い方はサービスの中の人が知っている

最後に

ご清聴ありがとうございました。

AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例インスタンスが不安定...

Documents

Transcript of AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例インスタンスが不安定...

AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例 インスタンスが不安定...

Documents

Transcript of AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例 インスタンスが不安定...

AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例インスタンスが不安定...

Transcript of AWS SUMMIT TOKYO 2019 · 神姫PROJECTの事例インスタンスが不安定...