Q&A
あ、対策はあくまで例です。
サクッと突破されるんで、いくつか組み合わせる必要がありますし。
お世話になります。PHPとMySQLで、オリジナルの「いいねボタン」の実装を進めているのですが、ある方から以下のような指摘を頂戴し、皆様の意見を伺えればと、質問させて頂きました。
会員登録制のサイトで、会員のみが押せるボタンであれば良いが、非会員でも押せる場合、悪意あるユーザがツールを使った場合、秒間1000回とかおされるとDBかサーバーが落ちてしまう。なので非会員でも押せるようにしたいのであれば、DBではなくファイルで管理するようにした方が数倍も負荷が抑えられる。
というものでした。
データは、１いいね毎に行数が増えるものではなく、数値を書き換えるもの（押されたとき「４」いいねだったら、「５」に書き換えるもの）ですが、この程度のデータ管理であればやはりファイルで行った方が宜しいのでしょうか？
また、今回の件含め、ファイルでデータを監視瑠つ際のメリット・デメリットもアドバイス頂けると助かります。
DBが便利なので、つい使いたがる節があるもので・・・
お忙しい中恐縮ですがアドバイスのほど、よろしくお願いいたします。
回答7件
0
データは、１いいね毎に行数が増えるものではなく、数値を書き換えるもの
基本的にはこの機能はだめです
イナズマイレブン人気投票五条事件や同ポケモンコイル事件など
不特定の人間がボタンを押したことでインクリメントされる仕組みは
評価を歪めさせることになります。
DBにユーザーIDと文書IDがユニークになるようにいいね情報を
集積してください、それをやらないといいねの取り消しや悪いね、または
5段階評価などデータが集計できなくなります
投稿2017/07/13 04:59
総合スコア114814
0
問題箇所が以下なのであれば、DBだとかファイルだとかあまり関係ないです。
会員登録制のサイトで、会員のみが押せるボタンであれば良いが、非会員でも押せる場合、悪意あるユーザがツールを使った場合、秒間1000回とかおされるとDBかサーバーが落ちてしまう。
ここを対策すべきかと。
機械的に押させるのを回避するんであれば、セッション情報に開始時間を記述し、1秒以上経っていなかったら投稿させないとか。
投稿2017/07/13 03:01
退会済みユーザー
総合スコア0
te2jiさん
ご親切なアドバイスをありがとうございます。
皆さんからのご指摘もありますように、複数回クリックされても交わす施策が必要ということですね。
貴重な対策例も、とてもありがたいと思っております。ありがとうございました！
本論ではないので、聞き流してもらってかまわないのですが、私が指摘したのは、連続クリック（機械クリック）に対しての回答なので、複数回クリックとは別です。
個人を特定しないサイトでの複数回クリック対策は無理なんで、私が指摘したのとは別物です。
te2jiさん
> 連続クリック（機械クリック）に対しての回答なので・・・
そうですね。コメント中にも「1秒以上経っていなかったら投稿させない」とアドバイス頂いておりますね。コメントに「機械的に押させるのを回避」と書かれていますが、このような視点もとても大切だと教えられた気がします。ありがとうございました。
0
phpでDDoS対策、総当り対策、連続アクセス制限 - Qiita
同一IPによる連続アクションを一定時間ブロックする - Qiita
上記の記事は考え方の参考になるので読んでおくべきです。
投稿2017/07/13 04:07
編集2017/07/13 06:10退会済みユーザー
総合スコア0
0
ベストアンサー
悪意あるユーザがツールを使った場合、秒間1000回とかおされるとDBかサーバーが落ちてしまう。
⇒接続できなくなるユーザや処理待ちのユーザは出てくるかもしれませんが、
基本的には落ちないと思われます。
この程度の悪意ツールであれば、仮に落ちても再起動で済むかな、と。
なお、秒間1000回に対する対策も色々ありますが、
PHP内や.htaccess(webconfig)、サーバーのアクセス制限等で対策するのが良いかと思います。
セッション情報やJavaScriptでの対策でも良いですが、
セッション情報もJavaScriptも編集できてしまうので、
悪意あるユーザとのいたちごっこになります。
DBではなくファイルで管理するようにした方が数倍も負荷が抑えられる。
⇒この指摘はお門違いです。
まぁ、最大限譲歩すると、
「ファイル管理であれば、ファイルを開いている間は誰も編集ができないから、
連続クリックはできないだろう」
という考え（間違ってます）なのかもしれません。
おそらく「ある方」というのは、質問者さんの目上の方と推測するので、
やんわり伝えなければならないのかもしれませんが、
「ファイル管理の場合、ファイルを開いている間は誰も編集ができなくなるので、
悪意のあるユーザがファイルをロックしている間、
悪意のないユーザがファイルを編集できなくなり、
いいねの回数の正確さが欠けます。
また、会員の場合、1つのコンテンツに対して、１会員あたり１いいねまでの場合、
ファイル管理だと管理が難しいですが、
ＤＢで管理することで、制御する事が出来ます。
また、ＤＢ管理であれば、
悪意あるユーザのＩＰ等も一緒に登録する事で、
2回以上のクリックを防いだり、あとでカウントを削除する事ができます。
また、悪意あるユーザが登録中に、
悪意のないユーザが登録しようとしても、
待機状態になるだけなので、悪意あるユーザのロックが解除された段階で
いいねがカウントされるので、やはりＤＢ管理の方が良いです。」
と、これくらい丁寧に言わなきゃいけないかもしれませんね。
「ある方」はＤＢに対して信頼がない（知識がない）ようなので、
「ＤＢの中身を閲覧・編集するには・・・」とその辺の知識も伝える必要があるかもしれませんね。
１いいね毎に行数が増えるものではなく、数値を書き換えるもの（押されたとき「４」いいねだったら、「５」に書き換えるもの）ですが、この程度のデータ管理であればやはりファイルで行った方が宜しいのでしょうか？
⇒その場合でも上記の同時処理の問題上、ＤＢの方が良いと考えます。
まぁ、悪意あるユーザの件数を計上したままにするのであれば、
いいねの件数自体に、そんなに意味はないようなので、ファイル管理でも良いかもしれませんが。
なお、「悪意あるユーザ」の議論が出てきてしまっているので、
１いいね毎に行数が増える設計の方が良いかもしれません。
あと、管理の仕方的には、いいねの数を操作したいようにも受け取れましたが、
その場合もＤＢ管理で実際のいいねの数と操作の数の2項目を持てば良いのでは、と思ってます。
ファイルでデータを監視する際のメリット・デメリット
○メリット
・ＭｙＳＱＬが落ちた時、再起動中に閲覧ができる。（ほぼメリットとしてとらえられない）
・管理者側の閲覧・編集がＤＢより楽（誰でもできる）。
○デメリット
・誰でも開く事が出来てしまう。（ファイル権限等で防ぐことはできますが）
・管理者側が簡単にファイルを開いてロックし、データ不整合やエラーが発生する。
・同時編集によるファイル破損の可能性がある。
・ある程度の件数・容量以上のデータを管理できない。（開くのにも時間がかかる）
○テキストファイルで管理する用途
・Ｒｅａｄｍｅテキストファイル
・開発中のデバックログ等（ＤＢの方が良い場合もあります）
・環境設定データ群（他の方法で管理する方が良い場合もあります）
etc...
○テキストファイル管理が適さない用途
・リレーションが発生するもの全て
・編集が頻繁に行われるもの
・データ・容量が大きいもの
etc...
DBが便利なので、つい使いたがる節がある
⇒まったく問題ないです。
投稿2017/07/14 03:39
編集2017/07/14 03:41
総合スコア760
tomari_performさん
ご親切な書込みをありがとうございます。
長文でのとても分かり易い説明、そしてメリットデメリットまで書いていただき、私のようなレベルには、考え方としてとてもありがたく感じております。ありがとうございました！
横から失礼します。セッション情報が編集できるっていうのは、どういったケースを想定しているのでしょうか？
セッション情報が編集できるという言い方は正確にはまずかったですかね。
クッキー情報を編集できる、セッションをクリアできる、
ブラウザの脆弱性を利用できる等の方が良いかもしれません。
とはいえ、ここで悪意あるユーザに対する対策や悪意のある方法を記載するのも
本筋から少しずれてしまうので、参考ＵＲＬだけ載せておきます。
[ＩＰＡ 安全なウェブサイトの作り方]https://www.ipa.go.jp/security/vuln/websecurity.html
新版（改訂第7版）
安全なウェブサイトの作り方 （全115ページ、3.67MB）
セッションに関しては、上記ＰＤＦファイルの Ｐ１８ あたりに記載があります。
0
DBではなくファイルで管理するようにした方が数倍も負荷が抑えられる。
が、理解できないのですが、負荷が問題ならNoSQLデータベースは検討しましたでしょうか。
FacebookのApache Cassandraやニコニコ動画のRedisが有名です。
どちらも基本的にデータをインメモリで操作するため非常に高速です。
あと、インメモリという点ではMySQLでもMEMORYストレージエンジンがあります。（MEMORYは使ってみてクセが強くて難しいと個人的には感じました…）
投稿2017/07/13 09:41
総合スコア372
shoko1さん
ご親切な書込みをありがとうございます。MySQLばかりに目が向いてしまいがちですが、色々なものがあるのですね。ご自身の感想含め、貴重なご意見ありがとうございました。
負荷に話を絞れば、Redis 等をお勧めするのが妥当です。
連打そのものの可否の話と、負荷の話は別ですよね。連打にしか焦点をあてない回答が目立ちます。なぜだろう。
DB負荷が問題になるほどの大規模サイトの経験があるヒトが少ないのだと思います。なので自分がわかる連打の話となるのかと。ちなみにFacebookのいいねは全世界から秒間60,000回押されてたりします。
0
その指摘は少々ずれた感じがします
ＤＢに対する負荷の問題は、いいねボタンのような機能に限りません
また、同一ユーザもしくは同一クライアントから大量にいいねボタンを押せるような状態は、機能的な問題があると思います
ご質問中に見えている課題は２点
・ユーザアクセスによる負荷対応をどうすべきか
・同一ユーザもしくは同一クライアントからのいいねボタン連打対応をどうすべきか
というわけで、ＤＢの種類がファイルかＲＤＢかは問題では無いと思います
DBではなくファイルで管理するようにした方が数倍も負荷が抑えられる
とおっしゃることの技術的な理由を解説してもらっていますか？
どのような意図があって「ファイルがよい」とのことなのか、再度確認してみてください
投稿2017/07/13 04:28
総合スコア3111
takitoさん
ご親切なアドバイスをありがとうございます。
やはり、同一ユーザから大量にイイネを押されない対策をすべきということですね。この度、特に詳細な説明がないまま、「（いいねボタンを例にとりながら）DBよりファイルでのデータ管理が良いことがある」的な話を伺い、ここteratailにて質問した次第です。きちんとした施策を持っていればで、データ管理はDBに落ち着くという事でしょうか。貴重なご意見ありがとうございました！
0
ファイルで管理することで回避できる問題でしょうか？
そもそも1秒間に100万回押されたら？とかイタチごっこでダメだと思います。
処理的にもファイルロックして、開いて、読み込んでインクリメントして、書いて、保存？
無駄な気しかしませんが。。。。
ストレージの媒体が分かれることで、同期をとってバックアップする必要もあります。
DBでトランザクション無しのインクリメント処理でいいんじゃないかと。
悪意のあるユーザってそんなに暇じゃないと思いますが。
それに普通いいねって1人は1000回押せたらダメなんじゃないですか？
ファイルに回数だけ保存するとできませんよね。機能的な問題を抱えているような気がします。
投稿2017/07/13 04:05
総合スコア1400
szk.さん
ご親切なアドバイスをありがとうございます。
複数回クリック出来ない仕組みを用意すれば、DBで管理すべきということでしょうか。貴重なご意見ありがとうございました。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/13 05:37