Slide 1

Slide 1 text

  freee請求書のSLO違反改善活動について 2025/05/29

Slide 2

Slide 2 text

  2 kochan 経歴 ● ⼊社:2024/4 ○ 24卒で⼊社 2024年7⽉から請求書に配属された ● 関⻄ネスト配属 ● 趣味 ○ お菓⼦作り ● freee-developers-hub編集部に関わっています ● 最近髪のダメージが酷くて悩んでいる freee請求書 エンジニア 川本 孝太朗

Slide 3

Slide 3 text

3 01 SLOとは
 02 請求書でのSLO設定
 03 改善活動について
 04 まとめ
 
 Contents

Slide 4

Slide 4 text

4 01 SLOとは
 02 請求書でのSLO設定
 03 改善活動について
 04 まとめ
 
 Contents

Slide 5

Slide 5 text

5 SLOとは ● SLOとは? ○ SLO(Service Level Objective)は、システムやサービスの提供における 具体的な⽬標値を定めたもの ○ SLOでは、サービスレベルという形でサービスの品質を計測できるようにする

Slide 6

Slide 6 text

6 SLOとは ● なぜSLOを設定するのか? ○ プロダクトの品質の明⽂化 ○ ユーザ⽬線の品質指標 ○ ⼒をいれるところ、抜くところが明確になる

Slide 7

Slide 7 text

7 SLOとは ● なぜSLOを設定するのか(おまけ) ○ 進化的アーキテクチャの適応度関数の⽂脈 ○ アーキテクチャを継続的に進化させていくにあたって アーキテクチャの満たすべき客観的指標を定めている ○ 新機能開発と品質担保のいい感じのバランスをとりやすくなる ref: https://www.oreilly.co.jp/books/9784873118567/

Slide 8

Slide 8 text

8 01 SLOとは
 02 請求書でのSLO設定
 03 改善活動について
 04 まとめ
 
 Contents

Slide 9

Slide 9 text

9 ⼀括送付のパフォーマンスやインポートによる⼀括作成のパフォーマンスなど ○ バリデーションなどの同期処理はp99.5で3sという⾼めの⽬標設定 ○ ⼀⽅で⾮同期処理に関してはある程度遅くても業務を阻害しないのでp99.5で300sの設定 これらの指標はプロダクトマネージャーと協⼒してユーザー体験に基づいて決定した freee請求書でのSLO定義の例

Slide 10

Slide 10 text

10 ⼀括送付のバリデーションを⾏うエンドポイントが⼤きくユーザー体験を毀損している ○ バリデーションは同期処理。3sという⽬標に対して30sぐらいかかっていた SLOを定義してわかったこと

Slide 11

Slide 11 text

11 01 SLOとは
 02 請求書でのSLO設定
 03 改善活動について
 04 まとめ
 
 Contents

Slide 12

Slide 12 text

12 ○ 3sという⽬標に対して30sぐらいかかっている ■ N+1がひどい ■ PDF⽣成処理が重い(1件500msぐらいかかっている) 原因調査 PDF⽣成処理

Slide 13

Slide 13 text

13 ⼀括送付の事前バリデーション処理 ⼀括送付 Validation Request freee請求書 郵送にかかる料⾦を表⽰ 料⾦は帳票のページ数に よって決定 基盤サービス 帳票⽣成リクエスト … ここが遅い

Slide 14

Slide 14 text

14 難しいポイント ○ PDF⽣成処理が重いためN+1を解消しても3sというSLOは満たせない ○ メインの開発案件ではないため⼯数最⼩で進めたい 対策⽅針を考える

Slide 15

Slide 15 text

15 帳票作成‧更新時にPDFを⽣成してページ数だけ保存する ○ エンジニアの⼯数はそんなにかからない ■ ページ数を保存するテーブルの追加 ■ ページ数を保存/参照する処理の実装 ○ 既存のデータを変更しないためユーザーに⾒える仕様変更はない ■ 仕様変更に関わるユーザー影響調査が不要 この⽅針でプロダクトマネージャーと仕様合意 対策案:ページ数計算を事前に⾏う

Slide 16

Slide 16 text

16 作成‧更新でPDF⽣成なんて重い処理をやって⼤丈夫? エンジニアと設計を相談した時に出てきた議論 ○ 作成‧更新の際にPDF⽣成をするならインポートのパフォーマンスが悪化するのでは? ■ 確かにCSVインポートなど⼀括で帳票作成する処理が遅くなる

Slide 17

Slide 17 text

17 作成‧更新でPDF⽣成なんて重い処理をやって⼤丈夫? エンジニアと設計を相談した時に出てきた議論 ○ 作成‧更新の際にPDF⽣成をするならインポートのパフォーマンスが悪化するのでは? ■ 確かにCSVインポートなど⼀括で帳票作成する処理が遅くなる ○ しかし⼤きな問題はない ■ インポートのSLO定義はp99.5で300sなので、PDF⽣成処理を作成側に寄せてもSLOを違反しない

Slide 18

Slide 18 text

18 今まで一番酷かったケースは 30倍高速化 ○ リリース前の酷かったケースと件数同じ ○ リリース前は29.7sだったのが0.9sに 結果

Slide 19

Slide 19 text

19 SLOも改善傾向 完全解消とまではいかないが、大幅に改善 ● 今までのひどい処理に埋もれていた部分がボトルネックに。それも近日中に修正予定 インポート系もほぼ悪化していない

Slide 20

Slide 20 text

20 01 SLOとは
 02 請求書でのSLO設定
 03 改善活動について
 04 まとめ
 
 Contents

Slide 21

Slide 21 text

21 ● サービスの品質がユーザー体験を満たしているかどうかがわかる ● パフォーマンスの変化がユーザー体験にどんな影響を与えるのかを定量的に議論することができる ○ 定量的な指標があることでスムーズに合意を得られる 結論:SLO定義はいいぞ