シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
Rails 4 へのアップグレード時に遭遇した問題 - クックパッド開発者ブログ
技術部の鈴木 (@eagletmt) です。 クックパッドでは8月に本体アプリケーションや API サーバ等で使われている Rails のバージョンを 3.2 から 4.1 へ順次アップグレードを行いました。 アップグレードは主に松田さん (@amatsuda) と私で進めました。 この記事ではアップレードの際に遭遇した問題の一部を紹介します。 MySQL strict mode の有効化 MySQL を使っている場合、Rails 4.0 からデフォルトで @@SESSION.sql_mode = 'STRICT_ALL_TABLES' が最初に実行されるようになりました (Ruby on Rails 4.0 Release Notes) 。 これを無効化するために database.yml で strict: false という設定が用意されています。 しかし、同じく Rails 4.0
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
