dynoでredisを実行するのは興味深いアイデアです。 dynoがredisをダウンロードして実行できるように、おそらくredisビルドパックを作成する必要があります。 「redisには動作するGCCコンパイラとlibc以外の依存関係はない」ので、これは技術的に可能であるはずです。
ただし、発生する可能性のある問題は次のとおりです。
-
Herokudynoには静的IPアドレスがありません
「dynoには静的IPアドレスがありません。IPから直接dynoにアクセスすることはできません」
dynoでRedisをセットアップして実行したとしても、そのdynoインスタンスを見つけてredisリクエストを送信する方法を私は知りません。つまり、RedisサーバーはおそらくWebサーバー/メインアプリケーションと同じdynoで実行する必要があります。
これも つまり、より多くのWeb dynoを作成してアプリをスケーリングしようとすると、より多くのローカルredisインスタンスも作成されることになります。それらの間でデータが共有されることはありません。これは特にスケーラブルなデザインだとは思いませんが、アプリが1つのWeb dynoしか必要としないほど小さい場合は、機能する可能性があります。
-
Herokudynoには一時的なファイルシステムがあります
「書き込まれたファイルは他のdynoのプロセスに表示されず、書き込まれたファイルはdynoが停止または再起動された瞬間に破棄されます」
デフォルトでは、RedisはRDBファイルとAOFログをディスクに書き込みます。 dynoの再起動後にフェッチして復元できるように、これらを定期的にどこかにバックアップする必要があります。 Redisの永続性に関するドキュメントを参照してください。
-
Herokudynoは頻繁に再起動されます
「Dynosは少なくとも1日に1回、またはdynoマニホールドが基盤となるハードウェアの障害を検出するたびに循環します」
dynoが起動するたびに、redisサーバーを起動して、データを復元できる必要があります。
-
Herokudynoには512MBのRAMがあります
「各dynoには、動作する512MBのメモリが割り当てられています」
RedisサーバーがWebサーバーと同じdynoで実行されている場合は、メインアプリに必要なRAMを差し引きます。どのくらいのRedisメモリが必要ですか？
Redisのメモリ使用量を見積もり、追跡しようとするいくつかの質問があります：
- Redis：データベースサイズとメモリの比率？
- Redisのメモリ使用量のプロファイリング
-
全体： Herokuの対象となるアプリケーションモデルについてもう少し理解するために、12個のFactorAppsを読むことをお勧めします。
短いバージョンでは、dynoは、需要を満たすために簡単に作成および破棄できる独立したワーカーであることが意図されており、dynoはさまざまなリソースにアクセスしてデータの読み取りまたは書き込みを行い、アプリを提供します。 redisインスタンスはリソースの例です。上記の項目からわかるように、redisアドオンを使用することで、静的で安定し、アクセス可能であることが保証されたものを取得できます。
読み物：
- http://www.12factor.net/-特にプロセスとサービス
- Herokuプロセスモデル
- Herokuブログ-プロセスモデル