ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

2/73 自己紹介山城拓巳テクニカルアーティストチームモバイルゲーム開発会社での3Dアーティスト経験を経て、 2020年テクニカルアーティストとして株式会社 Cygames に合流。アーティスト向けの DCC ツールやゲームエンジン向けのツール開発に加え、 AWS を利用した Jira、ShotGrid 向けのパイプラインツール開発等を行っている。

Slide 3

Slide 3 text

3/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 4

Slide 4 text

4/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 5

Slide 5 text

5/73 1. 最近のゲーム事情と問題点 • プロジェクトの規模拡大 • 業務の専門化＆細分化

Slide 6

Slide 6 text

6/73 1. 最近のゲーム事情と問題点ツール数が増加し、保守コスト増加 • プロジェクトの規模拡大 • 業務の専門化＆細分化

Slide 7

Slide 7 text

7/73 1. 最近のゲーム事情と問題点 • 使われてないツールが整理され、改善予定のツール対応優先順位が整理されている • 新規ツールと既存ツールの優先度の判断ができる • 潜在的なエラーなどの問題がない保守コストが正常 • どれを優先しても良いかわからないので増え続けるツールを全て保守しなくてはならない • 新規ツールと既存ツールのどちらを進めるか判断できない • 伝えられていないエラー報告など潜在的な問題がある保守コストが高い

Slide 8

Slide 8 text

8/73 1. 最近のゲーム事情と問題点 • 使われてないツールが整理され、改善予定のツール対応優先順位が整理されている • 新規ツールと既存ツールの優先度の判断ができる • 潜在的なエラーなどの問題がない保守コストが正常 • どれを優先しても良いかわからないので増え続けるツールを全て保守しなくてはならない • 新規ツールと既存ツールのどちらを進めるか判断できない • 伝えられていないエラー報告など潜在的な問題がある保守コストが高いどうするべきか？

Slide 9

Slide 9 text

9/73 1. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素どの位使われているか？使用頻度どれを先に対応すべきか？対応優先度トラブルを起こしそうな物はあるか？潜在的な問題

Slide 10

Slide 10 text

10/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 11

Slide 11 text

11/73 2. ツール保守コスト削減の取り組みツールの利用状況をどう把握するか？アンケート、ユーザーに直接状況を聞くなどお互いにコストがかかり、大変なのでこれは避けたい… 自動的に利用状況を把握できる環境があるとよい

Slide 12

Slide 12 text

12/73 2. ツール保守コスト削減の取り組みカスタマイズ可能な内製のログ収集ツールを用意する自動的に利用状況を把握できる環境があるとよい

Slide 13

Slide 13 text

13/73 2. ツール保守コスト削減の取り組み利用ログ収集して利用状況を把握、分析するサービス「ツールログサービス」 =

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

15/73 1. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素どの位使われているか？使用頻度どれを先に対応すべきか？対応優先度トラブルを起こしそうな物はあるか？潜在的な問題

Slide 16

Slide 16 text

16/73 1. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素改善1 年間起動ログの集計使用頻度改善2 月間利用レポートのSlack通知対応優先度改善3 自動的なエラー通知潜在的な問題

Slide 17

Slide 17 text

17/73 2. ツール保守コスト削減の取り組み改善1 年間起動ログの集計 • 1年間の起動ログを集計 • 各ツールごとに利用頻度を表示可能 • 用途によって表示項目をカスタマイズ可能

Slide 18

Slide 18 text

18/73 使用頻度 2. ツール保守コスト削減の取り組み改善1 年間起動ログの集計利用されているかわからず整理できない使用頻度を把握、整理可能に！

Slide 19

Slide 19 text

19/73 2. ツール保守コスト削減の取り組み改善2 月間利用レポートの Slack 通知 • 1か月ごとの利用状況をSlackに通知 • 利用頻度が高いツールを認識可能

Slide 20

Slide 20 text

20/73 2. ツール保守コスト削減の取り組み改善2 月間利用レポートの Slack 通知利用状況がわからず優先度順位が決められない対応優先度を決められるように！対応優先度

Slide 21

Slide 21 text

21/73 2. ツール保守コスト削減の取り組み改善3 自動的なエラー通知 • ログにエラーが送信されたらSlackに通知 • 該当プロジェクト担当にメンション • 「エラーログを見る」から詳細へ移動可能

Slide 22

Slide 22 text

22/73 2. ツール保守コスト削減の取り組み改善3 自動的なエラー通知ユーザーからのエラー報告が必要潜在的な問題を把握可能に！潜在的な問題

Slide 23

Slide 23 text

23/73 2. ツール保守コスト削減の取り組み • 利用頻度が低いツールを整理できた (整理するとツールが半分ほどになる事例も) 改善1 年間起動ログの集計使用頻度改善2 月間利用レポートの Slack 通知 • 頻度の高いツールのバグ修正を優先的に行えるようになった • 利用頻度の変化を考察可能になった (ワークフローの変化、報告されてない不具合があるかなど) 対応優先度潜在的な問題改善3 自動的なエラー通知 • ユーザーが忙しく、TAへ報告されてなかったエラーを自動的に把握することができる様になった • 良くエラーが起きるツールの手順の整理やマニュアル見直しが行えるようになった

Slide 24

Slide 24 text

24/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 25

Slide 25 text

25/73 3. ツールログサービスの技術構成定期実行 Amazon EC2 Amazon OpenSearch Service AWS Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール

Slide 26

Slide 26 text

26/73 3. ツールログサービスの技術構成定期実行 Amazon EC2 Amazon OpenSearch Service AWS Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール内製モジュールを通してユーザーのツール実行ログを送信する ① ツールからのログ送信

Slide 27

Slide 27 text

27/73 3. ツールログサービスの技術構成定期実行 Amazon EC2 Amazon OpenSearch Service AWS Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール受け取ったログを整形してログのデータベースに転送する ②ログの受信・整形・転送

Slide 28

Slide 28 text

28/73 3. ツールログサービスの技術構成定期実行 Amazon EC2 Amazon OpenSearch Service AWS Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュールドキュメント型のデータベース上で可視化されたログの検索や集計、分析を行う ③ データベース上でのログの閲覧・分析

Slide 29

Slide 29 text

29/73 3. ツールログサービスの技術構成定期実行 Amazon EC2 Amazon OpenSearch Service AWS Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール ④ ログの集計と集計結果の Slack 通知データベースの情報を取得し、定期的にSlackに通知する

Slide 30

Slide 30 text

30/73 3. ツールログサービスの技術構成 ① ツールからのログ送信 ② ログの受信・整形・転送 ④ ログの集計と集計結果の Slack 通知 ③ データベース上でのログの閲覧・分析

Slide 31

Slide 31 text

31/73 3. ツールログサービスの技術構成 ① ツールからのログ送信利用技術・内製ログモジュール何をしているか？・あらかじめTAがツールにログ関数を入れる・ツールが実行されるとログが送信される

Slide 32

Slide 32 text

32/73 3. ツールログサービスの技術構成 ① ツールからのログ送信 • Python 標準の logging 同様に送信する • 実際のコード紹介は講演の後半 Loggerオブジェクト作成このログをツールに仕込むどうやって送信される？

Slide 33

Slide 33 text

33/73 3. ツールログサービスの技術構成 ② ログの受信・整形・転送利用技術・Fluentd 何をしているか？・ログの受け取り・ログの整形・ログデータベースへの登録

Slide 34

Slide 34 text

34/73 3. ツールログサービスの技術構成 ② ログの受信・整形・転送 Fluentd の動作イメージ fluentd.conf この中に文字を打ち込むログ送信 Match Match しない物は破棄される Filter ログの整形標準出力 Amazon OpenSearch Service Match したものを出力へ右図のデータフロー

Slide 35

Slide 35 text

35/73 3. ツールログサービスの技術構成 ② ログの受信・整形・転送 • ソフトウェアの表記揺れを対応する • Ruby製 • 単純な辞書比較による対応表記揺れ対応用のYaml Plugin 整形方法の例

Slide 36

Slide 36 text

36/73 利用技術・Amazon OpenSearch Service 何をしているか・ログを保持する・ログを検索や集計し、分析する 3. ツールログサービスの技術構成 ③ データベース上でのログの閲覧・分析

Slide 37

Slide 37 text

37/73 なにを分析する？ • 利用比率の円グラフ • 集計テーブル • 時間帯別の利用頻度グラフ • 地図表示 • ヒートマップなど • Amazon OpenSearch Service のベストプラクティス • https://docs.aws.amazon.com/ja_jp/opensearch- service/latest/developerguide/bp.html この中に文字を打ち込む大まかな位置を取得拠点固有問題対応のため 3. ツールログサービスの技術構成 ③ データベース上でのログの閲覧・分析

Slide 38

Slide 38 text

38/73 3. ツールログサービスの技術構成 ③ データベース上でのログの閲覧・分析 • ユーザー情報 • ユーザー名 • OSバージョン • 位置情報 • ツール情報 • タイムスタンプ • ツール名 • ツールカテゴリ • ツールバージョン • その他 • イベント • セッションID • ログレベル • メッセージ • 関数情報 • ファイル名 • 関数名 • 行番号 • 実行時間なにを集計する？

Slide 39

Slide 39 text

39/73 利用技術・AWS Lambda ・AWS Event Bridge ・AWS SAM 何をしているか・集計や Slack 通知・定期的な処理の実行・上記二つの自動生成 3. ツールログサービスの技術構成 ④ ログの集計と集計結果の Slack 通知

Slide 40

Slide 40 text

40/73 3. ツールログサービスの技術構成 ④ ログの集計と集計結果の Slack 通知 • OpenSearch へのデータの確認 • Slack への通知を担当 • 各機能は Python 製 AWS Lambda の補足 AWS Lambda この中に文字を打ち込む OpenSearchへ検索 Slack通知

Slide 41

Slide 41 text

41/73 • 定期実行が可能 • この方法で改善例の定期実行を行っている • 月間レポート(1か月ごとに実行) • エラー通知(15分ごとに実行) 3. ツールログサービスの技術構成 ④ ログの集計と集計結果の Slack 通知 Event Bridge の補足 AWS Lambda この中に文字を打ち込む OpenSearchへ検索 Slack通知定期実行 Amazon EventBridge

Slide 42

Slide 42 text

42/73 • Lambda と Event Bridge を一括で生成 • 15分ごとに実行指定 3. ツールログサービスの技術構成 ④ ログの集計と集計結果の Slack 通知定義ファイルの一部 SAM のリソース作成定義ファイル • Rate または Cron を使用したスケジュール式 • https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/services- cloudwatchevents-expressions.html 定期実行 AWS Lambda Amazon EventBridge AWS SAM

Slide 43

Slide 43 text

43/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 44

Slide 44 text

44/73 4.1. Amazon OpenSearch 4.2. 内製モジュール 4. 開発時のポイント紹介

Slide 45

Slide 45 text

45/73 4.1. Amazon OpenSearch 4.2. 内製モジュール 4. 開発時のポイント紹介

Slide 46

Slide 46 text

46/73 4.1. Amazon OpenSearch クラスター構成 • ツールログサービスは1ノード構成 • 公式では耐障害性や冗長性の観点から3ノードが推奨 • ログ収集ではそこまでスペック必要ないため1ノードに • Amazon OpenSearch Service のベストプラクティス • https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp.html

Slide 47

Slide 47 text

47/73 4.1. Amazon OpenSearch スペック設定 EC2は「r6g.large.search」を使用この中に文字を打ち込む以前の運用からlargeを選択したが、「t2.medium.search」でも良い • Amazon OpenSearch Service のベストプラクティス • https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp.html

Slide 48

Slide 48 text

48/73 4.1. Amazon OpenSearch インデックス設定 • インデックスは年単位を推奨 – 適切にインデックスのソースサイズとシャード数を計算しないとパフォーマンスに影響 – 日単位だと負荷が重くなり、ついにはインデックスが作れなくなった – 年間インデックスのリソースサイズが推奨される容量に収まっていたので、年単位に設定 • Amazon OpenSearch Service ドメインのサイジング • https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/sizing- domains.html#bp-sharding

Slide 49

Slide 49 text

49/73 4.1. Amazon OpenSearch マッピング設定 • 通常 – 新しい要素は自動的にフィールド追加される • { “tool_title”: “tool_01”, “abc” : “message” } • 赤字が自動で型を推論し、追加される • フィールド検証中は便利 • 後から自動挿入しない「strict」に変更する

Slide 50

Slide 50 text

50/73 4.1. Amazon OpenSearch マッピング設定 • 手順 1. 1通り必要なフィールドを入れたログを登録 2. フィールドが定まり次第、「 strict 」に設定この中に文字を打ち込むセキュリティ的にもおすすめ！ • マッピング設定 • https://www.elastic.co/guide/en/elasticsearch/reference/current /dynamic.html#dynamic-parameters

Slide 51

Slide 51 text

51/73 4.1. Amazon OpenSearch Reindex実行 • 新しい Index にコピーする必要がある = Reindex実行必要 • 日間インデックスを年間インデックスにマージする時なども同様マッピング適用しても既存 index にはマッピング情報は適用されない

Slide 52

Slide 52 text

52/73 4.1. Amazon OpenSearch Reindex実行 • 手順 1. フィールドの検証用でダイナミックで検証 2. マッピング設定する 3. 右図のように Reindex でマッピング設定を反映させる • Reindex API • https://www.elastic.co/guide/en/elasticsearch/reference/current /docs-reindex.html

Slide 53

Slide 53 text

53/73 4.1. Amazon OpenSearch 閲覧制限 • TAだけアクセス可能にする • 開発者には管理者、解析者には閲覧のみの権限 • セキュリティタブから簡単に設定可能 • 内部ユーザー作成 • https://docs.aws.amazon.com/ja_jp/ja_jp/opensearch- service/latest/developerguide/fgac-walkthrough- basic.html この中に文字を打ち込むセキュリティ的にもおすすめ！

Slide 54

Slide 54 text

54/73 4.1. Amazon OpenSearch OpenSearchへの移行 • コマンドでドメインからドメインへ index を移動できるツール • Json ファイルに書き出し、Json → Index登録なども可能「elasticdump input=“移行元” output=“移行先”」 • elasticdump Github • https://github.com/elasticsearch-dump/elasticsearch-dump elasticdump による移行が便利 Index Visualize Saved Object から Json形式で移行可能 ※ 一部 OpenSearch で対応してないものあり

Slide 55

Slide 55 text

55/73 4.1. Amazon OpenSearch 4.2. 内製モジュール 4. 開発時のポイント紹介

Slide 56

Slide 56 text

56/73 4.2. 内製モジュール送信するだけなら標準機能でもよいのになぜ内製モジュールを作ったのか？

Slide 57

Slide 57 text

57/73 4.2. 内製モジュールツールログサービスに色々な情報を付与した結果.. 送信が複雑になってしまった.. (ログに含めるユーザー情報やソフトウェア情報など)

Slide 58

Slide 58 text

58/73 4.2. 内製モジュール • 色々な情報をなるべく簡単に登録し、送信できないか • Python なら普段TAが使用している専用Pythonライブラリとして提供する！（元々TA内で共通ライブラリ開発の流れがあったのも幸いだった)

Slide 59

Slide 59 text

59/73 4.2. 内製モジュール Python標準モジュールに準拠したログ仕様この様に利用できると便利 • 実装参考 • https://docs.python.org/ja/3/library/logging.html#logging.Formatter • https://github.com/fluent/fluent-logger- python/blob/ace80f4c2bd0020fc16891440243663c612dd01e/fluent/handler.py#L15 実際のコード

Slide 60

Slide 60 text

60/73 4.2. 内製モジュール利用しやすいエラー送信 • メソッドとクラス用のデコレータを用意 • 特殊メソッド以外にメソッドデコレータを付与するこの様に利用できる • クラスデコレータ参考 • https://tr-ikym.hatenablog.com/entry/decorate-methods-inside-a-class-in-python 実際のコード

Slide 61

Slide 61 text

61/73 4.2. 内製モジュールシンプルな配布方法 Git リポジトリからpip installする形式 (PyPIにアップする様に、setup.py用意するだけで可能になる) 「python –m pip install git+“GitRepositoryURL”」

Slide 62

Slide 62 text

62/73 4.2. 内製モジュールシンプルな配布方法 • 理由 • プロジェクトによって Perforce、Git などがある • 内製 CLI ツール等のスタンドアロンツールのビルド自動化にも有効 • log 送信用のモジュール以外も内包される為、update 時に必要な物が入る形に Git リポジトリからpip installする形式 • pip 公式ドキュメント • https://pip.pypa.io/en/stable/cli/pip_install/#examples (PyPIにアップする様に、setup.py用意するだけで可能になる)

Slide 63

Slide 63 text

63/73 4.2. 内製モジュールコードドキュメントの自動生成 • MkDocs + Material for MkDocs で構築 – pythonのdocstringからコードドキュメントを自動生成 – 構築、公開が簡単 – StaticGenという集計サイトでPython分野で群を抜いて1位の人気(Start数) • 社内限定の閲覧サイトとして GitHub Pages で公開

Slide 64

Slide 64 text

64/73 4.2. 内製モジュール複数のPythonバージョンに対応したテストコード • 「tox」+「pytest」によりpy39, py38, py37 の各バージョンを自動テスト • DCCツールのバージョンにも対応した設計 Congratulations :) • https://tox.wiki/en/latest/ • https://docs.pytest.org/en/7.1.x/

Slide 65

Slide 65 text

65/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 66

Slide 66 text

66/73 5. 考察 / 利用状況把握の重要性と将来性 • 部署ごとのサポート割合を出し、サポートバランスを考える • 使用されてないツールを集計し、ツール紹介としてSlackで宣伝する保守コスト下げる目的以外にも... ⚫ 利用状況分析は守コストを下げることに有効だった ⚫ 分析、可視化はTA本来の業務ではないが、ツール開発後の指標に活用できる ⚫ 保守コストを下げるだけでなく色々なことに活用できそう

Slide 67

Slide 67 text

67/73 5. 考察 / そもそもなぜクラウド？ • 既にTAでレンダリングサーバーや Jenkins などを管理していた • 物理的に構築していると下記が大変だと感じていた – 引っ越し、スケールアップ、在宅業務の対応、管理者の継承... 物理サーバーの管理を避け、クラウドに移行したい

Slide 68

Slide 68 text

68/73 5. 考察 / TAがクラウドサービスはどうなのか？ • 当然メイン業務ではない • 様々なサービスがある事により学習コストはかかる解決方法の一つの武器としての選択 AWS Lambda TAが扱う様々な問題 Amazon EC2 Amazon OpenSearch Service クラウドの様々サービス解決方法の拡大

Slide 69

Slide 69 text

69/73 5. 考察 / CygamesTAのクラウドへの取り組み本講演以外にも... AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み [Cygames Tech Conference 2021] https://tech.cygames.co.jp/archives/3495/

Slide 70

Slide 70 text

70/73 5. 考察 / クラウドのセキュリティについて • 社内専門部署からのセキュリティのサポートは必須 • ツールログサービスも社内専門部署と協力して実現セキュリティには十分な注意を

Slide 71

Slide 71 text

71/73 ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4. 開発時のポイント紹介 5. 考察 6. まとめ

Slide 72

Slide 72 text

72/73 6. まとめ ⚫ 保守コストを下げるために把握すべき３つの要素 ⚫ 起動状況を分析することで、ツールを整理できる ⚫ 利用頻度を分析することで、対応優先度を判断できる ⚫ エラー通知をすることで、潜在的な問題に迅速に気づける ⚫ 利用状況の分析は保守コスト削減以外にもメリットがある利用状況の分析により保守コストを削減する ⚫ クラウドは、TAにとって強力な武器になる ⚫ 様々なサービスを学習することで解決方法の幅が広がる ⚫ 自動処理を行う上で物理サーバーから解放される恩恵は大きい ⚫ セキュリティには十分に注意しよう TAがクラウドに取り組む意義

Slide 73

Slide 73 text

73/73