Slide 1
Slide 1 text
AWSのEKS環境でログ機能
を構築/リリースしたお話
グリーエンターテインメント株式会社
エンジニアマネージャー
菅澤 要平
Slide 2
Slide 2 text
自己紹介
氏名：菅澤 要平
所属：グリーエンターテインメント株式会社 / 開発本部 /エンジニア部
担当：エンジニアマネージャー
- 運営中タイトルのエンジニアリング全般のマネジメント
- エンジニア部の横断活動
経歴：
- 2009年：WEBシステム開発会社（非ゲーム 主にBtoB）
- 2017年：ファンプレックス株式会社
- サーバーエンジニアとして JOIN
- 現グリーエンターテインメント株式会社
2
Slide 3
Slide 3 text
グリーエンターテインメントについて
3
Slide 4
Slide 4 text
IPプロデュース事業
4
Slide 5
Slide 5 text
ゲーム事業
5
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
目次
- はじめに
- システム概要
- ログの重要性
- ログ周りの構成
- リリース後〜発生した事象と対応
- まとめ
7
Slide 8
Slide 8 text
はじめに
8
Slide 9
Slide 9 text
グリーエンターテインメント社で開発したゲームタイトルにおいて、ログ機能を1から構築
した際のお話をさせていただきます。
今回はサーバーサイドのログについてとなります。
どのようなログをどのように収集しているか、開発/運用時にどのようなことを気をつけて
おくとよいかということを紹介させていただきます。
はじめに
9
Slide 10
Slide 10 text
ログの重要性
10
Slide 11
Slide 11 text
ログというと、エンジニアしか関係ないと思われがちですが、
実際にはエンジニアだけでなく、プロダクトに関わる全員にとってとても重要なものだと
思っています。
11
Slide 12
Slide 12 text
リリース前は、「不具合解消」や「品質向上」に全力を注ぎがちです。
しかし、アプリを運営していくうえでPDCAサイクルを回すのはとても重要です。アプリの
寿命に直結するといっても過言でありません。
そのPDCAを回すためにもログ収集/分析は不可欠です。
12
Slide 13
Slide 13 text
リリース前に、下記の定義をプロダクト内で認識合わせしておくのが重要です。
- 取得すべき基本KPI
- 各施策で振り返るべきログの定義
- イベント参加率
- 目玉報酬の獲得率
- ランキング帯ごとの課金額
- etc
もちろん、全て完璧に定義出来るわけは無いので、リリース後でも柔軟に追加で取得できるよう
な構成にしておくのが大事です。
施策のQAとは別に、意図したとおりのログが取得出来ているかの検証も行えていればベストで
す。
13
Slide 14
Slide 14 text
また、
ログについては一部の人だけが認識していてもあまり意味はありません。
「どこに注力すべきなのか？」というようなプロダクト方針がブレずに全員同じ認識になっ
ていることがとても重要です。
そのためにプロダクトにJOINしているメンバーにはいつでも同じデータ（ログ）にアクセ
ス出来るようにしておくのが望ましいです。
14
Slide 15
Slide 15 text
- Redash等を使用してブラウザ等で手軽にアクセスできる
- 定例等の場で共有を地道に行う
コレをやれば簡単に共有できる！というのはなく、地道に共有を続け、少しでも変化があ
ればそれに気付けるように、全員の関心度を上げていくのが大事だと思います。
基本KPIについて、毎日メンバーが持ち回りで共有/考察を入れていっても良いかもしれ
ません。
15
Slide 16
Slide 16 text
1. 施策リリース前にプランナーからエンジニアに取得してほしいログの依頼がくる
- より効率のいいログがあればエンジニアからのFBをすることもある
2. ログの実装
3. 施策リリース後、プランナーがRedashでログの集計/可視化を実施
4. プロダクト内で共有
5. 次回リリースに向けて、分析 / 追加するログの検討
6. 1に戻る
16
実際にグリーエンターテインメントでは
Slide 17
Slide 17 text
17
Slide 18
Slide 18 text
システム概要
18
Slide 19
Slide 19 text
システム概要
19
インフラ Amazon Web Services
主な使用言語 PHP 7.4 （FWはphalconベース）
Webサーバー apache 2.4
DBサーバー Amazon Aurora
キャッシュサーバー Amazon ElastiCache（redis, memcached）
CDN Akamai
オーケストレーションツール Kubernetes
デプロイツール Argo CD
BIツール redash
DWH Amazon Athena
Slide 20
Slide 20 text
ログ周りの構成について
20
Slide 21
Slide 21 text
ログの種類
21
種類 出力 保存場所 主な用途
PHP / apacheのログ 標準出力 cloudwatch エラー検知
アプリケーションログ 各nodeのス
トレージ
s3 KPI分析
取り扱うログは以下の2種類です。
Slide 22
Slide 22 text
22
Slide 23
Slide 23 text
PHP / apacheのログ
PHPやapacheで出力しているログです。
主にPHP（logger含む）で出力されるWarningやErrorログです。
参照する場合はAmazonCloudWatch経由で参照しています。
- AWS標準の機能である
- エンジニアしか参照しないので最低限、日時指定で検索できれば問題なし
23
Slide 24
Slide 24 text
アプリケーションログ
分析用のログです。
アクセスログやガチャの実行ログといったようなものになります。
それぞれのログを組み合わせて集計して分析に活用しています。
SQLで操作できるとプランナーが自由に集計して分析できるようになるので、Athena経
由で参照できるようにしています。
24
Slide 25
Slide 25 text
アプリケーションログの種類
一部抜粋
25
access アクセスログ
user_data ログイン時のuser情報。1日1回のログイン時。
pay 課金ログ
consume 石の消費ログ
issuing 石の獲得ログ
gift プレゼントボックスからのアイテムの出し入れのログ
mission 各ミッションの進行ログ
gacha_log ガチャの実行ログ
item_consume 各アイテムの消費ログ
item_gain 各アイテムの獲得ログ
Slide 26
Slide 26 text
アプリケーションログについてもう少し詳しく
26
Slide 27
Slide 27 text
ログの出力例
json形式でログ別にファイル出力しています。
出力先のディレクトリはnodeのストレージとなっています。
27
例)
/applog/pod-A/access.log
/applog/pod-A/pay.log
/applog/pod-B/access.log
/applog/pod-B/pay.log
Slide 28
Slide 28 text
ログの最終的な配置例
「fluent-bit」 →「 Kinesis Firehose」を通してs3に配置しています。
Athenaはスキャンしたデータ量による従量課金なので、時間でパーティションを作成しています。
例）2023/10/13 9時(UTC)台のアクセスログのs3への配置例
s3:///access/datehour=2023-10-13-09/xxxxxx.gz
Athenaから検索する際は下記のような
SQLで検索できます。
28
select *
from access
where datehour = ‘2023-10-13-09’
Slide 29
Slide 29 text
パーティションについて
パーティションの設定をAthenaでのcreate table時のオプションで設定
29
PARTITIONED BY (
‘datehour’ string)
TBLPROPERTIES (
‘projection.enabled’ = ‘true’,
‘projection.datehour.type’ = ‘date’,
‘projection.datehour.format’ = ‘yyyy-MM-dd-HH’
‘projection.datehour.interval.unit’ = ‘HOURS’,
‘projection.datehour.interval.unit’ = ‘1’,
‘projection.datehour.range’ = ‘2023-01-01-00, NOW’,
‘storage.location.template’ = ‘s3:///access/datehur=${datehour}’
)
Slide 30
Slide 30 text
中間テーブルについて
分析時の利便性のために、日次の積み上げデータとして中間テーブルを作成すること
はよくあると思います。
30
Slide 31
Slide 31 text
中間テーブルについて
31
ユーザーID 購入アイテム 消費石 消費日時間
111111111 ガチャA 3000 2023/10/13 10:00:00
22222222 ガチャA 3000 2023/10/13 20:00:00
33333333 ガチャB 1500 2023/10/13 15:00:00
日付 購入アイテム 購入ユーザー数 合計消費石
2023/10/13 ガチャA 2 6000
2023/10/13 ガチャB 1 1500
Slide 32
Slide 32 text
中間テーブルについて
中間テーブル作成は、Lambdaから日次でAthenaでinsert-select文を実行すること
で、中間テーブルを作成しています。
利便性向上の他にも、集計時のスキャンするデータ量が減らせるため、費用削減にも繋
がります。
32
Slide 33
Slide 33 text
リリース後、発生した事象と対策
33
Slide 34
Slide 34 text
事象1
アプリケーションログの欠損
34
Slide 35
Slide 35 text
発生したこと
各種アプリケーションログをみていたところ、明らかに格納されているべきログが
athenaから検索しても抽出されない。
35
Slide 36
Slide 36 text
原因
fluent-bitで下記のエラーが発生していた
①．「Thoughput limits may have been exceeded.」
②．「xxx have long lines. Skipping long lines.」
36
Slide 37
Slide 37 text
原因
①．「Thoughput limits may have been exceeded.」
- 「fluent-bit」→「KinesisFirehose」へのログ送信時に「KinesisFirehose」側の受
信時のthroughtput上限に引っかかっていました。
②．「xxx have long lines. Skipping long lines.」
- 対象のログの1行のサイズが「fluent-bit」の読み込みのバッファサイズの上限を超
えていました。
37
Slide 38
Slide 38 text
原因
38
②
①
Slide 39
Slide 39 text
暫定対応
39
- 出力するアプリケーションログを一部止める
- 課金等の重要なもののみにする
- WAFのログについては欠損していないので、そちらでカバー
- どのユーザーが、どのAPIを実行したかはわかる
- 課金周りのログについては別のログを参照する
- 別途基盤チームにサマリのログを提供してもらう
- Adjustのログを参考にする
Slide 40
Slide 40 text
根本対応
- 「Thoughput limits may have been exceeded.」
- 「KinesisFirehose」の「Delivery Stream Throughput」について、AWS
へ上限緩和申請をだす
- 「xxx have long lines. Skipping long lines.」
- 「fluent-bit」の読み込みバッファサイズの上限の引き上げ
40
Slide 41
Slide 41 text
事象2
ログインユーザーの現在のLvがわからない
41
Slide 42
Slide 42 text
発生したこと
別アプリとの連動施策で「本アプリをプレイしよう」というのがあり、さらに本アプリでのLv
に応じて、別アプリの方でアイテムがもらえるものがありました。
「user_data」（ログイン時のuser情報ログ）に、Lvが記録されているのでそこから集計
をし、何件かピックアップしてアプリのサポートツールの情報と比較していたところLvが
ズレているユーザーがいました。
42
Slide 43
Slide 43 text
原因
施策のために、その日だけインストールしてプレイしたユーザーの方は最終的なLvが保
持されていない。ユーザーのレベルのログはログインボーナス獲得時のログにしか存在
したいため。
43
Slide 44
Slide 44 text
原因
44
チュートリアル
ログインボーナス
ゲームプレイ
レベルアップ
この時点でレベルのログが保存さ
れる。
もちろんLv1。
翌日以降ログインしないと、最新の
レベルがログに保存されない。
Slide 45
Slide 45 text
暫定対応
45
シャーディングされているDBから直接select
Slide 46
Slide 46 text
根本対応
46
（未対応ですが）
- アクセスログにLvを追加する
- 別途Lvアップのログを追加する
Slide 47
Slide 47 text
教訓
47
ログを使用して施策を実施する際は、実施前の検討段階できちんとユースケースを洗い
出して、そのログを使用するのが妥当なのかの確認をしっかり行うべきでした。
ログがおかしかった場合、分析であれば最悪次回からきれいにしようで済みますが、施
策の場合はそういう訳にはいきません。
Slide 48
Slide 48 text
ちなみに
48
今回のような、別システムからIDのリストをもらってアプリのログと付き合わせることはよ
くあるケースかと思います。
Athena + Redashの環境だと、SQLに知見があり後はAthenaの「create table」文
を理解していれば、
1. IDのリストをS3に配置し、Athenaに「別システムから連携されたIDのテーブル」を
作成
2. redash上で1のテーブルとログをJOINしてデータ抽出
というフローでデータ抽出がEN以外でも実施できます。
Slide 49
Slide 49 text
まとめ
49
Slide 50
Slide 50 text
まとめ
50
- 必要なログについてはリリース前に定義をきちんとしておくと良いです。
- 運用が始まってからも必要なログは変動するので、後から追加しやすい構成にして
おくのが良いです。
- アプリケーションログについては、プロダクトの方針決定に使用するものなので、全
員が手軽に参照できるようにしておくと良いです。
- 全員が同じ認識を持てるように関心度を上げる取り組みも必要
- ログについても検証をしっかりと実施しておくと安心です。
- 意図したログが保存出来ているか
- 高負荷時でも問題なくログが保存できるか
Slide 51
Slide 51 text
ご清聴ありがとうございました
51