AWSのEKS環境でログ機能を構築/リリースしたお話

GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackB-6

Transcript

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