2022/08/24 CEDEC2022
View Slide
2/73自己紹介山城 拓巳テクニカルアーティストチームモバイルゲーム開発会社での3Dアーティスト経験を経て、2020年テクニカルアーティストとして株式会社 Cygames に合流。アーティスト向けの DCC ツールやゲームエンジン向けのツール開発に加え、AWS を利用した Jira、ShotGrid 向けのパイプラインツール開発等を行っている。
3/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
4/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
5/731. 最近のゲーム事情と問題点• プロジェクトの規模拡大• 業務の専門化＆細分化
6/731. 最近のゲーム事情と問題点ツール数が増加し、保守コスト増加• プロジェクトの規模拡大• 業務の専門化＆細分化
7/731. 最近のゲーム事情と問題点• 使われてないツールが整理され、改善予定のツール対応優先順位が整理されている• 新規ツールと既存ツールの優先度の判断ができる• 潜在的なエラーなどの問題がない保守コストが正常• どれを優先しても良いかわからないので増え続けるツールを全て保守しなくてはならない• 新規ツールと既存ツールのどちらを進めるか判断できない• 伝えられていないエラー報告など潜在的な問題がある保守コストが高い
8/731. 最近のゲーム事情と問題点• 使われてないツールが整理され、改善予定のツール対応優先順位が整理されている• 新規ツールと既存ツールの優先度の判断ができる• 潜在的なエラーなどの問題がない保守コストが正常• どれを優先しても良いかわからないので増え続けるツールを全て保守しなくてはならない• 新規ツールと既存ツールのどちらを進めるか判断できない• 伝えられていないエラー報告など潜在的な問題がある保守コストが高いどうするべきか？
9/731. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素どの位使われているか？使用頻度どれを先に対応すべきか？対応優先度トラブルを起こしそうな物はあるか？潜在的な問題
10/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
11/732. ツール保守コスト削減の取り組みツールの利用状況をどう把握するか？アンケート、 ユーザーに直接状況を聞くなどお互いにコストがかかり、大変なのでこれは避けたい…自動的に利用状況を把握できる環境があるとよい
12/732. ツール保守コスト削減の取り組みカスタマイズ可能な内製のログ収集ツールを用意する自動的に利用状況を把握できる環境があるとよい
13/732. ツール保守コスト削減の取り組み利用ログ収集して利用状況を把握、分析するサービス「ツールログサービス」=
15/731. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素どの位使われているか？使用頻度どれを先に対応すべきか？対応優先度トラブルを起こしそうな物はあるか？潜在的な問題
16/731. 最近のゲーム事情と問題点保守コスト削減のために把握すべき3要素改善1 年間起動ログの集計使用頻度改善2 月間利用レポートのSlack通知対応優先度改善3 自動的なエラー通知潜在的な問題
17/732. ツール保守コスト削減の取り組み改善1 年間起動ログの集計• 1年間の起動ログを集計• 各ツールごとに利用頻度を表示可能• 用途によって表示項目をカスタマイズ可能
18/73使用頻度2. ツール保守コスト削減の取り組み改善1 年間起動ログの集計利用されているかわからず整理できない使用頻度を把握、整理可能に！
19/732. ツール保守コスト削減の取り組み改善2 月間利用レポートの Slack 通知• 1か月ごとの利用状況をSlackに通知• 利用頻度が高いツールを認識可能
20/732. ツール保守コスト削減の取り組み改善2 月間利用レポートの Slack 通知利用状況がわからず優先度順位が決められない対応優先度を決められるように！対応優先度
21/732. ツール保守コスト削減の取り組み改善3 自動的なエラー通知• ログにエラーが送信されたらSlackに通知• 該当プロジェクト担当にメンション• 「エラーログを見る」から詳細へ移動可能
22/732. ツール保守コスト削減の取り組み改善3 自動的なエラー通知ユーザーからのエラー報告が必要潜在的な問題を把握可能に！潜在的な問題
23/732. ツール保守コスト削減の取り組み• 利用頻度が低いツールを整理できた (整理するとツールが半分ほどになる事例も)改善1 年間起動ログの集計使用頻度改善2 月間利用レポートの Slack 通知• 頻度の高いツールのバグ修正を優先的に行えるようになった• 利用頻度の変化を考察可能になった (ワークフローの変化、報告されてない不具合があるかなど)対応優先度潜在的な問題 改善3 自動的なエラー通知• ユーザーが忙しく、TAへ報告されてなかったエラーを自動的に把握することができる様になった• 良くエラーが起きるツールの手順の整理やマニュアル見直しが行えるようになった
24/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
25/733. ツールログサービスの技術構成定期実行Amazon EC2Amazon OpenSearchServiceAWS Lambda Amazon EventBridgeAWS SAMSlackTAユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール
26/733. ツールログサービスの技術構成定期実行Amazon EC2Amazon OpenSearchServiceAWS Lambda Amazon EventBridgeAWS SAMSlackTAユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール内製モジュールを通してユーザーのツール実行ログを送信する① ツールからのログ送信
27/733. ツールログサービスの技術構成定期実行Amazon EC2Amazon OpenSearchServiceAWS Lambda Amazon EventBridgeAWS SAMSlackTAユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール受け取ったログを整形してログのデータベースに転送する②ログの受信・整形・転送
28/733. ツールログサービスの技術構成定期実行Amazon EC2Amazon OpenSearchServiceAWS Lambda Amazon EventBridgeAWS SAMSlackTAユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュールドキュメント型のデータベース上で可視化されたログの検索や集計、分析を行う③ データベース上でのログの閲覧・分析
29/733. ツールログサービスの技術構成定期実行Amazon EC2Amazon OpenSearchServiceAWS Lambda Amazon EventBridgeAWS SAMSlackTAユーザーログ送信ツール実行データ解析通知クエリ・情報取得ログ整形登録ログモジュール④ ログの集計と集計結果の Slack 通知データベースの情報を取得し、定期的にSlackに通知する
30/733. ツールログサービスの技術構成① ツールからのログ送信② ログの受信・整形・転送④ ログの集計と集計結果の Slack 通知③ データベース上でのログの閲覧・分析
31/733. ツールログサービスの技術構成① ツールからのログ送信利用技術・内製ログモジュール何をしているか？・あらかじめTAがツールにログ関数を入れる・ツールが実行されるとログが送信される
32/733. ツールログサービスの技術構成① ツールからのログ送信• Python 標準の logging 同様に送信する• 実際のコード紹介は講演の後半Loggerオブジェクト作成このログをツールに仕込むどうやって送信される？
33/733. ツールログサービスの技術構成② ログの受信・整形・転送利用技術・Fluentd何をしているか？・ログの受け取り・ログの整形・ログデータベースへの登録
34/733. ツールログサービスの技術構成② ログの受信・整形・転送Fluentd の動作イメージfluentd.confこの中に文字を打ち込むログ送信MatchMatch しない物は破棄されるFilterログの整形標準出力Amazon OpenSearchServiceMatch したものを出力へ右図のデータフロー
35/733. ツールログサービスの技術構成② ログの受信・整形・転送• ソフトウェアの表記揺れを対応する• 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/733. ツールログサービスの技術構成③ データベース上でのログの閲覧・分析• ユーザー情報• ユーザー名• OSバージョン• 位置情報• ツール情報• タイムスタンプ• ツール名• ツールカテゴリ• ツールバージョン• その他• イベント• セッションID• ログレベル• メッセージ• 関数情報• ファイル名• 関数名• 行番号• 実行時間なにを集計する？
39/73利用技術・AWS Lambda・AWS Event Bridge・AWS SAM何をしているか・集計や Slack 通知・定期的な処理の実行・上記二つの自動生成3. ツールログサービスの技術構成④ ログの集計と集計結果の Slack 通知
40/733. ツールログサービスの技術構成④ ログの集計と集計結果の Slack 通知• OpenSearch へのデータの確認• Slack への通知を担当• 各機能は Python 製AWS Lambda の補足AWS Lambdaこの中に文字を打ち込むOpenSearchへ検索 Slack通知
41/73• 定期実行が可能• この方法で改善例の定期実行を行っている• 月間レポート(1か月ごとに実行)• エラー通知(15分ごとに実行)3. ツールログサービスの技術構成④ ログの集計と集計結果の Slack 通知Event Bridge の補足AWS Lambdaこの中に文字を打ち込むOpenSearchへ検索 Slack通知定期実行AmazonEventBridge
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 EventBridgeAWS SAM
43/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
44/734.1. Amazon OpenSearch4.2. 内製モジュール4. 開発時のポイント紹介
45/734.1. Amazon OpenSearch4.2. 内製モジュール4. 開発時のポイント紹介
46/734.1. Amazon OpenSearchクラスター構成• ツールログサービスは1ノード構成• 公式では耐障害性や冗長性の観点から3ノードが推奨• ログ収集ではそこまでスペック必要ないため1ノードに• Amazon OpenSearch Service のベストプラクティス• https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp.html
47/734.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/734.1. Amazon OpenSearchインデックス設定• インデックスは年単位を推奨– 適切にインデックスのソースサイズとシャード数を計算しないとパフォーマンスに影響– 日単位だと負荷が重くなり、ついにはインデックスが作れなくなった– 年間インデックスのリソースサイズが推奨される容量に収まっていたので、年単位に設定• Amazon OpenSearch Service ドメインのサイジング• https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/sizing-domains.html#bp-sharding
49/734.1. Amazon OpenSearchマッピング設定• 通常– 新しい要素は自動的にフィールド追加される• {“tool_title”: “tool_01”,“abc” : “message”}• 赤字が自動で型を推論し、追加される• フィールド検証中は便利• 後から自動挿入しない「strict」に変更する
50/734.1. Amazon OpenSearchマッピング設定• 手順1. 1通り必要なフィールドを入れたログを登録2. フィールドが定まり次第、「 strict 」に設定この中に文字を打ち込むセキュリティ的にもおすすめ！• マッピング設定• https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic.html#dynamic-parameters
51/734.1. Amazon OpenSearchReindex実行• 新しい Index にコピーする必要がある = Reindex実行必要• 日間インデックスを年間インデックスにマージする時なども同様マッピング適用しても既存 index にはマッピング情報は適用されない
52/734.1. Amazon OpenSearchReindex実行• 手順1. フィールドの検証用でダイナミックで検証2. マッピング設定する3. 右図のように Reindex でマッピング設定を反映させる• Reindex API• https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html
53/734.1. Amazon OpenSearch閲覧制限• TAだけアクセス可能にする• 開発者には管理者、解析者には閲覧のみの権限• セキュリティタブから簡単に設定可能• 内部ユーザー作成• https://docs.aws.amazon.com/ja_jp/ja_jp/opensearch-service/latest/developerguide/fgac-walkthrough-basic.htmlこの中に文字を打ち込むセキュリティ的にもおすすめ！
54/734.1. Amazon OpenSearchOpenSearchへの移行• コマンドでドメインからドメインへ index を移動できるツール• Json ファイルに書き出し、Json → Index登録なども可能「elasticdump input=“移行元” output=“移行先”」• elasticdump Github• https://github.com/elasticsearch-dump/elasticsearch-dumpelasticdump による移行が便利IndexVisualizeSaved Object から Json形式で移行可能※ 一部 OpenSearch で対応してないものあり
55/734.1. Amazon OpenSearch4.2. 内製モジュール4. 開発時のポイント紹介
56/734.2. 内製モジュール送信するだけなら標準機能でもよいのになぜ内製モジュールを作ったのか？
57/734.2. 内製モジュールツールログサービスに色々な情報を付与した結果..送信が複雑になってしまった..(ログに含めるユーザー情報やソフトウェア情報など)
58/734.2. 内製モジュール• 色々な情報をなるべく簡単に登録し、送信できないか• Python なら普段TAが使用している専用Pythonライブラリとして提供する！（元々TA内で共通ライブラリ開発の流れがあったのも幸いだった)
59/734.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/734.2. 内製モジュール利用しやすいエラー送信• メソッドとクラス用のデコレータを用意• 特殊メソッド以外にメソッドデコレータを付与するこの様に利用できる• クラスデコレータ参考• https://tr-ikym.hatenablog.com/entry/decorate-methods-inside-a-class-in-python実際のコード
61/734.2. 内製モジュールシンプルな配布方法Git リポジトリからpip installする形式(PyPIにアップする様に、setup.py用意するだけで可能になる)「python –m pip install git+“GitRepositoryURL”」
62/734.2. 内製モジュールシンプルな配布方法• 理由• プロジェクトによって Perforce、Git などがある• 内製 CLI ツール等のスタンドアロンツールのビルド自動化にも有効• log 送信用のモジュール以外も内包される為、update 時に必要な物が入る形にGit リポジトリからpip installする形式• pip 公式ドキュメント• https://pip.pypa.io/en/stable/cli/pip_install/#examples(PyPIにアップする様に、setup.py用意するだけで可能になる)
63/734.2. 内製モジュールコードドキュメントの自動生成• MkDocs + Material for MkDocs で構築– pythonのdocstringからコードドキュメントを自動生成– 構築、公開が簡単– StaticGenという集計サイトでPython分野で群を抜いて1位の人気(Start数)• 社内限定の閲覧サイトとして GitHub Pages で公開
64/734.2. 内製モジュール複数のPythonバージョンに対応したテストコード• 「tox」+「pytest」によりpy39, py38, py37 の各バージョンを自動テスト• DCCツールのバージョンにも対応した設計Congratulations :)• https://tox.wiki/en/latest/• https://docs.pytest.org/en/7.1.x/
65/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
66/735. 考察 / 利用状況把握の重要性と将来性• 部署ごとのサポート割合を出し、サポートバランスを考える• 使用されてないツールを集計し、ツール紹介としてSlackで宣伝する保守コスト下げる目的以外にも...⚫利用状況分析は守コストを下げることに有効だった⚫分析、可視化はTA本来の業務ではないが、ツール開発後の指標に活用できる⚫保守コストを下げるだけでなく色々なことに活用できそう
67/735. 考察 / そもそもなぜクラウド？• 既にTAでレンダリングサーバーや Jenkins などを管理していた• 物理的に構築していると下記が大変だと感じていた– 引っ越し、スケールアップ、在宅業務の対応、管理者の継承...物理サーバーの管理を避け、クラウドに移行したい
68/735. 考察 / TAがクラウドサービスはどうなのか？• 当然メイン業務ではない• 様々なサービスがある事により学習コストはかかる解決方法の一つの武器としての選択AWS LambdaTAが扱う様々な問題Amazon EC2Amazon OpenSearchServiceクラウドの様々サービス 解決方法の拡大
69/735. 考察 / CygamesTAのクラウドへの取り組み本講演以外にも...AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み [Cygames Tech Conference 2021]https://tech.cygames.co.jp/archives/3495/
70/735. 考察 / クラウドのセキュリティについて• 社内専門部署からのセキュリティのサポートは必須• ツールログサービスも社内専門部署と協力して実現セキュリティには十分な注意を
71/73ツール保守コスト大幅削減！テクニカルアーティストによるツールログサービスの開発と運用事例1. 最近のゲーム事情と問題点2. ツール保守コスト削減の取り組み3. ツールログサービスの技術構成4. 開発時のポイント紹介5. 考察6. まとめ
72/736. まとめ⚫保守コストを下げるために把握すべき３つの要素⚫起動状況を分析することで、ツールを整理できる⚫利用頻度を分析することで、対応優先度を判断できる⚫エラー通知をすることで、潜在的な問題に迅速に気づける⚫利用状況の分析は保守コスト削減以外にもメリットがある利用状況の分析により保守コストを削減する⚫クラウドは、TAにとって強力な武器になる⚫様々なサービスを学習することで解決方法の幅が広がる⚫自動処理を行う上で物理サーバーから解放される恩恵は大きい⚫セキュリティには十分に注意しようTAがクラウドに取り組む意義
73/73
cygames
lycorptech_jp
tomoaki25
yuj1osm
nishiuma
takanorig
inureyes
yoshiitaka
el_stoffel
segavvy
miyakemito
yamamuteki
.png){kind=icon}
3playmarketing
gr2m
holman
marcduiker
kneath
sachag
eileencodes
rocio
lemiorhan
addyosmani
deanohume
colly
jakevdp