なぜいま Heroku なのか - Qiita
開発中のサービスに Heroku を採用した経緯を社内で周知するために書いた文章なんですが、ついでに Qiita にも貼っておきます（ちなみに Heroku の回し者ではないので悪しからず）。 従来、Heroku は日本で使うにはレイテンシの問題で本番環境での利用が避けられることが多かった これは Heroku の Common Runtime には Tokyo region がなく US 等のサーバーと通信するとレイテンシが大きいため1 実際、Wantedly 社なんかもレイテンシを理由に Heroku から AWS に移行している だが、Service Worker の先読みと Fastly（のような instant purge 可能な CDN）の登場により、このレイテンシの影響は極小化された のではないか 多くのリクエストは Fastly のエッジサーバー からレスポンスを返せるはず
Heroku x Rails のサービスを本番運用する際に確認したいこと - ボクココ
ども、@kimihom です。 私は Heroku に Rails サーバーを立ててサービスを運用している。これまでの経験を元に、定期的にチェックしておきたい指標とか項目をまとめてみる。今後のサービス開発などで参考になれば幸いだ。 サービス構成 現在の構成はというと、以下のような感じである。 Ruby 2.4.1 (執筆時点で最新) Ruby on Rails 4.2.8 Heroku Standard 1X Dyno * 4 Heroku Postgres Standard 0 Heroku Redis Premium 0 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
Rails アプリのインフラを AWS から heroku に移行した話 - sakagami memo
先日、自分の携わっている Rails アプリのインフラを AWS から heroku に移行しました。 移行時にハマった点や、その後 使い始めてみて便利だった点を列挙。 移行した主な理由としては、開発が少人数体制のためインフラは気にせずコードを書くことにのみ集中して、限られたリソースを有効活用させるため。 また、移行するにあたり以下のスライドも参考になりました。 Wantedlyを2年間Herokuで運用した話 from Yoshinori Kawasaki 移行時の手順・ハマったところ 基本的な手順 基本的な手順は簡単。 Heroku Toolbelt をインストールして、 heroku login でログイン、 heroku create で heroku 上に新しいアプリケーションを作成した後、 git push heroku master で デプロイ。 heroku open
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
