Geekly Articles each Day

アンチクリック保護システムを書いたように

画像

当社はオンライン広告の分野で活動しています。 約2年前、ついにコンテンツネットワークに組み込まれたアンチクリックプロテクションシステムに幻滅し、その時点で内部使用のために独自のシステムを作成することにしました。

カットの下には、システムの機能に関する多くの技術的な詳細だけでなく、作業の過程で遭遇した問題とその解決策の説明もあります。 システムを見るだけの場合は、メイン画像をクリックしてください。

解決する必要がある最初のタスクは、一意のユーザーの識別でした。
つまり ユーザーがブラウザを変更したり、Cookieをクリアした場合でも、ユーザーを識別する必要があります。
いくつかの検討と一連の実験の後、私たちはCookieだけでなく、そのようなリポジトリを備えたブラウザ用のすべての可能なプラグインのリポジトリにも書き込みを始めました。さて、ささいなこと、サードパーティのCookie、さまざまなJSストレージ。
その結果、ほとんどの場合、ユーザーを識別するだけでなく、コンピューターの特定のデジタルキャスト（OS、画面解像度、色深度、特定のプラグインの有無、ブラウザーによるさまざまなJSストレージのサポート、サードパーティのCookie）も取得します、ユーザーに設定したすべてをクリーンアップしても、ユーザーを高い確率で識別することができます。
この段階では、書く価値のある特別な問題は発生しませんでした。

2番目のタスクは、すべてのユーザーデータをサーバーに転送することです。
最も完全なデータを取得するには、サーバーサイド（PHP / Python / ASP.NET）とクライアントサイドJSの2つのスクリプトを使用します。 したがって、完全なダウンロード、したがってクライアントJSの開発を待つことなく、ページを閉じたユーザーに関する情報も受け取ることができます。 このようなティーザー広告のクリックは通常30％以上であり、それらを考慮する他のシステムは見つかりませんでした。 そのため、同じメトリック、分析、およびJSカウンターを備えた他のすべての統計システムよりもはるかに多くのデータを取得します。
データはクロスドメインAJAXを介してサーバーに送信され、ブラウザがそれをサポートしていない場合はiframeを介して送信されます。 送信は、ページの読み込み時に実行されるほか、多くのJSイベントに対しても実行されます。 これにより、サイト上のユーザーの行動を分析し、サイト上の行動のパターンや特定のJavascriptイベントの不完全な模倣によって、ボットと実際のユーザーを区別することができます。 たとえば、多くのボットはonClickイベントをシミュレートしますが、onMouseDownイベント、onMouseUp ...イベントは生成しません。

そこで、 3番目のタスクである鉄の選択にスムーズに取り組みました。
現時点では、システムは4つのセグメントで構成されています。

すべてのドメインは、ttl 60秒でAmazon Route 53に関連付けられているため、サーバーで問題が発生した場合に、バックアップドメインにすばやく移行できます。
フロントエンドについて特別なことは何もありません。 その負荷は小さく、ほとんどすべてのvpsで処理できます。
データの収集と処理では、大量のデータを扱う必要があるため、すべてがやや複雑になります。 現在、毎秒約200件のリクエストを処理しています。
ハードウェアとソフトウェアの最初の正しい選択により、1台のサーバーがこのボリュームに完全に対応します。
ハードウェアの場合-8コアAMD、SASディスクからのRAID10、16Gb RAM。
データ収集はnginx + php-fpm + mysqlの調整された束によって実行され、処理はC ++スクリプトによって実行されます。
最初は、データ収集スクリプトによる集中的なCPUリソース消費の問題に直面しました。 解決策は完全に予想外でした。 すべてのereg_ php関数をそれらのpreg_類似物に置き換えて、CPU消費を約8倍削減しました。これは非常に驚くべきことでした。
現在のサーバーで問題が発生したり、スケーリングが必要な場合、別のDCで、1時間以内に稼働する可能性がある同様の構成の2番目のサーバーが翼で待機しています。
ランディングページは、専用のIPブロックを備えた別のサーバーによってインデックスが作成されますが、これはCPUとRAMを大量に消費しますが、ディスクサブシステムにはまったく必要ありません。 インデックス作成は、Pythonで記述された「検索ボット」によって行われます。
このノードは複製されませんが、その交換または拡張は1日未満で完了し、トラフィック分析の品質に直接影響しません。最悪の場合、クライアントがサイトに横たわっているか、サイトからコードが消えても、いくつかの広告キャンペーンは停止しません。
サードパーティのサービスのユーザー名/パスワードのリポジトリはかなり具体的なものであり、一般的に、セキュリティの観点からは良くありません。
ただし、ほとんどの広告ネットワークでは、APIが必要な機能をすべて提供するわけではなく、Webインターフェースを解析する必要があります。これはパスワードなしでは実行が困難です。 たとえば、Google Adwordsでは、IPアドレスの禁止はウェブインターフェースからのみ可能です。 ボーナスとして、ユーザーはワンクリックでシステムのインターフェースから広告ネットワークのアカウントにアクセスできます。
これは4番目のタスクです。平文で保存する場合のデータセキュリティを確保します。
最も安全なデータストレージのために、次のスキームを作成しました。

完全なブラウザエミュレーションを使用しないと一部のWebインターフェースを解析できないため、ストレージはRAMとCPUを必要とします。 別のDCでは、予期しない状況の場合、バックアップストレージサーバーも待機しており、1時間以内に作業を開始する準備ができています。

最後の5番目のタスクは、「悪い」IPおよびサイトの自動禁止のための広告ネットワークとの統合でした。
BegunやMarketGuideなどの条件付きの小さなネットワークでは問題はなく、すべてのやり取りはAPIによって機能します。一部の方法では不十分な場合、パートナーはそれらをすばやく追加します。
しかし、Yandex.Direct、特にAdWordsには、十分な問題があります。 AdWordsでAPIを取得することは完全なクエストになります。 最初に1か月間取得し、それから関数の半分がそこになく、Webインターフェースを解析する必要があることがわかります。 そして、基本的なAPIで購入できないユニットによって厳密に制限されている機能でさえあることがわかりました。 そして、新しいクエストは、ユニットの数を増やして、次のレベルのアクセスのAPIから始まります。 ご覧のように、検索の巨人は、広告主が広告費用を最適化するのを可能な限り困難にするためにあらゆることを行っています。 ただし、現時点では、トラフィックの分析に成功し、自動的にクリアします。

現時点では、私たちのシステムには、機能が類似しており、最も重要なこととして、低品質のトラフィックの検出品質に匹敵する実際の競合他社はありません。 場合によっては、他の分析システムよりも40〜45％多くのトラフィックが見られます。
トラフィック監査のコストは、購入した広告のコストの平均で約100倍低く、個々の広告システムの場合、サービスは完全に無料です。 同時に、節約額は広告予算の10〜50％であり、最大90％になることもあります。
現在、システムは、Yandex.Direct、Google AdWords、Begun、MarketGuideで完全自動モードで動作しています。 他の広告システムでは、サービスはトラフィック監査モードで動作し、その後、ブラックリストに不正なIPとサイトを手動で追加します。

今すぐ参加しよう！

Source: https://habr.com/ru/post/J208484/

More articles:


All Articles