로드 밸런싱 참조 아키텍처(Load Balancing Reference Architecture)

글로벌 및 로컬 트래픽 관리를 위한 로드 밸런싱 솔루션을 배포하려는 조직을 위한 참조 아키텍처예요. IT, 웹 호스팅, 네트워크 전문가에게 유용해요.

출처: 문서

본문

소개(Introduction)

Cloudflare Load Balancing은 조직이 전 세계 사용자를 위해 애플리케이션을 호스팅하면서 유지 관리, 장애 조치, 복원력, 확장성에 대한 우려를 크게 줄일 수 있게 해주는 SaaS 제품이에요. Cloudflare Load Balancing을 사용하면 다음 과제를 해결할 수 있어요:

• 특히 예상치 못한 급증이나 스파이크 상황에서 대량의 수신 트래픽을 효율적으로 처리하기
• 애플리케이션과 서비스가 사용자에게 계속 접근 가능하도록 보장하기
• 특히 높은 트래픽 기간 동안 모든 사용자에게 빠른 응답 시간과 최적의 성능을 유지하기
• 변화하는 트래픽 수요에 적응하고 인프라가 성장을 수용할 수 있도록 보장하기
• 애플리케이션과 서비스가 분산 서비스 거부(DDoS) 공격에 저항하도록 돕기

Cloudflare Load Balancing은 Cloudflare의 커넥티비티 클라우드(connectivity cloud) 위에 구축돼요. 이는 모든 네트워크(엔터프라이즈 및 인터넷), 클라우드 환경, 애플리케이션, 사용자 간의 안전한 any-to-any 연결을 가능하게 하는 통합된 지능형 프로그래머블 클라우드 네이티브 서비스 플랫폼이에요. 330개 이상의 도시에 걸친 데이터 센터와 13,000개 이상의 네트워크 피어와의 상호 연결을 갖춘 세계에서 가장 큰 글로벌 네트워크 중 하나예요. 또한 많은 대형 기술 기업보다 핵심 인터넷 익스체인지에서 더 큰 존재감을 가져요.

그 결과 Cloudflare는 세계 인터넷 연결 인구의 약 95%로부터 약 50ms 이내에서 운영돼요. 그리고 모든 Cloudflare 서비스가 모든 네트워크 위치에서 실행되도록 설계되었기 때문에 모든 요청이 소스에 가깝게 라우팅, 검사, 필터링되어 강력한 성능과 일관된 사용자 경험을 제공해요.

이 문서는 글로벌 및 로컬 트래픽 관리 로드 밸런싱 솔루션을 모두 배포하려는 조직을 위한 참조 아키텍처를 설명해요.

이 문서는 누구를 위한 것이며 무엇을 배우게 되나요?

이 참조 아키텍처는 조직의 기존 인프라에 대한 일부 책임 또는 친숙함을 가진 IT, 웹 호스팅, 네트워크 전문가를 위해 설계됐어요. 라우팅, DNS, IP 주소 지정과 같은 네트워킹 개념에 대한 약간의 경험과 로드 밸런서 기능에 대한 기본 이해가 있으면 유용해요.

Cloudflare와 그 로드 밸런싱 솔루션에 대한 더 강한 기반 이해를 위해 다음 리소스를 권장해요:

• Cloudflare란 무엇인가? | 웹사이트 ↗︎ (5분 읽기) 또는 동영상 ↗︎ (2분)

• 솔루션 브리프: Cloudflare Private Network Load Balancing ↗︎ (5분 읽기)

• 솔루션 브리프: Cloudflare GTM Load Balancing ↗︎ (5분 읽기)

• 블로그: 사설 IP와 Cloudflare Tunnels로 로드 밸런싱 향상: 효율적인 트래픽 분배를 위한 안전한 경로 ↗︎ (13분)

이 참조 아키텍처를 읽은 사람들은 다음을 배우게 돼요:

• Cloudflare Load Balancing이 Private Network Load Balancing과 글로벌 트래픽 관리 사용 사례를 모두 어떻게 해결하는지
• Cloudflare의 글로벌 네트워크가 Cloudflare Load Balancing의 기능을 어떻게 향상시키는지
• Cloudflare Load Balancer의 기능과 다양한 사용 사례에 어떻게 적용되는지
• Cloudflare Load Balancer의 구조와 다양한 구성

현대 애플리케이션의 동적 워크로드 처리

개념과 용어

엔드포인트(Endpoint)

이 문서에서 "엔드포인트"는 수신 공용 또는 사설 트래픽을 가로채고 처리하는 모든 서비스 또는 하드웨어예요. 로드 밸런싱은 웹 서버에만 국한되지 않으므로 엔드포인트라는 용어는 가능한 모든 유형의 오리진, 호스트 이름, 사설 또는 공용 IP 주소, 가상 IP 주소(VIP), 서버, 기타 전용 하드웨어 박스를 나타내기 위해 선택됐어요. 온프레미스일 수도 있고 공용 또는 사설 클라우드에 호스팅될 수도 있으며, 심지어 타사 로드 밸런서일 수도 있어요.

스티어링(Steering)

스티어링은 로드 밸런서의 주요 기능이에요. 정책 집합에 따라 요청을 처리, 전송, 전달하는 프로세스예요. 이러한 정책은 일반적으로 요청 URL, URL 경로, HTTP 헤더, 구성된 가중치, 우선순위, 그리고 엔드포인트 지연 시간, 응답성, 용량, 부하 등 많은 요소를 고려해요.

레이어 7(Layer 7)

OSI 모델 ↗︎의 레이어 7, 즉 애플리케이션 레이어에는 SSH, FTP, NTP, SMTP, HTTP(S) 같은 프로토콜이 있어요. 이 문서가 레이어 7 또는 레이어 7 로드 밸런서를 언급하면 HTTP(S) 기반 서비스를 의미해요. Cloudflare 레이어 7 스택은 Cloudflare가 DDoS 보호, Bot Management, WAF, CDN, Load Balancing 등을 고객 웹사이트에 적용해 성능, 가용성, 보안을 개선할 수 있게 해요.

레이어 4(Layer 4)

OSI 모델 ↗︎의 레이어 4, 즉 전송 레이어는 두 장치 간의 종단 간 통신을 담당해요. 레이어 4에서 작동하는 네트워크 서비스는 훨씬 더 넓은 범위의 서비스와 프로토콜을 지원할 수 있어요. Cloudflare의 공용 레이어 4 로드 밸런서는 Spectrum이라는 제품에 의해 활성화되며, 이는 레이어 4 리버스 프록시로 작동해요. Spectrum은 로드 밸런싱을 제공할 뿐만 아니라 DDoS 공격으로부터 보호하고 엔드포인트 IP 주소를 숨길 수 있어요.

SSL/TLS 오프로딩

SSL(Secure Sockets Layer)과 그 후속인 TLS(Transport Layer Security)는 인터넷을 통한 연결을 보호하는 데 사용되는 암호화 프로토콜이에요. SSL/TLS 오프로딩은 SSL/TLS 종료 또는 SSL/TLS 가속이라고도 하며, 로드 밸런서와 웹 서버가 엔드포인트의 성능에 영향을 주지 않고 SSL/TLS 암호화 및 복호화 프로세스를 처리하는 데 사용되는 기법이에요. SSL/TLS 오프로딩은 리소스 집약적인 암호화·복호화 작업을 전용 장치로 오프로드하여 서버 성능을 개선하고, 인증서 관리를 단순화하며, 확장성을 향상시켜 엔드포인트가 콘텐츠와 애플리케이션 로직을 서빙하는 데 집중하도록 돕는답니다.

로드 밸런서가 해결하는 과제

현대 웹사이트, 아니 어떤 애플리케이션이든 세 가지 주요 과제에 직면해요:

1. 성능(Performance): 애플리케이션이 사용자 요청과 입력에 적시에 응답하는지 보장하기
2. 가용성(Availability): 애플리케이션의 가동 시간을 유지하여 항상 사용자 요청에 응답할 수 있게 하기
3. 확장성(Scalability): 사용자 행동 또는 수요에 따라 애플리케이션 리소스를 늘리거나, 줄이거나, 재배치하기

성능(Performance)

애플리케이션 성능은 여러 요인에 의해 영향을 받을 수 있지만, 성능 문제의 가장 흔한 원인은 엔드포인트에 가해지는 사용량 또는 부하예요. 엔드포인트는 일반적으로 제공할 수 있는 컴퓨팅 리소스가 유한해요. 너무 많은 요청이 한 번에 도착하거나 요청 유형이 CPU/메모리 사용량을 증가시키면 엔드포인트는 응답이 느려지거나 전혀 응답하지 않을 수 있어요.

이러한 과제를 해결하기 위해 엔드포인트를 더 많은 컴퓨팅 리소스로 업그레이드할 수 있어요. 하지만 유휴 또는 낮은 사용량 기간에는 조직이 활용도가 낮은 리소스에 대해 비용을 지불하게 돼요. 조직은 여러 엔드포인트를 배포할 수도 있지만, 이들 사이에서 트래픽을 원활하게 스티어링하려면 최종 사용자에게 이 프로세스를 매끄럽게 만드는 로드 밸런싱 솔루션이 필요해요.

그림 1은 로드 밸런서 없이 부하가 어떻게 분산될 수 있는지 보여줘요:

그림 1: 로드 밸런서 없이는 엔드포인트 성능이 저하될 수 있어요

로드 밸런서는 조직이 여러 엔드포인트를 호스팅하고 그들 사이에 트래픽을 분할하여 단일 엔드포인트가 과부하되지 않도록 해요. 로드 밸런서는 모든 수신 요청을 처리하고 적절한 엔드포인트로 전달해요. 클라이언트는 엔드포인트 가용성이나 부하에 대해 알 필요 없어요. 요청을 로드 밸런서로 보내기만 하면 나머지는 로드 밸런서가 처리해요. 그림 2는 로드 밸런서가 일련의 엔드포인트에 걸쳐 사용자 트래픽을 고르게 분산할 수 있는 방법을 보여줘요.

그림 2: 로드 밸런서는 여러 엔드포인트에 걸쳐 부하 분산을 돕는답니다

성능과 관련된 또 다른 문제는 클라이언트와 엔드포인트 사이의 거리예요. 더 멀리 이동하거나 더 많은 네트워크 홉을 해야 한다는 사실 때문에 더 긴 거리를 이동하는 요청은 일반적으로 왕복 시간(RTT)이 더 높아요.

RTT는 규모가 커질 때 중요해져요. 예를 들어 클라이언트와 엔드포인트가 모두 미국에 있다면 RTT가 25ms일 것으로 합리적으로 예상할 수 있어요. 클라이언트가 응답을 받아야 하는 요청이 20개라면 이를 순차적으로 처리하는 데 필요한 총 시간(컴퓨팅 시간 제외)은 500ms(20 x 25ms)가 돼요. 그리고 같은 클라이언트가 APAC 지역에서 연결한다면 RTT는 150ms 이상일 수 있어 원치 않는 총 로딩 시간 3000ms(20 x 150ms)가 발생해요. (물론 HTTP/2 및 HTTP/3의 요청 스트리밍 개선이 이 계산을 바꿀 수 있지만, 응답 정보가 추가 요청을 생성하는 데 사용되는 동적 또는 대화형 콘텐츠가 있는 웹사이트에서는 이 예시가 일반적으로 여전히 성립해요.) 그림 3은 이것이 어떻게 발생하는지 보여줘요.

그림 3: 지연 시간이 어떻게 누적되어 리소스 로드에 걸리는 총 시간에 영향을 주는지

로드 밸런서가 트래픽을 덜 바쁜 엔드포인트로 전달할 수 있는 것과 같은 방식으로, 지리적으로 더 가까운 엔드포인트로도 전달할 수 있어 클라이언트에게 더 반응성 높은 경험을 제공해요. 구체적으로 로드 밸런서는 요청을 보낸 IP 주소를 조회하고 위치를 결정한 다음 가장 가깝거나 지역에 가장 적합한 엔드포인트를 선택해 보내요 (이는 GeoDNS 같은 DNS 솔루션이 제공하는 기능과 유사해요).

가용성(Availability)

서비스 가용성은 로드 밸런서 뒤에 있는 엔드포인트의 의도하지 않은 다운타임과 의도적인 다운타임을 모두 포함해요. 하드웨어 고장, 소프트웨어 버그, 네트워크 문제, ISP 또는 기타 벤더 문제 등 여러 요인이 의도하지 않은 다운타임에 기여할 수 있어요. 가장 발전된 조직조차도 이러한 문제를 피할 수는 없어요.

로드 밸런서는 항상 엔드포인트의 상태를 모니터링하여 이러한 문제를 해결해요. 엔드포인트가 상태 점검에 느리게 응답하거나 전혀 응답하지 않으면 엔드포인트는 비정상(unhealthy)으로 표시돼요. ICMP(ping) 및 TCP 연결 테스트 같은 기본 상태 테스트를 포함한 여러 모니터링 방법이 존재해요. HTTP GET 요청을 발행하고 특정 응답 코드와 응답 본문이 엔드포인트에서 반환되는지 확인하는 것 같은 더 고급 상태 테스트도 사용할 수 있어요. 엔드포인트가 저하된 상태가 되면 로드 밸런서는 더 건강한 엔드포인트를 선호해 그쪽으로 요청을 줄이거나 보내지 않아요. 엔드포인트가 다시 작동하고 로드 밸런서가 상태 점검에 응답을 받을 수 있게 되면 엔드포인트는 운영 상태로 표시되고 다시 트래픽이 스티어링돼요.

의도적인 다운타임은 용량 변경, 하드웨어 또는 인프라 업그레이드, 소프트웨어 업데이트 등 다양한 형태로 발생해요. 로드 밸런서는 이러한 유지 관리를 위해 하나 이상의 엔드포인트에서 트래픽을 우아하게 제거해요.

규모(Scale)

효과적인 애플리케이션 확장은 조직이 고객 또는 사용자 수요를 충족하고 불필요한 비용이나 요금을 피하는 데 도움을 줘요. 트래픽 증가 동안 조직은 서비스가 성능과 가용성을 유지하도록 일시적으로 더 많은 엔드포인트를 배포해야 할 수 있어요. 그러나 엔드포인트가 온프레미스에 있든 AWS, GCP, Azure 같은 클라우드 제공업체를 통하든, 최대 가능 트래픽을 충족하기 위해 항상 충분한 엔드포인트를 온라인으로 유지하는 것은 비용이 많이 들 수 있어요. 로드 밸런서는 엔드포인트에 대한 요청, 연결, 지연 시간을 모니터링하여 용량을 동적으로 증가 또는 감소시킬 수 있게 해줘요.

고려해야 할 또 다른 확장 유형은 지리적 확장이에요. 서비스가 인기를 얻으면서 엔드포인트 위치가 더 중요해져요. 엔드포인트와 다른 지리적 지역에 있는 사용자는 같은 지역의 사용자보다 응답 시간이 느리고 서비스 품질이 낮을 수 있어요. 조직이 서로 다른 지역에 새 엔드포인트를 배포하면서 트래픽을 어떻게 분배할지 결정해야 해요. 이 과제는 글로벌 트래픽 관리(GTM)와 Private Network Load Balancing이라고 하는 서로 다른 레이어의 로드 밸런싱으로 해결됐어요. 이 문서는 다음 섹션에서 이 둘을 자세히 설명해요. 요약하면, GTM 로드 밸런서는 초기 요청(일반적으로 DNS를 통해)을 처리한 다음 적절한 지리적 지역의 엔드포인트에 가깝게 배포된 Private Network Load Balancer로 트래픽을 선택하고 스티어링해요.

트래픽 관리 유형

앞서 언급했듯이 글로벌 애플리케이션과 서비스를 위한 로드 밸런싱은 두 레이어로 나뉘어요. 첫 번째 레이어는 Global Traffic Management 또는 Manager(GTM)라고 하며, Global Server Load Balancing(GSLB)이라고도 불러요. 두 번째 레이어는 Private Network Load Balancing이라고 하며, Server Load Balancing(SLB)이라고도 해요. 이 섹션은 이러한 다양한 로드 밸런싱 유형의 목적과 이들이 어떻게 함께 작동하는지 정의해요.

글로벌 트래픽 매니저 / 글로벌 트래픽 관리(GTM)

Global Traffic Manager는 일반적으로 인터넷에서 오는 요청을 적절한 지역 또는 데이터 센터로 라우팅하는 역할을 해요. 많은 GTM 로드 밸런서가 DNS 레이어에서 작동하여 다음을 가능하게 해요:

• 지리적 지역 또는 물리적 위치에 따라 DNS 요청을 IP 주소로 해석하기
• 클라이언트가 연결할 수 있게 클라이언트에 가장 가까운 엔드포인트 또는 서비스의 IP를 제공하기

그림 4는 GTM 로드 밸런서가 클라이언트 위치 또는 지역에 따라 데이터 센터를 선택하는 데 어떻게 사용되는지 보여줘요.

그림 4: 글로벌 트래픽 관리 로드 밸런서 개요

Global Traffic Manager는 트래픽을 프록시하고 HTTP 요청의 헤더 읽기/변경/삭제, 지역 또는 지리적 위치에 따른 URL 수정 등 다양한 검사를 수행할 수도 있어요. GTM 기능은 전 세계 어디에서든 트래픽을 스티어링하는 것이 목표이므로 (Cloudflare 같은) 클라우드 기반 로드 밸런서로 구현하는 것이 가장 좋아요. 하드웨어 로드 밸런서는 단일 물리적 위치에 존재하므로 트래픽이 로드 밸런서에서 멀리 발생할수록 최종 사용자 경험이 느려져요. 클라우드 기반 로드 밸런서는 다양한 지리적 위치에서 실행될 수 있어 DNS 전용, 레이어 4, 레이어 7 컨텍스트 모두에 성능 좋은 솔루션을 제공하는 데 도움을 줘요.

Private Network Load Balancing

Private Network Load Balancing은 데이터 센터 또는 지리적 위치 내에서 트래픽을 스티어링해요. Private Network Load Balancer는 로드 밸런싱, SSL/TLS 오프로딩, 콘텐츠 스위칭 및 기타 애플리케이션 전달 기능을 담당할 수 있어요. Private Network Load Balancing은 여러 엔드포인트에 걸쳐 클라이언트 요청을 효율적으로 분배하여 성능을 개선하고 높은 가용성을 보장해요. Private Network Load Balancer는 일반적으로 사설 네트워크 내부에 배치되며 공용 또는 사설로 접근 가능한 리소스를 로드 밸런싱하는 데 사용돼요. 아래 그림 5에서 GTM 로드 밸런서는 요청을 유럽 데이터 센터로 보내도록 선택했고, 유럽 데이터 센터의 Private Network Load Balancer가 이를 적절한 엔드포인트로 스티어링해요.

그림 5: Private Network Load Balancer 개요

Private Network Load Balancer와 그 엔드포인트는 일반적으로 방화벽 뒤에 있어요. 그러나 엔드포인트는 사설 네트워크에서 보호될 수 있지만, Private Network Load Balancer에 대한 접근성은 배포 요구 사항에 따라 공용 또는 사설이 될 수 있어요. Private Network Load Balancer는 총 요청, 연결, 엔드포인트 상태를 모니터링하여 요청이 적시에 응답할 수 있는 엔드포인트로 스티어링되도록 해요.

온프레미스 vs 클라우드 기반 로드 밸런서

두 가지 주요 로드 밸런서 아키텍처가 있어요:

• 온프레미스 로드 밸런서
  • 일반적으로 하드웨어 기반이지만 가상화 또는 소프트웨어 기반일 수도 있음
  • 최대 성능에 초점
• 클라우드 기반 로드 밸런서
  • 공용 클라우드 인프라에 배포된 소프트웨어
  • 요청 원점에 더 가까이서 요청 처리

각 접근 방식에는 장점과 단점이 있어요. 온프레미스 로드 밸런서는 일반적으로 조직이 완전히 제어하는 사설 네트워크 내부에 존재해요. 이 로드 밸런서는 로드 밸런싱하는 엔드포인트와 함께 배치되므로 지연 시간과 RTT가 최소여야 해요. 온프레미스 로드 밸런서의 단점은 단일 물리적 위치로 제한된다는 점이에요. 즉 다른 지역의 트래픽은 RTT가 길고 응답 지연 시간이 높을 수 있어요. 또한 데이터 센터를 추가하려면 새 장비를 모두 구매하고 배포해야 해요. 온프레미스 로드 밸런서는 지리적으로 지역에 적합한 데이터 센터에서 요청을 라우팅하도록 하려면 일반적으로 지리적 트래픽 스티어링을 위한 클라우드 기반 로드 밸런서가 필요해요. 클라우드 기반 로드 밸런서의 장점은 랙 공간, 전원, 냉각, 유지 관리에 대한 걱정 없이 거의 모든 지리적 지역에서 작동할 수 있고 새 섀시, 모듈 또는 더 큰 네트워크 연결에 대한 걱정 없이 확장할 수 있다는 점이에요. 그러나 클라우드 기반 로드 밸런서는 일반적으로 트래픽을 스티어링하는 엔드포인트와 함께 배치되지 않으므로 로드 밸런서와 엔드포인트 사이의 지연 시간과 RTT를 증가시켜요.

Cloudflare Load Balancing 아키텍처와 설계

Cloudflare는 2016년부터 클라우드 기반 GTM을 제공했고 2023년부터 Private Network Load Balancing 기능을 추가하기 시작했어요. 이 섹션은 전체 Cloudflare Load Balancing 아키텍처를 검토하고 다양한 구성과 옵션을 깊이 있게 살펴봐요. 하지만 먼저 Cloudflare Load Balancer가 Cloudflare 글로벌 네트워크에서 실행됨으로써 얻는 이점을 이해하는 것이 중요해요.

Cloudflare 아키텍처의 내재적 장점

Cloudflare Load Balancing은 Cloudflare의 커넥티비티 클라우드 위에 구축돼요. 이는 모든 네트워크(엔터프라이즈 및 인터넷), 클라우드 환경, 애플리케이션, 사용자 간의 any-to-any 연결을 가능하게 하는 통합된 지능형 프로그래머블 클라우드 네이티브 서비스 플랫폼이에요. 330개 이상의 도시에 걸친 데이터 센터와 13,000개 이상의 네트워크 피어와의 상호 연결을 갖춘 세계에서 가장 큰 글로벌 네트워크 중 하나예요. 또한 많은 대형 기술 기업보다 핵심 인터넷 익스체인지에서 더 큰 존재감을 가져요.

그 결과 Cloudflare는 세계 인터넷 연결 인구의 약 95%로부터 약 50ms 이내에서 운영돼요. 그리고 모든 Cloudflare 서비스가 모든 네트워크 위치에서 실행되도록 설계되었기 때문에 모든 트래픽은 최상의 성능과 일관된 사용자 경험을 위해 소스에 가깝게 연결, 검사, 필터링돼요.

Cloudflare의 로드 밸런싱 솔루션은 anycast 기술 사용의 이점을 얻어요. Anycast는 Cloudflare가 전 세계 모든 데이터 센터에서 서비스의 IP 주소를 공지하여 트래픽이 항상 소스에 가장 가까운 Cloudflare 데이터 센터로 라우팅되도록 해요. 즉 트래픽 검사, 인증, 정책 적용이 최종 사용자 가까이에서 이루어져 지속적으로 높은 품질의 경험을 제공해요.

anycast를 사용하면 Cloudflare 네트워크가 잘 균형을 유지해요. 네트워크에 갑작스러운 트래픽 증가가 있으면 부하가 여러 데이터 센터에 분산될 수 있으며, 이는 사용자에게 일관되고 안정적인 연결을 유지하는 데 도움을 줘요. 또한 Cloudflare의 대규모 네트워크 용량과 AI/ML 최적화 스마트 라우팅도 성능이 지속적으로 최적화되도록 보장해요.

대조적으로 많은 다른 SaaS 기반 로드 밸런싱 제공업체는 단일 IP 주소가 단일 엔드포인트 및/또는 데이터 센터와 연결되는 Unicast 라우팅을 사용해요. 많은 이러한 아키텍처에서 단일 IP 주소는 특정 애플리케이션과 연결되며, 따라서 해당 애플리케이션에 접근하는 요청은 트래픽이 얼마나 멀리 이동해야 하는지에 따라 매우 다른 네트워크 라우팅 경험을 가질 수 있어요. 예를 들어 애플리케이션 엔드포인트 옆 사무실에서 일하는 직원에게는 성능이 우수할 수 있지만 원격 직원이나 해외에서 일하는 사람에게는 좋지 않을 수 있어요. Unicast는 또한 트래픽 부하 확장을 복잡하게 만들어요. 단일 서비스 위치는 부하가 증가할 때 리소스를 늘려야 하지만, anycast 네트워크는 많은 데이터 센터와 지역에 걸쳐 트래픽을 공유할 수 있어요.

그림 6은 Cloudflare 네트워크를 사용하면 지리적으로 분산된 사용자가 가능한 한 빠르게 리소스에 연결할 수 있는 방법을 보여줘요.

그림 6: Cloudflare 글로벌 anycast 네트워크에 호스팅된 로드 밸런서

위 그림 6은 Cloudflare가 모든 데이터 센터에서 모든 서비스를 실행하므로 각 데이터 센터에서 다른 Cloudflare 서비스도 실행 중임을 보여줘요. 사용자는 어디서나 일관된 경험을 얻게 돼요. 예를 들어 Cloudflare의 레이어 7 로드 밸런서는 DDoS 보호, CDN/캐시, Bot Management, WAF 같은 다른 서비스도 활용할 수 있어요. 이러한 추가 서비스는 모두 악성 요청(DDoS 보호, Bot Management, WAF에 의해 차단됨)이나 엔드포인트에 대한 요청 대신 캐시로 서빙될 수 있는 요청 등 불필요한 트래픽으로부터 서비스를 보호하는 데 도움을 줘요. 이러한 모든 서비스는 필요에 따라 결합되어 서비스나 오퍼링을 가능한 한 보호되고, 복원력 있고, 성능이 좋게 만들 수 있어요.

그림 7: HTTP 요청이 Cloudflare 레이어 7 스택에서 통과하는 일부 프로세스

Cloudflare는 또한 모든 데이터 센터에서 지속적으로 실행되는 네트워크 최적화 서비스 ↗︎를 보유하고 있어 Cloudflare 데이터 센터 사이의 최상의 경로를 제공하고 엔드포인트로의 모든 사용 가능 경로를 추적해요. 이를 통해 Cloudflare는 엔드포인트에 항상 도달할 수 있음을 보장하고, 필요한 경우 엔드포인트에 도달하기 위해 트래픽을 대체 Cloudflare 데이터 센터로 재라우팅해요. 로드 밸런서가 트래픽을 스티어링할 엔드포인트를 결정한 후 트래픽은 Cloudflare의 네트워크 최적화 서비스로 전달되어 목적지에 도달하는 최상의 경로를 결정해요. 이 경로는 Argo Smart Routing이라는 기능에 의해 영향을 받을 수 있으며, 이 기능을 활성화하면 타이밍이 맞춰진 TCP 연결을 사용해 엔드포인트에 가장 빠른 RTT를 가진 Cloudflare 데이터 센터를 찾아요. 그림 8은 Argo Smart Routing이 엔드포인트에 대한 연결 시간을 개선하는 방법을 보여줘요.

그림 8: Argo Smart Routing은 요청자와 엔드포인트 사이의 가장 빠른 경로를 찾는답니다

트래픽 흐름에 영향을 줄 수 있는 또 다른 방법은 Cloudflare Tunnels를 사용하는 것이에요. 이 문서는 다음 섹션에서 Cloudflare Tunnels를 깊이 있게 다뤄요. Cloudflare Tunnels는 엔드포인트를 특정 Cloudflare 데이터 센터에 연결하므로, 해당 엔드포인트를 위한 트래픽은 엔드포인트에 도달하기 위해 그 데이터 센터를 거쳐야 해요. 그림 9는 Cloudflare Tunnel을 통해 연결된 사설 엔드포인트에 대한 연결이 터널이 종료되는 데이터 센터를 통과해야 하는 방법을 보여줘요.

그림 9: Cloudflare Tunnel을 통해 엔드포인트를 연결할 때 엔드포인트로의 경로가 달라져요

일반적으로 GTM과 Private Network Load Balancer는 별도의 하드웨어이거나 별도의 SaaS(GTM)와 하드웨어 Private Network Load Balancing 구성 요소예요. Cloudflare의 GTM과 Private Network Load Balancing 기능은 단일 SaaS 오퍼링으로 결합되어 구성과 관리를 크게 단순화해요. GTM 로드 밸런서를 만들어 더 로컬한 Private Network Load Balancer로 트래픽을 스티어링할 필요가 없어요. 모든 엔드포인트를 Cloudflare에 직접 연결하고 트래픽을 올바른 지역, 데이터 센터, 엔드포인트로 단일 로드 밸런서 구성에서 모두 스티어링할 수 있어요. GTM과 Private Network Load Balancing 기능의 개념은 유지되지만, 그 구현은 로드 밸런서 구성을 가능한 한 단순하고 직관적으로 유지하는 방식으로 Cloudflare에서 이루어져요. 그림 10은 글로벌 트래픽이 필요에 따라 모든 지리적 지역에서 특정 엔드포인트로 스티어링될 수 있는 방법을 보여줘요.

그림 10: Cloudflare는 GTM과 Private Network Load Balancing 기능을 단일 로드 밸런서 구성으로 결합

Cloudflare Load Balancer의 구조

Cloudflare Load Balancer는 종종 가상 IP(VIP)라고도 하며, 엔트리포인트로 구성돼요. 일반적으로 이 엔트리포인트는 DNS 레코드예요. 로드 밸런서는 먼저 정의된 트래픽 스티어링 알고리즘을 적용하여 엔드포인트 풀(endpoint pool)을 선택해요. 엔드포인트 풀은 기능, 지리적 영역 또는 지역에 따라 선택된 엔드포인트 그룹이에요. 로드 밸런서 구성은 하나 또는 여러 엔드포인트 풀을 가질 수 있고, 각 엔드포인트 풀은 하나 또는 여러 엔드포인트를 가질 수 있어요. 엔드포인트 풀을 선택한 후 로드 밸런서는 엔드포인트 목록에 엔드포인트 스티어링 알고리즘을 적용해 트래픽을 스티어링할 엔드포인트를 선택해요. 그림 11은 Cloudflare Load Balancer 내에서 클라이언트 요청부터 엔드포인트까지의 기본 단계를 보여줘요.

그림 11: Cloudflare Load Balancer를 통한 기본 프로세스 흐름

Cloudflare Load Balancer의 정의는 세 가지 주요 구성 요소로 나뉘어요:

1. 상태 모니터(Health monitors): 엔드포인트의 상태를 관찰하고 정상(healthy) 또는 심각/비정상(critical)으로 분류하는 구성 요소
2. 엔드포인트 풀(Endpoint pools): 엔드포인트가 정의되고 상태 모니터와 엔드포인트 스티어링이 적용되는 곳
3. 로드 밸런서(Load balancers): 엔드포인트 풀 목록과 트래픽 스티어링 정책이 적용되는 구성 요소

다음 섹션들은 Cloudflare Load Balancer 구성 시 사용 가능한 옵션과 고려 사항을 자세히 설명해요. 엔드포인트 풀과 로드 밸런서 구성 모두에서 사용되는 스티어링부터 시작해요.

스티어링 유형과 방법

스티어링은 로드 밸런서의 핵심 기능이며, 스티어링 방법은 로드 밸런서가 작동할 때 어떤 엔드포인트가 선택될지를 궁극적으로 결정해요. 로드 밸런서 관점에서 스티어링은 두 가지 핵심 영역에 적용될 수 있어요.

첫 번째는 '트래픽 스티어링'이라 하며, 일반적으로 요청자의 근접성 또는 지리적 지역에 따라 어떤 엔드포인트 풀이 수신 요청을 처리할지 결정하는 역할을 해요. 트래픽 스티어링의 개념은 글로벌 트래픽 관리와 밀접하게 일치해요.

스티어링이 적용되는 두 번째 영역은 지역, 데이터 센터 또는 엔드포인트 풀이 선택된 후예요. 이 시점에서 로드 밸런서는 요청 또는 연결을 처리할 단일 엔드포인트를 선택해야 하며, 이를 '엔드포인트 스티어링'이라고 해요. 이 두 수준 모두에서 스티어링은 로드 밸런서를 배포하는 고객의 특정 요구에 맞춘 스티어링 방법을 적용하여 수행돼요. 선택할 수 있는 알고리즘은 여러 가지가 있지만 모든 알고리즘이 두 스티어링 유형 모두에 적용 가능한 것은 아니에요.

아래는 Cloudflare가 제공하는 모든 스티어링 방법에 대한 심층 리뷰예요. 이 섹션 끝에는 어떤 알고리즘이 어떤 사용 사례에 적용되는지 이해하는 데 도움이 되는 빠른 참조 표가 있어요.

트래픽 스티어링

트래픽 스티어링은 엔드포인트 풀이라고도 하는 엔드포인트 그룹을 선택해요. 트래픽 스티어링의 가장 흔한 용도는 최소 지연 응답 시간, 지리적 지역 또는 물리적 위치에 따라 엔드포인트 풀을 선택하는 것이에요. 트래픽 스티어링은 글로벌 트래픽 관리와 밀접하게 일치하며 트래픽을 엔드포인트로 안내하는 초기 단계 역할을 해요.

엔드포인트 스티어링

엔드포인트 스티어링은 요청 또는 연결을 받을 엔드포인트를 선택하는 역할을 해요. 엔드포인트 스티어링은 엔드포인트를 무작위로 선택하거나, 이전에 선택된 엔드포인트(세션 어피니티가 활성화된 경우), 또는 요청 또는 연결에 대해 가장 덜 사용되고 가장 빠르게 응답하는 엔드포인트를 선택하는 데 사용될 수 있어요. 엔드포인트 스티어링은 요청 또는 연결의 최종 목적지를 선택하는 역할을 하므로 Private Network Load Balancing과 밀접하게 관련돼요.

가중치 스티어링(Weighted steering)

가중치 스티어링은 로드 밸런서의 요청을 처리할 엔드포인트 풀과 엔드포인트의 차이를 고려해요. 모든 엔드포인트에 필수 필드인 엔드포인트 가중치는 특정 스티어링 방법이 선택된 경우에만 사용돼요. 마찬가지로 엔드포인트 풀 가중치도 특정 스티어링 방법이 선택될 때만 필요해요. 가중치가 언제 적용되는지에 대한 빠른 참조는 스티어링 옵션 개요 섹션을 참조해요.

가중치는 로드 밸런서 내에서 단일 요청 또는 연결에 대한 엔드포인트 풀 또는 엔드포인트 선택의 무작위성에 영향을 줘요. 가중치는 과거 데이터나 현재 연결 정보를 고려하지 않으므로 더 짧은 기간에는 분포에 변동이 있을 수 있어요. 그러나 더 긴 기간과 상당한 트래픽에서는 분포가 구성에 적용된 원하는 가중치와 더 가까워져요. 세션 어피니티는 초기 연결 이후 가중치 설정을 재정의한다는 점도 중요해요. 세션 어피니티는 후속 요청을 같은 엔드포인트 풀 또는 엔드포인트로 안내하기 위한 것이기 때문이에요. 그림 12는 선택될 확률이 동일한 두 엔드포인트 풀에 대한 가중치 예를 보여줘요.

그림 12: 선택될 확률이 동일한 두 엔드포인트 풀

Least Outstanding Request Steering 같은 특정 알고리즘은 열린 요청과 연결 수를 고려해요. 가중치는 어떤 엔드포인트 또는 엔드포인트 풀이 더 많은 수의 열린 요청 또는 연결을 처리할 수 있는지 결정하는 데 사용돼요. 본질적으로 가중치는 선택된 스티어링 방법과 무관하게 엔드포인트 또는 엔드포인트 풀의 용량을 정의해요.

가중치는 0.00과 1.00 사이의 임의의 숫자로 정의돼요. 엔드포인트 풀 또는 엔드포인트 풀 내 엔드포인트의 총 가중치가 1이 될 필요는 없다는 점에 유의해요. 대신 가중치가 함께 더해지고, 개별 가중치 값이 그 합으로 나뉘어 해당 엔드포인트가 선택될 확률을 얻어요.

가중치-백분율 방정식: (엔드포인트 가중치) ÷ (풀 내 모든 가중치의 합) = (엔드포인트로의 트래픽 %)

다음은 가중치가 트래픽 분배에 어떻게 사용되는지 이해하는 데 도움이 되는 몇 가지 예시와 다이어그램이에요. 이 예시에서 목표는 같은 용량 또는 컴퓨팅 리소스를 가진 모든 엔드포인트에 트래픽을 고르게 분배하는 것이라고 가정해요. Random 트래픽 스티어링을 사용해 세 개의 엔드포인트 풀에 걸친 트래픽 분배를 보여줄 거예요.

예시 1:

• 가중치가 모두 1인 세 개의 엔드포인트 풀이 정의됨
• 각 엔드포인트 풀은 선택될 확률이 33%
• 가중치 1에 대한 예시 계산: (1) ÷ (1 + 1 + 1) = (.3333) (또는 33.33%)

그림 13: 가중치가 동일한 세 개의 엔드포인트 풀

이 예시에서는 각 엔드포인트 풀의 모든 가중치 값에 1을 적용하는 것이 쉬웠어요. 그러나 세 엔드포인트 풀 모두에 같은 숫자를 사용하는 한 0.01과 1.00 사이의 임의의 숫자를 사용할 수 있었음을 유의해야 해요. 예를 들어 세 풀을 모두 .1이나 .7로 설정해도 각 풀이 트래픽을 받도록 선택될 확률이 동일해요.

가중치의 합이 확률을 계산하는 데 사용되므로 조직은 이러한 입력을 이해하기 쉽게 만들기 위해 임의의 값 개수를 사용할 수 있어요. 다음 예시에서는 각 엔드포인트가 동일한 용량을 가지므로 각 엔드포인트에 .1 가중치 값을 할당하고, 이 값들의 합을 엔드포인트 풀의 가중치로 사용해요.

예시 2

• 세 개의 엔드포인트 풀이 정의됨
• 각 엔드포인트 풀은 서로 다른 수의 엔드포인트를 가지지만 모든 엔드포인트는 동일한 용량
• 엔드포인트에 걸쳐 부하를 고르게 분배하려면 각 엔드포인트 풀에 다른 확률이 필요함

그림 14: 다른 용량의 엔드포인트 풀에 걸쳐 부하를 균형 있게 맞추기 위해 가중치를 사용하는 방법

가중치 .4에 대한 예시 계산: (.4) ÷ (.4 + .5 + .6) = (.2667) (또는 26.67%) 가중치 .5에 대한 예시 계산: (.5) ÷ (.4 + .5 + .6) = (.3333) (또는 33.33%) 가중치 .6에 대한 예시 계산: (.6) ÷ (.4 + .5 + .6) = (.4000) (또는 40.00%)

엔드포인트가 모두 동일한 용량을 갖지 않을 수도 있어요. 다음 예시에서 엔드포인트 풀 중 하나의 엔드포인트는 다른 두 엔드포인트 풀의 엔드포인트보다 용량이 두 배예요.

예시 3

• 세 개의 엔드포인트 풀이 정의됨
• 엔드포인트 풀 1의 엔드포인트는 엔드포인트 풀 2와 엔드포인트 풀 3의 엔드포인트에 비해 용량이 두 배
• 목표는 엔드포인트당 트래픽의 두 배를 엔드포인트 풀 1로 보내는 것
• 엔드포인트 풀 1은 엔드포인트가 4개이지만 용량이 두 배이므로 각 엔드포인트의 가중치는 .2, 엔드포인트 풀 전체로는 .8

그림 15: 다른 용량과 엔드포인트 수를 가진 엔드포인트 풀에 걸쳐 부하를 균형 있게 맞추기 위해 가중치를 사용

가중치 .8에 대한 예시 계산: (.4) ÷ (.8 + .5 + .6) = (.4211) (또는 42.11%) 가중치 .5에 대한 예시 계산: (.5) ÷ (.8 + .5 + .6) = (.2632) (또는 26.32%) 가중치 .6에 대한 예시 계산: (.6) ÷ (.8 + .5 + .6) = (.3157) (또는 31.57%)

이 마지막 예시에서 엔드포인트 풀 1의 네 엔드포인트는 다른 엔드포인트의 용량이 두 배이므로 계산은 엔드포인트 풀 1을 4개 대신 사실상 8개의 엔드포인트를 가진 것처럼 취급해요. 따라서 예시 2에 표시된 .4 대신 가중치 값이 .8이에요.

이것은 가중치를 사용해 엔드포인트 풀 또는 엔드포인트에 걸쳐 부하를 분배하는 방법을 보여주는 세 가지 간단한 예시일 뿐이에요. 엔드포인트 풀 내 엔드포인트에 적용되는 가중치에도 같은 계산이 사용돼요. 하지만 다른 스티어링 방법에서 가중치를 사용할 때의 영향은 유사하며, 아래 섹션에서 다루듯 계산이 약간 수정돼요.

가중치는 한 엔드포인트 풀이 다른 엔드포인트 풀보다 더 많은 리소스를 가질 때나 엔드포인트 풀 내 엔드포인트가 동일한 용량을 갖지 않을 때 가장 유용해요. 가중치는 모든 리소스가 주어진 능력에 비례해 동등하게 사용되도록 돕는답니다.

스티어링 방법

Off - failover

Off - failover는 가장 기본적인 트래픽 스티어링 정책이에요. 트래픽을 안내할 풀을 선택하기 위한 우선순위 목록으로 엔드포인트 풀의 순서를 사용해요. 목록의 첫 번째 풀이 정상이고 트래픽을 받을 수 있으면 그 풀이 선택돼요. Off - failover는 엔드포인트 스티어링에는 사용할 수 없으므로 엔드포인트를 선택하는 데 다른 스티어링 방법이 사용돼요. Off - failover는 주 데이터 센터 또는 엔드포인트 그룹이 트래픽을 처리하고 실패 조건에서만 백업 엔드포인트 풀로 트래픽이 스티어링되는 액티브/패시브 장애 조치 시나리오에서 흔히 사용돼요.

Random 스티어링

Random 스티어링은 트래픽 스티어링과 엔드포인트 스티어링 모두에서 사용할 수 있어요. Random은 로드 밸런서 구성과 엔드포인트 풀 내에서 정의된 가중치를 기반으로 리소스에 걸쳐 트래픽을 분산시켜요. 로드 밸런서에서 각 엔드포인트 풀에 설정된 가중치 값은 해당 엔드포인트 풀 내 엔드포인트별로 설정된 가중치 값과 다를 수 있어요. 예를 들어 로드 밸런서 구성 내에서 트래픽의 70%를 두 엔드포인트 풀 중 하나로 보낸 다음, 그 엔드포인트 풀 내에서 트래픽을 네 엔드포인트에 고르게 분배할 수 있어요. 이전 가중치 스티어링 섹션에서 가중치가 어떻게 사용되고 엔드포인트 풀 또는 엔드포인트 선택을 결정하는 계산에 대해 자세히 설명했어요.

Hash 스티어링

Hash 스티어링은 엔드포인트 가중치와 요청의 소스 IP 주소를 사용해 엔드포인트를 선택하는 엔드포인트 스티어링 알고리즘이에요. 결과적으로 같은 IP 주소의 모든 요청은 항상 같은 엔드포인트로 스티어링돼요. 엔드포인트의 순서를 변경하거나 엔드포인트 풀에서 엔드포인트를 추가 또는 제거하면 hash 알고리즘을 사용할 때 다른 결과가 나올 수 있다는 점에 유의해야 해요.

Geo 스티어링

Geo 스티어링은 엔터프라이즈 요금제 고객이 사용할 수 있는 트래픽 스티어링 알고리즘으로, 엔드포인트 풀을 특정 국가 또는 지리적 지역에 연결하는 데 사용돼요. 이 옵션은 트래픽을 사용자에게 더 가까운 엔드포인트로 스티어링하여 성능을 개선하는 데 유용해요. 또한 특정 지역의 사용자 요청을 같은 지역의 리소스나 특정 규제 요구 사항을 충족하도록 설계된 리소스로 스티어링하여 법률과 규정을 준수하는 데도 도움을 줘요.

Dynamic 스티어링

Dynamic 스티어링은 엔터프라이즈 요금제 고객이 사용할 수 있는 트래픽 스티어링 알고리즘으로 왕복 시간(RTT) 프로필을 만들어요. 상태 프로브 요청이 이루어질 때마다 RTT 값이 수집되고 엔드포인트의 모니터 요청에 대한 응답에 기반해요. 요청이 이루어지면 Cloudflare는 RTT 데이터를 검사하고 RTT 값으로 풀을 정렬해요. 특정 지역 또는 콜로케이션 센터에 풀의 기존 RTT 데이터가 없으면 Cloudflare는 장애 조치 순서로 풀에 트래픽을 안내해요. 엔드포인트 풀에 대해 dynamic 스티어링을 처음 활성화할 때는 Cloudflare가 해당 풀에 대한 RTT 프로필을 구축하므로 변경 사항이 적용되는 데 10분을 허용해요. Dynamic 스티어링은 의사 결정 과정에서 지리적 경계를 사용하지 않고 오직 가장 낮은 RTT 엔드포인트 풀을 선택하는 데만 집중해요.

Proximity 스티어링

Proximity 스티어링은 엔터프라이즈 요금제 고객이 사용할 수 있는 트래픽 스티어링 알고리즘으로, 요청이 시작된 위치에 따라 가장 가까운 물리적 데이터 센터로 트래픽을 스티어링해요.

Cloudflare는 다음 방법을 순서대로 사용해 요청자의 물리적 위치를 결정해요:

1. DNS 요청에 제공된 경우 EDNS Client Subnet ↗︎ 정보
2. Cloudflare에 도달하는 데 사용된 리졸버의 지리적 위치 정보
3. 요청을 처리하는 Cloudflare 데이터 센터의 GPS 위치

Proximity 스티어링은 모든 엔드포인트 풀에 대한 GPS 좌표 제공을 요구해요. 이를 통해 Cloudflare가 요청 IP, DNS 리졸버 또는 Cloudflare 데이터 센터에 기반해 가장 가까운 엔드포인트 풀을 계산할 수 있게 해요.

Least outstanding requests 스티어링 (LORS)

Least outstanding request 스티어링(LORS)은 엔터프라이즈 요금제 고객이 사용할 수 있으며 트래픽 스티어링과 엔드포인트 스티어링 모두에 사용될 수 있어요.

LORS는 응답되지 않은 HTTP 요청의 수를 사용해 스티어링에 영향을 주며 Cloudflare Layer 7 프록시 방식 Cloudflare Load Balancer와 함께 사용할 때만 기능해요. LORS가 다른 유형의 로드 밸런서에 할당되면 그 동작은 random 스티어링과 동일해요. LORS는 열린 요청 수와 가중치를 사용해 스티어링 결정에 사용되는 새 변환 가중치를 만들어요.

LORS 변환 가중치 방정식:

• weight / (count + 1) = transformedWeight

random 가중치 계산 기억:

• weight / (total weight) = probability of being selected

LORS 예시:

• Pool A의 가중치는 0.4
• Pool B의 가중치는 0.6
• Pool A에 열린 요청 3개
• Pool B에 열린 요청 0개
• 관련 방정식
  • weight / (count + 1) = transformedWeight
• Pool A의 변환 가중치: 0.4 / (3 + 1) = 0.1
• Pool B의 변환 가중치: 0.6 / (0 + 1) = 0.6
• 관련 방정식
  • weight / (total weight) = probability of being selected
• Pool A로 스티어링될 확률: 0.1 / (0.1+0.6) = .1429 (14.29%)
• Pool B로 스티어링될 확률: 0.6 / (0.1+0.6) = .8571 (85.71%)

이 예시에서 다음 연결은 14.29%의 확률로 Pool A로, 85.71%의 확률로 Pool B로 스티어링돼요. 트래픽이 Pool B로 스티어링될 가능성이 높지만 Pool A로 스티어링될 가능성도 여전히 있어요. 부하가 가벼운 상황에서는 스티어링 결과에 더 많은 변동이 있어 구성된 가중치와 정확히 일치하지 않을 수 있어요. 그러나 부하가 증가함에 따라 실제 스티어링 결과는 구성된 가중치와 밀접하게 일치해요.

비 L7 프록시 로드 밸런서를 LORS와 함께 사용하면 열린 요청 수 정보를 사용할 수 없어요. 결과적으로 분모는 항상 1이 돼요. 어떤 숫자를 1로 나누어도 분자가 바뀌지 않고, 이 경우 분자는 가중치이므로 스티어링 결정은 가중치에만 기반해 이루어져요. 이는 위에서 설명한 random 방법을 초래해요.

LORS는 엔드포인트 풀 또는 엔드포인트가 동시 요청 급증에 쉽게 압도될 때 가장 잘 사용돼요. 지연 시간, 지리적 정렬 또는 기타 지표 같은 요인보다 엔드포인트 상태를 중요시하는 애플리케이션에 적합해요. 이는 일부 또는 모든 요청이 엔드포인트에 부하를 크게 가하고 응답을 생성하는 데 상당한 시간이 걸릴 때 특히 유용해요.

스티어링 옵션 개요

Steering Method	Traffic Steering	Endpoint Steering	Weight-based	Enterprise-only
Off - Failover	X
Random	X	X	X
Hash		X	X	X
Geo	X			X
Dynamic	X			X
Proximity	X			X
Least Outstanding Requests	X	X	X	X

위에서 Enterprise-only로 표시된 모든 트래픽 스티어링 방법은 셀프 서비스 애드온으로도 얻을 수 있어요. Enterprise-Only로 표시된 모든 엔드포인트 스티어링 방법은 Cloudflare와의 엔터프라이즈 요금제가 필요해요.

상태 모니터(Health monitors)

상태 모니터는 엔드포인트 풀 내에 구성된 후 엔드포인트의 상태를 결정해요. 상태 모니터는 프로브(probes)를 생성하며, 이는 엔드포인트에 대한 연결 시도예요. 상태 모니터는 프로브에 대한 응답을 사용해 엔드포인트 상태를 기록해요. 상태 모니터는 서비스 유형, 경로, 포트와 간격, 타임아웃, 프로토콜별 엔드포인트 상태 평가 설정 같은 고급 기능을 포함하는 템플릿 역할을 해요. 상태 모니터 템플릿은 그런 다음 유사한 서비스를 호스팅하는 엔드포인트를 포함하는 엔드포인트 풀에 적용돼요. 상태 모니터가 엔드포인트 풀에 연결되면 엔드포인트 주소가 상태 모니터 프로브의 목적지로 사용돼요. 단일 상태 모니터는 많은 엔드포인트 풀에서 사용될 수 있으며, 상태 모니터는 계정 수준 객체로 같은 Cloudflare 계정 내 여러 존에서 활용될 수 있어요.

기본적으로 상태 모니터 프로브는 전체 레이어 7 스택을 우회하여 엔드포인트 주소로 직접 전송돼요. 이는 로드 밸런서를 통해 엔드포인트로 가는 실제 트래픽이 상태 모니터 프로브와 다른 처리를 받는다는 뜻이에요. 구성에 따라 실제 연결 또는 요청이 실패하는데도 상태 모니터가 엔드포인트를 정상으로 보고할 수 있어요.

Simulate Zone 기능은 상태 모니터 프로브가 주어진 존에 대한 레이어 7 HTTP/HTTPS 요청과 같은 경로를 따라가도록 보장해요. 동일한 Cloudflare 소프트웨어 정의 라우팅을 통과해 오리진으로의 이그레스(eEgress)를 제공해요. 이는 상태 모니터가 오리진 엔드포인트에 도달하기 위해 Cloudflare 네트워크와 기타 레이어 7 프로세스를 통해 같은 경로를 취하도록 보장해요.

Simulate Zone 기능은 Authenticated Origin Pulls 또는 Origin CA 같은 일부 기능이 존 수준에서 활성화된 경우 상태 모니터에 필수예요. 오리진 서버와의 인증을 위한 적절한 mTLS 인증서 또는 기관이 제공되지 않으면 프로브가 실패하기 때문이에요. Simulate Zone은 또한 조직이 엔드포인트에 도달하기 위해 Cloudflare가 사용하는 에지 IP 주소를 제한하기 위해 Smart Shield Advanced를 활용할 때 상태 모니터 프로브가 Argo Smart Routing이 제공하는 것과 같은 경로와 동일한 Dedicated CDN Egress IPs를 사용하도록 보장해요.

그림 16: HTTPS 상태 모니터 구성

상태 모니터 프로브는 다음 유형으로 구성할 수 있어요:

• HTTP
• HTTPS
• TCP
• UDP ICMP
• ICMP Ping
• SMTP
• LDAP

상태 모니터가 정의되면 엔드포인트에 할당될 수 있고 프로브는 정의된 간격으로 엔드포인트에 전송돼요. 엔드포인트 풀 내 상태 모니터 구성과 관련해 주의할 추가 설정 두 가지가 있어요. 첫 번째는 Health Threshold로, 풀 내에서 풀이 정상 또는 저하된 것으로 간주되기 위해 몇 개의 엔드포인트가 정상이어야 하는지 결정하는 데 사용돼요.

• 정상 상태의 엔드포인트 풀
  • 정상 엔드포인트만 포함
• 저하 상태의 엔드포인트 풀
  • 최소 하나의 심각 엔드포인트를 포함하지만 health threshold 설정 이상으로 유지됨
• 심각 상태의 엔드포인트 풀
  • health threshold 미만의 정상 엔드포인트 포함
  • 트래픽 처리 불가; 모든 스티어링 결정에서 제외됨

그림 17: 엔드포인트 풀이 정상, 저하, 또는 심각으로 간주되는 시점

엔드포인트 풀에서 상태 모니터를 정의한 후 두 번째 설정은 상태 모니터 프로브가 Cloudflare 글로벌 네트워크 내부의 어떤 지역에서 시작되어야 하는지 정의하는 것이에요. 사용 가능한 선택은 아래와 같아요:

• All Regions (Default)
• All Data Centers (Enterprise Only)
• Western North America
• Eastern North America
• Western Europe
• Eastern Europe
• Northern South America
• Southern South America
• Oceania
• Middle East
• Northern Africa
• Southern Africa
• Southern Asia
• Southeast Asia
• Northeast Asia

그림 18: 엔드포인트 풀 구성에 대한 Health Threshold 및 지역 선택

"All Regions" 및 "All Data Centers"를 제외하고, 상태 모니터 프로브는 선택된 지역 또는 지역들의 데이터 센터에서만 시작돼요. 로컬 관련 서비스의 경우 세계 반대편 데이터 센터가 엔드포인트에 도달할 수 있는지 여부는 중요하지 않을 수 있어요. 따라서 검사를 특정 지역 또는 지역 집합으로 제한하는 것이 합리적일 수 있어요. "All Regions" 또는 "All Data Centers" 선택은 엔드포인트 집합에 도달하는 것이 애플리케이션 기능에 중요할 수 있는 전 세계적으로 사용 가능한 서비스를 위해 사용하기 위한 것이에요.

엔드포인트와 엔드포인트 풀

엔드포인트는 로드 밸런서가 모든 정책을 적용한 후 연결과 요청을 처리하는 실제 서버예요. 엔드포인트는 물리적 서버, 가상 머신 또는 서버리스 애플리케이션일 수 있어요. 사용자 또는 클라이언트의 요청이나 연결을 처리할 수 있으면 엔드포인트로 간주될 수 있어요. 엔드포인트를 정의하고 Cloudflare에 연결하는 방법은 여러 가지가 있으며 다음 섹션에서 이러한 방법을 자세히 설명해요.

엔드포인트를 Cloudflare에 연결하기

Cloudflare 엔드포인트는 IP 주소 또는 호스트 이름 두 가지 방식으로 정의할 수 있어요. IP 주소는 가장 간단하고 기본적인 연결 방법이며, 호스트 이름은 고려할 몇 가지 옵션을 제공해요. 호스트 이름은 Cloudflare DNS에서 정의될 수 있고 프록시되거나 DNS 전용(비프록시)일 수 있어요. 또 다른 옵션은 물론 호스트 이름이 Cloudflare가 권위 DNS 서버인 도메인에 있지 않은 경우로, Cloudflare는 외부 DNS 서버에 의존해 그 호스트 이름을 IP 주소로 해석해요. Cloudflare Tunnel도 사용할 수 있으며 두 가지 다른 옵션을 제공해요. 이러한 방법은 이 섹션에서 아래에서 설명돼요.

Cloudflare 프록시, DNS, IP, 비 Cloudflare 엔드포인트

위 "HTTP(S) Load Balancing" 섹션에서 언급했듯이 로드 밸런싱은 요청이 엔드포인트로 전송되기 전에 실행되는 가장 마지막 프로세스예요. 그러나 엔드포인트가 Cloudflare 에지를 통해 프록시되더라도 로드 밸런서 이후에는 요청이 레이어 7 스택을 다시 통과하지 않고 엔드포인트로 직접 전달돼요. 이는 엔드포인트가 보호되지 않거나 캐시되지 않는다는 뜻은 아니에요. 로드 밸런서 자체가 프록시되면 이러한 모든 보호가 엔드포인트가 아닌 로드 밸런서에 제공돼요. 엔드포인트와의 직접 통신은 여전히 프록시되고 Cloudflare 레이어 7 스택으로 처리될 수 있지만, 엔드포인트와의 통신은 모든 처리를 로드 밸런서 앞에, 엔드포인트가 아닌 로드 밸런서 앞에 배치해요. 그림 19는 Cloudflare 레이어 7 스택이 엔드포인트(들)와 관련하여 배치되는 위치의 차이를 보여줘요.

그림 19: 로드 밸런서와 엔드포인트 사이의 레이어 7 경로 차이

로드 밸런서 관점에서 엔드포인트 풀의 일부로 정의되는 엔드포인트 유형에 따른 차이는 거의 없어요. 트래픽 및 엔드포인트 스티어링 정책과 로드 밸런서 규칙이 적용되면 Cloudflare Load Balancing 서비스는 L7 스택에 수신 요청 또는 연결을 전달할 위치를 지시해요. 이 요청은 엔드포인트로 직접 전송돼요. 엔드포인트에 대한 연결 유형에 따라 다른 경로가 있을 수 있어요. Argo Smart Routing 또는 다른 Cloudflare 데이터 센터에서 종료되는 터널 연결 엔드포인트 같은 기능은 요청을 Cloudflare 에지 밖으로, 인터넷을 통해 엔드포인트로 직접 보내는 대신 트래픽을 다르게 라우팅해요. 그러나 어떤 경로든 로드 밸런싱은 스택의 마지막 프로세스이며 이는 트래픽이 추가 처리를 받지 않는다는 뜻이에요. 엔드포인트에 대한 연결은 Cloudflare에서 엔드포인트로의 경로를 바꿀 수 있지만, 엔드포인트가 선택된 후에는 처리나 처리가 바뀌지 않아요.

Cloudflare Tunnel

Cloudflare Tunnel은 조직이 방화벽 구성을 단순화하고, 복잡성을 줄이며, 보안을 강화하고, 자산을 Cloudflare 네트워크에 더 쉽게 연결할 수 있게 해주는 아웃바운드 연결이에요. 이러한 터널을 만드는 실행 파일은 cloudflared라고 하며 이 문서와 다음 다이어그램에서 참조될 수 있어요.

Cloudflare Tunnel(cloudflared)은 엔드포인트 자체 또는 엔드포인트에 대한 IP 연결이 있는 모든 서버에 직접 설치할 수 있어요. Cloudflare에 대한 연결은 Cloudflare Tunnel이 설치된 위치에서 Cloudflare로 시작되므로 필요한 유일한 접근은 Cloudflare로의 아웃바운드 접근이에요. 단일 Cloudflare Tunnel은 두 가지 방법 중 하나로 하나 또는 여러 다른 엔드포인트에 트래픽을 전송할 수 있어요. 한 방법은 엔드포인트를 공개적으로 접근 가능하게 만들고, 다른 방법은 엔드포인트를 완전히 비공개로만 접근 가능하게 유지해요.

Cloudflare Tunnel은 엔드포인트 자체 또는 Cloudflare에 연결해야 하는 엔드포인트(들)에 대한 레이어 3(IP) 연결이 있는 모든 서버에 설치할 수 있어요. cloudflared를 분리하기로 결정하는 이유는 다양할 수 있어요. 엔드포인트(들)를 격리하고 성능을 보장하거나, 네트워크 수준 연결과 엔드포인트를 관리하는 별도의 팀이 있거나, 서버가 분리된 역할 또는 책임을 가지는 아키텍처 단순화를 위한 것 등이지만 이에 국한되지는 않아요.

그림 20: 별도 서버에 배포된 공유 cloudflared가 여러 엔드포인트에 대한 터널을 전송

단일 cloudflared 인스턴스는 서로 다른 두 Cloudflare 데이터 센터에 각각 두 개씩 총 4개의 다른 터널을 만들 거예요. 이 모델은 높은 가용성을 보장하고 개별 연결 실패의 위험을 완화해요. 즉 단일 연결, 서버 또는 데이터 센터가 오프라인이 되더라도 엔드포인트는 계속 사용 가능해요. Cloudflare Tunnel은 또한 조직이 가용성 및 장애 조치 시나리오를 위해 추가 cloudflared 인스턴스를 배포할 수 있게 해요. 이러한 고유 인스턴스를 레플리카(replicas)라고 해요. 각 레플리카는 엔드포인트(들)에 대한 추가 인그레스 지점 역할을 하는 4개의 새 연결을 설정해요. 각 레플리카는 같은 터널을 가리켜요. 이는 cloudflared를 실행하는 단일 호스트가 다운되더라도 네트워크가 계속 유지되도록 보장해요. 설계상 레플리카는 어떤 수준의 트래픽 스티어링(random, hash, round-robin)도 제공하지 않아요.

공용 호스트 이름(Public hostname)

공용 엔드포인트 메서드는 조직이 엔드포인트에서 실행 중인 특정 서비스 또는 포트를 가리키는 터널을 정의할 수 있게 해요. 터널은 엔드포인트에서 또는 엔드포인트에 대한 IP 연결이 있는 모든 서버에서 종료될 수 있어요. 이 공용 호스트 이름 메서드를 사용하려면 터널을 통해 접근할 각 서비스가 터널 구성에 정의되어야 해요. 구성되면 터널이 트래픽을 연결하는 IP와 포트 또는 서비스에 대해 d74b3a46-f3a3-4596-9049-da7e72c876f5 같은 고유 터널 ID가 생성돼요. 이 터널 ID는 Cloudflare 소유 도메인인 cfargotunnel.com에서 고유 공용 호스트 이름으로 만들어져 해당 서비스를 직접 가리키는 DNS A 레코드, 즉 d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com이 생성돼요. 이 호스트 이름은 공용이지만 Cloudflare Tunnel 구성을 소유한 계정을 통해 전송되는 트래픽에 의해서만 접근되거나 활용될 수 있어요. 다른 계정은 이 DNS 주소로 직접 접근하거나 트래픽을 보낼 수 없어요. cfargotunnel.com 호스트 이름을 소유한 계정 밖에서 생성된 DNS CNAME 레코드는 해당 특정 Cloudflare Tunnel을 통해 트래픽을 보낼 수 없어요.

대시보드를 통해 구성하면 Cloudflare는 cfargotunnel.com 호스트 이름을 가리키는 DNS 존에 CNAME 레코드를 자동으로 만들어요. 예를 들어 myTunnelService.example.com의 CNAME 레코드를 만들어 d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com의 A 레코드를 가리킬 수 있어요. 주요 이점은 사용과 관리의 용이성이에요. CNAME 레코드가 그 목적에 대해 훨씬 더 암시적이고 고객 DNS 존에 속하기 때문이에요.

또 다른 옵션은 cloudflared를 실행하는 호스트에서 이러한 터널과 서비스를 만드는 것이에요. 이를 로컬 관리형 터널(locally-managed tunnel)이라고 해요. 로컬 관리형 터널을 사용할 때 CNAME 항목은 자동으로 생성되지 않으므로 조직은 터널과 서비스가 정의된 후 이를 수동으로 구성해야 해요.

로드 밸런서 관점에서 이러한 터널을 엔드포인트로 어떻게 사용할 수 있는지 이해하는 것은 매우 중요해요. 엔드포인트는 cfargotunnel.com 호스트 이름을 사용해서만 정의할 수 있어요. cfargotunnel.com 주소를 가리키는 공용 CNAME 레코드를 사용하는 것은 제대로 작동하지 않으며 지원되지 않아요. 이는 포트 80 또는 443에서 작동하지 않는 엔드포인트 서비스에 특히 중요해요. Cloudflare Load Balancer는 이 두 포트를 기본값으로 사용해 엔드포인트에서 실행되는 서비스에 접근해요. 조직이 다른 포트에서 실행되는 서비스를 가지고 있다면 해당 포트에 도달하기 위해 catch-all 규칙이 있는 Cloudflare Tunnel을 구성해야 해요. 이 구성은 Cloudflare Load Balancer가 포트 443을 통해 서비스에 도달할 수 있게 하면서 Cloudflare 터널이 엔드포인트의 원하는 포트로 연결을 프록시하게 해요.

사설 IP(Private IP)

두 번째 메서드는 사설 서브넷용이에요. 이 메서드는 조직이 사설 IP 주소와 서브넷 마스크를 정의할 수 있게 해주며, 이는 Cloudflare 글로벌 네트워크 내에 사설 가상 네트워크를 만드는 데 사용돼요. 사설 서브넷 메서드는 포트 정의를 허용하지 않으므로 서브넷과 마스크가 정의되면 전체 서브넷이 그 터널을 통해 도달될 수 있지만 정의된 Zero Trust 정책을 통해 접근이 허용된 조직 내 사용자에게만 가능해요.

이 서브넷은 그런 다음 Cloudflare 내부의 가상 네트워크에 추가되어 고객이 사용자가 어떻게 접근할 수 있고 어떤 사용자가 접근할 수 있는지 제어할 수 있어요. 이 서브넷은 32비트 마스크(단일 IP 주소, 즉 10.0.0.1/32) 사용을 포함해 원하는 subletting 또는 라우팅을 위해 정의될 수 있어요. 허용된 서브넷은 cloudflared 프로세스를 실행하는 호스트에 존재할 필요도 없어요. 필요한 것은 cloudflared를 실행하는 호스트와 Cloudflare Tunnel을 통해 도달할 수 있는 서브넷 사이의 레이어 3 또는 IP 연결뿐이에요.

엔드포인트 풀 세부 사항

엔드포인트 풀 내에는 여러 구성 옵션이 있어요. 이 섹션은 이러한 구성 옵션이 무엇이고 Cloudflare Load Balancer의 동작을 어떻게 바꾸는지 자세히 설명해요.

엔드포인트 스티어링

엔드포인트 풀의 이름과 설명을 정의하는 것 외에 첫 번째 구성은 엔드포인트 스티어링 방법을 결정하는 것이에요. 엔드포인트 스티어링은 요청 또는 연결 시도를 받을 엔드포인트 풀 또는 엔드포인트를 궁극적으로 선택하는 역할을 해요(각 방법에 대한 자세한 설명은 Steering methods 섹션을 참조해요).

엔드포인트

개별 엔드포인트는 엔드포인트 풀 내에 정의되며, 엔드포인트 풀은 풀당 하나 이상의 엔드포인트 정의를 허용해요.

• 엔드포인트 이름은 주로 참조, 보고, 분석에 사용돼요. 로드 밸런서 또는 엔드포인트 풀의 기능에는 영향을 주지 않아요.
• 그러나 엔드포인트 주소는 로드 밸런서가 요청 또는 연결을 처리하는 데 사용할 수 있는 리소스를 정의해요.
  • 엔드포인트 풀 내 엔드포인트는 포트 80 또는 443을 통해 접근 가능해야 해요. 엔드포인트가 포트 80 또는 443에서 수신하지 않는다면 서비스가 실제로 수신하는 포트에 포트 80 또는 443을 매핑하기 위해 프록시 서비스 또는 네트워크 포트 포워딩 장치를 엔드포인트 앞에 배치해야 해요.
  • 엔드포인트의 포트를 80 또는 443에 매핑하는 또 다른 방법은 Cloudflare Tunnel을 사용해 엔드포인트 서비스에 연결하고 그 프로세스를 통해 만들어진 호스트 이름을 엔드포인트 주소로 사용하는 것이에요. 이는 의도된 엔드포인트 포트를 포트 443에 자동으로 매핑해요.

엔드포인트 주소는 다음 중 한 가지 방식으로 정의할 수 있어요:

• 공용 라우팅 가능 IP 주소
• Cloudflare 프록시 공용 도달 가능 호스트 이름
• 공용 도달 가능 비 Cloudflare 호스트 이름
• 가상 네트워크 선택과 함께 사설, 비공용 라우팅 가능 IP 주소

가상 네트워크(Virtual networks)

공용 IP와 모든 유형의 호스트 이름을 사용하면 추가 구성이 필요 없어요. 이러한 시나리오에서 가상 네트워크는 기본값인 "none"으로 설정해야 해요. "none" 설정은 이러한 리소스가 Cloudflare의 글로벌 에지 네트워크를 통해 라우팅되는 공용 인터넷에서 접근 가능함을 신호해요.

virtual network 옵션의 사용은 사설 IP 리소스를 위해 예약돼 있어요. 이 설정은 Cloudflare Tunnel 구성 뒤에 호스팅되는 IP 서브넷에 매핑해요. 엔드포인트의 IP 주소에 대한 경로가 있는 가상 네트워크를 선택해야 해요. Cloudflare Dashboard에서 이 설정으로 이동하려면 Zero Trust 페이지에서 Networks - Routes를 선택해요.

엔드포인트 가중치

엔드포인트 가중치는 random, hash, least outstanding request 스티어링 방법에만 사용되며 항상 엔드포인트 정의의 일부로 정의되어야 해요. (가중치가 엔드포인트 선택에 어떻게 사용되는지에 대한 자세한 내용은 Weighted Steering 섹션을 참조해요.)

호스트 헤더 수정

엔드포인트 풀은 요청을 엔드포인트로 전달하기 전에 호스트 헤더를 수정할 수 있게 해요. 이 구성은 HTTP(S) 레이어 7 로드 밸런서에만 적용돼요(사설 IP 및 Spectrum을 포함한 레이어 4 로드 밸런서와 함께 사용하면 무시돼요).

요청이 HTTP(S) 기반인 레이어 7 로드 밸런서 내에서 Host 헤더는 단일 엔드포인트가 여러 다른 웹 도메인을 호스팅할 수 있으므로 어떤 웹사이트가 요청되고 있는지 엔드포인트에 알려줘요. 엔드포인트가 웹 도메인을 호스팅하도록 특별히 구성된 경우, Host 헤더에 요청된 리소스를 호스팅한다고 생각하지 않으면(즉 Host 헤더가 일치하지 않으면) 리소스 요청에 응답하지 않거나 실패 응답을 보낼 수 있어요.

예를 들어:

• 사용자가 www.example.com에 도달하려 한다고 가정해요. 로드 밸런서는 모든 요청을 받도록 www.example.com의 호스트 이름으로 구성될 거예요.
• 엔드포인트는 DNS에서 같은 공용 호스트 이름을 가질 수 없으므로 그 호스트 이름은 endpoint1.example.com이에요.
• 사용자가 www.example.com에 요청을 하면 Host 헤더도 www.example.com으로 설정돼요. 엔드포인트는 www.example.com의 Host 헤더에 응답하도록 구성되어야 해요.
• 그러나 일부 경우(특정 클라우드 또는 SaaS 애플리케이션 같은) 엔드포인트는 그런 방식으로 구성할 수 없어서, 엔드포인트가 알 수 없는 Host 헤더로 요청을 받고 적절히 응답하지 못할 수 있어요.
• 이 예시에서 엔드포인트 구성의 호스트 헤더를 엔드포인트 주소인 endpoint1.example.com으로 설정하면 www.example.com의 Host 헤더를 endpoint1.example.com으로 대체하고 엔드포인트가 이 요청에 적절히 응답할 수 있게 돼요.

그림 21은 일치하지 않는 Host 헤더의 잠재적 문제를 보여줘요:

그림 21: 로드 밸런서가 Host 헤더를 엔드포인트에 맞게 다시 쓰는 방법

또한 엔드포인트 풀에서 (proximity 트래픽 스티어링과 함께 사용되는) 풀의 GPS 좌표를 정의할 수 있어요. Proximity 스티어링을 사용하지 않는다면 이러한 좌표는 필요하지 않아요(Proximity Steering 참조).

로드 셰딩(Load shedding)

로드 셰딩 — 풀 내 엔드포인트가 비정상이 되어가는 것을 보호하기 위해 관리자에게 제공되는 실시간 응답 — 도 엔드포인트 풀에서 구성돼요.

로드 셰딩 설정은 관리자가 엔드포인트 풀이 비정상이 되는 것을 적극적으로 보호하려고 할 때가 아니면 활성화하기 위한 것이 아니에요. 예를 들어 여전히 요청에 응답하는 엔드포인트가 CPU나 메모리 사용량 증가, 응답 시간 증가, 또는 가끔 전혀 응답하지 못하는 상황이 발생할 때 활성화돼요.

엔드포인트 풀의 상태가 저하되기 시작하면 로드 셰딩은 기존 부하의 일부를 한 엔드포인트 풀에서 다른 풀로 안내하는 데 도움을 줄 수 있어요.

엔드포인트 풀의 상태에 따라 엔드포인트 풀에서 새 요청과 연결을 셰딩하거나 리디렉션하는 것만으로 충분할 수 있어요. 이 정책은 세션 어피니티 규칙의 적용을 받지 않는 트래픽에 적용돼요. 아직 엔드포인트 풀 또는 엔드포인트가 선택되지 않은 새 연결이기 때문이며, 따라서 최종 사용자 경험에 잠재적으로 영향을 주지 않아요.

엔드포인트 풀이 부하로 인해 심각한 실패에 가까워지면 다음 옵션은 추가 세션 어피니티 트래픽을 셰딩하는 것이에요. 이는 세션 어피니티를 통해 엔드포인트 풀에 바인딩된 요청과 연결도 리디렉션하기 시작할 거예요. 그러나 이 프로세스는 궁극적으로 사용자의 엔드포인트를 변경할 수 있으므로 최종 사용자 경험에 영향을 줄 수 있음을 유의해야 해요. 궁극적으로 그 영향은 로드 밸런싱되는 애플리케이션과 엔드포인트 간에 공유되는 연결 컨텍스트의 양에 의해 결정돼요.

상태 모니터

상태 모니터는 엔드포인트 풀의 엔드포인트에 health threshold와 상태 점검 지역 선택과 함께 연결돼요. 이러한 옵션의 세부 사항은 health monitor 섹션에서 찾을 수 있어요.

로드 밸런서

Cloudflare 내 로드 밸런싱은 GTM과 Private Network Load Balancing을 단일 로드 밸런서 구성으로 결합해요. 특정 기능이나 용어가 GTM 또는 Private Network Load Balancing과 더 일치할 수 있지만, Cloudflare 고객에게는 둘 다 관리하기 쉬운 단일 인스턴스로 결합돼요.

조직은 특정 사용 사례에 따라 다양한 유형의 Cloudflare Load Balancer를 활용할 수 있어요. 다음 섹션은 배포 모델 간의 주요 차이점을 강조하고 각 유형의 로드 밸런서를 언제 구현해야 하는지 설명해요.

그림 22는 Cloudflare가 지원하는 로드 밸런서와 엔드포인트의 모든 가능한 조합을 강조해요:

그림 22: 공용 및 사설 로드 밸런서와 엔드포인트의 조합과 연결 방식

배포 모델

Cloudflare는 세 가지 로드 밸런싱 배포 모델을 제공하며, 각각 다른 사용 사례, 기능, 개인정보 요구 사항을 지원해요.

• Layer 7 HTTP(S) load balancing
• DNS-only load balancing
• Spectrum load balancing

아래에서 더 자세히 설명하는 DNS 전용 로드 밸런싱 옵션을 제외하고, 모든 배포 모델은 로드 밸런서를 통해 트래픽을 고정시켜요. 이는 요청 또는 연결을 만드는 사용자 또는 클라이언트가 요청 또는 연결을 서비스하는 데 사용되는 엔드포인트를 인지하지 못한다는 뜻이에요. 엔드포인트 정보는 원한다면 헤더 사용을 통해 확실히 노출될 수 있지만, 이러한 고정 배포 모델 중 어떤 것에서도 기본 동작은 아니에요.

다음은 네 가지 주요 배포 모델(과 그 차이점)을 더 자세히 탐구해요.

Layer 7 HTTP(S) 로드 밸런싱

먼저 가장 흔한 모델은 HTTP(S) 기반 레이어 7 프록시 로드 밸런서예요. 이러한 로드 밸런서는 Cloudflare 에지에 존재하며 공용으로 도달 가능해요. 다른 기능들 중에서도 이 모델은 클라이언트와 엔드포인트 사이의 열린 연결로 둘 사이에 데이터가 앞뒤로 전달될 수 있게 하는 WebSockets을 지원해요.

이 동일한 레이어 7 보안 스택이 WAF, DDoS 보호, Bot Management, Zero Trust 및 기타 서비스를 제공하므로 필요에 따라 인증되고 권한 있는 사용자로 제한해 이러한 공용 로드 밸런서에 접근할 수 있게 할 수 있어요. (Securing Load Balancers 참조.)

이 레이어 7 스택에서 로드 밸런싱은 조직의 공용 웹 자산의 성능, 신뢰성, 도달성을 더욱 개선할 수 있어요. 이러한 로드 밸런서의 엔드포인트는 공용 클라우드, 사설 클라우드, 온프레미스, 또는 같은 로드 밸런서 내에서 이들의 조합에 배포될 수 있어요. (엔드포인트를 Cloudflare 에지 네트워크에 연결하는 방법에 대한 자세한 내용은 Connecting endpoints to Cloudflare를 참조해요.)

그림 23: Cloudflare 레이어 7 로드 밸런서가 공용 및 사설 엔드포인트 모두로 트래픽을 스티어링하는 방법

위 그림 23에서 볼 수 있듯이 레이어 7 스택의 로드 밸런싱 구성 요소는 요청이 엔드포인트로 이동할 때 실행되는 마지막 프로세스예요. 이는 성능을 높이고 엔드포인트의 부하를 줄이는 데 큰 긍정적 영향을 줄 수 있어요.

예를 들어 캐싱은 요청이 엔드포인트에 도달하는 것을 방지하고 로드 밸런서를 사용하지 않고도 응답할 수 있어요. 또한 WAF, DDoS 보호, Bot Management는 공격 트래픽을 완전히 제거하여 합법적인 트래픽을 위한 용량을 더 확보해요.

요청이 로드 밸런서 프로세스에 도달하면 요청은 항상 선택된 엔드포인트로 직접 전송돼요. 이는 엔드포인트가 Cloudflare를 통해 프록시되더라도 요청이 엔드포인트로 직접 전송되고 더 이상의 처리를 받지 않는다는 뜻이에요.

로드 밸런서가 엔드포인트를 선택한 후 사용자 지정 처리를 위해 로드 밸런서의 Custom Rules가 적용돼요. (이에 대한 자세한 내용은 아래 Load balancers 섹션에서 다뤄요.)

Layer 7 HTTP(S) 로드 밸런서에 대한 중요 참고 사항:

• Layer 7 HTTP(S) 로드 밸런서는 공용 및 사설 엔드포인트를 모두 지원
• Layer 7 HTTP(S) 로드 밸런서는 HTTP(S) 및 WebSocket 트래픽만 지원
• Layer 7 HTTP(S) 로드 밸런서에 Zero trust 정책을 적용할 수 있음

DNS 전용 로드 밸런싱

Cloudflare의 DNS 전용 로드 밸런서는 비프록시 로드 밸런서예요. 이는 리소스에 대한 초기 DNS 요청만 — 실제 트래픽이 아닌 — Cloudflare 에지를 통과한다는 뜻이에요. 따라서 앞서 그림 7에서 본 것처럼 DNS 요청이 Cloudflare IP로 해석된 후 레이어 7 스택을 통과하는 대신, Cloudflare는 DNS 전용 로드 밸런서에 대한 DNS 요청을 받고 모든 적절한 로드 밸런싱 정책을 적용한 다음 요청 클라이언트에 IP 주소를 반환해 직접 연결하게 해요.

클라이언트와 엔드포인트 사이의 모든 트래픽은 둘 사이에서 직접 이동하고 Cloudflare 레이어 7 스택을 통과하지 않으므로 어떤 유형의 IP 트래픽이든 DNS 전용 로드 밸런서로 지원될 수 있어요.

그림 24: 프록시된 로드 밸런서 구성

그림 25: 비프록시(DNS 전용) 로드 밸런서 구성

Cloudflare가 이러한 유형의 로드 밸런서 연결을 프록시하지 않더라도 상태 모니터 서비스는 여전히 풀의 모든 엔드포인트 상태를 모니터링해요. 엔드포인트의 상태 또는 가용성에 따라 Cloudflare DNS 전용 로드 밸런서는 엔드포인트가 정상 엔드포인트로 트래픽이 스티어링되도록 DNS 응답에 적용 가능한 엔드포인트를 추가 또는 제거해요.

그림 26: Cloudflare DNS 전용 로드 밸런서의 작동 방식

DNS 전용 로드 밸런서가 트래픽 스티어링을 통해 엔드포인트 풀을 선택한 후 DNS 응답에서 하나 또는 여러 IP 주소가 반환될 수 있어요.

DNS 응답에서 하나 또는 여러 IP 주소를 보낼지 여부는 선택된 엔드포인트 풀 내 엔드포인트에 할당된 가중치에 기반해요:

• 모든 엔드포인트에 걸쳐 모든 가중치가 동일하면 모든 엔드포인트의 모든 IP 주소가 DNS 응답에서 반환돼요.
• 엔드포인트 풀 내 최소 하나의 엔드포인트가 고유 가중치로 지정되면 DNS 응답에서 단일 IP 주소만 반환돼요 — 엔드포인트 풀에서 선택된 엔드포인트 스티어링 방법과 무관해요.

이것은 조직에 애플리케이션이 모든 엔드포인트를 인지하고 로컬 장애 조치를 수행할 수 있게 하거나, Cloudflare가 애플리케이션이 활용할 단일 IP를 제공하게 하는 유연성을 제공해요.

그림 27은 엔드포인트 풀 내 정의된 가중치가 DNS 전용 로드 밸런서의 응답에 어떻게 영향을 줄 수 있는지 보여줘요.

그림 27: 가중치가 DNS 전용 로드 밸런서의 DNS 응답에 영향을 주는 방법

DNS 전용 로드 밸런서는 프록시 로드 밸런서에 비해 몇 가지 제한 사항이 있음을 유의해주세요:

• 로드 밸런서는 더 이상 엔드포인트의 IP 주소를 클라이언트에서 숨기지 않아요. 클라이언트에 직접 다시 전송되기 때문이에요.
• 이전 모델에서 언급한 내장 레이어 7 스택 서비스가 없어요. 즉 DNS 전용 로드 밸런서는 캐싱, WAF, DDoS 보호 또는 Zero Trust 지원을 포함하지 않아요.
• 세션 어피니티는 ip_cookie로 제한되며, 이는 엔드포인트를 결정적으로 선택한 다음 모든 후속 요청에 대해 그 엔드포인트를 클라이언트 IP 주소에 매핑해요.
• 마지막으로 DNS 전용은 연결이 로드 밸런서를 통해 프록시되지 않으므로 특정 스티어링 방법도 작동하지 않아요. 예를 들어 LORS는 Cloudflare가 엔드포인트에 대한 연결을 인지하지 못하므로 작동하지 않아요. 이러한 스티어링 방법은 random 가중치 스티어링으로 돌아가요.

추가 스티어링 방법에 대한 자세한 내용은 Steering 섹션을 참조해요.

DNS 전용 로드 밸런서를 사용할 때 클라이언트와 리졸버 DNS 캐시 고려 사항도 있어요. 캐시 수명은 요청에 응답하는 DNS 서버에 의해 결정돼요. Time-to-Live (TTL) ↗︎ 값은 DNS 요청자에게 목적지가 변경되었는지 확인하기 위해 클라이언트가 새 DNS 요청을 보내기 전에 응답이 유효한 기간을 알려줘요. TTL은 초 단위로 계산되므로, 예를 들어 TTL 값 3600은 1시간의 TTL에 해당해요. 그러나 표준 DNS TTL 값은 일반적으로 12시간 또는 24시간, 즉 각각 43200과 86400이에요.

DNS 전용 로드 밸런서의 TTL은 30(초)으로 설정돼요. 이는 엔드포인트 상태가 변경되거나 엔드포인트가 추가 또는 삭제될 때 DNS 전용 로드 밸런서가 더 자주 쿼리되어 가능한 가장 정확한 사용 가능한 엔드포인트 목록을 제공하도록 보장해요.

DNS 전용 로드 밸런서에 대한 중요 참고 사항:

• DNS 전용 로드 밸런서는 공용 엔드포인트만 지원
• DNS 전용 로드 밸런서는 트래픽을 프록시하지 않으며 — 따라서 — 엔드포인트에 대한 연결에 관여하지 않음
• DNS 전용 로드 밸런서는 IP 주소 또는 IP 주소 집합으로만 DNS 요청에 응답

Spectrum 로드 밸런싱

Cloudflare는 또한 Spectrum 제품을 통해 또 다른 인그레스 방법을 제공해요.

레이어 7 스택이 HTTP(S) 및 WebSockets만 지원한 반면, Spectrum은 TCP 또는 UDP 기반 프로토콜을 지원해요. 트래픽 인그레스로 Spectrum을 사용하는 Cloudflare Load Balancer는 TCP와 UDP 프로토콜이 모두 존재하는 레이어 4에서 작동해요. TCP 또는 UDP를 전송에 활용하는 모든 서비스는 SSH, FTP, NTP, SMTP 등을 포함해 Cloudflare Load Balancer와 함께 Spectrum을 활용할 수 있어요.

이것이 나타내는 서비스와 프로토콜의 범위를 고려할 때 제공되는 처리는 레이어 7 HTTP(S) 스택에서 제공되는 것보다 더 일반화돼요. 예를 들어 Cloudflare Spectrum은 TLS/SSL 오프로딩, DDoS 보호, IP 액세스 목록, Argo Smart Routing, 레이어 4 로드 밸런서와의 세션 지속성 같은 기능을 지원해요.

그림 28: Spectrum 레이어 4 로드 밸런서는 TCP와 UDP 프로토콜을 모두 지원

Cloudflare 레이어 4 Spectrum 로드 밸런서는 공용으로 접근 가능해요. 이러한 로드 밸런싱 리소스에 대한 접근은 IP Access Rules라는 Spectrum 구성을 사용해 관리할 수 있어요. 이는 WAF 구성의 일부로 정의될 수 있지만 특정 IP 주소, 서브넷, 국가 또는 Border Gateway Protocol (BGP) ↗︎ Autonomous System Numbers(ASN)에 대한 "allow" 또는 "block" 작업으로 생성된 규칙으로 제한돼요.

공용인 것 외에도 Spectrum 로드 밸런서는 항상 프록시돼요. Spectrum이 로드 밸런서의 인그레스 경로로 구성되면 앞서 보여준 proxy 설정(그림 24 및 25)은 무시돼요. Spectrum 기반 로드 밸런서를 위한 모든 트래픽은 항상 Cloudflare 에지를 통과해요.

Spectrum 로드 밸런서에 대한 중요 참고 사항:

• Spectrum 로드 밸런서는 공용 및 사설 엔드포인트를 모두 지원
• Spectrum 로드 밸런서는 초기에 Layer 7 HTTP(S) 로드 밸런서로 생성됨. 그런 다음 Load Balancer 엔드포인트 유형으로 Spectrum 애플리케이션을 만들고 이미 생성된 로드 밸런서를 선택
• Spectrum 로드 밸런서는 로드 밸런서 구성의 proxy 설정과 무관하게 항상 프록시됨
• 인터넷에서 Spectrum을 통해 엔드포인트로 인그레스 포트를 변경할 수 없음. 즉 트래픽이 포트 22로 Spectrum에 들어오면 엔드포인트의 포트 22로 스티어링됨
• Spectrum 로드 밸런서는 hash 엔드포인트 스티어링 방법을 사용해 세션 어피니티만 지원
• Spectrum 로드 밸런서는 Custom Rules를 지원하지 않음

배포 모델 한눈에 보기

Load Balancer Model	Public	Proxied	OSI Layer	Traffic Type
Layer 7 HTTP(S)	X	X	7	HTTP(S)
DNS-Only	X		7 (DNS)	IP-Based
Spectrum	X	X	4	TCP/UDP

로드 밸런서 세부 사항

호스트 이름(Hostname)

호스트 이름 설정은 로드 밸런서의 공용 도달 가능 호스트 이름이에요. 호스트 이름은 로드 밸런서가 생성되는 존 내에서 생성되어야 해요.

프록시 상태(Proxy status)

프록시 설정은 Cloudflare가 로드 밸런서에 대한 트래픽을 프록시할지, 아니면 클라이언트가 직접 연결할 엔드포인트와 함께 DNS 응답을 제공할지 결정해요. 이에 대한 자세한 내용은 Deployment models 섹션에서 다뤄요.

세션 어피니티(Session affinity)

세션 어피니티는 세션 지속성 또는 스티키 세션이라고도 하며, 첫 번째 요청 또는 연결 이후의 모든 후속 요청에 대해 클라이언트를 같은 엔드포인트에 연결시켜 유지해요. 이는 세션 데이터(사용자의 웹 애플리케이션 상호작용 컨텍스트)를 엔드포인트 간에 공유하지 않는 애플리케이션에 중요한 기능이 될 수 있어요. 예를 들어 클라이언트 세션 중간에 새 엔드포인트가 선택되고 세션에 대한 정보(예: 사용자의 쇼핑 카트 내용)가 손실되면 해당 애플리케이션의 사용자 경험이 좋지 않을 수 있어요.

Cloudflare는 세션 어피니티를 활성화하는 세 가지 방법을 제공해요:

1. Cloudflare 쿠키만 사용(cookie): 프록시된 로드 밸런서에 대한 첫 번째 요청에서 쿠키가 생성되어 요청이 전달될 엔드포인트의 정보를 인코딩해요. (같은 클라이언트의 같은 로드 밸런서에 대한) 후속 요청은 a) 쿠키 기간 동안 그리고 b) 엔드포인트가 정상인 한 쿠키가 인코딩한 엔드포인트로 전송돼요. 쿠키가 만료되었거나 엔드포인트가 비정상이면 새 엔드포인트가 계산되어 사용돼요.
2. Cloudflare 쿠키 및 클라이언트 IP 폴백(ip_cookie): 이는 위의 쿠키 방법과 유사하게 동작하지만 쿠키가 클라이언트 IP 주소를 기반으로 생성돼요. 이 경우 같은 IP 주소의 요청은 a) 쿠키 기간 동안 그리고 b) 엔드포인트가 정상인 한 항상 같은 엔드포인트로 스티어링돼요. 쿠키가 만료되었거나 엔드포인트가 비정상이면 새 엔드포인트가 계산되어 사용돼요.
3. HTTP 헤더 사용(header): 프록시된 로드 밸런서에 대한 첫 번째 요청에서 구성된 HTTP 헤더를 기반으로 세션 키가 생성돼요. 같은 헤더를 가진 로드 밸런서에 대한 후속 요청은 a) 세션 기간 동안 또는 b) 엔드포인트가 정상인 한 같은 엔드포인트로 전송돼요. 세션이 세션 어피니티 TTL(time-to-live) 초 동안 유휴 상태였거나 엔드포인트가 비정상이면 새 엔드포인트가 계산되어 사용돼요.

이 세 가지 세션 어피니티 옵션은 레이어 7 HTTP(S) 로드 밸런서에만 적용돼요. 세션 어피니티에는 로드 밸런서가 특정 엔드포인트로 후속 요청을 라우팅할 기간을 결정하는 TTL이 필요해요. 기본 TTL은 82,800초(23시간)이지만 1,800초(30분)부터 604,800초(7일)까지 설정할 수 있어요.

쿠키 기반 세션 어피니티의 경우 만료 타이머는 재설정되지 않아요. 즉 세션이 유휴이든 활성이든 타이머는 세션 시작부터 카운트다운돼요. HTTP 헤더 기반 세션 어피니티는 세션에 활동이 있을 때마다 만료 타이머를 재설정해요.

엔드포인트 드레이닝(Endpoint draining)

엔드포인트 드레이닝은 세션 어피니티의 하위 기능이에요. 세션이 엔드포인트에서 우아하게 만료되도록 하면서 같은 엔드포인트에 새 세션이 생성되는 것을 허용하지 않아요. 엔드포인트 드레이닝은 유지 관리에 유용해요. 관리자가 엔드포인트에서 모든 활성 세션을 제거하기 위해 사용자 세션을 임의로 또는 갑자기 끊을 필요가 없기 때문이에요.

엔드포인트 드레인 TTL은 강제로 종료되기 전에 엔드포인트가 활성 세션을 유지할 수 있는 시간이에요. 엔드포인트 드레인 TTL이 설정되면 엔드포인트 풀 내에서 엔드포인트(하나 이상)를 비활성화하여 엔드포인트 드레이닝이 시작돼요. 아래 이미지에서 볼 수 있듯이 관리자는 로드 밸런서 UI에서 엔드포인트 드레이닝 작업에 남은 시간을 모니터링할 수 있어요.

그림 30: Cloudflare Load Balancer 내에서 발생하는 엔드포인트 드레이닝

엔드포인트 드레이닝은 세션 어피니티에만 적용 가능해요. 세션 어피니티가 없으면 후속 요청 또는 연결이 같은 엔드포인트로 스티어링된다는 보장이 없기 때문이에요. 따라서 엔드포인트 비활성화는 사용자 경험에 영향을 주지 않아요.

무중단 장애 조치(Zero-downtime failover)

무중단 장애 조치는 일시적인 네트워크 문제 동안 엔드포인트 풀 내 엔드포인트로 자동으로 트래픽을 보내요.

풀에 다른 정상 엔드포인트가 있고 521, 522, 523, 525 또는 526 오류 코드가 발생하는 경우에만 무중단 장애 조치가 단일 재시도를 트리거해요. 다른 오류 코드는 무중단 장애 조치 작업을 트리거하지 않아요.

이러한 응답 코드는 엔드포인트에서 반환되는 것이 아니라 상류 Cloudflare 서비스가 조직의 엔드포인트에 요청하여 반환돼요.

무중단 장애 조치에는 세 가지 작동 모드가 있어요:

1. None (Off): 장애 조치가 발생하지 않으며 사용자가 오류 메시지 또는 좋지 않은 사용자 경험을 받을 수 있음
2. Temporary: 엔드포인트가 다시 사용 가능해질 때까지 트래픽이 다른 엔드포인트(들)로 전송됨
3. Sticky: 세션 어피니티 쿠키가 업데이트되고 필요에 따라 후속 요청이 앞으로 새 엔드포인트로 전송됨. 세션 어피니티가 HTTP 헤더 모드를 사용할 때는 지원되지 않음

적응형 라우팅 - 풀 간 장애 조치

Adaptive routing - failover across pools는 장애 조치가 같은 풀의 엔드포인트로만 실패하는 대신 다른 엔드포인트 풀의 엔드포인트로 확장될 수 있게 하여 무중단 장애 조치의 기능을 확장해요.

엔드포인트 풀

엔드포인트 풀은 우선순위 순서로 구성되며 필요에 따라 재정렬할 수 있어요. 이 우선순위 순서는 Off - Failover 트래픽 스티어링을 사용할 때만 고려돼요. 그 외에는 Steering methods 섹션에 설명된 기준에 따라 엔드포인트 풀이 선택돼요.

로드 밸런서에 할당된 엔드포인트 풀은 로드 밸런서를 통해 요청 또는 연결을 처리할 수 있는 모든 엔드포인트의 전체 컬렉션을 나타내요. 엔드포인트 풀은 일반적으로 모두 같은 기능을 가지고 데이터 센터 또는 지리적 지역에 있는 엔드포인트를 포함해요. 풀의 모든 엔드포인트는 엔드포인트 풀로 향하는 모든 요청을 처리할 수 있어야 해요. 엔드포인트 풀에 대한 자세한 내용은 Endpoint pools 섹션을 참조해요.

폴백 풀(Fallback pools)

폴백 풀은 마지막 수단의 풀이에요. 모든 엔드포인트 풀을 사용할 수 없거나 비정상일 때, 폴백 풀이 모든 요청과 연결에 사용돼요. 상태 모니터 데이터는 로드 밸런서 내에서 트래픽을 스티어링할 때 항상 고려되지만, 폴백 풀은 이 데이터에 의존하지 않으며 그 적용을 받지 않아요.

상태 모니터

상태 모니터는 일반적으로 엔드포인트 풀의 일부로 구성돼요. 상태 모니터는 로드 밸런서 구성의 일부로 추가, 변경 또는 삭제될 수 있어요. 자세한 내용은 Health monitors 섹션을 참조해요.

트래픽 스티어링

트래픽 스티어링은 엔드포인트 풀 사이를 스티어링하는 방법이에요. 어떤 트래픽 스티어링 방법을 선택할지 이해하려면 Steering types and methods 섹션을 참조해요.

사용자 지정 규칙(Custom rules)

Custom rules를 사용하면 로드 밸런서가 결정 프로세스를 마치기 전에 요청 또는 연결에 대한 작업을 수행할 수 있어요. Custom rules는 요청 또는 연결의 특정 필드와 일치하는 표현식으로 구성돼요. 트래픽과 일치하도록 표현식이 생성되면 요청 또는 연결이 표현식과 일치할 때 수행할 작업이 할당돼요.

Custom rules는 요청 또는 연결이 엔드포인트로 전송되기 전에 로드 밸런서의 스티어링과 출력을 사용자 지정하기 위한 강력한 도구예요. 예를 들어 HTTP 메서드(예: GET, PUT, POST)를 일치시켜 POST 메시지가 클라이언트로부터 정보 수신을 전담하는 특정 엔드포인트 풀로 전송되도록 할 수 있어요.

또는 클라이언트가 트랜잭션을 완료할 충분한 시간을 가지도록 특정 URL 경로로 가는 요청에 기반해 세션 어피니티 TTL을 재설정할 수 있어요.

일치할 수 있는 필드와 취할 수 있는 작업의 모든 잠재적 조합을 문서화하는 것은 불가능해요. 그러나 다음 리소스는 현재 사용 가능한 모든 필드와 작업을 설명해요:

• 지원 필드 및 연산자
• Load Balancing 작업

로드 밸런서의 기본 동작이 위에 나열된 문서에서 다루지 않는다면 custom rule이 고유한 사용 사례 요구 사항을 충족하는 데 도움이 될 가능성이 높아요.

로드 밸런서 보호 및 보안

내재적 보안

모든 Cloudflare Load Balancer 배포 모델에는 내재적 보호가 함께 제공돼요. 다음 섹션은 Cloudflare가 제공하는 기본 보안과 Cloudflare Load Balancer 앞에 추가할 수 있는 선택적 보호를 간략히 강조해요:

• 프록시 HTTP 레이어 7 로드 밸런서(공용)
  • 공격에 대비한 DDoS 보호
  • 알려진 취약점과 익스플로잇을 차단하는 Cloudflare 관리 규칙셋 및 OWASP 규칙셋을 갖춘 WAF
• DNS 전용 로드 밸런서(공용)
  • DNS 전용 로드 밸런서가 항상 사용 가능하도록 하는 DNS DDoS 보호 ↗︎
• Spectrum 레이어 4 로드 밸런서(공용)
  • 레이어 4 공격에 대비한 DDoS 보호

추가 옵션

Cloudflare는 웹사이트, API, HTTP(S) 기반 서비스 등을 포함한 모든 서비스를 보호하기 위해 로드 밸런싱과 함께 사용할 수 있는 추가 보안 레이어를 제공해요:

• 프록시 HTTP 레이어 7 로드 밸런서(공용)
  • 어떤 봇이 리소스에 접근할 수 있는지 제어하는 Bot management
  • 웹 애플리케이션용 사용자 지정 규칙을 만드는 WAF
  • 웹 애플리케이션에서 스크립트 사용을 모니터링하는 Client-side security
  • API를 보호하는 API Shield
• DNS 전용 로드 밸런서(공용)
  • DNS 레코드의 진위를 보장하는 DNSSEC
• Spectrum 레이어 4 로드 밸런서(공용)
  • 공용 레이어 4 로드 밸런서에 대한 접근을 제어하는 IP Access Rules

요약(Summary)

Cloudflare 글로벌 anycast 네트워크는 로드 밸런싱을 위한 강력한 플랫폼이에요. Cloudflare의 로드 밸런싱 구성은 전 세계 330개 이상의 도시에서 접근 가능하며 사실상 무제한의 용량과 대역폭을 가져요.

이러한 로드 밸런서는 Cloudflare Load Balancer가 GTM과 Private Network Load Balancing을 모두 수행할 수 있게 하는 엔드포인트를 포함해 인터넷 연결 인구의 약 95%로부터 약 50ms 이내에서 작동해요. Cloudflare는 이제 이 두 가지 구별되는 로드 밸런싱 개념을 단일 로드 밸런서로 결합해요. 이는 조직이 지리적으로 관련된 데이터 센터로 트래픽을 스티어링한 다음 요청을 처리할 적절한 엔드포인트를 선택할 수 있게 해줘요.

Cloudflare Tunnel을 사용하면 엔드포인트가 사설 네트워크에 위치해도 Cloudflare Load Balancer로 계속 활용될 수 있어요. Cloudflare는 HTTP(S) 및 WebSockets를 모두 지원하는 공용 레이어 7 로드 밸런서와 모든 TCP 또는 UDP 트래픽을 스티어링할 수 있는 공용 레이어 4 로드 밸런서를 제공해요. 즉 Cloudflare는 위치, 사용 사례 또는 기존 구성과 관계없이 모든 조직과 사용자에게 로드 밸런싱 서비스를 제공할 수 있어요.

더 알아보기 (Learn more)

이 참조 아키텍처는 GTM과 Private Network Load Balancing을 단일 SaaS 로드 밸런서로 결합하는 Cloudflare Load Balancing의 구조, 스티어링 방법, 배포 모델, 보안 옵션을 폭넓게 다뤄요. 그림과 표의 상세한 구체 수치는 원문을 참고해요.