Fantiaで実施したRuby / Ruby on Railsアップデート作業のご紹介

虎の穴ラボでFantiaの開発を担当している Y.K です。

今回はFantiaで実施したRubyとRuby on Rails(以下Railsと表記します)のアップデートについて、どのような手順で実施したかについてご紹介できればと思います。

背景

虎の穴ラボでは言語やライブラリ、各種サービスで利用しているシステム(DBなど)について定期的にアップデートを行いサポート内かつ脆弱性がないバージョンを保つように日々対応を行っています。

今回はFantiaで利用しているRuby / Railsについてそれぞれ以下の期限でEOLを迎えることとなり、それぞれについてアップデートを行っています。

対象	バージョン	EOL
Ruby	3.1.x	2025/03/26
Rails	7.0.x	2025/04/01

今回は社内の実績や各種メンテナンススケジュールを加味したうえで、Rubyを3.3.x、Railsを7.2.xまでアップデートすることを目標として作業を行いました。

実際に行ったこと

全体の流れとしては以下のような手順を踏みました。

事前調査
ローカル環境: Rubyアップデート・検証
ローカル環境: Railsアップデート・検証
テスト環境: Ruby / Railsアップデート・検証
打鍵テスト
リリース
経過観察

事前調査

虎の穴ラボで協賛させていただいているRailsガイド様の「Rails アップグレードガイド」やruby-jp様がScrapboxで公開しているアップデートに関する各種Knowledge、社内の他サービス事例を元に以下のような情報の整理を行いました。

アップデートによって起きるデフォルト挙動の変更
破壊的変更によるFantiaのコードへの影響範囲
Rails以外にアップデートが必要になりそうなライブラリの調査・整理
以前のアップデートで起きたバージョンに由来しないサービス特有の考慮事項

railsguides.jp

scrapbox.io

アップデートによる影響・対応例

Fantiaで実際に対応をしたり影響を受けた変更のうちいくつかをご紹介させていただければと思います。

(Rails7.1)「Rails.cache.redis」で取得されるインスタンスの変更

これまではredis gemのRedisクラスのインスタンスが取得できましたが、アップデート以降はconnection_pool gemのConnectionPoolクラスのインスタンスが取得されるような形に変わりました。

gemのREADMEにあるように取得したインスタンスに対して.withや. thenを叩き、引数としてブロック内で処理をするように変更をするという形で対応を行いました。

github.com

(Rails 7.1)「Enumerable.sum」の挙動変更・「to_s(:format)」の削除

Enumerable.sumの挙動変更
- Active Supportの独自実装から、Rubyで実装されているものを利用されるように
- 数値以外が含まれる配列に対してsumを呼び出すとエラーが出るようになる
「to_s(:format)」の削除
- 数値を3桁区切りの文字列にする場合に利用されていたto_s(:delimited)など
- to_fsやto_formatted_sを利用するように

どちらも既に非推奨化されていたものが削除・変更された形になります。残ってしまっているものが無いか調査と、残ってしまっているものに関して修正を行いました。

(Rails7.2) 「enumの宣言方式」非推奨化

Rails7.2にてenumをキーワード引数で宣言する方式が非推奨化されました。

Rails8.0にて廃止される予定になっているため、今回のアップデートにて対応を合わせて行いました。

以下のようにRails7.0から新しく追加された形式での記述にすべて置き換えました。

# 非推奨化された形式
enum entry_type: { user: 0, system: 1}, _suffix: :entry

# 今後も利用できる形式
enum :entry_type, { user: 0, system: 1}, suffix: :entry

(Rails7.2)「config.active_support.cache_format_version」の一部バージョン廃止

ActiveSupport::Cacheに関する設定で、値を変えるとシリアライズフォーマットが変わります。当時利用していたバージョンが廃止されてしまったため、更新が必要になりました。

この設定は後方互換性のみを持つ設定になっています。そのためバージョンを上げ続ける分には特別な対応をせずに設定の変更ができます。

ただ、例えば「この値の更新を含むリリースで不具合が見つかりロールバックをする」ような状態が発生した場合、この設定を更新した後に生成されたキャッシュはロールバックをすると読めなくなるため様々な部分でアプリが壊れる可能性が高いです。

そのため、今回はアップデート本体のリリースとは別でこの設定変更のみのリリースを行うこととしました。

ローカルアップデート作業

まず、ローカル環境にてバージョンアップ作業を以下のような形で順に実施しました。

Ruby 3.1 -> Ruby 3.2のアップデート・修正作業
Ruby 3.2 -> Ruby 3.3のアップデート・修正作業
Rails 7.0.x -> Rails 7.1.xのアップデート・修正作業
Rails 7.1.x -> Rails 7.2.xのアップデート・修正作業

Fantiaのローカル開発環境はDocker Composeを用いて作成しているためRubyに関してはイメージの変更、Railsに関してはGemfileの変更をして対応しています。

また、各種バージョンアップを実施した場合はそれぞれのバージョンごとに以下の内容を確認しています。

テストコードの実行がすべて成功すること
アプリの起動ができること
アプリを軽く触ってみて壊れないこと
特にアップデートの影響で挙動が変わりそうな部分

バージョンごとにそれぞれ確認を実施した理由としては一度に上げてしまうと「どうしてそうなったか」の原因究明に時間がかかってしまうためで、実際に段階を分けて実施して良かったと感じています。

最終的には打鍵テストを行う予定なので細かい部分の確認まではせず、ある程度動きそうかどうかを観点として動作検証にはそこまで多くの時間を使わないようにしていました。

所感

前から想定していた部分ではありますが、一番時間がかかったのは対象以外の使用ライブラリや関連ライブラリのアップデートになります。

事前段階で確認できていないものもいくつかあり、それぞれについてCHANGELOGや既存の実装などを確認したうえでアップデートをしていきました。
今回のこの作業については人力である程度済ませてしまったのですが、こういった作業についてはもっとAIを活用して効率化をしたほうが良かったかなと感じており、これは個人的な今後の課題です。

また、今回の作業をする中でFantia全体の課題として『非推奨項目をまとめて管理・確認できる仕組みがない』という点に気づきました。そこで、作業中に発生した非推奨項目をまとめて確認できるような仕組みづくりを行いました。

その後の打鍵テスト工程では、今回作成した仕組みを使い非推奨項目の修正漏れなどを適宜確認しました。この確認作業を通じて、仕組みの有効性を実感でき作って良かったと思っています。

社内のエンジニアに対してもアナウンスを行っているので、次のアップデート(Rails8.0.xなど)に向けて日々非推奨項目への対応が進んでいけば良いなと思っています。

テスト環境アップデート作業

ローカルでの作業が終わった段階でFantiaにあるいくつかのテスト環境のうち1つを占有しアップデートの適用と動作検証に取り組みました。

Fantiaの開発に関して、Fantiaのプロジェクト本体以外との連携などローカル環境では動作確認が困難な機能もあるためそういった部分についてとりあえず動きそうかの確認をしました。

今回の場合はデプロイの時点でエラーが発生してかなり焦った記憶があります。起きた事象としては、ローカルでは問題なく動いたgemについてテスト環境側ではインストールが失敗するというもので、現状のFantia開発環境はローカルとテスト環境でOSが完全に一致しているわけではないのでネイティブgemを利用している部分で問題が発生していました。今回の対応内では時間を取れなかったのですが、タイミングを見てローカルとテスト環境でOSを一致させるようにしようかと考えています。

打鍵テスト

テスト環境でアプリがある程度動きそうなことを確認した段階で、Fantiaのほぼ全機能について打鍵テストを実施しました。Railsアップデートによる挙動の変更についてコード上で追い切るのが難しい部分についてはこの打鍵テストで問題ないことを担保しています。

Fantiaは長く運用しているサービスということもありテストケースの数も膨大なため、同じチームのメンバーやディレクター、運用チームの皆さんなど様々なメンバーに手伝っていただきました。

テストにて発覚した問題にはテスト環境の設定やseedsの不足など、環境由来のものもあったためテスト環境の改善や整備をする良いタイミングにもなったかなと思っています。

リリース

今回のアップデート対応では以下の2回に分けてリリースを行いました。

どちらのリリースもアップデート関連以外の変更は混ぜずに単体のリリースとし、日々のアクセス状況から比較的利用される方の少ない早朝に行いました

事前調査の項目にて記載した「config.active_support.cache_format_version」の更新
アップデート本体のリリース

それぞれのリリースは1週間程度間隔をあけています。

システム内で利用している各種ライブラリやアップデートによる挙動の変更など、影響範囲の大きいリリースなため不具合がゼロだったわけではありませんが、サービスそのものが動かなくなるといったような自体にはならなかったので安心しています。

Fantiaで起きたアップデートによる問題のご紹介

今回ご紹介する事象の原因となったのは、Rails7.1で挙動が変更されたconfig.active_record.run_after_transaction_callbacks_in_order_definedという設定になります。

これはModelで定義するafter_commitの実行順序に関して、以下のどちらの挙動とするかを設定することができます。

定義された順序に対して下から実行する(旧デフォルト)
定義された順序に対して上から実行する(Rails7.1以降デフォルト)

追加された経緯が「他のコールバックと挙動を揃える(after_commit以外は定義された順に実行されている)」というものであるため、検証して問題がなければ新しい挙動にするという方針で対応を行いました。テスト環境では問題が発生しなかったため方針通りにリリースを行いましたが、結果として本番リリース後に一部の機能で問題が確認される自体となりました・・・・。

発生した問題の原因は「after_commitで非同期処理をenqueueしている箇所があり、その非同期処理と同タイミングで動いてはいけないafter_commitの処理が存在した」というものになります。

これまでは「after_commitの処理(最後の方に非同期処理のenqueue) -> 非同期で動く処理」という形で動いていたのですが、after_commitの順序が変わったことによりenqueueのタイミングが早まり状況によってはほぼ同タイミングで動くような状態が生まれてしまっていました。

after_commitの処理が終わった後に非同期処理が実行されるような状況が作れれば良いので、今回はenqueueしてから実行されるまでに遅延をつけることで対応をしています。

また、関連コードについては分かりづらくなってしまっている部分もあるため既存実装について見直しを進行中です！

経過観察

リリース後数日はモニタリングによる各種リソースの使用率やエラー数などの確認について高頻度で確認をするようにしていました。

懸念点として想定外の不具合以外に、YJITを有効化したことによるメモリ使用量の増加がありましたが、もともと余裕のある構成にしていたためリリース後も問題はなさそうでした。

ちなみにFantiaでYJITを有効化したことによるレイテンシへの影響についてですが、1ヶ月くらいの期間で比較してみたところ50 パーセンタイルで8.8%減でした。

99 パーセンタイルなどでは有意な数値が出なかったのですが、これは現状のFantiaにおけるレイテンシについてSQLの実行時間などが占める割合が大きいためと予想しています。

※ パーセンタイル: データを昇順に並べた際に、特定の割合のデータが収まる境界値を示す指標です。50パーセンタイルは下から見て50%の位置に存在する値(= 中央値)を示しています。

アップデートの際に注意したこと

アップデートの作業自体ももちろん注意して行っていたのですが、それ以外に「社内への情報共有」や「他メンバーが早めに新バージョンを触れるようにする」ことは特に意識していました。

Fantiaの開発に携わっている人数は現状それなりにおり、アップデートの作業中もどんどん様々な開発が進んでいく状態です。

そのため把握している破壊的変更に起因して「開発中の内容が突然動作しなくなる」事態を避けるべく、以下のようにSlack上で適宜情報を共有し、注意喚起を行っていました。

また早めに新環境でのテストをできるようにするため、打鍵テストがある程度終わった段階でテスト環境は1台を除いて最新のアップデート後の状態にしました。その後、状況の連携と開発中の機能について動作確認の依頼を行っていました。

これまでに公開したFantia業務に関する記事のご紹介

Fantiaの新規機能開発については以下でご紹介しています。 toranoana-lab.hatenablog.com

また、「Fantiaチームの改善」についての取り組みは以下でご紹介しています。 toranoana-lab.hatenablog.com

それぞれFantiaの開発チームが日々どのように業務に取り組んでいるかがわかるような記事になっています。ぜひご覧いただければと思います。

まとめ

この記事では「Fantiaで実施したRuby / Ruby on Railsアップデート作業」についてご紹介させていただきました。

Fantiaでは新規機能や既存開発の開発だけではなく、言語やライブラリのバージョンアップに関しても開発エンジニアが行っています。

こういったアップデート作業は言語やライブラリの細かな仕様や担当しているシステムそのものへの理解が深まるため、今後のFantiaでの開発やエンジニアとしてのキャリアを考えた際に貴重な経験を得ることができていると感じています。

虎の穴ラボでの開発に興味がある方はぜひ下記採用情報をご覧ください。また、カジュアル面談も実施しておりますので興味がある方はそちらもご利用いただければと思います！

Fantia開発採用情報

虎の穴ラボでは現在、一緒にFantiaを開発していく仲間を積極募集中です！
多くのユーザーに使っていただけるtoCサービスの開発をやってみたい方は、ぜひ弊社の採用情報をご覧ください。
toranoana-lab.co.jp

虎の穴ラボ技術ブログ

虎の穴ラボ株式会社所属のエンジニアが書く技術ブログです