AuroraのフェイルオーバーとRailsのコネクションプールを共存させる方法 - Qiita
はじめに こんにちは、ここ最近AzureからAWSに主戦場を移したalfaです。 AWS なので早速地雷を踏みました。 具体的には、Auroraでフェイルオーバーが発生した際にDBへ書き込みが出来なくなってしまい、アプリが再起動されるまで正しく動かなくなってしまうといった症状です。 何が起こったのか AuroraのフェイルオーバーとActiveRecordのコネクションプールの仕組みは相性が悪かったという事ですが順を追って説明していきます。 クラスターに障害が発生した場合、クラスタエンドポイントのDNS(CNAME)を書き換えることで参照先を切り替える仕組みです。 クラスタエンドポイントをDBの接続先に設定したRubyアプリケーションがあったとき フェイルオーバーしてマスターが切り替わると... アプリケーションは再接続するだけで昇格したマスターを参照できます。 ウルトラハイパーメチャクチ
RailsとAmazon Aurora利用時のフェイルオーバー問題を解決 - matsukaz's blog
tl;dr RailsのコネクションプールとAmazon Auroraのフェイルオーバーの仕組みは相性が悪く、フェイルオーバー時に致命的な問題が発生する 解決方法の1つは、コネクションプールを使わないこと ただし、都度接続だと接続コストがかかる New Relicなどを使ってる場合は、自分の実装以外で使ってるコネクションまで都度接続になってしまう 別スレッドでDB操作を行っている場合、処理中であってもそのスレッドのコネクションまで切断されてしまう（Railsのコネクション破棄がプロセス単位のため） コネクションプールを活かしたままこの問題を解決できたので、その方法をご紹介します。ちなみにRails 4.2の話。 RailsとAmazon Aurora利用時のフェイルオーバー問題とは 詳しくはこちら qiita.com 問題が発生する状況をまとめると以下の通りです。 Amazon Auror
new, create アクション
new, createアクション この章ではCRUDのC（Create）にあたる新規登録を行うための2つのアクション、newとcreateについて説明していきます。 説明に使うアプリは前の章でつくったものを引き続き使います。 概略 前の章での「CRUD遷移図」において、newとcreateはこの部分になります。 新規登録は2つのアクションで構成されます。処理の流れは以下のようになります。 ステップ1: newアクション（新規作成画面） newアクションが実行され新規入力画面を表示します。ここで本のタイトルとメモを入力します。Create Bookボタンを押すと、次に画面のないcreateアクションが実行されます。 ステップ2: createアクション（画面なし） つづくcreateアクションで、前のステップで入力されたタイトルとメモで本のデータを新規登録します。 この流れを詳しく説明してい
Railsの開発効率をあげる - Pryを使ってRailsのコンソールをパワーアップ & デバッグをする - Rails Webook
Pryとは Rubyには、標準で付属されているirb(Interactive Ruby)というツールがあります。 consoleで、irbと入力するとirbが実行されます。 そこで、対話的にRubyの式を入力・実行することができます。 $ irb irb(main):001:0> 1 + 2 => 3 そして、Pryはirbの代替となるパワフルな対話ツールです。 なにがパワフルかというと次のようなことができます。 ドキュメントが見れる シンタックスハイライト デバッグができる（binding.pryをソース二記載するとブレイクポイントになる） $ pry [1] pry(main)> ls # 現在のスコープの変数とメソッドを表示 self.methods: inspect to_s locals: _ __ _dir_ _ex_ _file_ _in_ _out_ _pry_ 動作確認
RailsでHello, world!を表示してみる - yk5656 diary (旧)
CentOSにPassenger/Ruby2.0/Rails4.0をインストールしてみる(rbenv版)の続き RailsでHello, world!を表示してみる。 とりあえずHello, world!を表示してみる railsのコマンドでコントローラを作成する。 今回はsampleという名前のコントローラにする。 $ rails generate controller sample create app/controllers/sample_controller.rb invoke erb create app/views/sample invoke test_unit create test/controllers/sample_controller_test.rb invoke helper create app/helpers/sample_helper.rb invoke te
Rails4をはじめよう
はじめに このコラムは、 2014年12月5日から始まった「Rails4技術者認定シルバー試験」の推奨教材となった「Ruby on Railsガイド」に沿って、Ruby初心者の筆者がリアルタイムで勉強をしていくコラムです。全12回を予定しています。勉強する上でつまずいた点やその回避法、他のプログラミング言語や職業経験に基づいたアドバイスなども紹介する予定です。RubyやRailsに興味のある方は、ぜひ一緒に勉強してみませんか。 今回参照するガイドはこちらです。 はじめにRailsをはじめよう それでは早速チュートリアルを開始しましょう。 クラウド上に開発環境を構築 何はともあれ、まずは開発環境を揃えないといけませんよね。今回のチュートリアルで一番時間がかかったのが、実はここです（笑）。ガイドには必要なものがさらっと書いてあるだけですが、具体的な手順を把握するために、何度も何度もGoogle
Money Forward, Inc.
We are Money Forward, the largest fintech company in Japan. Founded on May 18th, 2012 we launched our personal financial management product Money Forward ME in 2013, and are now helping our user base of over 12 million see and understand their money situation. At our core, we strive for the well-being of everyone in society by solving concerns with money faced by individuals, businesses, and socie
UnicornとかRainbows!とかの話 : As Sloth As Possible
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった？ なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
rails/Unicornを本番環境で運用する設定 – 技術メモ
概要 unicornを本番環境でちゃんと運用するための設定をまとめた。 基本的には、 RailsサーバUnicornを飼いならす! 運用時の便利技と同じ。 設定 1. 必要なファイルを以下のパスに配置する 以下のファイルをダウンロードして同じパスに配置する config/unicorn.conf.rb unicorn設定ファイル bin/unicornctl.sh unicornの起動/停止/再起動/リロードを行うスクリプト lib/unicorn_manager.rb rubyからunicornを操作するためのクラス bin/fat-memory-unicorn-killer.rb 子プロセスのメモリ使用量監視＆再起動スクリプト 2. monitでunicornを監視する 基本的にunicornは一度起動したら停止する事はないが、 なんらかの理由でマスタープロセスが停止していたり、 メモ
[Rails] APサーバの比較検証（Puma, Unicorn, Passenger） - Tech Log - s21g
仕事でRailsを使うことになり、APサーバの選定にあたってPuma, Unicorn, Passenger の比較検討を行いました。方法としてはJMeterでAPサーバにデプロイしたRailsアプリケーションに対して負荷をかけられるだけかけるというやり方です。 試験環境 試験の環境としては下記の構成です。 Ruby2.0, Rails4 アプリケーションサーバ：1台（VM） JMeterサーバ：3台（VM） JMeterクライアント：1台（通常の作業PC） サーバ構成 hostanameCPU仮想コア数（Per CPU）MemoryDisk用途 loadtest01248192MB20GBAPサーバ loadtest02114096MB20GBJMeterサーバ loadtest03114096MB20GBJMeterサーバ loadtest04114096MB20GBJMeterサーバ
Ruby on Rails - Unicorn のログローテーション！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... 以前、Ruby on Rails のログ（”production.log”）のローテーションについて記録を残しました。 * CentOS - Rails ログローテーション！ Rails のログだけでなく、Rails サーバ Unicorn のログも放おっておくと肥大化します。そこで、ログローテーションの設定を行なってみました。 0. 前提条件 Ruby 2.0.0-p247, Rails 4.0.0 を想定（動作確認）。 “/var/www/rails/” ディレクトリ配下に “rails_app” という Rails アプリを作成。 １．logrotate 全体設定の確認
アプリサーバー対決 パート1：主なRubyアプリケーションサーバーの機能比較 - Engine Yard Blog
本記事は英語版ブログで公開された記事の翻訳版です。 2013年7月に、米国テキサス州オースティンで開催されたLonestar Ruby Conferenceで、Rubyによるアプリケーションサーバーについてお話させていただきました。その中でいくつかのRubyアプリケーションサーバーのパフォーマンスや、さまざまな状況における挙動の違いを比較しました。この記事では、講演準備として行ったリサーチの中で分かったことをかいつまんでご紹介します。 実際のカンファレンスの録画をご覧になりたい方は、Confreaksで公開されていますのでそちらをご参照ください。テストに使用した簡単な自作アプリケーションはGitHubに、講演スライドはSlideshareにそれぞれ公開しています。 このリサーチは、Passenger 4のパフォーマンス評価以外すべて2013年7月に行ったものなので、情報が多少古くなっている
オレオレRailsアプリを支えるインフラの作り方 - くりにっき
はじめに これは Ruby on Rails Advent Calendar 2014 - Qiita の19日目です 18日目 @yancya さんの Rails でシングルじゃないテーブル継承 - Qiita でした 19日目：オレオレRailsアプリを支えるインフラの作り方 最近では Heroku などのPaaS*1 も普及してインフラのことを知らなくても簡単にアプリを公開することができるようになりました。 しかしトラブルシューティングやパフォーマンスチューニングなどを行うにはアプリケーションコードだけで完結することは少なく、全体像を把握する必要があります。Railsアプリケーションの裏でどんな構成で動いているかを知っておくかは重要なのでざっくりと紹介したいと思います。 書かないこと Railsアプリを作る上でのノウハウ 便利なgemや外部サービスの紹介 *2 監視 アラート検知 モ
passegner のドキュメントを読む - おもしろwebサービス開発日記
気になったところだけのメモです。nginx用。 Phusion Passenger users guide, Nginx version サブURIにデプロイする 例えば http://example.com/rails をアプリのトップディレクトリにしたい場合で、 root /websites/phusion;な時。 ln -s /webapps/mycook/public /websites/phusion/rails のようにシンボリックリンクを張って、 passenger_base_uri /rails; を server ディレクティブ内に設定するとおｋ。 passenger_log_level nginxのエラーログファイルにどこまでの情報を書くかを決める設定。 0 error と warning のみ 1 最重要なデバッグ用情報を表示。アドミニストレータ用。 2 デバッグ情報
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails のルーティング - Railsガイド
「Ruby on Railsで簡単で素早くWebアプリを開発する」 第２回 動的ページを作ってみよう
Passengerのアーキテクチャ解説 : sonots:blog
http://blog.usagee.co.jp/2010/11/06/%E4%BC%9A%E5%93%A1%E5%88%B6%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E4%B8%80%E8%A1%8C%E3%81%A7%E4%BD%9C%E3%82%8B%E7%82%BA%E3%81%AE-rails3-%E7%94%A8%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3