Rails 8がついに登場:PaaS不要のデプロイを実現する主要な新機能を徹底解説
Rails 8がついにリリースされ、開発者の世界に大きな波を起こしています。すでにRailsコミュニティで活動している方なら、「No PaaS Required(PaaSはもう不要)」というキャッチフレーズを目にしたことがあるかもしれません。
これは少し珍しい、しかし決して意外ではないミッションです。今回のリリースは、フル機能のプラットフォーム・アズ・ア・サービス(PaaS)に頼ることなく、Railsアプリケーションを簡単にデプロイできるようにすることに焦点が置かれています。
PaaSとは、コードを実行する基盤インフラの管理をせずにアプリをWeb上に公開できるようにする仕組みです。Heroku、Render、Fly.io、Railwayといったサービスは、Railsコミュニティで長年人気の選択肢でした。開発者は、プラットフォームが提供する優れた開発者体験と引き換えに、追加のホスティングコストを払うことに抵抗がないことが多いのですが、Rails 8はその取引の魅力を下げようとしているのです。
本記事では、それを可能にした新機能や改善点を詳しく見ていきます。Solid Cache、Solid Queue、Solid Cableといった新機能により、これまで必要だった依存関係(Redisなど)が取り除かれました。さらに、Kamal 2がデプロイの標準となり、認証ジェネレーターの登場で別途gemを導入する必要性もなくなっています。それでは詳しく見ていきましょう。
Rails 8で何が変わったのか?
Rails(特にRails 8)は、プラットフォームにお金を払わずにアプリケーションを本番環境へ出荷することを、強く支援したいと考えています。今回のリリースにおける変更の大部分は、このミッションを中心に展開されています。つまり、自分でRailsアプリケーションをホスティングする際の手間を減らし、「PaaS不要」を実現することです。
それでは、主要な変更点を一つずつ詳しく確認していきましょう。
Solid Cache:Redisを使わないキャッシング
RailsはActiveSupportを使ってキャッシュを行います。これはWebアプリのパフォーマンスにとって極めて重要な要素です。歴史的には、Redisが高速かつ信頼性に優れていたため、キャッシュ用途でRedisに頼るのが一般的でした。
Solid Cacheは以前から提供されていた、Redisに依存しないActiveSupport用のキャッシュストアです。37signalsなどでしばらく運用実績があり、Rails 8ではデフォルトの選択肢として推奨されるようになりました。RAMの代わりにデータベース(デフォルトではSQLite)をキャッシュストアとして使用するため、通常よりもはるかに多くのデータをキャッシュできるというメリットもあります。データベースのストレージ容量はRAMより安価なため、RAMを使うキャッシュシステムより速度面では劣りますが、より多くのデータをより長期間キャッシュできることで、アプリによってはむしろパフォーマンスが向上するケースもあります。
このパフォーマンスのトレードオフは用途によって向き不向きがありますが、従来どおり他のキャッシュストアを選ぶことも簡単です。RedisやMemcachedがデフォルトで不要になることで、Railsが掲げる「No PaaS Required」のミッションに一歩近づいたのです。
Solid Queue:Redisを使わないバックグラウンドジョブ
ご存知のとおり、RailsはActiveJobライブラリを使用して、バックグラウンドジョブの作成と実行を容易にしています。キャッシングと同様に、RailsではActiveJobのバックエンドを選択できます。SidekiqやGood Jobを愛用している方も多いでしょうが、現在の選択肢の多くには2つの課題があります。
- 導入・管理・場合によっては支払いが必要な、別の依存関係が増える
- ホスティング・管理・支払いが必要な、Redisのような別サービスに依存している
Solid Queueは、Redisに頼らずにバックグラウンドジョブを管理することで、この両方の課題を解決します。SidekiqなどRedisに依存するキュープロバイダーを使っているなら、Solid Queueは複雑さを減らし、ホスティングを容易にする代替手段となります。Solid Cacheと同様に、Solid QueueもRAMではなくアプリケーションのデータベースを使ってバックグラウンドジョブを管理します。依存関係を減らし、本番デプロイをシンプルにするために、Railsがデフォルトで提供するようになった機能の一つです。
Solid Cable:Redisを使わないWebSocket
RailsはAction Cableを通じて、リアルタイム機能のためのWebSocketを開発者が簡単に利用できるようにしています。しかし歴史的に、これにはRedisが必要でした。ここからの展開は、もうお察しでしょう!
「Solid」シリーズのテーマを受け継ぎ、Rails 8にはデータベースバックエンドのアダプターがもうひとつ標準搭載されています。必ずしも使う必要はありませんが、WebSocketを利用したいけれどRedisの設定や保守は避けたいという場合に、非常に優れたファーストパーティ製の選択肢となります。Solid CacheやSolid Queueと組み合わせることで、Redisへの依存を排除してデータベースに集約でき、PaaSなしでのRailsアプリケーション公開がさらに容易になります。
Kamal 2:より簡単なデプロイ
Rails 8のもうひとつの新機能は、Solidシリーズのアダプターとはかなり異なるものです。Kamal(特にKamal 2)は、自前のサーバーでアプリケーションを出荷するプロセスをシンプルにします。Dockerのおかげでソフトウェアのモジュール化が容易になった今、言語を問わずDockerコンテナを出荷できるツールが存在するのは理にかなっています。
個人的な意見としては、KamalはRails 8の他の新機能と組み合わせても、多くのPaaSが提供する開発者体験にはまだ及ばないと感じています。それでも、Railsを使っていない場合でさえ、自分のWebサーバーへソフトウェアをデプロイするのが格段に楽になります。PaaSの完全な代替品にはならないかもしれませんが、初期セットアップさえ完了すれば、kamal deployコマンド一つでデプロイできるのは、手動でのデプロイ作業と比べて大きな進歩です。
認証ジェネレーター(Deviseなしで!)
ユーザーを持つRailsアプリを作るなら、おそらく認証機能が必要になるでしょう。これまでRailsは、認証をフレームワーク本体に含めてきませんでした。コミュニティにはRails開発者向けの優れた認証ソリューションがいくつもあり、中でも最も人気があるのがDeviseです。
Rails 8には認証ジェネレーターが同梱されています。これは完全な認証システムではありませんが、セキュリティなどの重要な部分を正しく実装するための手助けには十分です。ログイン画面やユーザー登録フロー用のビューは開発者が書く必要がありますが、ジェネレーターがセッション管理、パスワード認証、さらにはパスワード関連のメール送信まで処理してくれます。DHH(David Heinemeier Hansson)は、ビューを認証機能に含めなかったのは、Railsアプリが画一的な見た目になるのを防ぐための意図的な判断だと語っています。
この新しいジェネレーターの追加は、アプリの出荷を直接簡素化するものではありませんが、Railsが長らく欠いていた、Webアプリ構築における共通の課題に対するファーストパーティ製ソリューションを提供するものです。
Propshaft:新しいアセットパイプライン
Rails 8における最大級の(内部的な)変更のひとつが、デフォルトのアセットパイプラインをSprocketsからPropshaftへ移行したことです。必要であれば引き続きSprocketsもサポートされますが、新しく作成するRails 8アプリケーションはPropshaftがデフォルトになります。
Propshaftは、アセットのバンドルや圧縮(minify)をあえて行わないという強い思想を持っています。RailsがPaaSを不要にしようとしているのと同じように、複雑なビルドパイプラインも不要にしようとしているのです。Rails 8の他の新しいデフォルトと同様に、Propshaftは古いバージョンのRailsでも使用できますし、逆にRails 8でもSprocketsを使い続けることが可能です。
SQLiteとRails
SQLiteは厳密にはRailsの一部ではありませんが、今回のリリースでRailsはSQLiteをさらに活用するようになりました。SQLiteはサーバーレスのデータベースエンジンであり、Postgresのようなデータベースよりもシンプルです。RailsアプリケーションでSQLiteを使えば、Webプロセスとは別にデータベースプロセスを起動しておく必要がありません。もちろん、これはWebアプリケーションの出荷をシンプルにするというRails 8のミッションに完全に合致しています。
Rails 8はSQLiteのファーストパーティサポートを同梱しており、従来のデータベース要件を十分に処理できるだけでなく、新しいデータベースバックエンドのSolidアダプター群にも対応できるようになっています。
Rails 8の新機能はすべて「プラットフォームの必要性を下げる」ためのもの
既存のRailsアプリをRails 8へアップグレードする場合、作業量はそれほど多くありません。削除された機能はごく一部で、主にActive Record内の、すでに非推奨告知が長期間表示されていたものだけです。もちろん、Rails 8の新しいデフォルト設定をすべて活用してデプロイを簡素化することもできますが、それは任意です。
Rails 8の変更の恩恵を最も大きく受けるのは、なんといっても新規アプリケーションです。新しいRailsアプリでは、バックグラウンドジョブにSolid Queue、キャッシュにSolid Cache、WebSocketにSolid Cable、アセットパイプラインにPropshaft、そしてデプロイにKamal 2がそれぞれデフォルトで採用されます。
Railsは近年、複雑さを圧縮し、モダンなWebアプリを作るためのフル機能フレームワークを提供することに注力してきました。Rails 8は、Webアプリの制作にとどまらず、Webアプリの出荷まで視野に入れながら、既存の選択肢との互換性も維持しています。
Rails 8のデフォルト設定をすべて使っても、一部だけ使っても、まったく使わなくても構いません。開発者体験を重視するなら、引き続きPaaSを利用することも可能です。しかしこのリリースは、プラットフォームをスキップして、インフラをより自分自身で管理するという選択肢を提供することを目指しているのです。
この記事が役に立った方は、Honeybadgerのニュースレターに登録して、RubyとRailsの最新ニュースやチュートリアルをぜひチェックしてみてください。
-
【実践ガイド】AppSignalでRuby on Railsのフィーチャーフラグの効果を測定する方法
フィーチャーフラグ(機能フラグ)は、ソフトウェア開発における強力な手法の一つです。新しいコードをデプロイすることなく、アプリケーションの動作を実行時に切り替えられるため、新機能のテスト、A/Bテスト、段階的なリリースなどに幅広く活用できます。 Ruby on Railsにはフィーチャーフラグを管理するためのツールが多数存在しますが、中でも最も人気が高いのがFlipper gemです。本記事では、Solidusストアフロントを題材に、FlipperとAppSignalのカスタムメトリクスを組み合わせて、フィーチャーフラグを実装し、その影響を測定する手順を詳しく解説します。 おさらい:Railsに
-
Ruby on Rails でポリモーフィズムをマスターする:初心者にもわかる実践ガイド
オブジェクト指向プログラミング(OOP)でアプリケーションを開発したことがあるなら、ポリモーフィズムを実際に使ったことがあるか、少なくともその用語は耳にしたことがあるでしょう。 科学やコンピュータサイエンスの教科書に登場しそうな言葉です。調べてみたことはあっても、概念をきちんと理解しないまま実装してしまった、という経験がある方もいるかもしれません。 この記事では、特にRuby on Railsにおけるポリモーフィズムへの理解を深めていきます。取り上げるトピックは以下の通りです。 現実世界におけるポリモーフィズム OOPにおけるプログラミングのポリモーフィズム Railsアプリケーションに組み