현재 부하 분산 솔루션을 Cloudflare와 통합하는 방법을 알아보세요.
개요
Cloudflare와 통합할 때 다음 모범 사례를 따라 웹사이트의 호스트 환경에서 부하를 분산하시기 바랍니다.
- Cloudflare의 DNS Load Balancing
- HTTP 활성화 유지
- 세션 쿠키
- Railgun
DNS Load Balancing
Cloudflare의 Load Balancing 기능은 원본 서버의 상태를 검사하면서 DNS 기반 부하 분산을 지원합니다. Cloudflare의 기존 Anycast DNS 네트워크를 확대하여 DDoS 내성이 있는 장애 조치(비정상 원본 우회)와 지오스티어링(사용자를 특정 오리진 풀로 연결)을 제공합니다.
HTTP 활성화 유지(HTTP 지속 연결)
Cloudflare는 지속 연결을 유지하므로, 성능이 개선되고, Cloudflare가 에지 네트워크에서 사이트 원본으로 고객 트래픽을 프록시 설정할 때 요청 트랜잭션에 반복적으로 발생하는 TCP 연결 비용을 절감합니다.
원본 서버에 HTTP 지속 연결이 활성화됐는지 확인하세요. Cloudflare는 마지막 HTTP 요청 후 최대 15분(900초) 동안, 열린 TCP 연결을 재사용합니다. TCP 연결이 너무 많이 열린 경우, 원본 서버는 연결을 닫습니다. HTTP 지속 연결은 Cloudflare가 프록시 설정한 요청을 너무 일찍 재설정하는 것을 막는 데 도움이 됩니다.
세션 쿠키
HTTP 쿠키를 사용하여 사용자 세션을 추적하고 이를 부하 분산 장치의 특정 애플리케이션 서버에 연결하는 경우, 지속 연결 때문에, HTTP 요청이 동일한 TCP 연결을 공유하더라도 부하 분산 장치가 쿠키 헤더별로 HTTP 요청을 구문 분석하고 각 요청을 올바른 애플리케이션 서버에 연결하는 것이 최선입니다.
예: F5 BIG-IP 부하 분산 장치는 세션 쿠기가 없는 경우, TCP 연결 시작 시 세션 쿠키를 설정한 후, 동일한 TCP 소켓 상에서 이루어진 후속 HTTP 요청을 통과한 모든 쿠기를 무시합니다. 이것은 세션 선호도를 깨는 경향이 있습니다. Cloudflare가 동일한 TCP 연결에서 다른 HTTP 세션을 여러 개 보내기 때문입니다. (HTTP 쿠키 기반 세션 선호도).
Railgun(WAN 최적화)
Railgun과 load balancer 사용할 경우의 이상적인 설정은 Railgun 수신기를 load balancer 앞에 배치하는 것입니다. 발신/수신 사이에 오래 지속된 TLS 연결의 부하를 분산하기는 어렵기 때문에, 수신기를 앞에 배치하면, load balancer가 HTTP/S 연결을 정상으로 처리할 수 있으므로 이렇게 하는 것이 좋습니다.
Railgun이 HTTP 리버스 프록시로 작동하기 때문에, load balancer 설정은, Railgun이 배치되지 않았을 때의 설정과 일치해야 합니다 (즉, HTTP 지속 연결을 사용하고 90초 제한 시간 초과를 설정해야 합니다).
Railgun이 부하 분산 장치 뒤에 배치된 설정도 작동하기는 하지만 사이트 트래픽과 간섭을 피하기 위해 추가 조치가 필요합니다.
- railgun-nat.conf 파일을 구성하여 호스트의 내부 주소를 설정합니다. Railgun이 최적화합니다(인터넷으로 향하는 요청이 load balancer로 돌아와 원본으로 연결되는 상황을 피합니다).
- 수신기와 원본 서버 사이의 트래픽 속도를 방해하거나 제한하는 방화벽 규칙이 없는지 확인합니다.
- 포트 2408이 열려 있고 수신기와 발신기의 TLS 연결을 방해하지 않고 LB를 통과하게 하세요.