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

Slide 1

Slide 1 text

システムリニューアルをやってみた株式会社ウェイブ渡邉晋 2019/11/30 C-4 #devboostC 1

Slide 2

Slide 2 text

会社紹介株式会社ウェイブ 2010 年設⽴現在約100 名（開発エンジニア15 名）電⼦コミック出版を軸に多⽅⾯に事業を展開アニメ、スマホゲーム等々 2

Slide 3

Slide 3 text

プロフィール現職に2014 年新卒⼊社メインはRails 、AWS を使ったWeb 開発 Unity でiOS 、Android 向けのアプリ開発も経験現在は新規サービスを担当中 3

Slide 4

Slide 4 text

今⽇話すことシステムリニューアルのプロジェクトリーダーをやった話すごくうまくいったという話じゃない当時考えたこと、今振り返って思うこと、リニューアルを通して得たものをお伝えできればと思っています＊ソフトウェアアーキテクチャの詳細な技術や図などのお話は出てきません 4

Slide 5

Slide 5 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 5

Slide 6

Slide 6 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 6

Slide 7

Slide 7 text

サービス紹介 ComicFesta https://comic.iowl.jp/ 電⼦コミック配信サイト Web アプリ⾃社オリジナル作品が読める決済⽅法クレジットカード携帯料⾦合算 7

Slide 8

Slide 8 text

当時の ComicFesta の状況 2017 年5 ⽉時点リリースからの年数 : 6 年⽬開発チーム：3 名ネットワーク構成：アプリ1 台、DB1 台負荷の増加にはスケールアップで対応 8

Slide 9

Slide 9 text

抱えていた問題ライブラリのバージョンが古く、最新の機能が使えないドキュメントが無くブラックボックスな機能テストが無い環境に依存した不具合スペック上限までスケールアップしていた ⇛ システムリニューアルしよう！ 9

Slide 10

Slide 10 text

当時の⾃分のスキルちょうどプロジェクトが終了して空いていた渡邉に⽩⽻の⽮が⽴つ⼩規模プロジェクトをいくつか経験⼩さめ（2core8GB ）のアプリサーバー1 台で済む程度の規模⼤体のプロジェクトが単発で作って終わり経験した開発チームは多くて3 名 O/R マッパーしか使ったことがなく、SQL 書けないシステムリニューアルって何をすればいいの... ？ 10

Slide 11

Slide 11 text

不安最初はリニューアルプロジェクトを１⼈で進めていく既存の開発チームは進めている機能開発が終了次第合流する予定経験のないプロジェクト規模に不安を覚えるひたすら本や他社事例を読んだり、他メンバーの助⾔を受けながらリニューアルに必要そうな知識をつけていくアーキテクチャ設計テーブル設計アジャイル etc 11

Slide 12

Slide 12 text

ある本に出会うレガシーソフトウェア改善ガイドクリス・バーチャル著吉川邦夫訳おすすめリニューアルを考えている⼈はぜひ読んでほしいこの本でリニューアルをするための道筋が⾒えた 12

Slide 13

Slide 13 text

リニューアルへの道筋 1. サービス全体のアーキテクチャを決める 2. リニューアルの進め⽅を決める 3. リニューアル後のためにワークフローと基盤を改善する 13

Slide 14

Slide 14 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 14

Slide 15

Slide 15 text

サービスのアーキテクチャを考える今回のリニューアルではモノリシックな形を⽬指すマイクロサービスなどのサービスの分割も検討するが辞める学習コストと経験不⾜によるリリース時の予期せぬ不具合を懸念不安材料は減らす後々のサービスの分割を⾒据えて、整理されたモノリシックな形のリニューアルを⽬指す 15

Slide 16

Slide 16 text

リリースの⽅法を考える⼀気にリライトしてリリースするビッグバンリリースを選択するまだ今の規模感ならビッグバンリリースで⼗分と判断段階的なリプレイスの場合に考慮しなければならないDB のデータの同期などを無視できるだが、実際はそんな⽢くなかった... 16

Slide 17

Slide 17 text

インフラストラクチャを考える Docker を使う 12FactorApp を参考に環境を構築 https://12factor.net/ja/ 本番、ステージングをできるだけ⼀緒の実⾏環境にする Docker のデプロイ先にはECS を選択する当時、Kubernetes より国内の使⽤実績があったECS を選択したオートスケーリングにも対応させる AWS のマネージドサービスをフルで使う CloudFormation 、RDS 、ElastiCache 、CloudWatch 、etc 17

Slide 18

Slide 18 text

開発環境を考えるできるだけ⾃動化する開発環境は1 コマンドで⽴ち上がるようにする⾃動テストの導⼊ CI/CD の導⼊ DB のスキーマ情報からカラムに対してコメントを書き込める表を⾃動で⽣成するスクリプトを⾃作 ER 図もライブラリを使って⾃動出⼒ 18

Slide 19

Slide 19 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 19

Slide 20

Slide 20 text

期間を⾒積もる開発着⼿時は期間限定メンバーも含めて5 ⼈で開発できることに！⾒積もりは3 ヶ⽉ぐらいを想定参考にできるコードはあるので、うまくリライトしながら実装できれば0 から作るよりはコストは軽そう（と考えた）だが、この⾒積もりが⽢かった... そして2017 年7 ⽉、開発が始まる 20

Slide 21

Slide 21 text

⻑引くリニューアル開発開始して4 ヶ⽉が経過したが進捗は5 割既存のコードには、歴史的背景から対応した特例コードがたくさんドキュメントが無い中で、そのコードを無視してリライトして良いのか調べながら実装するのは思ったよりコストが掛かった... この間は機能開発が進まず、ユーザーに価値を届けられていないビジネス的にまずい状態 21

Slide 22

Slide 22 text

計画を⾒直す必要な機能の優先度を洗い直し、リリース予定⽇を再設定⼗分なリファクタリングができないままの旧コードをもってきたりして、スピードを早める技術的負債は後で回収するという計画 22

Slide 23

Slide 23 text

無事にリリース最終的には7 ヶ⽉の開発期間でリリース技術的負債を許容しないそのままのペースで進めていたら9 ヶ⽉はかかっていたかも...( 当初⾒積もりの約3 倍）リリース時⼤きな不具合はなく、無事稼働することができたリリース後はリニューアルで⽌まっていた新機能開発を優先的に進めていった 23

Slide 24

Slide 24 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 24

Slide 25

Slide 25 text

良かったところテストの導⼊やデバッグを⼿厚く⾏ったので、⼤きな不具合なくリリースができた定量的に⾒られていないが、開発スピードが上がった（と思う）ドキュメント整備と⾃動化で開発が楽になった企画のメンバーに開発が速くなったとお褒めの⾔葉を頂いた 25

Slide 26

Slide 26 text

良かったところリニューアルを通して、⻑く開発していける変更に強いアーキテクチャの設計を学ぶことができた作りっぱなしで良かった今までとは違う視点適切なコンポーネントの分割依存関係の管理ワークフローと基盤の改善 26

Slide 27

Slide 27 text

良くなかったところビッグバンリリースを簡単に選択したことリライトのコスト⾒積もりが⽢かった... 開発が⻑引いてしまった時を考慮して、段階的なリプレイスの検討をもっとしておくべきだった 27

Slide 28

Slide 28 text

良くなかったところ計画の⾒直しが遅かったリリースを早めるため、技術的負債を残すことを選択せざるを得なかった今でもまだ回収できていないところがある⾒積もり⽤の期間を最初の1 ヶ⽉ぐらいとって、その間の開発の進み具合をみてからじっくりリリース計画を練っていけばよかったかも 28

Slide 29

Slide 29 text

⽬次 1. リニューアルを任された不安 2. アーキテクチャの検討 3. ⻑引くリニューアル 4. 振り返って思うこと 5. まとめ 29

Slide 30

Slide 30 text

まとめシステムリニューアルやってよかった変更に強いアーキテクチャの設計を学んだビッグバンリリースで良いのかはよく考えよう不測の⾃体が起きたときのリスクが⼤きい最初の⾒積もりの3 倍は膨れる（＊個⼈の感想です）計画の⾒直しはお早めに技術的負債は残り続ける 30