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

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

ただいまの
回答率

88.10%

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

受付中

回答 1

投稿 編集

  • 評価
  • クリップ 3
  • VIEW 1,280

score 172

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

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

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

5) その他、注意しておいた方が良い点などございましたらお願いします。
このサイトで回答なさってくださる方々にとっては、当たり前な内容かもしれませんが、
どうかご協力頂けますと幸いです。

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

 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アプリの負荷どちらを懸念されていますか?

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

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

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

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

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • coco_bauer

    2016/05/26 10:46

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

    キャンセル

  • kento2543

    2016/05/26 10:55

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

    キャンセル

回答 1

+1

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

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

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

  • Webサーバに負荷を掛けては行けない
    →集計の際に、DBに頑張ってもらう
  • DBサーバに負荷を掛けては行けない
    →集計の際に、Webアプリに頑張ってもらう

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

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

  • 新規サーバーからDBサーバ集計対象のデータを随時(or定期的に)取得し、保持する
    →ログデータとのことだったので、追加のデータしかありえないため、差分だけ取得する。
  • 集計は定期的でもよいし、リアルタイムでもよい
    →なぜならば、一番負荷がかかるのは集計専用サーバのみだから。

【既存サーバへの影響】

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/05/26 10:29

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

    キャンセル

  • 2016/05/26 10:47

    ご回答ありがとうございます。

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

    はい、別です。

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

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

    > counter_cacheはあまり向いてないかもしれません

    私もこの辺は詳しくないのですが、どうも調べていると
    counter_cacheのデットロックの問題を補った
    counter_cultureというgemがあるみたいです。
    http://qiita.com/tachiba/items/797ea74e7eeb7f32f886

    キャンセル

  • 2016/05/26 10:54 編集

    ダーティーリードしてるかしてないかですよね。これって。

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

    キャンセル

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

  • ただいまの回答率 88.10%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

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