Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Living with legacy systems

fukudat
February 14, 2019

Living with legacy systems

デブサミ2019 14-A-6 「レガシーのいい感じの付き合い方」

fukudat

February 14, 2019
Tweet

Other Decks in Technology

Transcript

  1. レガシーとの
    いい感じの付き合い方
    2019/02/14
    #devsumiA 14-A-6

    View Slide

  2. View Slide

  3. VOYAGE GROUP
    3

    View Slide

  4. ECナビ(https://ecnavi.jp)
    ・2004年スタート
    ・ネットショッピングでお
    得にポイントが貯まる、
    ポイントサイト
    ・主婦層が中心

    View Slide

  5. 発表者

    View Slide

  6. セッション概要
    ● レガシーシステム改善に取り組む方に向けて、
    ● 15年物のレガシーシステムを4年間改善し続けている経験を
    元に、「レガシーとのいい感じの付き合い方」をお伝えします。
    ● 「技術詳細」でなく「判断」寄りの説明が多いです。

    View Slide

  7. 時期 1999年頃〜
    2015年10月〜
    2016年6月
    2016年7月〜
    2017年11月
    2017年12月〜
    2018年4月
    2018年4月〜
    名称 カイゼン前
    カイゼン
    事始め
    ECナビ
    AWS移行
    旧管理系
    AWS移行
    カイゼン
    継続中
    環境 オンプレ オンプレ
    オンプレ
    →AWS(大半)
    AWS(大半)
    →AWS
    AWS
    カイゼンに取り組んだ2015年〜2018年の活動をお伝えし、
    最後に振り返ります。
    全体構成

    View Slide

  8. カイゼン事始め
    時期 1999年頃〜
    2015年10月〜
    2016年6月
    2016年7月〜
    2017年11月
    2017年12月〜
    2018年4月
    2018年4月〜
    名称 カイゼン前
    カイゼン
    事始め
    ECナビ
    AWS移行
    旧管理系
    AWS移行
    カイゼン
    継続中
    環境 オンプレ オンプレ
    オンプレ
    →AWS(大半)
    AWS(大半)
    →AWS
    AWS

    View Slide

  9. 2015年当時の状況(システム周辺)
    ● 事業ライフサイクルが、成長期から成熟期に差し掛かり始めた
    頃。
    ● 事業方針を「収益成長 only」から「収益成長 and 業務改善」へ
    転換
    ○ ちょうど同時期に、事業全体での振り返りプロジェクトが実
    施された。

    View Slide

  10. 2015年当時の状況(システム周辺)
    ● エンジニア組織は、別ミッションを持つ2グループで構成。
    ○ 「システムと開発者の生産性を向上」
    ■ システム改善専任チーム
    ● エンジニア組織内で意思決定する
    ○ 「事業の各領域を成長させる」
    ■ 別チーム
    ● 事業側と連動して開発を進める。

    View Slide

  11. 2015年当時の状況(システム概要)
    古くて大規模
    10〜15年物が半分
    1089機能+900table
    旧管理系サーバがカオス
    200x年からメンテ放置
    雑多詰め込み状態
    インフラがオンプレ&別部門管
    轄で、変更が遅い。

    View Slide

  12. 時間が経ち、さらに問題が広がる
    がけっぷち。
    自分たちで変えてやる
    ● オンプレ、データセンター撤退の予兆
    ● エンジニア新規採用、苦戦。
    ● 在籍エンジニア、モチベーションDOWN

    View Slide

  13. ● 2015年10月〜12月の3ヶ月で、4-5人で調査とヒアリングした。
    その後、事業全体での議論も実施。
    ● 機能一覧、テーブル一覧、コード量・半減期調査、機能相関分
    析、サービス全体図、コスト管理、セキュリティ対策評価、イン
    フラ役割分担検討、etc…
    ● 資料作成は、grep、静的解析、ログ解析、リバースエンジニア
    リング、などの手法で実施。新規作成がほぼ。
    事始め① 調査

    View Slide

  14. 具体例) 機能一覧
    ● 機能とパスを調べ上げ、分類をつけて、一覧形式に。
    ● 機能単位は、関係者全員で議論できるので便利

    View Slide

  15. ● 【社内用語】
    ● 1単位
    ○ 対象:画面系:URL、バッチ系:crontabでの1行
    ○ 対象外:システム内部モジュール
    ● 事業とシステムのインターフェースのような箇所に論点を絞る
    ことで、事業部全体で必要性の議論しやすくする。
    ○ より上段で必要性が判断できれば、詳細な必要性は後で
    調べればよい。
    事始め① 調査(機能とは?)

    View Slide

  16. 事始め② “葬り”
    ● 【社内用語】不要な機能を削除すること
    ● 初回6ヶ月実施、あとは随時実施。
    ● 「問題の分母を、手間を掛けずに減らす」効果

    View Slide

  17. 機能数の推移 2015年→2019年
    1876→700

    View Slide

  18. テーブル数の推移 2015年→2019年
    1200→813

    View Slide

  19. コード行数の推移 2015年→2019年
    半減

    View Slide

  20. 無理しない方針
    ● 長期で段階的にカイゼン
    ○ 短期のフルリプレースだと、規模的に非現実的。
    ● 取り組む問題は、絞る
    ○ 発散してコツコツやっても、規模的に終わらない。
    ○ 「価値」と「工数」の評価軸で、選びとる。

    View Slide

  21. 無理しない方針(補足)
    ● 評価軸
    ○ 価値
    ■ 「いま取り組むことで、長期&段階的カイゼンがより加速
    していくか?」
    ○ 工数
    ■ 「5人くらいのチームで、3〜6ヶ月内で完了できるか?」

    View Slide

  22. 調査&葬り後の現状
    ● インフラは、問題の量と複雑さ & オンプレ環境の制約 & 管轄
    の問題が絡み合い、「少しずつカイゼンしていく」ことができな
    い。
    ● アプリケーションは、必要十分に絞った。機能追加と修正は随
    時発生。
    ● アプリケーションをカイゼンするには、コントロールできるインフ
    ラがあると、進みが早い。

    View Slide

  23. 問題選定
    ● いま、取り組む!
    ○ 自由なインフラ
    ■ インフラとアプリを管轄を分けずに運用する
    ■ レイヤー間で権限を分けず、開発者がコントロール可
    能な状態にする。
    ○ AWS移行
    ■ サービス全体をオンプレからAWS移行する
    ○ 開発しやすい環境整備
    ■ 環境に依らず、アプリケーションを誰でも同じ開発フ
    ローで開発できるように、整備しておく

    View Slide

  24. 問題選定
    ● 先送り!
    ○ アプリケーションの根本的見直し
    ■ インフラの後で。
    ○ その他
    ■ ソースコード&データベースがeuc-jp
    ■ Oracleから卒業
    ■ 古いインフラ資産のリプレース(監視/ログ/LDAPなど
    ■ 他サービスのAWS移転
    ■ サービス間の密結合・依存性の撤廃
    ■ メール配信サーバリプレース
    ■ etc...

    View Slide

  25. まとめ(カイゼン事始め)
    • 調査&葬りにより、機能を必要十分に絞り、各機能の今後の位
    置づけも把握できた。
    • 問題自体はリストアップしつつ、無理しない方針と大雑把な判断
    軸、だけ認識合わせをし、細かいロードマップを引かなかった。
    • 「いま取り組む」と「先送り」をはっきりとさせた。

    View Slide

  26. ECナビAWS移行
    時期 1999年頃〜
    2015年10月〜
    2016年6月
    2016年7月〜
    2017年11月
    2017年12月〜
    2018年4月
    2018年4月〜
    名称 カイゼン前
    カイゼン
    事始め
    ECナビ
    AWS移行
    旧管理系
    AWS移行
    カイゼン
    継続中
    環境 オンプレ オンプレ
    オンプレ
    →AWS(大半)
    AWS(大半)
    →AWS
    AWS

    View Slide

  27. 移行方針
    ● こだわる
    ○ 自由なインフラを実現する
    ○ AWS移行
    ○ 開発しやすい環境整備
    ● こだわらない
    ○ 積極的に改良しない。既存要件を踏まえればよし。
    ■ アプリケーションのアーキテクチャ
    ■ サーバ構成、ミドルウェア
    ■ 監視、ログ収集

    View Slide

  28. ● 期間
    ○ 2016年9月〜2017年2月ごろ
    ■ 6ヶ月くらいで片付けよう。
    ■ 移行日は仮
    スケジュール

    View Slide

  29. 先送り
    移行範囲

    View Slide

  30. 移行先(範囲別詳細
    ● ecnavi-web
    ○ EC2
    ■ 問題無さそう
    ● MySQL
    ○ RDS MySQL
    ■ 問題無さそう
    ● Oracle
    ○ RDS Oracle
    ■ 不安…?

    View Slide

  31. 不安とは?
    ● Enterprise Edition & RAC & アプライアンス
    ● 既存と近しい要件が、RDS上では無い。
    ● サービスレベルを変えない前提での、RDS上での最適構成が
    不明。

    View Slide

  32. RDS移行
    ● ランニングコストの問題
    ○ Enterprise Edition(既存スライド案)
    ■ 高価!
    ○ Standard Edition(ダウングレード案)
    ■ (価格だけ見ると)お値打ち!
    ● ダウングレード案を深掘り、他の観点で実現可能か
    を検討していく

    View Slide

  33. ダウングレード案を検証
    ● 機能差
    ○ パフォーマンス情報収集が自前
    ○ メンテナンス作業が自前
    ● パフォーマンス
    ○ 問題なし
    ● データ移行時の互換性、移行時間
    ○ 問題なし
    ● ※追加での開発および運用工数が発生するも、それでも断然
    お得。

    View Slide

  34. ● 検証期間
    ○ 2016年7月〜11月(5ヶ月)
    ● 結果
    ○ ダウングレード案でGo
    ダウングレード案を検証

    View Slide

  35. ● 期間
    ○ 2016年12月〜2017年2月
    ■ 移行実施タイミングは、2月or4月以降だったので、2月
    を選択。
    ■ 残り3ヶ月で、データベース検証以外の移行タスクを片
    付けていく。
    スケジュール(データベース検証後、調整

    View Slide

  36. ● 開発しやすい環境整備に向けて、以下に絞って対応
    ○ AWSのリソース構築/変更
    ○ EC2のプロビジョニング
    ● 選んだ理由
    ○ 今後の改善が加速させる為に、任意のバージョンの言語
    やミドルウェア環境を構築してテストができるようにする。
    注力すること

    View Slide

  37. 目指す状態
    ● 普段のアプリケーション開発と同じ感覚で、開発/リリースがで
    きるようにする
    ○ コード化する
    ○ レビュー可能
    ○ リリースプロセスを自動化する

    View Slide

  38. AWSリソース構築
    ● リリースフロー

    View Slide

  39. ● CloudFormationテンプレートでコード化
    ● sandbox環境と本番環境を用意
    ○ sandboxは、開発者に広く権限を渡し、試して壊すをやりや
    すく。
    ○ 本番は、sandboxで作った構成を再現すれば良い
    ● レビューフロー(※開発者のスキルに合わせて
    ○ 実際に構成を作ってからレビュー
    ○ 不安であれば実際に作る前にレビュー
    解説) AWSリソース構築

    View Slide

  40. プロビジョニング
    ● リリースフロー
    S3 EC2

    View Slide

  41. 解説) プロビジョニング
    ● Puppetマニフェストで管理
    ○ オンプレで利用されていたものをほぼコピー
    ● 開発しやすい環境整備の視点で、改善した点
    ○ Puppetのversionを2系から当時の最新の4系へ
    ■ 2系は、web上でノウハウ探せない状態
    ○ CircleCIでマニフェスト適用を試せるように
    ■ 実際のサーバに依存したコードがあった為

    View Slide

  42. やってみた結果
    新卒が権限追加依頼のPR投げる

    View Slide

  43. やってみた結果
    EFS来た!使ってみようをアプリエンジニアから投げられる

    View Slide

  44. まとめ(ECナビAWS移行)
    • 全体を見通して、一番不安な問題から検証した。不安を解消して
    から、具体的な移行作業に入った。
    • 達成したいゴールに対して、手段は今あるものを絶対とせず柔
    軟に選び直した。
    • AWSのリソース構築/変更、EC2のプロビジョニングに絞って、開
    発しやすい環境整備を実現させた。

    View Slide

  45. 旧管理系AWS移行
    時期 1999年頃〜
    2015年10月〜
    2016年6月
    2016年7月〜
    2017年11月
    2017年12月〜
    2018年4月
    2018年4月〜
    名称 カイゼン前
    カイゼン
    事始め
    ECナビ
    AWS移行
    旧管理系
    AWS移行
    カイゼン
    継続中
    環境 オンプレ オンプレ
    オンプレ
    →AWS(大半)
    AWS(大半)
    →AWS
    AWS

    View Slide

  46. 旧管理系サーバー
    ● バックオフィス向け。10-15年選手多し。
    ○ 管理画面 (主にPHP、一部Perl CGI)
    ○ バッチ (主にPerl、多種多様)
    ● 新機能は「新」環境があるので、そちらで。

    View Slide

  47. 旧管理系サーバー
    ● 位置付け
    ○ 事業の大黒柱だが、枯れてる領域。
    ○ 粛々と安定稼働させたい。機能改良は不要で、修正も歴
    史的に少ない。
    ● 移行後の新サーバ名:antique

    View Slide

  48. 旧管理系サーバーの内部イメージ

    View Slide

  49. アプリケーション
    問題点(1) 規模 × レガシーあるある問題

    View Slide

  50. 225
    管理画面のURL Path数
    問題点(1) 規模 × レガシーあるある問題

    View Slide

  51. 470
    バッチの数(crontab調べ)
    問題点(1) 規模 × レガシーあるある問題

    View Slide

  52. レガシーあるある問題(※一部抜粋
    ● ユニットテストが書かれていないコード多数
    ● 継続的なテストが行われていないため、知らない間に動かなくなっている
    ● 積み重なったパッチ的な対応の結果、膨れ上がったクラス
    ● 同じような機能を持つライブラリ
    ● Subversion の複数リポジトリが複雑に配置
    ● サードパーティのコードがリポジトリに含まれている
    ● crontab で華麗にスケジューリング、順序が重要!
    ● 局所最適結果として乱立するフレームワークとその亜種。
    ● アプリ間やアプリ-FW間の依存も強く、絶妙なバランスで動いている
    ● 絶対パスによるファイルの参照
    ● 実行環境に依存するパラメータのハードコーディング
    ● 他とは異なる開発/デプロイフロー(本番サーバーでsvn up)
    ● 学習コストが高くなり結果として属人化
    (※小さい問題は、他にも多数)
    :

    View Slide

  53. システム基盤
    問題点(2) システム基盤周りがメンテし辛い

    View Slide

  54. View Slide

  55. 古さの歴史的経緯
    ● OS、言語バージョン、ミドルウェアが、単純に古すぎ。
    ● 過去に数回サーバーリプレイスは実施したが、物理サーバの
    載せ替えに留まり、この点は改善は無し。
    ○ 当時のリソース状況や事業状況により、問題点に対応しき
    るパワーが無かった。
    ○ 社内システムという甘え

    View Slide

  56. 単にEC2に移行した場合に残る問題
    ● アプリケーションやフレームワーク
    ○ 数の多さ×レガシー満載
    ○ 開発しにくい環境
    ■ 膨れ上がった Subversion リポジトリ
    ■ 本番環境に ssh ログイン & svn up
    ● インフラ
    ○ 「古い」ままのリスク
    ○ 既にAWSで稼動中のシステムと異なる構成

    View Slide

  57. 移行時の改善ポイント
    ● 開発しやすい環境整備
    ○ Subversion から Git へ
    ○ パッケージ管理ツール(Composer/Carton)の導入
    ■ Subversionレポジトリにコミットされた、サードパーティ
    のコードを移設
    ○ Jenkins による自動デプロイ
    ● 自由なインフラ
    ○ マシンイメージをAWS上の既存システムと同一に 。

    View Slide

  58. 移行時の先送りポイント
    ● 先送り
    ○ アプリケーションをクラウドネイティブな構成へ
    ■ 改善ポイントに関わる所を、必要最小限で対応するに
    留める
    ○ ユニットテスト書いてカバレッジを上げる
    ■ 時間が掛かりすぎるし、後からでもできる為

    View Slide

  59. テスト方針
    ● 1.新環境でユニットテストがパスする
    ○ UTのカバレッジ低い。
    ○ UTを増やすのは、時間が掛かりすぎる。
    ● 2.本番に近い環境で、実際に動かして、アウトプットを照合する
    ○ 課題:開発環境のデータは、本番環境とは程遠い

    View Slide

  60. テスト環境への要求
    ● 本番相当のデータを利用できる
    ● データが壊れても元に戻る
    ● 本番環境やユーザーに影響を与えない
    → 自由なインフラを活用する

    View Slide

  61. View Slide

  62. 解説) テスト環境
    ● 「ECナビAWS移行」で構築した、CFn + Puppet で作成。
    ● AWS LambdaでCFnのChangeSetを作成し、日次でRDSスナッ
    プショットからリストア
    ● 本番環境とはネットワーク上分離。メールサーバーは、送信を
    外向けにブロック
    ● エラー通知はSlackに転送し、エラー状況を可視化

    View Slide

  63. View Slide

  64. 解説) テスト方法
    ● バッチ1つずつ
    ○ 1.テスト環境でテスト
    ■ 結果が、現行本番環境とテスト環境で比較して同一で
    あることで担保
    ● 既存仕様で、メールでこと細かに実行結果が送ら
    れくるので、活用。
    ○ 2.テストがクリアしたら、新本番環境へ移行。現行本番環
    境で停止。
    ● 実際実施してみると、想定通りには、いかず。

    View Slide

  65. バッチ一つ動かしてみると
    ● ユニットテストが書かれていないコード多数
    ● 継続的なテストが行われていないため、知らない間に動かなくなっている
    ● 積み重なったパッチ的な対応の結果、膨れ上がったクラス
    ● 同じような機能を持つライブラリ
    ● Subversion の複数リポジトリが複雑に配置
    ● サードパーティのコードがリポジトリに含まれている
    ● crontab で華麗にスケジューリング、順序が重要!
    ● 局所最適結果として乱立するフレームワークとその亜種
    ● 絶対パスによるファイルの参照
    ● 実行環境に依存するパラメータのハードコーディング
    ● 他とは異なる開発/デプロイフロー(本番サーバーでsvn up)
    ● 学習コストが高くなり結果として属人化
    :
    エラーおおすぎ

    View Slide

  66. エラー要因
    ● 先にあげたあるあるの課題が足かせになって、エラーが大量
    にでる。
    ● 特にハードコーディングとかライブラリの問題とか根幹の部分
    のエラーが多く発生
    ● 軌道修正しよう

    View Slide

  67. テスト軌道修正(1)
    ● エラー多発問題
    ○ 個別で無く横断的に把握してまとめて潰す。
    ■ 1.テスト環境で、全バッチをスケジュール通りに動作。
    ■ 2.エラーを捕捉分析して、原因に対処。

    View Slide

  68. テスト軌道修正(2)
    ● 密結合・依存性問題
    ○ 移行単位をバッチ単位で無く、似たものグループ単位にし
    て、問題を軽減する。
    ■ 任意のバッチグループと管理画面を分けて

    View Slide

  69. 軌道修正後の進捗
    ● Slackエラー件数推移
    ○ 2018/1/21 1982 件 ← 全実行スタート
    ○ 2018/1/30 528 件 ← 潰し回る日々
    ○ 2018/2/10 23 件 ← ほぼ問題無し
    ● バッチは、まとまった単位で段階的に移行
    ● 管理画面は運用者含め、みんなでE2Eテスト後、一気に移行

    View Slide

  70. オンプレ卒業
    ● 約4ヶ月で、470 バッチ、 225 画面の移行
    ● 移行後のトラブルは、特に無し。安定稼働。

    View Slide

  71. まとめ(旧管理系AWS移行)
    ● レガシーの厄介な問題に対して、手書き図のように大雑把に捉
    えて把握し、要因に個別対処せずに解決する手段を考え出し
    た。
    ● システムに対する今後の期待を踏まえ、解決したい問題(自由
    なインフラと開発環境の整備)と先送る問題を切り分けた。
    ● 取り組みながら見えてきた課題には、既存の実現手段に拘ら
    ず、手元の武器(AWS移行後の環境、バッチのメールなど)を組
    み合わせて、新しい手段(テスト環境)を作っていく。

    View Slide

  72. 振り返り

    View Slide

  73. 時期 1999年頃〜
    2015年10月〜
    2016年6月
    2016年7月〜
    2017年3月
    2017年4月〜
    2018年9月
    2018年10月〜
    名称 カイゼン前
    カイゼン
    事始め
    ECナビ
    AWS移行
    旧管理系
    AWS移行
    カイゼン
    継続中
    環境 オンプレ オンプレ オンプレ→AWS(大半) AWS(大半)→AWS AWS
    カイゼン実績
    ● 全サービスのAWS移転、開発しやすい環境整備、アプリ・イン
    フラ運用、葬り済みの機能

    View Slide

  74. ● 無理はしてない。
    ○ 普通に。
    ○ 長時間労働、要員追加、精神的ストレスは、特に。
    ● でも、着実にレガシーから脱却しつつある。
    相当頑張った?

    View Slide

  75. ● 「レガシーシステムは、問題の”数”と”質”の2面の難しさがあ
    る。でも、一度に取り組む数を減らせば、攻略は、少しずつだ
    が確実に進められるだろう」という認識があった。
    ● だから、各個撃破という戦法を選択した。
    ○ 問題の量と複雑さに苦しまないように切り分けて
    ○ 1個ずつ各個撃破し
    ○ コントロール可能な範囲を徐々に広げた。
    ○ 以上を繰り返す。
    なぜ「無理せずカイゼンが進む」?

    View Slide

  76. ● 現状把握から始める
    ○ レガシーシステムの事実をカイゼンの立脚点とする
    ● いま取り組む事を絞る
    ○ 効果x工数のコスパの良さで見極める
    ● 建設的先送り
    ○ 色々手を出す位なら、先送る。
    ○ 周辺状況の変化により、あとの方が対応しやすくなること
    もある。
    各個撃破を実現する基本動作

    View Slide

  77. レガシーとのいい感じの付き合い方
    各個撃破!
    ● 現状把握から始める
    ● いま取り組む事を絞る
    ● 建設的先送り
    はじめは、
    問題を減らす & 解けるサイズに切り出すところから!
    ご清聴ありがとうございました

    View Slide