Railsをアップグレードするということ
じゅんてつです。 Rails4更新時にはご報告の記事が書かれていたのにも関わらず、Rails5更新は記事を挙げておりませんでした。今更ながら記事をしたためてみました。ひとえに多忙だったり、Rails4更新のように世間的に宣言して更新をしていなかったからかと思います。
さて、今年はRails6がリリースされたように大きな動きのあったRails界隈ですがいかがお過ごしでしょうか。
Rails4更新のときのように特に大きな告知はしておりませんが、CrowdWorksでは、Rails4.2からRails5.2へのアップグレードに取り組んでいました。Rails6がでたところ今さら感も漂いつつあるかもしれませんが、CrowdWorksはサービス全体がRails5.2で稼働していますことをここにご報告いたします🎉
根幹となるフレームワークを古いまま使い続けることは、洗練された記法が使えなかったり、高速化最適化が進んだモジュールが使えなかったり、周辺gemの対応についていけずに置いていかれるリスクなどが負債となって積み上がっていきます。また、セキュリティの問題が修正されなくなるリスクもあるため長い目でみてユーザーに不利益になり、生きたサービスを開発し続けるためにはフレームワークのアップグレードが不可欠と感じています。
CrowdWorksがやったこと
稼働中のサービスのRailsをアップグレードするということは、単に bundle update するだけでは終わりません。ましてやCrowdWorksのような30万行を超えるサービスの中心となるフレームワークを更新していくことにはいくつもの課題があります。10万行超のRails4更新時は「車を走らせながらエンジンを取り替えるようなもの」と課題の大きさを比喩していたようですが、今回はさらに規模が大きくなっており「旅客機を飛ばしながらエンジンを空中で取り替える〜」と比喩してもいいのではないかと思います。
稼働したサービスを止めずにRailsのアップグレードをするにあたって、Rails4とRails5が並列に存在できる環境を構築しました。これによってHTTPリクエストを振り分け、カナリアリリースの体裁をとることが可能になり、問題が発生した際は即座にRails4へ切り戻しができたり、ユーザー影響を最小限に留めることができ安全に新しいバージョンへ移行することができるようになりました。安全なリリース方法を模索した結果、カナリアリリースを採用しましたが、もちろんリリースに至るまでに多大なる努力を行っています。自動テストの充実や、手動テストでの網羅的な確認、シナリオテストでのパターン網羅、ミドルウェアやインフラ構成に着眼した個別の確認など、思いつくあらゆる軸で対応を行いました。
このような取り組みのお陰で大きな障害を出すこともなくユーザーへの影響も最小で移行しています。 Rails5更新に関する記事は、メインミッションとしたメンバーが少数という事情や、技術的な話は世の中の多くの会社の方が記事にしていただいてるところもありますので、特筆する内容が思い浮かびましたら記事にしたためたいと思います。
