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

13d936e697fe0f4fa96f926d0a712f6c?s=47 Sansan
February 22, 2019

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

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

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

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

13d936e697fe0f4fa96f926d0a712f6c?s=128

Sansan

February 22, 2019
Tweet

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

  41. None