０→１フェーズのプロダクトのパフォーマンス分析をしてみた話/登壇資料（二瓶 亮）

「【ログラス×Hacobu】各業界が直面するドメイン課題と解決に向けたアプローチとは」
2024年4月25日（木）19:00〜21:00
https://hacobu.connpass.com/event/312643/

Transcript

1. Confidential ０→１フェーズのプロダクトの パフォーマンス分析をしてみた話 2024年4月25日 二瓶 亮
2. Copyright Hacobu, Inc. 2 自己紹介 二瓶 亮（にへい りょう） nihei9 2023年5月、Hacobuに入社。 配送案件管理サービスMOVO Vistaの開発を経て、 現在はトラック予約受付サービスMOVO Berthの開発に携わる。 株式会社 Hacobu バックエンドエンジニア
3. Copyright Hacobu, Inc. 3 今日話すこと 目立ったパフォーマンス問題がないプロダクトでも、 パフォーマンス分析をすることで潜在的な問題に気づけるかもしれない。 ※パフォーマンスはAPIの応答速度に限定して話します。
4. MOVO Vista？ 分析の動機
5. Copyright Hacobu, Inc. 5 MOVO Vista？ 配送案件管理サービス ＝ ものを動かす人たちのコミュニケーションをオンラインで実現するDXツール 運んで欲しいものがある人たち ものを運べる人たち 下請けに依頼することも多い
6. Copyright Hacobu, Inc. 6 MOVO Vista？ 取引関係の多さ ＋ 多重下請け → 取引データが増えやすい構造 運んで欲しいものがある人たち ものを運べる人たち 下請けに依頼することも多い この人たちがVistaを契約してくれるとこの人たちは無料でVistaを使えるようになる。 同一案件で複数の運送会社に依頼を出すこともある。 トラック輸送における多重下請構造につ いての実態把握調査に係る調査結果 多重下請け構造が問題視されている。
7. Copyright Hacobu, Inc. 7 分析の動機 ビジネス目標の達成をシステムのスケーラビリティが阻害することを懸念していた。 取引データが一気に増えやすい。 トラフィックの規模の割にDBの負荷が 高い。 深刻なパフォーマンス問題は起きてい ない。 導入社数を増やしたい。 プロダクトの性 質 開発チームの モニタリング ビジネス目標 データ量の増加が気になる。 将来的にパフォーマンスが悪化しそうなAPIにあ たりがつけられたら嬉しいかもしれない。 潜在的な問題がいつ顕在化してもおかしくない。 取引関係の多さ・多重下請構造 物流業界の性質 潜在的な問題をどうやって見つけよう？
8. Copyright Hacobu, Inc. 8 分析の動機 パフォーマンスの不安定さに注目してみる。 応答速度が不安定 → 何かに依存して応答速度が変化しやすい 仮説 応答速度のばらつきを調べることから始めよう。
9. データのばらつき具合の可視化
10. Copyright Hacobu, Inc. 10 データのばらつき具合の可視化 箱ひげ図 ＝ データのばらつき具合を表した図 参考：総務省統計局 | なるほど統計学園 ＜ ばらつき 中央値 小さい 大きい 大きい 小さい ＞ ※箱の幅に意味はない 最大値 最小値 中央値 50% 25% 25% 箱やひげが長い ＝ データが広くばらついている
11. APIの応答速度の分布を調べる （実際のデータ）
12. Copyright Hacobu, Inc. 12 APIの応答速度の分布を調べる 実際の図 「ばらつきが大きい ＝ 不安定」と捉えてみる。 箱の幅が広い 箱の幅が狭い 応答速度が 不安定 応答速度が 安定的 ※Spread Sheetのローソク足チャートを使用しています。厳密には箱ひげ図ではありませんが見方は同じです。
13. Copyright Hacobu, Inc. 13 APIの応答速度の分布を調べる 中央値は高いが比較的安定している。 全体的にばらつきが大きい。 大部分は比較的安定してそうだ が、ばらつきの裾が広い。 ヒストグラムでもう少し詳しく分布を見てみる。
14. Copyright Hacobu, Inc. 14 APIの応答速度の分布を調べる 山が２つある（二峰性）。 異なる性質を持つ集団のデータが混在 していると考えられる。 使っているユーザーとそのデータ規模 に偏りがあるのかもしれない。 一定規模以上のデータは処理方法変えたりデ ータ量の制限を設けたりするといいかもしれ ない。 一般論 仮説 観測値
15. Copyright Hacobu, Inc. 15 APIの応答速度の分布を調べる データ量などの影響を受けやすく、パフォーマンスの劣化 する速度が速いのかもしれない。 ばらつきの裾が非常に広い。 観測値 仮説 計算量削減や最悪時のパフォーマンスだけでも改善する ことを目標にチューニングするといいかもしれない。
16. Copyright Hacobu, Inc. 16 APIの応答速度の分布を調べる 応答速度の分布を可視化することはAPIのパフォーマンス特性を捉えるのに役立った。 もっと具体的に調べるには？ • プロファイリングツールの結果をフレームグラフなどで可視化する。 • パフォーマンステストを実施してより詳細なパフォーマンス特性を把握する。 他のアプローチは？ • マシンリソースの面からパフォーマンスを分析する。 • 分析せずにパフォーマンステストからパフォーマンス特性を調査する。 応答速度の分布を知ることで単一の統計値より深くAPIの特性を理解できる。 パフォーマンスの平均値・中央値と安定性は区別して考えた方がいい。 パフォーマンス特性を知ることはチューニングの方向性を考えるヒントにも なる。 学び
17. Copyright Hacobu, Inc. 17 まとめ ユーザー数が少なくても傾向を分析することで予防的な対策への第一歩になる。 ユーザー数が少ないプロダクトでは、パフォーマンス問題は後回しにされがちなうえ、平均値 などの単一の統計値を観察するだけでは潜在的な問題に気づきづらい。 パフォーマンスの不安定さに注目することで潜在的な問題に気づけるかもしれない。 システムのスケーラビリティがビジネスの成長が阻害しないようにするための予防的な分析と して効果的だった。 分析は将来的なリスクへの解像度を上げることにも寄与し、関係者間の認識を合わせることに も役立った。 まとめ