OSC Fukuokaオンラインでの発表資料です。 TISで提供している運用レコメンドプラットフォームのアーキテクチャについての話。

1. © 2020 TIS Inc.
オープンソースカンファレンス2020 Online/Fukuoka
IT運用自律化を支援する
「運用レコメンドプラットフォーム」実現の舞台裏
IT基盤技術事業部
IT基盤エンジニアリング企画室 小川・池田

2. © 2020 TIS Inc. 2
発表者紹介 1/2
おがわ まさと
小川 真人
所属: TIS株式会社
IT基盤エンジニアリング企画室
役割: 運用レコメンドPF サービス展開チーム
興味: 低レイヤに興味があります(知識はない)
アピール？： 今回を機にQiitaなどで知識のアウトプットをはじめ、
スキルアップをしていこうと思います。
Qiita https://qiita.com/yumidukasattin

3. © 2020 TIS Inc. 3
発表者紹介 2/2
いけだ だいすけ
池田 大輔
所属: TIS株式会社
IT基盤エンジニアリング企画室
役割: 運用レコメンドPF プロダクトオーナー
興味: 運用管理系の効率化
技術: Zabbix,AWS,Docker,Kubernetes,
JobScheduler,fluentd,Ansible,Golang
著書: 技術評論社「改訂2版 Zabbix統合監視徹底活用」
Twitter @ike_dai
Qiita https://qiita.com/ike_dai

4. © 2020 TIS Inc. 4
アジェンダ
• パート1「運用レコメンドPFについての紹介」
– TISが開発する運用レコメンドPF
– 運用レコメンドPFの提供状況と今後の方針
• パート2「開発の舞台裏」
– OSSを軸にした運用レコメンドPFの仕組み全体像
– アーキテクチャ検討に際し意識していること
– 実現するアーキテクチャ「5つのポイント」

5. © 2020 TIS Inc. 5
運用レコメンドPFについての紹介

6. © 2020 TIS Inc. 6
IT運用 効率化・品質向上への取組み
定常業務 定型業務 ⇒旗印は「標準化」
非定常業務 非定型業務 ⇒標準化できない
･･･> だからこそ、非定常・非定型
最終ゴールは、AIによる自律・自動型のIT運用
【保守・運用の効率化・品質向上の限界】
【”運用レコメンドプラットフォーム”の目指す世界】
障害の発生予防（予兆検知）
障害の早期回復（ダウンタイムの短縮）
最終ゴールは、「自律型自動運用」
運用保守に関する
データの集約と共有
イベントデータ
(ログ、障害、構成変更、
システム操作、脆弱性発覚etc.)
構成情報データ
(サーバ、SW、
パラメータetc.)
集約データの分析
統計分析・機械学習 etc
(テキスト分類、類似度分析、共起分析 etc.)
保守・運用作業の
Nextアクションをレコメンド

7. © 2020 TIS Inc. 7
既存の分析ツール、可視化ツールとの違い
• 既存の監視系ツール、ログ管理系ツールの置き換えというわけではなく、
各運用系ツールを束ねて、運用の効率化を促進するという位置づけの製品となります。
• (メトリクス監視をしている既存の監視データを活用し、状態の異常を検知したり、
構成情報やその他作業イベントの情報と関連付けて可視化したり)
運用保守に関する
データの集約と共有
イベントデータ
(ログ、障害、構成変更、
システム操作、脆弱性発覚etc.)
構成情報データ
(サーバ、SW、
パラメータetc.)
集約データの分析
統計分析・機械学習 etc
(テキスト分類、類似度分析、共起分析 etc.)
保守・運用作業の
Nextアクションをレコメンド
障害の発生予防（予兆検知）と、障害の早期回復（ダウンタイムの短縮）
【運用レコメンドPFのコンセプト】

8. © 2020 TIS Inc. 8
運用レコメンドPFの機能紹介

9. © 2020 TIS Inc. 9
運用レコメンドプラットフォームサービス概要
2パターンの提供形態 運用情報の統合表示 いつもと違うを機械的に捉える
SaaS型
パッケージ型
手軽に使える..
クローズド環境でも使える..
サーバ1 サーバ2 サーバ3
ネットワーク1
関連する監視傾向情報
関連するログ情報
統合的に可視化
関連する作業履歴情報
なんとなく
おかしいな..
いつもの稼動傾向をモデル化 変化を機械検知
想定外の状況発生に早期に気づく
従来…
運用レコメンドPFを使うと…

10. © 2020 TIS Inc. 10
◼ 監視データ、ログデータ、設定情報、操作履歴等統合的に確認可能
Data Collector Data Analyzer
データ収集基盤 データ分析基盤
ダッシュボード
Operation Dashboard
◼ 根本的なデータ収集は既存監視ツール等と連携し、
分析できる形に変換して保有することに注力
◼ システムの状態変化の検出と検知結果と
運用作業との関係性分析に注力
提供予定の機能概要
以下を確認可能に
・システムで異常が起こっていないか
・異常状態になっているのはどこか
・異常箇所に関連する状態がどうなっているか
以下を実現
・保守運用に必要なデータを自動的に集約
・構成情報を軸にし、各データを関連付けて管理
以下を実現
・いつもと状態が違うタイミングを早期に検知して伝える
※データ分析機能詳細は参考情報ページを参照

11. © 2020 TIS Inc. 11
分析機能仕組み 1 -監視データ変化点検知分析-
◼ 数値系監視結果データに対して、変化点の検出処理を実施する機能
◼ ① 指定した監視アイテムのデータに対し、正常状態時の分析パターンを生成
(周期性も考慮した変動パターンの生成。デフォルトは1週間の変動周期を考慮)
◼ ② 直近の監視データを用いて、①の正常パターンと比較して変化点が発生していないかを定期分析
(実行間隔はデフォルト30分に1回)
分析評価イメージ
評価のため、
内部では正常状態の傾向パターンを管理
突発的ではなく、
状態が変化し始めた点を検出

12. © 2020 TIS Inc. 12
分析機能仕組み 2 -複数監視データ同士の相関変化分析-
◼ 複数の監視データ同士の変動の相関変化を分析する機能を提供
◼ ① 任意の複数の監視項目のデータを用いてそれぞれの変動の相関関係の正常時パターンを算出
◼ ② 定期的に、直近データを用いて相関関係を算出、①正常時パターンと比較し変動が大きい箇所を検知
(実行間隔は調整可能。デフォルトは30分に1回)
◼ 複数の監視項目の選択のパターン例
◼ i. 同一のサーバの監視項目同士の相関を見るケース
◼ ii. 同一の監視項目(CPU使用率)のサーバ間の相関を見るケース
分析評価イメージ
正常状態時の相関係数を内部で保持
相関係数の変化箇所を検出
普段は出ていない相関が
出始めていることの検知の例

13. © 2020 TIS Inc. 13
分析機能仕組み 3 -ログデータ出力傾向変化分析-
◼ ログに含まれるキーワードの出力傾向情報を分析し、前日の同時間帯と比較して傾向が
変わってきたタイミングで検知
期待する効果
- キーワードマッチベースの検出では気づけない傾向変化を早期検知できるようになる
比較対象期間(前日の同時間帯データ)
2019/09/18 12:01:20 +09:00 warning Starting app server ...
2019/09/18 12:03:21 +09:00 info check test ok
2019/09/18 12:07:12 +09:00 info check test ok
2019/09/18 12:08:21 +09:00 info check test ok
2019/09/18 12:12:43 +09:00 warning Starting app server ...
2019/09/18 12:15:14 +09:00 warning lotate debug log
2019/09/18 12:16:45 +09:00 warning invalid type integer
2019/09/18 12:29:11 +09:00 info check test ok
2019/09/18 12:31:01 +09:00 warning Starting app server ...
2019/09/18 12:32:32 +09:00 info check test ok
評価対象期間(直近のデータ)
2019/09/19 12:05:23 +09:00 warning Starting app server ...
2019/09/19 12:06:22 +09:00 warning old test debug log
2019/09/19 12:07:21 +09:00 warning invalid type integer
2019/09/19 12:08:20 +09:00 warning invalid max connections parameters
2019/09/19 12:12:19 +09:00 warning Starting app server ...
2019/09/19 12:15:18 +09:00 warning lotate debug log
2019/09/19 12:16:17 +09:00 warning invalid type integer
2019/09/19 12:29:15 +09:00 warning less max connections parameters 200
2019/09/19 12:31:14 +09:00 warning Starting app server ...
2019/09/19 12:32:13 +09:00 info change debug level 3 to 4
変化度合
いを分析

14. © 2020 TIS Inc. 14
分析結果の確認イメージ
• 検知結果イメージ
正常時の状態と比較した変動箇所を検知
しきい値ベースの監視設定で気づきにくい
「いつものとなんとなく異なるを早期検知」
監視項目同士の相関度合いを算出し
「総合的にいつもとなんとなく異なるを早期検知」

15. © 2020 TIS Inc. 15
運用レコメンドPFに期待する効果

16. © 2020 TIS Inc. 16
運用レコメンドPF活用によるビジネス損害の極小化
障害予防（発生抑制）と発生時の早期回復（ダウンタイムの短縮）により、
ビジネス損害を抑制
ビジネスにITを活用する（＝システムを運用する）
障害対応の直接費用（IT関連・業務関連の対応人件費・外注費、機器交換・補修費、・・）
機会損失
顧客からの損害賠償
信用力低下による中長期的なビジネス損害
直接的損害
ダウンタイム中の業務効率低下（当該システムの直接影響、その他関連業務への波及影響）
間接的損害
【影響度】
⇒見えない損害ほど、その影響度の抑制効果が大
残念ながら、（必ず、）障害は起こる

17. © 2020 TIS Inc. 17
システムの異常に”いち早く”・”的確に” 気付けるように
【現行のよくある運用シーン】
1 監視の仕組みは入っていて障害には気付けるようになっているが・・・
課題
• 閾値ベースの設定が中心で調整が複雑になりがち(属人的)
• 閾値を厳しくしすぎると大量のアラート発生
• 閾値をゆるくしすぎると障害発生の検知が遅れる
2 おかしくなってきていないかの確認を
週次や月次で目検チェックしているが・・・
課題
• チェックする対象が多く時間がかかる
• おかしそうかなという基準が見る人によってブレる(属人的)
• チェックとチェックの間隔が長くなりがちなので検知のタイミングは遅れる

18. © 2020 TIS Inc. 18
システムの異常に”いち早く”・”的確に” 気付けるように
【現行のよくある運用シーン】
1 監視の仕組みは入っていて障害には気付けるようになっているが・・・
課題
• 閾値ベースの設定が中心で調整が複雑になりがち(属人的)
• 閾値を厳しくしすぎると大量のアラート発生
• 閾値をゆるくしすぎると障害発生の検知が遅れる
2 おかしくなってきていないかの確認を
週次や月次で目検チェックしているが・・・
課題
• チェックする対象が多く時間がかかる
• おかしそうかなという基準が見る人によってブレる(属人的)
• チェックとチェックの間隔が長くなりがちなので検知のタイミングは遅れる
運用レコメンドPF
運用システム
正常時
パターン
いつもの稼働状態を
データとして記録
直近稼働
パターン
データ収集
機械的に違いをチェックし続け
変化の発生を検知
いつもと違うおかしくなってきたタイミングを機械的に判断できる！
将来的には・・・
属人的になりがちな閾値ベースの監視設定を排除していける

19. © 2020 TIS Inc. 19
”なんでだっけ？”をよりスピーディに解決できるように
【現行のよくある運用シーン】
1 監視の仕組み、作業記録管理、インシデント管理の仕組みは入っているが・・・
課題
• それぞれ管理しているツールが別々になっていて確認に手間がかかる
• 各情報の関連付けもできておらず効果的に活動できる状態で管理できていない
2 監視の仕組みは調整されていてアラートは的確にあがってくるが・・・
課題
• 監視アラートが何をきっかけにその状態になったのかを確認するのに時間がかかる
• どこを確認すべきかについても属人的になりがち

20. © 2020 TIS Inc. 20
”なんでだっけ？”をよりスピーディに解決できるように
【現行のよくある運用シーン】
1 監視の仕組み、作業記録管理、インシデント管理の仕組みは入っているが・・・
課題
• それぞれ管理しているツールが別々になっていて確認に手間がかかる
• 各情報の関連付けもできておらず効果的に活動できる状態で管理できていない
2 監視の仕組みは調整されていてアラートは的確にあがってくるが・・・
課題
• 監視アラートが何をきっかけにその状態になったのかを確認するのに時間がかかる
• どこを確認すべきかについても属人的になりがち
運用レコメンドPF
運用システム
運用情報を時間軸に沿って統合的に管理
監視データ
監視アラート
ログデータ
操作履歴
設定変更履歴
時間
サーバの負荷上昇警告アラート
サーバ内の設定パラメータ変更
サーバ内の設定パラメータ変更
サーバの負荷復旧アラート
何か起こった時に時間に沿って実施された事象を即座に確認できる！
将来的には・・・
機械的に関係性を判断し作業実施前の未然予防や
アラート発生時のリカバリプランの判断を機械的にできようになる

21. © 2020 TIS Inc. 21
運用レコメンドPFの提供状況と今後の方針

22. © 2020 TIS Inc. 22
運用レコメンドPFの状況
2020/10/30にの正式版の提供を開始しました。
AI技術を益々活用した保守運用者を補助できる仕組みを開発中です。
～開発中や検討中の機能～
– 分析モデルの自動管理強化 (現状いつもの状態の期間指定が運用者による指示ベース)
– 構成情報の表現のバリエーション強化
– ゆくゆくはAI技術を駆使して、
• 異常の原因となった行動の分析(原因分析)
• 異常により影響を与える箇所の分析(影響分析)
今後の方針
提供状況

23. © 2020 TIS Inc. 23
開発の舞台裏

24. © 2020 TIS Inc. 24
OSSを軸にした運用レコメンドPFの仕組みの全体像

25. © 2020 TIS Inc. 25
OSSを軸にした運用レコメンドPFの仕組みの全体像
• 分析に必要な運用情報を集める
①
②
③
⑤
⑥

26. © 2020 TIS Inc. 26
OSSを軸にした運用レコメンドPFの仕組みの全体像
• ダッシュボードで情報を確認する
①
② ③
⑤
⑥
④
⑦

27. © 2020 TIS Inc. 27
OSSを軸にした運用レコメンドPFの仕組みの全体像
• 異常予兆分析を行う(いつもの状態パターンモデルを作成)
①
② ③
⑤
⑥
④
⑦
⑧
⑨

28. © 2020 TIS Inc. 28
OSSを軸にした運用レコメンドPFの仕組みの全体像
• 異常予兆分析を行う(いつもの状態と異なる点検知)
①
②
③

29. © 2020 TIS Inc. 29
アーキテクチャ検討に際し意識していること
極力必要なところだけを作るにとどめる
今後が不透明なので、方向性が変わっても
対処できるようにする
エンジニアのモチベーション維持および研
究開発の観点も絡んでいたので比較的新し
い要素も試す
既存の仕組みを使えるとこは使う
- 監視ツール等は既存のものと連携
機能まるごと入れ替えるとかも考慮
提供する場所もどう転ぶか
- クラウド提供、オンプレ提供
よいものを提供するには実現できるエンジニア重要

30. © 2020 TIS Inc. 30
• 企画～PoC
– 素早く手軽に
• プロダクト化～展開
– セキュアに確実に
フェーズによっても意識を変えて取り組みを
要素 企画～PoC プロダクト化～展開
コンテナ管理 Docker Composeベース Kubernetesベース
DB InfluxDB(時系列DB)、Neo4j(グラフ
DB)
TimescaleDB(PostgreSQLの時系列拡張)
認証 KONG (JWT認証プラグイン) Keycloak
API仕様 REST API (Python Flaskベース) gRPC
分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio)
コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式

31. © 2020 TIS Inc. 31
• 企画～PoC
– 素早く手軽に
• プロダクト化～展開
– セキュアに確実に
フェーズによっても意識を変えて取り組みを
要素 企画～PoC プロダクト化～展開
コンテナ管理 Docker Composeベース Kubernetesベース
DB InfluxDB(時系列DB)、Neo4j(グラフ
DB)
TimescaleDB(PostgreSQLの時系列拡張)
認証 KONG (JWT認証プラグイン) Keycloak
API仕様 REST API (Python Flaskベース) gRPC
分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio)
コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式
開発のしやすさを優先的に
・開発言語の統一
・疎結合だけどシンプルにワンセットで動く

32. © 2020 TIS Inc. 32
• 企画～PoC
– 素早く手軽に
• プロダクト化～展開
– セキュアに確実に
フェーズによっても意識を変えて取り組みを
要素 企画～PoC プロダクト化～展開
コンテナ管理 Docker Composeベース Kubernetesベース
DB InfluxDB(時系列DB)、Neo4j(グラフ
DB)
TimescaleDB(PostgreSQLの時系列拡張)
認証 KONG (JWT認証プラグイン) Keycloak
API仕様 REST API (Python Flaskベース) gRPC
分析管理 MLflow + Sqlite3 + localファイル MLflow + PostgreSQL + S3(S3互換Minio)
コレクター Python コンテナイメージ配布方式 Golang バイナリ配布方式
導入・運用を考慮
・展開した後の管理
・拡大するチーム体制も考慮

33. © 2020 TIS Inc. 33
1. コンテナベース&マイクロサービス型
2. gRPC API
3. Kubernetesベース基盤
4. Goベースのコレクター
5. MLflowによる分析管理
実現するためのアーキテクチャ5つのポイント

34. © 2020 TIS Inc. 34
コンテナベース&マイクロサービス型
Why?
How?
Pros?
Cons?
◆ 機能変更に追随しやすいように
◆ 分析機能等処理負荷読みにくいものも
柔軟に切り出して管理しやすいように
◆ 場所を問わず動かせるように
◆ Front - BFF – Backend構成に
◆ BFFは画面の表示コンポーネント毎に
◆ Backendは扱うデータの種別毎に
◆ 分析は処理種別毎に
◆ 機能変更時の影響範囲を局所化
◆ クラウド基盤やオンプレ環境どこでも
稼動可能に
◆ コンテナ数が非常に多く
◆ 実装が冗長になりがち

35. © 2020 TIS Inc. 35
gRPC API
Why?
How?
Pros?
Cons?
◆ 分析処理等リソース指向の操作を表現
するRESTでは表現しにくい
◆ 分析用大量データ送受信等のため少し
でも早く軽量に
◆ API仕様もしっかり管理できるように
◆ ProtocolBuffersでAPI仕様定義
◆ gRPCによるAPI実装
◆ Front(JS)からはgrpc-web
◆ BFF(Python)からBackendはgRPC
◆ コレクター(Go)からBackendもgRPC
◆ ProtocolBuffersでAPI定義し明確化
◆ 開発者間やプロダクトオーナーとの会
話もスムーズに
◆ 若干高速化しているかも
◆ gRPCサーバとのやり取りのデバッグ
がやりにくい
✓ curlとかで手軽にできない(grpcurlとか)
✓ フロントも開発者ツールとかで通信の内容
確認しにくい(シリアライズ化)
◆ ProtocolBuffersからbuildするワンス
テップ管理が増える

36. © 2020 TIS Inc. 36
• Protocol Buffers
– インターフェース定義言語
– データシリアライズするための形式
– API通信の処理を定義に沿ってシリア
ライズ/デシリアライズする等
• gRPC
– リモートプロシージャコール
– HTTP/2を利用した通信
– Protocol Buffersでデータをシリアラ
イズし、通信することで高速なやり取
りができる
– 双方向通信等も対応
syntax = "proto3";
// 分析処理管理サービス
service AnalyzeService {
// 分析処理を実行するrpc
rpc ExecAnalyze (ExecAnalyzeRequest) returns (ExecAnalyzeResponse) {}
// 分析結果のリストを取得するrpc
rpc GetResults (GetResultsRequest) returns (GetResultsResponse) {}
}
message ExecAnalyzeRequest {
repeated string monitor_id = 1; // 分析対象のID(リスト)
}
message ExecAnalyzeResponse {
bool result = 1; // 成功かどうかのフラグ
string message = 2; // 結果のメッセージ
}
参考) Protocol BuffersとgRPC
サービス定義
rpc定義
メッセージ型定義
Go Python JS
.protoファイル
コンパイル
サーバやクライアントのコード実装
・protoの仕様に沿ってシリアライズ/デシリアライズ

37. © 2020 TIS Inc. 37
Kubernetesベース基盤
Why?
How?
Pros?
Cons?
◆ SaaS版/パッケージ版両提供
◆ SaaS版は複数顧客を論理的に分割し
つつ維持管理
◆ SaaS版は接続元IP制限等管理強化
◆ Kubernetes前提の稼動
◆ Kubernetesの実行定義manifestは
SaaS・パッケージ極力同一で管理
◆ 環境毎の区分けはConfigMapで
(Kustomize活用)
◆ SaaSはEKS、パッケージはmicrok8s
◆ 顧客用環境の追加削除が簡単に
◆ 同一基盤上で複数管理可能なのでリ
ソース効率もよくなる
◆ リソース制限や通信制限等安全な構成
に
◆ Kubernetesの仕組み複雑でなにかト
ラブルあったときの切り分けが辛い
◆ シングル構成で軽く動かしたくても
k8s環境必要なのでオーバースペック

38. © 2020 TIS Inc. 38
Goベースのコレクター
Why?
How?
Pros?
Cons?
◆ 利用者環境側に導入するので極力シン
プルに導入できる
◆ 稼動負荷も軽量に
◆ 各種ツールと連携するのでライブラリ
が豊富
◆ Goをベースに開発
◆ データ収集の常駐処理をGo Routine
で実装
◆ 配布物はbuild済みバイナリ+設定ファ
イルのみでシンプルに提供
◆ 導入のためにPython実行環境等準備
しなくてよくなりシンプルに
◆ ライブラリも不自由なく実装しやすい
◆ 動作も比較的軽量に
◆ build済み配布物の管理が必要
◆ 少人数の開発チームで扱う言語が増え
る(本体側は分析の都合上Python)

39. © 2020 TIS Inc. 39
MLflowによる分析管理
Why?
How?
Pros?
Cons?
◆ 分析モデル管理や生成物管理を極力自
前実装したくない
◆ 稼動場所(SaaS/パッケージ)によらず
同じように管理したい
◆ 実行時間や実行成否、実行時の分析ス
コア管理、生成物管理はMLflowで実
施
◆ 生成物はSaaSはS3に配置、パッケー
ジ版はMinioを同梱し同一の仕組みで
実現
◆ 分析処理の実装に注力した開発ができ
ている
◆ 自前で管理の仕組みなしで稼動場所の
変化に対応できている
◆ 開発初期はMLflowのバグ引くことも
多かった
◆ 試行回数が増えたときの検索性能が上
がらないなどハマるところはちょこ
ちょこと

40. © 2020 TIS Inc. 40
• 機械学習のライフサイクル管理を行うOSS
– 分析処理環境の管理
– 分析試行の実行管理
– 分析時のパラメータ管理
– 分析実行結果の管理
– 分析による算出される生成物の管理
– これらを確認できるダッシュボード提供
参考) MLflow (https://mlflow.org/)
例えば...
ハイパーパラメータ切り替えて
実施した結果を比較チェックしたいな
実行にかかった時間や実行時の
メトリクス情報を記録しておきたいな
AWS上やローカル環境上など
実行先を切り替えて処理させたいな
分析処理のステップ毎に状況を記録し
途中状態をチェックできるようにしたいな
Jupyter Notebookではちょっとやりにくい管理部分が統合できる！

41. © 2020 TIS Inc. 41
参考) MLflow ダッシュボードのイメージ
試行結果の管理・検索

42. © 2020 TIS Inc. 42
参考) MLflow ダッシュボードのイメージ
試行結果の比較チェック

43. © 2020 TIS Inc. 43
• 各種優れたOSSのおかげで要件を満たす構成に
• まだまだ改善が必要ではあるが、自分たちの強みになるも
のをOSSの組み合わせで作ることは可能性があるのではな
いか
• オーバースペック気味でスピード感が損なわれてしまった
ことは否めないが・・
• 我々はOSSを活用しつつ、そのノウハウ発信し、OSSに貢
献する活動も継続！
– (いずれは部分的にOSS化をしたいとは思っています・・)
試行錯誤を繰り返しながらも・・・

44. © 2020 TIS Inc. 44
• 検討中の案
✓ AWS EKSベースのサービス提供とmicrok8s環境でのパッケージ型提供
✓ マイクロサービスアーキテクチャ実現のためのEnvoyとKeycloak
✓ React.js + gRPCベースのWebアプリケーション実装例とハマリどころ
✓ MLflowをベースにしたデータ分析管理の仕組み
などなど
今後のOSCでの講演テーマの予告
今後のOSCのTIS枠の講演にもぜひご参加ください

45. © 2020 TIS Inc. 45
• 運用レコメンドPFに興味を持った方
– 機能的に使ってみたい → トライアル導入のご相談ください
– 中の仕組みを知りたい → 気軽にお声がけください
• TIS(我々の部隊)では、CloudNativeなシステムに取り組んでみ
たい、運用保守改善に貢献できる仕組みづくりをしてみたいと
いった方と一緒にチャレンジしたいと思っています。
おわりに

46. THANK YOU
本資料に関するお問い合わせ
TIS株式会社
IT基盤エンジニアリング企画室
運用レコメンドPFサービス運営窓口
opsbear.service@ml.tis.co.jp
＜本資料の取り扱いに関して＞
本資料は、著作権法及び不正競争防止法上の保護を受けております。資料の一部
あるいは全部について、TIS株式会社から許諾を得ずに、複写、複製、転記、転
載、改変、ノウハウの使用、営業秘密の開示等を行うことは禁じられております。
本文記載の社名・製品名・ロゴは各社の商標または登録商標です。