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上で運用しております。
質問点
-
バッチ処理かcounter_cacheならどちらの方が今回の要件に向いてますか?
-
仮にcounter_cacheで実装した場合、最悪、非同期処理(resqueなどを用いて)とかで対処していきたいのですが、そういうことはかのうでしょうか?
調べていると、こういうgemがあったので、可能なのかなと思ったのですが、参考記事が少なく少々不安ではあります。
https://github.com/agibralter/ar-resque-counter-cache
-
counter_cacheで実装した際で、かつ、1時間に10万アクセスがあった際に、一般的には負荷に耐えられるのでしょうか?
-
AWSということもあり、いざとなったらスケールさせて対処しようとも思うのですが、この考えは浅はかでしょうか?(もっと根深い問題やリスクなどがあるのではないかと思いまして)
-
その他、注意しておいた方が良い点などございましたらお願いします。
このサイトで回答なさってくださる方々にとっては、当たり前な内容かもしれませんが、
どうかご協力頂けますと幸いです。
説明不足の点は補足できますので、何なりとおっしゃって頂ければと思います。
何卒よろしくお願いします。
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アプリの負荷どちらを懸念されていますか?
今のところはそういう成約はないです。
また、負荷が高くなった際にスケールしても問題ないという許可は頂いております。