ADC 성능 지표 이해하기
소개
애플리케이션 딜리버리 서비스는 애플리케이션의 성공에 매우 중요합니다. 확장성, 안정성 또는 보안을 강화하는 이러한 서비스 중 하나 이상을 대부분의 애플리케이션이 사용합니다. 따라서 애플리케이션 딜리버리 컨트롤러(ADC)는 대부분의 애플리케이션, 클라우드 및 데이터 센터 설계에서 핵심적인 역할을 합니다.
프라이빗 클라우드 구축 환경을 비롯한 많은 환경에서는 여전히 전용 ADC 하드웨어가 애플리케이션 전송 서비스를 제공하기 위한 선호 플랫폼입니다. 전용 플랫폼은 제어 가능하고 안정적이며 일관된 리소스를 제공하기 때문입니다. 특정 용도에 맞게 설계된 전용 어플라이언스는 하이퍼바이저, 소프트웨어 또는 기반 컴퓨팅 플랫폼에 따른 편차가 없으며, 특수 하드웨어 구성 요소를 통해 CPU의 작업을 분산할 수 있다는 이점도 갖추고 있어 가장 까다로운 애플리케이션 워크로드에 필요한 성능과 안정성을 일관되게 제공할 수 있습니다.
그렇다면 "성능"이란 실제로 무엇을 의미할까요? 일반적으로 ADC 공급업체는 성능을 입증하기 위해 다음과 같은 네 가지 주요 유형의 지표를 공개합니다:
- 초당 요청 수(RPS)
- 초당 연결 수(CPS)
- 초당 트랜잭션 수(TPS)
- 처리량(일반적으로 초당 기가비트, Gbps로 측정)
제조업체는 처리량, SSL 트랜잭션 수, 동시 연결 수에 관한 표를 비롯해 이러한 특성과 기타 플랫폼 특성을 정리한 종합 데이터시트를 제공합니다. 올바른 플랫폼을 선택하려면 이러한 수치와 애플리케이션 워크로드 간의 관련성을 해석하고 시스템에서 예상되는 한계와 병목 현상을 이해하는 것이 필수적입니다. 공급업체의 데이터시트를 해석하고 애플리케이션과 관련된 지표를 이해하는 방법을 익히면 비즈니스에 적합한 플랫폼을 더욱 성공적으로 선택할 수 있습니다.
ADC는 어떤 역할을 하나요?
애플리케이션 전송 컨트롤러(ADC)는 애플리케이션 프록시 역할을 하는 인프라 구성 요소로, 트래픽 관리, 부하 분산, SSL 복호화, 애플리케이션 계층 보안, 애플리케이션 액세스 제어 등의 애플리케이션 전송 서비스를 제공합니다. 클라이언트 장치와 서비스가 ADC에 연결되면 ADC는 애플리케이션에 대한 별도의 연결을 생성하거나 기존 연결을 재사용합니다. ADC는 이렇게 형성된 논리적 간극에 애플리케이션 전송 서비스를 삽입합니다.
ADC의 워크로드를 이해하려면 TCP 연결과 애플리케이션 계층 요청을 살펴보는 것이 도움이 됩니다. ADC는 TCP 스택의 여러 계층에서 작업을 수행하고, 애플리케이션 트래픽에 애플리케이션 서비스를 제공하기 위한 다양한 활동을 처리해야 합니다. (그림 1 참조) 이로 인해 ADC 공급업체가 제시하는 성능 지표를 해석하기가 어려울 수 있습니다. 어떤 지표가 관련성이 있는지 파악하기 위한 핵심 전제 조건은 워크로드 유형을 식별하는 것입니다.
애플리케이션의 유형이 다양한 만큼 ADC 워크로드도 매우 다양합니다. 대부분의 프로덕션 배포 환경에는 여러 워크로드가 혼재하지만, 각 워크로드의 영향과 요구 사항에 따라 ADC에서 가장 많이 사용되는 구성 요소가 달라집니다. 동일한 구성 요소 내에서도 워크로드별 요구 사항은 서로 다릅니다. 어떤 워크로드는 지연 시간에 더 민감하고, 다른 워크로드는 지터에 더 민감할 수 있습니다. 또한 처리량 제한에 민감한 워크로드가 있는 반면, 가용성에 더 크게 의존하는 워크로드도 있습니다.
다음은 가장 일반적인 워크로드와 이를 지원하는 주요 지표입니다:
- 현재 웹사이트와 많은 모바일 애플리케이션에서 가장 일반적으로 사용되는 워크로드는 트랜잭션 기반 HTTP 웹 애플리케이션이며, SSL과 TLS를 사용하는 경우가 많습니다. 이 워크로드에서 가장 중요한 메트릭은 RPS, TPS, 처리량을 비롯한 모든 SSL 메트릭과 계층 7 RPS 및 CPS입니다.
- DNS는 거의 모든 인터넷 통신에서 사용되는 또 다른 일반적인 워크로드입니다. DNS는 사용 빈도가 높지만 트래픽 양은 적으며, 일반적으로 TCP 대신 UDP를 사용하여 배포됩니다. 따라서 가장 중요한 메트릭은 계층 3 및 계층 4 처리량입니다.
- REST API의 사용은 빠르게 증가하고 있으며, 서비스에 공통적으로 사용되는 API 전송 방식을 의미합니다. 따라서 REST API는 시스템 간 통신에 자주 사용됩니다. REST API는 HTTP를 기반으로 하므로 주요 메트릭은 HTTP의 경우와 동일하며, 모든 SSL 메트릭인 RPS, TPS, 처리량과 계층 7 RPS 및 CPS가 포함됩니다.
- MQTT는 다양한 용도로 활용되는 새로운 메시징 프로토콜로, 사물 인터넷(IoT) 통신 분야에서 빠르게 성장하고 있습니다. REST API와 마찬가지로 MQTT는 주로 시스템 간 통신 애플리케이션에 사용됩니다. MQTT의 주요 지표는 레이어 4 CPS와 처리량입니다.
- Diameter는 계층 4에서 작동하며 TCP 연결을 장시간 유지하는 RADIUS 인증 프로토콜의 대체 프로토콜입니다. 주요 지표는 계층 4 CPS와 계층 4 연결 테이블의 견고성입니다.
- FIX, SAIL, OUCH와 같은 금융 거래 프로토콜은 계층 4와 계층 7 모두에서 지연 시간에 민감합니다. 따라서 주요 지표는 계층 4 CPS와 계층 7 RPS 및 CPS입니다.
- WebSockets 기술은 비교적 최근에 추가된 워크로드 유형으로, 서버가 장시간 유지되는 계층 4 및 계층 7 연결을 통해 클라이언트와의 통신을 시작할 수 있습니다. 주요 지표는 계층 4 CPS, 계층 7 RPS 및 CPS, 그리고 계층 4 및 계층 7 연결 테이블의 견고성입니다.
- 로깅 및 알림 워크로드는 모두 계층 4에서 작동하며, 일부는 계층 7에서 작동하는 REST API를 기반으로 합니다. 따라서 주요 메트릭은 계층 4 CPS이며, REST API 기반 워크로드의 경우 계층 7 RPS 및 CPS도 주요 메트릭입니다.
워크로드 구성은 계속 진화하고 새로운 워크로드도 끊임없이 도입되고 있으며, 각 워크로드에는 주요 작업을 기준으로 한 고유의 핵심 ADC 메트릭이 있습니다.
성능 지표와 해석 방법
모든 네트워크 장치의 처리량은 네트워크 트래픽 처리로 인해 발생하는 지연 시간의 영향을 받습니다. 최소한 빛의 속도로 인해 구리선을 통과하는 전기 신호나 광섬유를 통과하는 광 신호에는 일정 수준 이상의 지연 시간이 발생합니다. 그러나 ADC는 단순히 유선이나 광섬유를 통해 데이터를 전송하는 것 외에도 네트워크 트래픽에 대해 여러 작업을 수행합니다. ADC의 최대 성능은 병렬로 수행되지 않는 직렬 작업의 지연 시간을 모두 합한 값에 따라 결정됩니다. 다행히 많은 작업이 병렬로 수행되지만, 이러한 작업을 수행하는 데 필요한 시간은 여전히 전체 처리량을 제한하는 요인입니다. ADC 설계의 목표 중 하나는 이러한 지연 시간을 최소화하여 처리량을 극대화하는 것입니다.
특정 ADC의 성능을 평가하고 이를 특정 배포 환경에 맞추는 작업은 쉽지 않을 수 있습니다. 네트워킹 공급업체는 다른 지표를 희생하면서 특정 지표를 극대화하도록 설계된 테스트를 바탕으로 성능 수치를 발표합니다. 이러한 접근 방식의 목적은 아키텍처 설계와 의사 결정에 참고할 수 있는 유용한 수치를 제공하는 것이지만, 공급업체도 발표된 모든 수치가 동시에 충족되지는 않는다는 점을 알고 있습니다. 자동차에 비유하면, Toyota는 2017년형 Camry 기본 모델이 178마력의 출력과 고속도로에서 갤런당 33마일의 연비를 낸다고 광고하지만, 엔진 회전수가 6,000RPM일 때 가속 페달을 끝까지 밟아 178마력의 최대 출력을 내면서 동시에 갤런당 33마일의 연비를 달성할 것이라고 기대하는 것은 무리입니다. 이와 마찬가지로 네트워킹 공급업체는 각 성능 지표에 대해 최상의 조건을 적용한 개별 수치를 제시합니다. 일반적으로 발표된 여러 성능 지표를 동시에 재현하는 것은 불가능합니다.
메트릭과 OSI 계층 간의 관계
공개된 일부 메트릭은 서로 다른 처리 계층에 적용될 수 있습니다. 예를 들어 초당 요청 수는 OSI 계층 2(L2) 또는 OSI 계층 7(L7)의 처리 성능을 나타낼 수 있습니다. 반면 TPS는 대개 SSL 키 협상만을 의미하며, 계층 7의 초당 요청 수는 설정된 SSL 세션을 사용하는 후속 암호화 요청을 의미합니다. 워크로드에 따라 ADC의 여러 처리 구성 요소에 가해지는 부하가 달라집니다. ADC의 공개 메트릭과 관련해 또 하나 주목해야 할 점은 워크로드마다 서로 다른 성능 한계에 도달한다는 것입니다.
각 OSI 네트워크 계층에는 해당 계층에서 가장 일반적으로 제시되는 여러 지표가 있습니다. 예를 들어, 계층 4 지표는 초당 연결 수로 표시되는 경우가 많으며, 계층 4 처리량을 나타내는 다른 지표도 있습니다. OSI 계층 5와 6은 IP 스택에 명확하게 대응하지 않지만, SSL/TLS 및 압축과 같은 서비스는 계층 5와 6에 해당한다고 볼 수 있습니다. 앞서 언급했듯이 이러한 각 지표에 대한 테스트는 해당 지표에 부하를 주도록 설계된 트래픽을 사용해 수행되는 경우가 많으므로 실제 환경의 트래픽 부하를 나타내지는 않습니다. 예를 들어, 최대 SSL TPS는 길이가 0인 SSL 페이로드를 사용한 테스트에서 측정됩니다. 이 경우 SSL 데이터를 복호화하는 데 ADC 처리 시간이 소요되지 않기 때문입니다. 이는 SSL 하드웨어의 성능만 측정하는 데는 적합하지만, 실제 운영 애플리케이션에서 길이가 0인 페이로드를 전송하는 경우는 없습니다. 마찬가지로 계층 2 처리량은 SSL을 활성화하지 않고 계층 7 처리도 수행하지 않은 상태에서 테스트됩니다. 이러한 기능은 ADC의 속도를 저하시키기 때문입니다. 하지만 실제 운영 환경에서는 이러한 기능을 사용하는 경우가 많습니다. 대부분의 ADC 지표는 개별적으로 테스트되지만, 대부분의 운영 환경에서는 여러 ADC 기능을 함께 사용하며 각 지표는 서로 다른 구성 요소 또는 구성 요소 조합에 부하를 줍니다. 관련 구성 요소로는 CPU, 네트워크 인터페이스 카드(NIC), 주문형 반도체(ASIC), 필드 프로그래머블 게이트 어레이(FPGA) 등이 있습니다. ADC에 특정 구성 요소가 없는 경우에는 CPU가 대신 사용됩니다.
패킷 메트릭은 ADC가 초당 처리할 수 있는 패킷 수를 나타내며, 이 처리로 인해 가장 큰 부하를 받는 구성 요소는 계층마다 다릅니다. 예를 들어, 계층 2 패킷을 처리할 때는 주로 네트워크 인터페이스 카드(NIC)에 부하가 집중되는 반면, 계층 4 패킷을 처리할 때는 주로 FPGA에 부하가 집중됩니다. 모든 계층에서 처리량 메트릭은 초당 기가비트 단위의 총 가용 처리량을 의미하며, 연결 메트릭은 해당 계층에서 초당 생성할 수 있는 연결 수를 측정합니다. 예를 들어, 계층 4 연결 메트릭은 초당 설정할 수 있는 TCP 연결 수를 측정합니다.
SSL 처리 메트릭
SSL 처리는 여러 연결에 걸쳐 세션이 설정되고 관리된다는 점에서 고유합니다. 하나의 연결에서 SSL 세션을 설정할 수 있으며(이를 트랜잭션이라고 함), 이후 연결에서는 SSL 세션을 재사용할 수 있습니다(이를 요청이라고 함). 따라서 트랜잭션과 요청 메트릭은 별도로 표시됩니다. SSL 트랜잭션은 이후의 SSL 요청보다 훨씬 오래 걸리므로 처리량 성능을 제한하는 수치는 대개 트랜잭션 메트릭입니다. SSL 세션이 설정된 후 후속 요청이 이루어지면 데이터 페이로드를 암호화하거나 복호화해야 합니다. 암호화 ASIC이 암호화와 복호화를 처리하며, 성능은 처리량 메트릭으로 측정됩니다.
데이터 페이로드를 압축하는 것이 유용한 경우가 많습니다. 압축은 압축 ASIC에서 수행되며, 이 역시 처리량을 지표로 사용합니다.
애플리케이션 계층 처리
마지막으로, 계층 7은 복잡하고 다양한 트래픽 관리 옵션을 제공하기 때문에 모든 처리가 CPU를 통해 수행된다는 점에서 고유합니다. 쿠키 지속성은 각 사용자 세션을 풀의 특정 서버에 연결하는 일반적인 계층 7 기능으로, CPU에서 처리됩니다. 계층 7 요청 메트릭은 ADC가 초당 처리할 수 있는 계층 7 요청 수를 나타냅니다. 마찬가지로 계층 7 처리량 메트릭은 계층 7에서 가능한 총 처리량을 나타냅니다.
마지막으로, 연결 상태를 유지해야 하는 모든 계층에서는 ADC가 연결 테이블을 관리해야 합니다. 연결 테이블은 계층 4 TCP 연결, SSL 세션 및 계층 7 HTTP 세션에서 일반적으로 사용됩니다. 연결이 장시간 유지되는 프로토콜은 ADC 연결 테이블의 용량을 소진하거나 과부하를 유발할 수 있습니다.
각 메트릭은 성능의 특정 측면을 파악하는 데 도움이 됩니다. 각 계층에서 수행되는 다양한 작업과 이러한 작업의 영향을 받는 구성 요소를 이해하면 특정 배포 환경의 ADC 성능 메트릭을 평가하는 데 도움이 됩니다.
특수 목적 하드웨어와 성능
ADC의 모든 기능은 CPU로 구현할 수 있습니다. 실제로 많은 ADC 하드웨어 공급업체가 소프트웨어 전용 버전을 제공합니다. 이는 CPU가 사용 가능한 하드웨어 중 가장 유연한 유형으로, 거의 모든 데이터 중심 작업을 수행할 수 있기 때문입니다.
하지만 ADC의 모든 기능을 CPU에 맡기는 데에는 한계가 있습니다. 네트워크 트래픽을 처리하는 세 가지 주요 하드웨어 유형인 CPU, ASIC, FPGA 중 CPU는 가장 느리고, 메모리와 메모리 컨트롤러의 지원이 필요하므로 비용도 가장 많이 든다고 볼 수 있습니다. 네트워크 트래픽을 처리하는 나머지 두 가지 하드웨어 유형은 ASIC과 FPGA입니다. ASIC은 이름에서 알 수 있듯이 특정 작업을 수행하도록 설계됩니다. 특정 작업을 수행하는 데 ASIC보다 빠른 하드웨어 유형은 없지만, 그 기능은 칩에 설계된 범위로 제한됩니다. 애플리케이션에 ASIC이 제공하지 않는 기능이 필요한 경우에는 CPU를 사용하여 소프트웨어로 해당 작업을 수행해야 합니다.
CPU가 유연하지만 느리고 ASIC이 유연하지 않지만 빠르다면, 그 중간에는 세 번째 기술인 FPGA가 있습니다. FPGA는 ASIC보다는 느리지만 CPU보다는 훨씬 빠르며, FPGA 설계자가 미처 예상하지 못한 작업도 수행하도록 프로그래밍할 수 있습니다.
잘 설계된 ADC는 각 하드웨어 유형의 역량을 최대한 활용합니다. 일반적이고 단순한 작업은 ASIC 구성 요소에 맡기고, 더 복잡한 작업은 FPGA 구성 요소에서 수행하며, 가장 복잡하고 빈도가 낮은 작업은 CPU에서 처리합니다. ADC의 뛰어난 엔지니어링 기술은 다양한 워크로드를 가장 효율적으로 처리할 수 있도록 서로 다른 유형의 구성 요소를 조율하는 데서 비롯됩니다.
ADC에서 수행되는 작업 중 단연 가장 빈번한 것은 네트워크 인터페이스에서의 패킷 처리입니다. 일반적인 상용 NIC는 대량의 인바운드 트래픽(예: 데스크톱이나 기타 사용자 장치)에 맞게 조정되거나, 대량의 아웃바운드 트래픽(예: 서버)에 맞게 조정됩니다. ADC는 양방향 모두에서 최대 처리량을 내도록 조정된 NIC가 필요하다는 점에서 독특합니다. 양방향 최대 처리량을 목표로 설계된 상용 NIC는 없습니다. ADC의 패킷 처리는 빈번하면서도 비교적 단순한 작업이므로 ASIC에 매우 적합합니다. 클러스터형 ADC 환경에서는 디스어그리게이터(DAG) ASIC가 프런트엔드 로드 밸런서 역할을 하여 동일한 클라이언트 및 서버 세션이 항상 같은 클러스터 노드를 통과하도록 보장합니다. 클러스터 환경에서 DAG를 사용하면 트래픽 수요에 맞춰 ADC 어플라이언스를 수평으로 확장하기가 쉬워집니다. 적절하게 설계된 ADC에서는 모든 계층 2 패킷 처리와 스위칭을 특수 ASIC 하드웨어에서 수행할 수 있습니다.
계층 3 및 4의 처리 작업은 더 복잡하므로 FPGA에 적합합니다. FPGA는 라우팅 기능뿐만 아니라 TCP SYN 쿠키를 포함한 방화벽 및 분산 서비스 거부(DDoS) 방어 기능도 제공할 수 있습니다. 이 수준에서 FPGA를 사용하면 계층 4 처리 및 보호가 가능해져, 추가 처리 대상으로 고려되는 트래픽이 올바르게 재조립되고 필터링되도록 보장할 수 있습니다.
SSL 또는 TLS와 같은 암호화 및 압축 처리와 HTTP/2에서 새롭게 도입된 기능 역시 전용 하드웨어의 활용 분야입니다. 암호화 처리에는 특수 ASIC이 사용되는 경우가 많으며, 여기에는 타원 곡선 디피-헬먼 암호화(ECDHE)와 같은 최신 암호화 방식에서 연산 집약적인 SSL 키 협상도 포함됩니다. SSL 키 협상이 완료되면 이후 요청에 대한 대량 암호화 및 복호화 역시 ASIC 하드웨어에서 처리할 수 있습니다. 마찬가지로 일반적인 알고리즘을 사용하는 압축 및 압축 해제도 ASIC 하드웨어에서 수행할 수 있습니다. 전용 ASIC 구성 요소를 사용하면 암호화 및 압축을 빠르게 처리할 수 있습니다.
ASIC 및 FPGA에서 처리되지 않은 나머지 네트워크 트래픽은 모두 CPU에서 처리해야 합니다. CPU는 ASIC 및 FPGA에 비해 느리지만 ADC에서 가장 유연한 구성 요소입니다. 또한 GUI 및 기타 구성 작업, I/O 인터럽트 처리, 디스크 요청 처리 등 네트워크 처리와 무관한 작업도 담당합니다. CPU의 부하는 지연 시간에 따라 달라질 수 있고 CPU는 네트워크 트래픽을 처리하는 마지막 하드웨어이므로, ADC는 의도적으로 CPU에 할당되는 트래픽 처리량을 최소화하고 가능한 한 많은 작업을 더 빠른 ASIC 및 FPGA에서 처리하도록 설계됩니다.
결론
공급업체가 공개한 지표를 실제 환경의 성능으로 환산하기는 어려울 수 있습니다. 다양한 유형의 워크로드와 각 워크로드가 소비하는 리소스, 하드웨어 플랫폼의 성능 간 상호 작용을 이해하는 일은 복잡하지만, 조직에 가장 적합한 구매 결정을 내리는 데 도움이 될 수 있습니다.
공개된 데이터시트와 기타 자료를 활용하면 적합한 플랫폼을 보다 쉽게 선정할 수 있지만, 가능하면 공급업체의 경험과 전문 지식을 직접 활용하는 것도 중요합니다. 선도적인 공급업체는 워크로드에 적합한 플랫폼을 선정하는 데 풍부한 전문 지식을 갖추고 있으며, 고객은 이러한 전문 지식을 손쉽게 활용할 수 있어야 합니다.
애플리케이션 트래픽의 특성과 플랫폼 기능을 충분히 이해하고 공급업체의 전문 지식을 활용하면 플랫폼을 과소 또는 과다 프로비저닝할 위험과 그에 따른 잠재적 비용을 줄일 수 있습니다.
2017년 3월 28일 게시