Web HighLoad - 수만 개의 도메인에 대한 트래픽을 관리하는 방법

DDoS-Guard 네트워크의 합법적인 트래픽이 최근 초당 50기가비트를 초과했습니다. 현재 전체 트래픽의 XNUMX%는 클라이언트 웹 서비스에서 생성됩니다. 이는 수만 개의 도메인으로 매우 다르며 대부분의 경우 개별 접근 방식이 필요합니다.

아래에는 프런트 노드를 관리하고 수십만 개의 사이트에 대한 SSL 인증서를 발급하는 방법이 나와 있습니다.

매우 큰 사이트라도 한 사이트에 대한 전면을 설정하는 것은 쉽습니다. 우리는 nginx, haproxy 또는 lighttpd를 사용하여 가이드에 따라 구성하고 잊어버립니다. 무언가를 변경해야 하면 다시 로드하고 다시 잊어버립니다.

대량의 트래픽을 즉시 처리하고, 요청의 적법성을 평가하고, 사용자 콘텐츠를 압축 및 캐시하고, 동시에 매개변수를 초당 여러 번 변경하면 모든 것이 변경됩니다. 사용자는 개인 계정의 설정을 변경한 후 즉시 모든 외부 노드에서 결과를 확인하기를 원합니다. 사용자는 API를 통해 개별 트래픽 처리 매개변수가 포함된 수천 개(때로는 수만 개)의 도메인을 다운로드할 수도 있습니다. 이 모든 것은 미국, 유럽 및 아시아에서도 즉시 작동해야 합니다. 모스크바에만 물리적으로 분리된 여러 개의 여과 노드가 있다는 점을 고려하면 작업은 가장 사소한 것이 아닙니다.

전 세계에 신뢰할 수 있는 대규모 노드가 많은 이유는 무엇입니까?

• 클라이언트 트래픽에 대한 서비스 품질 - 미국으로부터의 요청은 미국에서 처리되어야 하며(공격, 구문 분석 및 기타 이상 현상 포함) 모스크바나 유럽으로 가져오지 않아야 하므로 처리 지연이 예측할 수 없을 정도로 증가합니다.

• 공격 트래픽은 현지화되어야 합니다. 대중교통 운영자는 공격 중에 성능이 저하될 수 있으며, 그 볼륨은 종종 1Tbps를 초과합니다. 대서양 횡단 또는 아시아 횡단 링크를 통해 공격 트래픽을 전송하는 것은 좋은 생각이 아닙니다. Tier-1 운영자가 "당신이 받는 공격의 양은 우리에게 위험합니다."라고 말한 실제 사례가 있었습니다. 그렇기 때문에 우리는 가능한 한 소스에 가까운 수신 스트림을 허용합니다.

• 서비스 연속성을 위한 엄격한 요구 사항 - 청소 센터는 빠르게 변화하는 세상에서 서로 또는 지역 행사에 의존해서는 안 됩니다. 일주일 동안 MMTS-11 9층 전체의 전원을 차단하셨나요? - 괜찮아요. 이 특정 위치에 물리적 연결이 없는 단일 클라이언트는 문제가 발생하지 않으며 웹 서비스는 어떤 상황에서도 문제가 발생하지 않습니다.

이 모든 것을 어떻게 관리합니까?

서비스 구성은 가능한 한 빨리(이상적으로는 즉시) 모든 프런트 노드에 배포되어야 합니다. 텍스트 구성을 가져와서 다시 빌드하고 변경될 때마다 데몬을 재부팅할 수는 없습니다. 동일한 nginx는 몇 분 동안(또는 긴 웹소켓 세션이 있는 경우 몇 시간 동안) 프로세스를 종료(작업자 종료) 상태로 유지합니다.

nginx 구성을 다시 로드할 때 다음 그림은 매우 정상입니다.

메모리 활용:

오래된 작업자는 연결 수에 선형적으로 의존하지 않는 메모리를 포함하여 메모리를 소모합니다. 이는 정상적인 현상입니다. 클라이언트 연결이 닫히면 이 메모리가 해제됩니다.

nginx가 막 시작되었을 때 이것이 문제가 되지 않았던 이유는 무엇입니까? HTTP/2도, WebSocket도, 대규모의 장기 연결 유지 연결도 없었습니다. 우리 웹 트래픽의 70%는 HTTP/2입니다. 이는 매우 긴 연결을 의미합니다.

해결책은 간단합니다. nginx를 사용하지 말고, 텍스트 파일을 기반으로 프런트를 관리하지 말고, 태평양 횡단 채널을 통해 압축된 텍스트 구성을 보내지 마세요. 물론 채널은 보장되고 예약되어 있지만 그렇다고 해서 대륙 횡단이 덜되는 것은 아닙니다.

우리는 자체적인 전면 서버 밸런서를 갖고 있으며, 이에 대한 내부 내용은 다음 기사에서 다루겠습니다. 이것이 수행할 수 있는 가장 중요한 작업은 다시 시작, 다시 로드, 메모리 소비의 급격한 증가 등의 작업 없이 즉시 초당 수천 개의 구성 변경 사항을 적용하는 것입니다. 이는 예를 들어 Erlang의 Hot Code Reload와 매우 유사합니다. 데이터는 지리적으로 분산된 키-값 데이터베이스에 저장되며 전면 액추에이터에 의해 즉시 읽혀집니다. 저것들. 모스크바의 웹 인터페이스나 API를 통해 SSL 인증서를 업로드하면 몇 초 안에 로스앤젤레스의 청소 센터로 이동할 준비가 됩니다. 갑자기 세계 대전이 일어나고 전 세계에서 인터넷이 사라진 경우, 우리 노드는 로스앤젤레스-암스테르담-모스크바, 모스크바-암스테르담-홍콩- Los-Los를 사용할 수 있게 됩니다.Angeles 또는 GRE 백업 오버레이 중 하나 이상.

이와 동일한 메커니즘을 통해 Let's Encrypt 인증서를 즉시 발급하고 갱신할 수 있습니다. 매우 간단하게 다음과 같이 작동합니다.

1. 인증서가 없거나 만료된 인증서가 있는 클라이언트 도메인에 대해 하나 이상의 HTTPS 요청이 표시되는 즉시 요청을 수락한 외부 노드는 이를 내부 인증 기관에 보고합니다.

   

2. 사용자가 Let's Encrypt 발급을 금지하지 않은 경우, 인증기관은 CSR을 생성하고, LE로부터 확인 토큰을 받아 암호화된 채널을 통해 전방위로 전송합니다. 이제 모든 노드는 LE의 유효성 검사 요청을 확인할 수 있습니다.

   

3. 잠시 후 올바른 인증서와 개인 키를 수신하고 동일한 방식으로 전면에 보냅니다. 다시 말하지만, 데몬을 다시 시작하지 않고

   

4. 유효기간 만료 7일 전부터 인증서 재발급 절차가 시작됩니다.

현재 우리는 사용자에게 완전히 투명하게 350개의 인증서를 실시간으로 순환시키고 있습니다.

시리즈의 다음 기사에서는 대규모 웹 트래픽 실시간 처리의 다른 기능에 대해 설명하겠습니다. 예를 들어 불완전한 데이터를 사용하여 RTT를 분석하여 대중교통 클라이언트의 서비스 품질을 향상시키는 방법과 일반적으로 대중교통 트래픽을 보호하는 방법에 대해 설명합니다. 테라비트 공격, 트래픽 정보 전달 및 집계, WAF, 거의 무제한에 가까운 CDN 및 콘텐츠 전달 최적화를 위한 다양한 메커니즘에 대해 설명합니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

무엇을 먼저 알고 싶나요?

• 14,3%웹 트래픽 품질을 클러스터링하고 분석하는 알고리즘<3

• 33,3%DDoS-Guard7 밸런서의 내부

• 9,5%전송 L3/L4 트래픽 보호2

• 0,0%대중교통 트래픽에서 웹사이트 보호0

• 14,3%웹 애플리케이션 방화벽3

• 28,6%구문 분석 및 클릭으로부터 보호6

21명의 사용자가 투표했습니다. 6명의 사용자가 기권했습니다.

출처 : habr.com