ADC 성능 지표 이해

성공적인 애플리케이션을 위해서는 애플리케이션 전달 서비스가 중요합니다. 이러한 서비스가 확장성, 안정성 또는 보안을 추가하는지 여부에 관계없이 대부분의 애플리케이션은 하나 이상에 의존합니다. 따라서 애플리케이션 전송 컨트롤러(ADC)는 대부분의 애플리케이션, 클라우드, 데이터 센터 설계에서 중요한 위치를 차지합니다.

프라이빗 클라우드 설치를 포함한 많은 환경에서는 전용 ADC 하드웨어가 여전히 애플리케이션 전송 서비스를 제공하는 데 선호되는 플랫폼입니다. 전용 플랫폼에는 통제되고 안정적이며 일관된 리소스가 통합되어 있기 때문입니다. 전용으로 제작된 어플라이언스는 하이퍼바이저, 소프트웨어 또는 기본 컴퓨팅 플랫폼에 변형이 없고, CPU에서 작업을 오프로드하는 특수 하드웨어 구성 요소의 이점이 있으므로 가장 까다로운 애플리케이션 작업 부하에도 필요한 성능과 안정성을 지속적으로 제공할 수 있습니다.

하지만 "성능"은 실제로 무엇을 뜻할까? 일반적으로 ADC 공급업체는 성능을 입증하기 위해 4가지 주요 유형의 메트릭을 게시합니다.

• 초당 요청(RPS)
• 초당 연결(CPS)
• 초당 거래(TPS)
• 처리량(종종 초당 기가비트, Gbps로 측정)

제조업체는 처리량, SSL 거래 수, 동시 연결 표를 포함하여 이러한 특성과 기타 플랫폼 특성을 나열한 포괄적인 데이터 시트를 제공합니다. 이러한 숫자를 해석하고 애플리케이션 작업 부하와의 관련성을 파악하며, 시스템의 한계와 병목 현상의 가능성을 파악하는 것은 올바른 플랫폼을 선택하는 데 필수적입니다. 공급업체 데이터 시트를 해석하고 애플리케이션과 관련된 측정항목을 이해하는 방법을 배우면 비즈니스에 맞는 올바른 플랫폼을 선택하는 데 더욱 성공할 수 있습니다.

애플리케이션 전송 컨트롤러는 애플리케이션 프록시 역할을 하는 인프라 구성 요소로, 트래픽 관리, 부하 분산, SSL 복호화, 애플리케이션 계층 보안, 애플리케이션 액세스 제어 등의 애플리케이션 전송 서비스를 제공합니다. 클라이언트 장치와 서비스는 ADC에 연결되고, ADC는 애플리케이션에 대한 별도의 연결을 생성하거나 기존 연결을 재사용합니다. 이러한 논리적 간격에 ADC는 애플리케이션 전송 서비스를 삽입합니다.

ADC의 작업 부하를 이해하려면 TCP 연결과 애플리케이션 계층 요청을 살펴보는 것이 좋습니다. ADC는 TCP 스택의 여러 계층에서 작업을 수행하고 애플리케이션 트래픽에 대한 애플리케이션 서비스를 제공하기 위해 여러 가지 활동을 수행해야 합니다. (그림 1 참조) 이로 인해 ADC 공급업체의 성능 지표를 해석하는 것이 어려울 수 있습니다. 어떤 측정 항목이 관련성이 있는지 이해하기 위한 핵심 전제 조건은 작업 부하 유형을 식별하는 것입니다.

다양한 유형의 애플리케이션이 있으므로 ADC 작업 부하도 다양합니다. 대부분의 프로덕션 배포에는 여러 가지 워크로드가 섞여 있지만, 각 워크로드의 영향과 요구 사항에 따라 ADC의 어떤 구성 요소가 가장 많이 활용될지가 결정됩니다. 구성 요소 내에서도 작업 부하 요구 사항은 다양합니다. 일부 작업 부하는 지연 시간에 더 민감하고, 다른 작업 부하는 지터에 더 민감합니다. 일부 작업 부하는 처리량 제한에 민감하고, 일부 작업 부하는 가용성에 더 많이 의존합니다.

가장 일반적인 작업 부하와 이를 지원하는 주요 지표는 다음과 같습니다.

• 현재 웹사이트와 많은 모바일 애플리케이션에서 가장 일반적으로 사용되는 작업 부하는 SSL과 TLS를 사용하는 경우가 많은 트랜잭션 HTTP 웹 애플리케이션입니다. 이 작업 부하에 대한 가장 중요한 메트릭은 모든 SSL 메트릭입니다. RPS, TPS 및 처리량, 그리고 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입니다.
• 웹소켓 기술은 워크로드 유형에 비교적 최근에 추가된 기술로, 서버가 장시간 지속되는 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의 성능을 평가하고 이를 특정 배포에 맞추려고 시도하는 것은 어려울 수 있습니다. 네트워킹 공급업체는 다른 지표를 희생하고 특정 지표를 극대화하려는 테스트를 기반으로 한 지표를 게시합니다. 이러한 접근 방식의 이유는 아키텍처와 의사 결정의 지침이 될 수 있는 유용한 숫자를 게시하기 위한 것이지만, 공급업체는 게시된 모든 숫자가 동시에 사실이 되는 것은 아니라는 점을 알고 있습니다. 자동차 비유를 사용하면: 토요타는 2017년형 캠리 기본 모델이 고속도로에서 178마력, 33MPG의 연비를 달성한다고 광고합니다. 하지만 이 차량이 6,000RPM에서 가속 페달을 밟고 동시에 33MPG의 연비를 달성하면서 최대 178마력을 낼 수 있기를 기대하는 것은 무리입니다. 마찬가지로, 네트워크 공급업체는 각각의 성능 지표를 최상의 시나리오를 사용하여 보여줍니다. 일반적으로 공개된 성과 지표 중 다수는 동시에 재현할 수 없습니다.

공개된 지표 중 일부는 다양한 수준의 처리에 적용될 수 있습니다. 예를 들어, 초당 요청 수는 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인 페이로드를 전송하지 않습니다. 마찬가지로, SSL을 활성화하지 않고 계층 7 처리를 사용하지 않는 경우 2계층 처리량이 테스트됩니다. 이렇게 하면 ADC 속도가 느려지지만, 많은 프로덕션 배포에서는 이러한 기능을 사용합니다. 대부분의 ADC 지표는 단독으로 테스트되지만, 대부분의 프로덕션 환경에서는 ADC 기능을 조합하여 사용하고 각 지표는 다른 구성 요소나 구성 요소 조합에 중점을 둡니다. 관련 구성 요소에는 CPU, 네트워크 인터페이스 카드(NIC), ASIC(Application-Specific Integrated Circuit), FPGA(Field-Programmable Gate Array) 등이 포함될 수 있습니다. ADC에 특정 구성요소가 없는 경우 대신 CPU를 사용합니다.

패킷 메트릭은 ADC가 초당 처리할 수 있는 패킷 수를 나타내며, 이 처리로 인해 가장 많은 부담을 받는 구성 요소는 계층마다 다릅니다. 예를 들어, 2계층 패킷을 처리하면 주로 네트워크 인터페이스 카드(NIC)에 부담이 가해지고, 4계층 패킷을 처리하면 주로 FPGA에 부담이 가해집니다. 모든 계층의 처리량 지표는 초당 기가비트 단위로 사용 가능한 총 처리량을 나타내는 반면, 연결 지표는 특정 계층에서 초당 만들 수 있는 연결 수를 측정합니다. 예를 들어, 4계층 연결 메트릭은 초당 설정할 수 있는 TCP 연결 수를 측정합니다.

SSL 처리의 독특한 점은 세션이 여러 연결을 통해 설정되고 관리된다는 것입니다. 하나의 연결은 SSL 세션(트랜잭션이라고 함)을 설정할 수 있고, 이후의 연결은 SSL 세션(요청이라고 함)을 재사용할 수 있습니다. 따라서 거래 및 요청 메트릭은 별도로 나열됩니다. SSL 트랜잭션은 후속 SSL 요청보다 훨씬 더 길기 때문에 처리량 성능의 한계 숫자는 종종 트랜잭션 지표입니다. SSL 세션이 설정되고 후속 요청이 이루어지면 데이터 페이로드를 암호화하거나 복호화해야 합니다. 암호화 ASIC은 암호화와 복호화를 처리하며, 성능은 처리량 지표로 측정됩니다.

종종 데이터 페이로드를 압축하는 것이 유용합니다. 압축은 압축 ASIC에 의해 수행되며 그 측정 기준은 처리량입니다.

마지막으로, 7계층은 복잡하고 다양한 트래픽 관리 옵션이 주어졌을 때 모든 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에서 처리해야 합니다. ASIC 및 FPGA에 비해 느리지만 CPU는 ADC에서 가장 유연한 구성 요소입니다. CPU는 또한 GUI 및 기타 구성 업무, I/O 인터럽트 처리 또는 디스크 요청 처리와 같은 네트워크 처리와 관련 없는 작업을 담당합니다. CPU에 대한 요구는 지연 시간에 따라 달라질 수 있고, CPU는 네트워크 트래픽을 처리하는 마지막 하드웨어 유형이기 때문에 ADC는 가능한 한 적은 트래픽 처리를 CPU에 맡기고 대신 더 빠른 ASIC 및 FPGA에서 가능한 한 많은 트래픽 처리를 처리하도록 의도적으로 설계되었습니다.

공급업체가 공개한 지표를 실제 성과로 변환하는 것은 어려울 수 있습니다. 다양한 유형의 작업 부하, 이러한 작업 부하가 소모하는 리소스, 하드웨어 플랫폼의 기능 간의 상호 작용을 이해하면(복잡하긴 하지만) 조직에 가장 적합한 구매 결정을 내리는 데 도움이 될 수 있습니다.

공개된 데이터 시트와 기타 리소스를 활용하면 적합한 플랫폼을 보다 쉽게 지정할 수 있지만, 가능한 한 공급업체의 경험과 전문 지식에 직접 의존하는 것도 중요합니다. 선도적인 공급업체는 플랫폼에 맞게 워크로드를 매칭하는 데 깊은 전문 지식을 갖고 있으며, 이러한 전문 지식은 고객이 쉽게 이용할 수 있어야 합니다.

애플리케이션 트래픽 특성과 플랫폼 기능에 대한 충분한 이해와 공급업체의 전문 지식을 결합하면 플랫폼의 프로비저닝이 부족하거나 과도하게 되어 발생하는 위험과 잠재적 비용을 줄일 수 있습니다.