実際にリビルドを完遂してみて

by takayuki.miura

Slide 1

Slide 1 text

実際にリビルドを完遂してみてエキサイト株式会社三浦大幸

Slide 2

Slide 2 text

自己紹介三浦大幸エキサイト株式会社 2016年入社技術スタック - バックエンド（PHP・Java等） - フロントエンド（Vue等） - インフラ（AWS） - アプリ（iOS） https://twitter.com/miura0203

Slide 3

Slide 3 text

アジェンダ実際に1年かけて行ったリビルドの、経験と知見を共有します - リビルドの目的 - リビルド内容 - リビルドによる効果予測 - 実際にリビルドを行ったことによる効果 - 大変だったこと - リビルドの効果をより長持ちさせていくには

Slide 4

Slide 4 text

リビルドの目的

Slide 5

Slide 5 text

リビルドの目的 - 担当サービス：ウーマンエキサイト - とても古いサービス - 確認できるだけでも、最終コミットは 2010年

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

リビルドの目的コードがあたかもゴミ屋敷 - 使われていない大量のコード - 1ファイルが長大 - いくつものif分岐が存在する共通メソッド - 謎アーキテクチャなどなど…

Slide 8

Slide 8 text

リビルドの目的ゴミ屋敷だと… - 普段やらないことをしようとすると、何がどこにあるかわからない - 物の位置がすぐに変わってどこにあるかわからなくなる - 新しい入居者が、まともに生活できるようになるまで時間がかかる

Slide 9

Slide 9 text

リビルドの目的ゴミ屋敷（整理されていないコード）だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる - 新しい入居者が、まともに生活できるようになるまで時間がかかる

Slide 10

Slide 10 text

リビルドの目的ゴミ屋敷（整理されていないコード）だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる → バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかかる

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

リビルドの目的掃除することで、以下の達成が期待できる - 普段触っていないものでも、どこにあるかすぐに分かる - 物の位置がちゃんと決められており、失くしにくい - 新しい入居者が、すぐに生活を始められる

Slide 15

Slide 15 text

リビルドの目的掃除（リビルド）することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い - 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

リビルド内容

Slide 19

Slide 19 text

リビルド内容時間の問題もあり、今回は特に使用されている API2つに絞ってリビルド - 言語・フレームワーク - PHP + Bear.Saturday → Java + Spring Boot - Webサーバ - Apache → Nginx - アーキテクチャ - 謎アーキテクチャ → クリーンアーキテクチャ - インフラ - EC2 → ECS（コンテナ化） - キャッシュシステム - ローカルファイル → Redis - その他 - 不要なコードの削除 - 複雑なコードのリファクタリング

Slide 20

Slide 20 text

リビルドによる効果予測

Slide 21

Slide 21 text

Slide 22

Slide 22 text

リビルドによる効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング - アーキテクチャの改善

Slide 23

Slide 23 text

リビルドによる効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング - アーキテクチャの改善 - 希望的観測 - 必要なコンテナスペック減少 - 言語やフレームワークの変更

Slide 24

Slide 24 text

実際にリビルドを行ったことによる効果

Slide 25

Slide 25 text

実際にリビルドを行ったことによる効果 - コード量 1 /4 （ついでにユニットテストも追加）

Slide 26

Slide 26 text

実際にリビルドを行ったことによる効果 - コード量 1 /4 （ついでにユニットテストも追加） → 削減量はともかく、減ったことは想定通り

Slide 27

Slide 27 text

実際にリビルドを行ったことによる効果 - ネットワーク通信量 1 / 2 - サーバ（コンテナ）台数 1 / 3 （スペック単位で計算） - レスポンスタイム 1 / 4

Slide 28

Slide 28 text

実際にリビルドを行ったことによる効果 - ネットワーク通信量 1 / 2 → 不要なレスポンスの削除と、 Nginxにして圧縮されるようになったから？ - サーバ（コンテナ）台数 1 / 3 （スペック単位で計算） → 言語・フレームワークの変更による？ - レスポンスタイム 1 / 4 → 言語・フレームワークの変更と、キャッシュを Redisにしたことによる？

Slide 29

Slide 29 text

実際にリビルドを行ったことによる効果目的は主にコード量の削減やアーキテクチャの変更等で、それ以外の改善は希望的観測だったが、想定以上に改善された

Slide 30

Slide 30 text

大変だったこと

Slide 31

Slide 31 text

大変だったこと時間がかかった最初はAPI2つだけなので、3ヶ月から長くて半年程度で終わると思っていたが、最終的にまるまる 1年かかった。ずっとリビルドをやり続けることが大変だったのはもちろん、リビルドは完了してリリースして初めて成果として現れるので、周りへの申し訳無さもあった。

Slide 32

Slide 32 text

大変だったことどうしてもAPIの入出力は変えられない部分が多いため、合わせる必要があるリビルド対象が限定されていたため、リクエスト・レスポンスデータは大きく変えることができなかった。加えて、本来APIでやらなくてもいいはずの処理だったとしても、場合によってはそのまま APIでやる必要があったりした。

Slide 33

Slide 33 text

大変だったこと使われている部分と使われていない部分の選定使われていない部分は削除することも目的の 1つだったため、 APIの各エンドポイントの使用箇所とそのリクエスト・レスポンスデータ、及びレスポンスデータの使いみちをすべて特定し、使われていない部分を削除した。

Slide 34

Slide 34 text

大変だったこと DBへの接続方法やキャッシュシステムの違いリビルド後はDB接続時にコネクションプールを使うようになったり、キャッシュシステムがファイルから Redisになったことで、考慮すべき点が増えた。

Slide 35

Slide 35 text

リビルドの効果をより長持ちさせていくには

Slide 36

Slide 36 text

リビルドの効果をより長持ちさせていくにはどんなにきれいに掃除しても、その後住人がまた汚く使っていてはいずれゴミ屋敷に戻ってしまう。リビルドも同様で、その時どんなに綺麗に作り直しても、その後考えて開発していかないと、やがてまた汚いコードに戻ってしまう。リビルドの効果をより長持ちさせていくには、 - エンジニアが、可読性や変更容易性を意識して開発していくことが大事

Slide 37

Slide 37 text

ちゃんと掃除しよう！