Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ツール保守コスト大幅削減!テクニカルアーティストによるツールログサービスの開発と運用事例
Search
Cygames
August 31, 2023
Technology
0
380
ツール保守コスト大幅削減!テクニカルアーティストによるツールログサービスの開発と運用事例
2022/08/24 CEDEC2022
Cygames
August 31, 2023
Tweet
Share
More Decks by Cygames
See All by Cygames
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
290
『GRANBLUE FANTASY: Relink』最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
1
250
『GRANBLUE FANTASY Relink』ソフトウェアラスタライザによる実践的なオクルージョンカリング
cygames
0
270
高品質なフォトグラメトリデータを取得するためのハードウェア&ソフトウェア開発
cygames
0
670
AIを活用した柔軟かつ効率的な社内リソース検索への取り組み
cygames
0
360
『GRANBLUE FANTASY: Relink』開発からリリースまでを支えたCI/CDの取り組み
cygames
0
170
『GRANBLUE FANTASY: Relink』専任エンジニアチームで回す大規模開発QAサイクル
cygames
0
190
『GRANBLUE FANTASY: Relink』クオリティと物量の両立に挑戦したフェイシャルアニメーション事例 ~カットシーンからランタイムまで~
cygames
0
190
『GRANBLUE FANTASY: Relink』キャラクターの個性にlinkした効果音表現
cygames
0
89
Other Decks in Technology
See All in Technology
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3.3k
CData Virtuality 日本ローンチイベントのKeynote
cdataj
0
120
ADRを運用して3年経った僕らの現在地
onk
PRO
13
5.3k
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
340
いまからでも遅くない! コンテナでWebアプリケーションを 動かしてみよう(2-1)WebAPI座学
nomu
0
160
YAPC::Hakodateの映像記録を支える技術
godan
4
230
【shownet.conf_】革新と伝統を融合したファシリティ
shownet
PRO
0
340
小さな勉強会の始め方、広げ方、あるいは友達の作り方 / How to Start, Grow, and Build Connections with Small Study Groups
ar_tama
6
2.7k
【shownet.conf_】ShowNet x 宇宙ネットワーク
shownet
PRO
0
410
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
2
240
業務ヒアリングと知識の呪い
tamai_63
0
290
Webセキュリティのあるきかた
akiym
32
10k
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
787
250k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Rails Girls Zürich Keynote
gr2m
93
13k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
Become a Pro
speakerdeck
PRO
24
4.9k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
GraphQLとの向き合い方2022年版
quramy
43
13k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2k
Designing Experiences People Love
moore
138
23k
Transcript
None
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/73 1. 最近のゲーム事情と問題点 • プロジェクトの規模拡大 • 業務の専門化&細分化
6/73 1. 最近のゲーム事情と問題点 ツール数が増加し、保守コスト増加 • プロジェクトの規模拡大 • 業務の専門化&細分化
7/73 1. 最近のゲーム事情と問題点 • 使われてないツールが整理され、改善予定のツール対応優先 順位が整理されている • 新規ツールと既存ツールの優先度の判断ができる • 潜在的なエラーなどの問題がない
保守コストが 正常 • どれを優先しても良いかわからないので増え続けるツールを 全て保守しなくてはならない • 新規ツールと既存ツールのどちらを進めるか判断できない • 伝えられていないエラー報告など潜在的な問題がある 保守コストが 高い
8/73 1. 最近のゲーム事情と問題点 • 使われてないツールが整理され、改善予定のツール対応優先 順位が整理されている • 新規ツールと既存ツールの優先度の判断ができる • 潜在的なエラーなどの問題がない
保守コストが 正常 • どれを優先しても良いかわからないので増え続けるツールを 全て保守しなくてはならない • 新規ツールと既存ツールのどちらを進めるか判断できない • 伝えられていないエラー報告など潜在的な問題がある 保守コストが 高い どうするべきか?
9/73 1. 最近のゲーム事情と問題点 保守コスト削減のために把握すべき3要素 どの位使われているか? 使用頻度 どれを先に対応すべきか? 対応優先度 トラブルを起こしそうな物はあるか? 潜在的な問題
10/73 ツール保守コスト大幅削減! テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4.
開発時のポイント紹介 5. 考察 6. まとめ
11/73 2. ツール保守コスト削減の取り組み ツールの利用状況をどう把握するか? アンケート、 ユーザーに直接状況を聞くなど お互いにコストがかかり、大変なのでこれは避けたい… 自動的に利用状況を把握できる環境があるとよい
12/73 2. ツール保守コスト削減の取り組み カスタマイズ可能な 内製のログ収集ツールを用意する 自動的に利用状況を把握できる環境があるとよい
13/73 2. ツール保守コスト削減の取り組み 利用ログ収集して利用状況を把握、分析するサービス 「ツールログサービス」 =
None
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へ報告されてなかったエラーを自動的に把握することができる様になった • 良くエラーが起きるツールの手順の整理やマニュアル見直しが行えるようになった
24/73 ツール保守コスト大幅削減! テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4.
開発時のポイント紹介 5. 考察 6. まとめ
25/73 3. ツールログサービスの技術構成 定期実行 Amazon EC2 Amazon OpenSearch Service AWS
Lambda Amazon EventBridge AWS SAM Slack TA ユーザー ログ送信 ツール実行 データ解析 通知 クエリ・情報取得 ログ整形登録 ログモジュール
26/73 3. ツールログサービスの技術構成 定期実行 Amazon EC2 Amazon OpenSearch Service AWS
Lambda Amazon EventBridge AWS SAM Slack TA ユーザー ログ送信 ツール実行 データ解析 通知 クエリ・情報取得 ログ整形登録 ログモジュール 内製モジュールを通して ユーザーのツール実行ログを送信する ① ツールからのログ送信
27/73 3. ツールログサービスの技術構成 定期実行 Amazon EC2 Amazon OpenSearch Service AWS
Lambda Amazon EventBridge AWS SAM Slack TA ユーザー ログ送信 ツール実行 データ解析 通知 クエリ・情報取得 ログ整形登録 ログモジュール 受け取ったログを整形して ログのデータベースに転送する ②ログの受信・整形・転送
28/73 3. ツールログサービスの技術構成 定期実行 Amazon EC2 Amazon OpenSearch Service AWS
Lambda Amazon EventBridge AWS SAM Slack TA ユーザー ログ送信 ツール実行 データ解析 通知 クエリ・情報取得 ログ整形登録 ログモジュール ドキュメント型のデータベース上で 可視化されたログの 検索や集計、分析を行う ③ データベース上でのログの閲覧・分析
29/73 3. ツールログサービスの技術構成 定期実行 Amazon EC2 Amazon OpenSearch Service AWS
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
43/73 ツール保守コスト大幅削減! テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4.
開発時のポイント紹介 5. 考察 6. まとめ
44/73 4.1. Amazon OpenSearch 4.2. 内製モジュール 4. 開発時のポイント紹介
45/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 で対応してないものあり
55/73 4.1. Amazon OpenSearch 4.2. 内製モジュール 4. 開発時のポイント紹介
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/
65/73 ツール保守コスト大幅削減! テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4.
開発時のポイント紹介 5. 考察 6. まとめ
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. 考察 / クラウドのセキュリティについて • 社内専門部署からのセキュリティのサポートは必須 • ツールログサービスも社内専門部署と協力して実現 セキュリティには十分な注意を
71/73 ツール保守コスト大幅削減! テクニカルアーティストによるツールログサービスの開発と運用事例 1. 最近のゲーム事情と問題点 2. ツール保守コスト削減の取り組み 3. ツールログサービスの技術構成 4.
開発時のポイント紹介 5. 考察 6. まとめ
72/73 6. まとめ ⚫ 保守コストを下げるために把握すべき3つの要素 ⚫ 起動状況を分析することで、ツールを整理できる ⚫ 利用頻度を分析することで、対応優先度を判断できる ⚫
エラー通知をすることで、潜在的な問題に迅速に気づける ⚫ 利用状況の分析は保守コスト削減以外にもメリットがある 利用状況の分析により保守コストを削減する ⚫ クラウドは、TAにとって強力な武器になる ⚫ 様々なサービスを学習することで解決方法の幅が広がる ⚫ 自動処理を行う上で物理サーバーから解放される恩恵は大きい ⚫ セキュリティには十分に注意しよう TAがクラウドに取り組む意義
73/73