OSC Osakaオンラインでの発表資料です TISで提供している運用レコメンドプラットフォームで使用している認証アーキテクチャの紹介

1. © 2021 TIS Inc.
オープンソースカンファレンス2021 Online/OSAKA
IT運用自律化を支援する「運用レコメンドプラットフォーム」
においてKeycloakを用いて認証を実装した話
IT基盤技術事業部
IT基盤エンジニアリング企画室 小川・内藤

2. © 2021 TIS Inc. 2
発表者紹介 1/2
おがわ まさと
小川 真人
所属: TIS株式会社
IT基盤エンジニアリング企画室
役割: 運用レコメンドPF サービス展開チーム
興味: 低レイヤに興味があります(知識はない)

3. © 2021 TIS Inc. 3
発表者紹介 2/2
ないとう たくや
内藤 拓也
所属: TIS株式会社
IT基盤エンジニアリング企画室
役割: 運用レコメンドPF 開発チーム
興味: セキュリティ,プロダクティビティ
技術: Docker,Kubernetes,Golang,Python等

4. © 2021 TIS Inc. 4
アジェンダ
• パート1「運用レコメンドPFについての紹介」
– TISが開発する運用レコメンドPF
– 運用レコメンドPFの提供状況と今後の方針
• パート2「Keycloakを用いて認証を実装した話」
– 認証部分アーキテクチャ
– 機能と要件
– Keycloakとは？なぜKeycloak？
– 実装内容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. © 2021 TIS Inc. 23
Keycloakを用いて認証を実装した話

24. © 2021 TIS Inc. 24
認証部分アーキテクチャ
• 運用レコメンドPFの全体的なアーキテクチャ

25. © 2021 TIS Inc. 25
認証部分アーキテクチャ
• 運用レコメンドPFの機能
1. 分析に必要な運用情報の収集

26. © 2021 TIS Inc. 26
認証部分アーキテクチャ
• 運用レコメンドPFの機能
1. 分析に必要な運用情報の収集
2. 利用者がダッシュボードで情報確認

27. © 2021 TIS Inc. 27
認証部分アーキテクチャ
• 運用レコメンドPFの機能
1. 分析に必要な運用情報の収集
2. 利用者がダッシュボードで情報確認
3. 異常予兆分析を行う(いつもの状態と異なる点検知)

28. © 2021 TIS Inc. 28
認証部分アーキテクチャ
• 運用レコメンドPFの機能
1. 分析に必要な運用情報の収集
2. 利用者がダッシュボードで情報確認
3. 異常予兆分析を行う(いつもの状態と異なる点検知)
適切なアクセス制限が必要
運用レコメンドPF内
での実行(アクセス制限不要)

29. © 2021 TIS Inc. 29
認証部分アーキテクチャ
実装箇所
• アクセス制限のために認証(authentication)を実装

30. © 2021 TIS Inc. 30
認証部分アーキテクチャ
• アクセス制限のために認証(authentication)を実装
• 機能と要件
実装箇所

31. © 2021 TIS Inc. 31
機能と要件
• 機能1(分析に必要な運用情報の収集)
• データ収集用のコレクターから運用レコメンドPFにデータを送信する
• コレクター
• Goで作成したアプリケーション
• バイナリを利用者環境内に配置して実行すると、監視サーバから定期的に自
動で情報を収集し、運用レコメンドPFに送信
収集先
監視サーバ
(zabbix等)
コレクター
利用者環境 運用レコメンドPF
収集 送信
※認証無しでのフロー
API群
プロキシ データベース

32. © 2021 TIS Inc. 32
機能と要件
• 機能2(利用者がダッシュボードで情報確認)
• 利用者はブラウザからダッシュボードにアクセスして情報を確認できる
• 確認できる情報
• 収集した運用情報
• 異常予兆分析の結果
利用者環境
ブラウザ
運用レコメンドPF
確認
※認証無しでのフロー
API群
プロキシ データベース
ダッシュボード

33. © 2021 TIS Inc. 33
機能と要件
• 要件
• 機能1(分析に必要な運用情報の収集)
• 認証対象
• 情報収集用のコレクター
• 定期的に自動で情報を収集
• 実行時の初回設定以降、利用者は操作しない
• 機能2 (利用者がダッシュボードで情報確認)
• 認証対象
• ダッシュボードにアクセスする利用者
• ダッシュボードアクセス時に利用者はユーザ/パスワードで都度ログイン
• 利用者のアカウントは最初に１つ発行後、利用者自身で管理(ユーザ追加/削
除等)
• 共通
• SaaS版、パッケージ版の両方で出来る
(外部依存しない)

34. © 2021 TIS Inc. 34
機能と要件
認証対象
1.認証
2.アクセストークン返却
3.トークン付きで通信
4.トークン検証
運用レコメンドPF
(API群)
5.APIアクセス
認証
サービス
コレクター
Or
ダッシュボード
• 認証フロー
• 各APIへのアクセス前に認証を行う
• API側で認証検証の処理を実装すると手間がかかるので、手前で一括検証処理する
検証

35. © 2021 TIS Inc. 35
• Keycloak
– アクセス管理・制御を行うためのOSS
Keycloakとは？なぜKeycloak？
• 機能(一部)
 ブラウザ・アプリケーション
に対するSSO
 認証・認可
(OIDC/Oauth2.0/SAMLに対
応)
 外部連携
 二要素認証(Google
Authenticator,
FreeOTP)
等
• 良いところ
 NRIにより日本語ドキュメント
が整っている
 Dockerイメージを使用すること
で簡単に立ち上げが可能
 特に細かく設定しなくても使い
やすいUI
 認証機能が一通り揃っており、
自前で実装する手間がほとんど
無い
等

36. © 2021 TIS Inc. 36
• Keycloakに至るまで
– サービスプロトタイプ時代
• APIGWおよびAPIの認証としてOSSの『KONG』を使用
Keycloakとは？なぜKeycloak？
• 認証(プラグインによる補助的なもの)
 細かい部分が出来ない
 自分たちで実装しなければいけない部
分が多く開発コストがかかる
プロトタイプの改善点
認証機能を専用の
ソフトウェアに変更
• KONGの認証はあくまでプラグインによ
る補助的なものでしかない
 細かい設定が出来ない
 自分たちで実装しなければいけない部
分が多く開発コストがかかる

37. © 2021 TIS Inc. 37
• Keycloakに至るまで
– 認証用のOSS選定
• 有名なのが『Keycloak』と『OpenAM』
Keycloakとは？なぜKeycloak？
Keycloak OpenAM
歴史 新しめ 古くからある
機能 必要なものはまとまっている 高機能
導入しやすさ 簡単 複雑
更新頻度 活発 最新版が1年前…
情報 日本語マニュアルをNRIが作成 ナレッジ豊富

38. © 2021 TIS Inc. 38
• Keycloakに至るまで
– 認証用のOSS選定
• 有名なのが『Keycloak』と『OpenAM』
Keycloakとは？なぜKeycloak？
Keycloak OpenAM
歴史 新しめ 古くからある
機能 必要なものはまとまっている 高機能
導入しやすさ 簡単 複雑
更新頻度 活発 最新版が1年前…
情報 日本語マニュアルをNRIが作成 ナレッジ豊富
開発チームが小規模→開発コストが低いKeycloakを採用
採用ポイント

39. © 2021 TIS Inc. 39
Keycloakとは？なぜKeycloak？
https://landscape.cncf.io/

40. © 2021 TIS Inc. 40
Keycloakとは？なぜKeycloak？
CNCFのLandscapeに
Keycloakが存在
https://landscape.cncf.io/

41. © 2021 TIS Inc. 41
実装内容
• 認証フロー
• Keycloakで認証管理
• プロキシのenvoyでAPIアクセス前にトークンを検証
認証対象
1.認証
2.アクセストークン返却
3.トークン付きで通信
4.トークン検証
運用レコメンドPF
(API群)
5.APIアクセス
コレクター
Or
ダッシュボード
検証
認証

42. © 2021 TIS Inc. 42
• 要件(再掲)
• 機能1(分析に必要な運用情報の収集)
• 認証対象
• 情報収集用のコレクター
• 定期的に自動で情報を収集
• 実行時の初回設定以降、利用者は操作しない
• 機能2 (利用者がダッシュボードで情報確認)
• 認証対象
• ダッシュボードにアクセスする利用者
• ダッシュボードアクセス時に利用者はユーザ/パスワードで都度ログイン
• 利用者のアカウントは最初に１つ発行後、利用者自身で管理(ユーザ追加/削
除等)
• 共通
• SaaS版、パッケージ版の両方で出来る
(外部依存しない)
実装内容

43. © 2021 TIS Inc. 43
実装内容
• 要件(再掲)
• 機能1(分析に必要な運用情報の収集)
• 認証対象
• 情報収集用のコレクター
• 定期的に自動で情報を収集
• 実行時の初回設定以降、利用者は操作しない
• 機能2 (利用者がダッシュボードで情報確認)
• 認証対象
• ダッシュボードにアクセスする利用者
• ダッシュボードアクセス時に利用者はユーザ/パスワードで都度ログイン
• 利用者のアカウントは最初に１つ発行後、利用者自身で管理(ユーザ追加/削
除等)
• 共通
• SaaS版、パッケージ版の両方で出来る
(外部依存しない)
ユーザ情報を使用したアクセス
ユーザ管理
シークレットキーを
使用したアクセス(ユーザ無し)
認証方法が
2パターン
=Keycloakではレル
ムという単位で管理
Keycloakのユーザ管
理機能をそのまま使
用できるようにする

44. © 2021 TIS Inc. 44
実装内容
• レルム
• ユーザ、ロール、クライアントなどの管理単位
• 認証を含めた様々な設定がレルムごとに可能
• 基本的に制御したい対象の範囲ごとに1レルム作成するイメージ
(顧客ごと、組織ごとに分ける等)
ユーザ ロール
…
コレクターレルム
ユーザ ロール
フロントエンドレルム
ユーザ ロール
クライアント …
Masterレルム
Keycloak作成時
に存在するレルム
クライアント
クライアント
クライアント
クライアント
クライアント
…
クライアント
クライアント
クライアント
認証対象の
アプリケーション

45. © 2021 TIS Inc. 45
実装内容
• レルム管理画面

46. © 2021 TIS Inc. 46
実装内容
• レルム管理画面
• Keycloakの設定は基本的にこの管理画面上で行う
レルム名
管理
項目
設定項目

47. © 2021 TIS Inc. 47
実装内容
クライアント一覧
ここから作成
• 例：フロントエンド用の認証設定の流れ(Keycloak)
1. 認証対象用のクライアントを追加する

48. © 2021 TIS Inc. 48
実装内容
クライアント追加画面
適当なクライアント名をつける
• 例：フロントエンド用の認証設定の流れ(Keycloak)
1. 認証対象用のクライアントを追加する

49. © 2021 TIS Inc. 49
実装内容
• 例：フロントエンド用の認証設定の流れ(Keycloak)
1. 認証対象用のクライアントを追加する
2. クライアントの設定を行う
プロトコルと
アクセスタイプに
“openid-connect”
“public”を選択
認証リダイレクトする
URLを設定
色々設定項目は存在するが、たったこれだけで認証可能
(※クライアント側(ここだとフロントエンド)の設定は別)

50. © 2021 TIS Inc. 50
実装内容
• 利用者側でユーザ管理
• 自前で実装せず、Keycloakの機能をそのまま使用
• 開発コスト削減
• 認証回りの管理一元化
• Keycloakのロールを適切に設定することで管理画面の一部
のみを参照させることが可能(下記画面)
本来 特定権限のみ

51. © 2021 TIS Inc. 51
実装内容
• ユーザ管理機能
• ユーザ追加/削除、有効化、パスワード変更等一通り可能
ユーザ一覧画面
ユーザ設定画面

52. © 2021 TIS Inc. 52
実装内容(共通)
• SaaS版、パッケージ版の両方で同じように使用できる
• Dockerによるサービス起動
• 起動時に必要な設定(DBやKeycloak自体の設定など) を設定ファイル
から読み込ませる
• (開発上)本番想定の設定と開発用の設定をわけて作成すると良い。テス
ト用にユーザや認証の鍵を固定化するなどを行うため。
• Keycloak自体には外部連携の便利な機能が存在するが、導入方法
の差異を生じさせないために一旦使用しない → 今後は検討中
• 外部連携の例
• LDAP,AD連携
• googleやgithub等を利用したソーシャルログイン

53. © 2021 TIS Inc. 53
Keycloakを使いこなす上で
• サービスを起動して連携させるまでは本当に簡単。画面だけでも
大体内容がわかる。(日本語マニュアルで詳細を確認可能)
• きちんと目的に沿った設計・設定を行うには、認証・認可回りに
関する基礎的な知識が求められる
• 認証・認可の基礎的な知識
• プロトコルの理解
• 例：Oauth2とOpenID Connect
• Keycloakのドキュメントにはプロトコルの中身も含めた割と詳
しい説明がある。ただこれだけで理解するのも大変なので、1冊
認証に関する本を読んだ後に、ドキュメント読みこむのがおす
すめ。

54. © 2021 TIS Inc. 54
まとめ
• サービスの機能や要件を洗い出して整理し、必要となる
認証を実装した
• 認証まわりを全て専用のOSS(Keycloak)に任せることで、
管理や設定が楽になった
• Keycloakの導入しやすさ、使いやすさのおかげで開発コ
ストを下げ、サービス開発の速度向上につながった

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

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

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

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