Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWSのEKS環境でログ機能を構築/リリースしたお話
Search
gree_tech
PRO
October 13, 2023
Technology
0
580
AWSのEKS環境でログ機能を構築/リリースしたお話
GREE Tech Conference 2023で発表された資料です。
https://techcon.gree.jp/2023/session/TrackB-6
gree_tech
PRO
October 13, 2023
Tweet
Share
More Decks by gree_tech
See All by gree_tech
kustomizeをいい感じに使う方法
gree_tech
PRO
5
3.1k
スケーラビリティとコスト管理 Google Cloud Spanner 費用最適化の取り組み
gree_tech
PRO
0
900
「アナザーエデン 時空を超える猫」の5年前のログを引っ越してデータドリブンで事業運用プロセスを改善した話
gree_tech
PRO
0
640
Unity,PHP+Jenkins+GAS 多言語対応を意識させない開発を目指したシステム構築
gree_tech
PRO
0
1.1k
全社総会における「REALITY Spaces」の活用と、Addressableを用いたコンテンツ配信技術について
gree_tech
PRO
0
750
「ヘブンバーンズレッド」の大規模アップデートにおける国内及び翻訳QAの取り組み
gree_tech
PRO
0
690
アプリ「REALITY」の12言語対応プロセスの仕組みと品質向上の取り組み
gree_tech
PRO
0
1k
REALITYアプリのメンテナンスなしでの機能リリースを実現する、Istio導入とB/Gデプロイ実現の取り組み
gree_tech
PRO
1
810
Web3のバリデーター運営の開始、運用、課題、今後の取り組みについて
gree_tech
PRO
0
1.3k
Other Decks in Technology
See All in Technology
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
380
JEP 480: Structured Concurrency
aya_ebata
0
130
Google CloudのLLM活用の選択肢を広げるVertex AIのパートナーモデル
nayuts
0
130
eBPFのこれまでとこれから
yutarohayakawa
9
3.1k
不動産tech Product Night#2_AIことはじめ_GA橋本
takehikohashimoto
0
180
不動産 x AIことはじめ~データの真価を拓くために
estie
0
110
PDF Viewer作成の今までとこれから
hunachi
0
400
Privacy Sandbox on Android / DroidKaigi 2024
7pairs
1
240
LINEヤフーのフロントエンド組織・体制の紹介
lycorp_recruit_jp
1
1.2k
DroidKaigi 2024 たすけて!ViewModel
mhidaka
5
880
グイグイ系QAマネージャーの仕事
sadonosake
0
290
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
550
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
334
56k
YesSQL, Process and Tooling at Scale
rocio
167
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
230
17k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
354
29k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
Gamification - CAS2011
davidbonilla
79
5k
Mobile First: as difficult as doing things right
swwweet
221
8.8k
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
8.9k
Creatively Recalculating Your Daily Design Routine
revolveconf
215
12k
Transcript
AWSのEKS環境でログ機能 を構築/リリースしたお話 グリーエンターテインメント株式会社 エンジニアマネージャー 菅澤 要平
自己紹介 氏名:菅澤 要平 所属:グリーエンターテインメント株式会社 / 開発本部 /エンジニア部 担当:エンジニアマネージャー - 運営中タイトルのエンジニアリング全般のマネジメント
- エンジニア部の横断活動 経歴: - 2009年:WEBシステム開発会社(非ゲーム 主にBtoB) - 2017年:ファンプレックス株式会社 - サーバーエンジニアとして JOIN - 現グリーエンターテインメント株式会社 2
グリーエンターテインメントについて 3
IPプロデュース事業 4
ゲーム事業 5
6
目次 - はじめに - システム概要 - ログの重要性 - ログ周りの構成 -
リリース後〜発生した事象と対応 - まとめ 7
はじめに 8
グリーエンターテインメント社で開発したゲームタイトルにおいて、ログ機能を1から構築 した際のお話をさせていただきます。 今回はサーバーサイドのログについてとなります。 どのようなログをどのように収集しているか、開発/運用時にどのようなことを気をつけて おくとよいかということを紹介させていただきます。 はじめに 9
ログの重要性 10
ログというと、エンジニアしか関係ないと思われがちですが、 実際にはエンジニアだけでなく、プロダクトに関わる全員にとってとても重要なものだと 思っています。 11
リリース前は、「不具合解消」や「品質向上」に全力を注ぎがちです。 しかし、アプリを運営していくうえでPDCAサイクルを回すのはとても重要です。アプリの 寿命に直結するといっても過言でありません。 そのPDCAを回すためにもログ収集/分析は不可欠です。 12
リリース前に、下記の定義をプロダクト内で認識合わせしておくのが重要です。 - 取得すべき基本KPI - 各施策で振り返るべきログの定義 - イベント参加率 - 目玉報酬の獲得率 -
ランキング帯ごとの課金額 - etc もちろん、全て完璧に定義出来るわけは無いので、リリース後でも柔軟に追加で取得できるよう な構成にしておくのが大事です。 施策のQAとは別に、意図したとおりのログが取得出来ているかの検証も行えていればベストで す。 13
また、 ログについては一部の人だけが認識していてもあまり意味はありません。 「どこに注力すべきなのか?」というようなプロダクト方針がブレずに全員同じ認識になっ ていることがとても重要です。 そのためにプロダクトにJOINしているメンバーにはいつでも同じデータ(ログ)にアクセ ス出来るようにしておくのが望ましいです。 14
- Redash等を使用してブラウザ等で手軽にアクセスできる - 定例等の場で共有を地道に行う コレをやれば簡単に共有できる!というのはなく、地道に共有を続け、少しでも変化があ ればそれに気付けるように、全員の関心度を上げていくのが大事だと思います。 基本KPIについて、毎日メンバーが持ち回りで共有/考察を入れていっても良いかもしれ ません。 15
1. 施策リリース前にプランナーからエンジニアに取得してほしいログの依頼がくる - より効率のいいログがあればエンジニアからのFBをすることもある 2. ログの実装 3. 施策リリース後、プランナーがRedashでログの集計/可視化を実施 4. プロダクト内で共有
5. 次回リリースに向けて、分析 / 追加するログの検討 6. 1に戻る 16 実際にグリーエンターテインメントでは
17
システム概要 18
システム概要 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
ログの種類 21 種類 出力 保存場所 主な用途 PHP / apacheのログ 標準出力
cloudwatch エラー検知 アプリケーションログ 各nodeのス トレージ s3 KPI分析 取り扱うログは以下の2種類です。
22
PHP / apacheのログ PHPやapacheで出力しているログです。 主にPHP(logger含む)で出力されるWarningやErrorログです。 参照する場合はAmazonCloudWatch経由で参照しています。 - AWS標準の機能である - エンジニアしか参照しないので最低限、日時指定で検索できれば問題なし
23
アプリケーションログ 分析用のログです。 アクセスログやガチャの実行ログといったようなものになります。 それぞれのログを組み合わせて集計して分析に活用しています。 SQLで操作できるとプランナーが自由に集計して分析できるようになるので、Athena経 由で参照できるようにしています。 24
アプリケーションログの種類 一部抜粋 25 access アクセスログ user_data ログイン時のuser情報。1日1回のログイン時。 pay 課金ログ consume
石の消費ログ issuing 石の獲得ログ gift プレゼントボックスからのアイテムの出し入れのログ mission 各ミッションの進行ログ gacha_log ガチャの実行ログ item_consume 各アイテムの消費ログ item_gain 各アイテムの獲得ログ
アプリケーションログについてもう少し詳しく 26
ログの出力例 json形式でログ別にファイル出力しています。 出力先のディレクトリはnodeのストレージとなっています。 27 例) /applog/pod-A/access.log /applog/pod-A/pay.log /applog/pod-B/access.log /applog/pod-B/pay.log
ログの最終的な配置例 「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’
パーティションについて パーティションの設定を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
中間テーブルについて 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
中間テーブルについて 中間テーブル作成は、Lambdaから日次でAthenaでinsert-select文を実行すること で、中間テーブルを作成しています。 利便性向上の他にも、集計時のスキャンするデータ量が減らせるため、費用削減にも繋 がります。 32
リリース後、発生した事象と対策 33
事象1 アプリケーションログの欠損 34
発生したこと 各種アプリケーションログをみていたところ、明らかに格納されているべきログが athenaから検索しても抽出されない。 35
原因 fluent-bitで下記のエラーが発生していた ①.「Thoughput limits may have been exceeded.」 ②.「xxx have
long lines. Skipping long lines.」 36
原因 ①.「Thoughput limits may have been exceeded.」 - 「fluent-bit」→「KinesisFirehose」へのログ送信時に「KinesisFirehose」側の受 信時のthroughtput上限に引っかかっていました。
②.「xxx have long lines. Skipping long lines.」 - 対象のログの1行のサイズが「fluent-bit」の読み込みのバッファサイズの上限を超 えていました。 37
原因 38 ② ①
暫定対応 39 - 出力するアプリケーションログを一部止める - 課金等の重要なもののみにする - WAFのログについては欠損していないので、そちらでカバー - どのユーザーが、どのAPIを実行したかはわかる
- 課金周りのログについては別のログを参照する - 別途基盤チームにサマリのログを提供してもらう - Adjustのログを参考にする
根本対応 - 「Thoughput limits may have been exceeded.」 - 「KinesisFirehose」の「Delivery
Stream Throughput」について、AWS へ上限緩和申請をだす - 「xxx have long lines. Skipping long lines.」 - 「fluent-bit」の読み込みバッファサイズの上限の引き上げ 40
事象2 ログインユーザーの現在のLvがわからない 41
発生したこと 別アプリとの連動施策で「本アプリをプレイしよう」というのがあり、さらに本アプリでのLv に応じて、別アプリの方でアイテムがもらえるものがありました。 「user_data」(ログイン時のuser情報ログ)に、Lvが記録されているのでそこから集計 をし、何件かピックアップしてアプリのサポートツールの情報と比較していたところLvが ズレているユーザーがいました。 42
原因 施策のために、その日だけインストールしてプレイしたユーザーの方は最終的なLvが保 持されていない。ユーザーのレベルのログはログインボーナス獲得時のログにしか存在 したいため。 43
原因 44 チュートリアル ログインボーナス ゲームプレイ レベルアップ この時点でレベルのログが保存さ れる。 もちろんLv1。 翌日以降ログインしないと、最新の
レベルがログに保存されない。
暫定対応 45 シャーディングされているDBから直接select
根本対応 46 (未対応ですが) - アクセスログにLvを追加する - 別途Lvアップのログを追加する
教訓 47 ログを使用して施策を実施する際は、実施前の検討段階できちんとユースケースを洗い 出して、そのログを使用するのが妥当なのかの確認をしっかり行うべきでした。 ログがおかしかった場合、分析であれば最悪次回からきれいにしようで済みますが、施 策の場合はそういう訳にはいきません。
ちなみに 48 今回のような、別システムからIDのリストをもらってアプリのログと付き合わせることはよ くあるケースかと思います。 Athena + Redashの環境だと、SQLに知見があり後はAthenaの「create table」文 を理解していれば、 1.
IDのリストをS3に配置し、Athenaに「別システムから連携されたIDのテーブル」を 作成 2. redash上で1のテーブルとログをJOINしてデータ抽出 というフローでデータ抽出がEN以外でも実施できます。
まとめ 49
まとめ 50 - 必要なログについてはリリース前に定義をきちんとしておくと良いです。 - 運用が始まってからも必要なログは変動するので、後から追加しやすい構成にして おくのが良いです。 - アプリケーションログについては、プロダクトの方針決定に使用するものなので、全 員が手軽に参照できるようにしておくと良いです。
- 全員が同じ認識を持てるように関心度を上げる取り組みも必要 - ログについても検証をしっかりと実施しておくと安心です。 - 意図したログが保存出来ているか - 高負荷時でも問題なくログが保存できるか
ご清聴ありがとうございました 51