ロールが細分化された組織でSREは何をするか？

by norimichi.osanai

Slide 1

Slide 1 text

ロールが細分化された組織で SREは何をするか？ KINTOテクノロジーズ株式会社長内則倫

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

©KINTO Corporation. All rights reserved. 5 KINTOテクノロジーズ株式会社(KTC)についてトヨタ自動車株式会社トヨタファイナンシャルサービス株式会社（TFS）海外販売金融会社世界40以上の国と地域でサービスを展開トヨタファイナンス株式会社 KINTOテクノロジーズ株式会社株式会社KINTO 販売金融・クレジットカードなど 2019年1月設立 2021年4月設立

Slide 6

Slide 6 text

©KINTO Corporation. All rights reserved. 6 プロダクト紹介任意保険や自動車税など、車にかかる諸経費がコミコミで月々定額で車を持つことができるサブスクリプションサービス。WEB でも簡単にお申込みから契約まででき、気軽にカーライフをはじめることができます。気軽にマイカーを持てる、クルマのサブスクサービス https://kinto-jp.com/ トヨタ・レクサス既販車のソフトウェア・ハードウェアの機能やアイテムを最新の状態に「進化」させるサービスです。購入時設定が無かったオプションの後付けや、経年劣化した内外装の交換などを正規品質でご提供します。クルマのオーナーに向けた愛車のカスタム・機能向上サービス https://factory.kinto-jp.com/ 「KINTO ONE」でご利用いただいた良質な車から厳選した中古車を、諸経費コミコミ月々定額で乗ることができる中古車のサブスクリプションサービスです。WEBからお申込み可能、乗りやすさ、手放しやすさが自慢です。クルマがより持ちやすくなる、中古車のサブスクサービス https://up.kinto-jp.com/ 保険やメンテナンスなどのクルマの維持費に加え、トヨタのコネクティッド技術により最新の安全・便利機能を装備できる特別な車をサブスクリプションで気軽にご利用いただけるサービスです。ハードウェアもソフトウェアもアップグレードし続ける特別なクルマ https://kinto-jp.com/unlimited/ and more...

Slide 7

Slide 7 text

©KINTO Corporation. All rights reserved. 7 KTCにおけるSREの立ち位置エンジニア組織：約30グループ社内のエンジニアの数：約380名アプリケーション開発組織・KINTOサービス開発・決済/ID基盤開発・バックオフィスシステム開発・モバイルアプリ開発 etc... 横断組織・QA ・Cloud Infrastructure ・SRE(2名) / DBRE(6名) ・Platform Engineering ・MSP (24×365保守運用) ・Security ・CCoE etc... アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織アプリケーション開発組織 … プラットフォーム開発部 QA Cloud Infrastructure SRE/DBRE MSP Platform Engineering Security CCoE …

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©KINTO Corporation. All rights reserved. 10 SREのプラクティスを考える SRE QA CCoE Security Platform Engineering Cloud Infrastructure DBRE • インフラ構築・運用 • インシデント対応 • パフォーマンスチューニング • 監視運用 • CI/CDの仕組み作り • セキュリティ • 品質保証 etc... → 専門のチームがある or SREと重複

Slide 11

Slide 11 text

©KINTO Corporation. All rights reserved. 11 SREのプラクティスを考える SRE QA CCoE Security Platform Engineering Cloud Infrastructure DBRE • インフラ構築・運用 • インシデント対応 • パフォーマンスチューニング • 監視運用 • CI/CDの仕組み作り • セキュリティ • 品質保証 etc... → 専門のチームがある or SREと重複 SREチームが管轄となって価値を出せるテーマが実は意外と少ないんじゃないか？

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©KINTO Corporation. All rights reserved. 19 Observabilityの変遷 • 当時 • ログ：OpenSearch • トレース：X-Ray • メトリクス：Prometheus, Grafana • 課題感 • ログ・トレース・メトリクスがバラバラで管理 • トレース、メトリクスが開発・運用であまり活用されない • PromQLなどの学習コストが高く、自走してもらいにくい

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

©KINTO Corporation. All rights reserved. 22 New Relic活用の推進 - アラート移行 • OpenSearchのアラートをNew Relicに移行する • エラーログをトリガーにアラートを発報する • アラート設定のIaC (Infrastructure as Code)化 • 手作業で管理していたアラート設定を簡単に • TerraformやNew Relicのアラートについてのレクチャーの実施 • プロダクトで自走してアラートが管理できるような環境作り

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

©KINTO Corporation. All rights reserved. 25 New Relic活用の推進 - メトリクスを見る習慣付け • 課題 • New Relicを導入したはいいものの、障害発生時にしか使わない • 日常的なメトリクス監視やプロアクティブな改善が根付いていない • 取り組み • KINTO ONEのバックエンドチームとNew Relicをどう活用するかについて定期的なMTG • ダッシュボードを作って日次の定例で眺めてもらうことに • 効果 • プロアクティブなパフォーマンス改善が始まった • 現場ならではの改善提案も出るようになった

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©KINTO Corporation. All rights reserved. 27 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない

Slide 28

Slide 28 text

©KINTO Corporation. All rights reserved. 28 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない 2. サービスレベルによって運用をどう変えるかが分からない • 試しにエラー率とレイテンシに関してSLOを考えてもらう • エラー率のSLOが99.999%という設定値に • 現状はエラーログが発生したらアラートが鳴るような仕組み • 一回のエラーも許容しない(調査やリカバリをする)運用がSLOに反映

Slide 29

Slide 29 text

©KINTO Corporation. All rights reserved. 29 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない 2. サービスレベルによって運用をどう変えるかが分からない • 試しにエラー率とレイテンシに関してSLOを考えてもらう • エラー率のSLOが99.999%という設定値に • 現状はエラーログが発生したらアラートが鳴るような仕組み • 一回のエラーも許容しない(調査やリカバリをする)運用がSLOに反映 • レスポンスタイムに関しては可能性を感じた • レスポンスタイムの早い/遅いは個人の感性に依存する • 改善する/しないを判断するための客観的な基準値を設けるには適している • 妥当性のある基準値に関しては課題が残る

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

©KINTO Corporation. All rights reserved. 38 改善ツールの課題感と展望 • どこまで改善させるか？ • 遅い順に提案していたら延々と改善案が出てきてしまう → 一定の閾値をベースとした提案にすることでゴールを見せる • サービスレベル導入と同じような問題を抱えているものの… プロダクト固有の妥当性のあるサービスレベルは決められなくても、暗黙的に一定水準のサービスレベルを守っている状態が作れるのでは？

Slide 39

Slide 39 text

©KINTO Corporation. All rights reserved. 39 改善ツールの課題感と展望 • どこまで改善させるか？ • 遅い順に提案していたら延々と改善案が出てきてしまう → 一定の閾値をベースとした提案にすることでゴールを見せる • サービスレベル導入と同じような問題を抱えているものの… • 提案内容の精度向上 • 改善が効果的なエンドポイントから提案するように抽出ロジックの改善 • GitHubリポジトリを連携した実際のコードに即した提案作成プロダクト固有の妥当性のあるサービスレベルは決められなくても、暗黙的に一定水準のサービスレベルを守っている状態が作れるのでは？

Slide 40

Slide 40 text

Slide 41

Slide 41 text

©KINTO Corporation. All rights reserved. 41 まとめ • ロールが細分化された組織(KTC)では、SREが管轄となって価値を出せるテーマが少ない • まずはObservabilityの向上とデータを元に改善する文化を推進 • サービスレベル導入を試みるも、妥当性や運用面の壁があった • 改善ツールを作成し、一定のサービスレベルを自然と満たせるような仕組みを模索中