SRE Enabling戦記 - 急成長する組織にSREを浸透させる戦いの歴史

by Masaki Ishigaki

Embed

Start on current slide

Slide 1

Slide 1 text

SRE Enabling戦記株式会社LegalOn Technologies 急成⻑する組織にSREを浸透させる戦いの歴史

Slide 2

Slide 2 text

登壇者プロフィール⽯垣雅基 (いしがきまさき) 株式会社LegalOn Technologies SRE 最近はObservability頑張ってます

Slide 3

Slide 3 text

会社・事業紹介

Slide 4

Slide 4 text

Our Purpose 法とテクノロジーの力で、安心して前進できる社会を創る。 LegalOn Technologiesは、AI分野における⾼度な技術⼒と法律‧契約の専⾨知識を兼ね備えたグローバルリーガルAIカンパニーです。設⽴当初から、AIを活⽤したリーガルAIサービスの開発に注⼒し、⼤規模⾔語モデル（LLM）やAIエージェントなど最先端のAI技術を製品開発に取り⼊れ、多様な企業課題に応えるソリューションでお客様のビジネスを⽀援します。会社名株式会社LegalOn Technologies 設⽴ 2017年4⽉21⽇従業員数 626名（役員含む∕2025年11⽉時点）所在地〒150-6219 東京都渋⾕区桜丘町1-1 渋⾕サクラステージSHIBUYAタワー19F 資本⾦ 201.5億円（資本準備⾦等含）

Slide 5

Slide 5 text

法務AIのグローバルリーダー 7,500+ 顧客数グローバル7,500社を突破 600人従業員数 7拠点合計（東京‧⼤阪‧福岡‧名古屋‧サンフランシスコ‧ロンドン‧ミュンヘン） 20人弁護⼠資格保有者数⽇本、NY州、CA州、ドイツの資格者を含む 1000+ 導⼊上記業者数 / 前上場企業者数 3,800社 200人開発チーム⼈数 286億円ゴールドマン‧サックス、ソフトバンクなどが出資。全調達ラウンド累計

Slide 6

Slide 6 text

法務・契約領域で幅広く最先端のリーガルテックソリューションを提供法務・契約業務支援経営支援世界⽔準の法務 AIで法務業務⽀援様々なコンテンツでAIリーガルリサーチ⽀援オンライン法務学習⽀援サービス契約学習メディアとコミュニティを提供 AIコーポレートガバナンスプラットフォーム組織の規範運⽤をAIで⾃動化するAIカウンセル

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

我々の組織を取り巻く現在の状況

Slide 9

Slide 9 text

LegalOn開発の歴史 2023年3⽉キックオフ 2024年4⽉ LegalOn Cloud リリース 2024年7⽉ US版の開発開始 2025年7⽉ US版リリース＆「LegalOn Cloud」を「Legal On」にリブランディング弊社主⼒プロダクトであるLegalOnは、開発開始からわずか2年弱でグローバル展開するプロダクトとなった

Slide 10

Slide 10 text

組織の変遷 ● LegalOnは開発スタートからグローバル展開までを 2年で実現したが、急ピッチで開発を進めるため開発中多くのエンジニアを採用して、開発組織は短い期間で急拡大した ● LegalOnはリリース後も、ユーザーの様々なニーズに答えるため日々機能追加を実施しており、それを実現するために弊社の開発組織も日々拡大している

Slide 11

Slide 11 text

急ピッチの開発と組織急拡大による歪み ● 機能開発を優先してきた結果、 Observabilityが疎かに ● 弊社のSREはインフラ構築作業がメインになってしまっていた最近になって、障害が多発するように、、、

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

我々はなぜこれまで”SRE”をできずにいたのか？

Slide 14

Slide 14 text

置き去りにされた Observability 低Observability Observabilityに対する感度の違い Enabling不⾜僕たちはObservabilityを見て見ぬふりをしてしまった、、、 +

Slide 15

Slide 15 text

形骸化してしまった SLO - LegalOnリリース時に設定した SLO 一応リリース時には、 SLOを設定してみたのです、、、扱いやすい microservice APIのAvailability / LatencyのSLOから始めることにした ● Availability / Latency SLIは、それぞれistio GatewayからGatewayに接した microserviceに対するrequest_countとresponse_latency ● SLOのtarget値は、開発チームのEngineering Managerと協議の上決めた ● Burn Rate Alertも設定ここでの後悔は、SLOのEnablingがままらないまま SLOの値を決めさせてしまったこと💦 「SLOの理解がままならないのに、SLOについて決めることは難しいよね」というのが教訓でした、、、

Slide 16

Slide 16 text

アラート疲労！！！

Slide 17

Slide 17 text

形骸化してしまった SLO - LegalOnリリース時に設定した SLO 次第にBurn Rate Alertが”オオカミ 🐺少年化”してしまい、最終的には SLOの運用を取りやめた ● リリース当初はErrorのハンドリングが適切でないケースが多く、 Burn Rate Alertが発火しても実際には使用上問題なかったケースが多かった ● そもそもObservabilityが担保されていない状態であったので、 Burn Rate Alertが発火したとしても、 Alert発火後の調査が難しかった ● SLOを決めるだけで、Error Budget Policyを定めるなどして、運用面などの取り決めまで行えていなかった

Slide 18

Slide 18 text

形骸化してしまった Postmortem LegalOnリリース時に、 Postmortem運用も導入をすることにはした一応リリース時から、 Postmortemもやってました、、、当初の運用高いレベルのインシデントが発生した際は Postmortemを行い、再発防止策の取り決めまで行ったが、実際に再発防止のアクションまで取られるケースは少なかった →リリース後しばらくは新機能開発のスケジュールがタイトな状態が続いたので、抜本的な対策まで手を出すことが難しい状態であった形骸化の現実次第にPostmortemも”実施して終わり”という状況が散見されるようになった 😢 崩壊していくPostmortem

Slide 19

Slide 19 text

まずはやれるところから！ Postmortemの運用刷新

Slide 20

Slide 20 text

改善活動開始！弊社のSREチームは、こうした現状を打開すべく、本格的にSREのEnablingに乗り出した。まずは手のつけやすいPostrmoteの運用改善に取り組むことにし、開発チームのEM、およびQAの方と改善チームを組成して、改善に取り組み始めた。

Slide 21

Slide 21 text

現状分析

Slide 22

Slide 22 text

対策① - Postmortem運用の改善 ⭐ Postmortemに記載すべき項⽬を簡略化し、重要なポイントだけに絞るようにした -> ✅ 課題”Postmortem項⽬の複雑化”の解消 ⭐ Notion内に、Postmortem⽤のNotionDBとPostmortem Action Item(=再発防⽌策)⽤のNotionDBを作成して、それぞれ個別に管理するようにした -> ✅課題”NotionDB管理の難しさ”の解消 ⭐ 再発防⽌策を決める時は優先順位を設定するようにして、急いでやるべきものを選別するようにした -> ✅ 課題”再発防⽌策の未実⾏”の解消

Slide 23

Slide 23 text

対策② - Postmortemの啓蒙 ⭐ Postmortemの意義について社内Meet upイベントで説明会を実施 -> ✅ 課題”再発防⽌策の未実⾏”の解消元記事 -> https://now.legalontech.jp/n/ndcd0eaf03b23

Slide 24

Slide 24 text

Observability基盤の刷新

Slide 25

Slide 25 text

Platformを軸とした Observabilityの改善 Postmortemの改善の次に取り組んだのは、 Observabilityの向上である。障害に対して迅速な対応を行えるようにするには、これは避けて通れない道である。また、Observabilityが担保されていてこそ、意味のある SLOの運用をすることができる。そのように考えて、我々はObservability向上に取り組んだ。幸運なことに我々の組織では全社共通基盤のプラットフォームがあるので、これを軸にして Observabilityの向上とEnablingを加速させることを図った。

Slide 26

Slide 26 text

Akupara What is Akupara ? LegalOn Technologiesでプロダクト開発を⾏うにあたり、プロダクトチームが認知負荷低くソフトウェアライフサイクルを⾃律的に回すための社内開発者向けプロダクト Mission and Vision of Akupara 開発者にゴールデンパスと堅牢なインフラを提供し、創造的な開発に集中できるようにする

Slide 27

Slide 27 text

Akuparaについて詳しく知りたい方は弊社のStaﬀ Platform Engineerの杉⽥が、Platform Engineering Kaigi 2025にてAkuparaについてお話ししているので、ご興味ある⽅は是⾮動画をご視聴ください！！ https://www.cnia.io/pek2025/sessions/fee134a5-3254-4d02-aee4-c91b4dc0664e/

Slide 28

Slide 28 text

開発ライフサイクルの各ステップの開発体験向上を目指す Akupara Interface Build Test Deploy Operate Platform Infrastructure Proto 生成コード管理言語毎のテンプレート言語毎のライブラリ CI テンプレート Playwright Job デプロイ時自動実行継続的負荷試験ドキュメントサポート Production readiness Check GitOps デプロイ DB マイグレーション単発 Job の実行 Feature flag 依存関係のある Job 実行「LegalOn」開発者モニタリングダッシュボード SLO ベースのアラートエラー発生時のログ、メトリクス、トレース連携脆弱性管理暫定的権限昇格 Kubernetes 管理 DB 管理 FinOps セキュリティ認証対応各種法令準拠サービスメッシュ Web Application Firewall CDN トレーニングオフィスアワーサービスカタログ

Slide 29

Slide 29 text

これまでの Observability これまで弊社ではObservabilityツールとして、Google Cloud Observability (Cloud Monitoring / Trace / Logging)のみを使⽤していた Observabilityの向上＆self-service化を進めていくために以下のことを実施したかったが、Google Cloud Observabilityだけでは難しい側⾯があった ● 各microservice⽤のDashboard作成を抽象化するためのTerraform Moduleを作りたい -> Google Cloud Terraform Providerでは、うまく抽象化するのはやや難しい ● APIごとにAvailability / Latencyを測りたい -> Cloud Traceにはspanをmetricsに変更する機構がないので、やるのであれば⾃前計測 ● Frontendの監視をしたい -> Google Cloud ObservabilityにはFrontend監視に特化した機能はない

Slide 30

Slide 30 text

ObservabilityツールをDatadogに移行 Akupara⽤のObservabilityツールとして、Datadogも導⼊することに！！ペインポイントの解消 ● 各microservice用のDashboard作成を抽象化するための Terraform Moduleを作りたい -> Datadogには powerpackという機能がありdashboard横断で使うwidgetを定義することができ、これをうまく使うことで Dashboard作成をTerraformで抽象化できる ● APIごとにAvailability / Latencyを測りたい -> Datadogではtraceを送信すると、spanをmetricsに変換してくれる ● Frontendの監視をしたい -> DatadogにはFrontend監視ツールとしてReal User Monitoringがある

Slide 31

Slide 31 text

Datadog移行後のObservability Architecture OpenTelemetryを利⽤するため、 Datadog Agentに内蔵された OpenTelemetry Collectorを有効化

Slide 32

Slide 32 text

Obserbility周りの課題の一つに traceが計装されていないmicroserviceが存在するというものがあった Trace拡充 - OpenTelemetryのZero-code instrumentation trace未実装のものはPythonで書かれた microserviceに多かった PythonはOpenTelemetryのZero-code instrumentationが利用できるので、まずこれを利用してtraceを拡充することに！！ LegalOnのmicroserviceは主にGo、Java、Pythonで構築されている

Slide 33

Slide 33 text

Trace拡充 - PubSub間trace 幸運にも、Cloud Pub/Sub用のlibraryには、OpenTelemetry Tracingを自動で行ってくれる機能があるので、これを有効化して spanの送信とContextの伝播を行った LegalOnではCloud Pub/Subを利用した非同期処理が多く、この非同期処理に起因した障害も数多く発生していた Pub/Sub間をtraceで繋ぐことで、非同期処理の見える化を行った

Slide 34

Slide 34 text

着々とmicroservice間のtraceは繋がっていっている！！

Slide 35

Slide 35 text

k8s manifestの抽象化 OpenTelemetry Zero-code instrumentationの設定 Datadog Log Autodiscovery用の annotation LegalOnは50以上のmicroserviceで構成されるので、Observability関連の設定をmanifestに忘れずかつ間違いなく入れておくのは大変 k8s-genによる抽象化

Slide 36

Slide 36 text

k8s-genを用いたObservability設定の抽象化 k8s-genとは、以下のような機能を有したツール ● 標準化されたkubernetes manifest、ディレクトリ構成を生成 ○ server, worker, jobなどPodの役割に応じて適切な manifestが生成される ● microservice数の増加に伴うmanifest管理の複雑化の防止 ○ マニフェスト作成・更新の属人化を回避 ● セキュリティのベストプラクティスも含まれており、開発者は意識することなく infraをセキュアな状態にすることができる k8s-genをupdateして、開発者が意識することなくObservabilityの設定ができるようにした

Slide 37

Slide 37 text

Telemetry Data活用を促進するこれまでは、telemetry dataを送る際の抽象化のお話次に考えたのは、telemetry dataの利⽤シーンをどれだけ抽象化できるかということだった dashboard作りたいけど、どう作ったらいいか、、、 Alertの設定の仕⽅がわからない Observability-Kit / SLO-Kitによる抽象化 SLOはどう設定したらいい？

Slide 38

Slide 38 text

Observability-Kit Observability-Kitとは、以下のDatadogリソースを簡単に作成可能なTerraform Module ● Software Catalog ● Dashboard ● Monitor ● RUM Application

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

SLO-Kit SLO-Kitとは、microservice APIのAvailability / Latency SLO、Burn Rate Alert、Dashboardを簡単に作成可能なTerraform Module trace spanのmetricsをSLIとして、critical / importAPI をchoiceしてSLOを設定する

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

SREの日の出準備はできた、さあ、Enabling やっていきましょう

Slide 43

Slide 43 text

Postmortem改善後日談 ● Postmortemの改善を⾏ったが、今回⾏った改善だけで完全に良くなったという訳ではもちろんなく、まだまだ改善の余地はある ● 実際に、templateをもう少し改善してほしいという声も上がっている ● ただ、開発者内で自律的にフィードバックループが回りだしたようなので、 SREとしては適宜それをサポートしていけば良いと考えている ○ 開発チームの方で、 Postmortem改善のタスクフォースが立ち上がって、日々改善に取り組まれている SREが改善の最初の一歩を踏み出したことで、そこに続く形で開発チームで自律的に改善を進めるようになってくれたので、今回の改善はやってよかった

Slide 44

Slide 44 text

Observabilityの推進 - 社内勉強会 Datadogを導⼊したり、便利ツールを作ったりしたとしても、結局は使ってもらわないと意味がないわけで、、、開発者に向けてDatadog、ツールの使い⽅に関する説明会を実施

Slide 45

Slide 45 text

Observabilityの推進 - Documentation ⼀回説明会を実施しただけで、すぐに使えるようになるわけはないので、Akupara Guidelineとして、今回作成したObservability-Kit / SLO-Kit のDocumentも⽤意ツールの使い⽅だけでなく、開発者がiterativeな計装を⾏っていけるように、計装ガイドラインみたいなものも今後⽤意していきたいと考えている

Slide 46

Slide 46 text

Observabilityの推進 - Akupara issues Akuparaでは、開発ライフサイクル上の課題を拾えるように、Akupara issuesという取り組みを⾏っており、開発者は⾃由にissueを上げられるようになっている AkuparaのObservability周りの機能に関しても、このAkupara issuesを介して常に改善していけられるような体制をとっている

Slide 47

Slide 47 text

SLOの推進 - Embed Stream Aligned Team LegalOn Team A Team B Team X … LegalOnは複数のStream Aligned Teamによって開発されている SRE Core機能開発チーム mission criticalな機能を開発している Stream Aligned TeamにFocusしてSREが Embed 定期的に開催されるProduction Meeting(※)を通して、開発者とSREでSLOの運⽤を⾏っている ※Production Meeting: “Site Reliability Engineering”のChapter 31(https://sre.google/sre-book/communication-and-collaboration/)にて紹介されている、コミュニケーションの⽅法

Slide 48

Slide 48 text

SLOの推進 - microservice SLOを超えてCUJ SLOへ SLO-Kitによって、microservice単位でSLOを簡単に作成して運⽤できるようになったものの、、、 “プロダクト全体がHealthyか否か”を判断する基準が策定したいという要望が開発責任者から上がってきた Critical User Journey(CUJ)に基づいたSLOの必要性現在、プロダクトのステークホルダーとともにCritical User Journeyを整理している近い将来、CUJベースのSLOの運⽤を開始して、プロダクト全体の監視ができるような体制を敷いていく予定

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ SLOの運⽤は漫然とやってもダメ、Observabilityをキチンと整えてからやりましょう ● SLOは決めればいいというものではない ● SLOのAlertは、”Actionable Alert”なので、Observabilityが整ってなければAlertが発⽕した後にどうしていいかわからない ● 結果、SLOは⾵化してしまう

Slide 51

Slide 51 text

まとめ⼤規模組織になればなるほど、Observabilityを促進していくにはPlatform Engineeringの⼒が必要となる ● 組織のスケールとSREチームのスケールは必ずしも⽐例はしない ● Observabilityの感度は⼈それぞれなので、できるだけ抽象化する ● その上で、SREがEnablingするところ、self-serviceで推進していくところのバランスをとる

Slide 52

Slide 52 text

株式会社LegalOn Technologies https://legalontech.jp/