HAProxy Introduction

HAProxy Introduction(Starter Guide)


This document is an introduction to HAProxy for all those who don't know it, as well as for those who want to re-discover it when they know older versions. Its primary focus is to provide users with all the elements to decide if HAProxy is the product they're looking for or not. Advanced users may find here some parts of solutions to some ideas they had just because they were not aware of a given new feature. Some sizing information is also provided, the product's lifecycle is explained, and comparisons with partially overlapping products are provided.

이 문서는 HAProxy를 모르는 모든 사람들과 이전 버전을 알고 있지만 다시 찾고 싶은 사람들을 위해 HAProxy에 대한 소개입니다. 이 문서의 주요 초점은 HAProxy가 그들이 찾고 있는 제품인지 아닌지를 결정하기 위한 모든 요소를 사용자에게 제공하는 것입니다. 고급 사용자는 주어진 새로운 기능을 인식하지 못했기 때문에 생각했던 일부 아이디어에 대한 솔루션의 일부를 여기에서 찾을 수 있습니다. 일부 사이징 정보도 제공되며, 제품의 수명 주기를 설명하고, 부분적으로 겹치는 다른 제품과의 비교도 제공됩니다.

This document doesn't provide any configuration help or hints, but it explains where to find the relevant documents. The summary below is meant to help you search sections by name and navigate through the document.

이 문서는 구성 도움말이나 힌트를 제공하지 않지만 관련 문서를 찾을 수 있는 위치를 설명합니다. 아래 요약은 이름으로 섹션을 검색하고 문서를 탐색하는 데 도움이 됩니다.

HAProxy Starter Guide version 2.6 - 원문(original doc)

Summary 목차


1. Available documentation

The complete HAProxy documentation is contained in the following documents. Please ensure to consult the relevant documentation to save time and to get the most accurate response to your needs. Also please refrain from sending questions to the mailing list whose responses are present in these documents.

전체 HAProxy 설명서는 다음 문서에 포함되어 있습니다. 시간을 절약하고 요구 사항에 가장 정확한 응답을 얻으려면 관련 문서를 참조하십시오.

  • intro.txt (this document) : it presents the basics of load balancing, HAProxy as a product, what it does, what it doesn't do, some known traps to avoid, some OS-specific limitations, how to get it, how it evolves, how to ensure you're running with all known fixes, how to update it, complements and alternatives.
    intro.txt(이 문서) : 로드 밸런싱의 기본, 제품으로서의 HAProxy, 하는 일, 하지 않는 일, 피해야 할 알려진 트랩, 일부 OS별 제한 사항, 얻는 방법, 어떻게 발전하는지, 알려진 모든 수정 사항으로 실행되고 있는지 확인하는 방법, 업데이트하는 방법, 보완과 대안에 대해 설명합니다.
  • architecture.txt : HAProxy 아키텍처에 대해 설명합니다.
  • management.txt : it explains how to start haproxy, how to manage it at runtime, how to manage it on multiple nodes, and how to proceed with seamless upgrades.
    management.txt : haproxy를 시작하는 방법, 운영중(runtime)에 관리하는 방법, 여러 노드를 관리하는 방법, 원활한 업그레이드를 진행하는 방법에 대해 설명합니다.
  • configuration.txt : the reference manual details all configuration keywords and their options. It is used when a configuration change is needed.
    configuration.txt : 모든 구성 키워드와 해당 옵션이 자세히 설명되어 있습니다. 구성 변경이 필요할 때 사용합니다.
  • coding-style.txt : this is for developers who want to propose some code to the project. It explains the style to adopt for the code. It is not very strict and not all the code base completely respects it, but contributions which diverge too much from it will be rejected.
    coding-style.txt : 프로젝트에 어떤 코드를 제안하고자 하는 개발자를 위한 것입니다. 코드에 적용할 스타일을 설명합니다. 매우 엄격하지 않고 모든 코드 기반이 이를 완전히 존중하는 것은 아니지만 너무 많이 벗어나는 것은 거부됩니다.
  • proxy-protocol.txt : this is the de-facto specification of the PROXY protocol which is implemented by HAProxy and a number of third party products.
    proxy-protocol.txt : 이것은 HAProxy와 다수의 타사 제품에 의해 구현되는 PROXY 프로토콜의 사실상 사양입니다.
  • README : doc 간략 설명
  • INSTALL : how to build HAProxy from sources
    소스에서 HAProxy를 빌드하는 방법

2. Quick introduction to load balancing and load balancers

로드 밸런싱(부하 분산)과 로드 밸런서에 대한 소개

Load balancing consists in aggregating multiple components in order to achieve a total processing capacity above each component's individual capacity, without any intervention from the end user and in a scalable way. This results in more operations being performed simultaneously by the time it takes a component to perform only one. A single operation however will still be performed on a single component at a time and will not get faster than without load balancing. It always requires at least as many operations as available components and an efficient load balancing mechanism to make use of all components and to fully benefit from the load balancing. A good example of this is the number of lanes on a highway which allows as many cars to pass during the same time frame without increasing their individual speed.

로드 밸런싱은 최종 사용자의 개입 없이 확장 가능한 방식으로 각 구성 요소의 개별 용량을 초과하는 총 처리 용량을 달성하기 위해 여러 구성 요소를 집계하는 것으로 구성됩니다. 그 결과 구성 요소가 하나만 수행하는 데 걸리는 시간만큼 더 많은 작업이 동시에 수행됩니다. 그러나 단일 작업은 여전히 한 번에 단일 구성 요소에서 수행되며 로드 밸런싱이 없는 경우보다 빨라지지 않습니다.
모든 구성 요소를 사용하고 로드 밸런싱의 이점을 최대한 활용하려면 항상 사용 가능한 구성 요소 수만큼의 작업과 효율적인 로드 밸런싱 메커니즘이 필요합니다. 이에 대한 좋은 예는 개별 속도를 높이지 않고 동일한 시간 프레임에 많은 자동차가 통과할 수 있도록 하는 고속도로의 차선 수입니다.

Examples of load balancing 부하 분산의 예:

  • Process scheduling in multi-processor systems
    다중 프로세서 시스템의 프로세스 스케줄링
  • Link load balancing (e.g. EtherChannel, Bonding)   링크 로드 밸런싱
    EtherChannel : 다수의 포트를 하나의 논리적 포트로 묶어서 사용하는 기술
        100Mbps 포트 2개를 묶어서 사용하면 200Mbps의 논리적 포트 하나로 사용 가능
    Bonding : 여러 개의 NIC를 논리적으로 묶어서 한 개의 NIC의 개수만큼 대역폭을 확장하는 기술
  • IP address load balancing (e.g. ECMP, DNS round-robin)   IP 주소 로드 밸런싱
    ECMP : Equal-cost multi-path routing의 약자로 하나의 목적지로 패킷 라우팅을 수행하면서
        여러 개의 경로를 선택하는 라우팅 기법
    DNS round-robin : 별도의 소프트웨어 혹은 하드웨어 로드밸런싱 장비를 사용하지 않고,
        DNS만을 이용하여 도메인 레코드 정보를 조회하는 시점에서 트래픽을 분산하는 기법
  • Server load balancing (via load balancers)   서버 로드 밸런싱(로드 밸런서를 통해)
    SLB (Server Load Balancing) : Server의 부하를 조절하는 기법.
        SLB는 LB(Load Balancer)와 VIP(Virtual IP)로 구성

The mechanism or component which performs the load balancing operation is called a load balancer. In web environments these components are called a "network load balancer", and more commonly a "load balancer" given that this activity is by far the best known case of load balancing.

로드 밸런싱 작업을 수행하는 메커니즘 또는 구성 요소를 로드 밸런서라고 합니다. 웹 환경에서 이러한 구성 요소를 "네트워크 로드 밸런서"라고 하며 이 활동이 가장 잘 알려진 로드 밸런싱 사례라는 점을 감안할 때 일반적으로 "로드 밸런서"라고 합니다.

A load balancer may act : 로드 밸런서는 다음과 같이 작동할 수 있습니다.

  • at the link level : this is called link load balancing, and it consists in choosing what network link to send a packet to;
    링크 수준에서: 이것을 링크 로드 밸런싱이라고 하며 패킷을 보낼 네트워크 링크를 선택하는 것으로 구성됩니다.
  • at the network level : this is called network load balancing, and it consists in choosing what route a series of packets will follow;
    네트워크 수준에서: 이것을 네트워크 로드 밸런싱이라고 하며 일련의 패킷이 따라갈 경로를 선택하는 것으로 구성됩니다.
  • at the server level : this is called server load balancing and it consists in deciding what server will process a connection or request.
    서버 수준에서 : 이를 서버 로드 밸런싱이라고 하며 연결 또는 요청을 처리할 서버를 결정하는 것으로 구성됩니다.

Two distinct technologies exist and address different needs, though with some overlapping. In each case it is important to keep in mind that load balancing consists in diverting the traffic from its natural flow and that doing so always requires a minimum of care to maintain the required level of consistency between all routing decisions.

두 가지 별개의 기술이 존재하며 일부 중복되는 부분이 있지만 서로 다른 요구 사항을 해결합니다. 각각의 경우에 로드 밸런싱은 트래픽을 자연스러운 흐름에서 전환하는 것으로 구성되며 그렇게 하려면 모든 라우팅 결정 간에 필요한 수준의 일관성을 유지하기 위해 항상 최소한의 주의가 필요합니다.

The first one acts at the packet level and processes packets more or less individually. There is a 1-to-1 relation between input and output packets, so it is possible to follow the traffic on both sides of the load balancer using a regular network sniffer. This technology can be very cheap and extremely fast. It is usually implemented in hardware (ASICs) allowing to reach line rate, such as switches doing ECMP. Usually stateless, it can also be stateful (consider the session a packet belongs to and called layer4-LB or L4), may support DSR (direct server return, without passing through the LB again) if the packets were not modified, but provides almost no content awareness. This technology is very well suited to network-level load balancing, though it is sometimes used for very basic server load balancing at high speed.

첫 번째 것은 패킷 수준에서 작동하고 패킷을 다소 개별적으로 처리합니다. 입출력 패킷은 1:1 관계이므로 일반 네트워크 스니퍼를 사용하여 로드 밸런서 양쪽의 트래픽을 추적할 수 있습니다. 이 기술은 매우 저렴하고 매우 빠를 수 있습니다. 일반적으로 ECMP를 수행하는 스위치와 같이 회선 속도에 도달할 수 있도록 하는 하드웨어(ASIC)로 구현됩니다. 일반적으로 상태 비저장, 상태 저장(패킷이 속하고 layer4-LB 또는 L4라고 하는 세션 고려)일 수 있으며 패킷이 수정되지 않은 경우 DSR(LB를 다시 통과하지 않고 직접 서버 반환)을 지원할 수 있지만 거의 콘텐츠 인식이 없습니다. 이 기술은 네트워크 수준의 부하 분산에 매우 적합하지만 매우 기본적인 서버 부하 분산에 고속으로 사용되기도 합니다.
DSR(Direct Server Return) : 로드밸런서를 거치지 않고 서버에서 클라이언트로 직접 패킷을 전달하는 것.

The second one acts on session contents. It requires that the input streams is reassembled and processed as a whole. The contents may be modified, and the output stream is segmented into new packets. For this reason it is generally performed by proxies and they're often called layer 7 load balancers or L7. This implies that there are two distinct connections on each side, and that there is no relation between input and output packets sizes nor counts. Clients and servers are not required to use the same protocol (for example IPv4 vs IPv6, clear vs SSL). The operations are always stateful, and the return traffic must pass through the load balancer. The extra processing comes with a cost so it's not always possible to achieve line rate, especially with small packets. On the other hand, it offers wide possibilities and is generally achieved by pure software, even if embedded into hardware appliances. This technology is very well suited for server load balancing.

두 번째는 세션 내용에 대해 작동합니다. 입력 스트림이 전체적으로 재조립되고 처리되어야 합니다. 내용은 수정될 수 있으며 출력 스트림은 새로운 패킷으로 분할됩니다. 이러한 이유로 일반적으로 프록시에서 수행되며 종종 레이어 7 로드 밸런서 또는 L7이라고 합니다. 이것은 양쪽에 두 개의 별개의 연결이 있으며 입력 및 출력 패킷 크기나 개수 간에 관계가 없음을 의미합니다. 클라이언트와 서버는 동일한 프로토콜을 사용할 필요가 없습니다(예: IPv4 vs IPv6, clear vs SSL). 작업은 항상 상태를 저장하며 반환 트래픽은 로드 밸런서를 통과해야 합니다. 추가 처리에는 비용이 수반되므로 특히 작은 패킷의 경우 항상 회선 속도를 달성할 수 있는 것은 아닙니다. 반면에 하드웨어 어플라이언스에 내장된 경우에도 광범위한 가능성을 제공하며 일반적으로 순수 소프트웨어에 의해 달성됩니다. 이 기술은 서버 로드 밸런싱에 매우 적합합니다.

Packet-based load balancers are generally deployed in cut-through mode, so they are installed on the normal path of the traffic and divert it according to the configuration. The return traffic doesn't necessarily pass through the load balancer. Some modifications may be applied to the network destination address in order to direct the traffic to the proper destination. In this case, it is mandatory that the return traffic passes through the load balancer. If the routes doesn't make this possible, the load balancer may also replace the packets' source address with its own in order to force the return traffic to pass through it.

패킷 기반 로드 밸런서는 일반적으로 컷스루(cut-through) 모드로 배포되므로 트래픽의 일반 경로에 설치되고 구성에 따라 우회합니다. 반환 트래픽이 반드시 로드 밸런서를 통과하는 것은 아닙니다. 트래픽을 적절한 대상으로 보내기 위해 일부 수정이 네트워크 대상 주소에 적용될 수 있습니다. 이 경우 반환 트래픽이 로드 밸런서를 통과해야 합니다. 경로가 이를 가능하게 하지 않는 경우 로드 밸런서는 반환 트래픽이 통과하도록 하기 위해 패킷의 소스 주소를 자체 주소로 바꿀 수도 있습니다.
컷스루(Cut-through) Switching, wiki 설명 : 스위칭 시스템에서, 수신된 패킷의 헤더 부분 만 검사하여, 이를 곧바로 스위칭하는 방식      

Proxy-based load balancers are deployed as a server with their own IP addresses and ports, without architecture changes. Sometimes this requires to perform some adaptations to the applications so that clients are properly directed to the load balancer's IP address and not directly to the server's. Some load balancers may have to adjust some servers' responses to make this possible (e.g. the HTTP Location header field used in HTTP redirects). Some proxy-based load balancers may intercept traffic for an address they don't own, and spoof the client's address when connecting to the server. This allows them to be deployed as if they were a regular router or firewall, in a cut-through mode very similar to the packet based load balancers. This is particularly appreciated for products which combine both packet mode and proxy mode. In this case DSR is obviously still not possible and the return traffic still has to be routed back to the load balancer.

프록시 기반 로드 밸런서는 아키텍처 변경 없이 고유한 IP 주소와 포트가 있는 서버로 배포됩니다. 때로는 클라이언트가 서버의 IP 주소가 아닌 로드 밸런서의 IP 주소로 적절하게 전달되도록 애플리케이션에 대한 일부 조정을 수행해야 합니다. 일부 로드 밸런서는 이를 가능하게 하기 위해 일부 서버의 응답을 조정해야 할 수 있습니다 (예: HTTP 리디렉션에 사용되는 HTTP 위치 헤더 필드). 일부 프록시 기반 로드 밸런서는 자신이 소유하지 않은 주소에 대한 트래픽을 가로채고 서버에 연결할 때 클라이언트 주소를 변조(spoof)할 수 있습니다. 이를 통해 패킷 기반 로드 밸런서와 매우 유사한 컷스루 모드에서 일반 라우터 또는 방화벽인 것처럼 배포할 수 있습니다. 이는 패킷 모드와 프록시 모드를 결합한 제품에 특히 유용합니다. 이 경우 DSR(Direct Server Return)은 분명히 여전히 불가능하며 반환 트래픽은 여전히 로드 밸런서로 다시 라우팅되어야 합니다.
변조(spoofing) , IP 스니핑 및 스푸핑 : 다른 사람의 컴퓨터 시스템에 접근할 목적으로 IP주소를 변조한 후 합법적인 사용자인 것처럼 위장하여 시스템에 접근함으로써 나중에 IP주소에 대한 추적을 피하는 해킹 기법의 일종이다.

A very scalable layered approach would consist in having a front router which receives traffic from multiple load balanced links, and uses ECMP to distribute this traffic to a first layer of multiple stateful packet-based load balancers (L4). These L4 load balancers in turn pass the traffic to an even larger number of proxy-based load balancers (L7), which have to parse the contents to decide what server will ultimately receive the traffic.

확장성이 뛰어난 계층화된 접근 방식은 여러 로드 밸런싱된 링크에서 트래픽을 수신하고 ECMP를 사용하여 이 트래픽을 여러 상태 저장 패킷 기반 로드 밸런서(L4)의 첫 번째 레이어에 배포하는 전면 라우터를 갖는 것으로 구성됩니다. 이러한 L4 로드 밸런서는 결국 더 많은 수의 프록시 기반 로드 밸런서(L7)로 트래픽을 전달합니다. 이 로드 밸런서는 궁극적으로 트래픽을 수신할 서버를 결정하기 위해 콘텐츠를 구문 분석해야 합니다.

The number of components and possible paths for the traffic increases the risk of failure; in very large environments, it is even normal to permanently have a few faulty components being fixed or replaced. Load balancing done without awareness of the whole stack's health significantly degrades availability. For this reason, any sane load balancer will verify that the components it intends to deliver the traffic to are still alive and reachable, and it will stop delivering traffic to faulty ones. This can be achieved using various methods.

트래픽에 대한 구성 요소의 수와 가능한 경로는 장애 위험을 높입니다. 매우 큰 환경에서는 몇 가지 결함이 있는 구성 요소를 영구적으로 수정하거나 교체하는 것이 정상입니다. 전체 스택의 상태를 인식하지 않고 로드 밸런싱을 수행하면 가용성이 크게 저하됩니다. 이러한 이유로 정상적인 로드 밸런서는 트래픽을 전달하려는 구성 요소가 아직 살아 있고 연결할 수 있는지 확인하고 결함이 있는 구성 요소에 대한 트래픽 전달을 중지합니다. 이것은 다양한 방법을 사용하여 달성할 수 있습니다.

The most common one consists in periodically sending probes to ensure the component is still operational. These probes are called "health checks". They must be representative of the type of failure to address. For example a ping- based check will not detect that a web server has crashed and doesn't listen to a port anymore, while a connection to the port will verify this, and a more advanced request may even validate that the server still works and that the database it relies on is still accessible. Health checks often involve a few retries to cover for occasional measuring errors. The period between checks must be small enough to ensure the faulty component is not used for too long after an error occurs.

가장 일반적인 방법은 구성 요소가 계속 작동하는지 확인하기 위해 주기적으로 확인(probe)을 보내는 것입니다. 이러한 확인을 "상태 확인(health checks)"이라고 합니다. 해결하지 못한 유형을 대표해야 합니다. 예를 들어 ping 기반 검사는 웹 서버가 충돌했음(crashed)을 감지하지 못하고 더 이상 포트를 수신하지 않는 반면, 포트에 대한 연결은 이를 확인하고 더 고급 요청은 서버가 여전히 작동하고 있는지 확인할 수도 있습니다. 의존하는 데이터베이스는 여전히 액세스할 수 있습니다. 상태 확인에는 가끔 발생하는 측정 오류를 처리하기 위해 몇 번의 재시도가 포함되는 경우가 많습니다. 검사 사이의 기간은 오류가 발생한 후 결함이 있는 구성 요소가 너무 오랫동안 사용되지 않도록 충분히 작아야 합니다.

Other methods consist in sampling the production traffic sent to a destination to observe if it is processed correctly or not, and to evict the components which return inappropriate responses. However this requires to sacrifice a part of the production traffic and this is not always acceptable. A combination of these two mechanisms provides the best of both worlds, with both of them being used to detect a fault, and only health checks to detect the end of the fault. A last method involves centralized reporting : a central monitoring agent periodically updates all load balancers about all components' state. This gives a global view of the infrastructure to all components, though sometimes with less accuracy or responsiveness. It's best suited for environments with many load balancers and many servers.

다른 방법은 대상으로 전송된 프로덕션 트래픽을 샘플링하여 올바르게 처리되었는지 여부를 관찰하고 부적절한 응답을 반환하는 구성 요소를 제거하는 것입니다. 그러나 이것은 프로덕션 트래픽의 일부를 희생해야 하며 이것이 항상 허용되는 것은 아닙니다. 이 두 메커니즘의 조합은 두 가지 장점을 모두 제공하며, 둘 다 결함을 감지하는 데 사용되며 상태 검사만 결함의 끝을 감지하는 데 사용됩니다.
마지막 방법은 중앙 집중식 보고를 포함합니다. 중앙 모니터링 에이전트는 모든 구성 요소의 상태에 대한 모든 로드 밸런서를 주기적으로 업데이트합니다. 이렇게 하면 정확도나 응답성이 떨어지는 경우도 있지만 모든 구성 요소에 대한 인프라에 대한 글로벌 보기가 제공됩니다. 로드 밸런서와 서버가 많은 환경에 가장 적합합니다.

Layer 7 load balancers also face another challenge known as stickiness or persistence. The principle is that they generally have to direct multiple subsequent requests or connections from a same origin (such as an end user) to the same target. The best known example is the shopping cart on an online store. If each click leads to a new connection, the user must always be sent to the server which holds his shopping cart. Content-awareness makes it easier to spot some elements in the request to identify the server to deliver it to, but that's not always enough. For example if the source address is used as a key to pick a server, it can be decided that a hash-based algorithm will be used and that a given IP address will always be sent to the same server based on a divide of the address by the number of available servers.
But if one server fails, the result changes and all users are suddenly sent to a different server and lose their shopping cart. The solution against this issue consists in memorizing the chosen target so that each time the same visitor is seen, he's directed to the same server regardless of the number of available servers. The information may be stored in the load balancer's memory, in which case it may have to be replicated to other load balancers if it's not alone, or it may be stored in the client's memory using various methods provided that the client is able to present this information back with every request (cookie insertion, redirection to a sub-domain, etc). This mechanism provides the extra benefit of not having to rely on unstable or unevenly distributed information (such as the source IP address). This is in fact the strongest reason to adopt a layer 7 load balancer instead of a layer 4 one.

레이어 7 로드 밸런서는 또한 고정성(stickiness) 또는 지속성(persistence)으로 알려진 또 다른 문제에 직면해 있습니다. 원칙은 일반적으로 동일한 출처(최종 사용자와 같은)의 여러 후속 요청 또는 연결을 동일한 대상으로 보내야 한다는 것입니다. 가장 잘 알려진 예는 온라인 상점의 장바구니입니다. 클릭할 때마다 새로운 연결이 발생하면 사용자는 항상 장바구니가 있는 서버로 보내져야 합니다. 콘텐츠 인식을 사용하면 전달할 서버를 식별하기 위해 요청에서 일부 요소를 더 쉽게 찾을 수 있지만 항상 충분하지는 않습니다. 예를 들어 소스 주소가 서버를 선택하는 키로 사용되는 경우 해시 기반 알고리즘을 사용하고 주어진 IP 주소는 사용 가능한 서버 수에 따라 주소 분할을 기반으로 항상 동일한 서버로 전송되도록 결정할 수 있습니다.
그러나 한 서버에 장애가 발생하면 결과가 변경되고 모든 사용자는 갑자기 다른 서버로 이동되어 장바구니를 잃게 됩니다. 이 문제에 대한 해결책은 동일한 방문자가 볼 때마다 사용 가능한 서버 수에 관계없이 동일한 서버로 안내되도록 선택한 대상을 기억하는 것으로 구성됩니다. 정보는 로드 밸런서의 메모리에 저장될 수 있으며, 이 경우 혼자가 아닌 경우 다른 로드 밸런서에 복제해야 할 수 있으며, 클라이언트가 이를 제시할 수 있는 경우 다양한 방법을 사용하여 클라이언트의 메모리에 저장할 수 있습니다. 모든 요청(쿠키 삽입, 하위 도메인으로 리디렉션 등)과 함께 정보를 반환합니다. 이 메커니즘은 불안정하거나 고르지 않게 분포된 정보(예: 소스 IP 주소)에 의존하지 않아도 되는 추가 이점을 제공합니다. 이것이 실제로 레이어 4 로드 밸런서 대신 레이어 7 로드 밸런서를 채택해야 하는 가장 강력한 이유입니다.

In order to extract information such as a cookie, a host header field, a URL or whatever, a load balancer may need to decrypt SSL/TLS traffic and even possibly to re-encrypt it when passing it to the server. This expensive task explains why in some high-traffic infrastructures, sometimes there may be a lot of load balancers.

쿠키, 호스트 헤더 필드, URL 등과 같은 정보를 추출하기 위해 로드 밸런서는 SSL/TLS 트래픽을 해독해야 하며 서버에 전달할 때 다시 암호화해야 할 수도 있습니다. 이 값비싼 작업은 트래픽이 많은 인프라에 때때로 많은 로드 밸런서가 있을 수 있는 이유를 설명합니다.

Since a layer 7 load balancer may perform a number of complex operations on the traffic (decrypt, parse, modify, match cookies, decide what server to send to, etc), it can definitely cause some trouble and will very commonly be accused of being responsible for a lot of trouble that it only revealed. Often it will be discovered that servers are unstable and periodically go up and down, or for web servers, that they deliver pages with some hard-coded links forcing the clients to connect directly to one specific server without passing via the load balancer, or that they take ages to respond under high load causing timeouts. That's why logging is an extremely important aspect of layer 7 load balancing. Once a trouble is reported, it is important to figure if the load balancer took a wrong decision and if so why so that it doesn't happen anymore.

레이어 7 로드 밸런서는 트래픽에 대해 여러 복잡한 작업(복호화, 구문 분석, 수정, 쿠키 일치, 보낼 서버 결정 등)을 수행할 수 있기 때문에 분명히 약간의 문제를 일으킬 수 있으며 매우 일반적으로 단지 공개한 많은 문제에 대한 책임이 있다고 비난받을 것입니다. 종종 서버가 불안정하고 주기적으로 위아래로 움직이거나 웹 서버의 경우 일부 하드 코딩된 링크가 있는 페이지를 전달하여 클라이언트가 로드 밸런서를 거치지 않고 특정 서버에 직접 연결하도록 하거나 시간 초과를 유발하는 높은 부하에서 응답하는 데 시간이 걸립니다. 이것이 로깅이 레이어 7 로드 밸런싱의 매우 중요한 측면인 이유입니다. 문제가 보고되면 로드 밸런서가 잘못된 결정을 내렸는지, 그렇다면 더 이상 그런 일이 발생하지 않도록 하는 이유를 파악하는 것이 중요합니다.


3. Introduction to HAProxy

HAProxy is written as "HAProxy" to designate the product, and as "haproxy" to designate the executable program, software package or a process. However, both are commonly used for both purposes, and are pronounced H-A-Proxy. Very early, "haproxy" used to stand for "high availability proxy" and the name was written in two separate words, though by now it means nothing else than "HAProxy".

HAProxy는 제품을 지칭하기 위해 "HAProxy"로 표기하고, 실행 가능한 프로그램, 소프트웨어 패키지 또는 프로세스를 지칭하기 위해 "haproxy"로 표기한다. 그러나 둘 다 일반적으로 두 가지 목적으로 사용되며 H-A-Proxy로 발음됩니다. 아주 초기에 "haproxy"는 "고가용성 프록시"를 나타내는 데 사용되었으며 이름은 두 개의 별도 단어로 작성되었지만 지금은 "HAProxy" 이외의 의미는 없습니다.

3.1. What HAProxy is and is not   HAProxy가 할 수 있는 것, 하지 않는 것.

HAProxy is : HAProxy가 할 수 있는 것.

  • a TCP proxy : it can accept a TCP connection from a listening socket, connect to a server and attach these sockets together allowing traffic to flow in both directions; IPv4, IPv6 and even UNIX sockets are supported on either side, so this can provide an easy way to translate addresses between different families.
    TCP 프록시: 수신 소켓에서 TCP 연결을 수락하고 서버에 연결하고 이 소켓을 함께 연결하여 트래픽이 양방향으로 흐르도록 할 수 있습니다. IPv4, IPv6 및 UNIX 소켓도 양쪽에서 지원되므로 서로 다른 제품군 간에 주소를 쉽게 변환할 수 있습니다.
  • an HTTP reverse-proxy (called a "gateway" in HTTP terminology) : it presents itself as a server, receives HTTP requests over connections accepted on a listening TCP socket, and passes the requests from these connections to servers using different connections. It may use any combination of HTTP/1.x or HTTP/2 on any side and will even automatically detect the protocol spoken on each side when ALPN is used over TLS.
    HTTP 역 프록시(HTTP 용어로 "게이트웨이"라고 함): 자신을 서버로 표시하고 수신 TCP 소켓에서 허용된 연결을 통해 HTTP 요청을 수신하고 이러한 연결의 요청을 다른 연결을 사용하는 서버로 전달합니다. 어느 쪽에서든 HTTP/1.x 또는 HTTP/2의 조합을 사용할 수 있으며 ALPN이 TLS를 통해 사용될 때 양쪽에서 사용되는 프로토콜을 자동으로 감지합니다.
    ALPN(Application Layer Protocol Negotiation) : 보안 연결을 통해 HTTP/2 트래픽이 실행되도록 허용합니다.
  • an SSL terminator / initiator / offloader : SSL/TLS may be used on the connection coming from the client, on the connection going to the server, or even on both connections. A lot of settings can be applied per name (SNI), and may be updated at runtime without restarting. Such setups are extremely scalable and deployments involving tens to hundreds of thousands of certificates were reported.
    SSL 터미네이터/이니시에이터/오프로더: SSL/TLS는 클라이언트에서 오는 연결, 서버로 가는 연결 또는 두 연결 모두에서 사용될 수 있습니다. 이름당(SNI) 많은 설정을 적용할 수 있으며 다시 시작하지 않고 런타임에 업데이트할 수 있습니다. 이러한 설정은 확장성이 매우 뛰어나며 수만에서 수십만 개의 인증서가 포함된 배포가 보고되었습니다.
    SNI(Server Name Indication) : 컴퓨터 네트워크 프로토콜인 TLS의 확장으로, 핸드셰이킹 과정 초기에 클라이언트가 어느 호스트명에 접속하려는지 서버에 알리는 역할을 한다.
  • a TCP normalizer : since connections are locally terminated by the operating system, there is no relation between both sides, so abnormal traffic such as invalid packets, flag combinations, window advertisements, sequence numbers, incomplete connections (SYN floods), or so will not be passed to the other side. This protects fragile TCP stacks from protocol attacks, and also allows to optimize the connection parameters with the client without having to modify the servers' TCP stack settings.
    TCP 노멀라이저: 운영 체제에 의해 로컬에서 연결이 종료되므로 양측 간에 아무런 관련이 없으므로 잘못된 패킷, 플래그 조합, 창 광고, 시퀀스 번호, 불완전한 연결(SYN 플러드) 등과 같은 비정상적인 트래픽이 발생합니다. 반대편으로 넘어가지 않습니다. 이렇게 하면 취약한 TCP 스택을 프로토콜 공격으로부터 보호하고 서버의 TCP 스택 설정을 수정하지 않고도 클라이언트와의 연결 매개변수를 최적화할 수 있습니다.
  • an HTTP normalizer : when configured to process HTTP traffic, only valid complete requests are passed. This protects against a lot of protocol-based attacks. Additionally, protocol deviations for which there is a tolerance in the specification are fixed so that they don't cause problem on the servers (e.g. multiple-line headers).
    HTTP 노멀라이저: HTTP 트래픽을 처리하도록 구성된 경우 유효한 완전한 요청만 전달됩니다. 이것은 많은 프로토콜 기반 공격으로부터 보호합니다. 또한 사양에 허용 오차가 있는 프로토콜 편차가 서버에 문제를 일으키지 않도록 수정됩니다(예: 다중 라인 헤더).
  • an HTTP fixing tool : it can modify / fix / add / remove / rewrite the URL or any request or response header. This helps fixing interoperability issues in complex environments.
    HTTP 수정 도구: URL 또는 요청 또는 응답 헤더를 수정(modify)/고침(fix)/추가/제거/재작성할 수 있습니다. 이는 복잡한 환경에서 상호 운용성 문제를 해결하는 데 도움이 됩니다.
  • a content-based switch : it can consider any element from the request to decide what server to pass the request or connection to. Thus it is possible to handle multiple protocols over a same port (e.g. HTTP, HTTPS, SSH).
    콘텐츠 기반 스위치: 요청 또는 연결을 전달할 서버를 결정하기 위해 요청의 모든 요소를 고려할 수 있습니다. 따라서 동일한 포트(예: HTTP, HTTPS, SSH)를 통해 여러 프로토콜을 처리할 수 있습니다.
  • a server load balancer : it can load balance TCP connections and HTTP requests. In TCP mode, load balancing decisions are taken for the whole connection. In HTTP mode, decisions are taken per request.
    서버 로드 밸런서 : TCP 연결 및 HTTP 요청의 로드 밸런싱을 수행할 수 있습니다. TCP 모드에서는 전체 연결에 대해 로드 밸런싱 결정이 내려집니다. HTTP 모드에서는 요청별로 결정이 내려집니다.
  • a traffic regulator : it can apply some rate limiting at various points, protect the servers against overloading, adjust traffic priorities based on the contents, and even pass such information to lower layers and outer network components by marking packets.
    트래픽 레귤레이터 : 다양한 지점에서 속도 제한을 적용하고 과부하로부터 서버를 보호하고 콘텐츠에 따라 트래픽 우선 순위를 조정하고 패킷을 표시하여 이러한 정보를 하위 계층 및 외부 네트워크 구성 요소에 전달할 수도 있습니다.
  • a protection against DDoS and service abuse : it can maintain a wide number of statistics per IP address, URL, cookie, etc and detect when an abuse is happening, then take action (slow down the offenders, block them, send them to outdated contents, etc).
    DDoS 및 서비스 남용에 대한 보호 : IP 주소, URL, 쿠키 등 다양한 통계를 유지하고, 남용 발생 시 감지하여 조치(공격자 속도 저하, 차단, 오래된 사용자에게 전송 내용 등).
  • an observation point for network troubleshooting : due to the precision of the information reported in logs, it is often used to narrow down some network-related issues.
    네트워크 문제 해결을 위한 관찰 지점: 로그에 보고되는 정보의 정확성으로 인해 일부 네트워크 관련 문제의 범위를 좁히는 데 자주 사용됩니다.
  • an HTTP compression offloader : it can compress responses which were not compressed by the server, thus reducing the page load time for clients with poor connectivity or using high-latency, mobile networks.
    HTTP 압축 오프로더: 서버에서 압축하지 않은 응답을 압축할 수 있으므로 연결이 좋지 않거나 대기 시간이 긴 모바일 네트워크를 사용하는 클라이언트의 페이지 로드 시간을 줄일 수 있습니다.
  • a caching proxy : it may cache responses in RAM so that subsequent requests for the same object avoid the cost of another network transfer from the server as long as the object remains present and valid. It will however not store objects to any persistent storage. Please note that this caching feature is designed to be maintenance free and focuses solely on saving haproxy's precious resources and not on save the server's resources. Caches designed to optimize servers require much more tuning and flexibility. If you instead need such an advanced cache, please use Varnish Cache, which integrates perfectly with haproxy, especially when SSL/TLS is needed on any side.
    캐싱 프록시 : 동일한 객체에 대한 후속 요청이 객체가 존재하고 유효한 상태로 유지되는 한 서버로부터의 다른 네트워크 전송 비용을 피하기 위해 RAM에 응답을 캐시할 수 있습니다. 그러나 영구 저장소에 개체를 저장하지 않습니다. 이 캐싱 기능은 유지 관리가 필요 없도록 설계되었으며 서버의 리소스를 절약하는 것이 아니라 haproxy의 귀중한 리소스를 절약하는 데에만 중점을 둡니다. 서버를 최적화하도록 설계된 캐시에는 훨씬 더 많은 조정과 유연성이 필요합니다. 이러한 고급 캐시가 필요한 경우 특히 SSL/TLS가 어느 쪽에서나 필요할 때 haproxy와 완벽하게 통합되는 Varnish Cache를 사용하십시오.
  • a FastCGI gateway : FastCGI can be seen as a different representation of HTTP, and as such, HAProxy can directly load-balance a farm comprising any combination of FastCGI application servers without requiring to insert another level of gateway between them. This results in resource savings and a reduction of maintenance costs.
    FastCGI 게이트웨이: FastCGI는 HTTP의 다른 표현으로 볼 수 있으므로 HAProxy는 FastCGI 응용 프로그램 서버 사이에 다른 수준의 게이트웨이를 삽입할 필요 없이 조합으로 구성된 팜을 직접 로드 밸런싱할 수 있습니다. 그 결과 자원이 절약되고 유지보수 비용이 절감됩니다.

HAProxy is not : HAProxy가 하지 않는 것.

  • an explicit HTTP proxy, i.e. the proxy that browsers use to reach the internet. There are excellent open-source software dedicated for this task, such as Squid. However HAProxy can be installed in front of such a proxy to provide load balancing and high availability.
    명시적 HTTP 프록시, 즉 브라우저가 인터넷에 연결하는 데 사용하는 프록시입니다. Squid와 같이 이 작업을 위한 우수한 오픈 소스 소프트웨어가 있습니다. 그러나 로드 밸런싱 및 고가용성을 제공하기 위해 HAProxy를 이러한 프록시 앞에 설치할 수 있습니다.
    Squid, wiki : 오픈 소스(GPL)소프트웨어 프록시 서버이자 웹 캐시이다.
  • a data scrubber : it will not modify the body of requests nor responses.
    데이터 스크러버: 요청이나 응답의 본문을 수정하지 않습니다.
    data scrubber : 백그라운드 작업을 사용하여 주기적으로 메인 메모리 또는 스토리지에서 오류를 검사한 다음 다른 체크섬 또는 데이터 복사본 형태의 중복 데이터를 사용하여 감지된 오류를 수정 하는 오류 수정 기술입니다.
  • a static web server : during startup, it isolates itself inside a chroot jail and drops its privileges, so that it will not perform any single file- system access once started. As such it cannot be turned into a static web server (dynamic servers are supported through FastCGI however). There are excellent open-source software for this such as Apache or Nginx, and HAProxy can be easily installed in front of them to provide load balancing, high availability and acceleration.
    정적 웹 서버: 시작하는 동안 chroot 감옥 내부에 자체를 격리하고 권한을 삭제하여 시작되면 단일 파일 시스템 액세스를 수행하지 않습니다. 따라서 정적 웹 서버로 전환할 수 없습니다(동적 서버는 FastCGI를 통해 지원됨). Apache 또는 Nginx와 같은 이를 위한 뛰어난 오픈 소스 소프트웨어가 있으며 HAProxy는 로드 밸런싱, 고가용성 및 가속을 제공하기 위해 그 앞에 쉽게 설치할 수 있습니다.
    chroot: change root directory, jail (isolated) : 프로세스의 루트 디렉터리 격리
  • a packet-based load balancer : it will not see IP packets nor UDP datagrams, will not perform NAT or even less DSR. These are tasks for lower layers. Some kernel-based components such as IPVS (Linux Virtual Server) already do this pretty well and complement perfectly with HAProxy.
    패킷 기반 로드 밸런서: IP 패킷이나 UDP 데이터그램을 볼 수 없으며 NAT 또는 더 적은 DSR(Direct Server Return)을 수행하지 않습니다. 하위 계층에 대한 작업입니다. IPVS(Linux Virtual Server)와 같은 일부 커널 기반 구성 요소는 이미 이를 잘 수행하고 HAProxy와 완벽하게 보완합니다.
    IPVS(IP Virtual Server), LVS(Linux Virtual Server) : Linux에서 제공하는 L4 Load Balancer 솔루션

3.2. How HAProxy works

HAProxy is an event-driven, non-blocking engine combining a very fast I/O layer with a priority-based, multi-threaded scheduler. As it is designed with a data forwarding goal in mind, its architecture is optimized to move data as fast as possible with the least possible operations. It focuses on optimizing the CPU cache's efficiency by sticking connections to the same CPU as long as possible. As such it implements a layered model offering bypass mechanisms at each level ensuring data doesn't reach higher levels unless needed. Most of the processing is performed in the kernel, and HAProxy does its best to help the kernel do the work as fast as possible by giving some hints or by avoiding certain operation when it guesses they could be grouped later. As a result, typical figures show 15% of the processing time spent in HAProxy versus 85% in the kernel in TCP or HTTP close mode, and about 30% for HAProxy versus 70% for the kernel in HTTP keep-alive mode.

HAProxy는 매우 빠른 I/O 계층과 우선 순위 기반의 다중 스레드 스케줄러를 결합한 이벤트 중심의 비차단 엔진입니다. 데이터 전달 목표를 염두에 두고 설계되었기 때문에 아키텍처는 최소한의 작업으로 최대한 빠르게 데이터를 이동하도록 최적화되어 있습니다. 동일한 CPU에 가능한 한 오랫동안 연결을 유지하여 CPU 캐시의 효율성을 최적화하는 데 중점을 둡니다. 따라서 필요한 경우가 아니면 데이터가 더 높은 수준에 도달하지 않도록 각 수준에서 우회 메커니즘을 제공하는 계층화된 모델을 구현합니다.
대부분의 처리는 커널에서 수행되며 HAProxy는 몇 가지 힌트를 제공하거나 나중에 그룹화될 수 있다고 추측할 때 특정 작업을 피함으로써 커널이 가능한 한 빨리 작업을 수행할 수 있도록 최선을 다합니다.
결과적으로 일반적인 수치는 TCP 또는 HTTP 닫기 모드에서 커널에서 85%, HAProxy에서 15%, HTTP 연결 유지 모드에서 커널에서 70%, HAProxy에 약 30% CPU 사용률을 보여줍니다.

A single process can run many proxy instances; configurations as large as 300,000 distinct proxies in a single process were reported to run fine. A single core, single CPU setup is far more than enough for more than 99% users, and as such, users of containers and virtual machines are encouraged to use the absolute smallest images they can get to save on operational costs and simplify troubleshooting. However the machine HAProxy runs on must never ever swap, and its CPU must not be artificially throttled (sub-CPU allocation in hypervisors) nor be shared with compute-intensive processes which would induce a very high context-switch latency.

단일 프로세스는 많은 프록시 인스턴스를 실행할 수 있습니다. 단일 프로세스에서 최대 300,000개의 개별 프록시 구성이 제대로 실행되는 것으로 보고되었습니다. 단일 코어, 단일 CPU 설정은 99% 이상의 사용자에게 충분하므로 컨테이너 및 가상 머신 사용자는 운영 비용을 절감하고 문제 해결을 단순화하기 위해 얻을 수 있는 가장 작은 이미지를 사용하는 것이 좋습니다. 그러나 HAProxy가 실행되는 시스템은 절대로 스왑되어서는 안 되며, 해당 CPU는 인위적으로 조절되거나(하이퍼바이저의 하위 CPU 할당) 매우 높은 컨텍스트 전환 대기 시간을 유발할 수 있는 컴퓨팅 집약적인 프로세스와 공유되어서는 안 됩니다.

Threading allows to exploit all available processing capacity by using one thread per CPU core. This is mostly useful for SSL or when data forwarding rates above 40 Gbps are needed. In such cases it is critically important to avoid communications between multiple physical CPUs, which can cause strong bottlenecks in the network stack and in HAProxy itself. While counter-intuitive to some, the first thing to do when facing some performance issues is often to reduce the number of CPUs HAProxy runs on.

스레딩을 사용하면 CPU 코어당 하나의 스레드를 사용하여 사용 가능한 모든 처리 용량을 활용할 수 있습니다. 이는 SSL 또는 40Gbps 이상의 데이터 전달 속도가 필요한 경우에 주로 유용합니다. 이러한 경우 네트워크 스택과 HAProxy 자체에 강력한 병목 현상을 일으킬 수 있는 여러 물리적 CPU 간의 통신을 피하는 것이 매우 중요합니다. 일부 사람들에게는 직관적이지 않지만 일부 성능 문제에 직면했을 때 가장 먼저 해야 할 일은 종종 HAProxy가 실행되는 CPU 수를 줄이는 것입니다.

HAProxy only requires the haproxy executable and a configuration file to run. For logging it is highly recommended to have a properly configured syslog daemon and log rotations in place. Logs may also be sent to stdout/stderr, which can be useful inside containers. The configuration files are parsed before starting, then HAProxy tries to bind all listening sockets, and refuses to start if anything fails. Past this point it cannot fail anymore. This means that there are no runtime failures and that if it accepts to start, it will work until it is stopped.

HAProxy를 실행하려면 haproxy 실행 파일과 구성 파일만 필요합니다. 로깅을 위해 적절하게 구성된 syslog 데몬과 로그 회전을 제자리에 두는 것이 좋습니다. 로그는 컨테이너 내부에서 유용할 수 있는 stdout/stderr로 보낼 수도 있습니다. 구성 파일은 시작하기 전에 구문 분석된 다음 HAProxy가 모든 수신 소켓을 바인딩하려고 시도하고 실패하는 경우 시작을 거부합니다. 이 시점을 지나면 더 이상 실패할 수 없습니다. 즉, 런타임 오류가 없으며 시작을 수락하면 중지될 때까지 작동합니다.

Once HAProxy is started, it does exactly 3 things :
- process incoming connections;
- periodically check the servers' status (known as health checks);
- exchange information with other haproxy nodes.
HAProxy가 시작되면 정확히 3가지 작업을 수행합니다.
- 들어오는 연결을 처리합니다.
- 주기적으로 서버의 상태를 확인합니다(health checks라고 함).
- 다른 haproxy 노드와 정보를 교환합니다.

Processing incoming connections is by far the most complex task as it depends on a lot of configuration possibilities, but it can be summarized as the 9 steps below :
들어오는 연결을 처리하는 것은 많은 구성 가능성에 따라 달라지기 때문에 가장 복잡한 작업이지만 아래의 9단계로 요약할 수 있습니다.

  • step 1: accept incoming connections from listening sockets that belong to a configuration entity known as a "frontend", which references one or multiple listening addresses;
    하나 이상의 수신 주소를 참조하는 "프론트엔드(frontend)"로 알려진 구성 엔티티에 속하는 수신 소켓에서 들어오는 연결을 수락합니다.
  • step 2: apply the frontend-specific processing rules to these connections that may result in blocking them, modifying some headers, or intercepting them to execute some internal applets such as the statistics page or the CLI;
    이러한 연결에 프론트엔드별 처리 규칙을 적용하여 연결을 차단하거나 일부 헤더를 수정하거나 통계 페이지 또는 CLI와 같은 일부 내부 애플릿을 실행하기 위해 차단할 수 있습니다.
  • step 3: pass these incoming connections to another configuration entity representing a server farm known as a "backend", which contains the list of servers and the load balancing strategy for this server farm;
    이러한 들어오는 연결을 "백엔드(backend)"라고 하는 서버 팜을 나타내는 다른 구성 엔터티에 전달합니다. 여기에는 서버 목록과 이 서버 팜에 대한 로드 밸런싱 전략이 포함됩니다.
  • step 4: apply the backend-specific processing rules to these connections;
    이러한 연결에 백엔드별 처리 규칙을 적용합니다.
  • step 5: decide which server to forward the connection to according to the load balancing strategy;
    로드 밸런싱 전략에 따라 연결을 전달할 서버를 결정합니다.
  • step 6: apply the backend-specific processing rules to the response data;
    응답 데이터에 백엔드별 처리 규칙을 적용합니다.
  • step 7: apply the frontend-specific processing rules to the response data;
    응답 데이터에 프론트엔드별 처리 규칙을 적용합니다.
  • step 8: emit a log to report what happened in fine details;
    무슨 일이 있었는지 자세히 보고하기 위해 로그를 내보냅니다.
  • step 9: in HTTP, loop back to the second step to wait for a new request, otherwise close the connection.
    HTTP에서 두 번째 단계로 루프백하여 새 요청을 기다리거나 그렇지 않으면 연결을 닫습니다.

Frontends and backends are sometimes considered as half-proxies, since they only look at one side of an end-to-end connection; the frontend only cares about the clients while the backend only cares about the servers. HAProxy also supports full proxies which are exactly the union of a frontend and a backend. When HTTP processing is desired, the configuration will generally be split into frontends and backends as they open a lot of possibilities since any frontend may pass a connection to any backend. With TCP-only proxies, using frontends and backends rarely provides a benefit and the configuration can be more readable with full proxies.

프런트엔드와 백엔드는 종단 간 연결의 한 쪽만 보기 때문에 때때로 하프 프록시로 간주됩니다. 프론트엔드는 클라이언트에만 관심이 있고 백엔드는 서버에만 관심이 있습니다. HAProxy는 또한 프론트엔드와 백엔드의 결합인 전체 프록시를 지원합니다. HTTP 처리가 필요한 경우 구성은 일반적으로 프론트엔드와 백엔드로 분할됩니다. 모든 프론트엔드가 백엔드에 대한 연결을 전달할 수 있기 때문에 많은 가능성이 열리기 때문입니다. TCP 전용 프록시를 사용하면 프론트엔드와 백엔드를 사용하는 것이 거의 이점을 제공하지 않으며 전체 프록시를 사용하면 구성을 더 쉽게 읽을 수 있습니다.

3.3. Basic features

This section will enumerate a number of features that HAProxy implements, some of which are generally expected from any modern load balancer, and some of which are a direct benefit of HAProxy's architecture. More advanced features will be detailed in the next section.

이 섹션에서는 HAProxy가 구현하는 여러 기능을 열거합니다. 그 중 일부는 일반적으로 모든 최신 로드 밸런서에서 예상되며 일부는 HAProxy 아키텍처의 직접적인 이점입니다. 더 많은 고급 기능은 다음 섹션에서 자세히 설명합니다.

3.3.1. Basic features : Proxying

Proxying is the action of transferring data between a client and a server over two independent connections. The following basic features are supported by HAProxy regarding proxying and connection management :

프록시는 두 개의 독립적인 연결을 통해 클라이언트와 서버 간에 데이터를 전송하는 작업입니다. 프록시 및 연결 관리와 관련하여 HAProxy에서 지원하는 기본 기능은 다음과 같습니다.

  • Provide the server with a clean connection to protect them against any client-side defect or attack;
    클라이언트 측 결함이나 공격으로부터 서버를 보호하기 위해 깨끗한 연결을 서버에 제공합니다.
  • Listen to multiple IP addresses and/or ports, even port ranges;
    여러 IP 주소 및 포트, 심지어 포트 범위를 수신합니다.
  • Transparent accept : intercept traffic targeting any arbitrary IP address that doesn't even belong to the local system;
    투명 수락: 로컬 시스템에도 속하지 않는 임의의 IP 주소를 대상으로 하는 트래픽을 가로챕니다.
  • Server port doesn't need to be related to listening port, and may even be translated by a fixed offset (useful with ranges);
    서버 포트는 수신 포트와 관련될 필요가 없으며 고정 오프셋으로 변환될 수도 있습니다(범위에 유용).
  • Transparent connect : spoof the client's (or any) IP address if needed when connecting to the server;
    투명 연결: 서버에 연결할 때 필요한 경우 클라이언트(또는 임의의) IP 주소를 변조합니다.
    변조(Spoofing)의 사전적 의미는 '속이다'이다. 네트워크에서 스푸핑 대상은 MAC 주소, IP주소, 포트 등 네트워크 통신과 관련된 모든 것이 될 수 있고, 스푸핑은 속임을 이용한 공격을 총칭한다.
  • Provide a reliable return IP address to the servers in multi-site LBs;
    다중 사이트 LB의 서버에 안정적인 반환 IP 주소를 제공합니다.
  • Offload the server thanks to buffers and possibly short-lived connections to reduce their concurrent connection count and their memory footprint;
    버퍼와 가능한 단기 연결 덕분에 서버의 부하를 줄여 동시 연결 수와 메모리 사용 공간을 줄입니다.
  • Optimize TCP stacks (e.g. SACK), congestion control, and reduce RTT impacts;
    TCP 스택(예: SACK), 혼잡 제어를 최적화하고 RTT 영향을 줄입니다.
    SACK(Selective Acknowledgments) : TCP 손실 복구 알고리즘 중 하나
    RTT(Round Trip Time, 왕복 시간) : 패킷 왕복 시간
  • Support different protocol families on both sides (e.g. IPv4/IPv6/Unix);
    양쪽에서 서로 다른 프로토콜 제품군을 지원합니다(예: IPv4/IPv6/Unix).
  • Timeout enforcement : HAProxy supports multiple levels of timeouts depending on the stage the connection is, so that a dead client or server, or an attacker cannot be granted resources for too long;
    제한시간 적용: HAProxy는 연결 단계에 따라 여러 수준의 제한시간을 지원하므로 죽은 클라이언트나 서버 또는 공격자에게 너무 오랫동안 리소스를 부여할 수 없습니다.
  • Protocol validation: HTTP, SSL, or payload are inspected and invalid protocol elements are rejected, unless instructed to accept them anyway;
    프로토콜 검증: HTTP, SSL 또는 페이로드를 검사하고 유효하지 않은 프로토콜 요소를 수락하라는 지시가 없는 한 거부합니다.
  • Policy enforcement : ensure that only what is allowed may be forwarded;
    정책 시행: 허용된 내용만 전달되도록 합니다.
  • Both incoming and outgoing connections may be limited to certain network namespaces (Linux only), making it easy to build a cross-container, multi-tenant load balancer;
    들어오는 연결과 나가는 연결 모두 특정 네트워크 네임스페이스로 제한될 수 있으므로(Linux만 해당) 컨테이너 간, 다중 테넌트 로드 밸런서를 쉽게 구축할 수 있습니다.
  • PROXY protocol presents the client's IP address to the server even for non-HTTP traffic. This is an HAProxy extension that was adopted by a number of third-party products by now, at least these ones at the time of writing :
    - client : haproxy, stud, stunnel, exaproxy, ELB, squid
    - server : haproxy, stud, postfix, exim, nginx, squid, node.js, varnish
    PROXY 프로토콜은 HTTP가 아닌 트래픽의 경우에도 클라이언트의 IP 주소를 서버에 제공합니다. 이것은 지금까지 여러 타사 제품에서 채택한 HAProxy 확장입니다. 적어도 작성 당시에는 다음과 같습니다.
    - 클라이언트 : haproxy, stud, stunnel, exaproxy, ELB, squid
    - 서버 : haproxy, stud, postfix, exim, nginx, squid, node.js, varnish

3.3.2. Basic features : SSL

HAProxy's SSL stack is recognized as one of the most featureful according to Google's engineers (http://istlsfastyet.com/). The most commonly used features making it quite complete are : HAProxy의 SSL 스택은 Google 엔지니어에 따르면 가장 기능적인 스택 중 하나로 인식됩니다. 가장 일반적으로 사용되는 기능은 다음과 같습니다.

  • SNI-based multi-hosting with no limit on sites count and focus on performance. At least one deployment is known for running 50000 domains with their respective certificates;
    사이트 수에 제한이 없는 SNI(Server Name Indication) 기반 멀티 호스팅 및 성능에 중점을 둡니다. 적어도 하나의 배포는 각각의 인증서로 50,000개의 도메인을 실행하는 것으로 알려져 있습니다.
  • support for wildcard certificates reduces the need for many certificates ;
    와일드카드 인증서 지원은 많은 인증서의 필요성을 줄입니다.
  • certificate-based client authentication with configurable policies on failure to present a valid certificate. This allows to present a different server farm to regenerate the client certificate for example;
    유효한 인증서를 제시하지 못할 경우 구성 가능한 정책을 사용하는 인증서 기반 클라이언트 인증. 이를 통해 예를 들어 클라이언트 인증서를 다시 생성하기 위해 다른 서버 팜을 제공할 수 있습니다.
  • authentication of the backend server ensures the backend server is the real one and not a man in the middle;
    백엔드 서버의 인증은 백엔드 서버가 중간 서버가 아닌 실제 서버임을 보장합니다.
  • authentication with the backend server lets the backend server know it's really the expected haproxy node that is connecting to it;
    백엔드 서버와의 인증은 백엔드 서버가 실제로 연결되는 예상 haproxy 노드임을 알 수 있도록 합니다.
  • TLS NPN and ALPN extensions make it possible to reliably offload SPDY/HTTP2 connections and pass them in clear text to backend servers;
    TLS NPN 및 ALPN 확장을 통해 SPDY/HTTP2 연결을 안정적으로 오프로드하고 일반 텍스트로 백엔드 서버에 전달할 수 있습니다.
    - TLS(Transport Layer Security) : TLS는 인터넷 커뮤니케이션을 위한 개인 정보와 데이터 무결성을 제공하는 보안 프로토콜
    - NPN(Next Protocol Negotiation)
    - ALPN(Application Layer Protocol Negotiation)
    - SPDY : 웹 콘텐츠를 전송할 목적으로 구글이 개발한 비표준 개방형 네트워크 프로토콜이다.
    Next Protocol Negotiation (NPN) 은 TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장이다. ALPN과 동등한 기능적인 결과를 가져온다. ALPN은 NPN을 수정하여 확장된 버전으로 IETF에 승인을 받았다.
  • OCSP stapling further reduces first page load time by delivering inline an OCSP response when the client requests a Certificate Status Request;
    OCSP 스테이플링은 클라이언트가 인증서 상태 요청을 요청할 때 OCSP 응답을 인라인으로 전달하여 첫 번째 페이지 로드 시간을 더욱 줄입니다.
    OCSP : OCSP 란 Online Certificate Status Protocol - 온라인 인증서 상태 프로토콜 - 의 약자로, 인증서 유효성 확인을 제공하는 방법입니다. 인증서가 폐기된것인지 정상인지 빠르게 확인을 할수 있습니다. CRL (Certificate Revocation List) 도 동일한 기능을 하지만, CRL 보다 개선된 표준이라고 할수 있습니다.
  • Dynamic record sizing provides both high performance and low latency, and significantly reduces page load time by letting the browser start to fetch new objects while packets are still in flight;
    동적 레코드 크기 조정은 고성능과 짧은 대기 시간을 모두 제공하며 패킷이 아직 전송 중인 동안 브라우저가 새 개체를 가져오기 시작하도록 하여 페이지 로드 시간을 크게 줄입니다.
  • permanent access to all relevant SSL/TLS layer information for logging, access control, reporting etc. These elements can be embedded into HTTP header or even as a PROXY protocol extension so that the offloaded server gets all the information it would have had if it performed the SSL termination itself.
    로깅, 액세스 제어, 보고 등을 위한 모든 관련 SSL/TLS 계층 정보에 대한 영구 액세스. 이러한 요소는 HTTP 헤더에 포함되거나 심지어 PROXY 프로토콜 확장으로 포함될 수 있으므로 오프로드된 서버는 SSL 종료 자체를 수행하는 경우 가질 수 있는 모든 정보를 얻습니다.
  • Detect, log and block certain known attacks even on vulnerable SSL libs, such as the Heartbleed attack affecting certain versions of OpenSSL.
    OpenSSL의 특정 버전에 영향을 미치는 Heartbleed 공격과 같이 취약한 SSL 라이브러리에서도 알려진 특정 공격을 탐지, 기록 및 차단합니다.
  • support for stateless session resumption (RFC 5077 TLS Ticket extension). TLS tickets can be updated from CLI which provides them means to implement Perfect Forward Secrecy by frequently rotating the tickets.
    상태 비저장 세션 재개 지원(RFC 5077 TLS 티켓 확장). TLS 티켓은 티켓을 자주 교체하여 Perfect Forward Secrecy를 구현하는 수단을 제공하는 CLI에서 업데이트할 수 있습니다.

3.3.3. Basic features : Monitoring

HAProxy focuses a lot on availability. As such it cares about servers state, and about reporting its own state to other network components : HAProxy는 가용성에 많은 중점을 둡니다. 따라서 서버 상태와 다른 네트워크 구성 요소에 자신의 상태를 보고하는 데 관심이 있습니다.

  • Servers' state is continuously monitored using per-server parameters. This ensures the path to the server is operational for regular traffic;
    서버별 매개변수를 사용하여 서버의 상태를 지속적으로 모니터링합니다. 이렇게 하면 서버에 대한 경로가 일반 트래픽에 대해 작동할 수 있습니다.
  • Health checks support two hysteresis for up and down transitions in order to protect against state flapping;
    상태 확인은 상태 플래핑을 방지하기 위해 위아래 전환에 대한 두 가지 히스테리시스를 지원합니다.
    Flapping: 라우터 간의 링크,경로 등이 죽었다 살았다를 반복하는 현상
  • Checks can be sent to a different address/port/protocol : this makes it easy to check a single service that is considered representative of multiple ones, for example the HTTPS port for an HTTP+HTTPS server.
    확인은 다른 주소/포트/프로토콜로 보낼 수 있습니다. 이렇게 하면 HTTP+HTTPS 서버의 HTTPS 포트와 같이 여러 서비스를 대표하는 것으로 간주되는 단일 서비스를 쉽게 확인할 수 있습니다.
  • Servers can track other servers and go down simultaneously : this ensures that servers hosting multiple services can fail atomically and that no one will be sent to a partially failed server;
    서버는 다른 서버를 추적하고 동시에 다운될 수 있습니다. 이렇게 하면 여러 서비스를 호스팅하는 서버가 원자적으로 실패할 수 있고 부분적으로 실패한 서버로 아무도 보내지지 않습니다.
  • Agents may be deployed on the server to monitor load and health : a server may be interested in reporting its load, operational status, administrative status independently from what health checks can see. By running a simple agent on the server, it's possible to consider the server's view of its own health in addition to the health checks validating the whole path;
    부하 및 상태를 모니터링하기 위해 서버에 에이전트를 배포할 수 있습니다. 서버는 상태 확인에서 볼 수 있는 것과 독립적으로 로드, 작동 상태, 관리 상태를 보고하는 데 관심이 있을 수 있습니다. 서버에서 간단한 에이전트를 실행하면 전체 경로의 유효성을 검사하는 상태 확인 외에도 서버 자체 상태에 대한 서버의 보기를 고려할 수 있습니다.
  • Various check methods are available : TCP connect, HTTP request, SMTP hello, SSL hello, LDAP, SQL, Redis, send/expect scripts, all with/without SSL;
    다양한 확인 방법 사용 가능: TCP 연결, HTTP 요청, SMTP Hello, SSL Hello, LDAP, SQL, Redis, 스크립트 보내기/예상, 모두 SSL 유무;
  • State change is notified in the logs and stats page with the failure reason (e.g. the HTTP response received at the moment the failure was detected). An e-mail can also be sent to a configurable address upon such a change ;
    상태 변경은 실패 이유(예: 실패가 감지된 순간에 수신된 HTTP 응답)와 함께 로그 및 통계 페이지에서 알려줍니다. 이러한 변경 시 구성 가능한 주소로 전자 메일을 보낼 수도 있습니다.
  • Server state is also reported on the stats interface and can be used to take routing decisions so that traffic may be sent to different farms depending on their sizes and/or health (e.g. loss of an inter-DC link);
    서버 상태는 통계 인터페이스에서도 보고되며 트래픽이 크기 및/또는 상태 (예: DC 간 링크 손실)에 따라 다른 팜으로 전송될 수 있도록 라우팅 결정을 내리는 데 사용할 수 있습니다.
  • HAProxy can use health check requests to pass information to the servers, such as their names, weight, the number of other servers in the farm etc. so that servers can adjust their response and decisions based on this knowledge (e.g. postpone backups to keep more CPU available);
    HAProxy는 상태 확인 요청을 사용하여 이름, 무게(weight; 가중치), 팜의 다른 서버 수 등과 같은 정보를 서버에 전달할 수 있습니다. 서버가 이 지식을 기반으로 응답 및 결정을 조정할 수 있도록 합니다(예: 더 많은 CPU를 사용할 수 있도록 백업 연기).
  • Servers can use health checks to report more detailed state than just on/off (e.g. I would like to stop, please stop sending new visitors);
    서버는 상태 확인을 사용하여 켜짐/꺼짐보다 더 자세한 상태를 보고할 수 있습니다 (예: 중지하고 싶습니다. 새 방문자 보내기를 중지하십시오).
  • HAProxy itself can report its state to external components such as routers or other load balancers, allowing to build very complete multi-path and multi-layer infrastructures.
    HAProxy 자체는 라우터 또는 기타 로드 밸런서와 같은 외부 구성 요소에 상태를 보고할 수 있으므로 매우 완전한 다중 경로 및 다중 계층 인프라를 구축할 수 있습니다.

3.3.4. Basic features : High availability 고가용성

Just like any serious load balancer, HAProxy cares a lot about availability to ensure the best global service continuity :
다른 괜찮은 로드 밸런서와 마찬가지로 HAProxy는 최고의 글로벌 서비스 연속성을 보장하기 위해 가용성에 많은 관심을 기울입니다.

  • Only valid servers are used ; the other ones are automatically evicted from load balancing farms ; under certain conditions it is still possible to force to use them though;
    유효한 서버만 사용됩니다. 다른 것들은 로드 밸런싱 팜에서 자동으로 제거됩니다. 특정 조건에서는 여전히 강제로 사용하는 것이 가능합니다.
  • Support for a graceful shutdown so that it is possible to take servers out of a farm without affecting any connection;
    연결에 영향을 주지 않고 팜에서 서버를 제거할 수 있도록 단계적 종료를 지원합니다.
  • Backup servers are automatically used when active servers are down and replace them so that sessions are not lost when possible. This also allows to build multiple paths to reach the same server (e.g. multiple interfaces);
    백업 서버는 활성 서버가 다운될 때 자동으로 사용되며 가능하면 세션이 손실되지 않도록 교체합니다. 이것은 또한 동일한 서버에 도달하기 위해 여러 경로를 구축할 수 있도록 합니다(예: 다중 인터페이스).
  • Ability to return a global failed status for a farm when too many servers are down. This, combined with the monitoring capabilities makes it possible for an upstream component to choose a different LB node for a given service;
    너무 많은 서버가 다운된 경우 팜에 대한 전역 실패 상태를 반환하는 기능. 이것은 모니터링 기능과 결합되어 업스트림 구성 요소가 주어진 서비스에 대해 다른 LB 노드를 선택할 수 있도록 합니다.
  • Stateless design makes it easy to build clusters : by design, HAProxy does its best to ensure the highest service continuity without having to store information that could be lost in the event of a failure. This ensures that a takeover is the most seamless possible;
    상태 비저장 설계로 클러스터 구축이 용이합니다. 설계상 HAProxy는 장애 발생 시 손실될 수 있는 정보를 저장할 필요 없이 최고의 서비스 연속성을 보장하기 위해 최선을 다합니다. 이를 통해 인수(takeover)가 가장 원활하게 이루어집니다.
  • Integrates well with standard VRRP daemon keepalived : HAProxy easily tells keepalived about its state and copes very well with floating virtual IP addresses.
    Note: only use IP redundancy protocols (VRRP/CARP) over cluster- based solutions (Heartbeat, ...) as they're the ones offering the fastest, most seamless, and most reliable switchover.
    표준 VRRP 데몬 keepalived와 잘 통합됩니다. HAProxy는 keepalived 상태에 대해 쉽게 알려주고 유동 가상 IP 주소에 매우 잘 대처합니다.
    참고: 클러스터 기반 솔루션(Heartbeat, ...)보다 IP 중복 프로토콜(VRRP/CARP)만 사용하십시오. 가장 빠르고 원활하며 안정적인 전환을 제공하는 솔루션이기 때문입니다.

    VRRP(Virtual Router Redundancy Protocol) : Failover를 목적으로 Primary/Secondary 장비 간의 전환을 위해 사용된다.
      참고 1: VRRP란? (게이트웨이 이중화 구성 - FHRP)
      참고 2: VRRP 개념 - 게이트 웨이 이중화
    CARP(Common Address Redundancy Protocol) : 동일한 LAN 에 있는 여러 호스트가 IP 주소 집합을 공유할 수 있도록 하는 네트워킹 프로토콜 입니다. 주요 목적은 방화벽 및 라우터와 함께 사용할 때 장애 복구 중복성을 제공하는 것입니다. 일부 구성에서 CARP는 부하 분산 기능도 제공할 수 있습니다. CARP는 VRRP 및 Cisco Systems의 HSRP(Hot Standby Router Protocol)와 유사한 기능을 제공합니다.
    CARP와 HAProxy 설명

3.3.5. Basic features : Load balancing

HAProxy offers a fairly complete set of load balancing features, most of which are unfortunately not available in a number of other load balancing products :
HAProxy는 상당히 완전한 로드 밸런싱 기능 세트를 제공하며, 대부분은 불행히도 다른 여러 로드 밸런싱 제품에서 사용할 수 없습니다.

  • no less than 10 load balancing algorithms are supported, some of which apply to input data to offer an infinite list of possibilities.
    The most common ones are
    1) round-robin: for short connections, pick each server in turn
    2) leastconn: for long connections, pick the least recently used of the servers with the lowest connection count
    3) source: for SSL farms or terminal server farms, the server directly depends on the client's source address
    4) URI: for HTTP caches, the server directly depends on the HTTP URI
    5) hdr: the server directly depends on the contents of a specific HTTP header field
    6) first: for short-lived virtual machines, all connections are packed on the smallest possible subset of servers so that unused ones can be powered down

    10개 이상의 로드 밸런싱 알고리즘이 지원되며, 그 중 일부는 무한한 가능성 목록을 제공하기 위해 입력 데이터에 적용됩니다.
    가장 일반적인 것은
    1) round-robin: 짧은 연결의 경우 각 서버를 차례로 선택
    2) leastconn(최소 연결): 긴 연결의 경우 연결 수가 가장 적은 서버 중 가장 최근에 사용된 서버 선택
    3) source: SSL 팜 또는 터미널 서버 팜의 경우 서버는 클라이언트의 소스 주소에 직접 종속됨
    4) URI: HTTP 캐시의 경우 서버는 HTTP URI에 직접 의존함
    5) hdr: 서버는 특정 HTTP 헤더 필드의 내용에 직접적으로 의존함
    6) first: 짧은 수명의 가상 머신의 경우 모든 연결은 사용되지 않는 서버의 전원을 끌 수 있도록 가능한 가장 작은 서버 하위 집합에 포장됩니다.
  • all algorithms above support per-server weights so that it is possible to accommodate from different server generations in a farm, or direct a small fraction of the traffic to specific servers (debug mode, running the next version of the software, etc);
    위의 모든 알고리즘은 서버당 가중치를 지원하므로 팜의 다른 서버 세대를 수용하거나 트래픽의 작은 부분을 특정 서버(디버그 모드, 다음 버전의 소프트웨어 실행 등)로 보낼 수 있습니다.
  • dynamic weights are supported for round-robin, leastconn and consistent hashing ; this allows server weights to be modified on the fly from the CLI or even by an agent running on the server;
    round-robin, leastconn, 일관된 해싱에 대해 동적 가중치가 지원됩니다. 이를 통해 CLI에서 또는 서버에서 실행 중인 에이전트에 의해 서버 가중치를 즉시 수정할 수 있습니다.
  • slow-start is supported whenever a dynamic weight is supported; this allows a server to progressively take the traffic. This is an important feature for fragile application servers which require to compile classes at runtime as well as cold caches which need to fill up before being run at full throttle;
    동적 가중치가 지원될 때마다 느린 시작이 지원됩니다. 이렇게 하면 서버가 점진적으로 트래픽을 처리할 수 있습니다. 이것은 런타임에 클래스를 컴파일해야 하는 취약한 애플리케이션 서버와 최대 제한에서 실행되기 전에 채워야 하는 콜드 캐시에 대한 중요한 기능입니다.
  • hashing can apply to various elements such as client's source address, URL components, query string element, header field values, POST parameter, RDP cookie;
    해싱은 클라이언트의 소스 주소, URL 구성 요소, 쿼리 문자열 요소, 헤더 필드 값, POST 매개변수, RDP 쿠키와 같은 다양한 요소에 적용될 수 있습니다.
  • consistent hashing protects server farms against massive redistribution when adding or removing servers in a farm. That's very important in large cache farms and it allows slow-start to be used to refill cold caches;
    일관된 해싱은 팜에 서버를 추가하거나 제거할 때 대규모 재배포로부터 서버 팜을 보호합니다. 이는 대규모 캐시 팜에서 매우 중요하며 콜드 캐시를 다시 채우는 데 느린 시작(slow-start)을 사용할 수 있습니다.
  • a number of internal metrics such as the number of connections per server, per backend, the amount of available connection slots in a backend etc makes it possible to build very advanced load balancing strategies.
    서버당 연결 수, 백엔드당 연결 수, 백엔드에서 사용 가능한 연결 슬롯 수 등과 같은 여러 내부 메트릭을 통해 매우 고급 로드 밸런싱 전략을 구축할 수 있습니다.

3.3.6. Basic features : Stickiness 고정성

Application load balancing would be useless without stickiness. HAProxy provides a fairly comprehensive set of possibilities to maintain a visitor on the same server even across various events such as server addition/removal, down/up cycles, and some methods are designed to be resistant to the distance between multiple load balancing nodes in that they don't require any replication :
애플리케이션 로드 밸런싱은 고정성 없이는 쓸모가 없습니다. HAProxy는 서버 추가/제거, 다운/업 주기와 같은 다양한 이벤트에서도 동일한 서버에 방문자를 유지할 수 있는 상당히 포괄적인 가능성 세트를 제공하며 일부 방법은 여러 로드 밸런싱 노드 간의 거리에 저항하도록 설계되었습니다. 복제가 필요하지 않습니다.

Choosing a stickiness strategy for your load balancer : Stickiness is a term that is used to describe the functionality of a load balancer to repeatedly route traffic from a client to a single destination, instead of balancing the traffic across multiple destinations. For example, traffic from client A can be continually routed to a specific server, so that server can maintain session state data. If traffic from client A is routed to two distinct servers, each server might be missing important information that’s available to the other server.
고정성은 여러 대상 간에 트래픽을 분산시키는 대신 클라이언트에서 단일 대상으로 트래픽을 반복적으로 라우팅하는 로드 밸런서의 기능을 설명하는 데 사용되는 용어입니다. 예를 들어 클라이언트 A의 트래픽은 지속적으로 특정 서버로 라우팅되어 서버가 세션 상태 데이터를 유지할 수 있습니다. 클라이언트 A의 트래픽이 두 개의 서로 다른 서버로 라우팅되는 경우 각 서버에는 다른 서버에서 사용할 수 있는 중요한 정보가 누락될 수 있습니다.

  • stickiness information can be individually matched and learned from different places if desired. For example a JSESSIONID cookie may be matched both in a cookie and in the URL. Up to 8 parallel sources can be learned at the same time and each of them may point to a different stick-table;
    고정성 정보는 개별적으로 매칭하여 원하는 경우 다른 장소에서 학습할 수 있습니다. 예를 들어 JSESSIONID 쿠키는 쿠키와 URL 모두에서 일치할 수 있습니다. 최대 8개의 병렬 소스를 동시에 학습할 수 있으며 각각은 다른 고정 테이블을 가리킬 수 있습니다.
  • stickiness information can come from anything that can be seen within a request or response, including source address, TCP payload offset and length, HTTP query string elements, header field values, cookies, and so on.
    고정성 정보는 소스 주소, TCP 페이로드 오프셋과 길이, HTTP 쿼리 문자열 요소, 헤더 필드 값, 쿠키 등을 포함하여 요청 또는 응답 내에서 볼 수 있는 모든 것에서 올 수 있습니다.
  • stick-tables are replicated between all nodes in a multi-master fashion;
    고정 테이블은 다중 마스터 방식으로 모든 노드 간에 복제됩니다.
  • commonly used elements such as SSL-ID or RDP cookies (for TSE farms) are directly accessible to ease manipulation;
    SSL-ID 또는 RDP 쿠키(TSE 팜용)와 같이 일반적으로 사용되는 요소는 쉽게 조작할 수 있도록 직접 액세스할 수 있습니다.
    RDP(Remode Desktop Protocal) : 원격으로 서버나 컴퓨터의 파일, 앱, 데스크톱 공간을 사용할 수 있습니다.
  • all sticking rules may be dynamically conditioned by ACLs;
    모든 고정 규칙은 ACL에 의해 동적으로 조절될 수 있습니다.
  • it is possible to decide not to stick to certain servers, such as backup servers, so that when the nominal server comes back, it automatically takes the load back. This is often used in multi-path environments;
    백업 서버와 같은 특정 서버에 고정되지 않도록 결정할 수 있어 명목상(이름뿐인) 서버가 돌아올 때 자동으로 로드를 가져옵니다. 이것은 다중 경로 환경에서 자주 사용됩니다.
  • in HTTP it is often preferred not to learn anything and instead manipulate a cookie dedicated to stickiness. For this, it's possible to detect, rewrite, insert or prefix such a cookie to let the client remember what server was assigned;
    HTTP에서는 아무것도 배우지 않고 대신 고정성 전용 쿠키를 조작하는 것이 종종 선호됩니다. 이를 위해 클라이언트가 할당된 서버를 기억할 수 있도록 이러한 쿠키를 감지, 재작성, 삽입 또는 접두사로 사용할 수 있습니다.
  • the server may decide to change or clean the stickiness cookie on logout, so that leaving visitors are automatically unbound from the server;
    서버는 로그아웃 시 고정 쿠키를 변경하거나 정리하여 이탈 방문자가 서버에서 자동으로 해제되도록 결정할 수 있습니다.
  • using ACL-based rules it is also possible to selectively ignore or enforce stickiness regardless of the server's state; combined with advanced health checks, that helps admins verify that the server they're installing is up and running before presenting it to the whole world;
    ACL 기반 규칙을 사용하여 서버 상태에 관계없이 선택적으로 고정성을 무시하거나 적용할 수도 있습니다. 고급 상태 검사와 결합하여 관리자가 설치 중인 서버가 전 세계에 제공되기 전에 가동 및 실행 중인지 확인하는 데 도움이 됩니다.
  • an innovative mechanism to set a maximum idle time and duration on cookies ensures that stickiness can be smoothly stopped on devices which are never closed (smartphones, TVs, home appliances) without having to store them on persistent storage;
    쿠키의 최대 유휴 시간 및 지속 시간을 설정하는 혁신적인 메커니즘은 영구 저장소에 저장하지 않고도 닫히지 않는 장치(스마트폰, TV, 가전 제품)에서 고정성를 원활하게 중지할 수 있도록 합니다.
  • multiple server entries may share the same stickiness keys so that stickiness is not lost in multi-path environments when one path goes down; 여러 서버 항목이 동일한 고정 키를 공유할 수 있으므로 한 경로가 다운될 때 다중 경로 환경에서 고정이 손실되지 않습니다.
  • soft-stop ensures that only users with stickiness information will continue to reach the server they've been assigned to but no new users will go there.
    soft-stop은 고정 정보가 있는 사용자만 할당된 서버에 계속 도달하지만 새로운 사용자는 거기에 가지 않도록 합니다.

3.3.7. Basic features : Logging 로깅

Logging is an extremely important feature for a load balancer, first because a load balancer is often wrongly accused of causing the problems it reveals, and second because it is placed at a critical point in an infrastructure where all normal and abnormal activity needs to be analyzed and correlated with other components.
로깅은 로드 밸런서에서 매우 중요한 기능입니다. 첫째는 로드 밸런서가 종종 문제를 일으키는 것으로 잘못 비난받기 때문이고, 둘째는 모든 정상 및 비정상 활동을 분석해야 하는 인프라의 중요한 지점에 위치하기 때문입니다. 다른 구성 요소와 상관 관계가 있습니다.

HAProxy provides very detailed logs, with millisecond accuracy and the exact connection accept time that can be searched in firewalls logs (e.g. for NAT correlation). By default, TCP and HTTP logs are quite detailed and contain everything needed for troubleshooting, such as source IP address and port, frontend, backend, server, timers (request receipt duration, queue duration, connection setup time, response headers time, data transfer time), global process state, connection counts, queue status, retries count, detailed stickiness actions and disconnect reasons, header captures with a safe output encoding. It is then possible to extend or replace this format to include any sampled data, variables, captures, resulting in very detailed information. For example it is possible to log the number of cumulative requests or number of different URLs visited by a client.

HAProxy는 방화벽 로그(예: NAT 상관 관계)에서 검색할 수 있는 밀리초 정확도와 정확한 연결 수락 시간으로 매우 상세한 로그를 제공합니다. 기본적으로 TCP 및 HTTP 로그는 매우 상세하며 소스 IP 주소 및 포트, 프런트엔드, 백엔드, 서버, 타이머(요청 수신 기간, 대기열 기간, 연결 설정 시간, 응답 헤더 시간, 데이터 전송 시간 등), 전역 프로세스 상태, 연결 수, 대기열 상태, 재시도 횟수, 자세한 고정 작업 및 연결 끊기 이유, 안전한 출력 인코딩으로 헤더 캡처 같은 문제 해결에 필요한 모든 것이 포함되어 있습니다. 그런 다음 이 형식을 확장하거나 대체하여 샘플링된 데이터, 변수, 캡처를 포함하여 매우 상세한 정보를 얻을 수 있습니다. 예를 들어 누적 요청 수 또는 클라이언트가 방문한 다른 URL 수를 기록할 수 있습니다.

The log level may be adjusted per request using standard ACLs, so it is possible to automatically silent some logs considered as pollution and instead raise warnings when some abnormal behavior happen for a small part of the traffic (e.g. too many URLs or HTTP errors for a source address). Administrative logs are also emitted with their own levels to inform about the loss or recovery of a server for example.
로그 수준은 표준 ACL을 사용하여 요청별로 조정할 수 있으므로 오염으로 간주되는 일부 로그를 자동으로 잠그고 대신 트래픽의 작은 부분에 대해 비정상적인 동작 (예: 너무 많은 URL 또는 HTTP 오류 소스 주소)이 발생할 때 경고를 표시할 수 있습니다. 예를 들어 서버의 손실 또는 복구에 대해 알리기 위해 관리 로그도 자체 수준으로 내보내집니다.

Each frontend and backend may use multiple independent log outputs, which eases multi-tenancy. Logs are preferably sent over UDP, maybe JSON-encoded, and are truncated after a configurable line length in order to guarantee delivery. But it is also possible to send them to stdout/stderr or any file descriptor, as well as to a ring buffer that a client can subscribe to in order to retrieve them.
각 프론트엔드와 백엔드는 다중 테넌시를 용이하게 하는 여러 개의 독립적인 로그 출력을 사용할 수 있습니다. 로그는 가급적 JSON으로 인코딩된 UDP를 통해 전송되며 전달을 보장하기 위해 구성 가능한 줄 길이 후에 잘립니다. 그러나 stdout/stderr 또는 모든 파일 디스크립터와 클라이언트가 검색하기 위해 구독할 수 있는 링 버퍼로 보낼 수도 있습니다.

Multi-tenancy : 사용자들이 웹을 통해 단일 데이터베이스 안의 정보를 관리하고 공유할 수 있게 해주는 기술을 말한다.
Red Hat: What is multitenancy?

3.3.8. Basic features : Statistics 통계

HAProxy provides a web-based statistics reporting interface with authentication, security levels and scopes. It is thus possible to provide each hosted customer with his own page showing only his own instances. This page can be located in a hidden URL part of the regular web site so that no new port needs to be opened. This page may also report the availability of other HAProxy nodes so that it is easy to spot if everything works as expected at a glance. The view is synthetic with a lot of details accessible (such as error causes, last access and last change duration, etc), which are also accessible as a CSV table that other tools may import to draw graphs. The page may self-refresh to be used as a monitoring page on a large display. In administration mode, the page also allows to change server state to ease maintenance operations.

HAProxy는 인증, 보안 수준 및 범위가 포함된 웹 기반 통계 보고 인터페이스를 제공합니다. 따라서 호스팅된 각 고객에게 자신의 인스턴스만 표시하는 자체 페이지를 제공할 수 있습니다. 이 페이지는 일반 웹 사이트의 숨겨진 URL 부분에 위치할 수 있으므로 새 포트를 열 필요가 없습니다. 이 페이지는 다른 HAProxy 노드의 가용성을 보고하여 모든 것이 예상대로 작동하는지 한 눈에 쉽게 파악할 수 있습니다. 보기는 액세스 가능한 많은 세부 정보(예: 오류 원인, 마지막 액세스 및 마지막 변경 기간 등)가 있는 종합적이며 다른 도구에서 그래프를 그리기 위해 가져올 수 있는 CSV 테이블로도 액세스할 수 있습니다. 페이지는 대형 디스플레이에서 모니터링 페이지로 사용하기 위해 자동 새로고침될 수 있습니다. 관리 모드에서 페이지에서는 유지 관리 작업을 쉽게 하기 위해 서버 상태를 변경할 수도 있습니다.

A Prometheus exporter is also provided so that the statistics can be consumed in a different format depending on the deployment.
또한 배포에 따라 다른 형식으로 통계를 사용할 수 있도록 프로메테우스 내보내기도 제공됩니다.

프로메테우스(Prometheus) 모니터링 도구

3.4. Standard features: HAProxy만의 특징

In this section, some features that are very commonly used in HAProxy but are not necessarily present on other load balancers are enumerated.
이 섹션에서는 HAProxy에서 매우 일반적으로 사용되지만 다른 로드 밸런서에는 존재하지는 않는 몇 가지 기능을 열거합니다.

3.4.1. Standard features : Sampling and converting information 정보 샘플링 및 변환

HAProxy supports information sampling using a wide set of "sample fetch functions". The principle is to extract pieces of information known as samples, for immediate use. This is used for stickiness, to build conditions, to produce information in logs or to enrich HTTP headers.
HAProxy는 다양한 "샘플 가져오기 기능"을 사용하여 정보 샘플링을 지원합니다. 원칙은 즉시 사용하기 위해 샘플로 알려진 정보를 추출하는 것입니다. 이것은 고정성, 조건 구축, 로그에 정보 생성 또는 HTTP 헤더 강화에 사용됩니다.

Samples can be fetched from various sources :
다양한 소스에서 샘플을 가져올 수 있습니다.

  • constants : integers, strings, IP addresses, binary blocks;
    상수: 정수, 문자열, IP 주소, 이진 블록;
  • the process : date, environment variables, server/frontend/backend/process state, byte/connection counts/rates, queue length, random generator, ...
    프로세스: 날짜, 환경 변수, 서버/프론트엔드/백엔드/프로세스 상태, 바이트/연결 수/비율, 대기열 길이, 임의 생성기, ...
  • variables : per-session, per-request, per-response variables;
    변수: 세션당, 요청당, 응답당 변수;
  • the client connection : source and destination addresses and ports, and all related statistics counters;
    클라이언트 연결: 소스 및 대상 주소와 포트, 모든 관련 통계 카운터
  • the SSL client session : protocol, version, algorithm, cipher, key size, session ID, all client and server certificate fields, certificate serial, SNI, ALPN, NPN, client support for certain extensions;
    SSL 클라이언트 세션: 프로토콜, 버전, 알고리즘, 암호, 키 크기, 세션 ID, 모든 클라이언트 및 서버 인증서 필드, 인증서 직렬, SNI, ALPN, NPN, 특정 확장에 대한 클라이언트 지원
  • request and response buffers contents : arbitrary payload at offset/length, data length, RDP cookie, decoding of SSL hello type, decoding of TLS SNI;
    요청 및 응답 버퍼 내용: 오프셋/길이의 임의 페이로드, 데이터 길이, RDP 쿠키, SSL Hello 유형 디코딩, TLS SNI 디코딩
    RDP((Remode Desktop Protocal)
    SSL(Secure Sockets Layer, 보안 소켓 계층): 웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술입니다.
    TLS(Transport Layer Security, 전송 계층 보안): SSL의 향상된, 더욱 안전한 버전입니다.
    SNI(Server Name Indication): TLS의 확장
  • HTTP (request and response) : method, URI, path, query string arguments, status code, headers values, positional header value, cookies, captures, authentication, body elements;
    HTTP(요청 및 응답): 메서드, URI, 경로, 쿼리 문자열 인수, 상태 코드, 헤더 값, 위치 헤더 값, 쿠키, 캡처, 인증, 본문 요소

A sample may then pass through a number of operators known as "converters" to experience some transformation. A converter consumes a sample and produces a new one, possibly of a completely different type. For example, a converter may be used to return only the integer length of the input string, or could turn a string to upper case. Any arbitrary number of converters may be applied in series to a sample before final use. Among all available sample converters, the following ones are the most commonly used :
그런 다음 샘플은 "변환기(converters)"로 알려진 여러 연산자를 통과하여 일부 변환을 경험할 수 있습니다. 변환기는 샘플을 사용하고 완전히 다른 유형의 새 샘플을 생성합니다. 예를 들어 변환기를 사용하여 입력 문자열의 정수 길이만 반환하거나 문자열을 대문자로 바꿀 수 있습니다. 임의의 수의 변환기를 최종 사용 전에 샘플에 직렬로 적용할 수 있습니다. 사용 가능한 모든 샘플 변환기 중에서 다음이 가장 일반적으로 사용됩니다.

  • arithmetic and logic operators : they make it possible to perform advanced computation on input data, such as computing ratios, percentages or simply converting from one unit to another one;
    산술 및 논리 연산자: 계산 비율, 백분율 또는 단순히 한 단위에서 다른 단위로 변환과 같은 입력 데이터에 대한 고급 계산을 수행할 수 있습니다.
  • IP address masks are useful when some addresses need to be grouped by larger networks;
    IP 주소 마스크는 일부 주소를 더 큰 네트워크로 그룹화해야 할 때 유용합니다.
  • data representation : URL-decode, base64, hex, JSON strings, hashing;
    데이터 표현: URL-디코드, base64, 16진수, JSON 문자열, 해싱;
  • string conversion : extract substrings at fixed positions, fixed length, extract specific fields around certain delimiters, extract certain words, change case, apply regex-based substitution;
    문자열 변환: 고정 위치에서 부분 문자열 추출, 고정 길이, 특정 구분 기호 주변의 특정 필드 추출, 특정 단어 추출, 대소문자 변경, 정규식 기반 대체 적용
  • date conversion : convert to HTTP date format, convert local to UTC and conversely, add or remove offset;
    날짜 변환: HTTP 날짜 형식으로 변환하고 로컬을 UTC로 변환하고 반대로 오프셋을 추가하거나 제거합니다.
  • lookup an entry in a stick table to find statistics or assigned server;
    통계 또는 할당된 서버를 찾기 위해 고정 테이블에서 항목을 조회합니다.
  • map-based key-to-value conversion from a file (mostly used for geolocation).
    파일에서 맵 기반 키-값 변환(주로 지리적 위치에 사용됨).

3.4.2. Standard features : Maps (key-value)

Maps are a powerful type of converter consisting in loading a two-columns file into memory at boot time, then looking up each input sample from the first column and either returning the corresponding pattern on the second column if the entry was found, or returning a default value. The output information also being a sample, it can in turn experience other transformations including other map lookups. Maps are most commonly used to translate the client's IP address to an AS number or country code since they support a longest match for network addresses but they can be used for various other purposes.

맵은 부팅 시 메모리에 2열 파일을 로드한 다음 첫 번째 열에서 각 입력 샘플을 찾고 항목이 발견되면 두 번째 열에서 해당 패턴을 반환하거나 기본값을 반환합니다. 출력 정보도 샘플이므로 다른 맵 조회를 포함한 다른 변환을 경험할 수 있습니다. 맵은 네트워크 주소에 대해 가장 긴 일치 항목을 지원하기 때문에 클라이언트의 IP 주소를 망식별(AS) 번호 또는 국가 코드로 변환하는 데 가장 일반적으로 사용되지만 다양한 다른 목적으로 사용될 수 있습니다.
망식별번호(Autonomous System 번호)
한국인터넷정보센터: AS번호 사용자 현황

Part of their strength comes from being updatable on the fly either from the CLI or from certain actions using other samples, making them capable of storing and retrieving information between subsequent accesses. Another strength comes from the binary tree based indexation which makes them extremely fast even when they contain hundreds of thousands of entries, making geolocation very cheap and easy to set up.

장점 중 일부는 CLI에서 또는 다른 샘플을 사용하는 특정 작업에서 즉석에서 업데이트할 수 있기 때문에 후속 액세스 간에 정보를 저장하고 검색할 수 있습니다. 또 다른 강점은 수십만 개의 항목이 포함된 경우에도 매우 빠르게 만드는 이진 트리 기반 인덱싱으로 인해 위치 정보를 매우 저렴하고 쉽게 설정할 수 있습니다.

3.4.3. Standard features : ACLs and conditions ACL 및 조건

Most operations in HAProxy can be made conditional. Conditions are built by combining multiple ACLs using logic operators (AND, OR, NOT). Each ACL is a series of tests based on the following elements :
HAProxy의 대부분의 작업은 조건부로 만들 수 있습니다. 조건은 논리 연산자(AND, OR, NOT)를 사용하여 여러 ACL을 결합하여 작성됩니다. 각 ACL은 다음 요소를 기반으로 하는 일련의 테스트입니다.
접근 제어 목록(access control list, ACL)

  • a sample fetch method to retrieve the element to test ;
    테스트할 요소를 검색하기 위한 샘플 가져오기 방법
  • an optional series of converters to transform the element ;
    요소를 변환하는 선택적 일련의 변환기
  • a list of patterns to match against ;
    일치시킬 패턴 목록;
  • a matching method to indicate how to compare the patterns with the sample
    패턴과 샘플을 비교하는 방법을 나타내는 매칭 방법

For example, the sample may be taken from the HTTP "Host" header, it could then be converted to lower case, then matched against a number of regex patterns using the regex matching method.

예를 들어, HTTP "호스트" 헤더에서 샘플을 가져온 다음 소문자로 변환한 다음 정규식 일치 방법을 사용하여 여러 정규식 패턴과 일치시킬 수 있습니다.

Technically, ACLs are built on the same core as the maps, they share the exact same internal structure, pattern matching methods and performance. The only real difference is that instead of returning a sample, they only return "found" or or "not found". In terms of usage, ACL patterns may be declared inline in the configuration file and do not require their own file. ACLs may be named for ease of use or to make configurations understandable. A named ACL may be declared multiple times and it will evaluate all definitions in turn until one matches.

기술적으로 ACL은 맵과 동일한 코어에 구축되며 정확히 동일한 내부 구조, 패턴 일치 방법 및 성능을 공유합니다. 유일한 실제 차이점은 샘플을 반환하는 대신 "찾음" 또는 "찾을 수 없음"만 반환한다는 것입니다. 사용 측면에서 ACL 패턴은 구성 파일에서 인라인으로 선언될 수 있으며 자체 파일이 필요하지 않습니다. ACL은 사용 편의성을 위해 또는 구성을 이해하기 쉽게 이름을 지정할 수 있습니다. 명명된 ACL은 여러 번 선언될 수 있으며 하나가 일치할 때까지 모든 정의를 차례로 평가합니다.

About 13 different pattern matching methods are provided, among which IP address mask, integer ranges, substrings, regex. They work like functions, and just like with any programming language, only what is needed is evaluated, so when a condition involving an OR is already true, next ones are not evaluated, and similarly when a condition involving an AND is already false, the rest of the condition is not evaluated.

IP 주소 마스크, 정수 범위, 하위 문자열, 정규식 등 약 13가지 패턴 일치 방법이 제공됩니다. 그것들은 함수처럼 작동하고 다른 프로그래밍 언어와 마찬가지로 필요한 것만 평가됩니다. 따라서 OR을 포함하는 조건이 이미 참이면 다음 조건은 평가되지 않으며, AND를 포함하는 조건이 이미 거짓이면 마찬가지로, 나머지 조건은 평가되지 않습니다.

There is no practical limit to the number of declared ACLs, and a handful of commonly used ones are provided. However experience has shown that setups using a lot of named ACLs are quite hard to troubleshoot and that sometimes using anonymous ACLs inline is easier as it requires less references out of the scope being analyzed.

선언된 ACL의 수에는 실질적인 제한이 없으며 일반적으로 사용되는 소수의 ACL이 제공됩니다. 그러나 경험에 따르면 명명된 ACL을 많이 사용하는 설정은 문제를 해결하기가 상당히 어렵고 때로는 익명 ACL을 인라인으로 사용하는 것이 분석 대상 범위를 벗어나는 참조가 덜 필요하기 때문에 더 쉽습니다.

3.4.4. Standard features : Content switching 콘텐츠 전환

HAProxy implements a mechanism known as content-based switching. The principle is that a connection or request arrives on a frontend, then the information carried with this request or connection are processed, and at this point it is possible to write ACLs-based conditions making use of these information to decide what backend will process the request. Thus the traffic is directed to one backend or another based on the request's contents. The most common example consists in using the Host header and/or elements from the path (sub-directories or file-name extensions) to decide whether an HTTP request targets a static object or the application, and to route static objects traffic to a backend made of fast and light servers, and all the remaining traffic to a more complex application server, thus constituting a fine-grained virtual hosting solution. This is quite convenient to make multiple technologies coexist as a more global solution.

HAProxy는 콘텐츠 기반 전환이라는 메커니즘을 구현합니다. 원칙은 연결 또는 요청이 프론트엔드에 도착한 다음 이 요청 또는 연결과 함께 전달되는 정보가 처리되고, 이 시점에서 이러한 정보를 사용하여 요청을 처리할 백엔드를 결정하는 ACL 기반 조건을 작성할 수 있습니다. 따라서 트래픽은 요청의 내용을 기반으로 한 백엔드 또는 다른 백엔드로 전달됩니다.
가장 일반적인 예는 HTTP 요청이 정적 개체 또는 응용 프로그램을 대상으로 하는지 여부를 결정하고 정적 개체 트래픽을 백엔드로 라우팅하기 위해 경로(하위 디렉터리 또는 파일 이름 확장명)의 호스트 헤더 및 요소를 사용하는 것입니다. 빠르고 가벼운 서버로 구성되고 나머지 모든 트래픽은 더 복잡한 응용 프로그램 서버로 보내져 세분화된 가상 호스팅 솔루션을 구성합니다. 이는 보다 글로벌한 솔루션으로 여러 기술을 공존시킬 수 있어 매우 편리합니다.

Content switching 콘텐츠 전환
1) 고객 또는 파트너의 IP 범위에 있는 사용자가 특수 웹 포털에 액세스할 수 있도록 허용할 수 있습니다.
2) 특정 지역과 관련된 콘텐츠를 해당 지역의 사용자에게 제공할 수 있습니다.
3) 해당 언어를 사용하는 사용자에게 다른 언어로 콘텐츠를 제공할 수 있습니다.
4) 스마트폰과 같은 특정 장치에 맞는 콘텐츠를 해당 장치를 사용하는 사람들에게 제공할 수 있습니다.

Another use case of content-switching consists in using different load balancing algorithms depending on various criteria. A cache may use a URI hash while an application would use round-robin.
콘텐츠 전환의 또 다른 사용 사례는 다양한 기준에 따라 다양한 로드 밸런싱 알고리즘을 사용하는 것입니다. 캐시는 URI 해시를 사용하는 반면 애플리케이션은 라운드 로빈을 사용할 수 있습니다.

Last but not least, it allows multiple customers to use a small share of a common resource by enforcing per-backend (thus per-customer connection limits).
마지막으로 중요한 것은 백엔드당(따라서 고객당 연결 제한)을 적용하여 여러 고객이 공통 리소스의 작은 공유를 사용할 수 있다는 것입니다.

Content switching rules scale very well, though their performance may depend on the number and complexity of the ACLs in use. But it is also possible to write dynamic content switching rules where a sample value directly turns into a backend name and without making use of ACLs at all. Such configurations have been reported to work fine at least with 300000 backends in production.

콘텐츠 전환 규칙은 사용 중인 ACL의 수와 복잡성에 따라 성능이 달라질 수 있지만 확장성이 매우 뛰어납니다. 그러나 샘플 값이 ACL을 전혀 사용하지 않고 백엔드 이름으로 직접 바뀌는 동적 콘텐츠 전환 규칙을 작성하는 것도 가능합니다. 이러한 구성은 프로덕션 환경에서 최소 300,000개의 백엔드에서 제대로 작동하는 것으로 보고되었습니다.

3.4.5. Standard features : Stick-tables 고정 테이블

Stick-tables are commonly used to store stickiness information, that is, to keep a reference to the server a certain visitor was directed to. The key is then the identifier associated with the visitor (its source address, the SSL ID of the connection, an HTTP or RDP cookie, the customer number extracted from the URL or from the payload, ...) and the stored value is then the server's identifier.

고정 테이블은 일반적으로 고정 정보를 저장하는 데 사용됩니다. 즉, 특정 방문자가 연결된 서버에 대한 참조를 유지하는 데 사용됩니다. 키는 방문자와 관련된 식별자(소스 주소, 연결의 SSL ID, HTTP 또는 RDP 쿠키, URL 또는 페이로드에서 추출한 고객 번호 등)이고 저장된 값은 서버의 식별자입니다.

Stick tables may use 3 different types of samples for their keys : integers, strings and addresses. Only one stick-table may be referenced in a proxy, and it is designated everywhere with the proxy name. Up to 8 keys may be tracked in parallel. The server identifier is committed during request or response processing once both the key and the server are known.

고정 테이블은 키에 대해 정수, 문자열 및 주소의 3가지 다른 유형의 샘플을 사용할 수 있습니다. 하나의 고정 테이블만 프록시에서 참조할 수 있으며 프록시 이름으로 모든 곳에서 지정됩니다. 최대 8개의 키를 병렬로 추적할 수 있습니다. 서버 식별자는 키와 서버가 모두 알려지면 요청 또는 응답 처리 중에 커밋됩니다.

Stick-table contents may be replicated in active-active mode with other HAProxy nodes known as "peers" as well as with the new process during a reload operation so that all load balancing nodes share the same information and take the same routing decision if client's requests are spread over multiple nodes.

모든 로드 밸런싱 노드가 동일한 정보를 공유하고 클라이언트가 동일한 라우팅 결정을 내릴 수 있도록 고정 테이블 내용은 "피어"로 알려진 다른 HAProxy 노드와 새로운 프로세스와 함께 활성-활성 모드로 복제될 수 있습니다. 요청은 여러 노드에 분산됩니다.
Peer-to-Peer(P2P) 네트워크

Since stick-tables are indexed on what allows to recognize a client, they are often also used to store extra information such as per-client statistics. The extra statistics take some extra space and need to be explicitly declared. The type of statistics that may be stored includes the input and output bandwidth, the number of concurrent connections, the connection rate and count over a period, the amount and frequency of errors, some specific tags and counters, etc. In order to support keeping such information without being forced to stick to a given server, a special "tracking" feature is implemented and allows to track up to 3 simultaneous keys from different tables at the same time regardless of stickiness rules. Each stored statistics may be searched, dumped and cleared from the CLI and adds to the live troubleshooting capabilities.

고정 테이블은 클라이언트를 인식할 수 있는 항목에 대해 인덱싱되므로 클라이언트별 통계와 같은 추가 정보를 저장하는 데에도 자주 사용됩니다. 추가 통계는 약간의 추가 공간을 차지하므로 명시적으로 선언해야 합니다. 저장될 수 있는 통계 유형에는 입력 및 출력 대역폭, 동시 연결 수, 기간 동안의 연결 속도 및 개수, 오류 양 및 빈도, 일부 특정 태그 및 카운터 등이 포함됩니다. 주어진 서버에 강제로 고정되지 않고 이러한 정보를 유지하는 것을 지원하기 위해 특별한 "추적" 기능이 구현되고 고정 규칙에 관계없이 동시에 다른 테이블에서 최대 3개의 동시 키를 추적할 수 있습니다. 저장된 각 통계는 CLI에서 검색, 덤프 및 삭제할 수 있으며 실시간 문제 해결 기능에 추가할 수 있습니다.

While this mechanism can be used to surclass a returning visitor or to adjust the delivered quality of service depending on good or bad behavior, it is mostly used to fight against service abuse and more generally DDoS as it allows to build complex models to detect certain bad behaviors at a high processing speed.

이 메커니즘은 재방문자를 분류하거나 좋은 행동 또는 나쁜 행동에 따라 제공되는 서비스 품질을 조정하는 데 사용할 수 있습니다. 높은 처리 속도로 특정 불량 행위를 감지하는 복잡한 모델을 구축할 수 있으므로 주로 서비스 남용이나 보다 일반적으로 DDoS에 맞서 싸우는 데 사용됩니다.

3.4.6. Standard features : Formatted strings 형식이 지정된 문자열

There are many places where HAProxy needs to manipulate character strings, such as logs, redirects, header additions, and so on. In order to provide the greatest flexibility, the notion of Formatted strings was introduced, initially for logging purposes, which explains why it's still called "log-format". These strings contain escape characters allowing to introduce various dynamic data including variables and sample fetch expressions into strings, and even to adjust the encoding while the result is being turned into a string (for example, adding quotes). This provides a powerful way to build header contents, to build response data or even response templates, or to customize log lines. Additionally, in order to remain simple to build most common strings, about 50 special tags are provided as shortcuts for information commonly used in logs.

HAProxy는 로그, 재지정(redirect), 헤더 추가 등과 같이 많은 곳에서 문자열을 조작해야 합니다. 최고의 유연성을 제공하기 위해 처음에는 로깅 목적으로 형식화된 문자열이라는 개념이 도입되었으며, 이것이 왜 여전히 "로그 형식"이라고 불리는지 설명합니다. 이러한 문자열에는 변수 및 샘플 가져오기 표현식을 포함한 다양한 동적 데이터를 문자열에 도입할 수 있는 이스케이프 문자가 포함되어 있으며 결과가 문자열로 변환되는 동안 인코딩을 조정할 수도 있습니다(예: 따옴표 추가). 이것은 헤더 내용을 작성하거나 응답 데이터 또는 응답 템플릿을 작성하거나 로그 라인을 사용자 정의하는 강력한 방법을 제공합니다. 또한 가장 일반적인 문자열을 간단하게 작성할 수 있도록 로그에서 일반적으로 사용되는 정보에 대한 바로 가기로 약 50개의 특수 태그가 제공됩니다.
재지정(redirect)

3.4.7. Standard features : HTTP rewriting and redirection HTTP 재작성 및 재지정

Installing a load balancer in front of an application that was never designed for this can be a challenging task without the proper tools. One of the most commonly requested operation in this case is to adjust requests and response headers to make the load balancer appear as the origin server and to fix hard coded information. This comes with changing the path in requests (which is strongly advised against), modifying Host header field, modifying the Location response header field for redirects, modifying the path and domain attribute for cookies, and so on. It also happens that a number of servers are somewhat verbose and tend to leak too much information in the response, making them more vulnerable to targeted attacks. While it's theoretically not the role of a load balancer to clean this up, in practice it's located at the best place in the infrastructure to guarantee that everything is cleaned up.

이를 위해 설계되지 않은 애플리케이션 앞에 로드 밸런서를 설치하는 것은 적절한 도구 없이는 어려운 작업이 될 수 있습니다. 이 경우 가장 일반적으로 요청되는 작업 중 하나는 요청 및 응답 헤더를 조정하여 로드 밸런서를 원본 서버로 표시하고 하드 코딩된 정보를 수정하는 것입니다. 이것은 요청의 경로 변경(강력히 권장되지 않음), 호스트 헤더 필드 수정, 재지정에 대한 위치 응답 헤더 필드 수정, 쿠키의 경로 및 도메인 속성 수정 등과 함께 제공됩니다. 또한 많은 서버가 다소 장황하고 응답에서 너무 많은 정보를 누출하는 경향이 있어 표적 공격에 더 취약합니다. 이론적으로 이를 정리하는 것이 로드 밸런서의 역할은 아니지만 실제로는 모든 것이 정리되도록 보장하기 위해 인프라에서 가장 좋은 위치에 있습니다.

Similarly, sometimes the load balancer will have to intercept some requests and respond with a redirect to a new target URL. While some people tend to confuse redirects and rewriting, these are two completely different concepts, since the rewriting makes the client and the server see different things (and disagree on the location of the page being visited) while redirects ask the client to visit the new URL so that it sees the same location as the server.

마찬가지로 로드 밸런서가 일부 요청을 가로채고 새 대상 URL로 재지정하여 응답해야 하는 경우가 있습니다. 일부 사람들은 재지정과 재작성을 혼동하는 경향이 있지만, 재작성은 클라이언트와 서버가 다른 것을 보게 하는(방문하는 페이지의 위치에 동의하지 않음) 반면, 재지정은 클라이언트가 서버와 동일한 위치를 볼 수 있도록 클라이언트에 새 URL을 방문하도록 요청하기 때문에 완전히 다른 개념입니다.

In order to do this, HAProxy supports various possibilities for rewriting and redirects, among which :
이를 위해 HAProxy는 재작성과 재지정을 위한 다양한 가능성을 지원합니다.

  • regex-based URL and header rewriting in requests and responses. Regex are the most commonly used tool to modify header values since they're easy to manipulate and well understood;
    요청과 응답에서 정규식 기반 URL 및 헤더 재작성.
    정규식(regex)은 조작하기 쉽고 잘 이해되기 때문에 헤더 값을 수정하는 데 가장 일반적으로 사용되는 도구입니다.
  • headers may also be appended, deleted or replaced based on formatted strings so that it is possible to pass information there (e.g. client side TLS algorithm and cipher);
    헤더는 정보를 전달할 수 있도록 형식화된 문자열을 기반으로 추가, 삭제 또는 대체될 수도 있습니다(예: 클라이언트 측 TLS 알고리즘 및 암호).
  • HTTP redirects can use any 3xx code to a relative, absolute, or completely dynamic (formatted string) URI;
    HTTP 재지정은 상대, 절대 또는 완전히 동적(형식화된 문자열) URI에 대한 3xx 코드를 사용할 수 있습니다.
  • HTTP redirects also support some extra options such as setting or clearing a specific cookie, dropping the query string, appending a slash if missing, and so on;
    HTTP 재지정은 특정 쿠키 설정 또는 지우기, 쿼리 문자열 삭제, 누락된 경우 슬래시 추가 등과 같은 몇 가지 추가 옵션도 지원합니다.
  • a powerful "return" directive allows to customize every part of a response like status, headers, body using dynamic contents or even template files.
    강력한 "반환" 지시문을 사용하면 동적 콘텐츠 또는 템플릿 파일을 사용하여 상태, 헤더, 본문과 같은 응답의 모든 부분을 사용자 지정할 수 있습니다.
  • all operations support ACL-based conditions;
    모든 작업은 ACL 기반 조건을 지원합니다.

3.4.8. Standard features : Server protection 서버 보호

HAProxy does a lot to maximize service availability, and for this it takes large efforts to protect servers against overloading and attacks. The first and most important point is that only complete and valid requests are forwarded to the servers. The initial reason is that HAProxy needs to find the protocol elements it needs to stay synchronized with the byte stream, and the second reason is that until the request is complete, there is no way to know if some elements will change its semantics. The direct benefit from this is that servers are not exposed to invalid or incomplete requests. This is a very effective protection against slowloris attacks, which have almost no impact on HAProxy.

HAProxy는 서비스 가용성을 극대화하기 위해 많은 노력을 기울이고 있으며 이를 위해서는 과부하 및 공격으로부터 서버를 보호하기 위해 많은 노력이 필요합니다. 첫 번째이자 가장 중요한 점은 완전하고 유효한 요청만 서버로 전달된다는 것입니다. 첫 번째 이유는 HAProxy가 바이트 스트림과 동기화된 상태를 유지하는 데 필요한 프로토콜 요소를 찾아야 하고, 두 번째 이유는 요청이 완료될 때까지 일부 요소가 의미 체계를 변경할지 여부를 알 수 있는 방법이 없기 때문입니다. 이것의 직접적인 이점은 서버가 유효하지 않거나 불완전한 요청에 노출되지 않는다는 것입니다. 이것은 HAProxy에 거의 영향을 미치지 않는 slowloris 공격에 대한 매우 효과적인 보호입니다.

Slowloris (Slow HTTP Header DoS) 공격 : HTTP Header 정보를 비정상적으로 조작하여 웹서버가 온전한 Header정보가 올때 까지 기다리도록 한다. 서버가 연결 상태를 유지할 수 있는 가용자원은 한계가 있으므로 임계치를 넘어가면 다른 정상적인 접근을 거부하게 된다.

Another important point is that HAProxy contains buffers to store requests and responses, and that by only sending a request to a server when it's complete and by reading the whole response very quickly from the local network, the server side connection is used for a very short time and this preserves server resources as much as possible.

또 다른 중요한 점은 HAProxy에는 요청과 응답을 저장하는 버퍼가 포함되어 있으며, 요청이 완료되었을 때만 서버에 요청을 보내고, 로컬 네트워크에서 전체 응답을 매우 빠르게 읽어 서버 측 연결이 매우 짧은 시간 동안 사용된다는 것입니다. 시간을 절약하고 서버 리소스를 최대한 보존합니다.

A direct extension to this is that HAProxy can artificially limit the number of concurrent connections or outstanding requests to a server, which guarantees that the server will never be overloaded even if it continuously runs at 100% of its capacity during traffic spikes. All excess requests will simply be queued to be processed when one slot is released. In the end, this huge resource savings most often ensures so much better server response times that it ends up actually being faster than by overloading the server. Queued requests may be redispatched to other servers, or even aborted in queue when the client aborts, which also protects the servers against the "reload effect", where each click on "reload" by a visitor on a slow-loading page usually induces a new request and maintains the server in an overloaded state.

이에 대한 직접적인 확장은 HAProxy가 서버에 대한 동시 연결 수 또는 미해결 요청 수를 인위적으로 제한할 수 있다는 것입니다. 이를 통해 트래픽 급증 동안 용량의 100%에서 지속적으로 실행되더라도 서버에 과부하가 걸리지 않도록 보장합니다. 모든 초과 요청은 하나의 슬롯이 해제될 때 처리되도록 대기열에 추가됩니다. 결국 이 엄청난 리소스 절약은 서버에 과부하를 주는 것보다 실제로 더 빨라지는 결과를 가져오는 훨씬 더 나은 서버 응답 시간을 보장합니다. 대기 중인 요청은 다른 서버로 다시 전달되거나 클라이언트가 중단될 때 대기열에서 중단될 수도 있습니다. 이는 또한 느린 로딩 페이지에서 방문자가 "새로고침"를 클릭할 때마다 일반적으로 유도되는 "새로고침 효과"로부터 서버를 보호합니다. 새로운 요청을 처리하고 서버를 과부하 상태로 유지합니다.

The slow-start mechanism also protects restarting servers against high traffic levels while they're still finalizing their startup or compiling some classes.
느린 시작(slow-start) 메커니즘은 또한 시작을 완료하거나 일부 클래스를 컴파일하는 동안 높은 트래픽 수준으로부터 서버를 다시 시작하는 것을 보호합니다.

Regarding the protocol-level protection, it is possible to relax the HTTP parser to accept non standard-compliant but harmless requests or responses and even to fix them. This allows bogus applications to be accessible while a fix is being developed. In parallel, offending messages are completely captured with a detailed report that help developers spot the issue in the application. The most dangerous protocol violations are properly detected and dealt with and fixed. For example malformed requests or responses with two Content-length headers are either fixed if the values are exactly the same, or rejected if they differ, since it becomes a security problem. Protocol inspection is not limited to HTTP, it is also available for other protocols like TLS or RDP.

프로토콜 수준 보호와 관련하여 HTTP 파서를 완화하여 표준을 준수하지 않지만 무해한 요청이나 응답을 수락하고 수정하는 것이 가능합니다. 이렇게 하면 수정 프로그램이 개발되는 동안 가짜 응용 프로그램에 액세스할 수 있습니다. 이와 동시에 개발자가 애플리케이션에서 문제를 발견하는 데 도움이 되는 자세한 보고서와 함께 문제가 되는 메시지를 완전히 캡처합니다. 가장 위험한 프로토콜 위반을 적절히 감지하고 처리하고 수정합니다. 예를 들어, 두 개의 Content-length 헤더가 있는 잘못된 요청이나 응답은 값이 정확히 같으면 수정되거나 다르면 보안 문제가 되기 때문에 거부됩니다. 프로토콜 검사는 HTTP에 국한되지 않고 TLS 또는 RDP와 같은 다른 프로토콜에도 사용할 수 있습니다.

When a protocol violation or attack is detected, there are various options to respond to the user, such as returning the common "HTTP 400 bad request", closing the connection with a TCP reset, or faking an error after a long delay ("tarpit") to confuse the attacker. All of these contribute to protecting the servers by discouraging the offending client from pursuing an attack that becomes very expensive to maintain.

프로토콜 위반 또는 공격이 감지되면, 일반적인 "HTTP 400 잘못된 요청"을 반환하거나, TCP 재설정으로 연결을 닫거나, 오랜 지연("tarpit ") 공격자를 혼란스럽게 합니다. 이 모든 것은 문제가 되는 클라이언트가 유지 관리 비용이 많이 드는 공격을 시도하지 않도록 하여 서버를 보호하는 데 기여합니다.

Tarpit 늪 : 타핏은 들어오는 연결을 의도적으로 지연시키는 컴퓨터 시스템 (일반적으로 서버 )의 서비스입니다 . 이 기술은 컴퓨터 웜에 대한 방어 수단으로 개발되었으며, 시간이 너무 오래 걸리면 스팸이나 광범위한 검색과 같은 네트워크 악용은 효과가 떨어지므로 매력도가 떨어집니다. 이 개념은 동물이 수렁에 빠져 늪처럼 표면 아래로 천천히 가라앉을 수 있는 타르 구덩이와 유사합니다 .

HAProxy also proposes some more advanced options to protect against accidental data leaks and session crossing. Not only it can log suspicious server responses but it will also log and optionally block a response which might affect a given visitors' confidentiality. One such example is a cacheable cookie appearing in a cacheable response and which may result in an intermediary cache to deliver it to another visitor, causing an accidental session sharing.

또한 HAProxy는 우발적인 데이터 누출 및 세션 교차로부터 보호하기 위해 몇 가지 고급 옵션을 제안합니다. 의심스러운 서버 응답을 기록할 수 있을 뿐만 아니라 주어진 방문자의 기밀성에 영향을 줄 수 있는 응답을 기록하고 선택적으로 차단합니다. 그러한 예로는 캐시 가능한 응답에 나타나는 캐시 가능한 쿠키가 있으며 이로 인해 중간 캐시가 다른 방문자에게 전달하여 우발적인 세션 공유를 유발할 수 있습니다.

3.5. Advanced features   고급 기능

3.5.1. Advanced features : Management 관리

HAProxy is designed to remain extremely stable and safe to manage in a regular production environment. It is provided as a single executable file which doesn't require any installation process. Multiple versions can easily coexist, meaning that it's possible (and recommended) to upgrade instances progressively by order of importance instead of migrating all of them at once. Configuration files are easily versioned. Configuration checking is done off-line so it doesn't require to restart a service that will possibly fail. During configuration checks, a number of advanced mistakes may be detected (e.g. a rule hiding another one, or stickiness that will not work) and detailed warnings and configuration hints are proposed to fix them. Backwards configuration file compatibility goes very far away in time, with version 1.5 still fully supporting configurations for versions 1.1 written 13 years before, and 1.6 only dropping support for almost unused, obsolete keywords that can be done differently. The configuration and software upgrade mechanism is smooth and non disruptive in that it allows old and new processes to coexist on the system, each handling its own connections. System status, build options, and library compatibility are reported on startup.

HAProxy는 일반 프로덕션 환경에서 매우 안정적이고 안전하게 관리할 수 있도록 설계되었습니다. 설치 과정이 필요 없는 단일 실행 파일로 제공됩니다. 여러 버전이 쉽게 공존할 수 있습니다. 즉, 인스턴스를 한 번에 모두 마이그레이션하는 대신 중요도에 따라 점진적으로 인스턴스를 업그레이드하는 것이 가능하고 권장됩니다. 구성 파일은 쉽게 버전 관리됩니다. 구성 확인은 오프라인으로 수행되므로 실패할 수 있는 서비스를 다시 시작할 필요가 없습니다. 구성 확인 중에 여러 고급 실수(예: 다른 하나를 숨기는 규칙 또는 작동하지 않는 고정성)가 감지될 수 있으며 이를 수정하기 위해 자세한 경고 및 구성 힌트가 제안됩니다. 버전 1.5는 13년 전에 작성된 버전 1.1에 대한 구성을 여전히 완벽하게 지원하고 1.6은 다르게 수행할 수 있는 거의 사용되지 않고 더 이상 사용되지 않는 키워드에 대한 지원만 중단하면서 이전 구성 파일 호환성은 시간이 지나면서 매우 멀어집니다. 구성 및 소프트웨어 업그레이드 메커니즘은 이전 프로세스와 새 프로세스가 각각 고유한 연결을 처리하는 시스템에 공존할 수 있다는 점에서 원활하고 중단되지 않습니다. 시스템 상태, 빌드 옵션 및 라이브러리 호환성은 시작 시 보고됩니다.

Some advanced features allow an application administrator to smoothly stop a server, detect when there's no activity on it anymore, then take it off-line, stop it, upgrade it and ensure it doesn't take any traffic while being upgraded, then test it again through the normal path without opening it to the public, and all of this without touching HAProxy at all. This ensures that even complicated production operations may be done during opening hours with all technical resources available.

일부 고급 기능을 통해 응용 프로그램 관리자는 서버를 원활하게 중지하고 더 이상 활동이 없을 때 감지한 다음 오프라인으로 전환하고 중지하고 업그레이드하고 업그레이드하는 동안 트래픽을 사용하지 않는지 확인한 다음 테스트할 수 있습니다. 다시 일반 경로를 통해 일반에 공개하지 않고 이 모든 것을 HAProxy를 전혀 건드리지 않고 수행할 수 있습니다. 이렇게 하면 모든 기술 리소스를 사용할 수 있는 상태에서 영업 시간 동안 복잡한 생산 작업도 수행할 수 있습니다.

The process tries to save resources as much as possible, uses memory pools to save on allocation time and limit memory fragmentation, releases payload buffers as soon as their contents are sent, and supports enforcing strong memory limits above which connections have to wait for a buffer to become available instead of allocating more memory. This system helps guarantee memory usage in certain strict environments.

프로세스는 리소스를 최대한 절약하려고 하고, 메모리 풀을 사용하여 할당 시간을 절약하고 메모리 단편화를 제한하고, 콘텐츠가 전송되는 즉시 페이로드 버퍼를 해제하고, 연결이 버퍼를 기다려야 하는 강력한 메모리 제한 적용을 지원합니다. 더 많은 메모리를 할당하는 대신 사용할 수 있게 됩니다. 이 시스템은 특정 엄격한 환경에서 메모리 사용을 보장하는 데 도움이 됩니다.

A command line interface (CLI) is available as a UNIX or TCP socket, to perform a number of operations and to retrieve troubleshooting information. Everything done on this socket doesn't require a configuration change, so it is mostly used for temporary changes. Using this interface it is possible to change a server's address, weight and status, to consult statistics and clear counters, dump and clear stickiness tables, possibly selectively by key criteria, dump and kill client-side and server-side connections, dump captured errors with a detailed analysis of the exact cause and location of the error, dump, add and remove entries from ACLs and maps, update TLS shared secrets, apply connection limits and rate limits on the fly to arbitrary frontends (useful in shared hosting environments), and disable a specific frontend to release a listening port (useful when daytime operations are forbidden and a fix is needed nonetheless). Updating certificates and their configuration on the fly is permitted, as well as enabling and consulting traces of every processing step of the traffic.

CLI(명령줄 인터페이스)는 UNIX 또는 TCP 소켓으로 사용하여 여러 작업을 수행하고 문제 해결 정보를 검색할 수 있습니다. 이 소켓에서 수행되는 모든 작업에는 구성 변경이 필요하지 않으므로 임시 변경에 주로 사용됩니다. 이 인터페이스를 사용하여 서버의 주소, 무게 및 상태를 변경하고, 통계를 참조하고 카운터를 지우고, 고정 테이블을 덤프 및 지우고, 주요 기준에 따라 선택적으로 클라이언트 측 및 서버 측 연결을 덤프 및 종료하고, 캡처된 오류를 덤프할 수 있습니다. 오류의 정확한 원인과 위치에 대한 자세한 분석, ACL 및 맵에서 항목 덤프, 추가 및 제거, TLS 공유 비밀 업데이트, 임의의 프런트엔드에 즉시 연결 제한 및 속도 제한 적용 (공유 호스팅 환경에서 유용), 특정 프런트엔드를 비활성화하여 수신 포트를 해제합니다 (주간 작업이 금지되어 있지만 수정이 필요한 경우에 유용함). 즉석에서 인증서 및 해당 구성을 업데이트하고 트래픽의 모든 처리 단계에 대한 추적을 활성화하고 참조할 수 있습니다.

For environments where SNMP is mandatory, at least two agents exist, one is provided with the HAProxy sources and relies on the Net-SNMP Perl module. Another one is provided with the commercial packages and doesn't require Perl. Both are roughly equivalent in terms of coverage.

SNMP가 필수인 환경의 경우 에이전트가 두 개 이상 존재하며 하나는 HAProxy 소스와 함께 제공되며 Net-SNMP Perl 모듈에 의존합니다. 다른 하나는 상용 패키지와 함께 제공되며 Perl이 필요하지 않습니다. 둘 다 적용 범위 측면에서 거의 동일합니다.

SNMP(Simple Network Management Protocol) : 네트워크 관리를 위해, 관리 정보 및 정보 운반을 위한 프로토콜. UDP/IP 상에서 동작하는 비교적 단순한 형태의 메시지 교환형 네트워크 관리 프로토콜

It is often recommended to install 4 utilities on the machine where HAProxy is deployed :
HAProxy가 배포된 시스템에 4개의 유틸리티를 설치하는 것이 좋습니다.

  • socat (in order to connect to the CLI, though certain forks of netcat can also do it to some extents);
    socat (netcat의 특정 포크도 어느 정도 할 수 있지만 CLI에 연결하기 위해)
    socat 사용하기
    socat 을 사용한 포트 포워딩 Port forwarding
    Netcat (nc) 명령어, 사용 방법, 예제
    넷캣(netcat, nc)의 활용
    nmap.org/ncat 설치 yum install nc
  • halog from the latest HAProxy version : this is the log analysis tool, it parses native TCP and HTTP logs extremely fast (1 to 2 GB per second) and extracts useful information and statistics such as requests per URL, per source address, URLs sorted by response time or error rate, termination codes etc. It was designed to be deployed on the production servers to help troubleshoot live issues so it has to be there ready to be used;
    최신 HAProxy 버전의 halog : 이것은 로그 분석 도구로 기본 TCP 및 HTTP 로그를 매우 빠르게(초당 1~2GB) 구문 분석하고 URL당 요청, 소스 주소당, 정렬된 URL과 같은 유용한 정보 및 통계를 추출합니다. 응답 시간 또는 오류율, 종료 코드 등 실제 문제를 해결하는 데 도움이 되도록 프로덕션 서버에 배포하도록 설계되었으므로 사용할 준비가 되어 있어야 합니다.
    halog(1) - Linux Man Pages
  • tcpdump : this is highly recommended to take the network traces needed to troubleshoot an issue that was made visible in the logs. There is a moment where application and haproxy's analysis will diverge and the network traces are the only way to say who's right and who's wrong. It's also fairly common to detect bugs in network stacks and hypervisors thanks to tcpdump;
    tcpdump : 로그에 표시된 문제를 해결하는 데 필요한 네트워크 추적을 수행하는 것이 좋습니다. 애플리케이션과 haproxy의 분석이 분기되고 네트워크 추적이 누가 옳고 누가 그른지를 말할 수 있는 유일한 방법이 되는 순간이 있습니다. tcpdump 덕분에 네트워크 스택과 하이퍼바이저에서 버그를 감지하는 것도 꽤 일반적입니다.
    tcpdump : tcpdump는 주어진 조건식을 만족하는 네트워크 인터페이스를 거치는 패킷들의 헤더를 출력해 주는 프로그램
  • strace : it is tcpdump's companion. It will report what HAProxy really sees and will help sort out the issues the operating system is responsible for from the ones HAProxy is responsible for. Strace is often requested when a bug in HAProxy is suspected;
    strace : tcpdump의 동반자입니다. HAProxy가 실제로 보는 것을 보고하고 HAProxy가 담당하는 문제에서 운영 체제가 담당하는 문제를 분류하는 데 도움이 됩니다. HAProxy의 버그가 의심될 때 종종 Strace가 요청됩니다.
    리눅스에서 Strace를 이용한 7가지 디버깅 예제

3.5.2. Advanced features : System-specific capabilities 시스템별 기능

Depending on the operating system HAProxy is deployed on, certain extra features may be available or needed. While it is supported on a number of platforms, HAProxy is primarily developed on Linux, which explains why some features are only available on this platform.

HAProxy가 배포된 운영 체제에 따라 특정 추가 기능이 사용 가능하거나 필요할 수 있습니다. 여러 플랫폼에서 지원되지만 HAProxy는 주로 Linux에서 개발되므로 일부 기능을 이 플랫폼에서만 사용할 수 있는 이유가 설명됩니다.

The transparent bind and connect features, the support for binding connections to a specific network interface, as well as the ability to bind multiple processes to the same IP address and ports are only available on Linux and BSD systems, though only Linux performs a kernel-side load balancing of the incoming requests between the available processes.

투명한 바인드 및 연결 기능, 특정 네트워크 인터페이스에 대한 바인딩 연결 지원, 여러 프로세스를 동일한 IP 주소 및 포트에 바인딩하는 기능은 Linux 및 BSD 시스템에서만 사용할 수 있습니다. Linux만이 사용 가능한 프로세스 간에 들어오는 요청의 커널 측 로드 밸런싱을 수행합니다.

On Linux, there are also a number of extra features and optimizations including support for network namespaces (also known as "containers") allowing HAProxy to be a gateway between all containers, the ability to set the MSS, Netfilter marks and IP TOS field on the client side connection, support for TCP FastOpen on the listening side, TCP user timeouts to let the kernel quickly kill connections when it detects the client has disappeared before the configured timeouts, TCP splicing to let the kernel forward data between the two sides of a connections thus avoiding multiple memory copies, the ability to enable the "defer-accept" bind option to only get notified of an incoming connection once data become available in the kernel buffers, and the ability to send the request with the ACK confirming a connect (sometimes called "piggy-back") which is enabled with the "tcp-smart-connect" option. On Linux, HAProxy also takes great care of manipulating the TCP delayed ACKs to save as many packets as possible on the network.

Linux에는 HAProxy가 모든 컨테이너 간의 게이트웨이가 될 수 있도록 하는 네트워크 네임스페이스("컨테이너"라고도 함) 지원, MSS 설정 기능, 클라이언트 측 연결의 Netfilter 표시 및 IP TOS 필드, 수신측에서 TCP FastOpen 지원, 구성된 시간 초과 전에 클라이언트가 사라진 것을 감지하면 커널이 빠르게 연결을 종료할 수 있도록 하는 TCP 사용자 시간 초과, 커널이 연결의 양쪽 사이에서 데이터를 전달할 수 있도록 하는 TCP 스플라이싱으로 여러 메모리 복사를 방지합니다. 커널 버퍼에서 데이터를 사용할 수 있게 되면 들어오는 연결에 대한 알림을 받기 위해 "지연 수락(defer-accept)" 바인드 옵션을 활성화하는 기능, "tcp-smart-connect" 옵션으로 활성화된 연결(때로는 "piggy-back"이라고도 함)을 확인하는 ACK와 함께 요청을 보내는 기능. Linux에서 HAProxy는 네트워크에서 가능한 한 많은 패킷을 저장하기 위해 TCP 지연 ACK 조작을 세심하게 처리합니다.

Some systems have an unreliable clock which jumps back and forth in the past and in the future. This used to happen with some NUMA systems where multiple processors didn't see the exact same time of day, and recently it became more common in virtualized environments where the virtual clock has no relation with the real clock, resulting in huge time jumps (sometimes up to 30 seconds have been observed). This causes a lot of trouble with respect to timeout enforcement in general. Due to this flaw of these systems, HAProxy maintains its own monotonic clock which is based on the system's clock but where drift is measured and compensated for. This ensures that even with a very bad system clock, timers remain reasonably accurate and timeouts continue to work. Note that this problem affects all the software running on such systems and is not specific to HAProxy. The common effects are spurious timeouts or application freezes. Thus if this behavior is detected on a system, it must be fixed, regardless of the fact that HAProxy protects itself against it.

일부 시스템에는 과거와 미래를 왔다갔다하는 신뢰할 수 없는 시계가 있습니다. 이것은 여러 NUMA 시스템에서 발생했습니다. 프로세서는 하루 중 정확히 같은 시간을 보지 못했고 최근에는 가상 시계가 실제 시계와 관련이 없는 가상화된 환경에서 더 일반적이 되어 엄청난 시간 점프가 발생했습니다(때로는 최대 30초가 관찰됨). 이것은 일반적으로 시간 초과 적용과 관련하여 많은 문제를 일으킵니다. 이러한 시스템의 이러한 결함으로 인해 HAProxy는 시스템의 시계를 기반으로 하지만 드리프트(drift)가 측정되고 보상되는 자체 단조 시계를 유지합니다. 이렇게 하면 시스템 시계가 매우 나쁜 경우에도 타이머가 합리적으로 정확하고 시간 초과가 계속 작동합니다. 이 문제는 이러한 시스템에서 실행되는 모든 소프트웨어에 영향을 미치며 HAProxy에만 국한되지 않습니다. 일반적인 결과는 가짜 시간 초과 또는 응용 프로그램 정지입니다. 따라서 이 동작이 시스템에서 감지되면 HAProxy가 이에 대해 스스로를 보호한다는 사실에 관계없이 수정해야 합니다.

On Linux, a new starting process may communicate with the previous one to reuse its listening file descriptors so that the listening sockets are never interrupted during the process's replacement.
Linux에서 새 시작 프로세스는 이전 프로세스와 통신하여 청취 파일 설명자를 재사용할 수 있으므로 프로세스가 교체되는 동안 청취 소켓이 중단되지 않습니다.

3.5.3. Advanced features : Scripting   Lua 스크립팅

HAProxy can be built with support for the Lua embedded language, which opens a wide area of new possibilities related to complex manipulation of requests or responses, routing decisions, statistics processing and so on. Using Lua it is even possible to establish parallel connections to other servers to exchange information. This way it becomes possible (though complex) to develop an authentication system for example. Please refer to the documentation in the file "doc/lua-api/index.rst" for more information on how to use Lua.

HAProxy는 요청 또는 응답의 복잡한 조작, 라우팅 결정, 통계 처리 등과 관련된 새로운 가능성의 넓은 영역을 열어주는 Lua 내장 언어를 지원하여 구축할 수 있습니다. Lua를 사용하면 정보를 교환하기 위해 다른 서버에 병렬 연결을 설정하는 것도 가능합니다. 이렇게 하면 (복잡하지만) 예를 들어 인증 시스템을 개발할 수 있습니다. Lua 사용법에 대한 자세한 내용은 "doc/lua-api/index.rst" 파일의 문서를 참조하십시오.

3.5.4. Advanced features: Tracing 추적

At any moment an administrator may connect over the CLI and enable tracing in various internal subsystems. Various levels of details are provided by default so that in practice anything between one line per request to 500 lines per request can be retrieved. Filters as well as an automatic capture on/off/pause mechanism are available so that it really is possible to wait for a certain event and watch it in detail. This is extremely convenient to diagnose protocol violations from faulty servers and clients, or denial of service attacks.

관리자는 언제든지 CLI를 통해 연결하고 다양한 내부 하위 시스템에서 추적을 활성화할 수 있습니다. 기본적으로 다양한 수준의 세부 정보가 제공되므로 실제로 요청당 한 줄에서 500줄 사이의 모든 항목을 검색할 수 있습니다. 필터와 자동 캡처 켜기/끄기/일시 정지 메커니즘을 사용할 수 있으므로 실제로 특정 이벤트를 기다리고 자세히 볼 수 있습니다. 이것은 결함이 있는 서버 및 클라이언트의 프로토콜 위반 또는 서비스 거부 공격을 진단하는 데 매우 편리합니다.

3.6. Sizing 확장

Typical CPU usage figures show 15% of the processing time spent in HAProxy versus 85% in the kernel in TCP or HTTP close mode, and about 30% for HAProxy versus 70% for the kernel in HTTP keep-alive mode. This means that the operating system and its tuning have a strong impact on the global performance.

일반적인 CPU 사용량 수치는 TCP 또는 HTTP 닫기 모드에서 HAProxy에서 15%, 커널에서 85%이고, HTTP 연결 유지 모드에서 HAProxy에서 약 30%, 커널에서 70%를 보여줍니다. 이는 운영 체제와 해당 조정이 글로벌 성능에 큰 영향을 미친다는 것을 의미합니다.

Usages vary a lot between users, some focus on bandwidth, other ones on request rate, others on connection concurrency, others on SSL performance. This section aims at providing a few elements to help with this task.

사용법은 사용자마다 많이 다르며, 일부는 대역폭, 다른 것은 요청 속도, 다른 것은 연결 동시성, 다른 것은 SSL 성능에 중점을 둡니다. 이 섹션은 이 작업에 도움이 되는 몇 가지 요소를 제공하는 것을 목표로 합니다.

It is important to keep in mind that every operation comes with a cost, so each individual operation adds its overhead on top of the other ones, which may be negligible in certain circumstances, and which may dominate in other cases.

모든 작업에는 비용이 따르므로 각 개별 작업은 오버헤드를 다른 작업 위에 추가합니다. 이 오버헤드는 특정 상황에서는 무시할 수 있고 다른 경우에는 압도적일 수 있습니다.

When processing the requests from a connection, we can say that :
연결의 요청을 처리할 때 다음과 같이 말할 수 있습니다.

  • forwarding data costs less than parsing request or response headers;
    요청 또는 응답 헤더를 구문 분석하는 것보다 데이터 전달 비용이 저렴합니다.
  • parsing request or response headers cost less than establishing then closing a connection to a server;
    요청 또는 응답 헤더를 구문 분석하는 비용은 서버에 대한 연결을 설정한 다음 닫는 것보다 저렴합니다.
  • establishing an closing a connection costs less than a TLS resume operation;
    TLS 재개 작업보다 비용이 적게 드는 연결 종료 설정;
  • a TLS resume operation costs less than a full TLS handshake with a key computation;
    TLS 재개 작업 비용은 키 계산이 포함된 전체 TLS 핸드셰이크보다 저렴합니다.
  • an idle connection costs less CPU than a connection whose buffers hold data;
    유휴 연결은 버퍼가 데이터를 보유하는 연결보다 CPU 비용이 적게 듭니다.
  • a TLS context costs even more memory than a connection with data;
    TLS 컨텍스트는 데이터 연결보다 더 많은 메모리 비용이 듭니다.

TLS(Transport Layer Security, 전송 계층 보안) 설명

  • TLS(Transport Layer Security, 전송 계층 보안)는 인터넷 상의 커뮤니케이션을 위한 개인 정보와 데이터 보안을 용이하게 하기 위해 설계되어 널리 채택된 보안 프로토콜입니다.
  • TLS와 SSL의 차이점은 무엇입니까?
    TLS는 Netscape가 개발한 SSL(Secure Sockets Layer)이라고 불리는 이전의 암호화 프로토콜에서 발전한 것입니다. TLS 버전 1.0은 SSL 버전 3.1로서 개발을 시작했지만 Netscape와 더 이상 연관이 없음을 명시하기 위해 발표 전에 프로토콜의 이름이 변경되었습니다. 이러한 역사 때문에 용어 TLS와 SSL은 가끔 서로 바꿔서 사용됩니다.
  • TLS와 HTTPS의 차이점은 무엇입니까?
    HTTPS는 HTTP 프로토콜 상위에서 TLS 암호화를 구현한 것으로 모든 웹 사이트와 다른 웹 서비스에서 사용됩니다. 따라서 HTTPS를 사용하는 웹 사이트는 TLS 암호화를 이용합니다.
  • TLS는 무엇을 합니까?
    TLS 프로토콜은 암호화, 인증, 무결성이라는 세 가지 주요 요소를 달성합니다.
    1) 암호화: 제3자로부터 전송되는 데이터를 숨깁니다.
    2) 인증: 정보를 교환하는 당사자가 요청된 당사자임을 보장합니다.
    3) 무결성: 데이터가 위조되거나 변조되지 않았는지 확인합니다.

So in practice, it is cheaper to process payload bytes than header bytes, thus it is easier to achieve high network bandwidth with large objects (few requests per volume unit) than with small objects (many requests per volume unit). This explains why maximum bandwidth is always measured with large objects, while request rate or connection rates are measured with small objects.

따라서 실제로는 헤더 바이트보다 페이로드 바이트를 처리하는 것이 더 저렴하므로 작은 개체(볼륨 단위당 많은 요청)보다 큰 개체(볼륨 단위당 적은 요청)로 높은 네트워크 대역폭을 달성하는 것이 더 쉽습니다. 이것은 최대 대역폭이 항상 큰 개체로 측정되는 반면 요청 속도 또는 연결 속도는 작은 개체로 측정되는 이유를 설명합니다.

Some operations scale well on multiple processes spread over multiple CPUs, and others don't scale as well. Network bandwidth doesn't scale very far because the CPU is rarely the bottleneck for large objects, it's mostly the network bandwidth and data buses to reach the network interfaces. The connection rate doesn't scale well over multiple processors due to a few locks in the system when dealing with the local ports table. The request rate over persistent connections scales very well as it doesn't involve much memory nor network bandwidth and doesn't require to access locked structures. TLS key computation scales very well as it's totally CPU-bound. TLS resume scales moderately well, but reaches its limits around 4 processes where the overhead of accessing the shared table offsets the small gains expected from more power.

일부 작업은 여러 CPU에 분산된 여러 프로세스에서 잘 확장되고 다른 작업은 확장되지 않습니다. CPU가 큰 개체에 대한 병목 현상이 거의 발생하지 않기 때문에 네트워크 대역폭은 크게 확장되지 않습니다. 대부분 네트워크 대역폭과 데이터 버스가 네트워크 인터페이스에 도달하기 때문입니다. 로컬 포트 테이블을 처리할 때 시스템의 몇 가지 잠금으로 인해 연결 속도가 여러 프로세서에서 잘 확장되지 않습니다. 지속적인 연결을 통한 요청 속도는 많은 메모리나 네트워크 대역폭을 포함하지 않고 잠긴 구조에 액세스할 필요가 없기 때문에 매우 잘 확장됩니다. TLS 키 계산은 완전히 CPU에 종속되기 때문에 확장성이 뛰어납니다. TLS 재개는 적절하게 확장되지만 공유 테이블에 액세스하는 오버헤드가 더 많은 전력에서 예상되는 작은 이득을 상쇄하는 4개의 프로세스 주변에서 한계에 도달합니다.

The performance numbers one can expect from a very well tuned system are in the following range. It is important to take them as orders of magnitude and to expect significant variations in any direction based on the processor, IRQ setting, memory type, network interface type, operating system tuning and so on.

매우 잘 조정된 시스템에서 기대할 수 있는 성능 수치는 다음 범위에 있습니다. 프로세서, IRQ 설정, 메모리 유형, 네트워크 인터페이스 유형, 운영 체제 조정 등을 기반으로 모든 방향에서 상당한 변화를 예상하고 크기의 순서로 사용하는 것이 중요합니다.

The following numbers were found on a Core i7 running at 3.7 GHz equipped with a dual-port 10 Gbps NICs running Linux kernel 3.10, HAProxy 1.6 and OpenSSL 1.0.2. HAProxy was running as a single process on a single dedicated CPU core, and two extra cores were dedicated to network interrupts :

다음 숫자는 Linux 커널 3.10, HAProxy 1.6 및 OpenSSL 1.0.2를 실행하는 듀얼 포트 10Gbps NIC가 장착된 3.7GHz에서 실행되는 Core i7에서 발견되었습니다. HAProxy는 단일 전용 CPU 코어에서 단일 프로세스로 실행되고 있었고 두 개의 추가 코어가 네트워크 인터럽트 전용으로 사용되었습니다.

  • 20 Gbps of maximum network bandwidth in clear text for objects 256 kB or higher, 10 Gbps for 41kB or higher;
    256kB 이상의 개체에 대해 일반 텍스트로 된 최대 네트워크 대역폭 20Gbps, 41kB 이상에 대해 10Gbps
  • 4.6 Gbps of TLS traffic using AES256-GCM cipher with large objects;
    대형 개체와 함께 AES256-GCM 암호를 사용하는 4.6Gbps의 TLS 트래픽
  • 83000 TCP connections per second from client to server;
    클라이언트에서 서버로 초당 83,000 TCP 연결;
  • 82000 HTTP connections per second from client to server;
    클라이언트에서 서버로 초당 82,000 HTTP 연결;
  • 97000 HTTP requests per second in server-close mode (keep-alive with the client, close with the server);
    서버 닫기 모드에서 초당 97000 HTTP 요청(클라이언트와 연결 유지, 서버와 닫기)
  • 243000 HTTP requests per second in end-to-end keep-alive mode;
    종단 간 연결 유지 모드에서 초당 243,000 HTTP 요청;
  • 300000 filtered TCP connections per second (anti-DDoS)
    초당 300,000 필터링된 TCP 연결(DDoS 방지)
  • 160000 HTTPS requests per second in keep-alive mode over persistent TLS connections;
    지속적인 TLS 연결을 통한 연결 유지 모드에서 초당 160,000 HTTPS 요청;
  • 13100 HTTPS requests per second using TLS resumed connections;
    TLS 재개 연결을 사용하여 초당 13,100 HTTPS 요청;
  • 1300 HTTPS connections per second using TLS connections renegotiated with RSA2048;
    RSA2048과 재협상된 TLS 연결을 사용하여 초당 1,300 HTTPS 연결
  • 20000 concurrent saturated connections per GB of RAM, including the memory required for system buffers; it is possible to do better with careful tuning but this result it easy to achieve.
    시스템 버퍼에 필요한 메모리를 포함하여 RAM GB당 20000개의 동시 포화(꽉 채워진) 연결 조심스럽게 조정하면 더 잘할 수 있지만 이 결과를 얻기는 쉽습니다.
  • about 8000 concurrent TLS connections (client-side only) per GB of RAM, including the memory required for system buffers;
    시스템 버퍼에 필요한 메모리를 포함하여 RAM GB당 약 8,000개의 동시 TLS 연결(클라이언트 측 전용)
  • about 5000 concurrent end-to-end TLS connections (both sides) per GB of RAM including the memory required for system buffers;
    시스템 버퍼에 필요한 메모리를 포함하여 RAM GB당 약 5,000개의 동시 종단 간 TLS 연결(양쪽 모두)

A more recent benchmark featuring the multi-thread enabled HAProxy 2.4 on a 64-core ARM Graviton2 processor in AWS reached 2 million HTTPS requests per second at sub-millisecond response time, and 100 Gbps of traffic:

AWS의 64코어 ARM Graviton2 프로세서에서 다중 스레드 지원 HAProxy 2.4를 특징으로 하는 보다 최근의 벤치마크는 밀리초 미만의 응답 시간 및 100Gbps의 트래픽에서 초당 200만 HTTPS 요청에 도달했습니다.

2 Million HTTP Requests per Second - 2021년 4월 8일

Thus a good rule of thumb to keep in mind is that the request rate is divided by 10 between TLS keep-alive and TLS resume, and between TLS resume and TLS renegotiation, while it's only divided by 3 between HTTP keep-alive and HTTP close. Another good rule of thumb is to remember that a high frequency core with AES instructions can do around 20 Gbps of AES-GCM per core.

따라서 기억해야 할 좋은 경험 법칙은 요청 속도를 TLS 연결 유지와 TLS 재개 사이, 그리고 TLS 재개와 TLS 재협상 간에 10으로 나누는 반면 HTTP 연결 유지와 HTTP 닫기 간에는 3으로만 나누는 것입니다. 또 다른 좋은 경험 법칙은 AES 명령어가 있는 고주파 코어가 코어당 약 20Gbps의 AES-GCM을 수행할 수 있다는 것을 기억하는 것입니다.

Another good rule of thumb is to consider that on the same server, HAProxy will be able to saturate :
또 다른 좋은 경험 법칙은 동일한 서버에서 HAProxy가 다음을 포화시킬 수 있다는 점입니다.

  • about 5-10 static file servers or caching proxies;
    약 5-10개의 정적 파일 서버 또는 캐싱 프록시;
  • about 100 anti-virus proxies;
    약 100개의 안티바이러스 프록시
  • and about 100-1000 application servers depending on the technology in use.
    사용 중인 기술에 따라 약 100-1000개의 애플리케이션 서버.

3.7. How to get HAProxy

HAProxy is an open source project covered by the GPLv2 license, meaning that everyone is allowed to redistribute it provided that access to the sources is also provided upon request, especially if any modifications were made.

HAProxy는 GPLv2 라이선스가 적용되는 오픈 소스 프로젝트입니다. 즉, 특히 수정 사항이 있는 경우 요청 시 소스에 대한 액세스도 제공된다면 모든 사람이 이를 재배포할 수 있습니다.

HAProxy evolves as a main development branch called "master" or "mainline", from which new branches are derived once the code is considered stable. A lot of web sites run some development branches in production on a voluntarily basis, either to participate to the project or because they need a bleeding edge feature, and their feedback is highly valuable to fix bugs and judge the overall quality and stability of the version being developed.

HAProxy는 "마스터" 또는 "메인라인"이라는 주요 개발 분기로 발전하며, 코드가 안정적인 것으로 간주되면 새 분기가 파생됩니다. 많은 웹 사이트가 프로젝트에 참여하기 위해 또는 최첨단 기능이 필요하기 때문에 자발적으로 프로덕션에서 일부 개발 분기를 실행하며, 피드백은 버그를 수정하고 개발 중인 버전의 전반적인 품질과 안정성을 판단하는 데 매우 중요합니다.

The new branches that are created when the code is stable enough constitute a stable version and are generally maintained for several years, so that there is no emergency to migrate to a newer branch even when you're not on the latest. Once a stable branch is issued, it may only receive bug fixes, and very rarely minor feature updates when that makes users' life easier. All fixes that go into a stable branch necessarily come from the master branch. This guarantees that no fix will be lost after an upgrade. For this reason, if you fix a bug, please make the patch against the master branch, not the stable branch. You may even discover it was already fixed. This process also ensures that regressions in a stable branch are extremely rare, so there is never any excuse for not upgrading to the latest version in your current branch.

코드가 충분히 안정적일 때 생성되는 새 브랜치는 안정적인 버전을 구성하며 일반적으로 몇 년 동안 유지되므로 최신 브랜치가 아니더라도 새 브랜치로 긴급하게 마이그레이션할 필요가 없습니다. 안정적인 분기가 발행되면 버그 수정만 받을 수 있으며 사용자의 삶을 더 쉽게 만들어주는 사소한 기능 업데이트는 거의 없습니다. 안정적인 브랜치로 이동하는 모든 수정 사항은 반드시 마스터 브랜치에서 제공됩니다. 이렇게 하면 업그레이드 후 수정 사항이 손실되지 않습니다. 따라서 버그를 수정한다면 안정 브랜치가 아닌 마스터 브랜치를 대상으로 패치를 진행하시기 바랍니다. 이미 수정되었음을 발견할 수도 있습니다. 이 프로세스는 또한 안정적인 분기에서 회귀가 극히 드물다는 것을 확인하므로 현재 분기에서 최신 버전으로 업그레이드하지 않을 이유가 없습니다.

Branches are numbered with two digits delimited with a dot, such as "1.6". Since 1.9, branches with an odd second digit are mostly focused on sensitive technical updates and more aimed at advanced users because they are likely to trigger more bugs than the other ones. They are maintained for about a year only and must not be deployed where they cannot be rolled back in emergency. A complete version includes one or two sub-version numbers indicating the level of fix. For example, version 1.5.14 is the 14th fix release in branch 1.5 after version 1.5.0 was issued. It contains 126 fixes for individual bugs, 24 updates on the documentation, and 75 other backported patches, most of which were needed to fix the aforementioned 126 bugs. An existing feature may never be modified nor removed in a stable branch, in order to guarantee that upgrades within the same branch will always be harmless.

분기는 "1.6"과 같이 점으로 구분된 두 자리 숫자로 번호가 매겨집니다. 1.9 이후로 두 번째 숫자가 홀수인 분기는 대부분 민감한 기술 업데이트에 중점을 두고 있으며 다른 것보다 더 많은 버그를 유발할 가능성이 있기 때문에 고급 사용자를 대상으로 합니다. 약 1년 동안만 유지 관리되며 비상 시 롤백할 수 없는 곳에 배포해서는 안 됩니다. 전체 버전에는 수정 수준을 나타내는 하나 또는 두 개의 하위 버전 번호가 포함됩니다. 예를 들어, 버전 1.5.14는 버전 1.5.0이 발행된 후 분기 1.5의 14번째 수정 릴리스입니다. 여기에는 개별 버그에 대한 126개의 수정, 문서에 대한 24개의 업데이트, 그리고 앞서 언급한 126개의 버그를 수정하는 데 필요한 기타 백포트된 패치 75개가 포함되어 있습니다. 동일한 브랜치 내의 업그레이드가 항상 무해하다는 것을 보장하기 위해 기존 기능은 안정적인 브랜치에서 수정되거나 제거될 수 없습니다.

HAProxy is available from multiple sources, at different release rhythms :
HAProxy는 다양한 릴리스 리듬으로 여러 소스에서 사용할 수 있습니다.

  • The official community web site : http://www.haproxy.org/ : this site provides the sources of the latest development release, all stable releases, as well as nightly snapshots for each branch. The release cycle is not fast, several months between stable releases, or between development snapshots. Very old versions are still supported there. Everything is provided as sources only, so whatever comes from there needs to be rebuilt and/or repackaged;

    공식 커뮤니티 웹사이트 : www.haproxy.org
    이 사이트는 최신 개발 릴리스, 모든 안정적인 릴리스 및 각 분기에 대한 야간 스냅샷의 소스를 제공합니다. 릴리스 주기는 빠르지 않습니다. 안정적인 릴리스 사이 또는 개발 스냅샷 사이에 몇 개월이 걸립니다. 아주 오래된 버전이 여전히 지원됩니다. 모든 것은 소스로만 제공되므로 거기에서 나오는 것은 무엇이든 다시 빌드 및/또는 재패키징해야 합니다.
  • GitHub : https://github.com/haproxy/haproxy/ : this is the mirror for the development branch only, which provides integration with the issue tracker, continuous integration and code coverage tools. This is exclusively for contributors;
    GitHub : github.com/haproxy/haproxy/ :
    이슈 추적기, 지속적인 통합 및 코드 커버리지 도구와의 통합을 제공하는 개발 브랜치 전용 미러입니다. 이것은 기여자(contributors) 전용입니다.
  • A number of operating systems such as Linux distributions and BSD ports. These systems generally provide long-term maintained versions which do not always contain all the fixes from the official ones, but which at least contain the critical fixes. It often is a good option for most users who do not seek advanced configurations and just want to keep updates easy;

    Linux 배포판 및 BSD 포트와 같은 여러 운영 체제.
    이러한 시스템은 일반적으로 공식 버전의 모든 수정 사항을 항상 포함하지는 않지만 최소한 중요한 수정 사항은 포함하는 장기 유지 버전을 제공합니다. 고급 구성을 추구하지 않고 업데이트를 쉽게 유지하려는 대부분의 사용자에게 좋은 옵션인 경우가 많습니다.
  • Commercial versions from http://www.haproxy.com/ : these are supported professional packages built for various operating systems or provided as appliances, based on the latest stable versions and including a number of features backported from the next release for which there is a strong demand. It is the best option for users seeking the latest features with the reliability of a stable branch, the fastest response time to fix bugs, or simply support contracts on top of an open source product;

    상용 버전 www.haproxy.com :
    이들은 최신 안정 버전을 기반으로 하고 수요가 많은 다음 릴리스에서 백포트된 여러 기능을 포함하여 다양한 운영 체제용으로 구축되거나 어플라이언스로 제공되는 지원되는 전문 패키지입니다. 안정적인 브랜치의 신뢰성, 버그 수정에 대한 가장 빠른 응답 시간 또는 단순히 오픈 소스 제품 위에 계약을 지원하는 최신 기능을 찾는 사용자에게 가장 적합한 옵션입니다.

In order to ensure that the version you're using is the latest one in your branch, you need to proceed this way :
사용 중인 버전이 분기의 최신 버전인지 확인하려면 다음과 같이 진행해야 합니다.

  • verify which HAProxy executable you're running : some systems ship it by default and administrators install their versions somewhere else on the system, so it is important to verify in the startup scripts which one is used;
    실행 중인 HAProxy 실행 파일 확인: 일부 시스템은 기본적으로 이를 제공하고 관리자는 시스템의 다른 위치에 해당 버전을 설치하므로 시작 스크립트에서 어느 것이 사용되는지 확인하는 것이 중요합니다.
  • determine which source your HAProxy version comes from. For this, it's generally sufficient to type "haproxy -v". A development version will appear like this, with the "dev" word after the branch number :
    HAProxy 버전의 출처를 확인합니다. 이를 위해 일반적으로 "haproxy -v"를 입력하는 것으로 충분합니다. 개발 버전은 브랜치 번호 뒤에 "dev"라는 단어가 있는 다음과 같이 나타납니다.
    HAProxy version 2.4-dev18-a5357c-137 2021/05/09 - https://haproxy.org/
  • A stable version will appear like this, as well as unmodified stable versions provided by operating system vendors :
    안정적인 버전과 운영 체제 공급업체에서 제공하는 수정되지 않은 안정적인 버전이 다음과 같이 표시됩니다.
    HAProxy version 1.5.14 2015/07/02
  • And a nightly snapshot of a stable version will appear like this with an hexadecimal sequence after the version, and with the date of the snapshot instead of the date of the release :
    그리고 안정적인 버전의 야간 스냅샷은 다음과 같이 버전 뒤에 16진수 시퀀스로 표시되며 릴리스 날짜 대신 스냅샷 날짜가 표시됩니다.
    HAProxy version 1.5.14-e4766ba 2015/07/29
  • Any other format may indicate a system-specific package with its own patch set. For example HAProxy Enterprise versions will appear with the following format (<branch>-<latest commit>-<revision>) :
    다른 형식은 자체 패치 세트가 있는 시스템별 패키지를 나타낼 수 있습니다. 예를 들어 HAProxy Enterprise 버전은 다음 형식(<branch>-<latest commit>-<revision>)으로 나타납니다.
    HAProxy version 1.5.0-994126-357 2015/07/02
  • Please note that historically versions prior to 2.4 used to report the process name with a hyphen between "HA" and "Proxy", including those above which were adjusted to show the correct format only, so better ignore this word or use a relaxed match in scripts. Additionally, modern versions add a URL linking to the project's home.
    역사적으로 2.4 이전 버전은 올바른 형식만 표시하도록 조정된 위를 포함하여 "HA"와 "프록시" 사이에 하이픈이 있는 프로세스 이름을 보고하는 데 사용되었으므로 이 단어를 무시하거나 다음에서 완화된 일치를 사용하는 것이 좋습니다. 스크립트. 또한 최신 버전은 프로젝트의 홈으로 연결되는 URL을 추가합니다.
  • Finally, versions 2.1 and above will include a "Status" line indicating whether the version is safe for production or not, and if so, till when, as well as a link to the list of known bugs affecting this version.
    마지막으로 버전 2.1 이상에는 해당 버전이 프로덕션에 안전한지 여부를 나타내는 "상태" 행과 안전한 경우 언제까지, 이 버전에 영향을 미치는 알려진 버그 목록에 대한 링크가 포함됩니다.
  • for system-specific packages, you have to check with your vendor's package repository or update system to ensure that your system is still supported, and that fixes are still provided for your branch. For community versions coming from haproxy.org, just visit the site, verify the status of your branch and compare the latest version with yours to see if you're on the latest one. If not you can upgrade. If your branch is not maintained anymore, you're definitely very late and will have to consider an upgrade to a more recent branch (carefully read the README when doing so).

    시스템별 패키지의 경우 공급업체의 패키지 리포지토리 또는 업데이트 시스템에 확인하여 시스템이 계속 지원되고 해당 지점에 수정 사항이 계속 제공되는지 확인해야 합니다. haproxy.org에서 제공하는 커뮤니티 버전의 경우 사이트를 방문하여 분기의 상태를 확인하고 최신 버전을 귀하의 것과 비교하여 최신 버전인지 확인하십시오. 그렇지 않은 경우 업그레이드할 수 있습니다. 당신의 브랜치가 더 이상 유지되지 않는다면 당신은 확실히 매우 늦은 것이고 더 최신 브랜치로의 업그레이드를 고려해야 할 것입니다(그렇게 할 때 README를 주의 깊게 읽으십시오).

HAProxy will have to be updated according to the source it came from. Usually it follows the system vendor's way of upgrading a package. If it was taken from sources, please read the README file in the sources directory after extracting the sources and follow the instructions for your operating system.

HAProxy는 출처에 따라 업데이트해야 합니다. 일반적으로 패키지를 업그레이드하는 시스템 공급업체의 방식을 따릅니다. 소스에서 가져온 경우 소스를 추출한 후 소스 디렉토리에서 README 파일을 읽고 운영 체제에 대한 지침을 따르십시오.

4. Companion products and alternatives 동반 제품 및 대안

HAProxy integrates fairly well with certain products listed below, which is why they are mentioned here even if not directly related to HAProxy.
HAProxy는 아래에 나열된 특정 제품과 상당히 잘 통합되므로 HAProxy와 직접 관련이 없더라도 여기에 언급됩니다.

4.1. Apache HTTP server

Apache is the de-facto standard HTTP server. It's a very complete and modular project supporting both file serving and dynamic contents. It can serve as a frontend for some application servers. It can even proxy requests and cache responses. In all of these use cases, a front load balancer is commonly needed. Apache can work in various modes, some being heavier than others. Certain modules still require the heavier pre-forked model and will prevent Apache from scaling well with a high number of connections. In this case HAProxy can provide a tremendous help by enforcing the per-server connection limits to a safe value and will significantly speed up the server and preserve its resources that will be better used by the application.

Apache는 사실상의 표준 HTTP 서버입니다. 파일 서비스와 동적 콘텐츠를 모두 지원하는 매우 완전하고 모듈화된 프로젝트입니다. 일부 애플리케이션 서버의 프론트엔드 역할을 할 수 있습니다. 요청을 프록시하고 응답을 캐시할 수도 있습니다. 이러한 모든 사용 사례에서 일반적으로 전면 로드 밸런서가 필요합니다. Apache는 다양한 모드에서 작동할 수 있으며 일부는 다른 것보다 무겁습니다. 특정 모듈은 여전히 더 무거운 사전 포크 모델이 필요하며 Apache가 많은 수의 연결로 잘 확장되는 것을 방지합니다. 이 경우 HAProxy는 서버당 연결 제한을 안전한 값으로 적용하여 엄청난 도움을 제공할 수 있으며 서버 속도를 크게 높이고 응용 프로그램에서 더 잘 사용할 리소스를 보존합니다.

Apache can extract the client's address from the X-Forwarded-For header by using the "mod_rpaf" extension. HAProxy will automatically feed this header when "option forwardfor" is specified in its configuration. HAProxy may also offer a nice protection to Apache when exposed to the internet, where it will better resist a wide number of types of DoS attacks.

Apache는 "mod_rpaf" 확장을 사용하여 X-Forwarded-For 헤더에서 클라이언트 주소를 추출할 수 있습니다. HAProxy는 구성에 "옵션 전달(option forwardfor)"이 지정된 경우 이 헤더를 자동으로 제공합니다. HAProxy는 또한 인터넷에 노출되었을 때 Apache에 대한 훌륭한 보호 기능을 제공할 수 있으며, 이 경우 다양한 유형의 DoS 공격에 더 잘 저항할 수 있습니다.

4.2. NGINX   엔진엑스

NGINX is the second de-facto standard HTTP server. Just like Apache, it covers a wide range of features. NGINX is built on a similar model as HAProxy so it has no problem dealing with tens of thousands of concurrent connections. When used as a gateway to some applications (e.g. using the included PHP FPM) it can often be beneficial to set up some frontend connection limiting to reduce the load on the PHP application. HAProxy will clearly be useful there both as a regular load balancer and as the traffic regulator to speed up PHP by decongesting it. Also since both products use very little CPU thanks to their event-driven architecture, it's often easy to install both of them on the same system. NGINX implements HAProxy's PROXY protocol, thus it is easy for HAProxy to pass the client's connection information to NGINX so that the application gets all the relevant information. Some benchmarks have also shown that for large static file serving, implementing consistent hash on HAProxy in front of NGINX can be beneficial by optimizing the OS' cache hit ratio, which is basically multiplied by the number of server nodes.

NGINX는 사실상의 두 번째 표준 HTTP 서버입니다. Apache와 마찬가지로 광범위한 기능을 다룹니다. NGINX는 HAProxy와 유사한 모델을 기반으로 구축되어 수만 개의 동시 연결을 처리하는 데 문제가 없습니다. 일부 응용 프로그램에 대한 게이트웨이로 사용되는 경우(예: 포함된 PHP FPM 사용) PHP 응용 프로그램의 부하를 줄이기 위해 일부 프런트엔드 연결 제한을 설정하는 것이 종종 유용할 수 있습니다. HAProxy는 일반 로드 밸런서와 PHP의 정체를 해소하여 PHP 속도를 높이는 트래픽 조절기로 분명히 유용할 것입니다. 또한 두 제품 모두 이벤트 기반 아키텍처 덕분에 CPU를 거의 사용하지 않기 때문에 두 제품을 동일한 시스템에 쉽게 설치할 수 있는 경우가 많습니다. NGINX는 HAProxy의 PROXY 프로토콜을 구현하므로 HAProxy가 클라이언트의 연결 정보를 NGINX에 쉽게 전달하여 애플리케이션이 모든 관련 정보를 얻을 수 있도록 합니다. 일부 벤치마크에서는 대용량 정적 파일 서비스의 경우 NGINX 앞의 HAProxy에서 일관된 해시를 구현하는 것이 기본적으로 서버 노드 수를 곱한 OS의 캐시 적중률을 최적화함으로써 이점을 얻을 수 있음을 보여주었습니다.

Nginx 이해하기 및 기본 환경설정 세팅하기
Nginx 공식 홈페이지

4.3. Varnish   바니시

Varnish is a smart caching reverse-proxy, probably best described as a web application accelerator. Varnish doesn't implement SSL/TLS and wants to dedicate all of its CPU cycles to what it does best. Varnish also implements HAProxy's PROXY protocol so that HAProxy can very easily be deployed in front of Varnish as an SSL offloader as well as a load balancer and pass it all relevant client information. Also, Varnish naturally supports decompression from the cache when a server has provided a compressed object, but doesn't compress however. HAProxy can then be used to compress outgoing data when backend servers do not implement compression, though it's rarely a good idea to compress on the load balancer unless the traffic is low.

Varnish는 아마도 웹 애플리케이션 가속기로 가장 잘 설명되는 스마트 캐싱 역방향 프록시입니다. Varnish는 SSL/TLS를 구현하지 않으며 모든 CPU 주기를 최선을 다하는 데 사용하려고 합니다. Varnish는 또한 HAProxy의 PROXY 프로토콜을 구현하여 HAProxy가 SSL 오프로더 및 로드 밸런서로서 Varnish 앞에 매우 쉽게 배포되고 모든 관련 클라이언트 정보를 전달할 수 있습니다. 또한 Varnish는 서버가 압축된 개체를 제공할 때 캐시에서 압축 해제를 자연스럽게 지원하지만 압축하지는 않습니다. 그러면 백엔드 서버가 압축을 구현하지 않을 때 HAProxy를 사용하여 나가는 데이터를 압축할 수 있지만 트래픽이 낮은 경우가 아니면 로드 밸런서에서 압축하는 것은 거의 좋은 생각이 아닙니다.

When building large caching farms across multiple nodes, HAProxy can make use of consistent URL hashing to intelligently distribute the load to the caching nodes and avoid cache duplication, resulting in a total cache size which is the sum of all caching nodes. In addition, caching of very small dumb objects for a short duration on HAProxy can sometimes save network round trips and reduce the CPU load on both the HAProxy and the Varnish nodes. This is only possible is no processing is done on these objects on Varnish (this is often referred to as the notion of "favicon cache", by which a sizeable percentage of useless downstream requests can sometimes be avoided). However do not enable HAProxy caching for a long time (more than a few seconds) in front of any other cache, that would significantly complicate troubleshooting without providing really significant savings.

여러 노드에 걸쳐 대규모 캐싱 팜을 구축할 때 HAProxy는 일관된 URL 해싱을 사용하여 캐싱 노드에 지능적으로 로드를 분산하고 캐시 중복을 방지하여 모든 캐싱 노드의 합계인 총 캐시 크기를 생성할 수 있습니다. 또한 HAProxy에서 짧은 기간 동안 매우 작은 벙어리 개체를 캐싱하면 네트워크 왕복을 절약하고 HAProxy와 Varnish 노드 모두에서 CPU 로드를 줄일 수 있습니다. 이는 Varnish에서 이러한 개체에 대해 처리가 수행되지 않는 경우에만 가능합니다 (이를 종종 "파비콘 캐시"의 개념이라고 하며, 상당한 비율의 쓸모없는 다운스트림 요청을 피할 수 있음). 그러나 다른 캐시 앞에서 오랜 시간(몇 초 이상) 동안 HAProxy 캐싱을 활성화하지 마십시오. 그러면 실제로 상당한 비용 절감 없이 문제 해결이 상당히 복잡해집니다.

Varnish 캐시 서버 소개
Varnish는 HTTP 요청에 신속한 응답을 제공하기 위해 결과 데이터를 캐싱(Caching)한 뒤 동일한 요청이 다시 들어오면 캐시된 데이터로 내려줘서 응답 시간을 줄여줄 수 있는 리버스 프록시(Reverse Proxy)이다. 흔히 웹 가속기라고도 불려진다. 요청한 URL을 기준으로 캐시 데이터를 생성하고, 만료 시간(TTL)을 설정해서 캐시가 자동 소멸되는 라이프 타임을 유지한다.
Varnish 캐시 히트 효율을 높이는 방법 - 2020년 3월 17일
Varnish 이야기 (NAVER) - 2013년 4월 25일
Varnish HTTP Cache 공식 홈페이지
Varnish Software

4.4. Alternatives   다른 선택

Linux Virtual Server (LVS or IPVS) is the layer 4 load balancer included within the Linux kernel. It works at the packet level and handles TCP and UDP. In most cases it's more a complement than an alternative since it doesn't have layer 7 knowledge at all.

Linux Virtual Server(LVS 또는 IPVS)는 Linux 커널에 포함된 레이어 4 로드 밸런서입니다. 패킷 수준에서 작동하며 TCP 및 UDP를 처리합니다. 대부분의 경우 레이어 7 지식이 전혀 없기 때문에 대안보다 보완에 가깝습니다.
LVS (Linux Virtual Server) 개요 (Red Hat)
IPVS(IP Virtual Server) - 2019년 1월 27일

Pound is another well-known load balancer. It's much simpler and has much less features than HAProxy but for many very basic setups both can be used. Its author has always focused on code auditability first and wants to maintain the set of features low. Its thread-based architecture scales less well with high connection counts, but it's a good product.

파운드는 또 다른 잘 알려진 로드 밸런서입니다. HAProxy보다 훨씬 간단하고 기능이 훨씬 적지만 많은 기본 설정에 둘 다 사용할 수 있습니다. 작성자는 항상 코드 감사 가능성에 중점을 두었으며 기능 집합을 낮게 유지하려고 합니다. 스레드 기반 아키텍처는 연결 수가 많으면 잘 확장되지 않지만 좋은 제품입니다.
RHEL / CentOS에서 POUND를 사용하여 웹 서버로드 밸런싱 설정
Pound (github)
Pound Proxy Server

Pen is a quite light load balancer. It supports SSL, maintains persistence using a fixed-size table of its clients' IP addresses. It supports a packet-oriented mode allowing it to support direct server return and UDP to some extents. It is meant for small loads (the persistence table only has 2048 entries).

Pen은 매우 가벼운 로드 밸런서입니다. SSL을 지원하고 고정된 크기의 클라이언트 IP 주소 테이블을 사용하여 지속성을 유지합니다. 패킷 지향 모드를 지원하여 서버 직접 반환 및 UDP를 어느 정도 지원할 수 있습니다. 작은 로드를 위한 것입니다(지속성 테이블에는 2048개의 항목만 있음).
Pen Load Balancer
Ubuntu pen manpage
Pen (github)

NGINX can do some load balancing to some extents, though it's clearly not its primary function. Production traffic is used to detect server failures, the load balancing algorithms are more limited, and the stickiness is very limited. But it can make sense in some simple deployment scenarios where it is already present. The good thing is that since it integrates very well with HAProxy, there's nothing wrong with adding HAProxy later when its limits have been reached.

NGINX는 분명히 주요 기능은 아니지만 로드 밸런싱을 어느 정도 수행할 수 있습니다. 프로덕션 트래픽은 서버 장애를 감지하는 데 사용되며 로드 밸런싱 알고리즘은 더 제한적이며 고정성은 매우 제한적입니다. 그러나 이미 존재하는 일부 간단한 배포 시나리오에서는 의미가 있을 수 있습니다. 좋은 점은 HAProxy와 매우 잘 통합되기 때문에 나중에 제한에 도달했을 때 HAProxy를 추가하는 데 아무런 문제가 없다는 것입니다.

Varnish also does some load balancing of its backend servers and does support real health checks. It doesn't implement stickiness however, so just like with NGINX, as long as stickiness is not needed that can be enough to start with. And similarly, since HAProxy and Varnish integrate so well together, it's easy to add it later into the mix to complement the feature set.

Varnish는 또한 백엔드 서버의 일부 로드 밸런싱을 수행하고 실제 상태 확인을 지원합니다. 그러나 고정성(stickiness)를 구현하지 않으므로 NGINX와 마찬가지로 고정성가 필요하지 않은 한 시작하기에 충분할 수 있습니다. 마찬가지로 HAProxy와 Varnish는 서로 잘 통합되므로 나중에 기능 세트를 보완하기 위해 혼합에 쉽게 추가할 수 있습니다.

5. Contacts

If you want to contact the developers or any community member about anything, the best way to do it usually is via the mailing list by sending your message to haproxy@formilux.org. Please note that this list is public and its archives are public as well so you should avoid disclosing sensitive information. A thousand of users of various experience levels are present there and even the most complex questions usually find an optimal response relatively quickly. Suggestions are welcome too. For users having difficulties with e-mail, a Discourse platform is available at http://discourse.haproxy.org/ . However please keep in mind that there are less people reading questions there and that most are handled by a really tiny team. In any case, please be patient and respectful with those who devote their spare time helping others.

개발자나 커뮤니티 회원에게 무엇이든 연락하고 싶은 경우 가장 좋은 방법은 일반적으로 메일링 리스트를 통해 haproxy@formilux.org로 메시지를 보내는 것입니다. 이 목록은 공개되며 해당 아카이브도 공개되므로 민감한 정보를 공개하지 않도록 주의하십시오. 다양한 경험 수준의 수천 명의 사용자가 거기에 있으며 가장 복잡한 질문조차도 일반적으로 비교적 빨리 최적의 응답을 찾습니다.
제안도 환영합니다. 이메일 사용에 어려움이 있는 사용자를 위해 http://discourse.haproxy.org에서 Discourse 플랫폼을 사용할 수 있습니다. 그러나 거기에는 질문을 읽는 사람이 적고 대부분은 아주 작은 팀에서 처리한다는 점을 명심하십시오. 여가 시간을 다른 사람을 돕는 데 바치는 사람들은 어떤 경우에도 인내심을 갖고 존중해 주십시오.

I you believe you've found a bug but are not sure, it's best reported on the mailing list. If you're quite convinced you've found a bug, that your version is up-to-date in its branch, and you already have a GitHub account, feel free to go directly to https://github.com/haproxy/haproxy/ and file an issue with all possibly available details. Again, this is public so be careful not to post information you might later regret. Since the issue tracker presents itself as a very long thread, please avoid pasting very long dumps (a few hundreds lines or more) and attach them instead.

버그를 발견했다고 생각하지만 확실하지 않은 경우 메일링 리스트에 보고하는 것이 가장 좋습니다. 버그를 발견했다고 확신하고 해당 분기에서 버전이 최신 상태이며 이미 GitHub 계정이 있는 경우 https://github.com/haproxy/haproxy/로 직접 이동하십시오. 가능한 모든 세부 정보로 이슈를 제출하십시오. 다시 말하지만 이것은 공개된 내용이므로 나중에 후회할 수 있는 정보를 게시하지 않도록 주의하십시오. 이슈 트래커는 매우 긴 스레드로 표시되므로 매우 긴 덤프(수백 줄 이상)를 붙여넣지 말고 대신 첨부하십시오.

If you've found what you're absolutely certain can be considered a critical security issue that would put many users in serious trouble if discussed in a public place, then you can send it with the reproducer to security@haproxy.org. A small team of trusted developers will receive it and will be able to propose a fix. We usually don't use embargoes and once a fix is available it gets merged. In some rare circumstances it can happen that a release is coordinated with software vendors. Please note that this process usually messes up with eveyone's work, and that rushed up releases can sometimes introduce new bugs, so it's best avoided unless strictly necessary; as such, there is often little consideration for reports that needlessly cause such extra burden, and the best way to see your work credited usually is to provide a working fix, which will appear in changelogs.

당신이 절대적으로 확신하는 것이 공개 장소에서 논의될 경우 많은 사용자를 심각한 문제에 빠뜨릴 수 있는 중대한 보안 문제로 간주될 수 있다는 것을 발견했다면 재생산자와 함께 security@haproxy.org로 보낼 수 있습니다. 신뢰할 수 있는 소규모 개발자 팀이 이를 받고 수정 사항을 제안할 수 있습니다. 우리는 일반적으로 금수 조치를 사용하지 않으며 수정 사항이 제공되면 병합됩니다. 드문 경우지만 릴리스가 소프트웨어 공급업체와 조정되는 경우가 있습니다. 이 프로세스는 일반적으로 모든 사람의 작업을 엉망으로 만들고 서두른 릴리스는 때때로 새로운 버그를 유발할 수 있으므로 꼭 필요한 경우가 아니면 피하는 것이 가장 좋습니다. 따라서 불필요한 추가 부담을 초래하는 보고서에 대한 고려가 거의 없으며 일반적으로 작업을 인정받는 가장 좋은 방법은 변경 로그에 표시될 작업 수정 사항을 제공하는 것입니다.

관련 글과 용어 설명

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy (NAVER) - 2013년 2월 15일
VRRP(Virtual Router Redundancy Protocol) - wiki
리눅스 VIP 설정 방법 - 2017년 8월 27일

가상 IP 할당하기 - 2016년 1월 16일
GNS3로 알아보는 OSI7 - L2 - 2016년 1월 16일

스위치, VIP, 로드밸런싱 A to Z - 2022년 5월 24일

  • L2 스위치 (스위칭 허브) 2계층(데이터 링크 계층)에서 작동
    각 장비의 MAC 주소를 내부적으로 저장하고 있기 때문에, 들어온 패킷의 MAC 주소를 읽어 해당하는 장비를 찾아 전달해주는 장비를 뜻한다.
  • L3 스위치 (라우터, 공유기) 3계층(네트워크 계층)은 라우팅 기능을 하는 층 라우팅은 서로 다른 네트워크를 연결하는 기능을 뜻한다. 스위치 자체에도 IP 주소가 할당되어 있다. L3 스위치는 MAC주소 + IP 주소까지 알고 있다.
  • L4 스위치 4계층(전송 계층)은 외부에서 들어오는 모든 요청을 먼저 받아들이는 계층이다. 로드 밸런싱 기능 제공 L4 스위치는 IP + Port 정보도 참고한다.
  • L7 스위치 (L5 스위치, L6 스위치) : L7 스위치가 L5, L6 기능까지 같이 한다.
    7계층(응용 계층) 역시 4계층처럼 일반적으로 스위치로 들어온 패킷을 적절한 서버로 전송해주는 로드 밸런싱을 위해 스위치를 사용하는데, L4 스위치와는 차이가 있다. L4 스위치의 경우 3~4 계층에 속하는 IP 주소 및 TCP/UDP Port 정보를 보고 스위칭하지만, L7 스위치의 경우 3~7계층에 속하는 IP 주소 및 TCP/UDP Port 정보, 패킷 내용까지 모두 보고 스위칭해주는 장비이다. 또한, L4 스위치의 경우 TCP/UDP Port를 이용하여 로드 밸런싱을 하지만, L7 스위치의 경우 7계층 HTTP의 URL, FTP 쿠키 정보 및 바이러스 패턴을 분석하여 보안에 더 유리하고 정교한 로드 밸런싱이 가능하다(Ex. VPN) 그래서 L7 스위치를 보안 스위치라고 부르기도한다.
  • VIP (Virtual IP, 가상 아이피) L4 스위치(로드밸런싱이라는 서비스를 제공해주는 장비)에 할당된다.
  • NAT (Network Address Translation) : 내부 네트워크에서 사용하는 사설 IP 주소와 로드밸런서 외부의 공인 IP 주소 간의 변환 역할
    SNAT (Source Network Address Translation): 내부에서 외부로 트래픽이 나갈 때 내부 사설 IP 주소 -> 외부 공인 IP 주소로 변환
    DNAT (Destination Network Address Translation) : 외부에서 내부로 트래픽이 들어오는 경우 외부 공인 IP 주소 -> 내부 사설 IP 주소로 변환

로드밸런싱의 개념 및 기법 설명 - 2022년 1월 4일

  • Health Check (상태 확인)
    - 서버들에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단하여, 정상 동작 중인 서버로만 트래픽을 보낸다.
    - L3 체크 : ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인한다.
    - ICMP : Internet Control Message Protocol. 패킷 전송에 실패했을 때 에러가 났음을 알림과 동시에, 해결 가능한 힌트를 제공하는 메시징 프로토콜.
    - L4 체크 : TCP는 3 Way-Handshaking (전송 - 확인/전송 - 확인) 를 기반으로 통신하는데, 이러한 TCP의 특성을 바탕으로 각 포트 상태를 체크하는 방식.
    - L7 체크 : 어플리케이션 계층에서 체크를 수행. 실제 웹페이지에 통신을 시도하여 이상 유무를 파악.
  • DSR (Direct Server Return)
    - 서버에서 클라이언트로 트래픽이 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음, 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트를 찾아가는 방식.
    - 이 기능을 통해 로드밸런서의 부하를 줄여줄 수 있음.
    - SLB(Server Load Balancer) 응답처리 : Client → L3 → L4 → Server → L3 → L4 → L3 → Client
    - DSR(Direct Server Return) 응답 처리 : Client → L3 → L4 → L3 → Server → L3 → Client

로드밸런싱 알고리즘

  • 라운드 로빈 방식 (Round Robin Method) - 서버로 들어온 요청을 순서대로 돌아가며 배정하는 방식. - 클라이언트의 요청을 순서대로 분배하기 때문에 서버들이 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합.
  • 가중 라운드로빈 방식 (Weighted Round Robin Method) - 각각의 서버마다 가중치(Weight)를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분. - 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 로드밸런싱 방식. - ex) 서버 A의 가중치: 5 / 서버 B의 가중치: 2 => A 서버에 5개의 Request, B 서버에 2개의 Request 할당.
  • IP 해시 방식 (IP Hash Method) - 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식. - 사용자의 IP를 해싱(Hashing)하여 부하를 분산하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장. - 경로가 보장되며, 접속자 수가 많을수록 분산 및 효율이 뛰어남. * 해싱(Hasing) : 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수.
  • 최소 연결 방식 (Least Connection Method) - Request가 들어온 시점에 가장 적은 연결(세션) 상태를 보이는 서버에 우선적으로 트래픽을 할당. - 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합.
  • 최소 응답시간 방식 (Least Response Time Method) - 서버의 현재 연결 상태와 응답시간(Response Time)을 모두 고려하여, 가장 짧은 응답 시간을 보내는 서버로 트래픽을 할당하는 방식. - 각 서버들의 가용한 리소스와 성능, 처리중인 데이터 양 등이 상이할 경우 적합.
  • 대역폭 방식 (Bandwidth Method) - 서버들과의 대역폭을 고려하여 서버에 트래픽을 할당.

L4 로드밸런서 vs L7 로드밸런서
특정 기능이 필요한 것이 아니라면, 초당 연결수(Connections Per Sec), 동시 연결수(Concurrent Connections), 처리용량(Throughput)을 성능 지표로 하여 L4 로드밸런서와 L7 로드밸런서 중 적절히 선택하는 것이 바람직할 것이다.

  • L4 로드 밸런서
    4 계층 - 네트워크 계층(IP, IPX)이나 3 계층 - 전송 계층(TCP, UDP) 의 정보를 바탕으로 로드를 분산.
    즉, IP 주소, 포트번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 분산하는 것이 가능.
    - 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르고 효율이 높음.
    - 데이터의 내용을 복호화할 필요가 없기에 안전.
    - L7 로드밸런서보다 가격이 저렴.
  • L7 로드 밸런서
    7 계층 - 어플리케이션 계층(HTTP, FTP, SMTP 등)에서 로드를 분산하기 때문에, HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능.
    - L4 로드밸런서의 기능에 더하여, 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능.
    - 특정한 패턴을 지닌 바이러스를 감지해 네트워크 보호 가능.
    - Dos/DDos 와 같은 비정상적인 트래픽 필터링 가능.
    ▶ URL 스위칭(URL Switching) 방식 : 특정 하위 URL들은 특정 서버로 처리하는 방식.
    ex) '.../steven/image' => 이미지 처리 서버 / '.../steven/video' => 동영상 처리 서버
    ▶ 컨텍스트 스위칭(Context Switching) 방식 : 클라이언트가 요청한 특정 리소스에 대해 특정 서버로 연결 가능.
    ex) 이미지 파일에 대해서는 확장자를 참조하여, 별도로 구성된 이미지 파일이 있는 서버 or 스토리지로 직접 연결.
    ▶ 쿠키 지속성(Persistence with Cookies) : 쿠키 정보를 바탕으로 클라이언트가 연결했었던 동일한 서버에 계속 할당해 주는 방식. 특히, 사설 네트워크에 있던 클라이언트의 IP 주소가 공인 IP 주소로 치환되어 전송하는 방식을 지원.
    ex) X-Forwarded-For 헤더에 클라이언트 IP 주소를 별도로 기입 장점)
    - 상위 계층에서 로드를 분산하기 때문에 훨씬 더 섬세한 라우팅 가능.
    - 캐싱(Cashing) 기능을 제공.
    - 비정상적인 트래픽을 사전에 필터링할 수 있어 서비스 안정성 높음.
  • Layer 간단 설명
    Layer 1 : Physical Network 전기적 신호 1 or 0
    Layer 2 : Network Insterface - MAC addr
    Layer 3 : Internet Protocol - IP addr
    Layer 4 : Transparent - Port
    Layer 7 : Application - HTTP, etc.
  • health check: tcp, inter=1 (매 1초마다 체크), retry=4 ( 4번 실패 시 down으로 정의)

LVS (Linux Virtual Server) 개요 (Red Hat)
LVS (Linux Virtual Server)는 실제 서버를 통해 IP 로드 밸런스를 맞추기 위한 통합된 소프트웨어 구성 요소 모음입니다. LVS는 동일하게 설정된 한 쌍의 컴퓨터 상에서 실행됩니다. 즉 하나는 활성 LVS 라우터이고 다른 하나는 백업 LVS 라우터이어야 합니다.
활성 LVS 라우터는 두 가지 역할을 수행합니다.
- 실제 서버 전역에 걸쳐 로드 밸런스 유지
- 각각의 실제 서버에서 서비스 무결성 확인
백업 LVS 라우터는
- 활성 LVS 라우터를 모니터하고
- 활성 LVS 라우터에 장애가 발생할 경우 이를 백업합니다.

Internet Network Level Protocol (인터넷 네트워크 레벨 프로토콜) (IBM)

  • ARP(주소 해석 프로토콜)
    첫 번째 네트워크 레벨 프로토콜은 주소 해석 프로토콜(ARP)입니다. ARP는 인터넷 주소를 근거리 통신망의 고유 하드웨어 주소로 동적으로 변환합니다.
  • ICMP(인터넷 제어 메시지 프로토콜) Layer 3
    두 번째 네트워크 레벨 프로토콜은 인터넷 제어 메시지 프로토콜(ICMP)입니다. ICMP는 모든 IP 구현의 필수 부분입니다. ICMP는 오류를 처리하고 IP 메시지를 제어합니다.
  • IP(인터넷 프로토콜) 세 번째 네트워크 레벨 프로토콜은 인터넷 프로토콜(IP)로 인터넷에 대해 신뢰할 수 없는 비연결 패킷 전달을 제공합니다.

ARP(Address Resolution Protocol) 프로토콜 - 2020년 6월 7일
ARP는 Address Resolution Protocol로 MAC 주소와 IP 주소를 맵핑하는 프로토콜이다.
$ arp -an
ARP (IBM)

ICMP(Internet Control Message Protocol, 인터넷 제어 메시지 프로토콜)
패킷 전송에 실패했을 때 에러가 났음을 알림과 동시에, 해결 가능한 힌트를 제공하는 메시징 프로토콜.
ICMP (IBM) - 2021년 3월 3일

  • L3 체크 : ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인한다.
    ping은 ICMP를 사용한다.
  • ICMP (blog.naver) - 2016년 1월 19일
    ICMP는 TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜이다.
    IP에는 오로지 패킷을 목적지에 도달시키기 위한 내용들로만 구성되어 있다. 따라서 정상적으로 목적지 호스트에 도달하는 경우에는 IP에서 통신이 성공하고 종료되므로 아무런 문제가 없다. 그러나, 만일 전달해야 할 호스트가 꺼져 있거나, 선이 단절된 경우와 같은 비정상적인 경우에 이 패킷 전달을 의뢰한 출발지 호스트에 이러한 사실을 알려야하지만, IP에는 그러한 에러에 대한 처리 방법이 명시되어있지 않다. 이러한 IP의 부족한 점을 메꾸기 위하여 사용되는 것이 바로 ICMP 프로토콜이다.

    ICMP는 해당 호스트가 없거나, 해당 포트에 대기중에 서버 프로그램이 없는 등의 에러 상황이 발생할 경우 IP헤더에 기록되어 있는 출발지 호스트로 이러한 에러에 대한 상황을 보내주는 역할을 수행하게 된다.
    Destination Unreachable : 목적지에 도달하지 못함
    - Network Unreachable : Code 0
    - Host Unreachable : Code 1
    - Protocol Unreachable : Code 2
    - Port Unreachable : Code 3
    Time Exceeded : 시간이 오래 걸려 목적지에 도달하지 못함
Email 답글이 올라오면 이메일로 알려드리겠습니다.
Email redisgate@gmail.com Address 서울시 강남구 강남대로 342 역삼빌딩 5층 (역삼동) 우 06242 Telephone 02.503.2235 Copyright © 2014-2024 redisGate
All right reserved
혹시 처음이세요?
레디스게이트에는 레디스에 대한 많은 정보가 있습니다.
레디스 소개, 명령어, SQL, 클라이언트, 서버, 센티널, 클러스터 등이 있습니다.
혹시 필요한 정보를 찾기 어려우시면 redisgate@gmail.com로 메일 주세요.
제가 찾아서 알려드리겠습니다.
 
close
IP를 기반으로 보여집니다.