⾃律的な開発チームを ⽀えるためのSLO運⽤ Sansan株式会社 Bill One Engineering Unit SREチーム 上司 陽平

⾃⼰紹介 じょーし（上司） Sansan株式会社 @paper2parasol - Sansan株式会社でBill OneプロダクトのSREチーム に2022年8⽉から所属 - 前職はSIer企業でコンテナ技術やSREの普及活動、 AWS・AzureでのKubernetesサービスの設計・構 築に従事 - 現職ではSREのミッション定義、オブザーバビリ ティの向上、負荷試験による性能改善、IaC化など を推進 - 好きなものはラーメンとCloud Run

Bill OneとSREチームの紹介 SLOの取り組み 今後の展望

Bill OneとSREチームの紹介 SLOの取り組み 今後の展望

© Sansan, Inc.

プロダクト開発チーム 4 ⼈前後のチームが 12 個存在 SRE 機能開発 グローバル対応 機能開発 機能開発 機能開発 コンプリケイテッド ・サブシステム グローバル対応 機能開発 機能開発 機能開発 機能開発

マイクロサービスを採⽤ サービス 機能開発チーム 機能開発チーム サービス 機能開発チーム サービス 機能開発チーム 開発・運⽤ 開発・運⽤ 開発・運⽤ 主要マイクロサービスが10個程あり、 各マイクロサービスを1~2の機能開発チームで担当（重複あり）

アーキテクチャ概要図 Microservice B Microservice A BFF (backend for frontend) Microservice Z ‧‧‧ DB DB DB

Bill One SREチームのビジョンとミッション ミッション 開発チームが⾃律的に動ける仕組みを整えつつ、 信頼性と開発効率の向上をリードする ビジョン ⾃律的に⾼い信頼性を維持できる 開発チームを⽀えるための触媒となる

ビジョン ⾃律的に⾼い信頼性を維持できる開発チームを⽀えるための触媒となる ※ 触媒とは化学反応の反応速度を速める物質で、⾃⾝は反応の前後で変化しないものをいう サービス 機能開発チーム 機能開発チーム サービス 機能開発チーム サービス 機能開発チーム 開発・運⽤ 開発・運⽤ 開発・運⽤

SRE チーム なんかめっちゃ 信頼性維持しやすい！ ビジョン ⾃律的に⾼い信頼性を維持できる開発チームを⽀えるための触媒となる ※ 触媒とは化学反応の反応速度を速める物質で、⾃⾝は反応の前後で変化しないものをいう サービス 機能開発チーム 機能開発チーム サービス 機能開発チーム サービス 機能開発チーム 開発・運⽤ 開発・運⽤ 開発・運⽤

- SRE チームメンバの専⾨性が必要なタスクは SRE が主導する - 並⾏してそれらを機能開発チームに委譲する仕組みづくりを検討・推進する 信頼性向上 促進 SRE チーム ミッション 開発チームが⾃律的に動ける仕組みを整えつつ、信頼性と開発効率の 向上をリードする サービス 機能開発チーム 機能開発チーム サービス 機能開発チーム サービス 機能開発チーム 開発・運⽤ 開発・運⽤ 開発・運⽤

Bill OneとSREチームの紹介 SLOの取り組み 今後の展望

サービス全体のSLOとバーンレートアラートの試験運⽤を開始 各バックエンドサービスのSLOとバーンレートアラートの運⽤開始 改善を重ねてバーンレートアラートが実⽤的になる SREチームの⽴ち上げ、リリースフローや性能など様々な課題に向き合う 2022/02 2022/03 2023/01 2023/07

サービス全体のSLOとバーンレートアラートの試験運⽤を開始 各バックエンドサービスのSLOとバーンレートアラートの運⽤開始 改善を重ねてバーンレートアラートが実⽤的になる SREチームの⽴ち上げ、リリースフローや性能など様々な課題に向き合う 2022/02 2022/03 2023/01 2023/07

Bill One サービス全体（≒BFF）のSLI/SLO Users サービス ・・・ SLO レイテンシ 99%tileが1000ms以下 エラー率 0.1%以下 - ユーザリクエストのレスポンス レイテンシとエラー率をSLIと している - エラーバジェットが急激に低下 した場合にバーンレートアラー トを発報する サービス

サービス全体のバーンレートアラート活⽤状況 - バーンレートアラートを受けて異常事態としてSREチーム外のメンバが 調査を開始できる状況になってきた - 設定当時はアラートがよく発⽣し、SREだけが気にしている感じだった - 2023/01頃には様々な改善によりアラートが基本発報されなくなった Users Bill One バーンレートアラート Slack

サービス全体のSLOとバーンレートアラートの試験運⽤を開始 各バックエンドサービスのSLOとバーンレートアラートの運⽤開始 改善を重ねてバーンレートアラートが実⽤的になる SREチームの⽴ち上げ、リリースフローや性能など様々な課題に向き合う 2022/02 2022/03 2023/01 2023/07

- 信頼性と開発のバランスを取れるようにする - バーンレートアラートにより単⼀サービスの異常を検知し、 各開発チームが⾃律的に担当サービスの信頼性を向上しやすくする 各バックエンドサービスごとにSLO運⽤を開始した⽬的 最速機能追加 最速機能追加 信頼性向上 信頼性向上 バジェットが 残っている バジェットが 枯渇

- 開発チームの負荷が⼤きくなり過ぎないように⼩さく始めて少しずつ改 善していくことを前提に進めた - エラー率を0.1%以下にするというSLOのみを設けた - SLI/SLOなどの⽤語や基本的な考え⽅、Bill Oneでの運⽤（後述）の説明 会を実施して開始した はじめの⼀歩

- 調査 - （Fast Burnの場合）即座に原因調査 - （Slow Burnの場合）適宜原因調査 - エラーバジェットが枯渇していない限り、原因不明の場合は各チームの 判断で適宜調査を打ち切って良い - 対応・対策・改修 - チーム内で話し合い、任意で実施する - 誤検知削減 - 各チームが誤検知を減らすように適宜値を調整する バーンレートアラートの発報時の運⽤

- 必ず枯渇原因を調査し、優先度が⾼い場合は改善計画を⽴てる - 必ず即座に対応するのではなく、まずはライトな意思決定で活⽤してい くことにした エラーバジェット枯渇時の対応

エラーバジェットを意思決定に活⽤できています！！

エラーバジェットを意思決定に活⽤できています！！ …と⾔いたかったですがまだ道半ばです。。。

- エラーバジェットの残量を活⽤したアラートが作成できない - エラーバジェットを表⽰する機能はあるが枯渇前の検知などができない - 各チームに定期的に⾒ることを強制したくなかったのでバジェット枯渇 時の運⽤を保留している - 特定エンドポイントのエラー率やレイテンシのSLIにはログベースの指 標が必要 - CUJ (Critical User Journey)を元にした重要なエンドポイントのみを 対象としたSLIを作成するときにサクッと作れると嬉しい - SLO 99.9%が最⼤ - Bill Oneの各サービスのエラー率は低いので必要に応じてより厳しい値 で運⽤ができたら良いかもと妄想している Google CloudのSLO機能の課題

Bill OneとSREチームの紹介 SLOの取り組み 今後の展望

- 現在CUJ (Critical User Journey) を踏まえたエンドポイントを別の⽂脈 で洗い出している - 今後整理したエンドポイントを活⽤し、SLIとして活⽤していくことも 考えている CUJベースのSLI/SLOの作成

- エラーバジェットが残り少なくなった際のアラートを実装し、エラーバ ジェットによる意思決定を実施 - CUJを踏まえて洗い出したエンドポイントを活⽤し、SLI/SLOを実装 - エラー率のSLOを99.9%より厳しくするかの検討 - バーンレートアラートからサービスマップに直接遷移できるようにし、 より迅速な対応を実現 SLOの実装をGoogle CloudからSplunkに移⾏

- Bill OneのSREチームは開発チームが⾃律的に信頼性を向上できる仕組 みを整えつつ、信頼性と開発効率の向上をリードする - バーンレートアラートを受けてSREチーム外のメンバも調査を開始でき る状況になってきた - バックエンドサービスのSLO運⽤を始めたがエラーバジェット枯渇時の 運⽤はまだできていない - SLOの実装をGoogle CloudからSplunkに移⾏することでSLO運⽤を洗練 していきたい まとめ

© Sansan, Inc. Sansan 技術本部 Bill One 開発エンジニア 採⽤情報 https://media.sansan-engineering.com/billone-engineer

© Sansan, Inc. 請求書受領から、⽉次決算を加速する インボイス管理サービス