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

2025年7月11-12日に開催された「SRE NEXT 2025」の登壇資料です。

Transcript

1. ロールが細分化された組織で SREは何をするか？ KINTOテクノロジーズ株式会社 長内 則倫
2. ©KINTO Corporation. All rights reserved. 2 自己紹介 長内 則倫 (おさない のりみち) @tgidgd KINTOテクノロジーズ株式会社 プラットフォーム開発部 DBRE G SREチーム TL 2020年5月に株式会社KINTOに入社 翌年9月にKINTOテクノロジーズ株式会社設立に伴い転籍 SREは2021年1月〜 趣味
3. ©KINTO Corporation. All rights reserved. 3 Index 1 会社紹介と組織構成について 2 SREのプラクティスを考える 3 SREチームの取り組みの変遷 4 サービスレベルの導入 5 改善ツールの作成 6 まとめ 目次
4. ©KINTO Corporation. All rights reserved. 4 会社紹介と組織構成について 1
5. ©KINTO Corporation. All rights reserved. 5 KINTOテクノロジーズ株式会社(KTC)について トヨタ自動車株式会社 トヨタファイナンシャルサービス株式会社（TFS） 海外販売金融会社 世界40以上の国と地域で サービスを展開 トヨタファイナンス 株式会社 KINTOテクノロジーズ 株式会社 株式会社KINTO 販売金融・クレジットカード など 2019年1月設立 2021年4月設立
6. ©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...
7. ©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 …
8. ©KINTO Corporation. All rights reserved. 8 SREのプラクティスを考える 2
9. ©KINTO Corporation. All rights reserved. 9 SREのプラクティスを考える • インフラ構築・運用 • インシデント対応 • パフォーマンスチューニング • 監視運用 • CI/CDの仕組み作り • セキュリティ • 品質保証 etc...
10. ©KINTO Corporation. All rights reserved. 10 SREのプラクティスを考える SRE QA CCoE Security Platform Engineering Cloud Infrastructure DBRE • インフラ構築・運用 • インシデント対応 • パフォーマンスチューニング • 監視運用 • CI/CDの仕組み作り • セキュリティ • 品質保証 etc... → 専門のチームがある or SREと重複
11. ©KINTO Corporation. All rights reserved. 11 SREのプラクティスを考える SRE QA CCoE Security Platform Engineering Cloud Infrastructure DBRE • インフラ構築・運用 • インシデント対応 • パフォーマンスチューニング • 監視運用 • CI/CDの仕組み作り • セキュリティ • 品質保証 etc... → 専門のチームがある or SREと重複 SREチームが管轄となって価値を出せるテーマが 実は意外と少ないんじゃないか？
12. ©KINTO Corporation. All rights reserved. 12 SREチームの取り組みの変遷 3
13. ©KINTO Corporation. All rights reserved. 13 溝を埋める活動 • 課題 • 横断組織からのツールや仕組みがあまり開発組織に浸透していない
14. ©KINTO Corporation. All rights reserved. 14 溝を埋める活動 • 課題 • 横断組織からのツールや仕組みがあまり開発組織に浸透していない • 対応 • 現場の業務に合わせた個別最適なサポート
15. ©KINTO Corporation. All rights reserved. 15 溝を埋める活動 • 課題 • 横断組織からのツールや仕組みがあまり開発組織に浸透していない • 対応 • 現場の業務に合わせた個別最適なサポート コアバリューとするには腹落ちしない 「困っている人を見つけて伴走する」やり方は効果的だが再現性が低い
16. ©KINTO Corporation. All rights reserved. 16 Mission/Visionの策定 Mission 信頼性の高い価値あるプロダクトを 最速で提供できるようにする Vision サービスレベルに基づいた 開発と運用のバランスが取れた組織の実現
17. ©KINTO Corporation. All rights reserved. 17 Mission/Visionの策定 Mission 信頼性の高い価値あるプロダクトを 最速で提供できるようにする Vision サービスレベルに基づいた 開発と運用のバランスが取れた組織の実現
18. ©KINTO Corporation. All rights reserved. 18 サービスレベルをやるには一足飛びな気がしてきた Step 01 Observabilityの向上 まずはここから！
19. ©KINTO Corporation. All rights reserved. 19 Observabilityの変遷 • 当時 • ログ ：OpenSearch • トレース ：X-Ray • メトリクス：Prometheus, Grafana • 課題感 • ログ・トレース・メトリクスがバラバラで管理 • トレース、メトリクスが開発・運用であまり活用されない • PromQLなどの学習コストが高く、自走してもらいにくい
20. ©KINTO Corporation. All rights reserved. 20 • 2024年4月〜 • New Relicが使えるように • メリット • ログ・トレース・メトリクスが一つの場所に集約 • デフォルトで見える情報が多く、最初の学習コストが低い → SREチームが率先して導入を推進していくことに Observabilityの変遷
21. ©KINTO Corporation. All rights reserved. 21 New Relic活用の推進 - ドキュメントの整備 • 各種サービスでできることの紹介 • KTCの技術スタックに合わせた導入方法 • 各プロダクトの活用事例を掲載
22. ©KINTO Corporation. All rights reserved. 22 New Relic活用の推進 - アラート移行 • OpenSearchのアラートをNew Relicに移行する • エラーログをトリガーにアラートを発報する • アラート設定のIaC (Infrastructure as Code)化 • 手作業で管理していたアラート設定を簡単に • TerraformやNew Relicのアラートについてのレクチャーの実施 • プロダクトで自走してアラートが管理できるような環境作り
23. ©KINTO Corporation. All rights reserved. 23 New Relic活用の推進 - リクエスト解析ツールの作成 • New Relic Analyzer • Slack上で /nr <トレースID> と打つと、 そのリクエストのトレース情報とログ情報から何があったかを要約して教えてくれる • エラー原因を素早く、かつその人の調査スキルに依存しない形で把握できる
24. ©KINTO Corporation. All rights reserved. 24 New Relic活用の推進 - リクエスト解析ツールの作成 • New Relic Analyzer • Slack上で /nr <トレースID> と打つと、 そのリクエストのトレース情報とログ情報から何があったかを要約して教えてくれる • エラー原因を素早く、かつその人の調査スキルに依存しない形で把握できる
25. ©KINTO Corporation. All rights reserved. 25 New Relic活用の推進 - メトリクスを見る習慣付け • 課題 • New Relicを導入したはいいものの、障害発生時にしか使わない • 日常的なメトリクス監視やプロアクティブな改善が根付いていない • 取り組み • KINTO ONEのバックエンドチームとNew Relicをどう活用するかについて定期的なMTG • ダッシュボードを作って日次の定例で眺めてもらうことに • 効果 • プロアクティブなパフォーマンス改善が始まった • 現場ならではの改善提案も出るようになった
26. ©KINTO Corporation. All rights reserved. 26 サービスレベルの導入 4
27. ©KINTO Corporation. All rights reserved. 27 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない
28. ©KINTO Corporation. All rights reserved. 28 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない 2. サービスレベルによって運用をどう変えるかが分からない • 試しにエラー率とレイテンシに関してSLOを考えてもらう • エラー率のSLOが99.999%という設定値に • 現状はエラーログが発生したらアラートが鳴るような仕組み • 一回のエラーも許容しない(調査やリカバリをする)運用がSLOに反映
29. ©KINTO Corporation. All rights reserved. 29 サービスレベル導入の難しさ 1. サービスレベルの妥当性が分からない • Amazonではレスポンスタイムが100ms増加すると1%の収益減 • 車のサブスクサービスにも適用できるようには感じない • 車の供給台数、季節性、キャンペーンによる変動 etc... • 実際に契約台数と相関するデータもない • 直帰率や離脱率を見ながらの分析 • Core Web Vitals(フロントエンド)の数値改善 • どこまでやるかという部分には納得感のある答えが出し切れない 2. サービスレベルによって運用をどう変えるかが分からない • 試しにエラー率とレイテンシに関してSLOを考えてもらう • エラー率のSLOが99.999%という設定値に • 現状はエラーログが発生したらアラートが鳴るような仕組み • 一回のエラーも許容しない(調査やリカバリをする)運用がSLOに反映 • レスポンスタイムに関しては可能性を感じた • レスポンスタイムの早い/遅いは個人の感性に依存する • 改善する/しないを判断するための客観的な基準値を設けるには適している • 妥当性のある基準値に関しては課題が残る
30. ©KINTO Corporation. All rights reserved. 30 改善ツールの作成 5
31. ©KINTO Corporation. All rights reserved. 31 改善ツールの作成 • プロアクティブな改善のサイクルに着目 • このプラクティスをもっと楽に、属人性を排除する形で横断的に展開していきたい
32. ©KINTO Corporation. All rights reserved. 32 改善ツールの作成 • プロアクティブな改善のサイクルに着目 • このプラクティスをもっと楽に、属人性を排除する形で横断的に展開していきたい
33. ©KINTO Corporation. All rights reserved. 33 改善ツールの作成
34. ©KINTO Corporation. All rights reserved. 34 改善ツールの作成
35. ©KINTO Corporation. All rights reserved. 35 改善ツールの作成
36. ©KINTO Corporation. All rights reserved. 36 改善ツールの作成
37. ©KINTO Corporation. All rights reserved. 37 改善ツールの課題感と展望 • どこまで改善させるか？ • 遅い順に提案していたら延々と改善案が出てきてしまう → 一定の閾値をベースとした提案にすることでゴールを見せる • サービスレベル導入と同じような問題を抱えているものの…
38. ©KINTO Corporation. All rights reserved. 38 改善ツールの課題感と展望 • どこまで改善させるか？ • 遅い順に提案していたら延々と改善案が出てきてしまう → 一定の閾値をベースとした提案にすることでゴールを見せる • サービスレベル導入と同じような問題を抱えているものの… プロダクト固有の妥当性のあるサービスレベルは決められなくても、 暗黙的に一定水準のサービスレベルを守っている状態が作れるのでは？
39. ©KINTO Corporation. All rights reserved. 39 改善ツールの課題感と展望 • どこまで改善させるか？ • 遅い順に提案していたら延々と改善案が出てきてしまう → 一定の閾値をベースとした提案にすることでゴールを見せる • サービスレベル導入と同じような問題を抱えているものの… • 提案内容の精度向上 • 改善が効果的なエンドポイントから提案するように抽出ロジックの改善 • GitHubリポジトリを連携した実際のコードに即した提案作成 プロダクト固有の妥当性のあるサービスレベルは決められなくても、 暗黙的に一定水準のサービスレベルを守っている状態が作れるのでは？
40. ©KINTO Corporation. All rights reserved. 40 まとめ 6
41. ©KINTO Corporation. All rights reserved. 41 まとめ • ロールが細分化された組織(KTC)では、SREが管轄となって価値を出せるテーマが少ない • まずはObservabilityの向上とデータを元に改善する文化を推進 • サービスレベル導入を試みるも、妥当性や運用面の壁があった • 改善ツールを作成し、一定のサービスレベルを自然と満たせるような仕組みを模索中
42. ©KINTO Corporation. All rights reserved. 42 We are hiring!
43. Thank you！