성능 튜닝을 위한 Nitro 시스템 고려 사항

성능 튜닝을 위한 Nitro 시스템 고려 사항 (Nitro system considerations for performance tuning)

Nitro System은 AWS가 구축한 하드웨어·소프트웨어 컴포넌트의 모음으로, 높은 성능, 높은 가용성, 높은 보안을 가능하게 해요. Nitro System은 가상화 오버헤드를 제거하고 호스트 하드웨어에 대한 전체 접근이 필요한 워크로드를 지원하는 베어 메탈에 가까운 능력을 제공해요.

출처: 문서

본문

모든 현재 세대 EC2 인스턴스 유형은 EC2 Nitro Cards에서 네트워크 패킷 처리를 수행해요. 이 주제는 Nitro 카드에서의 높은 수준의 패킷 처리, 패킷 처리 성능에 영향을 주는 네트워크 아키텍처·구성의 일반적인 측면, 그리고 Nitro 기반 인스턴스에서 최고 성능을 달성하기 위해 취할 수 있는 조치를 다뤄요.

Nitro Cards는 VPC에 필요한 것 같은 모든 입출력(I/O) 인터페이스를 처리해요. 네트워크를 통해 정보를 보내거나 받는 모든 컴포넌트에 대해 Nitro 카드는 고객 워크로드가 실행되는 시스템 메인 보드와 물리적으로 분리된, I/O 트래픽용 자체 컴퓨팅 장치로 동작해요.

Nitro 카드에서의 네트워크 패킷 흐름

Nitro 시스템 기반 EC2 인스턴스는 초당 패킷 수(PPS) 처리량으로 측정되는 더 빠른 패킷 처리 기능을 가진 하드웨어 가속 능력을 가져요. Nitro 카드가 새 플로우에 대한 초기 평가를 수행할 때 보안 그룹, 접근 제어 목록, 라우트 테이블 항목처럼 플로우의 모든 패킷에서 동일한 정보를 저장해요. 같은 플로우의 추가 패킷을 처리할 때는 저장된 정보를 사용해 해당 패킷의 오버헤드를 줄일 수 있어요.

연결 속도는 초당 연결 수(CPS) 지표로 측정돼요. 각 새 연결은 워크로드 능력 추정치에 반영해야 하는 추가 처리 오버헤드를 필요로 해요. 워크로드를 설계할 때 CPS와 PPS 지표를 모두 고려하는 것이 중요해요.

연결이 수립되는 방식

Nitro 기반 인스턴스와 다른 엔드포인트 사이에 연결이 수립되면 Nitro 카드가 두 엔드포인트 사이에서 보내거나 받는 첫 번째 패킷에 대해 전체 플로우를 평가해요. 같은 플로우의 후속 패킷은 보통 전체 재평가가 필요하지 않아요. 다만 예외가 있어요.

다음 다섯 가지 속성이 두 엔드포인트와 그 사이의 패킷 흐름을 정의해요. 이 다섯 속성을 함께 5-tuple flow라고 불러요.

  • 소스 IP
  • 소스 포트
  • 대상 IP
  • 대상 포트
  • 통신 프로토콜

패킷 흐름의 방향을 ingress(인바운드)와 egress(아웃바운드)라고 해요.

  • Ingress – Nitro 카드가 인바운드 네트워크 패킷을 처리할 때 상태 저장 방화벽 규칙과 접근 제어 목록에 대해 패킷을 평가해요. 연결을 추적하고, 측정하고, 해당되는 다른 작업을 수행한 뒤 패킷을 호스트 CPU의 대상으로 전달해요.
  • Egress – Nitro 카드가 아웃바운드 네트워크 패킷을 처리할 때 원격 인터페이스 대상을 조회하고, 다양한 VPC 기능을 평가하고, 속도 제한을 적용하고, 해당되는 다른 작업을 수행한 뒤 패킷을 네트워크의 다음 홉 대상으로 전달해요.

최적 성능을 위한 네트워크 설계

Nitro 시스템의 성능 능력을 활용하려면 네트워크 처리 요구사항과 그 요구사항이 Nitro 리소스 워크로드에 미치는 영향을 이해해야 해요. 인프라 설정과 애플리케이션 워크로드 설계·구성은 패킷 처리와 연결 속도 모두에 영향을 줄 수 있어요. 예를 들어 DNS 서비스, 방화벽, 가상 라우터 같은 높은 연결 수립 속도를 가진 애플리케이션은 연결이 수립된 후에만 발생하는 하드웨어 가속을 활용할 기회가 더 적어요.

애플리케이션·인프라 설정을 구성해 워크로드를 간소화하고 네트워크 성능을 개선할 수 있어요. 다만 모든 패킷이 가속 대상이 되지는 않아요. Nitro 시스템은 새 연결과 가속 대상이 아닌 패킷에 대해 전체 네트워크 플로우를 사용해요.

인프라 고려 사항

비대칭 네트워크 인터페이스 구성 – 보안 그룹은 연결 추적을 사용해 인스턴스로 들어오고 나가는 트래픽 정보를 추적해요. 트래픽이 한 네트워크 인터페이스로 들어와 다른 인터페이스로 나가는 비대칭 라우팅은, 플로우가 추적되는 경우 인스턴스가 달성할 수 있는 최고 성능을 줄일 수 있어요.

네트워크 드라이버 – 네트워크 드라이버는 정기적으로 업데이트·출시돼요. 드라이버가 오래되면 성능이 크게 저하될 수 있어요. 최신 세대 드라이버에서만 사용 가능한 가속 경로(accelerated path) 기능 같은 성능 개선을 활용하려면 드라이버를 최신으로 유지하세요. 가속 경로 기능을 활용하려면 인스턴스에 최신 ENA 드라이버를 설치할 것을 권장해요.

  • Linux – ENA Linux 드라이버 2.2.9 이상.
  • Windows – ENA Windows 드라이버 2.0.0 이상.

엔드포인트 사이의 거리 – 같은 가용 영역의 두 인스턴스 간 연결은 애플리케이션 계층의 TCP 윈도잉(어느 시점에 얼마나 많은 데이터가 전송 중일 수 있는지 결정) 때문에 리전 간 연결보다 더 많은 초당 패킷을 처리할 수 있어요. 인스턴스 사이의 거리가 길어지면 지연 시간이 늘고 엔드포인트가 처리할 수 있는 패킷 수가 줄어요.

바이트 큐 제한(BQL) – BQL은 큐잉을 줄이기 위해 Nitro 카드에 전달되는 바이트 수를 제한하는 기능이에요. BQL은 ENA 드라이버, Amazon Linux OS, 대부분의 Linux 배포판에서 기본적으로 비활성화돼 있어요. BQL과 프래그먼트 프록시 오버라이드가 모두 활성화되면 모든 프래그먼트가 처리되기 전에 Nitro에 전달되는 바이트 수를 제한해 성능 제한이 발생할 수 있어요.

애플리케이션 설계 고려 사항

패킷 크기 – 더 큰 패킷 크기는 인스턴스가 네트워크에서 보내고 받을 수 있는 데이터 처리량을 늘릴 수 있어요. Amazon EC2는 9001 바이트의 점보 프레임을 지원하지만 다른 서비스는 다른 제한을 적용할 수 있어요. 더 작은 패킷 크기는 패킷 처리 속도를 높일 수 있지만, 패킷 수가 PPS 허용량을 초과하면 최대 달성 대역폭이 줄어들 수 있어요.

패킷 크기가 네트워크 홉의 MTU를 초과하면 경로상의 라우터가 패킷을 프래그먼트할 수 있어요. 결과 프래그먼트는 예외로 간주되어 보통 표준 속도로(가속되지 않게) 처리돼요. 다만 프래그먼트 프록시 모드 설정으로 아웃바운드 프래그먼트 패킷의 표준 동작을 오버라이드할 수 있어요. MTU를 구성할 때 토폴로지를 평가할 것을 권장해요.

프로토콜 트레이드오프 – TCP 같은 신뢰성 있는 프로토콜은 UDP 같은 신뢰성 없는 프로토콜보다 오버헤드가 더 커요. UDP 전송 프로토콜의 낮은 오버헤드와 단순화된 네트워크 처리는 더 높은 PPS 속도를 낼 수 있지만, 신뢰성 있는 패킷 전달을 희생해요. 애플리케이션에 신뢰성 있는 패킷 전달이 중요하지 않다면 UDP가 좋은 선택일 수 있어요.

마이크로 버스팅(Micro-bursting) – 트래픽이 고르게 분산되지 않고 짧은 기간 동안 허용량을 초과할 때 발생해요. 보통 마이크로초 규모로 발생해요. 예를 들어 10 Gbps까지 보낼 수 있는 인스턴스에서 애플리케이션이 0.5초 만에 전체 10Gb를 보내면, 이 마이크로 버스트가 전반부에서 허용량을 초과하고 나머지 후반에는 남는 것이 없어요. Linux Traffic Control 같은 네트워크 스케줄러로 처리량을 배치하면 마이크로 버스팅으로 인한 큐잉·드롭을 피할 수 있어요.

플로우 수 – 단일 플로우는 클러스터 배치 그룹 내부(최대 10 Gbps 지원)에 있거나 ENA Express를 사용하지 않는 한(최대 25 Gbps 지원) 5 Gbps로 제한돼요. Nitro 카드는 단일 플로우 대신 여러 플로우에 걸쳐 더 많은 패킷을 처리할 수 있어요. 인스턴스당 최고 패킷 처리 속도를 달성하려면 총 대역폭이 100 Gbps 이상인 인스턴스에서 최소 100개의 플로우를 사용할 것을 권장해요. 벤치마킹이 최고 속도 달성에 필요한 구성을 결정하는 데 도움이 돼요.

ENA(Elastic Network Adapter) 큐 – ENA는 여러 수신(Rx)·전송(Tx) 큐(ENA queues)를 사용해 EC2 인스턴스의 네트워크 성능과 확장성을 개선해요. 이 큐는 사용 가능한 큐에 보내고 받는 데이터를 부하 분산해 네트워크 트래픽을 효율적으로 관리해요.

기능 처리 오버헤드 – Traffic Mirroring과 ENA Express 같은 기능은 더 많은 처리 오버헤드를 추가해 절대 패킷 처리 성능을 줄일 수 있어요. 기능 사용을 제한하거나 비활성화하면 패킷 처리 속도를 높일 수 있어요.

상태 유지 연결 추적 – 보안 그룹은 연결 추적을 사용해 인스턴스로 들어오고 나가는 트래픽 정보를 저장해요. 연결 추적은 각 네트워크 트래픽 플로우에 규칙을 적용해 허용·거부를 결정해요. Nitro 카드는 플로우 추적을 사용해 플로우의 상태를 유지해요. 보안 그룹 규칙이 많을수록 플로우를 평가하는 데 더 많은 작업이 필요해요.

참고: 모든 네트워크 트래픽 플로우가 추적되지는 않아요. Untracked connections로 구성된 보안 그룹 규칙은, 여러 유효한 응답 경로가 있을 때 대칭 라우팅을 보장하기 위해 자동 추적되는 연결 외에는 추가 작업이 필요하지 않아요.

하드웨어 가속을 사용하지 않는 패킷 (Packets that don't use hardware acceleration)

모든 패킷이 하드웨어 가속을 활용할 수는 없어요. 이 예외 처리에는 네트워크 플로우의 상태를 보장하는 데 필요한 처리 오버헤드가 수반돼요. 네트워크 플로우는 프로토콜 표준을 안정적으로 충족하고, VPC 설계 변경을 준수하고, 허용된 대상으로만 패킷을 라우팅해야 해요. 다만 이 오버헤드는 성능을 줄여요.

  • 패킷 프래그먼트 – 네트워크 MTU를 초과하는 패킷에서 생긴 프래그먼트는 보통 예외로 처리되어 하드웨어 가속을 활용할 수 없어요. 드라이버 버전에 따라 프래그먼트 프록시 모드로 egress 프래그먼트 제한을 우회할 수 있어요.
  • 유휴 연결(Idle connections) – 연결이 한동안 활동이 없으면(타임아웃에 도달하지 않았더라도) 시스템이 그 연결을 낮은 우선순위로 만들 수 있어요. 우선순위가 낮아진 후 데이터가 들어오면 재연결을 위해 예외로 처리해야 해요. 연결 관리를 위해 연결 추적 타임아웃으로 유휴 연결을 닫거나 TCP keepalives로 유휴 연결을 유지할 수 있어요.
  • VPC 변경(VPC mutation) – 보안 그룹, 라우트 테이블, 접근 제어 목록의 업데이트는 라우트 항목과 보안 그룹 규칙이 여전히 예상대로 적용되는지 처리 경로에서 재평가해야 해요.
  • ICMP 플로우 – ICMP(Internet Control Message Protocol)는 네트워크 장치가 네트워크 통신 문제를 진단하는 데 사용하는 네트워크 계층 프로토콜이에요. 이 패킷은 항상 전체 플로우를 사용해요.
  • 비대칭 L2 플로우 – NitroV3 이하 플랫폼은 같은 서브넷에서 두 ENI 사이의 트래픽, 특히 한 ENI는 기본 게이트웨이 라우터를 사용하고 다른 ENI는 사용하지 않는 경우에 하드웨어 가속을 사용하지 않아요. NitroV4 이상 플랫폼은 이 시나리오에서 하드웨어 가속을 사용해요. NitroV3 이하에서 더 나은 성능을 위해 두 ENI가 사용하는 기본 게이트웨이 라우터를 일치시키거나, ENI를 서로 다른 서브넷에 두세요.

Nitro 시스템의 네트워크 성능 극대화하기

네트워크 설정을 조정해 Nitro 시스템의 네트워크 성능을 최대화할 수 있어요.

고려 사항

설계 결정을 내리거나 네트워크 설정을 조정하기 전에 다음을 수행할 것을 권장해요.

  • "Nitro 시스템의 네트워크 설계 고려 사항"을 검토해 성능 개선을 위해 취할 수 있는 작업의 장단점을 이해하세요.
  • 최고 활성 플로우 수로 워크로드를 벤치마킹해 애플리케이션 성능의 기준선을 정하세요. 기준선이 있으면 설정이나 애플리케이션 설계의 변형을 테스트해 어떤 고려 사항이 가장 큰 영향을 주는지 이해할 수 있어요.

PPS 성능 튜닝

  • 두 인스턴스 사이의 물리적 거리를 줄여요. 같은 가용 영역에 있거나 클러스터 배치 그룹을 사용하면 패킷이 한 엔드포인트에서 다른 엔드포인트로 이동하는데 필요한 홉 수를 줄일 수 있어요.
  • Untracked connections을 사용해요.
  • 네트워크 트래픽에 UDP 프로토콜을 사용해요.
  • 총 대역폭이 100 Gbps 이상인 EC2 인스턴스는 워크로드를 100개 이상의 개별 플로우에 분산해 Nitro 카드에 균등하게 부하를 분산해요.
  • EC2 인스턴스의 egress 프래그먼트 PPS 한도를 극복하려면(드라이버 버전에 따라) 프래그먼트 프록시 모드를 활성화할 수 있어요. 이 설정은 프래그먼트 패킷이 처리 경로에서 평가되게 해 egress PPS 한도 1024를 극복해요. 드라이버 로드 시 다음 명령 중 하나로 프래그먼트 프록시 모드를 활성화·비활성화해요.

프래그먼트 프록시 모드 활성화:

sudo insmod ena.ko enable_frag_bypass=1

비활성화:

sudo insmod ena.ko enable_frag_bypass=0

ENA 큐 할당 구성

지원되는 인스턴스 유형에서 Elastic Network Interfaces(ENIs)에 걸쳐 이 큐를 동적으로 할당할 수 있어요. 유연한 ENA 큐 할당은 리소스 분배를 최적화해 최대 vCPU 활용을 가능하게 해요. 높은 네트워크 성능 워크로드는 보통 여러 ENA 큐를 필요로 해요.

Linux 인스턴스에서 성능 모니터링

Linux 인스턴스에서 Ethtool 지표로 대역폭, 패킷 속도, 연결 추적 같은 인스턴스 네트워킹 성능 지표를 모니터링할 수 있어요.

더 알아보기