これは Redash Advent Calendar 2018 の 17 日目の記事です。
16 日目は @mazamachi さんの『kubernetess の redash か黒魔術』ですが、まだ投稿されていないようですね。今回の記事にも関連するので期待してます。
1 日目の『2018年12月現在における Redash のはじめかた 』を拝見しました。実際問題、どこに立てれば良いか、悩む方もいらっしゃるのではないでしょうか。今回はその点をまとめていきます。
Redash をどこに立てれば良いか？
身も蓋もありませんが、ご自身が一番慣れた Docker の PaaS 上で動かすのが良いと思います。
AWS EC2 や GCE などの、非 Docker 環境は運用負荷がそれなりに発生するため、避けたほうが良いでしょう。アップグレードでハマったり、ストレージ使用量 100% になるのはあるあるです。
↓ 公式の How to Upgrade はいつの頃からか、非 Docker 環境でのアップグレード方法が “legacy guide” になってました。公式でも Docker 推しのようです。
This instructions are for those who use our new Docker based instance. If you use our older instances (or used the old bootstrap script), check the legacy guide .
業務では先月、Redash を本番環境と同じ Heroku に立てました。予想以上に簡単かつ安定して動いています。この記事では、Redash on Heroku のメリットをデメリット含めて紹介します。
メリット1: 簡単に立てられる
README.md の通りにセットアップすれば、10 分程度で Redash を起動できるのではないでしょうか。
先日 heroku.yml に対応した PR がマージされた ため、セットアップがより簡単になりました。git push でコンテナを起動できるのは便利です。
ちなみに私は Redash のバージョンを固定するため、Fork 版を使っています。
- ブランチ: https://github.com/feedforce/redash-on-heroku/tree/ecbooster
- 差分: https://github.com/willnet/redash-on-heroku/compare/master...feedforce:ecbooster
5.0.2.b5486 の場合、5.0.2 がバージョンで、b5486 はビルド番号 です。ビルド番号は気にしなくて良いと思います。Docker Image のタグは https://hub.docker.com/r/redash/redash/tags で確認できます。
メリット2: 毎日再起動される
Heroku の Dyno はだいたい 24 時間に 1 回、自動的に再起動され、Dyno が差し替わります。
Dynos and the Dyno Manager > Automatic dyno restarts
仮に Redash にメモリリークのバグがあったとしても、次の日にはリセットされます。本番環境と違って Redash はそれなりに動けば良いため、地味にメリットだと思います。
本番環境に加えて Redash まで監視してアラートの通知が来るのは、ちょっと運用負荷が高いと思うので、とりあえずリセットされるのはうれしいですね。
メリット3: クエリが詰まっても安心？
Redash はたまにクエリが詰まることがあり、再起動が必要になることがあるそうです。
3 日目の塚田さんの記事『redashの導入、運用で得た知見、改善まとめ 』で言及されています。
ですが、メモリ要因の詰まりであれば、Redash on Heroku では何もする必要はないかもしれません（今のところ手動で再起動したことはありません）。
Heroku ではメモリが Dyno の上限を超えてスワップし始めると、R14 Error (Memory quota exceeded) が発生します。例えば Hobby Dyno のメモリ上限は 512MB です。
さらにスワップが増え、メモリ上限の 2 倍を超えると R15 Error (Memory quota vastly exceeded) が発生し、Dyno は強制再起動されます。
Dynos and the Dyno Manager > Memory behavior
エンジニアが手動で再起動しなくて良いのは、運用面で大きなメリットです。もちろん頻発する場合は、Dyno type を上げたほうが良いと思います。
ちなみに、エラーや Dyno の再起動の様子は Heroku のダッシュボードで確認できます。以下は例です。もちろん Heroku のログでも確認できます。
メリット4: DB のバックアップ
Heroku Postgres Add-on は Free 含めて全てのプランで自動/手動バックアップ可能です。
事故が起きた場合に役立つでしょう。Redash のアップグレード前の手動バックアップは忘れずに。
割と致命的なデメリット
データソースとして使いたい MySQL や PostgreSQL のエンドポイントがインターネットに露出していない場合、Redash on Heroku を採用することは出来ないでしょう。ECS や GKE など、当該プラットフォームの Docker サービスを使いましょう。
参考: Dyno type
業務で使う場合は、Hobby ($7/mo) 以上が良いでしょう。もちろん、試しに立てるだけなら Free で十分です。
Free と Hobby のメモリサイズは同じ 512MB ですが、Hobby 以上であれば Sleep がないことと、ダッシュボードで Metrics を見られるからです。結果的に運用時間の短縮になるでしょう。
参考: Dyno Types｜Heroku Dev Center )
参考: Add-on のプラン
Heroku Postgres Add-on のプランは Hobby Basic ($9/mo) 以上がほぼ必須です。
Hobby Dev ($0/mo) だと Row Limit が 10,000 であるためです。Redash は events Table にアクセスログっぽいものを記録するようで、一週間も経たないうちにプランを上げるハメになりました…。
ボタン一発で Hobby Dev から Hobby Basic にアップグレードすることは出来ない ため、最初から Hobby Basic で始めることをオススメします。Hobby Basic だと Row Limit は 10,000,000 なので、しばらくは大丈夫でしょう。
Redis Cloud と SendGrid Add-on は無料プランで十分だと思います。
まとめ
Redash on Heroku のメリットとデメリットを紹介しました。運用が非常に楽です。一度試してみてください。
明日の Redash Advent Calendar 2018 は @Udomomo さんが Redash CLI について書くそうです。Redash CLI は使ったことがないので、今から楽しみです。