Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実際にリビルドを完遂してみて
Search
takayuki.miura
June 28, 2022
Technology
0
550
実際にリビルドを完遂してみて
takayuki.miura
June 28, 2022
Tweet
Share
More Decks by takayuki.miura
See All by takayuki.miura
TerraformをやめてCDKでReStartしたあと、 CDKをやめてCDK for TerraformでReStartした話
tmiura0203
0
840
急激なDB書き込みが行われるサービスをリビルドした話
tmiura0203
0
600
Spring Bootという強すぎるフレームワークについて
tmiura0203
0
630
Other Decks in Technology
See All in Technology
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
240
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
570
GraphQL 成熟度モデルの紹介と、プロダクトに当てはめた事例 / GraphQL maturity model
mh4gf
7
1.3k
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
530
私が trocco を推す理由
__allllllllez__
1
230
エンジニアのキャリアをちょっと楽しくする3本の軸/Three Pillars to Make an Engineer's Career More Enjoyable
kwappa
0
2.7k
プラットフォームってつくることより計測することが重要なんじゃないかという話 / Platform Engineering Meetup #8
taishin
1
370
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
730
Kernel MemoryでAzure OpenAI Serviceとお手軽データソース連携
mitsuzono
1
250
【NW X Security JAWS#3】L3-4:AWS環境のIPv6移行に向けて知っておきたいこと
shotashiratori
0
310
開発パフォーマンスを最大化するための開発体制
ham0215
2
430
SIEMを用いて、セキュリティログ分析の可視化と分析を実現し、PDCAサイクルを回してみた
coconala_engineer
0
320
Featured
See All Featured
Debugging Ruby Performance
tmm1
70
11k
Being A Developer After 40
akosma
57
580k
The Pragmatic Product Professional
lauravandoore
25
5.8k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Building a Scalable Design System with Sketch
lauravandoore
456
32k
How to name files
jennybc
65
93k
Optimizing for Happiness
mojombo
370
69k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Side Projects
sachag
451
41k
Build your cross-platform service in a week with App Engine
jlugia
225
17k
Typedesign – Prime Four
hannesfritz
36
2.1k
Transcript
実際にリビルドを完遂し てみて エキサイト株式会社 三浦大幸
自己紹介 三浦大幸 エキサイト株式会社 2016年入社 技術スタック - バックエンド(PHP・Java等) - フロントエンド(Vue等) -
インフラ(AWS) - アプリ(iOS) https://twitter.com/miura0203
アジェンダ 実際に1年かけて行ったリビルドの、経験と知見を共有し ます - リビルドの目的 - リビルド内容 - リビルドによる効果予測 -
実際にリビルドを行ったことによる効果 - 大変だったこと - リビルドの効果をより長持ちさせていくには
リビルドの目的
リビルドの目的 - 担当サービス:ウーマンエキサイト - とても古いサービス - 確認できるだけでも、最終コミットは 2010年
None
リビルドの目的 コードがあたかもゴミ屋敷 - 使われていない大量のコード - 1ファイルが長大 - いくつものif分岐が存在する共通メソッド - 謎アーキテクチャ
などなど…
リビルドの目的 ゴミ屋敷だと… - 普段やらないことをしようとすると、何がどこにあるかわからない - 物の位置がすぐに変わってどこにあるかわからなくなる - 新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる -
新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる → 発展的な開発が難しい
リビルドの目的 ゴミ屋敷(整理されていないコード )だと… - 普段やらないことをしようとすると、何がどこにあるかわからない → 普段やっていない開発をしようとすると、大量の時間がかかる - 物の位置がすぐに変わってどこにあるかわからなくなる →
バグの発生率が高い - 新しい入居者が、まともに生活できるようになるまで時間がかか る → オンボーディングに時間がかかる → 発展的な開発が難しい でも、これからはガンガン開発していきたい …
リビルドの目的 掃除することで、以下の達成が期待できる - 普段触っていないものでも、どこにあるかすぐに分かる - 物の位置がちゃんと決められており、失くしにくい - 新しい入居者が、すぐに生活を始められる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる → 発展的な開発がしやすくなる
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる → 発展的な開発がしやすくなる ガンガン開発できる!
リビルド内容
リビルド内容 時間の問題もあり、今回は特に使用されている API2つに絞って リビルド - 言語・フレームワーク - PHP + Bear.Saturday
→ Java + Spring Boot - Webサーバ - Apache → Nginx - アーキテクチャ - 謎アーキテクチャ → クリーンアーキテクチャ - インフラ - EC2 → ECS(コンテナ化) - キャッシュシステム - ローカルファイル → Redis - その他 - 不要なコードの削除 - 複雑なコードのリファクタリング
リビルドによる効果予測
リビルドの目的 掃除(リビルド)することで、以下を達成したい - 普段触っていないものでも、どこにあるかすぐに分かる → 普段触っていない部分の開発でも、高スピードで進められる - 物の位置がちゃんと決められており、失くしにくい → バグの発生率が低い
- 新しい入居者が、すぐに生活を始められる → オンボーディングが簡単にできる
リビルドによる 効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング
- アーキテクチャの改善
リビルドによる 効果予測 - 予測 - コード量減少 - 不要なコード削除 - 複雑なコードのリファクタリング
- アーキテクチャの改善 - 希望的観測 - 必要なコンテナスペック減少 - 言語やフレームワークの変更
実際にリビルドを行ったことによる効果
実際にリビルドを行ったこ とによる効果 - コード量 1 /4 (ついでにユニットテストも追加)
実際にリビルドを行ったこ とによる効果 - コード量 1 /4 (ついでにユニットテストも追加) → 削減量はともかく、減ったことは想定通り
実際にリビルドを行ったこ とによる効果 - ネットワーク通信量 1 / 2 - サーバ(コンテナ)台数 1
/ 3 (スペック単位で計算) - レスポンスタイム 1 / 4
実際にリビルドを行ったこ とによる効果 - ネットワーク通信量 1 / 2 → 不要なレスポンスの削除と、 Nginxにして圧縮されるよう
になったから? - サーバ(コンテナ)台数 1 / 3 (スペック単位で計算) → 言語・フレームワークの変更による? - レスポンスタイム 1 / 4 → 言語・フレームワークの変更と、キャッシュを Redisにした ことによる?
実際にリビルドを行ったこ とによる効果 目的は主にコード量の削減やアーキテクチャ の変更等で、それ以外の改善は希望的観測 だったが、想定以上に改善された
大変だったこと
大変だったこと 時間がかかった 最初はAPI2つだけなので、3ヶ月から長くて半年程度で終わると 思っていたが、最終的にまるまる 1年かかった。 ずっとリビルドをやり続けることが大変だったのはもちろん、リビ ルドは完了してリリースして初めて成果として現れるので、周り への申し訳無さもあった。
大変だったこと どうしてもAPIの入出力は変えられない部分が多 いため、合わせる必要がある リビルド対象が限定されていたため、リクエスト・レスポンスデー タは大きく変えることができなかった。 加えて、本来APIでやらなくてもいいはずの処理だったとしても、 場合によってはそのまま APIでやる必要があったりした。
大変だったこと 使われている部分と使われていない部分の選定 使われていない部分は削除することも目的の 1つだったため、 APIの各エンドポイントの使用箇所とそのリクエスト・レスポンス データ、及びレスポンスデータの使いみちをすべて特定し、使わ れていない部分を削除した。
大変だったこと DBへの接続方法やキャッシュシステムの違い リビルド後はDB接続時にコネクションプールを使うようになった り、キャッシュシステムがファイルから Redisになったことで、考慮 すべき点が増えた。
リビルドの効果をより長持ちさせていく には
リビルドの効果をより長持ちさせていくには どんなにきれいに掃除しても、その後住人がまた汚く使っていてはいずれゴミ屋敷に 戻ってしまう。 リビルドも同様で、その時どんなに綺麗に作り直しても、その後考えて開発していかな いと、やがてまた汚いコードに戻ってしまう。 リビルドの効果をより長持ちさせていくには、 - エンジニアが、可読性や変更容易性を意識して開発していく ことが大事
ちゃんと掃除しよう!