記事

なぜ、アンドパッドは最新のRuby/Railsにこだわるのか？アップデートを止めないための体制と仕組み

公開日 2023年10月23日

カテゴリーコラム

株式会社アンドパッドの白土慧と申します。OSSなどではkei-sで活動しています。アンドパッドではリアーキテクティングチームに所属し、チームの立ち上げから携わっています。

リアーキテクティングチームの活動を簡単に紹介すると、アンドパッドにある大規模なRailsアプリケーションを、コードや構造も含めて、もっと拡張しやすくて、開発者が使いやすく、ミスの防止などもできるようにする活動をしています。今回のRuby/Railsのアップデートも取りまとめているほか、チームのスコープにはマイクロサービスやモジュラーモノリスなどへの移行の検討も含まれます。

アンドパッドでのRailsの役割

アンドパッドにある大規模なRailsアプリケーションをもう少し掘り下げます。

このアプリケーションは「ANDPAD施工管理」や「ANDPAD黒板」、「ANDPAD検査」などのアプリ向けのAPIサーバーであり、ブラウザレスポンスも返しています。他の製品ではGoも使って開発していますが、アンドパッドではこのRailsアプリケーションが最も歴史があります。それだけに大規模で、モデルだけで20万行はあります。私の開発経験上でも一番の規模です。この中で、コード品質を上げる取り組みとして、例えばRuboCopを使った検査や写真といったデータの持ち方などを整理しています。

アンドパッドがRuby/Railsを最新に保つ理由

では、本題に入りましょう。

まず現在のバージョンを申し上げると、Railsは、ほぼ最新の7.0系で、さらに近々アップデート予定です。一方でRubyはつい先週に最新の3.2.2にアップデートしたばかりです（2023年10月執筆時点）。そして、アンドパッドでは「最新に追従すること="しょっちゅう"アップデートすること」*を方針としています。その理由をこれから紹介します。

大きなジャンプの歴史

読者の皆さまには、これだけの規模だと影響範囲が広く、アップデートしにくいことを察していただけるのではないかと思います。ご多分に漏れず、アンドパッドでもアップデートが停滞し、過去にはジャンプが発生していました。

私が入社後に行われたものでは、2022年末から2023年1月にかけてのRubyのバージョンを2.7系から3.0へとアップデートしたことがそれに当たります。そのときは今のリアーキテクティングチームのような専門チームはなく、私のほか数名とSREの有志のチームで行ったため、通常業務とアップデート業務の両方をこなす必要があり、非常に負荷が高い状況になりました。また、本来のアップデート作業以外にも、各製品開発チームすべてが行う動作確認とその確認結果の集約に、とりわけ多くの工数がかかりました。

このようにジャンプが発生すると、どうしても工数が膨らみ、各製品チームのロードマップやマイルストーンにも影響を与えます。これはRubyに限らず、Railsでも発生し、誰もが苦労をしていました。

アップデートを止めることは「後退する」と同じ意味

アップデートはいつかはやらないといけません。放っておいても楽になることはなく、スキップすればするほど、後回しにすればするほど、どんどん作業が膨らむだけです。アンドパッドはこれまでのジャンプでそれを痛感しました。フルタイムRubyコミッターとしてアンドパッドに入社したhsbtからも、「世の中のほうが進んでいるので、止まる=後退すると同義である。前に進んでようやく留まっている」というアドバイスもあり、先ほど挙げた「"しょっちゅう"アップデートする」方針に変更しました。小さくアップデートすれば、影響範囲も限定的になり、工数も抑えられます。

ANDPADユーザーにもいい影響がある

"しょっちゅう"アップデートする方針に変更することには、ANDPADユーザーにもメリットがあります。特にRuby3系は3×3構想の通り、レスポンス速度が上がっており、タフな建築・建設現場でのユーザー体験の向上に寄与し、ポジティブな影響を与えられます。話題のYJITもスイッチONで動くことはわかっていますので、これも視野に入れています。もしアップデートが停滞した場合、脆弱性があったとしてもすぐに直せない可能性があり、ANDPADユーザーはもちろん、ビジネスとしてもリスクでしかありません。ANDPADは17万社44万人ものユーザーの毎日の業務を支える大規模SaaSだからこそ、安心して使える環境を用意しなくてはならないため、常に最新にアップデートすることにより、セキュリティも担保しやすくなります。

関連して、一般的には、アップデートのような内部品質の向上よりも、外部品質（例えば、ビジネスサイドや経営陣からの新機能開発の要求など）の向上が優先されがちです。しかし、アンドパッドが内部品質向上を専門とするリアーキテクティングチームを組んだことそのものが、ビジネスサイド・経営陣の理解がある証拠であり、また内部品質に投資するだけの体力・体制があるとも言えます。

アップデート体制と進め方の工夫

では、実際にどのようにアップデートを進めているのか、詳しく紹介します。

リアーキテクティングチームが中心

先ほど触れたRuby2.7→3.0へのアップデートでの教訓から、リアーキテクティングチームが進める体制となりました。ただし、他のチームに「アップデートはリアーキテクティングチームの仕事だから、やらなくていいや」と認識されることは本意ではなく、エンジニア全体でやることが理想です。現在はその過渡期にあり、リアーキテクティングチームがその環境整備を進めている段階です。

リアーキテクティングチーム主導になったことで、チームはアップデートに集中できるようになり、前回のような高い負荷はありません。また、ジャンプではなく、小さなアップデートにフォーカスしたことで、影響範囲を絞り込めて、自動テストでエラー検知がしやすく、安心してアップデートを進められました。そのほかhsbtからアップデートで影響がありそうな変更やYJITの話、注意点のアドバイスをもらえ、見通しがつけやすくなりました。ただ実際hsbtに手を動かしてもらう場面はなく、アップデート作業そのものはチームですべて完結できました。

数週間に及ぶmainブランチを使った開発検証でアップデートを検証

自動テストでアップデートによる非互換が検知されるとはいえ、エッジケースでの分岐や込み入った実データなど、手で触ってみることで自動テストではカバーできない部分の非互換が見つかることも考えられます。このため引き続き、各製品チームの動作確認が必要であり、工数がかかることが予想されました。また、一定期間だけ特定の開発環境を用意→動作確認→OK→マージと進んでも、その期間に新たに追加された機能の動作確認漏れが発生し、エラーが起きる可能性が高まります。

そこで社内検証環境の中に、プロダクションと同じmainブランチが動いているものがあり、それを最新のRubyバージョンにして何週間も動かす、ということに取り組みました。日々のプルリクエストなどによる開発の動作確認もその環境で行っているので、何週間にも及ぶ検証の結果、アップデートしても問題がないことがわかりました。この取り組みにより、動作確認の工数が膨らむこともなく、大きなエラーも発生しませんでした。

これにはRuby2.7→3.0で取り組んだCI/CD環境などの知見がそのまま活きています。詳しくはアンドパッドのテックブログで紹介していますので、ぜひご覧ください。

複数チームが開発するモノリシックなサービスにおける、Rubyのバージョンアッププロジェクトの進め方とこのプロジェクトから学んだこと - ANDPAD Tech Blog

これからはRuby/Railsアップストリームへのコントリビュートが視野

最後に今後の展望です。

今回のRuby3.2.2のアップデートにより、最新の環境になりました。これでhsbtたちRubyコアチームが毎日開発している最新バージョンを取り込み、実験できるようになりました。Nightly Buildを取り込み、テストを動かせば、すぐに問題箇所がわかり、アップストリームへのフィードバックも即座にできます。アンドパッドだけでなくRubyコミュニティにもメリットをもたらせるようになりました。こういうことができるのがフルタイムRubyコミッターを抱える強みの一つです。また、リアーキテクティングにはRailsチームのメンバーにも関わってもらっているので、Railsでも同様のことができます。

今後はBuilding GitHub with Ruby and Rails - The GitHub BlogでGitHubが発表したように、アンドパッドはRubyやRailsの改善に積極的に貢献し、ANDPADユーザーの体験向上に還元したいと考えています。

編集：中薗昴

提供：株式会社Haul

著者: 白土慧 (Shiratsuchi Kei) GitHub: kei-s

ソフトウェアエンジニア。好きな言語はRubyとRust。好きな小説家は舞城王太郎。現在はアンドパッドでRailsアプリケーションの大規模リファクタリングに携わっている。過去にはKaigi on Rails 2022「実践 Rails アソシエーションリファクタリング」などで登壇している。