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