レガシーシステムのおそうじ / Tidying legacy systems

■イベント
Legacy Meetup Kyoto
https://sansan.connpass.com/event/119556/

■登壇概要
タイトル：レガシーシステムのおそうじ
登壇者：加畑博也

▼Sansan Builders Box
https://buildersbox.corp-sansan.com/

Transcript

1. レガシーシステムのおそうじ Sansan株式会社 加畑博也
2. 自己紹介 - 加畑 博也（Kabata Hiroya） - @kabaome - 基盤チーム - Webエンジニア
3. 今日のおはなし - レガシーシステムとは - おそうじの事例 - おそうじガイド - まとめ
4. レガシーシステムとは
5. レガシーシステムとは：定義 “ 私の定義は非常に広いもので、 保守または拡張が困難な既存の プロジェクトなら、なんでも「レガ シー」（legacy）と呼ぶことにしてい る。”
6. レガシーシステムとは：特徴 - 古い - 大きい - 引き継がれている - ドキュメントが不十分
7. レガシーシステムとは
8. おそうじの事例
9. おそうじの事例 事例1. 名刺画像処理アーキテクチャの刷新 事例2. 名刺データ量の削減 事例3. サンプル名刺の撤廃
10. おそうじの事例 事例1. 名刺画像処理アーキテクチャの刷新 事例2. 名刺データ量の削減 事例3. サンプル名刺の撤廃
11. 事例1. 名刺画像処理アーキテクチャの刷新：背景 「名刺画像のid」と「S3のkey」の変換 名刺画像サイズの正規化 S3アップロード失敗時のバックアップ
12. 事例1. 名刺画像処理アーキテクチャの刷新：課題 - 信頼性 - 単一障害点、名刺画像データが消失するリスク - 性能 - 名刺の取り込み量が増えると、リソース（CPU/Network）が不足 - メンテナンス性 - ブラックボックス化、技術ノウハウの不足
13. 事例1. 名刺画像処理アーキテクチャの刷新：方法
14. 事例1. 名刺画像処理アーキテクチャの刷新：結果 - 信頼性向上 - SDKによるリトライ・適切な例外処理 - 性能向上 - 画像サーバを経由しない - メンテナンス性向上 - アプリケーションコードに組み込み
15. おそうじの事例 事例1. 名刺画像処理アーキテクチャの刷新 事例2. 名刺データ量の削減 事例3. サンプル名刺の撤廃
16. 事例2. 名刺データ量の削減：背景 - データベースは手を入れにくい - レガシー化しやすい - 不要っぽいカラム - 名刺データテーブルにある、 全文検索用のカラム - どうやら使われていない - 確証はない
17. 事例1. 名刺画像処理アーキテクチャの刷新：課題 - 不要なカラム？ - データベース容量を不必要に圧迫する - アプリケーションで不必要に考慮しなければならない - パフォーマンスを劣化させる（PostgreSQLでHOTが効きにくい） https://github.com/postgres/postgres/blob/master/src/backend/access/heap/README.HOT
18. 事例2. 名刺データ量の削減：方法 1. アプリケーションコードからの暗黙的な参照を消す 2. 開発環境の対象カラムをRENAMEしてしばらく放置する 3. 本番環境の対象カラムをRENAMEしてしばらく放置する 4. 本番環境の対象カラムをDROPする
19. 事例2. 名刺データ量の削減：結果 データベース容量にがっつり余裕ができた
20. おそうじの事例 事例1. 名刺画像処理アーキテクチャの刷新 事例2. 名刺データ量の削減 事例3. サンプル名刺の撤廃
21. 事例2. サンプル名刺の撤廃：背景 新規ユーザ登録時、システムが自動で登録する名刺
22. 事例2. サンプル名刺の撤廃：課題 - ユーザ一括登録時の性能ボトルネックになる - ストレージを無駄に消費する - サンプルとそれ以外の分岐がシステム/UIを複雑化する
23. 事例2. サンプル名刺の撤廃：方法 1. サポート部にヒアリング、要件を整理する - 既存のサンプル名刺をどうするか？ 2. タスクを整理する - ユーザとのコミュニケーション => サポート部 - UI変更、ユーザ登録コードの修正 => 開発部 3. サンプル名刺の登録を撤廃する
24. 事例2. サンプル名刺の撤廃：結果 性能改善＆UIの改善により利用率が向上した
25. おそうじガイド
26. おそうじガイド 計測・分解・合意
27. おそうじガイド 計測・分解・合意
28. おそうじガイド：計測 - 課題の定量化 - 「なんとなくよくない」のはみんなわかっている - 初手としての計測 - 計測した結果そのものは負債にならない - 「未知である」ということがレガシー化を促進する
29. おそうじガイド：計測 - 余談：試行錯誤も共有する
30. おそうじガイド：計測 事例 計測したもの 名刺画像処理 アーキテクチャの刷新 刷新前後のレスポンスタイム、画像登録から参照までの タイムラグ、参照頻度、画像サーバのリソース状況、画 像サーバのインスタンス費用、 名刺データ量の削減 DROP前後のテーブル（DB）サイズ、パフォーマンス、ス ケールアウト費用、 サンプル名刺の撤廃 撤廃前後のパフォーマンス、S3ストレージの利用料、
31. おそうじガイド 計測・分解・合意
32. おそうじガイド：分解 - スコープの分解 - 要件は際限なく増幅する - 「やる」と「やらない」の意思決定を明確にする - タスクの分解 - 最小単位のタスクを考える - その上で、「いつだれがやるのか」を考える - リスクの分解 - 複数のリスクを同時にハンドルしようとしない
33. おそうじガイド：スコープの分解 事例 やる やらない 名刺画像処理 アーキテクチャの刷新 画像サーバを TERMINATEする 画像サイズ正規化の 処理を改善する 名刺データ量の削減 テーブルAの 検索用カラムをDROPする テーブルA以外の 検索用カラムをDROPする サンプル名刺の撤廃 サンプル名刺の 新規登録をやめる 既存のサンプル名刺を 削除する
34. おそうじガイド：タスクの分解 - 必要に応じて他チームへ依頼する
35. おそうじガイド：リスクの分解 - 仕様の考慮漏れリスク - 愚直な手動テスト、歴史を知る人に聞く - 想定外の負荷リスク - ユーザ毎・アプリケーション毎に段階を分ける
36. おそうじガイド 計測・分解・合意
37. おそうじガイド：合意 - ステークホルダーとの合意 - “正しい情報があれば正しい判断が下せる” - 事業上（ユーザ）のメリットを言語化する - 開発メンバーとの合意 - 他チームにタスクを依頼する - 「なんのためにやるのか」を繰り返し伝える
38. おそうじガイド：合意 プロジェクト 開発上のメリット 事業上のメリット 名刺画像処理 アーキテクチャの刷新 シンプルになる 速くなる、画像サーバの 維持コストが削れる 名刺データ量の削減 シンプルになる データベース費用が削れる サンプル名刺の撤廃 シンプルになる UIが改善し利用率向上す る、速くなる
39. まとめ https://buildersbox.corp-sansan.com/entry/2018/12/11/110000
40. まとめ “本書を通じて私は「レガシー」（legacy）を、何か悪い言 葉のように扱ってきたが、そうする必要はない。望むと 望まないとに関わらず、我々は次世代の開発者に遺産 （legacy）を残すのだから、できるだけのことをして、誇 らしい遺産にしよう。” 『レガシーソフトウェア改善ガイド』 https://www.shoeisha.co.jp/book/detail/9784798145143