UZUMAKI TechBlog
UZUMAKI TechBlog
Ruby2.7, Rails6.0 のサポート終了間近！サポートが切れるとどういう不利益があるか

Ruby2.7, Rails6.0 のサポート終了間近！サポートが切れるとどういう不利益があるか

概要

ソフトウェアのサポート終了期限(以下EOL)とはなにか？EOLを迎えると何が起こるのか？

実際の開発現場においてどのようが不利益があるのか？

RubyとRailsのアップグレードの仕事をいくつも経験のある株式会社UZUMAKIが、RubyとRailsのEOLを元に考えていきます。

目次

目的

ソフトウェアのバージョンアップを何のためにするのか理解する

対象読者

エンジニアからソフトウェアのアップデート作業の工数を取ることを求められるプロダクトオーナーなど意思決定者

スケジュールや決済券を持つ人にソフトウェアノップデート工数を獲得したいエンジニア

PR

UZUMAKIではアジャイル開発で新規事業の開発から、大規模Webアプリケーションのアーキテクチャ更新などの開発をしています。

お問い合わせはUZUMAKIのHPのお問合せフォームから

EOLとは

EOLとは End Of Life の略で製品の更新を意味します。ソフトウェアのサポートが終了し、新たに発見されたセキュリティの問題が修正されません。商用のソフトウェアの場合、問い合わせにも対応されません。

RubyとRailsの直近のEOLスケジュール

まずはUZUMAKI社がクライアント各位から頼まれるRubyやRailsのアップグレード案件でも説明に使う直近のEOLスケジュールを共有します。

Ruby 2系 3系の2023年までにEOLを迎えるバージョン

  • Ruby2.6のEOL
    • 2022/03/31
  • Ruby2.7のEOL
    • 2023/3/31
  • Ruby3.0のEOL
    • 2024/03/31

Rails5, 6の2023年までにEOLを迎えるバージョン

  • Rails5.2のEOL
    • 2022/6/1
  • Rails6.0のEOL
    • 2023/6/1
  • Rails6.1のEOL
    • 2023/03現在 明記なし

Railsアップグレード用語の整理

RailsのアップグレードとはRailsのフレームワークのバージョンを上げることを指します。

Railsのバージョンをどのレベルで上げるか小数点単位で上げるのか整数単位で上げるのかによって名前が違います。

  • メジャーアップグレード
    • 5系から6系に上げるなど、Railsのバージョン番号の整数の位を上げること
  • マイナーアップグレード
    • 6.0から6.1に上げるなどRailsのバージョン番号の少数第一位を上げること
  • パッチアップグレード
    • 6.0.0から6.0.2に上げるなどRailsのバージョン番号の少数第二位(正確には2つ目のドット以下)を上げること
    • パッチはバグ修正のみが含まれ、public API変更はない

RubyとRailsのバージョン番号に対する意味合いはほぼ同じです。

0.1単位のバージョン変更でも使われないメソッドや非推奨のメソッドなどがあるので大雑把に「0.1上げるだけだからテストもしないでいいや」というわけには行かないのでご注意ください。 0.0.1単位のパッチであればprivateなメソッドを直接呼ぶなどトリッキーなことをしていない限りは問題ないでしょう。

Ruby x Railsの制約条件

2023年もサポート対称内のバージョンでサービスを維持するにはRuby3.0とRails6.1の組み合わせまではアップグレードが必要です。

制約条件を書き出すと以下の通り

  • Ruby2.7のサポートは2023/3/31まで
    • ただしRuby3.0のサポートは2024/3/31までなのでRuby3.1以上へのアップグレードも見据える必要あり
  • Rails5系でサポートしているRubyの最大のバージョンは2.6以下
  • Rails6系でサポートしているRubyの一番古いバージョンは2.5以上

Rails5.2-Ruby2.6の組み合わせのサービスを例にとって図にするとこのようになります

image
‣
Mermaidで作図したソース
flowchart TD
Rails5.2-Ruby2.6 --Ruby2.6のサポート切れかつ2022/06/01にRails5.2サポート切れ
--Rails5.2はRuby2.6まで --> Rails5.2-Ruby2.7は不可 -- Ruby2.7に対応するRails6.0へのアップグレードが必要--> Rails6.0-Ruby2.6 -- RubyとRailsを同時にあげない
--> Rails6.0-Ruby2.7-2022/11現在ギリギリ
--2023/03/31にRuby2.7サポート切れ --> Rails6.0-Ruby3.0
--2023/06/01にRails6.0はサポート切れ --> Rails6.1-Ruby3.0-2022/11現在ここまで持ってくると安心
 --> Rails6.1-Ruby3.1
--Rails7へ-->Rails7.0-Ruby3.1

flowchart TD
Rails5.2-Ruby2.6 --Ruby2.6のサポート切れかつ2022/06/01にRails5.2サポート切れ
--Rails5.2はRuby2.6まで --> Rails5.2-Ruby2.7は不可 -- Ruby2.7に対応するRails6.0へのアップグレードが必要--> Rails6.0-Ruby2.6 -- RubyとRailsを同時にあげない
--> Rails6.0-Ruby2.7-2022/11現在ギリギリ
--2023/03/31にRuby2.7サポート切れ --> Rails6.0-Ruby3.0
--2023/06/01にRails6.0はサポート切れ --> Rails6.1-Ruby3.0-2022/11現在ここまで持ってくると安心
 --> Rails6.1-Ruby3.1
--Rails7へ-->Rails7.0-Ruby3.1

※ 補足 RailsアップグレードのTips

  • Railsのアップグレードは1つずつ上げるのが定番
    • 現状のRailsのバージョンのパッチアップグレードする
    • Railsのマイナーアップグレードする
    • Railsのメジャーアップグレード
  • マイナーアップグレードもするべきなので、6.0, 6.1と刻むべき
    • Railsのバージョンを変更する場合、マイナーバージョンを1つずつゆっくりと上げながら、その都度表示される非推奨機能の警告メッセージを上手に利用するのがベストです。

    Railsガイドアップグレード手順より

ソフトウェアがEOLを迎えるとどうなるか？

不具合のアップデートがされなくなる

EOLを過ぎると新たなバグや脆弱性が発見されても改修が行われないため、自社(自分)でセキュリティ面の強化や運用対処などの回避策を取る必要があります。しかしこれは現実的ではありません。最初の一つの脆弱性の対応のパッチを当てることはできるかも知れませんがそれが2つ3つと増えてきたときに整合性を保つことは難しいです。技術的に高度なことをするため運用の負荷が増したり、属人化の原因になったりします。

セキュリティリスクが発生する

新たな脆弱性が発覚しても修正が行われないため、セキュリティリスクを抱えた状態で運用することになります。これはOSやアプライアンスの場合は特に重大な脆弱性が発見された場合、無差別に攻撃されると、EOLを迎えたものを使い続けていると攻撃を受けるリスクが高まります。

EOLについてRailsの場合どう説明されているか

3 セキュリティ問題
現在のリリースシリーズ、および１つ前のリリースシリーズには、セキュリティ問題発生時にパッチや新バージョンが提供されます。
これらのリリースは、直近にリリースされたバージョンにセキュリティパッチを適用してリリースされます。続いて、それらのパッチはx-y-stable（安定版）ブランチの最後に適用されます。たとえば、1.2.3というセキュリティリリースは、理論上1.2.2を元にビルドされ、1-2-stableの最後に追加されます。つまり、最新のRailsを利用していればセキュリティリリースへのアップグレードを容易に行えます。
セキュリティリリースには、直接的なセキュリティパッチ（修正プログラム）のみが含まれます。セキュリティパッチが原因で発生したセキュリティと無関係なバグの修正は、リリースのx-y-stableブランチで公開され、バグ修正ポリシーに基づいて新しいgemとしてのみリリースされます。
現在対象となっているシリーズ: 7.0.Z、6.1.Z。

4 重大なセキュリティ問題 重大なセキュリティ問題については、最新のメジャーなシリーズにおけるすべてのリリースと、前回のメジャーなシリーズの最新リリースに対してセキュリティパッチと新バージョンを提供します。セキュリティ問題の重大性の判定はコアチームによって行われます。
Rails 5.2.Zがサポート対象シリーズのリストに含まれるのは、2022年6月1日までです。
Rails 6.0.Zがサポート対象シリーズのリストに含まれるのは、2023年6月1日までです。
現在対象となっているシリーズ: 7.0.Z、6.1.Z、6.0.Z、5.2.Z。
5 サポート対象外となるリリースシリーズ あるリリースシリーズがサポート対象外になった場合、バグ修正とセキュリティ問題の対応は各自の責任となります。場合によっては修正のバックポートの提供とgitへの公開が行われる可能性もありますが、新バージョンがリリースされることはありません。アプリケーションで使われているバージョンのメンテナンスが難しい場合は、サポート対象のバージョンにアップグレードしてください。

まとめ、EOLを放置しアップグレードしないと発生する具体的な不利益はなにか？

以上のことからまとめると、EOLを放置したシステムのままでいると下記のような不利益を被ります。

  • 脆弱性を放置してセキュリティリスクを高める
    • これが現場では一番多いのではないでしょうか？アプリケーションのセキュリティの問題も、それを動かしているクラウドサービスで防いでいるので問題が顕在化しない場合もあり気づきにくです。基本的にはセキュリティは二重三重にしておくべきでしょう。
  • 脆弱性への対応するための修正を自分でやらないといけない
    • セキリティパッチを自前で行うこと、このようなタスクをデキる人が少ないので属人化してしまうリスクが高いです。人材の流動が激しいソフトウェア業界の場合、常に変えが効くようにできるだけベストプラクティスを意識したほうが良いです
  • ライブラリの依存関係を解決できなくなる
    • 基本的にOSSのライブラリを組み合わせてシステム構築します。一つ一つのライブラリ内でも別のライブラリを依存関係として利用していることもあります。そのライブラリのどこかに不具合があった場合に修正されるのはよっぽどメジャーなものでない限りは最新版にのみ反映されます。バージョンを上げられない場合はセキュリティパッチを自分ので当てるのと同様にフォークしてパッチを当てる必要が出て来てしまいます
    • OmniAuthの依存関係の例だと
  • エンジニア採用で困る
    • これが一番わかりやすく不利益を生むのではないでしょうか？古いシステムのメンテするのに飽きて転職するケースも多く、ソフトウェアのアップデートを訴えても拒否も認められない経験をしてきているはずです。そんなエンジニアがサポートの切れているソフトウェアを使っている会社に転職したいでしょうか？
  • ソフトウェアのパフォーマンスをあげられない
    • ソフトウェアは日々改善されていきます、ただしその改善は最新のものだけがその恩恵を受けることができます。
    • 例えばサーバ一台あたり100件/秒のリクエストをさばけるアプリケーションサーバが125件　/秒さばけるようになれば、1000件/秒のサービスの場合サーバの台数は10台から8台へとインフラコストを下げる事ができます

参考リンク

PR

XではUZUMAKIの新しい働き方や日常の様子を紹介！ぜひフォローをお願いします！

noteではUZUMAKIのメンバー・クライアントインタビュー、福利厚生を紹介！

UZUMAKIではRailsエンジニアを絶賛募集中です。

↓の記事を読んでご興味を持っていただいた方は、ぜひ応募よろしくお願いします！

是非応募宜しくおねがいします！