Solid Cacheの紹介
こんにちは、tanaken on Railsです。
第36回始めていきます。
今週は、This Week in Railsでは、
Solid CacheとSolid Queueについてのお話がありました。
もちろん他にもプールリクエストの紹介がありましたが、
このSolid CacheとSolid Queueについては、
結構、Rails 8のデフォルトが変わったと、
デフォルトのジェムが変わった、
キャッシュの管理だったり、
Queueの管理、
ジョブQueueの管理について変わったというところなので、
この2つを紹介していこうかなと思います。
まず1つ目、
Add Solid Cacheというプールリクエストですね。
こちらは、Railtiesに関する変更です。
Solid CacheジェムがRails 8系のデフォルトに追加されました。
--skip-solidというオプションを指定すると、
このジェムの追加をスキップすることができます。
リポジトリ、github.com//rails//solid-cacheというリポジトリを見てみましょう。
冒頭に概要の説明があって、
Solid Cache is a database backend active support cache store
that lets you keep a much larger cache than is typically possible
with traditional memory-only RAILS or memcached stores
ということで、
Solid Cacheはデータベースでバックアップされた、
データベースでバックアップというか、
翻訳バックアップってなってるんですけど、
データベースバックエンドなアクティブサポートの
キャッシュストアですと。
Railsの従来のメモリー、
よく使われるのはRedisとか、
memcachedとか、
memcachedとかを使われる、
ストアとして使われることが多いんですけど、
それらはメモリーですね、
メモリーに載せてるっていう感じですけど、
よりもはるかに大きなキャッシュを保持できるよと、
データベース、
リレーショナルデータベースに
アクティブレコードを介して
キャッシュするっていう感じになるので、
それは大量のデータが保存できるよね、
という話かなと思いますね。
その他読むと、
日本語訳した方読むか、
最新のSSDドライブは
すごい速度が向上してると、
なのでキャッシュの目的で
ディスクとランダムアクセスメモリー、
メモリーを使う、
もともとメモリーを使うのは
多分書き込みの速度とか、
読み込みの速度とか、
速度が重要なときに
小さなデータだけど
メモリーに入れとくっていうような
使い方がされていたが、
最近は速度がすごい技術が向上しているので、
別にメモリーじゃなくていいんじゃない、
みたいなことを言っていると。
簡単に言えば、
メモリーだとキャッシュが小さいっていう
デメリットだけあって、
キャッシュというか、
容量が小さいっていうのだけあって、
ちゃんとデータベースのディスク上に
データをしっかり大量に保存した方が
有意義なのでは、
みたいなことを言っています。
これは多分、
いろんな使い方にもよるでしょうけどね。
ということを主張していますね。
導入については、
新規で作る場合は、
Railsに入手してくれればいいし、
既存のアプリケーションに追加する場合も、
このソリッドジェム、
ソリッドキャッシュジェムを追加して、
バンドリンストールとかしてくれればいいですよ、
というのと、
設定としては、
データベースYAMLと、
ソリッドキャッシュYAML、
この2つを設定すれば、
基本的には使えるという感じですかね。
コンフィグストラデータベースYAML、
こいつについては、
もともとデータベースの設定が書かれているところですけど、
ここに各環境、プロダクションとか、
エンバイルメントとか、
デベロップメントとか、
皆さん書いてると思うんですけど、
環境ごとにね。
環境の下にキーとして、
キャッシュというキーを追加してもらって、
そのキャッシュキーの中に、
データベースというキーだったり、
マイグレーションズパスというキーだったり、
というのを入れてもらって、
指定してくださいよ、
というようなことが書いてありますね。
あとは、
コンフィグストラストリートアンダスコアキャッシュYAMLに関しては、
こいつはですね、
これも各環境ごとに、
デベロップメントとかプロダクションとかごとに、
書くんですけど、
ストアオプションズ、
ネームスペースとか、
サイズとかか、
ストアするマックスサイズとか、
そういった設定が書いてあるという感じですかね。
これらの他にも、
データベースのコネクションに関する設定などの仕方が
READMEに書いてあるので、
詳しくはそちらをご参照ください、
という感じでございます。
Solid Queueの導入
では続いて、
2個目ですね。
アドソリッドキューアロングサイドソリッドキャッシュ
というタイトルのプレリクエストです。
ソリッドキューを追加しましたというので、
レールタイズに関する変更ですね。
ソリッドキュージェムがレールズ8のデフォルトになっていますと。
先ほどのソリッドキャッシュというジェムと一緒で、
スキップソリッドというオプションを付けると、
このソリッドキューとソリッドキャッシュはスキップ、
ジェム追加されないという、
まとめてスキップできるという感じになっていますね。
このソリッドキューに関してはですね、
ずいぶん前の回でも紹介しています。
3月末頃の回ですね。
でも紹介しておりまして、
その時の小ノートの自分のメモをもう一度見てくると、
ソリッドキューはアクティブジョブのキューイングライブラリの一つですと。
レールズガードに記載がある通り、
ジョブの登録と実行にはキューイングのバックエンドを用意する必要があると。
そのキューイングのバックエンドの機能を提供してくれるのがキューイングライブラリ。
その中の一つが今回紹介しているソリッドキューですよと。
もともとキューイングライブラリにはいろいろあって、
サイドキックとかレスキューとかディレイドジョブなどが有名ですよと。
サイドキックとレスキューはデータストアがレディスです。
ディレイドジョブはデータストアのマッパーをいくつかの種類の中から選べるよというところで、
ディレイドジョブのリポジトリのウィキにも書いてありますね。
アクティブレコードを選ぶことも選べるし、データマッパーとかアイロンMQとか文言マッパーとかいろいろあるんですよね。
ソリッドキューはアクティブレコードの利用が前提となっているキューイングライブラリですと。
データストアとしてアクティブレコードが使えるデータベースを扱えるということですと。
現時点ではMySQL, PostgreSQLiteの3つをサポートしています。
MySQL 8以上あるいはPostgreの9.5以上を使う場合は、
forUpdateSkipLockedという機能を使って高パフォーマンスでロックを回避したりするような仕組みがあると。
ロックの待機を回避したりとかみたいな仕組みがもともとDB側に機能として最近あるので、
これを駆使して高パフォーマンスでキューイングライブラリとしての振る舞いができるよということですね。
これが3月末頃に僕が言ってたやつで、
DHHさんはその頃からこのソリッドキューをデフォルトのキューイングライブラリにするぜ、絶対にみたいな。
絶対に言ってないからするぜってことを言ってたと言ってたんで、そこから半年経たないくらいか。
デフォルトのキューイングライブラリになったよということですね。
こちらもリポジトリあるので、そちらのReadMeを詳しくは読んでくださいという感じですが、
比較的最近ですね、9月の4日、今9月の7日なんで3日前か、
メドピアさんのメドピア開発者ブログでソリッドキュー解体新書という記事が書かれております。
これが非常に丁寧に書かれて書いていただいている記事でありがたい記事でございます。
この記事はソリッドキューの内部実装の簡単な解説をしてくれると、
その前段としてソリッドキューとは何ぞやという話もしてくれているというところで、
僕は今話したようなことも重複して説明があるんですけども、より詳しく書かれているので、
ぜひぜひこちらはご覧いただきたいなと思っております。
アクターの役割
その中で特にソリッドキューを使うにあたって知っておくべきだなというところで、
アクターというものの概念についての説明もあったんで、そこだけちょっとピックアップしてお話ししておきますね。
ソリッドキューには3種類のアクターがありますと。
ディスパッチャー、ワーカー、スーパーバイザーの3つのアクターがあると。
ディスパッチャーとは何ぞやというと、
ジョブの実行タイミングの管理や同時実行可能数の制限などを行うものですと。
ワーカーというのは、実行待ちジョブをポーリングして処理を実行すると。
ワークしているワーカーですね。よくワーカーって言いますよね。
最後3つ目、スーパーバイザー。
こいつは設定内容に基づいてディスパッチャーとワーカーの2つを起動させてその稼働状況を監視する。
そういう役割。この3つに分かれているんだと。
3つに役割が明確に分かれているので、
例えばジョブの実行タイミングを管理するようなディスパッチャー君はこの子は1個だけあればいいよねと。
ワーカーはたくさん必要だね。実行部隊なんで。
たくさん必要なんで複数立ち上げようみたいな調整が柔軟にできるという風に言ってますね。
ディスパッチャーは1つだろうな。
ディスパッチャーが複数必要というのは相当処理しなきゃいけない。
割り振らなきゃいけない。ディスパッチしなければならないジョブが大量にあるときに
ディスパッチャーが詰まるみたいなことがあるとディスパッチャーを増やすのかな。
でも振り分けが難しい気もしますけどね。
ディスパッチャーに対するディスパッチみたいなのが必要になっちゃわない?みたいな気もするけど。
分かんないがその辺をうまくできる仕組みがあるんでしょう。きっと。
この3つの役割。ディスパッチャー、ワーカー、スーパーバイザー。
スーパーバイザーがそれをやるのかな。ディスパッチャーへのどういう振り分け。
ジョブの種類でそもそも分けるのかなとか。分かんないけど。
監視だからなスーパーバイザーは。分かんないけど。
そういう3つの役割があるよということを理解してソリッドQを使いましょうという話になるのかなと思いますね。
ということでMotopiaさんのブログも含めて今回はソリッドキャッシュとソリッドQについてのお話をしました。
ではこんなところで今週のTanaken on Railsは終わりにします。
ではまた来週。バイバイバイバイバイバイバイバイ。
