私は、AWS のロードバランサーの背後で 2 つの ec2.smalls を実行しているサイトを持つ DevOps Web 開発者です。
最近、1 秒あたり 3 ～ 4 件のリクエストによってクライアントのサイトがダウンするのを確認しました。
サイトはダウンしており、最近変更がプッシュされていないにもかかわらず、サーバーを複数回再起動し、問題の原因となっている可能性のあるスクリプトをエラー ログでスキャンした後も復旧しませんでした。
ロード バランサーのログ記録をオンにした後、1 つのページに対する 1000 件のリクエストが 1 つの IP アドレスから送信されていることがわかりました。
X-forwarded-for を使用して、ロード バランサーからリクエストを処理するサーバーにリクエストを転送し、.htaccess ルールを使用して IP をブロックしました。
クライアントの IT 部門と連絡を取っているときに、大量のリクエストの原因となっている IP アドレスが実際には社内のマシンの 1 つであることが通知されました。
原因となっているマシンはリモートで再起動され、すべてのリクエストが停止されました。サイトはオンラインに戻りました。
これに対する公式の説明は「コンピューターが異常をきたした」というものでした。
Web ブラウザーまたは Windows マシンが、負荷分散された Web ページに対して 1 秒あたり 3 ～ 4 回のリクエストを送信し、そのページを 5 時間以上ダウンさせることは可能ですか?
リクエストの内容は次の通りです:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
答え1
もちろん可能ですが、いくつかの要因に依存します。
1) サーバー側のアプリケーションで同時実行の問題が発生しているようです。ボトルネックになっているのがアプリケーション サーバーなのか、それとも DB などの上流で、Apache の設定でスレッドが十分に速くフラッシュされないためにアプリケーション サーバーがメモリ不足になったのかを調べる価値があるかもしれません。アプリケーション サーバーの場合は、チューニングを行う価値があるかもしれません。ELB の外部で同一のマシンを起動し、JMeter を使用して負荷をかけ、ボトルネックを突き止めます。
データベースの場合は、memcache/elasticache を使用して実際のクエリをキャッシュできる可能性があります (特定のオブジェクトを取得しているように見えるため)。 こうすることで、データベース接続が迅速に応答し、Apache が迅速に応答し、アプリケーション マシンのメモリ プールをいっぱいにせずにスレッドを強制終了できます。
本当に脆弱だと感じる場合は、Varnish をアップストリームに配置して、1 ～ 5 秒の TTL でリクエストをキャッシュし、大量のリクエストの集中を防ぐことができます。ただし、VCL は容赦がなく、大きな問題や苦痛 (キャッシュ ポイズニング/リーク) につながる可能性があるので注意してください。
2) 「対象」マシン自体については、明らかに侵害された可能性があり、必ず調査する必要があります。IT 担当者が正直かどうかは、皆さんの判断にお任せします。これは、serverfault の範囲外です。
侵害されていなかったと仮定すると、JavaScript コードに問題があった可能性があります。ポーリング更新を実行していて、タイミング パラメータが何らかの理由で変更された場合、1 秒あたり多数のリクエストが送信される可能性があります。同様に、JS は正常に動作していたかもしれませんが、ユーザーは 25 個のタブを開いて夕方に帰宅した可能性があります。各タブが 5 秒ごとに 1 つのリクエストを送信している場合、5req/秒になります。