Heroku と Redash は相性が良いのでは？という話
これは Redash Advent Calendar 2018 の 17 日目の記事です。 16 日目は @mazamachi さんの『kubernetess の redash か黒魔術』ですが、まだ投稿されていないようですね。今回の記事にも関連するので期待してます。 1 日目の『2018年12月現在における Redash のはじめかた 』を拝見しました。実際問題、どこに立てれば良いか、悩む方もいらっしゃるのではないでしょうか。今回はその点をまとめていきます。 Redash をどこに立てれば良いか？# 身も蓋もありませんが、ご自身が一番慣れた Docker の PaaS 上で動かすのが良いと思います。 AWS EC2 や GCE などの、非 Docker 環境は運用負荷がそれなりに発生するため、避けたほうが良いでしょう。アップグレードでハマったり、ストレージ使用量 100% になるのはある
なぜいま Heroku なのか - Qiita
開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
