掲示板 - 管理人様へ質問です（ID:76）｜口コミ風俗情報局

今回初投稿の方が★１つの体験談掲載されているけど方針が変わったのでしょうか？

>>3月9日さん

申し訳ございません。

早速ですが、該当の体験談を不掲載にさせていただきました。

ご指摘、ありがとうございましたm(__)m

◯◯◯◯◯◯◯◯◯◯が酷いのに、ｺﾚｶﾗや割引に多々載っていて見にくいです。
もっと優良店のｺﾚｶﾗや割引を見たいのに、悪質店の広告規制を願いたいです。

>>カーチャ様さんへ

リニューアル後は、表示するお店をフィルタリングできる機能を追加する予定です。

２～３ヶ月お待ちいただけないでしょうか。

運営側の状況は、『今後の変更予定』というコンテンツで見ることができます。

よろしくお願いいたします。

＞マスター様

PHPですよね、BDにフラグを持ってるようですから
直ぐに該当店にフラグを立てるだけですよね。

スクリプト（PHP）だってクエリですから割引も方もすぐに
対応できるはずですよね。

>>七誌さんへ

『今後の変更予定』というコンテンツをご覧いただけましたでしょうか？

現在、情報局のプログラムを１から書き直している最中です。

今まで１台のサーバーで動作していましたが、今後は複数台のサーバーで分散処理をする仕様に書きなおしています。


それと、単にプログラム上の問題ではありません。

もし貴方がお店を経営していて、いきなり運営側から一方的に悪質店としてフラグをつけられたらどう思いますか？

もしその運営側の判断が間違っていたら、どのように責任をとるのでしょうか？

悪質店とレッテルを貼ることは威力業務妨害や誹謗中傷に該当します。

現実問題として、ある店を独断と偏見で悪質店とレッテルを貼ってしまうことはできないことであるとご理解いただけますでしょうか。


ではどうやって実現するのか？

悪質店マークをつけるのではなく、優良店マークをつけるのです。

優良店マークをつけるのは、どの法律にも抵触しないはずです。

しかし、優良店マークをつけるにしても、優良店の基準をはっきりさせないといけません。

優良店マークをつけるかつけないかを運営側の独断と偏見で決めてしまっては、お店側も納得しないでしょう。

情報局の「体験入店速報」や「これから遊べる娘」、「イベント・割引情報」などは、お店側の投稿から成り立っています。

お店側が納得しなければ、上記のコンテンツの投稿がなくなり、情報局は成り立たなくなってしまうと思います。


ですから、悪質店の広告規制を、現実の世界で実現可能なレベルで実現するためには、

まず、情報局のリニューアルを完了させること。

次に、お店側も納得できて、なおかつ、不正や穴のない優良店の基準を制定すること。

その優良店の基準をもって優良店マークをつけることを、お店側に最低でも１ヶ月前から告知すること。

その基準をもって、優良店マークをつけること。

そして表示のフィルタリングに、『優良店のみ表示する』というフィルタを追加すること。

それらの手順をふまなければ、現実問題として、悪質店の広告規制を実現することはできないと考えておりますが・・・

何か間違っておりますでしょうか？

もし私のほうが何か勘違いしているようでしたら、ご指摘いただけたらと思います。

よろしくお願いいたします。

＞マスター様

もう出来てる訳ですよね。
問題は付加分散システム、ラウンドトリップにミラーリングなどと言う技術的なものとは無関係ですよね。しかも別筐体で開発さる訳ですから。

カーチャさんや新宿さんは振替詐欺店舗に対する現在の状態に対してのご意見だったので、直ぐ可能な事をご指摘させていただきました。

私は優先順位が違うように思えてなりません。もしかすると被害者が今にでも発生する状況だと判断した訳です。
優良店基準は、プログラムや付加分散とは別です、それより基準を作る方が最優先と思いませんか？

早くしないと来月、再来月と請求に間に合わず延び延びになる事の方が心配です。
現在のフィルタリングを「優良店と確認できた店舗のみの表示」に変えることと、基準を直ぐにでも作成して公開、配布する事が望まれます。表示されていない店舗様につきましても優良店がある事を明記すれば良いですよね。

私が考えるに「振替詐欺」のみの対応ならそんなに難しい基準ではないと・・・
マジパネ･盗用までを許容とすれば、「別人がこない」を基準にすれば言い訳ですからね。（なら証明は？）＜ごもっとも
例えば桜●リアの写真を指名して桜●リア以外の人物がきたら詐欺でしょう（彼方には他店の嫌がらせかどうか見分ける手段を多くお持ちな訳で、先日は今後のご対応を聞いてみたまでです。被害者は客だけでなく盗用された女性にも及ぶ可能性もあると思います。）何店舗かは彼方自身が確認されてますよね。

責任を誰がとるか？それは彼方運営責任者にあるんです、権利を持ってる彼方が責任を取る義務があると言う事です。
出来なければ、あの崇高な方針は取り下げるべきかと･･･
ちなみに御サイトに対する嫌がらせのつもりはありませんので悪しからず。

ここまで、私もおしゃべりさせられるとは思ってませんでした。（笑）

追伸：詐欺事件の公判によく出てくるのは、恐喝による重加罪容疑です。いわゆる、法律を出して有りもしない内容で脅かす行為は恐喝として訴追されます。知っている事は武器であり防御ですよね。禁止事項に抵触するなら削除していただいて結構ですのでよろしくお願いいたします。

久しぶりに書き込みましたが、パネマジ、別人派遣等は想定内では？
だって風俗店ってそうゆう所な気がします…

>>七誌さんへ

『今後の変更予定』というコンテンツは読んでいただけたのでしょうか？？

情報局のリニューアル（特に負荷分散による高速化）は急務です。

現状のまま、年末年始のアクセス数が急増する時期を迎えると、高アクセスにサーバーが耐え切れず、なかなかアクセスできかったり、最悪の場合、サーバーが頻繁に落ちてしまうようになってしまいます。

一方、今回カーチャ様から提起していただいた問題を要約させていただきますと、『一部のお店からの広告がうざい』ということだと思います。

・アクセスが急増すると情報局が見れなくなってしまう問題

・一部のお店からの広告がうざいという問題

どちらの優先順位が高いでしょうか？

私は、『アクセスが急増すると情報局が見れなくなってしまう問題』のほうが大問題で、優先順位が高いと考えています。

そして、それは七誌さんが思われているほど簡単に解決できる問題ではありません。

単純にミラーリングしただけでは、参照系の処理しか分散できないので、更新系の処理は1つのサーバーに集中させなければなりません。

情報局のような頻繁に投稿がある（更新系処理が多い）Webアプリは、ミラーリングではスケールアウトできないということがご理解いただけますでしょうか？

七誌さんが本当にシステムの知識をお持ちの方でしたら、

・PHP セッション 分散処理
・MySQL 分散処理
・レプリケーション
・Memcached
・Tokyo Tyrant
・Google App Engine
・Amazon EC2
・Microsoft Azure

などの検索キーワードでググって、Webアプリのスケールアウトに関する諸問題と現状についてきちんと理解して欲しいです。

アクセス増加によるシステムのスケールアウトは、IT業界全体の課題であり、まだ標準技術は確立されていません。

各社、現状で安定バージョンがリリースされているシステムをケース・バイ・ケースで選択し組み合わせて、その場をしのいでいるのが現状です。

七誌さんが思われているほど、高アクセスに対するスケールアウトの問題は、簡単に解決できる問題ではないということを理解して欲しいです。

上記の説明を読んでいただいても、まだ、優先順位が違うと思われますでしょうか？

はい違うと考えております。
この問題はコンプライアンスに帰属するもので、常に勘案すべき事項と考えられるからです。
負荷分散などの開発とは全く別工程として切り離せ、かつそれほど時間のかからない作業であるとお話しているつもりでした。
（※コンプライアンスは法的遵守だけでなくもっと大きな意味とご解釈ください。）

その別作業が大変だから対応できないとおしゃられているようでしたので、
今回の処理は、基準作成＞配布（メーリング）＞公開＞施行に、そんなに時間（請求スパン）も要らないのでは無いかと
考えた訳ですが、私の買い被りのようでした。

やはりシステムのお話になってしまうのが残念です、
いかなる負荷にも耐えるシステムはありません、彼方おっしゃる通り最良の選択しかない。私もそう考えております。

私の１行にこんなにご教授していただけるとは思ってませんでしたので感謝いたします。

上げられた項目ですが、内容が分散しているので解釈に戸惑っており、間違えておりましたらお許しください。

更新系を１台に集中させなければいけない理由はないです、
アプリケーション層は分散できますので１台ではなく複数台でも稼動できます。

あとデータベースの分散化に伴うレプリケーション処理でよろしいかと、
ジャストインタイムかマージ系かは更新系処理の各機能別に必要な要件を考えて選択ですよね。

上方３つは開発に前提となるもので、その下は応用された技術（キャッシュサーバーですか）？

セッション...は保存先の条件でしょうかね、特にPHPとは限りません、.net系だと各レベルでも管理できますね、asp,jspでも可能です。
各Ｗｅｂサーバー毎の設定で保存先を指定なので通常は１台に集中させます、ローミング対応など...もありますから。

ミラーリングはロードバランサーによるラウンドロビン方式を採用すればが、前提だったので２台とは限りません。ラウンドトリップではなくラウンドロビンの間違いでした、失礼しました。
私がミラーリングと言った事が誤解を招いたかもしれません、
アプリケーションの同期（アプリケーションの同時配信を想定）と言う事でした。

もうシステムの話は止めましょう、これにて失礼いたします。

優先順位につきましては、もうお返事は結構と言う事で悪しからず。