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