システムリニューアルをやってみた/tried-system-renewal

Transcript

1. システムリニューアルをやってみた 株式会社ウェイブ 渡邉 晋 2019/11/30 C-4 #devboostC 1
2. 会社紹介 株式会社ウェイブ 2010 年設⽴ 現在 約100 名（開発エンジニア15 名） 電⼦コミック出版を軸に多⽅⾯に事業を展開 アニメ、スマホゲーム等々 2
3. プロフィール 現職に2014 年新卒⼊社 メインはRails 、AWS を使ったWeb 開発 Unity でiOS 、Android 向けのアプリ開発も経験 現在は新規サービスを担当中 3
4. 今⽇話すこと システムリニューアルのプロジェクトリーダーをやった話 すごくうまくいったという話じゃない 当時考えたこと、今振り返って思うこと、リニューアルを通して 得たものをお伝えできればと思っています ＊ソフトウェアアーキテクチャの詳細な技術や図などのお話は出てき ません 4
5. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 5
6. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 6
7. サービス紹介 ComicFesta https://comic.iowl.jp/ 電⼦コミック配信サイト Web アプリ ⾃社オリジナル作品が読める 決済⽅法 クレジットカード 携帯料⾦合算 7
8. 当時の ComicFesta の状況 2017 年5 ⽉時点 リリースからの年数 : 6 年⽬ 開発チーム：3 名 ネットワーク構成 ：アプリ1 台、DB1 台 負荷の増加には スケールアップで対応 8
9. 抱えていた問題 ライブラリのバージョンが古く、最新の機能が使えない ドキュメントが無くブラックボックスな機能 テストが無い 環境に依存した不具合 スペック上限までスケールアップしていた ⇛ システムリニューアルしよう！ 9
10. 当時の⾃分のスキル ちょうどプロジェクトが終了して空いていた渡邉に⽩⽻の⽮が⽴つ ⼩規模プロジェクトをいくつか経験 ⼩さめ（2core8GB ）のアプリサーバー1 台で済む程度の規模 ⼤体のプロジェクトが単発で作って終わり 経験した開発チームは多くて3 名 O/R マッパーしか使ったことがなく、SQL 書けない システムリニューアルって何をすればいいの... ？ 10
11. 不安 最初はリニューアルプロジェクトを１⼈で進めていく 既存の開発チームは進めている機能開発が終了次第合流する予定 経験のないプロジェクト規模に不安を覚える ひたすら本や他社事例を読んだり、他メンバーの助⾔を受けながら リニューアルに必要そうな知識をつけていく アーキテクチャ設計 テーブル設計 アジャイル etc 11
12. ある本に出会う レガシーソフトウェア改善ガイド クリス・バーチャル 著 吉川邦夫 訳 おすすめ リニューアルを考えている⼈はぜひ読んで ほしい この本でリニューアルをするための道筋が ⾒えた 12
13. リニューアルへの道筋 1. サービス全体のアーキテクチャを決める 2. リニューアルの進め⽅を決める 3. リニューアル後のためにワークフローと基盤を改善する 13
14. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 14
15. サービスのアーキテクチャを考える 今回のリニューアルではモノリシックな形を⽬指す マイクロサービスなどのサービスの分割も検討するが辞める 学習コストと経験不⾜によるリリース時の予期せぬ不具合を懸念 不安材料は減らす 後々のサービスの分割を⾒据えて、整理されたモノリシックな形の リニューアルを⽬指す 15
16. リリースの⽅法を考える ⼀気にリライトしてリリースするビッグバンリリースを選択する まだ今の規模感ならビッグバンリリースで⼗分と判断 段階的なリプレイスの場合に考慮しなければならないDB の データの同期などを無視できる だが、実際はそんな⽢くなかった... 16
17. インフラストラクチャを考える Docker を使う 12FactorApp を参考に環境を構築 https://12factor.net/ja/ 本番、ステージングをできるだけ⼀緒の実⾏環境にする Docker のデプロイ先にはECS を選択する 当時、Kubernetes より国内の使⽤実績があったECS を選択した オートスケーリングにも対応させる AWS のマネージドサービスをフルで使う CloudFormation 、RDS 、ElastiCache 、CloudWatch 、etc 17
18. 開発環境を考える できるだけ⾃動化する 開発環境は1 コマンドで⽴ち上がるようにする ⾃動テストの導⼊ CI/CD の導⼊ DB のスキーマ情報からカラムに対してコメントを書き込める表を ⾃動で⽣成するスクリプトを⾃作 ER 図もライブラリを使って⾃動出⼒ 18
19. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 19
20. 期間を⾒積もる 開発着⼿時は期間限定メンバーも含めて5 ⼈で開発できることに！ ⾒積もりは3 ヶ⽉ぐらいを想定 参考にできるコードはあるので、うまくリライトしながら実装 できれば0 から作るよりはコストは軽そう（と考えた） だが、この⾒積もりが⽢かった... そして2017 年7 ⽉、開発が始まる 20
21. ⻑引くリニューアル 開発開始して4 ヶ⽉が経過したが進捗は5 割 既存のコードには、歴史的背景から対応した特例コードがたくさん ドキュメントが無い中で、そのコードを無視してリライトして良 いのか調べながら実装するのは思ったよりコストが掛かった... この間は機能開発が進まず、ユーザーに価値を届けられていない ビジネス的にまずい状態 21
22. 計画を⾒直す 必要な機能の優先度を洗い直し、リリース予定⽇を再設定 ⼗分なリファクタリングができないままの旧コードを もってきたりして、スピードを早める 技術的負債は後で回収するという計画 22
23. 無事にリリース 最終的には7 ヶ⽉の開発期間でリリース 技術的負債を許容しないそのままのペースで進めていたら9 ヶ⽉ はかかっていたかも...( 当初⾒積もりの約3 倍） リリース時⼤きな不具合はなく、無事稼働することができた リリース後はリニューアルで⽌まっていた新機能開発を優先的に 進めていった 23
24. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 24
25. 良かったところ テスト の導⼊やデバッグを⼿厚く⾏ったので、⼤きな不具合なく リリースができた 定量的に⾒られていないが、開発スピードが上がった（と思う） ドキュメント整備と⾃動化で開発が楽になった 企画のメンバーに開発が速くなったと お褒めの⾔葉を頂いた 25
26. 良かったところ リニューアルを通して、⻑く開発していける 変更に強いアーキテクチャの設計を学ぶことができた 作りっぱなしで良かった今までとは違う視点 適切なコンポーネントの分割 依存関係の管理 ワークフローと基盤の改善 26
27. 良くなかったところ ビッグバンリリースを簡単に選択したこと リライトのコスト⾒積もりが⽢かった... 開発が⻑引いてしまった時を考慮して、段階的なリプレイスの 検討をもっとしておくべきだった 27
28. 良くなかったところ 計画の⾒直しが遅かった リリースを早めるため、技術的負債を残すことを選択せざるを 得なかった 今でもまだ回収できていないところがある ⾒積もり⽤の期間を最初の1 ヶ⽉ぐらいとって、その間の開発の 進み具合をみてからじっくりリリース計画を練っていけばよかっ たかも 28
29. ⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 29
30. まとめ システムリニューアルやってよかった 変更に強いアーキテクチャの設計を学んだ ビッグバンリリースで良いのかはよく考えよう 不測の⾃体が起きたときのリスクが⼤きい 最初の⾒積もりの3 倍は膨れる（＊個⼈の感想です） 計画の⾒直しはお早めに 技術的負債は残り続ける 30