성능 튜닝을 위한 Nitro 시스템 고려 사항 - Amazon Elastic Compute Cloud
Nitro Card의 네트워크 패킷 흐름최적의 성능을 위한 네트워크 설계Nitro 시스템의 네트워크 성능 극대화

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

Nitro 시스템은 우수한 성능과 고가용성, 철저한 보안을 지원하기 위해 AWS가 구축한 하드웨어 및 소프트웨어 구성 요소의 모음입니다. Nitro System은 가상화 오버헤드를 없애고 호스트 하드웨어에 대한 모든 액세스 권한이 필요한 워크로드를 지원하는 베어 메탈과 유사한 기능을 제공합니다. 자세한 내용은 AWS Nitro 시스템을 참조하세요.

현재 세대의 모든 EC2 인스턴스 유형은 EC2 Nitro Card에서 네트워크 패킷 처리를 수행합니다. 이 주제에서는 Nitro Card에서 높은 수준의 패킷 처리, 패킷 처리 성능에 영향을 미치는 네트워크 아키텍처 및 구성의 일반적인 측면, Nitro 기반 인스턴스의 최대 성능을 얻기 위해 취할 수 있는 조치에 대해 다룹니다.

Nitro Card는 Virtual Private Cloud(VPC)에 필요한 인터페이스와 같은 모든 입출력(I/O) 인터페이스를 처리합니다. 네트워크를 통해 정보를 송수신하는 모든 구성 요소에서 Nitro Card는 고객 워크로드가 실행되는 시스템 메인 보드와 물리적으로 분리된 I/O 트래픽을 위한 독립형 컴퓨팅 디바이스 역할을 합니다.

Nitro Card의 네트워크 패킷 흐름

Nitro 시스템에 구축된 EC2 인스턴스에는 초당 패킷 수(PPS) 처리량 속도로 측정할 때 더 빠른 패킷 처리를 지원하는 하드웨어 가속 기능이 있습니다. Nitro Card가 새 흐름에 대한 초기 평가를 수행하면 보안 그룹, 액세스 제어 목록, 라우팅 테이블 항목 등 흐름의 모든 패킷에 대해 동일한 정보가 저장됩니다. 동일한 흐름에 대해 추가 패킷을 처리할 때 저장된 정보를 사용하여 해당 패킷의 오버헤드를 줄일 수 있습니다.

연결 속도는 초당 연결 수(CPS) 지표로 측정됩니다. 새로 연결할 때마다 추가 처리 오버헤드가 필요하며, 이 오버헤드는 워크로드 용량 추정에 포함되어야 합니다. 워크로드를 설계할 때는 CPS와 PPS 지표를 모두 고려하는 것이 중요합니다.

연결 설정 방법

Nitro 기반 인스턴스와 다른 엔드포인트 간에 연결이 설정되면 Nitro Card는 두 엔드포인트 간에 전송 또는 수신되는 첫 번째 패킷의 전체 흐름을 평가합니다. 동일한 흐름의 후속 패킷의 경우 일반적으로 전체 재평가가 필요하지 않습니다. 하지만 예외는 있습니다. 예외에 대한 자세한 내용은 하드웨어 가속을 사용하지 않는 패킷 섹션을 참조하세요.

다음 속성은 두 엔드포인트와 두 엔드포인트 간 패킷 흐름을 정의합니다. 이 다섯 가지 속성을 합쳐서 5튜플 흐름이라고 합니다.

  • 소스 IP

  • 원본 포트

  • 목적지 IP

  • 대상 포트

  • 통신 프로토콜

패킷 흐름의 방향을 수신(인바운드) 및 송신(아웃바운드)이라고 합니다. 다음은 포괄적인 네트워크 패킷 흐름을 요약한 개괄적인 설명입니다.

  • 수신 - Nitro Card가 인바운드 네트워크 패킷을 처리할 때 상태 저장 방화벽 규칙 및 액세스 제어 목록을 기준으로 패킷을 평가합니다. 연결을 추적하고, 측정하며, 필요에 따라 기타 작업을 수행합니다. 그런 다음, 패킷을 호스트 CPU의 대상으로 전달합니다.

  • 송신 - Nitro Card가 아웃바운드 네트워크 패킷을 처리할 때 원격 인터페이스 대상을 찾고, 다양한 VPC 기능을 평가하au, 속도 제한을 적용하고, 적용되는 기타 작업을 수행합니다. 그런 다음, 패킷을 네트워크의 다음 홉 대상으로 전달합니다.

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

Nitro 시스템의 성능 기능을 활용하려면 네트워크 처리 요구 사항을 이해하고, 이러한 요구 사항이 Nitro 리소스의 워크로드에 어떤 영향을 미치는지 이해해야 합니다. 그러면 네트워크 환경에 맞는 최적의 성능을 지원하도록 설계할 수 있습니다. 인프라 설정 및 애플리케이션 워크로드 설계와 구성은 패킷 처리 및 연결 속도 모두에 영향을 미칠 수 있습니다. 예를 들어 DNS 서비스, 방화벽 또는 가상 라우터와 같이 애플리케이션의 연결 설정 비율이 높으면 연결이 설정된 후에만 적용되는 하드웨어 가속을 활용할 기회가 줄어듭니다.

워크로드를 간소화하고 네트워크 성능을 개선하도록 애플리케이션 및 인프라 설정을 구성할 수 있습니다. 그러나 모든 패킷이 가속에 적합한 것은 아닙니다. Nitro 시스템은 새 연결과 가속에 적합하지 않은 패킷에 대해 전체 네트워크 흐름을 사용합니다.

이 섹션의 나머지 부분에서는 패킷 흐름이 최대한 가속 경로 내에서 진행되도록 보장하는 애플리케이션 및 인프라 설계 고려 사항에 초점을 맞춥니다.

Nitro 시스템의 네트워크 설계 고려 사항

인스턴스의 네트워크 트래픽을 구성할 때는 PPS 성능에 영향을 미칠 수 있는 여러 측면을 고려해야 합니다. 흐름이 설정된 후에는 정기적으로 수신되거나 송신되는 대부분의 패킷이 가속에 적합할 수 있습니다. 그러나 인프라 설계 및 패킷 흐름이 프로토콜 표준을 계속 충족하도록 하기 위한 예외가 존재합니다.

Nitro Card를 최대한 활용하려면 인프라 및 애플리케이션에 대한 다음 구성 세부 정보의 장단점을 신중하게 고려해야 합니다.

인프라 고려 사항

인프라 구성은 패킷 흐름과 처리 효율성에 영향을 미칠 수 있습니다. 다음 목록에는 중요한 몇 가지 고려 사항이 나와 있습니다.

비대칭성이 있는 네트워크 인터페이스 구성

보안 그룹은 연결 추적을 사용해 인스턴스에서 송수신되는 트래픽에 대한 정보를 추적합니다. 트래픽이 한 네트워크 인터페이스를 통해 인스턴스로 수신되고 다른 네트워크 인터페이스를 통해 송신되는 비대칭 라우팅을 사용하면 흐름을 추적하는 경우 인스턴스에서 달성할 수 있는 최고 성능을 줄일 수 있습니다. 보안 그룹 연결 추적, 추적되지 않은 연결 및 자동 추적된 연결에 대한 자세한 내용은 Amazon EC2 보안 그룹 연결 추적 섹션을 참조하세요.

네트워크 드라이버

네트워크 드라이버는 정기적으로 업데이트 및 릴리스됩니다. 오래된 드라이버인 경우 성능이 크게 저하될 수 있습니다. 최신 패치를 사용하고 최신 세대 드라이버에서만 사용할 수 있는 가속 경로 기능과 같은 성능 개선 기능을 활용할 수 있도록 드라이버를 최신 상태로 유지합니다. 이전 드라이버는 가속 경로 기능을 지원하지 않습니다.

가속 경로 기능을 활용하려면 인스턴스에 최신 ENA 드라이버를 설치하는 것이 좋습니다.

Linux 인스턴스 - ENA Linux 드라이버 2.2.9 이상. Amazon 드라이버 GitHub 리포지토리에서 ENA Linux 드라이버를 설치하거나 업데이트하려면 readme 파일의 Driver compilation 섹션을 참조하세요.

Windows 인스턴스 - ENA Windows 드라이버 2.0.0 이상. ENA Windows 드라이버를 설치하거나 업데이트하려면 EC2 Windows 인스턴스에 ENA 드라이버 설치 섹션을 참조하세요.

엔드포인트 간 거리

동일한 가용 영역에 있는 두 인스턴스 간의 연결은 애플리케이션 계층에서 TCP 윈도우 기능(지정된 시점에 전송할 수 있는 데이터의 양을 결정함)의 결과로 리전 간 연결보다 초당 더 많은 패킷을 처리할 수 있습니다. 인스턴스 간 거리가 멀면 지연 시간이 늘어나고 엔드포인트에서 처리할 수 있는 패킷 수가 줄어듭니다.

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

애플리케이션 설계 및 구성에는 처리 효율성에 영향을 줄 수 있는 여러 측면이 있습니다. 다음 목록에는 중요한 몇 가지 고려 사항이 나와 있습니다.

패킷 크기

패킷 크기가 클수록 인스턴스가 네트워크에서 송수신할 수 있는 데이터의 처리량이 증가할 수 있습니다. 패킷 크기가 작을수록 패킷 처리 속도가 증가할 수 있지만 패킷 수가 PPS 허용치를 초과할 경우 얻을 수 있는 최대 대역폭이 줄어들 수 있습니다.

패킷 크기가 네트워크 홉의 최대 전송 단위(MTU)를 초과하는 경우 경로를 따라 라우터에서 패킷을 조각화할 수 있습니다. 그 결과 패킷 조각은 예외로 간주되며, 표준 속도(가속화되지 않음)로 처리됩니다. 이로 인해 성능이 달라질 수 있습니다. Amazon EC2는 9001바이트의 점보 프레임을 지원하지만 모든 서비스가 이를 지원하는 것은 아닙니다. MTU를 구성할 때 토폴로지를 평가하는 것이 좋습니다.

프로토콜 절충

TCP와 같은 신뢰할 수 있는 프로토콜은 UDP와 같은 신뢰할 수 없는 프로토콜보다 오버헤드가 더 큽니다. UDP 전송 프로토콜은 오버헤드가 낮고 네트워크 처리가 단순화되므로 PPS 속도는 높지만 패킷 전달의 안정성이 떨어질 수 있습니다. 애플리케이션에 안정적인 패킷 전송이 중요하지 않은 경우 UDP를 사용하는 것이 좋습니다.

마이크로 버스팅

마이크로 버스팅은 트래픽이 균등하게 분배되지 않고 짧은 시간 동안 허용량을 초과할 때 발생합니다. 일반적으로 마이크로초 단위로 발생합니다.

예를 들어 인스턴스에서 최대 10Gbps를 전송할 수 있고, 애플리케이션이 0.5초 안에 10Gb 전체를 전송한다고 가정합니다. 이 마이크로 버스팅은 처음 0.5초 동안 허용량을 초과하고 나머지 0.5초 동안 아무 것도 남기지 않습니다. 1초 동안 10Gb를 전송했지만 처음 0.5초의 허용량 때문에 패킷이 삭제되거나 대기 상태가 될 수 있습니다.

Linux Traffic Control과 같은 네트워크 스케줄러를 사용하면 처리량을 조절하고 마이크로 버스팅으로 인해 패킷이 대기 상태가 되거나 삭제되는 것을 방지할 수 있습니다.

흐름 수

단일 흐름은 최대 10Gbps를 지원하는 클러스터 배치 그룹 내에 있지 않거나 최대 25Gbps를 지원하는 ENA Express를 사용하는 경우가 아니면 5Gbps로 제한됩니다.

마찬가지로 Nitro Card는 단일 흐름을 사용하는 것보다 여러 흐름에서 더 많은 패킷을 처리할 수 있습니다. 인스턴스당 최대 패킷 처리 속도를 달성하려면 총 대역폭이 100Gbps 이상인 인스턴스에서 최소 100개의 흐름을 사용하는 것이 좋습니다. 총 대역폭 용량이 증가하면 최대 처리 속도를 달성하는 데 필요한 흐름 수도 증가합니다. 벤치마킹은 네트워크에서 최고 속도를 달성하는 데 필요한 구성을 결정하는 데 도움이 됩니다.

Elastic Network Adapter(ENA) 대기열 수

기본적으로 최대 ENA 대기열 수는 인스턴스 크기 및 유형에 따라 네트워크 인터페이스에 할당됩니다. 대기열 수를 줄이면 달성 가능한 최대 PPS 속도를 줄일 수 있습니다. 최고 성능을 위해 기본 대기열 할당을 사용하는 것이 좋습니다.

Linux의 경우 네트워크 인터페이스는 기본적으로 최대값으로 구성됩니다. 데이터 영역 개발 키트(DPDK) 기반 애플리케이션의 경우 사용 가능한 최대 대기열 수를 구성하는 것이 좋습니다.

특성 처리 오버헤드

트래픽 미러링 및 ENA Express와 같은 특성은 처리 오버헤드를 증가시켜 절대 패킷 처리 성능을 감소시킬 수 있습니다. 특성 사용을 제한하거나 특성을 비활성화하여 패킷 처리 속도를 높일 수 있습니다.

연결 추적으로 상태 유지

보안 그룹은 연결 추적을 사용해 인스턴스에서 송수신되는 트래픽에 대한 정보를 저장합니다. 연결 추적은 네트워크 트래픽의 개별 흐름에 규칙을 적용하여 해당 트래픽의 허용 또는 거부를 결정합니다. Nitro Card는 흐름 추적을 사용하여 흐름의 상태를 유지 관리합니다. 더 많은 보안 그룹 규칙이 적용되면 흐름을 평가하는 데 더 많은 작업이 필요합니다.

참고

모든 트래픽 흐름을 추적하지는 않습니다. 추적되지 않는 연결에서 보안 그룹 규칙이 구성된 경우 유효한 응답 경로가 여러 개 있을 때 대칭 라우팅을 보장하기 위해 자동으로 추적되는 연결을 제외하고는 추가 작업이 필요하지 않습니다.

하드웨어 가속을 사용하지 않는 패킷

모든 패킷이 하드웨어 가속을 이용할 수 있는 것은 아닙니다. 이러한 예외를 처리하려면 네트워크 흐름의 상태를 보장하는 데 필요한 일부 처리 오버헤드가 수반됩니다. 네트워크 흐름은 프로토콜 표준을 안정적으로 충족하고, VPC 설계의 변경 사항을 준수하며, 허용된 대상으로만 패킷을 라우팅해야 합니다. 하지만 오버헤드로 인해 성능이 저하됩니다.

패킷 조각

애플리케이션 고려 사항에서 언급한 바와 같이, 네트워크 MTU를 초과하는 패킷으로 인해 발생하는 패킷 조각은 예외로 처리되며 하드웨어 가속을 활용할 수 없습니다.

유휴 연결

연결이 제한 시간에 도달하지 않았더라도 한동안 연결에 활동이 없으면 시스템에서 우선순위를 낮출 수 있습니다. 연결 우선순위가 낮아진 후에 데이터가 수신된 경우 다시 연결하려면 시스템에서 이를 예외로 처리해야 합니다.

연결을 관리하기 위해 연결 추적 제한 시간을 사용하여 유휴 연결을 종료할 수 있습니다. 또한 TCP Keepalive를 사용하여 유휴 연결을 열린 상태로 유지할 수 있습니다. 자세한 내용은 유휴 연결 추적 제한 시간 단원을 참조하십시오.

VPC 변형

보안 그룹, 라우팅 테이블, 액세스 제어 목록에 대한 모든 업데이트를 처리 경로에서 재평가하여 라우팅 항목과 보안 그룹 규칙이 여전히 예상대로 적용되는지 확인해야 합니다.

ICMP 플로우

ICMP(인터넷 제어 메시지 프로토콜)는 네트워크 장치가 네트워크 통신 문제를 진단하는 데 사용하는 네트워크 계층 프로토콜입니다. 이러한 패킷은 항상 전체 흐름을 사용합니다.

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

최상의 결과를 얻으려면 설계 결정을 내리거나 인스턴스의 네트워크 설정을 조정하기 전에 다음 단계를 수행하는 것이 좋습니다.

  1. Nitro 시스템의 네트워크 설계 고려 사항 검토를 통해 성능 개선을 위해 수행할 수 있는 작업의 장단점을 이해합니다.

    Linux에서 인스턴스 구성을 위한 추가 고려 사항과 모범 사례는 GitHub의 ENA Linux Driver Best Practices and Performance Optimization Guide를 참조하세요.

  2. 최대 활성 흐름 수로 워크로드를 벤치마킹하여 애플리케이션 성능의 기준선을 결정합니다. 성능 기준선을 통해 특히 스케일 업 또는 스케일 아웃을 계획하는 경우 설정 또는 애플리케이션 설계의 변화를 테스트하여 어떤 고려 사항이 가장 큰 영향을 미치는지 파악할 수 있습니다.

다음 목록에는 시스템 요구 사항에 따라 PPS 성능을 조정하기 위해 수행할 수 있는 작업이 포함되어 있습니다.

  • 두 인스턴스 간 물리적 거리를 줄입니다. 송신 및 수신 인스턴스가 동일한 가용 영역에 있거나 클러스터 배치 그룹을 사용하는 경우 패킷이 한 엔드포인트에서 다른 엔드포인트로 이동하는 데 필요한 홉 수를 줄일 수 있습니다.

  • 추적되지 않는 연결를 사용합니다.

  • 네트워크 트래픽에 UDP 프로토콜을 사용합니다.

  • 총 대역폭이 100Gbps 이상인 EC2 인스턴스의 경우 100개 이상의 개별 흐름에 워크로드를 분산하여 Nitro Card 전체에 작업을 고르게 분산합니다.

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

Linux 인스턴스에서 Ethtool 지표를 사용하여 대역폭, 패킷 속도, 연결 추적과 같은 인스턴스 네트워킹 성능 지표를 모니터링할 수 있습니다. 자세한 내용은 EC2 인스턴스의 ENA 설정에 대한 네트워크 성능 모니터링 단원을 참조하십시오.