「ブランドオフィシャル」 というサービスの開発エンジニアをしている suezawan といいます。
主にエンジニアチームのタスクマネジメントを行っています。
本日は、Developers Summit 2019 に参加してきたので、レポートを投稿します！
私が申し込んだセッションは、下記になります。※写真撮影OKのセッションです
レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜
大きすぎるレガシーシステム攻略において、“コツコツリファクタリング”だけではビクともせず、“ビックバンリリース”はリスキーすぎるという悩みがつきものです。そんな中、私達は、“いい感じの付き合い方”を探りながら、アプリケーションを大きく変更せず、オンプレからクラウドへ移行しました。取り組んできた4年間の各フェーズごとの戦略と戦術を紹介し、レガシーシステム改善の注力ポイントを明示します。
https://event.shoeisha.jp/devsumi/20190214/session/1933/
申し込んだ理由
弊社のサービスは長年続いているものが多く、レガシーシステムと化しているものもあり、改善したいけど新規開発でそこまで手が回らない場合があります。それを改善する方法として他社の実績を知見にしたかったというのがあります。
セッションレポート
カイゼン事始め
事業ライフサイクル : 成長期から成熟期
事業方針 収益成長 only -> 収益成長 and 業務改善へ
システム改善チーム発足
■ 事業方針に即して改善部隊を作られたようです。やはり事業としてサービスを成長させるために新規サービス（機能）をローンチする開発チームと、改善チームは分けたほうが人的リソースの観点からもよさそうと思います（ただ人的リソースが潤沢でないと難しいとも思いました）
当時システム概要
10〜15年ものが半分
1089機能 + 900 table
旧管理サーバがカオス
200x年からメンテ放置 -> 手が付けられない
インフラがオンプレ＆別部署管理でスピードがでない
■ セッション中に度々でたワードで「自由なインフラ（インフラとアプリの管理を分けずに運用する）」がありました。アプリケーションエンジニアがアプリケーションのコードを管理するように、インフラもコードで管理し、自分たちでメンテナンスできる環境をつくったそうです。
さらなる問題
データセンタからの撤退
エンジニア新規採用、苦戦
在籍エンジニア、モチベーションDOWN
崖っぷち自分たちで立ち向かうしかない
■ レガシーシステムを放置しておくことは巡り巡って自分たちの首をしめるか、未来のエンジニアに問題を先延ばしするかになりますが、どこかでリソースを割いてやりきるという強い意思決定が必要 と感じました。
事始め１
3ヶ月で、4-5人で調査、ヒアリング
機能一覧、テーブル一覧、などで見える化して言った。機能一覧、テーブル一覧、などで見える化して言った。
■ 一番効果があったものとして、機能一覧とURLパスを調べ上げ分類をつけて一覧形式にして可視化したことでした。さらに機能単位になることで関係者全員で議論できたことが良かったとのこと。
事始め “葬り”
社内用語 “葬り”とは、不要な機能を削除すること
実績 2015年 -> 2019年
機能数 1876 -> 700まで削減
テーブル数 1200 -> 813
■ 4年間でということなので、地道にリファクタリングされていったのかなと思いました。
無理しない方針
フルリプレースする工数捻出は難しい
■ レガシーすぎるから、もういっそ作り直したほうがいい というのはよく言われたりしますが、レガシーすぎてそもそも仕様把握できていないものを互換性維持したりとか考えると、まずはスリム化すべきだよなぁと話聞いてて思いました。
AWSリソース移行
そのまま持ってく（アプリケーションのアーキテクチャ、サーバ構成、ミドルウェア、監視、ログ収集）
■ 「自由なインフラ」を満たすためにAWS移行！まずはオンプレで動いている環境をそのままAWSに移行することを優先し、下記を実施したとのこと。
・AWSリソース構築/変更の簡易化
・EC2のプロビジョニング化
・CloudFormationの利用したインフラのコード化
・リリースプロセスの可視化
いまでは、EFSが利用できるようになったら、カジュアルにPRだしてさわってみるなど、「自由なインフラ」になったことで改善が進みやすくなったとのこと。
旧管理系AWS移行
サービス運営に必要なバックオフィス向けの管理画面
有象無象のバッチ群
管理画面のURL Path数 225
バッチ：cron数 470（crontab調べ）
量以外の課題も山積
ミドルウェアが古い
Googleで検索しても情報出てこない
脆弱性を踏んでいるバージョン
テストコードがない
■ 一気にヘビーな話になりました・・・インフラをAWS利用にしたことで本番データをテスト系で利用し、エラーをslack通知してつぶしていったそう。これにより全体のエラーの量を俯瞰してみる環境が整えられ、あとはエラーをつぶしていく作業を愚直にされたのかなと思いました。
セッションを通して
セッションを聴きに来た半数は10年以上のレガシーシステムを保守している人たちでした。レガシーシステムと面と向かい合って改善することは非常に労力がかかりますし、それをすることで目に見えて（わかりやすく）価値あるサービスになるかと言われるとそうでないことが多いかと思います。
ただ、やり遂げた先にはエンジニアとして成長でき、貴重な経験になると信じて、皆さんもレガシーシステムと真摯に向き合っていきましょう！！
Developers Summit 2019は明日も開催されます！
明日もセッションを楽しみましょう！
デブサミ2019、講演関連資料まとめ も参考にどうぞ。
SHARE YOUR FUN!
