急成長するBill Oneで低レイテンシを実現するための挑戦

■ イベント
上場テックカンパニーに聞く！ ~成長とその裏側~
https://coconala.connpass.com/event/328164/

■ 発表者
技術本部 Bill One Engineering Unit　前田 英司

■ Bill Oneエンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. Sansan株式会社 部署 名前 急成長するBill Oneで低レイテンシを 実現するための挑戦 Sansan技術本部 Sansan技術本部 Bill One Engineering Unit 前田 英司
2. 前田 英司 Sansan株式会社 Bill One Engineering Unit テクニカルリード Bill One でやってきたこと ⁃ 請求書の仕訳機能搭載 ⁃ SRE ⁃ いろんな改善 得意なこと ⁃ SQLのパフォーマンスチューニング（主にPostgreSQL） ⁃ OpenTelemetry周り（可観測性） ⁃ 会計学や経理業務への深いドメイン知識
3. 会社概要 2 表参道本社 神山ラボ Sansan Innovation Lab 社 名 Sansan株式会社 所在地 表参道本社 東京都渋谷区神宮前5-52-2 青山オーバルビル13F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ログミー株式会社 株式会社ダイヤモンド企業情報編集社 クリエイティブサーベイ株式会社 株式会社言語理解研究所 従業員数 1,698名（2024年5月31日時点） 2007年6月11日 設 立 支店：大阪、名古屋、福岡 サテライトオフィス：徳島、京都、新潟 拠 点 寺田 親弘 代表者
4. Bill Oneのサービス紹介
5. Bill Oneのサービス紹介をいい感じで載せたい
6. お話しするテーマ - 話すこと - Bill Oneの可用性の話 - 可観測性をどう活用しているか - 話さないこと - パフォーマンスチューニングの具体的な方法 - SLOやCUJの策定や、それらの運用について - 可観測性やOpenTelemetryの詳細な説明
7. Bill Oneのアーキテクチャ概要（前提）
8. Email Cloud Load Balancing Backend Cloud Run Database Cloud SQL Static Files Cloud Storage Cloud Tasks API Gateway Cloud Load Balancing API Client User Logging Error Reporting Cloud Build Bill One Entry Management / Developer Tools Cloud Functions Monitoring Authentication Login Screen Frontend / BFF Cloud Run Pub/Sub Bill Oneのアーキテクチャ概要（前提）
9. Bill Oneにおける可用性
10. - 企業の請求書受領は、その後の業務の起点になる - 社内の経費精算等の申請業務 - 月次決算などの報告業務 - 支払業務 等 - 企業が請求書を送付するタイミングは月初3営業日に集中する - 月初に届いた請求書を、そのままBill Oneで閲覧・処理するユーザーも多い - ユーザーがBill Oneを利用する時間は平日の日中（9時 ~ 18時）に偏る ピークである月初にBill Oneが使えない状況は絶対に避けなければならない Bill Oneにおける可用性
11. - 具体例: コア機能である請求書検索 - 請求書が閲覧できないと、ユーザーの業務は止まる > 承認フロー（経理による支払の前に部内チェック等を行う） > 仕訳（請求書画面から仕訳画面に遷移する） > 支払（支払対象の請求書を元に振込データを作る等） > etc - 請求書が閲覧できないBill Oneに価値はないとすら思う Bill Oneにおける可用性
12. - Bill Oneのエラー率はとても低い - エラー改善はリリース当初から実施しており、継続的改善の文化的な土壌が Bill Oneエンジニアにある - 今回はエラーに関する話は省きます - レイテンシに関しては、遅延発生の都度対処を行っている - データ量やリクエスト量などが増えることで顕在化するケースが多い - 実際に何度か、レスポンス遅延が発生している プロダクト成長によりリクエストの量が増えていくことは明白だったため、 レイテンシを継続的に改善できる体制が必要となる Bill Oneにおける可用性
13. データは増える一方であり、リクエスト数も毎月増えていく Bill Oneにおける可用性
14. 下記の赤部分の時期に大規模なレイテンシ遅延が発生した Bill Oneにおける可用性 解消に要した時間 2022年11月: 約3時間 2022年12月: 約2時間30分 2023年 1月: 約3時間 2023年 7月: 約3時間
15. 実施した解決策など
16. - 特定時間にリクエストが偏る - ピークに合わせた設計が必要になる - データとリクエストは増え続ける（とてもありがたいこと） - 極力、データ量にやリクエスト量に依存しないようにする - データ量などは予測したいが、予測している間に増える - マイクロサービスは増え続ける - 緊急時に備えて全容把握、というのをエンジニアに要求するのは厳しい - 全体を知らないと調査できない、という事態は避けたい - 各マイクロサービスで開発しているエンジニアの認知負荷を上げたくない Bill Oneのレイテンシに関する特性
17. - SQLのパフォーマンスチューニング - Google Cloud サービスのパラメータ調整 - Cloud SQLの最大接続数やメモリ、CPUを増やす - Cloud RunやApp Engineの最大同時リクエスト数などを調整する - プロダクトの仕様変更 - 利用するサービスの変更 - App Engine → Cloud Run など（なぜか改善した） - etc どういった手法で改善するか判断するのがとても難しい 打ち手: レイテンシを改善した例
18. レイテンシ悪化の原因を探すのがとても大変 例: Cloud Run間でHTTP通信を行うサービス 打ち手: 原因の探索 Backend 1 Cloud Run Frontend / BFF Cloud Run Backend 2 Cloud Run Backend 3 Cloud Run Database Cloud SQL Database Cloud SQL Database Cloud SQL
19. レイテンシ悪化の原因を探すのがとても大変 例: Cloud Run間でHTTP通信を行うサービス 打ち手: 原因の探索 Backend 1 Cloud Run Frontend / BFF Cloud Run Backend 2 Cloud Run Backend 3 Cloud Run Database Cloud SQL Database Cloud SQL Database Cloud SQL
20. レイテンシ悪化の原因を探すのがとても大変 例: Cloud Run間でHTTP通信を行うサービス 打ち手: 原因の探索 Backend 1 Cloud Run Frontend / BFF Cloud Run Backend 2 Cloud Run Backend 3 Cloud Run Database Cloud SQL Database Cloud SQL Database Cloud SQL
21. レイテンシ悪化の原因探索でやっていたこと - k6（https://k6.io/）を用いた負荷試験 - 負荷をかけるのは容易だが、本番と全く同じ状況を再現するのが困難で、原 因に辿り着きにくい - Google Cloud Monitoring やログ、各種サービスの指標を見る - 職人技とエスパー力が問われる（とても辛い） - 様々な知識が要求されるため、調査の負荷が有識者に偏る - マイクロサービスが今後も増えるため、プロダクトの全容を把握し続けるこ とが難しくなっていくと予想されていた 打ち手: 原因の探索
22. オブザーバビリティに着目し、OpenTelemetry & Splunkを導入 https://opentelemetry.io/ja/docs/what-is-opentelemetry/ > オブザーバビリティとは、システムの出力を調べることによって、システムの内部状態を理解する 能力のことです。（中略）システムをオブザーバビリティがある状態にするには、計装されていなけ ればなりません。 つまり、コードがトレース、メトリクス、またはログを出力しなければなりません。 計装されたデータは、オブザーバビリティバックエンドに送信されなければなりません。 Bill Oneでは自動計装を主軸とし、テレメトリーデータをSplunkに直接送信 している 打ち手: 原因の探索
23. （再掲）原因を探すのがとても大変 例: Cloud Run間でHTTP通信を行うサービス 打ち手: オブザーバビリティ（可観測性） Backend Cloud Run Frontend / BFF Cloud Run Backend Cloud Run Backend Cloud Run Database Cloud SQL Database Cloud SQL Database Cloud SQL
24. トレースデータを使うと、レイテンシの遅延場所を容易に特定できる （Splunkのサービスマップ。下記の図は正常時） 打ち手: オブザーバビリティ（可観測性）
25. 導入効果 - レイテンシの悪化に気づくまでの時間が短縮した - 発覚まで数十分ほどかかっていたが、事象によっては最短3分で気づける - 早期検知して手を打って、ユーザー影響が少ないうちに沈静化できている - レイテンシ悪化要因を特定するのが楽になった - 自前で計装することにより、検索条件ごとのレイテンシなども見える - よくある原因は、DBの特定クエリ、サービス間通信など - サービス間の依存を剥がしていくきっかけにもなった 打ち手: オブザーバビリティ（可観測性）
26. 改善の余地がある点 - 計装できていないサービスがまだある - 原則は、プロダクト上重要な部分から対応していく - 計装のライブラリバージョンアップが大変 - どのあたりに原因があるか、しか分からない - 例えば、DBのINSERTが全般的に遅いといったケースでは、発生時間を取得 できてもなぜINSERTが遅いのかわからない - 問題を全て解決できる銀の弾丸ではない - ログと標準メトリクスだけで頑張っていた頃と比較すると、原因特定の効率 はとても良くなったし、計装を増やす手段も取れるのも良い 打ち手: オブザーバビリティ（可観測性）
27. まとめ
28. データ量増加にもしっかり対応できている まとめ 大規模なレイテンシ悪化 可観測性への取り組み 継続的な改善
29. まとめ: 所感 - 拡大するプロダクトを、技術面でしっかり支えている感覚はすごくある - プロダクトの状況変化に技術面で対応することがエンジニアの価値だと 考えているので、機能開発をしなくてもユーザーに貢献できている感覚を 味わえる - 月初を無事乗り切るたびにとても良い気分になれる
30. まとめ: 展望 - データが増える一方という状況を変えるため、データ構造の見直しやプロ ダクトの仕様変更含め、視野を広くして対応する - もっと可観測性を高める - データ量やリクエスト量を再現できる検証環境を用意する - Cloud Service Meshとか、新しいものを取り入れていく - https://cloud.google.com/products/service-mesh?hl=ja
31. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/