Heroku で本番運用を続けていくために必要なこと - ボクココ
ども、@kimihom です。この記事は Heroku Advent Calendar 2017 の 20日目です。明日以降が豪華メンツで今から楽しみですね。 さて、今回は Heroku で本番運用を続けていくって方のための情報をシェアしたいと思う。自社サービスで Heroku を使い続けている事例ってのがあまり出て来ないので、積極的に開示していきたいと思う。 ※ 本記事は、今年書いた Heroku に関する記事のまとめ的な立ち位置として読んでいただけたら幸いだ。 Heroku で本番運用の実績 私は Heroku で 2年間以上、本番環境でサービスを動かし続けて来た。その間、Heroku 起因でトラブルに遭ったことは1日くらいで、他は安定的に動き続けてくれた。その1日も、いつもよりレスポンスが遅くなっていた程度で、なんとかなったので助かった。 さて、私がなぜ Heroku にこだわり続け
【Pythonで定期処理】 Cloud9を利用して、Seleniumでherokuから定期実行する
Cloud9というIDEを利用して、PythonからSeleniumを利用し、あるサイトでいいねを自動化するプログラムを作った。 これを定期実行を行いたい。検索してみると、crontabを使えば定期実行ができるようだが、cloud9上では実行できないらしい。 ほかの代替案を考えたとき、heroku schedulerを利用して定期実行を行えるのではと思い、やってみたらうまくいった。その時の作業ログを残しておく。特に詰まったところ。 手順としては ・bottleを使ってherokuにdeploy ・heroku schedulerに接続 ・heroku schedulerに実行プログラムを入力 pythonプログラムをherokuにdeployする 実行したいプログラムをherokuにdeployする。herokuにdeployするところまでは下記参照。これ通りにやれば、ひとまずheroku
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 もちろん他にも使っているのはいろいろあるけど、ベースは上記のように至って標準な作りになっている。これによってインフラ周りでトラブルが起きることを最小限にとどめている。今現在でもインフラ周りで特別に問題になっていることはないので、これからも 上記の構成を使い続けていく予
社内開発で使ってるSinatra + Datamapper + Heroku + Dockerの簡易テンプレート for Mac - Qiita
社内開発で使ってるSinatra + Datamapper + Heroku + Dockerの簡易テンプレート for MacRubySinatraHerokuDockerDataMapper なぜ？ 社内システムは、なるべくクラウドの既製品を使うという方針でIT部を運営していますが、ちょっとしたバッチ処理、自動監視、データ転送・変換処理なんかは自分で開発したほうが早かったりします。 そういった処理を実現するために、社内サーバを用意するのは面倒なので、Herokuを使ってサクっと作ってしまおうということを繰り返してきた結果、なんとなくテンプレートのようなものができたので、ここに公開しておきます。 なんでDockerを使うの？ 自分のMacの環境をできるだけ汚さないようにするためです。特にMacの場合はRubyの環境がmacOSのバージョンアップの度に大きく変わって、つらい思いをしたのでD
なぜ AWS をやめて Heroku を選んだのか - sakagami memo
仕事であるアプリケーション開発を担っているのですが、 当初 AWS を用いて1人で運用していたのが、現在は Heroku のプラットフォームに移行し、チームとして6人で開発を行っている状況になりました。そこに至るまでの経緯とその際の運用についてご紹介したいと思います。 もちろんそれぞれの開発の状況に応じて、判断は変わってくるかと思いますが参考になればと思います。 エンジニア 1人 もともと私が関わる以前のそこでの開発は外注していました。運用を引き受けることになったのですが、 ある程度 形になっているアプリケーションを1人で運用するには不安が大きく、実装したい機能が日々 増えていく中で、インフラ面で時間をかけていて満足にコードを書けない状況は非常にわずらわしい ものでした。 小さなスタートアップという会社の中で、開発の施策が次々と進められない状況はまずい と感じ、Heroku の導入を検討し
diary/2016/03/30/インフラの引っ越しを行いました
以下、ざっくり説明していきたいと思います。 > Web Server/Workerの移行Web Server/Workerの移行 従来はHeroku(US region)にサーバがあったため、日本からのアクセスの場合チューニングをどう頑張っても数百msの遅延がありました。これをAWS(Tokyo region)に移行することで、ページを表示するのに要する時間が1/2 ~ 1/3まで改善されました。 > DockerDocker 移行開始直後は自分が不慣れなこともあり、このタイミングでDockerを採用する気はありませんでした。しかし、実際にECS上でのデプロイを検証したり、Dockerについて学習するうちに移行のイメージが掴めてきたのでDockerを採用することにしました。 もともとHerokuで動いていて The Twelve-Factor App にほぼ沿っていたので、やってみるとDo
Heroku と Amazon Lambdaを連携して、バックグラウンドジョブを実現した - ボクココ
気にはなってたAmazon Lambda をようやく使えたのでシェア。 Heroku はご存知の通り、Web とは別のWorker プロセスを立ち上げようとすると、その分プランに応じて倍増する。バックグラウンドジョブがそこまでないシーンで、常にWorkerプロセスを立ち上げっぱなしにするのは非効率。必要な時に必要な時だけバックグラウンドジョブを実行できる環境がないのか、考えていた。そこで登場するのが Amazon Lambdaだった、って訳だ。Amazon Lambda の魅力は何と言っても便利なだけでなく、1 か月あたり 100 万の要求と最大 3.2M 秒のコンピューティング時間が無料である、という点にある。素晴らしい。 今回やりたいこと CSVなどのデータをアップロードして、それらを一括でHeroku Postgres の DBにデータを入れたい。それらの処理は時間がかかるので、バッ
私が実施する Heroku x Rails の高速化をまとめてみた - ボクココ
Herokuの欠点は、Tokyoリージョンがないため、ネットワークによる遅延が気になる と言われている。どの程度による遅延が気になっているのかは人によると思うが、Herokuを最大限に高速化させるために私がやっていることをまとめてみた。 これを実施すれば、Herokuが遅いとはあまり思わなくなると考えている。 Asset Sync を利用する [追記（重要）] Asset Syncを利用するのは公式で止めるよう勧告が出ている。CloudFrontを利用する方法が推奨されている。以下の内容は古いのでご注意を。 ーーーーーーーーーーーー Asset Syncは、Amazon S3に画像やCSS/JavaScriptを置き、各アセットのパスの向き先をそちらにかえてくれるgemだ。これを利用しないと、HTMLとかに置いた静的コンテンツが全てHerokuにアクセスしてしまうため、Herokuサーバー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker swarmで作る社内heroku: yadockeri - Qiita