Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
メインAPIのRailsバージョンを4.2から6.0に上げた話
Keisuke
July 05, 2021
0
310
メインAPIのRailsバージョンを4.2から6.0に上げた話
Keisuke
July 05, 2021
Tweet
Share
More Decks by Keisuke
See All by Keisuke
メインAPIのRailsバージョンを4.2→6.0に上げた話
keisuke1222
0
570
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
38
7.7k
How to Ace a Technical Interview
jacobian
270
21k
4 Signs Your Business is Dying
shpigford
171
20k
BBQ
matthewcrist
75
8.1k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
175
9.1k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
214
12k
Clear Off the Table
cherdarchuk
79
290k
No one is an island. Learnings from fostering a developers community.
thoeni
12
1.5k
How GitHub Uses GitHub to Build GitHub
holman
465
280k
Rails Girls Zürich Keynote
gr2m
87
12k
The Cult of Friendly URLs
andyhume
69
5.1k
For a Future-Friendly Web
brad_frost
166
7.8k
Transcript
メインAPIのRailsバージョンを4.2→6.0に上げた話 〜バージョンアップは計画的に〜 スペースマーケット 技術部 バックエンドチーム 鈴木 景介
2 自己紹介 鈴木 景介 (すずき けいすけ) 経歴: 公務員 → フリーター → 2019年1月ス
ペースマーケットにバックエンドエンジニ アとしてジョイン (最近はインフラも少し) 趣味: 読書、筋トレ、サウナ
3 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
4 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
5 2018年11月以前のAPI構成 長らくAPI側は単一のアプリケーションで構成されていた
6 2021年6月時点のAPI構成 現在ではAPI側は主に3サービスに分割されている
7 2021年6月時点のAPI構成 スペースマーケットのサービス分割粒度の考え方については 前回ミートアップの資料(タイトル:「マイクロサービスの取り組 み」)をご参照ください!
8 2021年6月時点のAPI構成 現在ではAPI側は主に3サービスに分割されている
9 2021年6月時点のAPI構成 現在ではAPI側は主に3サービスに分割されている 今回話すのはここ! Rails6 Rails4
10 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
11 メインAPIのRailsバージョンを4.2 → 6.0に上げました Rails バージョン一覧 4.0 → 4.1
→ 4.2 ↓ 5.0 → 5.1 → 5.2 ↓ 6.0 → 6.1
12 • Rails 6 に上げるために必要な Syntax的変更(一部) ◦ modelのuniqueness に case_sensitive
追加 ◦ ActiveRecord::AttributeMethod::Dirtyのメソッド名変更への対応 ▪ attribute_changed? → saved_change_to_attribute? ▪ attribute_was → attribute_before_last_save • マルチDB接続方法を変更 ◦ octopus -> Rails 6 標準のマルチDB接続へ • 技術的負債の返済 ◦ SQLiteに残っていたデータを MySQLに移行 ◦ 古いgemのバージョンアップ メインAPIのRailsバージョンを4.2 →6.0に上げました 主な対応内容
13 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
14 セキュリティリスクへの対応
15 セキュリティリスクへの対応 • Rails のメンテナンスポリシーは、新機能 (New feature)、バグ修正 (bug fixes)、セキュリティ問題 (security
issues)、重大なセキュリティ問題 (severe security issue) の4つに分割されている • 上記の4つのうち、Rails4.2は「セキュリティ問題」と「重大なセキュリティ問 題」のサポートが切れていた ◦ Rails自体にセキュリティ問題が発覚しても自力で修正する必要があると いう状態だった😨
16 開発効率の向上
17 • Enumerableモジュールに#pluck, #withoutが追加 • ActiveRecordの#saveにtouchオプションが追加 ◦ touch: falseとすることでタイムスタンプを更新しないようにできる •
ActiveRecord::Relation#in_batchesメソッドが追加 開発効率の向上 Rails5から使えるようになった機能、メソッド
18 • 並列テスト • 複数DB接続 • DBへのバルクインサートの標準サポート • ActiveRecord:Relation#pick 開発効率の向上
Rails6から使えるようになった機能、メソッド
19 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
20 基本方針
21 基本方針 • Railsのバージョンは4.2 → 6.0まで上げる ◦ 本来なら4.2 → 5.0、5.0
→ 5.2、5.2 → 6.0と段階的に上げるのがよ かったのかもしれないが、以下の理由から一気に上げることとした ▪ 他APIですでに4系から6系に上げた実績があったため • Rails 4 → 5 は大変であるが、5 → 6は楽にあげることができ た ▪ 同じ工程(修正→テスト→リリース)を3度行うより工数が少なく済み そうなため • 事前に影響範囲を減らすために断捨離しておく
22 ドキュメントと他社事例を読み込み
23 ドキュメントと他社事例を読み込み • 公式ドキュメント ◦ Rails アップグレードガイド ◦ リリースノート ▪
4.2 → 5.0 ▪ 5.0 → 5.1 ▪ 5.1 → 5.2 ▪ 5.2 → 6.0 • 他社事例をいくつか参照
24 ローカルで動作できるところまで持っていく
25 ローカル環境で動作するところまでもっていく • 公式推奨の方法でとりあえずやってみた • rails serverが動くようにした • rails consoleが動くようにした
26 落ちまくるテストをひたすら修正
27 落ちまくるテストをひたすら修正 • 500件ぐらいRspecのテストが落ちてた • 前半はSyntax的な一つの修正を横展開するだけで数十件ずつ減らせたが、 後半は1件あたりの対応時間が増えていった ◦ テストコードを直すべきか、実装を直すべきか ▪
仕様的に正しい挙動とは? ▪ そもそもこの機能は生きてるのか? • 最終的にテストをオールグリーンにするのに1ヶ月以上かかった
28 打鍵テスト confidential
29 打鍵テスト • sandbox環境で打鍵テスト ◦ 基本的には単体テスト(Rspec)を行なっているため、打鍵テストでは外部 システムとの接続部分を重点的にテスト • サイトの表示部分以外の機能のテスト ◦
バッチ処理 ◦ 通知系処理 ▪ メール送信 ▪ プッシュ送信
30 ようやくリリースへ confidential
31 リリース • 新環境用のターゲットグループを作成し、Rails 6環境で構築したEC2 インス タンスをアタッチ • ロードバランサー(ALB)レベルで Blue/Green
デプロイを行った 徐々に割合を上げていく 90% 10%
32 アジェンダ • スペースマーケットのAPI構成について • 何をやったか • なぜやったか • どうやったか
• ふりかえり
33 大変だったこと
34 • Rails 4系から6系に上げたので、エラー原因のあたりが付けづらかった ◦ Rubyやgemのバージョンアップも一緒にやったのでさらに調査時間が増えてしまった • バージョンアップは計画的に ◦ 「やらないことのリスク」を明確にする
◦ 高優先度のタスクとして枠をとってしまう 大変だったこと 一気にいろいろ上げすぎた
35 大変だったこと • DatabaseSelectorを利用した ◦ HTTPリクエストがGET/HEADの場合はreadingロールを使う ◦ GET/HEAD以外の場合はwritingロールを使う • controllerのshowメソッド(GET)内にwrite処理が含まれている場合に
ReadOnlyエラーが発生して しまう ◦ 該当箇所を全てActiveRecord::Base.connected_to(role: :writing) do ~ end ブロックで囲む 必要があった マルチDB接続におけるread処理とwrite処理の適切な振り分け
36 まとめ • メインAPIのRailsのバージョンを4.2から6.0に上げた ◦ セキュリティリスクの低減 ◦ 開発効率の向上 ◦ Railsのメジャーバージョンを2つ上げるのは大変だった
• 事前の断捨離のおかげで影響範囲を縮小でき、結果的に技術的負債を返済 しつつ、トータルの工数を減らすことができた • バージョンアップは計画的に…😇
ご清聴ありがとうございました!