freee請求書のSLO違反改善活動について / SLO violation remediation activities for freee invoices
by
freee
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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定義はいいぞ