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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール内製モジュールを通してユーザーのツール実行ログを送信する ① ツールからのログ送信

Lambda Amazon EventBridge AWS SAM Slack TA ユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール受け取ったログを整形してログのデータベースに転送する ②ログの受信・整形・転送

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 で対応してないものあり

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

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

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

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 実際のコード

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

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

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用意するだけで可能になる)

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

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/

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

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

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

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

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

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

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

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

More Decks by Cygames

Other Decks in Technology

Featured

Transcript