RedashをECS Fargate構成にしてv7からv10へアップグレードする

最近カービィシリーズの動きが活発で嬉しい 会員システムグループでエンジニアしている石川です。

弊社にはDWHのBIツールとして5年ほど前から使っているRedashがあります。
公式のAMIから作ったEC2単体構成で立ち上げてから、v1からv7までアップグレードしたりスケールアップで負荷に対応してきました。
v8からDocker必須となり移行が手間でアップグレードを見送っていたのですが、利用者も増えてきたのでちゃんとしようと思い　今回ECS Fargate構成にしてv10までのアップグレードを行いました。

構成図

可用性はそこまで高くする必要はないので、拡張性は担保しつつもシングルAZ構成。
安く組みたいのでAuroraではなくRDSを利用しています。

Fargate化とアップグレード手順

Redashの移行に関してDBデータ移すだけでいいため、まずFargate化から行いました。

1. Fargate構成のRedash v7を作成
2. 既存RedashのPostgreSQLのダンプファイルをRDSにリストア、v7動作確認
3. v8へアップグレード、v8動作確認
4. v10へアップグレード、v10動作確認
5. OneLoginとのSAML設定

アップグレード時の操作

インフラ構築はCDK使って作成しています。
アップグレードは立ち上げるタスクを切り替えてデプロイすることで実現しています。

アップグレード時の注意点

主に公式ドキュメントとGitHubリポジトリのRelease文面の通りにやっていれば問題ないのですが、ひっかかった部分だけ記載しておきます。

データソースの画面が空になった

REDASH_COOKIE_SECRET と REDASH_SECRET_KEY はDBとクッキーの暗号化キーとして使われているので、既存Redashで使われていた値を指定する必要があります。
これが空だったり違う値だと複合に失敗するためデータソースが取得できず空になります。

CFnでリソースの置き換えが進まない

既存タスクが終わらせられないのかデプロイが進まないことがあります。これは既存タスクを手動で止めた後ちょっと待っていれば進み出します。
根本原因だと思われるRQ Schedulerのバージョンを上げれば対応できそうですが、これだけのためにイメージ作り直すのも手間なので今回は手動対応しました。

参考：RedashでScheduler更新時に発生するエラー「There’s already an active RQ scheduler」について原因を調べて解消してみた | DevelopersIO

OneLoginとのSAML設定

v7を使っていた時は設定のためにRedashのソースを書き換えて対応していたのですが、v8やv10では書き換えなしで利用できるようになっていました。
ただマニュアル通りに書いてもうまくいかなかったのでv10でうまくいった設定を書いておきます（v8でも動くと思います）

OneLogin Appには SAML Custom Connector (Advanced) を利用。
Configurationは以下のように設定。
Parametersには　FirstName と LastName のマッピングを追加。

Redash側にも以下のように設定。
SAML Entity IDにはインスタンスのURLを指定しろとRedashのドキュメントには書いてありますが、それだと動きませんでした。

Fargate構成でRedash v10を使ってみた印象

フロントが100％Reactになった影響か、レスポンスが格段に速くなっていて気持ちいいです。
Fargate化して良かったのはインスタンスを意識しなくていいのはもちろん、アップグレードの楽な点がいいですね。

はじめは腰の重い作業でしたが先人の知恵がすでに多くあり、それほど引っ掛かることなくアップグレードできました。
OneLoginとのSAML設定だけはソースコードを書き換える方法しか見つからなくて、今回の設定値を見つけるのだけは時間がかかりました。。
もし同じような構成で悩んでいる方がいましたら本記事が参考になると幸いです。