「PaaS を使用しない」アプローチは Rails 開発者にとって賢明な選択ですか?

Rails 8 は、「PaaS は必要ない」という大胆な前提のもとに出荷されました。クラウド プラットフォームのコストが上昇するにつれて、Ruby on Rails は外部インフラストラクチャの依存関係を削減することに移行し、開発者がこれまでよりも少ないサービス依存関係でアプリケーションをデプロイおよび実行できるようにしました。

従来、Rails アプリをインターネットにデプロイするには、データベース サーバー (PostgreSQL など) と、キャッシュ、バックグラウンド ジョブ、WebSocket 用の Redis などの追加サービスをプロビジョニングする必要がありました。 Rails 8 では、コア チームは、アプリケーションのデータベースを利用したキャッシュ、ジョブ キュー、リアルタイム WebSocket のソリューションを組み込むことで、この状況を変えたいと考えています。

この記事では、「Solid Trifecta」の概要から始めて、Rails 8 が「PaaS 不要」という約束をどのように実現しているかを探っていきます。

Solid Cache を使用すると、Redis を使用せずにキャッシュを実行できます

Rails 8 で追加された私のお気に入りの 1 つはソリッド キャッシュです。 、 Redis や Memcached の必要性を置き換える新しいキャッシュ ストアです。 。 Solid Cache は、メモリ内のキー/値ストアの代わりにデータベースを使用して、キャッシュされたデータを永続化します。キャッシュされたオブジェクトをディスクに保存するのは技術的には RAM よりも遅いですが、いくつかの大きな利点があります。

まず、ディスク ストレージはより多くのスペースを提供し、メモリよりもはるかに安価です。 Solid Cache を使用すると、RAM を使い果たすことなく、より多くのデータをキャッシュする (そしてそれをより長く保持する) ことができます。 37signals (Basecamp と HEY の背後にある会社) では、Redis から Solid Cache に切り替えることで、キャッシュを 10 テラバイト以上のデータに拡張でき、最終的に P95 のレンダリング時間を 50% 短縮できました。

はい、メモリからの読み取りはディスクからの読み取りよりも高速です。多くの場合 (Basecamp の使用法など)、より多くのデータをキャッシュするというトレードオフにより、この高速化にはそれだけの価値があります。

デフォルトでは、Rails 8 は Solid Cache (SQLite によってサポートされる) を使用します。もちろん、Rails の規約ではよくあることですが、自分にとってより良い選択であれば、Redis などの別のオプションを選択することもできます。ただし、このデフォルトを維持すると、Redis などの別の実稼働サービスをサポートせずにキャッシュできるため、インフラストラクチャの負担が軽減されます。

Solid Queue は、Redis を使用せずにバックグラウンド ジョブを実行するのに役立ちます

「Solid」トリフェクタの 2 番目に気に入っている部分は、Solid Queue です。これは、Redis や Sidekiq のような別個のジョブ システムの依存関係を必要とせずに、バックグラウンド ジョブの処理を処理する新しいアクティブ ジョブ バックエンドです。

多くの Rails 開発者は、Sidekiq (Redis に依存) や Delayed Job などの gem をバックグラウンド ジョブに使用しています。 Solid Queue は、Rails がその必要性を排除しようとする試みです。 別の依存関係のために。ジョブ キューイングをアプリケーションのデータベースに統合するため、メモリ ソリューションやキューイング システムは必要ありません。

Solid Queue は、ジョブをデータベース テーブルのレコードとして保存し、効率的な SQL 機能を使用してジョブ キューを管理します。これは、Rails Web プロセスに埋め込まれて (単一サーバー設定用の Puma プラグインとして)、または別のワーカー プロセスで実行できます。

Rails コア チーム メンバーの 1 人が述べたように、目標は、開発者が「7 つの異なる gem やその他のシステムを管理することなく、Rails をインストールし、データベースをセットアップし、すぐにバックグラウンド ジョブ処理を実行できるようにする」ことです。

Solid Cable は Web ソケットの実行に役立ちます (驚くことに Redis なしで)

Rails 8 の「Redis 不要」パズルの 3 番目のピースはソリッド ケーブルです。 — ご想像のとおり、データベースを使用する新しいアクション ケーブル アダプター。これまで、Action Cable では、複数の Rails プロセス間でメッセージをブロードキャストするために Redis サーバーが必要でした。 Solid Cable を使用すると、追加のサービスを実行することなく、リアルタイム WebSocket 機能に Action Cable を活用し、チャットや通知などのアプリケーション機能のライブ アップデートをロック解除できます。

「Solid」三連単のメリットがもう明らかになっていることを願っています。 Redis サーバーや他のパブリッシュ/サブスクライブ サービスを立ち上げることなく、長期データをキャッシュし、高スループットのバックグラウンド ジョブを処理し、リアルタイム機能をデプロイできます。これらの機能を組み合わせることで、小規模アプリの複雑さが軽減され (1 つのデータベースを使用して単一のホスト上ですべてを実行できます)、デプロイを容易にするという Rails 8 の哲学に適合します。

Redis が不要になることはそれほど大きなことでしょうか?

Rails 8 が Redis への依存関係を取り除くことにどれほど重点を置いているかを見た後、それが実際にどれほど重要なのか知りたいと思うかもしれません。答えは状況によって異なりますが、いくつかの注目に値する利点があることは間違いありません。

可動部分が少ないということは、特に導入において複雑さが軽減されることを意味します。追加サービス (Redis、個別のバックグラウンド ジョブ ランナーなど) はすべて、機能が停止したり、スケーリングが必要になったりする可能性があります。データベースをさらに活用することで、運用操作が簡素化されます。 Redis メモリを監視したり、Redis インスタンスが常に実行されていることを確認したりする必要はありません。

多くの Rails 開発者は、開発時にはキャッシュ サーバーを実行していないか、別のキュー アダプターを使用しているのに、本番環境では Redis/Sidekiq を使用しているというシナリオに遭遇したことがあります。新しい Rails のデフォルトを使用すると、開発と運用で同じセットアップを実行でき、予期せぬ事態を最小限に抑えることができます。このスタックはより自己完結型であり、実稼働用の特別な構成を必要とせずに、すぐに「そのまま動作」します。

サーバーやアドオンが少ないほど、ホスティング料金も安くなります。より大規模な場合でも、インフラストラクチャを統合すると、ある程度のコスト効率が高まります。データベース スペースはメモリよりも安価です!

Rails によって、Redis やその他のサービスの使用が妨げられることはありません。それはオプションになるだけです。 。組み込みの Solid アダプターから始めることができ、必要に応じて、後で Redis または他のソリューションを導入できます。

SQLite によりデータベース プロセスが不要になります

Rails 8 におけるもう 1 つの意味のある変化は、Rails の SQLite アダプターに対する数多くの改良によって可能になった、使用可能な運用データベースとして SQLite を採用したことです。アプリが運用環境で SQLite を使用できる場合は、別のデータベース サーバーを実行する必要はありません。代わりに、データはアプリ プロセス自体によって管理されるディスク上の単純なファイルに保存されます。 Rails 8 による SQLite の改善により、これは以前よりも現実的になっています。

SQLite を使用すると、展開をより簡単に行うことができます。 MySQL や Postgres をサーバーにインストールまたは管理したり、マネージド DB サービスを使用したり (料金を支払ったり) する必要はありません。これは、Rails アプリが読み書きする単なるファイルです。

もちろん、SQLite の規模が大きくなりすぎた場合は、後でフル機能のデータベース システムに移行することもできます。 Rails コア チームは、デフォルトを軽量オプションに変更したところです。これは、「PaaS なし」の主張によく適合します。

Kamal 2 は導入に役立ちます

Rails 8 は実行を簡素化します アプリは実稼働環境にありますが、アプリを稼働させるにはどうすればよいでしょうか。 生産？ Kamal 2 のリリースは、その質問に答えようとしています。

Kamal は、最小限の手間でアプリを (Docker コンテナ経由で) Linux サーバーにデプロイするオーケストレーション ツールです。すべてのサーバー設定を手動で行う必要がなく、アプリのイメージの構築、プッシュ、サーバー上での実行が自動化されます。

いくつかの設定と 1 つのコマンド (kamal setup) )、Kamal は新しい Linux ボックスを取得し、Docker コンテナを実行するために必要なものをプロビジョニングします。

その後のデプロイは、kamal deploy を実行するだけで簡単になります。 これにより、最新のイメージが取得され、古いコンテナが新しいコンテナと交換され、ダウンタイムなしの展開が実現します。

Kamal 2 は、あらゆる Linux ホスト上で PaaS のような展開エクスペリエンスを提供したいと考えています。単一のコマンドで、任意のサーバーをアプリを実行する Rails サーバーに変えることができます。初期構成は面倒かもしれませんが、その後の展開ははるかに簡単です。これは、セルフホスティングを Heroku のようなプラットフォームにプッシュするのと同じくらい便利にするための大きな一歩です。

「PaaS を使用しない」は良い考えですか?

Rails 8 は本当にありますか？ プラットフォームを過去のものにする？また、小規模から中規模のチームは、セルフホスティングによって本当にコストを節約できるのでしょうか?

最近、Kamal を使用して趣味のプロジェクトを VPS にデプロイしましたが、イライラするような経験でした。動作させた後の展開は比較的スムーズですが、セットアップはそれほどスムーズではありませんでした。このプロジェクトを拡張する必要がある場合、私の仕事は私にとって最適です。

したがって、私にとって、 答えはノーです。Rails 8 はプラットフォームの価値提案を排除するものではありませんです。 。私はむしろ自分のアプリに集中して、インフラストラクチャは Heroku のようなプラットフォームに任せたいと思っています。

個人開発者や小規模チームは、規模の経済を追求するよりも、ユーザーに焦点を当てたほうがメリットが得られます。ホスティング、デプロイメント、スケーリングをこれらの分野で優れたプラットフォームにアウトソーシングし、顧客に愛される製品の構築に集中してみてはいかがでしょうか?

もちろん、チームとアプリケーションが成長するにつれて、プラットフォームの価格設定が魅力的ではなくなる可能性があります。ある時点で、SRE や運用の責任に専念する時間や人員を確保することは理にかなっています。Kamal は (他の素晴らしい Rails 8 のデフォルトとともに) それを容易にするための大きな一歩です。

すべてをまとめる

Rails 8 はセルフホスティングとプラットフォームの使用との間のギャップを狭めますが、正直に「PaaS は必要ありません」と主張できるほど距離は縮まりません。ただし、Rails 8 により、開発者のエクスペリエンスをあまり犠牲にすることなく、PaaS よりも VPS を選択しやすくなったことは明らかです。ただ、それがプラットフォームキラーだとは思いません。

Solid Cache、Solid Queue、Solid Cable はいずれも、これまでサードパーティが要求していた Web アプリの要件をファーストパーティのサポートに取り入れており、これには感謝しています。アプリケーションを軌道に乗せるための軽量かつ強力なデフォルトがあるのは素晴らしいことです。さらに、多くのインフラストラクチャを必要としないのがさらに良い点です。自己ホストを選択した場合、Kamal はデプロイメントの負担の一部を軽減してくれます。

プラットフォームを使用しているかどうかに関係なく、エラーや停止に迅速に対応し、顧客に優れたユーザー エクスペリエンスを提供するには監視が不可欠です。 Honeybadger にサインアップすると、Rails アプリケーションの健全性とパフォーマンスに関するリアルタイムの洞察が得られます。