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

2022/08/24 CEDEC2022

Transcript

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