$30 off During Our Annual Pro Sale. View Details »

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

Cygames
August 31, 2023

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

2022/08/24 CEDEC2022

Cygames

August 31, 2023
Tweet

More Decks by Cygames

Other Decks in Technology

Transcript

  1. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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
    この中に文字を打ち込む
    セキュリティ的にもおすすめ!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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/

    View Slide

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

    View Slide

  66. 66/73
    5. 考察 / 利用状況把握の重要性と将来性
    • 部署ごとのサポート割合を出し、サポートバランスを考える
    • 使用されてないツールを集計し、ツール紹介としてSlackで宣伝する
    保守コスト下げる目的以外にも...

    利用状況分析は守コストを下げることに有効だった

    分析、可視化はTA本来の業務ではないが、ツール開発後の指標に活用できる

    保守コストを下げるだけでなく色々なことに活用できそう

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. 72/73
    6. まとめ

    保守コストを下げるために把握すべき3つの要素

    起動状況を分析することで、ツールを整理できる

    利用頻度を分析することで、対応優先度を判断できる

    エラー通知をすることで、潜在的な問題に迅速に気づける

    利用状況の分析は保守コスト削減以外にもメリットがある
    利用状況の分析により保守コストを削減する

    クラウドは、TAにとって強力な武器になる

    様々なサービスを学習することで解決方法の幅が広がる

    自動処理を行う上で物理サーバーから解放される恩恵は大きい

    セキュリティには十分に注意しよう
    TAがクラウドに取り組む意義

    View Slide

  73. 73/73

    View Slide