大規模ログ分析における Amazon Web Services の活用

株式会社 バンダナムコスタジオ ＮＥ開発本部 分析運営部

竹村 伸太郎

1

• ゲームログ分析の事例紹介

– 大人の事情により、弊社タトルの話はございません

– 恐縮ながら、その代わりに論文を紹介させて下さい

• バンダイナムコスタジオの大規模ログ集約・分析基盤“Greco”の紹介

– ンフラについての話がメンになります

– 特に最近サービスンしたAmazon Redshiftについての使用感を重点的にお伝えします

• ユーザー企業側の導入事例はまだ稀有なはず

• 分析に耐えうる「正確な」ログを作るために

– タトル開発の現場で実践できることをお話しします

発表の流れ

2 本発表は個人の見解であり、所属する組織の公式見解ではありません

• 名前の由来は 映画 Ocean‘s Thirteen(2007)から

– カジノの併設ホテルを守る、人工知能セキュリテゖという設定

– 映画のGrecoはこんなに凄い！

• 瞳孔や体温から顧客の感情を推定

• Exabyteのデータをリゕルタム分析

• 派手なモニタルーム

– けどリブート中にカジノが侵入されるというオチ

• 人工的に地震を発生→システム再起動

• GrecoはAmazon Web Services (AWS)を全面採用

– 映画のようにはいきません

データ集約・分析基盤 “Greco”

3

• ゲームログの用途

• ゲームログの種類

• 上記のニーズに耐えられるシステムが求められる

ゲームログの用途と種類

ユーザーサポート 集計・分析

処理内容 On-Line Transaction Processing 単一レコードの取得がメン

On-Line Analytical Processing 大量レコードの集計がメン

システム要求

ログの書き込み速度 １クエリ当たりのレテンシ

データ容量とクエリ性能に対するスケーラビリテゖ

イベントログ アクセスログ

形式 JSON（構造化データ） 平文（非構造化データ）

システム要求

欠落がないこと 常時処理（タムラグ重視）

複雑な前処理が出来ること バッチ処理（１日１回）前提

4

5

• ゲームログの用途とその出力先

• ゲームログの種類とその前処理

Grecoの選択

ユーザーサポート 集計・分析

処理内容 On-Line Transaction Processing 単一レコードの取得がメン

On-Line Analytical Processing 大量レコードの集計がメン

システム要求

ログの書き込み速度 １クエリ当たりのレテンシ

データ容量とクエリ性能に対するスケーラビリテゖ

出力先 Amazon RDS (MySQL) Amazon Redshift

イベントログ アクセスログ

形式 JSON（構造化データ） 平文（非構造化データ）

システム要求

欠落がないこと 常時処理（タムラグ重視）

複雑な前処理が出来ること バッチ処理（１日１回）前提

前処理

(ETL)

EC2で全件RDS/Redshiftに挿入 ※RDSはパーテゖション必須

Hadoop (Elastic MapReduce) で処理してからRedshiftに挿入

システム構成図（AWS+オンプレ）

6 ※Hadoop周りは単純化しております。クローラー、リゕルタムモニタ、ユーザーサポート系は割愛しています。

ベントログの収集については、 • Grecoチームで開発した

ものを組み込むケース • プロジェクト側の運用に

合わせるケース の２つがある ※Fluentdを採用しているプロジェクトも複数あり ※S3をゕーカブ先としているのは共通

コンソールゲーム機や、モバル端末からの入力を受け持つサーバーを指す

• データウェアハウス(Data Ware House, DWH)の定義

– Wikipediaより

In computing, a data warehouse or enterprise data warehouse (DW, DWH, or EDW) is a database used for reporting and data analysis.

• 一言でいえば

– 大規模集計のためのデータベース （より正確にはOLTPではなくOLAPに特化したRDB）

– 巨大テーブルからのSELECTは得意だが、UPDATEやDELETEが苦手（出来ないものもある）

– 数１００万行以上のレコードから集計したいときに、初めて採用を検討すべきもの（速いRDBではない！）

そもそもデータウェゕハウスって何？

7

• カラムナデータベース(Columnar Database)

– 大量の行に対する集約処理が得意

• 逆に少数の行や大量の列の取得は苦手

– データ圧縮によるI/O・ストレージ削減の効果が高い

• カーデゖナリテゖ（集合の要素の数）が低いデータや、正規化されていない（JOIN不要な）データほど有利

– ンデックスやテーブルパーテゖションは自動的に設定されているものと考えて良い

• 超並列(Massively Parallel Processing, MPP)

– シャーデゖングを自動化できる

• ノード数を増やすことで、データの挿入や操作が分散処理で行えるようになる

近年のDWHの２大特徴

8

• PostgreSQL互換のものが多い

– Amazon Redshift は ParAccel を AWSに載せたもの

代表的な商用DWH (2013/6 ver.)

特徴 互換性

Oracle Exadata MPP Oracle

Teradata Aster MPP Postgre

IBM Netezza MPP Postgre

SAP Sybase IQ MPP TDS

MS SQLServer 2012 P.D.W. MPP TDS

EMC Greenplum MPP Postgre

Actian ParAccel MPP Postgre

HP Vertica MPP Postgre

Infobright SMP MySQL

Calpont InfiniDB MPP MySQL

[1] Gartner : "Dataware house DBMS magic quadrant". Dashboard Insight. February 2, 2013. 9

※ParAccelは2013年4月にActianに買収される

• ゲーム業界での採用事例

– HP Vertica

• Zynga

– Oracle Exadata

• Square Enix

• 導入のネック「一言でいうと高い！」

• 安いもの（HWは自前で用意）で初期投資 数１００万

• ゕプラゕンス製品なら数１０００万円を要覚悟

• 弊社のケース

– 様々なDWHを検証後、費用対効果を吟味し、Amazon Redshift ($1,000 ～ /TB/1Y)の導入を決断

DWHとゲーム業界

10

• パフォーマンスについて

– 集計は本当に楽になりました

• かなり無茶なSQLでも即なくこなせるように

• PostgreSQL 8.4の共通テーブル式が一部使えます

– WITH xxx AS (SELECT …) SELECT … from xxx, ….

• PostgreSQL 8.4のウゖンドウ関数も一部使えます

– SELECT RANK() OVER (PARTITION BY xxx ORDER BY yyy) …

• ARRAY型は使えません（これが一番残念）

– Redshift独自のチューニングやマグレーションについての知識は必須

• 以降のスラドにて解説

Amazon Redshiftを導入してみて

11

• インデックスにもいろいろある

• DWHはHash型がデフォルトというケースが多い

– OracleやPostgreSQLでいうBitmapンデックス

– 範囲検索を多用する場合はDDLでの指定が望ましい

Redshiftのチューニング

アルゴリズム Hash B-Tree LSM-Tree

機能・性質 等価検索のみ Bitmap Index可 In Memory向け

範囲検索可 Read性能重視 HDD向け

範囲検索可 Write性能重視 SSD向け

write 定数Order 1回のrandom I/O append

read 定数Order 1回のrandom I/O N回のrandom I/O

採用例 Postgre(Bitmap) Oracle(Bitmap) Memcached

Postgre(Default) Oracle(Default) MongoDB

Cassandra Hbase LevelDB

12

• DISTKEY

– 分散処理に用いるキーを指定

• RDSでいうShardingの基準としたいキー

• １つだけ指定可能

– JOINを多用するキーに指定するのが適切

• ユーザーID と 年月日、どちらが望ましいかは用途次第

• SORTKEY

– 範囲検索したいキーを指定

– 時系列ログなら例外なく生成日時が適切

– ログの種類に応じてユーザーステータスも

• ゲームなら例えばユーザーLV

• (1-10), (11-20) … と集計することが多いため

DDLの記述（キー指定）

13

• 基本はテーブル設計時に決める

– 自動カラム圧縮機能もあるが…

• 空のテーブルに100,000 /slice以上のレコードをS3経由でバルクンサートしたときのみ有効

• つまり頼りづらい

• 特に有用（使いやすい）なものは以下の２つ

– 辞書型(TEXT255, TEXT32K, BYTEDICT)

• カーデゖナリテゖ（集合の要素の数）が低いものに適用

• Enumを文字列で代用している場合とか

– 差分型(DELTA)

• Auto Incrementなカラムは迷わずこれ

DDLの記述（圧縮の指定）

14

• どのリージョンにするかは超重要

– 同一リージョンにあるS3上のフゔルからしか、Bulk Insertが出来ない

– s3cmdの転送速度が最大のボトルネックとなることも

• MySQLのTIMESTAMPデフォルト値

– 0000/00/00 00:00:00はMySQL固有のルール

– 標準SQLに準拠しないのでLOAD時にエラー

• DELETEは速いが容量は減らない

– Redshiftは追記型（PostgreSQLの仕様を踏襲）

– よって定期的なVACUUMが必須

– DELETEやUPDATEは必要最小限に

DBからのマグレーション注意点

15

16

• 最後に社内の取り組みの話を少しします

ここで何かご質問は？

• ログは出力する時点で構造化されているべき

– この思想を普及させたFluentdの功績はあまりに大きい

• だがそれだけで十分か？

– No

– 人為的なミスが紛れ込む要素はまだ多い

• 型が違う（数値と文字列）

• 外部キーが入るフゖールドで違うテーブルを参照

• そもそもフゖールドが欠落したレコードがある

etc…

– やっぱり制約が豊富なRDBMSって偉大だったんだなと思うことが毎日のように…

• まずはログ生成のプロセスを見直しましょう

分析に耐え得るログを出力するために

17

18

• 前提条件

– 実装担当者の裁量に任せず、企画者や分析担当者の意見を反映した上で、仕様をかっちり決める

• その上で必要なコード出力を自動化

– ログのスキーマを何らかのフォーマットで記述

• 参考： Google Protocol Buffers, Open Data Protocols

– ログ仕様から下記コードを生成するコンバータを用意

• SQLのデータ定義言語(DDL)

• ベントログ(JSON)の出力関数

• 上記を徹底することで単純なミスを大幅に減らせる

– 実行時に難しいものは、ステージング環境でレポート出力(これも極力自動化）を行うなど、工夫を重ねる

開発の現場で実践すべきこと