Slide 1
Slide 1 text
レガシーとの
いい感じの付き合い方
2019/02/14
#devsumiA 14-A-6
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
VOYAGE GROUP
3
Slide 4
Slide 4 text
ECナビ(https://ecnavi.jp)
・2004年スタート
・ネットショッピングでお
得にポイントが貯まる、
ポイントサイト
・主婦層が中心
Slide 5
Slide 5 text
発表者
Slide 6
Slide 6 text
セッション概要
● レガシーシステム改善に取り組む方に向けて、
● 15年物のレガシーシステムを4年間改善し続けている経験を
元に、「レガシーとのいい感じの付き合い方」をお伝えします。
● 「技術詳細」でなく「判断」寄りの説明が多いです。
Slide 7
Slide 7 text
時期 1999年頃〜
2015年10月〜
2016年6月
2016年7月〜
2017年11月
2017年12月〜
2018年4月
2018年4月〜
名称 カイゼン前
カイゼン
事始め
ECナビ
AWS移行
旧管理系
AWS移行
カイゼン
継続中
環境 オンプレ オンプレ
オンプレ
→AWS(大半)
AWS(大半)
→AWS
AWS
カイゼンに取り組んだ2015年〜2018年の活動をお伝えし、
最後に振り返ります。
全体構成
Slide 8
Slide 8 text
カイゼン事始め
時期 1999年頃〜
2015年10月〜
2016年6月
2016年7月〜
2017年11月
2017年12月〜
2018年4月
2018年4月〜
名称 カイゼン前
カイゼン
事始め
ECナビ
AWS移行
旧管理系
AWS移行
カイゼン
継続中
環境 オンプレ オンプレ
オンプレ
→AWS(大半)
AWS(大半)
→AWS
AWS
Slide 9
Slide 9 text
2015年当時の状況(システム周辺)
● 事業ライフサイクルが、成長期から成熟期に差し掛かり始めた
頃。
● 事業方針を「収益成長 only」から「収益成長 and 業務改善」へ
転換
○ ちょうど同時期に、事業全体での振り返りプロジェクトが実
施された。
Slide 10
Slide 10 text
2015年当時の状況(システム周辺)
● エンジニア組織は、別ミッションを持つ2グループで構成。
○ 「システムと開発者の生産性を向上」
■ システム改善専任チーム
● エンジニア組織内で意思決定する
○ 「事業の各領域を成長させる」
■ 別チーム
● 事業側と連動して開発を進める。
Slide 11
Slide 11 text
2015年当時の状況(システム概要)
古くて大規模
10〜15年物が半分
1089機能+900table
旧管理系サーバがカオス
200x年からメンテ放置
雑多詰め込み状態
インフラがオンプレ&別部門管
轄で、変更が遅い。
Slide 12
Slide 12 text
時間が経ち、さらに問題が広がる
がけっぷち。
自分たちで変えてやる
● オンプレ、データセンター撤退の予兆
● エンジニア新規採用、苦戦。
● 在籍エンジニア、モチベーションDOWN
Slide 13
Slide 13 text
● 2015年10月〜12月の3ヶ月で、4-5人で調査とヒアリングした。
その後、事業全体での議論も実施。
● 機能一覧、テーブル一覧、コード量・半減期調査、機能相関分
析、サービス全体図、コスト管理、セキュリティ対策評価、イン
フラ役割分担検討、etc…
● 資料作成は、grep、静的解析、ログ解析、リバースエンジニア
リング、などの手法で実施。新規作成がほぼ。
事始め① 調査
Slide 14
Slide 14 text
具体例) 機能一覧
● 機能とパスを調べ上げ、分類をつけて、一覧形式に。
● 機能単位は、関係者全員で議論できるので便利
Slide 15
Slide 15 text
● 【社内用語】
● 1単位
○ 対象：画面系：URL、バッチ系：crontabでの1行
○ 対象外：システム内部モジュール
● 事業とシステムのインターフェースのような箇所に論点を絞る
ことで、事業部全体で必要性の議論しやすくする。
○ より上段で必要性が判断できれば、詳細な必要性は後で
調べればよい。
事始め① 調査(機能とは？)
Slide 16
Slide 16 text
事始め② “葬り”
● 【社内用語】不要な機能を削除すること
● 初回6ヶ月実施、あとは随時実施。
● 「問題の分母を、手間を掛けずに減らす」効果
Slide 17
Slide 17 text
機能数の推移 2015年→2019年
1876→700
Slide 18
Slide 18 text
テーブル数の推移 2015年→2019年
1200→813
Slide 19
Slide 19 text
コード行数の推移 2015年→2019年
半減
Slide 20
Slide 20 text
無理しない方針
● 長期で段階的にカイゼン
○ 短期のフルリプレースだと、規模的に非現実的。
● 取り組む問題は、絞る
○ 発散してコツコツやっても、規模的に終わらない。
○ 「価値」と「工数」の評価軸で、選びとる。
Slide 21
Slide 21 text
無理しない方針(補足)
● 評価軸
○ 価値
■ 「いま取り組むことで、長期&段階的カイゼンがより加速
していくか？」
○ 工数
■ 「5人くらいのチームで、3〜6ヶ月内で完了できるか？」
Slide 22
Slide 22 text
調査＆葬り後の現状
● インフラは、問題の量と複雑さ & オンプレ環境の制約 & 管轄
の問題が絡み合い、「少しずつカイゼンしていく」ことができな
い。
● アプリケーションは、必要十分に絞った。機能追加と修正は随
時発生。
● アプリケーションをカイゼンするには、コントロールできるインフ
ラがあると、進みが早い。
Slide 23
Slide 23 text
問題選定
● いま、取り組む！
○ 自由なインフラ
■ インフラとアプリを管轄を分けずに運用する
■ レイヤー間で権限を分けず、開発者がコントロール可
能な状態にする。
○ AWS移行
■ サービス全体をオンプレからAWS移行する
○ 開発しやすい環境整備
■ 環境に依らず、アプリケーションを誰でも同じ開発フ
ローで開発できるように、整備しておく
Slide 24
Slide 24 text
問題選定
● 先送り！
○ アプリケーションの根本的見直し
■ インフラの後で。
○ その他
■ ソースコード&データベースがeuc-jp
■ Oracleから卒業
■ 古いインフラ資産のリプレース(監視/ログ/LDAPなど
■ 他サービスのAWS移転
■ サービス間の密結合・依存性の撤廃
■ メール配信サーバリプレース
■ etc...
Slide 25
Slide 25 text
まとめ（カイゼン事始め）
• 調査＆葬りにより、機能を必要十分に絞り、各機能の今後の位
置づけも把握できた。
• 問題自体はリストアップしつつ、無理しない方針と大雑把な判断
軸、だけ認識合わせをし、細かいロードマップを引かなかった。
• 「いま取り組む」と「先送り」をはっきりとさせた。
Slide 26
Slide 26 text
ECナビAWS移行
時期 1999年頃〜
2015年10月〜
2016年6月
2016年7月〜
2017年11月
2017年12月〜
2018年4月
2018年4月〜
名称 カイゼン前
カイゼン
事始め
ECナビ
AWS移行
旧管理系
AWS移行
カイゼン
継続中
環境 オンプレ オンプレ
オンプレ
→AWS(大半)
AWS(大半)
→AWS
AWS
Slide 27
Slide 27 text
移行方針
● こだわる
○ 自由なインフラを実現する
○ AWS移行
○ 開発しやすい環境整備
● こだわらない
○ 積極的に改良しない。既存要件を踏まえればよし。
■ アプリケーションのアーキテクチャ
■ サーバ構成、ミドルウェア
■ 監視、ログ収集
Slide 28
Slide 28 text
● 期間
○ 2016年9月〜2017年2月ごろ
■ 6ヶ月くらいで片付けよう。
■ 移行日は仮
スケジュール
Slide 29
Slide 29 text
先送り
移行範囲
Slide 30
Slide 30 text
移行先(範囲別詳細
● ecnavi-web
○ EC2
■ 問題無さそう
● MySQL
○ RDS MySQL
■ 問題無さそう
● Oracle
○ RDS Oracle
■ 不安…?
Slide 31
Slide 31 text
不安とは？
● Enterprise Edition & RAC & アプライアンス
● 既存と近しい要件が、RDS上では無い。
● サービスレベルを変えない前提での、RDS上での最適構成が
不明。
Slide 32
Slide 32 text
RDS移行
● ランニングコストの問題
○ Enterprise Edition(既存スライド案)
■ 高価！
○ Standard Edition(ダウングレード案)
■ (価格だけ見ると)お値打ち！
● ダウングレード案を深掘り、他の観点で実現可能か
を検討していく
Slide 33
Slide 33 text
ダウングレード案を検証
● 機能差
○ パフォーマンス情報収集が自前
○ メンテナンス作業が自前
● パフォーマンス
○ 問題なし
● データ移行時の互換性、移行時間
○ 問題なし
● ※追加での開発および運用工数が発生するも、それでも断然
お得。
Slide 34
Slide 34 text
● 検証期間
○ 2016年7月〜11月(5ヶ月)
● 結果
○ ダウングレード案でGo
ダウングレード案を検証
Slide 35
Slide 35 text
● 期間
○ 2016年12月〜2017年2月
■ 移行実施タイミングは、2月or4月以降だったので、2月
を選択。
■ 残り3ヶ月で、データベース検証以外の移行タスクを片
付けていく。
スケジュール(データベース検証後、調整
Slide 36
Slide 36 text
● 開発しやすい環境整備に向けて、以下に絞って対応
○ AWSのリソース構築/変更
○ EC2のプロビジョニング
● 選んだ理由
○ 今後の改善が加速させる為に、任意のバージョンの言語
やミドルウェア環境を構築してテストができるようにする。
注力すること
Slide 37
Slide 37 text
目指す状態
● 普段のアプリケーション開発と同じ感覚で、開発/リリースがで
きるようにする
○ コード化する
○ レビュー可能
○ リリースプロセスを自動化する
Slide 38
Slide 38 text
AWSリソース構築
● リリースフロー
Slide 39
Slide 39 text
● CloudFormationテンプレートでコード化
● sandbox環境と本番環境を用意
○ sandboxは、開発者に広く権限を渡し、試して壊すをやりや
すく。
○ 本番は、sandboxで作った構成を再現すれば良い
● レビューフロー(※開発者のスキルに合わせて
○ 実際に構成を作ってからレビュー
○ 不安であれば実際に作る前にレビュー
解説) AWSリソース構築
Slide 40
Slide 40 text
プロビジョニング
● リリースフロー
S3 EC2
Slide 41
Slide 41 text
解説) プロビジョニング
● Puppetマニフェストで管理
○ オンプレで利用されていたものをほぼコピー
● 開発しやすい環境整備の視点で、改善した点
○ Puppetのversionを2系から当時の最新の4系へ
■ 2系は、web上でノウハウ探せない状態
○ CircleCIでマニフェスト適用を試せるように
■ 実際のサーバに依存したコードがあった為
Slide 42
Slide 42 text
やってみた結果
新卒が権限追加依頼のPR投げる
Slide 43
Slide 43 text
やってみた結果
EFS来た！使ってみようをアプリエンジニアから投げられる
Slide 44
Slide 44 text
まとめ（ECナビAWS移行）
• 全体を見通して、一番不安な問題から検証した。不安を解消して
から、具体的な移行作業に入った。
• 達成したいゴールに対して、手段は今あるものを絶対とせず柔
軟に選び直した。
• AWSのリソース構築/変更、EC2のプロビジョニングに絞って、開
発しやすい環境整備を実現させた。
Slide 45
Slide 45 text
旧管理系AWS移行
時期 1999年頃〜
2015年10月〜
2016年6月
2016年7月〜
2017年11月
2017年12月〜
2018年4月
2018年4月〜
名称 カイゼン前
カイゼン
事始め
ECナビ
AWS移行
旧管理系
AWS移行
カイゼン
継続中
環境 オンプレ オンプレ
オンプレ
→AWS(大半)
AWS(大半)
→AWS
AWS
Slide 46
Slide 46 text
旧管理系サーバー
● バックオフィス向け。10-15年選手多し。
○ 管理画面 (主にPHP、一部Perl CGI)
○ バッチ (主にPerl、多種多様)
● 新機能は「新」環境があるので、そちらで。
Slide 47
Slide 47 text
旧管理系サーバー
● 位置付け
○ 事業の大黒柱だが、枯れてる領域。
○ 粛々と安定稼働させたい。機能改良は不要で、修正も歴
史的に少ない。
● 移行後の新サーバ名：antique
Slide 48
Slide 48 text
旧管理系サーバーの内部イメージ
Slide 49
Slide 49 text
アプリケーション
問題点(1) 規模 × レガシーあるある問題
Slide 50
Slide 50 text
225
管理画面のURL Path数
問題点(1) 規模 × レガシーあるある問題
Slide 51
Slide 51 text
470
バッチの数(crontab調べ)
問題点(1) 規模 × レガシーあるある問題
Slide 52
Slide 52 text
レガシーあるある問題(※一部抜粋
● ユニットテストが書かれていないコード多数
● 継続的なテストが行われていないため、知らない間に動かなくなっている
● 積み重なったパッチ的な対応の結果、膨れ上がったクラス
● 同じような機能を持つライブラリ
● Subversion の複数リポジトリが複雑に配置
● サードパーティのコードがリポジトリに含まれている
● crontab で華麗にスケジューリング、順序が重要！
● 局所最適結果として乱立するフレームワークとその亜種。
● アプリ間やアプリ-FW間の依存も強く、絶妙なバランスで動いている
● 絶対パスによるファイルの参照
● 実行環境に依存するパラメータのハードコーディング
● 他とは異なる開発/デプロイフロー(本番サーバーでsvn up)
● 学習コストが高くなり結果として属人化
(※小さい問題は、他にも多数)
:
Slide 53
Slide 53 text
システム基盤
問題点(2) システム基盤周りがメンテし辛い
Slide 54
Slide 54 text
No content
Slide 55
Slide 55 text
古さの歴史的経緯
● OS、言語バージョン、ミドルウェアが、単純に古すぎ。
● 過去に数回サーバーリプレイスは実施したが、物理サーバの
載せ替えに留まり、この点は改善は無し。
○ 当時のリソース状況や事業状況により、問題点に対応しき
るパワーが無かった。
○ 社内システムという甘え
Slide 56
Slide 56 text
単にEC2に移行した場合に残る問題
● アプリケーションやフレームワーク
○ 数の多さ×レガシー満載
○ 開発しにくい環境
■ 膨れ上がった Subversion リポジトリ
■ 本番環境に ssh ログイン & svn up
● インフラ
○ 「古い」ままのリスク
○ 既にAWSで稼動中のシステムと異なる構成
Slide 57
Slide 57 text
移行時の改善ポイント
● 開発しやすい環境整備
○ Subversion から Git へ
○ パッケージ管理ツール(Composer/Carton)の導入
■ Subversionレポジトリにコミットされた、サードパーティ
のコードを移設
○ Jenkins による自動デプロイ
● 自由なインフラ
○ マシンイメージをAWS上の既存システムと同一に 。
Slide 58
Slide 58 text
移行時の先送りポイント
● 先送り
○ アプリケーションをクラウドネイティブな構成へ
■ 改善ポイントに関わる所を、必要最小限で対応するに
留める
○ ユニットテスト書いてカバレッジを上げる
■ 時間が掛かりすぎるし、後からでもできる為
Slide 59
Slide 59 text
テスト方針
● 1.新環境でユニットテストがパスする
○ UTのカバレッジ低い。
○ UTを増やすのは、時間が掛かりすぎる。
● 2.本番に近い環境で、実際に動かして、アウトプットを照合する
○ 課題：開発環境のデータは、本番環境とは程遠い
Slide 60
Slide 60 text
テスト環境への要求
● 本番相当のデータを利用できる
● データが壊れても元に戻る
● 本番環境やユーザーに影響を与えない
→ 自由なインフラを活用する
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
解説) テスト環境
● 「ECナビAWS移行」で構築した、CFn + Puppet で作成。
● AWS LambdaでCFnのChangeSetを作成し、日次でRDSスナッ
プショットからリストア
● 本番環境とはネットワーク上分離。メールサーバーは、送信を
外向けにブロック
● エラー通知はSlackに転送し、エラー状況を可視化
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
解説) テスト方法
● バッチ1つずつ
○ 1.テスト環境でテスト
■ 結果が、現行本番環境とテスト環境で比較して同一で
あることで担保
● 既存仕様で、メールでこと細かに実行結果が送ら
れくるので、活用。
○ 2.テストがクリアしたら、新本番環境へ移行。現行本番環
境で停止。
● 実際実施してみると、想定通りには、いかず。
Slide 65
Slide 65 text
バッチ一つ動かしてみると
● ユニットテストが書かれていないコード多数
● 継続的なテストが行われていないため、知らない間に動かなくなっている
● 積み重なったパッチ的な対応の結果、膨れ上がったクラス
● 同じような機能を持つライブラリ
● Subversion の複数リポジトリが複雑に配置
● サードパーティのコードがリポジトリに含まれている
● crontab で華麗にスケジューリング、順序が重要！
● 局所最適結果として乱立するフレームワークとその亜種
● 絶対パスによるファイルの参照
● 実行環境に依存するパラメータのハードコーディング
● 他とは異なる開発/デプロイフロー(本番サーバーでsvn up)
● 学習コストが高くなり結果として属人化
:
エラーおおすぎ
Slide 66
Slide 66 text
エラー要因
● 先にあげたあるあるの課題が足かせになって、エラーが大量
にでる。
● 特にハードコーディングとかライブラリの問題とか根幹の部分
のエラーが多く発生
● 軌道修正しよう
Slide 67
Slide 67 text
テスト軌道修正(1)
● エラー多発問題
○ 個別で無く横断的に把握してまとめて潰す。
■ 1.テスト環境で、全バッチをスケジュール通りに動作。
■ 2.エラーを捕捉分析して、原因に対処。
Slide 68
Slide 68 text
テスト軌道修正(2)
● 密結合・依存性問題
○ 移行単位をバッチ単位で無く、似たものグループ単位にし
て、問題を軽減する。
■ 任意のバッチグループと管理画面を分けて
Slide 69
Slide 69 text
軌道修正後の進捗
● Slackエラー件数推移
○ 2018/1/21 1982 件 ← 全実行スタート
○ 2018/1/30 528 件 ← 潰し回る日々
○ 2018/2/10 23 件 ← ほぼ問題無し
● バッチは、まとまった単位で段階的に移行
● 管理画面は運用者含め、みんなでＥ２Ｅテスト後、一気に移行
Slide 70
Slide 70 text
オンプレ卒業
● 約4ヶ月で、470 バッチ、 225 画面の移行
● 移行後のトラブルは、特に無し。安定稼働。
Slide 71
Slide 71 text
まとめ（旧管理系AWS移行）
● レガシーの厄介な問題に対して、手書き図のように大雑把に捉
えて把握し、要因に個別対処せずに解決する手段を考え出し
た。
● システムに対する今後の期待を踏まえ、解決したい問題(自由
なインフラと開発環境の整備)と先送る問題を切り分けた。
● 取り組みながら見えてきた課題には、既存の実現手段に拘ら
ず、手元の武器(AWS移行後の環境、バッチのメールなど)を組
み合わせて、新しい手段(テスト環境)を作っていく。
Slide 72
Slide 72 text
振り返り
Slide 73
Slide 73 text
時期 1999年頃〜
2015年10月〜
2016年6月
2016年7月〜
2017年3月
2017年4月〜
2018年9月
2018年10月〜
名称 カイゼン前
カイゼン
事始め
ECナビ
AWS移行
旧管理系
AWS移行
カイゼン
継続中
環境 オンプレ オンプレ オンプレ→AWS(大半) AWS(大半)→AWS AWS
カイゼン実績
● 全サービスのAWS移転、開発しやすい環境整備、アプリ・イン
フラ運用、葬り済みの機能
Slide 74
Slide 74 text
● 無理はしてない。
○ 普通に。
○ 長時間労働、要員追加、精神的ストレスは、特に。
● でも、着実にレガシーから脱却しつつある。
相当頑張った？
Slide 75
Slide 75 text
● 「レガシーシステムは、問題の”数”と”質”の2面の難しさがあ
る。でも、一度に取り組む数を減らせば、攻略は、少しずつだ
が確実に進められるだろう」という認識があった。
● だから、各個撃破という戦法を選択した。
○ 問題の量と複雑さに苦しまないように切り分けて
○ 1個ずつ各個撃破し
○ コントロール可能な範囲を徐々に広げた。
○ 以上を繰り返す。
なぜ「無理せずカイゼンが進む」？
Slide 76
Slide 76 text
● 現状把握から始める
○ レガシーシステムの事実をカイゼンの立脚点とする
● いま取り組む事を絞る
○ 効果x工数のコスパの良さで見極める
● 建設的先送り
○ 色々手を出す位なら、先送る。
○ 周辺状況の変化により、あとの方が対応しやすくなること
もある。
各個撃破を実現する基本動作
Slide 77
Slide 77 text
レガシーとのいい感じの付き合い方
各個撃破！
● 現状把握から始める
● いま取り組む事を絞る
● 建設的先送り
はじめは、
問題を減らす & 解けるサイズに切り出すところから！
ご清聴ありがとうございました