10年以上続くシステムと向き合い始めた事例の紹介

2021-09-22
RECRUIT TECH MEETUP登壇時の資料です

Transcript

1. 10年以上続くシステムと 向き合い始めた事例の紹介 秋⽥ 諒 2021-09-22 RECRUIT TECH MEETUP #1
2. Whoami 秋⽥ 諒 • 株式会社リクルート（2017~） • 『じゃらんnet 』の開発、プロジェク トマネジメントなどを担当 • Java / Spring / Python / AWS 2
3. 今⽇話すこと ⻑年の増改築で肥⼤化したシステムが抱えていた問題に取り組んだ事例の紹介 • きっかけ • どうやって⼊っていったか • （技術要素は少なめです） 3
4. 『じゃらんnet 』 4
5. 『じゃらんnet 』 • 宿・ホテル予約サイト • 2000年からサービス開始 • 宿予約だけではなくレンタカー や⾶⾏機・新幹線の予約なども 可能 5 ͡ΌΒΜετʔϦʔ
   IUUQTXXXSFDSVJUDPKQTFSWJDFTUPSZKBMBOIUNM
6. 『じゃらんnet 』｜システム関連 • Java（独⾃FW） • オンプレ環境 6 ೥ͷ૿վஙͷ݁Ռ • クラス数：数万 • リポジトリ数：数百 • テーブル数：数千 構成 規模感 ※ 関連システム、じゃらんの全サービスを考慮
7. 『じゃらんnet 』とクーポン 7
8. 『じゃらんnet 』とクーポン • 『じゃらんnet 』では定期的にクーポンを発⾏しておりお客様からも好評をい ただいている 8 めっちゃ安くなった！ クーポン配布してる！ 無くなる前に急げー！
9. 配布⽅法 • 先着順 • 配布⽇時がセールのページに記載 9
10. 配布開始直後どうなるか • ユーザからの⼤量アクセス 10
11. 配布開始直後どうなるか • ユーザからの⼤量アクセスでDBの⼀部でCPU使⽤率が100%に 😇 11 クーポン配布開始直後のDBのCPU使⽤率グラフ（⼀部抜粋）
12. 開発者から⾒た当時のクーポン 12 複雑性 ⼤ システム負荷 ⼤ • 定期的に⼤型クーポンを配布 • 配布⽇の10時は恐怖 • 機能改修の頻度が⾼い機能 • 仕様が複雑で全体感が 
 把握できない • 実装はそれ以上に複雑
13. 開発者から⾒た当時のクーポン 13 複雑性 ⼤ システム負荷 ⼤ • 定期的に⼤型クーポンを配布 • 配布⽇の10時は恐怖 • 機能改修の頻度が⾼い機能 • 仕様が複雑で全体感が 
 把握できない • 実装はそれ以上に複雑 ΫʔϙϯػೳΛͳΜͱ͔͠ͳ͍ͱʜ
    ࠶ߏஙઆ͕ೱް
    ˠ
    ݕ౼Λґཔ͞ΕΔ
14. 戦略検討 14
15. アサイン当初思ったこと • 「再構築」の聞こえは魅⼒的だが結構時間がかかりそう ‣ 再構築が終わるまでビクビクしながらセールを迎えたくない • 「システム負荷」と「複雑性」は分けて考えたい ‣ （正直そんなてんこ盛りプロジェクト回せる⾃信ない） 15
16. システム負荷から攻める • セール時にユーザが通る導線を事前に軽く調査してみたところ無駄な処理が 結構ありそうなことが分かった • 勝ち筋が少し⾒えたので「開発者が安⼼してセールを迎える」ことを第⼀⽬ 標にプロジェクトを進めることに決めた 16 ϓϩδΣΫτݑষΑΓ
17. が、「複雑性の改善」に対して仕込みはしておく • ある程度負荷が改善し、プロジェクトの信頼感が獲得できれば「複雑性の改 善」への対応がやりやすくなるのではという仮説 • 負荷系の調査と同時に「複雑性の改善」に対しての仕様理解や課題整理もで きると嬉しい 17 ϓϩδΣΫτݑষΑΓ
18. 戦略サマリ｜短期と中⻑期の2階建て 18 2階 （中⻑期） 1階 （短期） セール時の 
 システム負荷 取り組む課題 得られるもの 仕様と実装の複雑性 セール時の安⼼感 周りからの信頼 素早く質の⾼い 
 機能開発 仕様理解
19. 戦略サマリ｜短期と中⻑期の2階建て 19 2階 （中⻑期） 1階 （短期） セール時の 
 システム負荷 取り組む課題 得られるもの 仕様と実装の複雑性 セール時の安⼼感 周りからの信頼 素早く質の⾼い 
 機能開発 仕様理解 イマココ 今回の内容は基本的に短期の内容のみ。 短期⽬標プロジェクトにどれくらい中⻑期を⾒越したものを混ぜたのか。を話す
20. プロジェクトスタート 20
21. 負荷改善プロジェクトはこんなフェーズで実施 21 情報 収集 対策 検討 実装 効果 測定 2020/11~ 2020/12~ 2021/01~ 2021/04~
22. 情報収集フェーズ 中⻑期を⾒越した幅優先での情報収集と対外的な印象づけ 22 開発軸 ユースケース軸 ‣ 対象機能⼀覧 ‣ リソース使⽤状況の整理 ‣ 画⾯遷移図 ‣ クーポン系障害整理 ‣ ソースコードリーディング ‣ ⽤語整理 ‣ 使われ⽅整理 
 （データのライフサイクル） 情報 収集 対策 検討 実装 効果測定
23. 中⻑期を⾒越した幅優先での情報収集と対外的な印象づけ 情報収集フェーズ 23 情報 収集 対策 検討 実装 効果測定 クーポンでこういう問題が 起きてて整理してるんです！ 分からないところを 教えてください！ اը୲౰ऀ όοΫΦϑΟεܥ୲౰ऀ ։ൃऀ この⼈たちは クーポンの⼈なんだな ヒアリングを⾏いつつ課題感を共有 「クーポン関連で開発者が動いてそう」という認識を持ってもらう
24. ここから先はセール時の負荷改善へ深さ優先で検討 対策検討フェーズ 24 情報 収集 対策 検討 実装 効果測定
25. 1. 対象機能⼀覧や画⾯遷移図を地図として、セール時にアクセスが多い機能を 特定 2. アクセスが多い機能のボトルネックをリソースの使⽤状況などから調査 3. ボトルネックを⾒つけ、打ち⼿を考える 対策検討フェーズ｜取り組み⽅ 25 情報 収集 対策 検討 実装 効果測定
26. セール導線の課題詳細と打ち⼿ • 結果がどこにも使われていないSQLがある • ⼤量のマスタデータを取得するSQLがリクエストのたびに実⾏されている • クーポンを発⾏時、発⾏枚数をカウントするために⾏ロックを取得。⼤量ア クセスが来るとロック解放待ちが発⽣（何度かリトライしてロックが取れな かったらエラーへ遷移） 26 情報 収集 対策 検討 実装 効果測定 注：発⾏枚数は「クーポンが使われた予約数」とは別の概念。『じゃらんnet 』を使うユーザからは⾒えない。
27. セール導線の課題詳細と打ち⼿ • 結果がどこにも使われていないSQLがある ‣ 消す！ • ⼤量のマスタデータを取得するSQLがリクエストのたびに実⾏されている ‣ キャッシュ化 • クーポンを発⾏時、発⾏枚数をカウントするために⾏ロックを取得。⼤量ア クセスが来るとロック解放待ちが発⽣（何度かリトライしてロックが取れな かったらエラーへ遷移） ‣ 即時のカウントアップではなく定期バッチで発⾏枚数を集計するように仕様変更を提 案 27 情報 収集 対策 検討 実装 効果測定 注：発⾏枚数は「クーポンが使われた予約数」とは別の概念。『じゃらんnet 』を使うユーザからは⾒えない。
28. やることが決まったらあとは粛々と装着 • ソースコードリーディングや仕様理解が進んでいたこともあり、実装⾃体は 無難に終了 28 情報 収集 対策 検討 実装 効果測定
29. 配布開始直後どうなるか • ユーザからの⼤量アクセスでDBの⼀部でCPU使⽤率が100%に 😇 29 クーポン配布開始直後のDBのCPU使⽤率グラフ（⼀部抜粋） 再掲
30. 効果測定｜実際負荷はどうなったのか • クーポンのセール導線のスループットが10倍以上になりつつ、DBの負荷は余 裕あり 30 情報 収集 対策 検討 実装 効果測定 セール開始時刻
31. 効果測定｜実際負荷はどうなったのか • クーポンのセール導線のスループットが10倍以上になりつつ、DBの負荷は余 裕あり 31 情報 収集 対策 検討 実装 効果測定 セール開始時刻 短期⽬標達成
32. ⼤変だったこと 32
33. ⼤変だったこと① • 開発外の体制/責務理解 ‣ 新機能を企画するチームやクーポンを使った施策を考えるマーケティングチームなど、 それぞれが思いを持っている ‣ 仕様や要件に対して「この観点だと〇〇チームの確認が必要ですね」などが良くあっ た 33 各チームの責務を理解することを⼼がける 各チームの⾔葉で話せるようになるまでドキュメントを読んだり場数をこなす
34. ⼤変だったこと② • ソースコード理解 ‣ 基本的にトランザクションスクリプトで記載されているため重複などが多く実装も⻑ くなりがち ‣ システム⾃体が巨⼤、関連システムも多いためローカル環境構築も⼀苦労 34 ペアでソースコードリーディング 動かさないと分からない箇所はすでに環境構築してる開発者を巻き込む
35. 中⻑期に向けて 35
36. 戦略サマリ｜短期と中⻑期の2階建て 36 2階 （中⻑期） 1階 （短期） セール時の 
 システム負荷 取り組む課題 得られるもの 仕様と実装の複雑性 セール時の安⼼感 周りからの信頼 素早く質の⾼い 
 機能開発 仕様理解 再掲
37. 短期から中⻑期への移⾏はどうだったのか 🙆 うまくいったこと • クーポン系の機能開発の時に⾃分たちに声がかかるように ‣ クーポンを網羅的に調査したことで仕様を⼀番理解しているのが⾃分たちになっていた ‣ 社内的に「ちょっと聞いとこ」や「頭出ししとこ」という存在に 🙅 うまくいかなかったこと • 機能開発に向けたプロセス整備が遅れ、移⾏期に混乱が発⽣ ‣ 別チームの開発者から「⼀応設計⾒ておいてもらおう」で来た依頼が、クーポン全体を 破壊しかねない修正だったりして企画担当者に「ほんまゴメンやけどやり直させてく ださい」ってお願いしに⾏った ‣ 必要な⼿戻りだったが、もう少し⼿前で指摘できればよかった 37
38. 今やっていること 中⻑期に⼊りかけ。⼟台づくり中。 38 課題 打ち⼿の⽅針 ・仕様や要件がまとまっていない ・検討中（ナレッジ？要件定義書の⾒直し？） ・難易度の⾼い要件を無理に実現しようとし  て複雑な実装が⽣まれている ・まずは新規案件でこれ以上の負を⽣まないよう  なプロセス設計中 ・すでに複雑な箇所は要求を整理中。仕様調整や  現在の仕様に基づいたデータモデルを検討中
39. やっていき 💪 39