質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

Ruby on Rails 4

Ruby on Rails4はRubyによって書かれたオープンソースのウェブフレームワークです。 Ruby on Railsは「設定より規約」の原則に従っており、効率的に作業を行うために再開発を行う必要をなくしてくれます。

Q&A

1回答

1865閲覧

5~10万アクセス/時間のサイトにおいて、counter_cacheかバッチ処理かで集計処理をしようと思っておりますが、判断基準が定まらず困っております。

kento2543

総合スコア163

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

Ruby on Rails 4

Ruby on Rails4はRubyによって書かれたオープンソースのウェブフレームワークです。 Ruby on Railsは「設定より規約」の原則に従っており、効率的に作業を行うために再開発を行う必要をなくしてくれます。

1グッド

3クリップ

投稿2016/05/25 17:23

編集2022/01/12 10:55

1時間に5~10万アクセスくるサイトを運営しております。
今回、新たな要件として、レコード数の集計をする機能をつけることになりました。

集計というと、バッチ処理でやるイメージがあったのですが、
今回の要件上、可能なかぎりリアルタイムにレコードを集計してほしいとのことです。
(例外として、リアルタイムにこだわりすぎて、サーバーを落とすぐらいなら、最悪1時間に一度の間隔までなら大丈夫とのことです。)

※バッチ処理といっても、ログとして出力したデータを数分毎に実行し、最終的にはレコードを作成します。
そのため、集計というより、レコードの作成と、そのレコードの総数を親クラスのカラムに保存するという意味合いです。

ArticleとCommentというのがあれば、 Commentのログを出し続けて、バッチ処理実行時に、ログからCommentのレコードを作成し、 Articleにある、comment_countのカラムを更新するという作業です。

また、今回は、Ruby on Railsで実装しているため、バッチ処理以外に
counter_cacheを用いて実装することも視野に含めております。

counter_cache
http://www.lanches.co.jp/blog/2331

私の考えでは、「可能なかぎりリアルタイムでレコードを集計する」という要件上、counter_cacheの方がいいのではないかと思いました。

しかし、このような要件の実装をしたことがないため、負荷がかかった時に本当に大丈夫なのかという点が不安で質問させていただきました。

※尚、現在はAWS上で運用しております。

質問点

  1. バッチ処理かcounter_cacheならどちらの方が今回の要件に向いてますか?

  2. 仮にcounter_cacheで実装した場合、最悪、非同期処理(resqueなどを用いて)とかで対処していきたいのですが、そういうことはかのうでしょうか?

調べていると、こういうgemがあったので、可能なのかなと思ったのですが、参考記事が少なく少々不安ではあります。
https://github.com/agibralter/ar-resque-counter-cache

  1. counter_cacheで実装した際で、かつ、1時間に10万アクセスがあった際に、一般的には負荷に耐えられるのでしょうか?

  2. AWSということもあり、いざとなったらスケールさせて対処しようとも思うのですが、この考えは浅はかでしょうか?(もっと根深い問題やリスクなどがあるのではないかと思いまして)

  3. その他、注意しておいた方が良い点などございましたらお願いします。

このサイトで回答なさってくださる方々にとっては、当たり前な内容かもしれませんが、
どうかご協力頂けますと幸いです。

説明不足の点は補足できますので、何なりとおっしゃって頂ければと思います。
何卒よろしくお願いします。

2016/05/26追加の情報

DBはmysqlをもちいております。

1つのCommentが複数のArticleに関係することはあるのでしょうか?

今の仕様では、複数には関係しません。
1つのCommentが一つのArticleに関係します。

アクセスのうち、Commentの書き込み(集計の処理対象)は何割ぐらいを占めるのでしょうか?

Commentの書き込みは全体の8割程を占めます。ここがメインの業務と言って過言ではありません。むしろ他の部分は負荷が少ないです。

counter_cacheだとデットロックのリスクがある

デットロックの問題を補ったcounter_cultureというgemがあるみたいです。
http://qiita.com/tachiba/items/797ea74e7eeb7f32f886

こちらを実運用した経験がないので、あるからといって何ともいえないのですが。

WebサーバとDBサーバは別ですか?

別です。

また、DBの負荷とWebアプリの負荷どちらを懸念されていますか?

今のところはそういう成約はないです。
また、負荷が高くなった際にスケールしても問題ないという許可は頂いております。

ikuwow👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

coco_bauer

2016/05/26 01:46

1つのCommentが複数のArticleに関係することはあるのでしょうか? アクセスのうち、Commentの書き込み(集計の処理対象)は何割ぐらいを占めるのでしょうか? アクセスする人の内、書き込みをする人は数%程度という記事を見た記憶があるのですが、担当されるサイトではどうでしょうか? この辺りの数値をおおまかにでも把握しておかないと現実離れした設計になりかねません。  
kento2543

2016/05/26 01:55

ご質問ありがとうございます。アクセスする人の内、書き込みをする人の割合などは設計を考える上ではとても重要な情報なのに、欠如しておりました。質問本文下部に追加させていただきました。何卒よろしくお願いします。
guest

回答1

0

すみません。
5)のみについての助言となりますが、ご容赦を。

WebサーバとDBサーバは別ですか?
また、DBの負荷とWebアプリの負荷どちらを懸念されていますか?
負荷については、ソフト的に解決できるものと解決できないものがあります。

「WebサーバとDBサーバが別であれば、特にどちらかのサーバーに負荷を掛けてはいけない」のような制約に従うのが良いと思われます。

  • Webサーバに負荷を掛けては行けない

→集計の際に、DBに頑張ってもらう

  • DBサーバに負荷を掛けては行けない

→集計の際に、Webアプリに頑張ってもらう


サーバを増やすことに特に問題がないのであれば、集計専用のサーバ(DB、アプリケーション入り)を用意すれば、現状のサイトに一番影響がない状況になるのではないでしょうか。
簡単にいうと、「もうなんも考えたくねぇー。今のサーバーに負荷をあんまり掛けなきゃいいんでしょ?w」という解決法ですね。

【新規サーバがやること】

  • 新規サーバーからDBサーバ集計対象のデータを随時(or定期的に)取得し、保持する

→ログデータとのことだったので、追加のデータしかありえないため、差分だけ取得する。

  • 集計は定期的でもよいし、リアルタイムでもよい

→なぜならば、一番負荷がかかるのは集計専用サーバのみだから。

【既存サーバへの影響】

  • 集計データを渡す際の負荷
  • 集計結果を表示するページを作成する際に、新規サーバーへデータをとりに行く必要が出てくる(ちょっとイレギュラー)。

投稿2016/05/26 01:02

koufukurairai

総合スコア64

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

koufukurairai

2016/05/26 01:29

ログデータというのが頻繁にアクセスされるデータであれば、どのDB使っていらっしゃるかわかりませんが、counter_cacheはあまり向いてないかもしれません。 →デッドロックが発生しやすいということは、ログにアクセスしに行く人全てに影響があるため
kento2543

2016/05/26 01:47

ご回答ありがとうございます。 > WebサーバとDBサーバは別ですか? はい、別です。 > また、DBの負荷とWebアプリの負荷どちらを懸念されていますか? 今のところはそういう成約はないです。 また、負荷が高くなった際にスケールしても問題ないという許可は頂いております。 > counter_cacheはあまり向いてないかもしれません 私もこの辺は詳しくないのですが、どうも調べていると counter_cacheのデットロックの問題を補った counter_cultureというgemがあるみたいです。 http://qiita.com/tachiba/items/797ea74e7eeb7f32f886
koufukurairai

2016/05/26 01:56 編集

ダーティーリードしてるかしてないかですよね。これって。 問題は、長い間そのテーブルやレコードを掴んでしまった場合に、実際ページにアクセスしている人に影響がないかだと思うんですけど、詳しいことわからないので、私から言えることはこれくらいが限界ですね。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問