第27回TokyoWebmining 講演資料 http://tokyowebmining27.eventbrite.com/ バンダイナムコスタジオのログ集計・分析基盤”Greco”では、Amazon RDSとEMR、そして最近では様々なデータウェアハウスを検証した上でRedshiftを活用しています。OLTPとOLAP、双方のニーズに応えるためにどんなシステム構成を取っているか、また分析に耐えうる正確なログ出力のためにどんな工夫が必要か、の２点を重点的にお伝えします。

1. 大規模ログ分析における
Amazon Web Services の活用
株式会社 バンダ゗ナムコスタジオ
ＮＥ開発本部 分析運営部
竹村 伸太郎
1

2. • ゲームログ分析の事例紹介
– 大人の事情により、弊社タ゗トルの話はございません
– 恐縮ながら、その代わりに論文を紹介させて下さい
• バンダイナムコスタジオの大規模ログ集約・分析基
盤“Greco”の紹介
– ゗ンフラについての話がメ゗ンになります
– 特に最近サービス゗ンしたAmazon Redshiftについての
使用感を重点的にお伝えします
• ユーザー企業側の導入事例はまだ稀有なはず
• 分析に耐えうる「正確な」ログを作るために
– タ゗トル開発の現場で実践できることをお話しします
発表の流れ
2
本発表は個人の見解であり、所属する組織の公式見解ではありません

3. • 名前の由来は 映画 Ocean‘s Thirteen(2007)から
– カジノの併設ホテルを守る、人工知能セキュリテゖと
いう設定
– 映画のGrecoはこんなに凄い！
• 瞳孔や体温から顧客の感情を推定
• Exabyteのデータをリゕルタ゗ム分析
• 派手なモニタルーム
– けどリブート中にカジノが侵入されるというオチ
• 人工的に地震を発生→システム再起動
• GrecoはAmazon Web Services (AWS)を全面採用
– 映画のようにはいきません
データ集約・分析基盤 “Greco”
3

4. • ゲームログの用途
• ゲームログの種類
• 上記のニーズに耐えられるシステムが求められる
ゲームログの用途と種類
ユーザーサポート 集計・分析
処理内容 On-Line Transaction Processing
単一レコードの取得がメ゗ン
On-Line Analytical Processing
大量レコードの集計がメ゗ン
システム
要求
ログの書き込み速度
１クエリ当たりのレ゗テンシ
データ容量とクエリ性能に対す
るスケーラビリテゖ
イベントログ アクセスログ
形式 JSON（構造化データ） 平文（非構造化データ）
システム
要求
欠落がないこと
常時処理（タ゗ムラグ重視）
複雑な前処理が出来ること
バッチ処理（１日１回）前提
4

5. 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に挿入

6. システム構成図（AWS+オンプレ）
6※Hadoop周りは単純化しております。クローラー、リゕルタ゗ムモニタ、ユーザーサポート系は割愛しています。
゗ベントログの収集につい
ては、
• Grecoチームで開発した
ものを組み込むケース
• プロジェクト側の運用に
合わせるケース
の２つがある
※Fluentdを採用しているプ
ロジェクトも複数あり
※S3をゕーカ゗ブ先として
いるのは共通
コンソールゲーム機
や、モバ゗ル端末か
らの入力を受け持つ
サーバーを指す

7. • データウェアハウス(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

8. • カラムナデータベース(Columnar Database)
– 大量の行に対する集約処理が得意
• 逆に少数の行や大量の列の取得は苦手
– データ圧縮によるI/O・ストレージ削減の効果が高い
• カーデゖナリテゖ（集合の要素の数）が低いデータや、
正規化されていない（JOIN不要な）データほど有利
– ゗ンデックスやテーブルパーテゖションは自動的に設
定されているものと考えて良い
• 超並列(Massively Parallel Processing, MPP)
– シャーデゖングを自動化できる
• ノード数を増やすことで、データの挿入や操作が分散処
理で行えるようになる
近年のDWHの２大特徴
8

9. • 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に買収される

10. • ゲーム業界での採用事例
– HP Vertica
• Zynga
– Oracle Exadata
• Square Enix
• 導入のネック「一言でいうと高い！」
• 安いもの（HWは自前で用意）で初期投資 数１００万
• ゕプラ゗ゕンス製品なら数１０００万円を要覚悟
• 弊社のケース
– 様々なDWHを検証後、費用対効果を吟味し、Amazon
Redshift ($1,000 ～ /TB/1Y)の導入を決断
DWHとゲーム業界
10

11. • パフォーマンスについて
– 集計は本当に楽になりました
• かなり無茶な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

12. • インデックスにもいろいろある
• 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

13. • DISTKEY
– 分散処理に用いるキーを指定
• RDSでいうShardingの基準としたいキー
• １つだけ指定可能
– JOINを多用するキーに指定するのが適切
• ユーザーID と 年月日、どちらが望ましいかは用途次第
• SORTKEY
– 範囲検索したいキーを指定
– 時系列ログなら例外なく生成日時が適切
– ログの種類に応じてユーザーステータスも
• ゲームなら例えばユーザーLV
• (1-10), (11-20) … と集計することが多いため
DDLの記述（キー指定）
13

14. • 基本はテーブル設計時に決める
– 自動カラム圧縮機能もあるが…
• 空のテーブルに100,000 /slice以上のレコードをS3経由で
バルク゗ンサートしたときのみ有効
• つまり頼りづらい
• 特に有用（使いやすい）なものは以下の２つ
– 辞書型(TEXT255, TEXT32K, BYTEDICT)
• カーデゖナリテゖ（集合の要素の数）が低いものに適用
• Enumを文字列で代用している場合とか
– 差分型(DELTA)
• Auto Incrementなカラムは迷わずこれ
DDLの記述（圧縮の指定）
14

15. • どのリージョンにするかは超重要
– 同一リージョンにあるS3上のフゔ゗ルからしか、Bulk
Insertが出来ない
– s3cmdの転送速度が最大のボトルネックとなることも
• MySQLのTIMESTAMPデフォルト値
– 0000/00/00 00:00:00はMySQL固有のルール
– 標準SQLに準拠しないのでLOAD時にエラー
• DELETEは速いが容量は減らない
– Redshiftは追記型（PostgreSQLの仕様を踏襲）
– よって定期的なVACUUMが必須
– DELETEやUPDATEは必要最小限に
DBからのマ゗グレーション注意点
15

16. 16
• 最後に社内の取り組みの話を少しします
ここで何かご質問は？

17. • ログは出力する時点で構造化されているべき
– この思想を普及させたFluentdの功績はあまりに大きい
• だがそれだけで十分か？
– No
– 人為的なミスが紛れ込む要素はまだ多い
• 型が違う（数値と文字列）
• 外部キーが入るフゖールドで違うテーブルを参照
• そもそもフゖールドが欠落したレコードがある
etc…
– やっぱり制約が豊富なRDBMSって偉大だったんだなと
思うことが毎日のように…
• まずはログ生成のプロセスを見直しましょう
分析に耐え得るログを出力するために
17

18. 18
• 前提条件
– 実装担当者の裁量に任せず、企画者や分析担当者の意
見を反映した上で、仕様をかっちり決める
• その上で必要なコード出力を自動化
– ログのスキーマを何らかのフォーマットで記述
• 参考： Google Protocol Buffers, Open Data Protocols
– ログ仕様から下記コードを生成するコンバータを用意
• SQLのデータ定義言語(DDL)
• ゗ベントログ(JSON)の出力関数
• 上記を徹底することで単純なミスを大幅に減らせる
– 実行時に難しいものは、ステージング環境でレポート
出力(これも極力自動化）を行うなど、工夫を重ねる
開発の現場で実践すべきこと