こんにちは！この記事は Heroku Redis についての記事になります。

Redis に関するナレッジはこれまで様々語られてきており、
この記事の位置づけとしては**「Salesforceデベロッパが Heroku Redisを知らねばならない時に見ておくと良いよガイド」**を目指しています。

僕も細かい挙動はDevCenterを見ながら動かして、なのですが、まず概要や全体観を知るためのメモとしてご覧いただければと思います。

Redis?

KVS。永続化もできるインメモリデータベースと言われることもある
KVSとしてはmemcachedと似ているけれど、データ型があるところと、非同期でディスクにもデータを書き出してくれるので再起動してもデータが揮発しないところ（≒永続化）が機能面の大きな違い

Redis には5つの型がある

用途に応じたデータ型が用意されている

String型
Hash型
List型
Set型
SortedSet型

どのデータ型を使うか気になったら、この記事がわかりやすい
Redisについて各データ型と想定用途をまとめてみた

1つのプロジェクトで全部使うことはなかなかないですね...

Heroku Redis?

Heroku Redis はHerokuが運用管理してくれる DaaS (Database as a Service)の Add-on
Herokuのダッシュボードからある程度データが見れて便利

どういう時に使う？

■ HerokuでWebアプリ作ったときのセッション管理

アプリケーションコンテナである Dynoは24時間+αで自動で再起動する ので、保持したいデータは必然PostgresなりRedisなりで抱えてあげる必要がある

■ 大量データを捌くためのKafkaとの併用、あるいはPostgresの前段として

このケースは少なめ

Redis + Kafka
- 先日 Salesforce による Slack の買収の話が持ち上がりましたが、Slackのバックエンド（ジョブキュー）も KafkaとRedisで構成されていたと思います。大量データをHerokuで面倒見なきゃいけないケースのときは、どちらかと言うと Heroku Kafkaメインで組むことが多いかなという印象
Redis + Postgres
- 大量の照会処理が入るケースで、Postgresの前段に起きつつPostgresのFDWで繋ぐパターン。いわゆる Heroku Data Linksの出番ですが、redis_fdw（Redis連携）は今日時点で、DevCenterでは非推奨となっているみたいです

■ リアルタイムランキングやソート済みリストの利用

SortedSet型を使うとランキングやソート済みリストを作るのに便利です

特に後者のようなコミュニティサイトの要件の場合、ライセンス費用や制約によって SalesforceのExperience Cloud（Community Cloud）とHerokuのどちらを使うかがソリューションの1つになることがあるのですが、Herokuを使うならばおそらく上記のようなケースでRedisが活用するかな、と思います

Heroku Redisの概要をよく知りたい

Partner Base Camp / Heroku

Salesforce公式 Partner Base Campで永野さんがまとめてくれているまとめから「Heroku Redis 概要」資料を参照しよう
ここは本当に良コンテンツの山

あとはざっとよくまとまった記事としてはuskさんのこの記事
Heroku Redisについてまとめてみた

書かれている中で、運用面では

メンテナンスウインドウ
メモリ容量オーバー時の挙動

この2つを特に抑えておけばいいかなと思います

メンテナンスウインドウ

メンテナンスウインドウとは、時間をこちらで指定することのできるパッチ適用のこと
Heroku Redis のメンテナンスウィンドウ

Postgres と Redis は設定をしておくと予期せぬタイミングでのメンテナンスが生じるリスクが減るので設定しておくと良いです

Heroku Redis / Heroku Postgres メンテンナンスの仕組み

ピンと来た人もいるかもしれませんが AWS のメンテナンスウインドウのこととほぼ同じ（HerokuはAWSをバックエンドで利用していて、Postgres/RedisもEC2の上に載っているはず）

ただし基本的にHerokuのメンテナンスウインドウの指定はコマンドライン
（AWSならSystems Managerからコンソールで行けるけど...）

Heroku CLI経由で

heroku redis:maintenance --window="Sunday 14:30"

とすればOK

なお、メンテナンスウインドウは予期された定常的なメンテナンスの場合の時間帯指定の話なので、突如発生する予期せぬメンテナンスの場合はその場で障害対応が必要です

Eviction Policy (メモリ容量オーバー時の挙動)

こっちは注意が必要。

メモリ容量オーバー時の挙動とは、指定したHeroku Redisインスタンス上のメモリの容量が迎えたときの挙動の話
Heroku の初期設定/デフォルトだと noeviction 。つまりメモリ容量溢れ時に何もしない状態。つまりメモリ容量でエラーが起きて動かないケースがあるということ。システム全体がコケることに繋がる

参考：本間さんの Heroku Redis は初期設定で利用してはならない

僕も実際こうなってしまったケースは無いのですが、こればっかりは気づいてからの対処がとても面倒なので、先に知っておくしかないですよね。。

Heroku Redis の Maxmemory Policy / キャッシュアルゴリズム一覧

maxmemory-policy一覧

noeviction - メモリ制限に到達したときにエラーを返します。
allkeys-lru - 最後に使われてから最も長い時間が経過したキーを最初に削除します。
volatile-lru - 有効期限が設定されている、最後に使われてから最も長い時間が経過したキーを最初に削除します。
allkeys-random - ランダムキーを追い出します。
volatile-random - ランダムキーを追い出しますが、有効期限が設定されているものに限られます。
volatile-ttl - 有効期限が設定されていて TTL が短いキーのみ追い出します。
volatile-lfu - 有効期限が設定されているキーの中から概算 LFU を使用して追い出します。
allkeys-lfu - 概算 LFU を使用していずれかのキーを追い出します。

アプリでの用途次第だけど volatile-lru を指定しておくのが定石かと

Maxmemory policy のチェックポイント

Maxmemory Policyを変更しておこう（Herokuのデフォルトが変わらない限り）
そもそもだけどキーのTTLは設定しよう
本番稼働時にリリース作業漏れしやすいのでどの環境でも設定済みかは必ず確認しよう

（Heroku Enterprise であれば最初に全App、全Addonを入れておくのもありなのですが、結局実装中にもろもろ設定を調整するので、結局最後は人の目が必要）

プランの考え方

どのプランにするかで見るのはここ

Premium-0かPremium-1 で済んでしまうことが多い
体感、非PS環境におけるProductionの7割はPremium-0で何とかなってるイメージ
（Heroku Redisは結構低めのPlanからそこそこの性能が用意されている）

ただし本番PrivateSpacesの場合Add-on消費はまあまあいってしまうので
↓のDynoの例のように最初にDevStarterPackの使いみちやアップセルなど想定しておくと良い

Partner Community - Heroku案件を手掛けるときに知っておきたいこと
（過去登壇資料）

柔軟にプラン変更できるのもHerokuの強みだけど、セオリーとか考え方のベースはあった方が良い

Heroku Postgres と Heroku Redis

2大DataService公式Addonと言えるけど前者はRDBMS、後者はKVS。用途が異なるのでそれぞれ違いを捉えておく
なお SFプロジェクトで、Heroku Connect周りでよく話題に上がるのは Postgresの方

Namespace？

強いて言えばたまに namespace を使うことがあるかも
単に値を保存するだけじゃなくて namespaceをキーに付与することで、これはマイページ用、これはEC用という分類に使えたり、Staging環境や調査環境などでnamespaceを分けて、ちょっと込み入った使い方ができたり

ただし1つのRedisインスタンスに複数環境、複数プロジェクトのデータが保管されるのは
The Twelve factor Appに照らすとあんまりよくないかもしれない

Heroku をもっと学ぶには

1. DevCenter

まずは手を動かして、というのもあるけど Dev Centerがゆりかごから墓場まで
https://devcenter.heroku.com/

最近DevCenterが日本語対応のアナウンスがありました。
対応しているページは日本語へ切り替えることができ、Google/DeepL両先生のお力を借りずとも読みやすくなっています
（日本語対応の件、本当にお疲れさまでした。）

2. HerokuのAdvent Calendar

今年は密を避けた形になってしまっているけど毎年良記事がたくさんデプロイされているので、追ってみるだけでも良いかも知れない

https://qiita.com/advent-calendar/2020/heroku
https://qiita.com/advent-calendar/2019/heroku
https://qiita.com/advent-calendar/2018/heroku
https://qiita.com/advent-calendar/2017/heroku
https://qiita.com/advent-calendar/2016/heroku
https://qiita.com/advent-calendar/2015/heroku

3. Partner Base Camp

本当に良いサイト

4. ユーザグループのSlack

ちなみにHeroku ユーザーの Slack グループがあります。
newsとか全体的に濃い話はこちらで

最後に

普段そこまでニーズ出てこなくても必要になったら急に調べないといけないので、
そのときはこの記事から各ナレッジやHerokuアーキテクト/デベロッパの皆さんの元へ飛んでいただければ幸いです。

それでは