01무엇이 바뀌었는가

변경된 것은 ENI(elastic network interface) 단위 설정인 TCP established 유휴 타임아웃의 기본값 하나입니다. API에서는 네트워크 인터페이스의 ConnectionTrackingSpecification에 포함된 TcpEstablishedTimeout 파라미터로 지정합니다. 60초에서 432,000초 사이로 조정하는 설정 범위는 예전 그대로이고 Nitro V6에서 기본값만 350초로 낮아졌습니다.

P6e-GB200에는 350초 기본값이 적용되지 않고 다른 세대와 같은 432,000초가 유지됩니다. 다만 이 타입의 Nitro 버전 분류는 문서마다 다릅니다. Nitro 인스턴스 문서는 Nitro v5로 분류하고 연결 추적 문서는 Nitro V6의 350초 예외 타입으로 명시합니다. 표 1의 "제외" 표기는 연결 추적 문서를 따랐습니다. 분류가 어느 쪽이든 타임아웃 결론은 같습니다.

적용 대상을 판단할 때는 세대 번호와 Nitro 버전이 항상 일치하지는 않는다는 점에 주의가 필요합니다. Graviton4 기반 8세대인 M8g, C8g, R8g는 Nitro v5라서 이번 변경의 영향을 받지 않고, 9세대인 M9g, C9g는 Nitro v6라서 해당됩니다. 사용 중인 타입이 해당하는지는 Nitro 인스턴스 문서의 목록으로 확인합니다. 가상화 인스턴스 기준 목록입니다.

베어메탈은 이 목록에서 -flex 계열과 M8ine, C8ine, 가속 컴퓨팅, HPC를 제외한 구성입니다. 혼동하기 쉬운 Nitro v5 타입은 M8g, M8gd, C7gn, C8g, C8gd, R8g, R8gd, X8g, I7ie, I8g, P5en, P6e-GB200, Trn2, Trn2u, Hpc7g입니다.

UDP 쪽은 원래부터 짧았습니다. 단방향이거나 요청-응답 한 번으로 끝나는 흐름에 적용되는 UdpTimeout 기본값이 30초(최대 60초), 스트림으로 분류된 흐름에 적용되는 UdpStreamTimeout 기본값이 180초(최소 60초)라서 이번 변경의 대상이 아닙니다.

02변경 배경

2.1 연결 추적 할당량 고갈 방지

연결 추적 할당량(allowance)은 인스턴스가 쓸 수 있는 Nitro 리소스에 따라 유한합니다. 기본값이 5일이던 시절에는 FIN이나 RST를 받지 못한 유휴 연결과 고아(orphaned) 연결이 추적 테이블에 최대 5일씩 남았습니다. 이것이 쌓여 할당량을 소진하면 기존 엔트리가 닫히거나 타임아웃될 때까지 인스턴스가 신규 연결을 아예 수립하지 못합니다. connection timeout과 connection refused 오류, 백엔드 연결 수립 실패로 인한 로드 밸런서의 504 응답, Network Load Balancer(NLB)의 TCP_ELB_Reset_Count 지표 증가가 이때 나타나는 대표 증상입니다.

UDP를 비롯한 non-TCP 흐름은 타임아웃이 30~180초로 짧아 대규모로 누적될 가능성이 낮습니다. 누적 리스크가 사실상 TCP established 상태에 몰려 있었고, 이번 변경은 정확히 그 이슈를 완화하기 위함입니다.

2.2 다른 네트워킹 서비스와의 정렬

NLB, NAT 게이트웨이, Gateway Load Balancer는 이미 350초 유휴 타임아웃을 사용합니다. EC2 ENI에서만 5일이면 한쪽은 연결이 살아 있다고 믿고 다른 쪽은 이미 버린 half-open 상태가 생깁니다. 350초 기본값은 이런 계층 간 불일치를 줄이려는 선택입니다.

03영향 분석

3.1 silent drop이 만드는 까다로운 장애 양상

타임아웃으로 연결 추적 엔트리가 삭제될 때 양쪽 어디에도 FIN이나 RST가 전달되지 않습니다. 클라이언트 소켓은 ESTABLISHED 상태로 남아 있고, 다음 요청을 보내는 순간 패킷이 조용히 버려집니다. AWS 블로그에서는 이 현상을 silent drop이라고 부릅니다.

silent drop이 까다로운 데는 이유가 있습니다. 애플리케이션이 즉시 오류를 받지 못하고 자체 타임아웃에 걸릴 때까지 멈춰 있으므로 요청 지연이 수십 초 단위로 치솟습니다. 연결 풀은 죽은 연결을 정상으로 판단해 계속 재사용하므로 유휴 시간이 길었던 새벽이나 주말 직후의 첫 요청들이 집중적으로 실패하는 패턴이 나타납니다. 재현도 어렵습니다. 부하 테스트는 트래픽을 계속 흘리기 때문에 유휴 상태 자체가 만들어지지 않아 그대로 통과해 버립니다.

3.2 영향받는 워크로드

350초보다 긴 유휴 구간이 생기는 연결이라면 모두 점검 대상입니다.

• 데이터베이스 연결 풀 - maxIdleTime이 350초보다 크거나 설정돼 있지 않은 경우로, 가장 흔한 피해 사례입니다.
• IoT 텔레메트리 - 간헐적으로 전송하는 MQTT와 장기 세션이 해당합니다.
• 마이크로서비스 간 persistent HTTP, gRPC 연결 - keep-alive로 재사용하는 풀이 대상입니다.
• 웹소켓과 롱폴링 - 애플리케이션 하트비트 주기가 350초보다 길면 영향을 받습니다.
• 배치 간격이 긴 워커, 유휴 상태로 열어 둔 SSH와 점프박스 세션

3.3 의도하지 않은 세대 이관

이번 변경에서 가장 주의할 지점은 이관이 결정이 아니라 자동으로 일어난다는 사실입니다. AWS도 블로그에서 이 부분을 명시적으로 경고합니다.

Amazon EKS 환경이라면 두 가지를 더 확인해야 합니다. Karpenter NodePool에 인스턴스 제약이 없으면 m8i 같은 Nitro V6 타입이 선택될 수 있습니다. 이때 karpenter.k8s.aws/instance-generation 같은 세대 제약만으로는 Nitro 버전을 통제할 수 없습니다. 9세대인 M9g는 Nitro v6라서 걸러지지 않고 Nitro v5인 M8g만 불필요하게 배제됩니다. 통제가 필요하면 인스턴스 패밀리 목록으로 지정하고 근본 대응은 세대와 무관하게 동작하는 keepalive에 둡니다. 그리고 Amazon VPC CNI 기본 모드에서 파드는 노드의 ENI를 공유하므로 노드 ENI의 타임아웃이 파드에 그대로 적용됩니다.

3.4 계층 간 타임아웃 불일치

NLB 유휴 타임아웃을 1,800초로 늘려 두었는데 ENI가 350초라면 로드 밸런서는 연결을 유지하는 동안 EC2가 먼저 추적을 버립니다. 클라이언트 입장에서는 잘 되던 연결에 갑자기 문제가 발생한다는 것입니다. ENI 타임아웃만 조정하는 대응은 이런 함정을 만듭니다. 스택 전체를 정렬하는 방법은 대응 방안에서 이어서 다룹니다.

04대응 방안

우선순위 순으로 살펴봅니다. 1순위인 keepalive를 적용하면 나머지는 보완 수단이 되고, 적용하지 않으면 나머지 수단만으로는 세대가 혼재된 환경에서 안전을 보장하기 어렵습니다.

4.1 TCP keepalive 적용

keepalive는 유휴 연결에 주기적으로 프로브 패킷을 보내 연결이 어느 인프라 계층에서도 유휴 상태에 도달하지 않게 합니다. 타임아웃 값 자체를 무의미하게 만들기 때문에 EC2, 로드 밸런서, NAT 게이트웨이를 포함한 모든 계층에서 유효하고 Nitro 세대가 섞여 있어도 동작이 달라지지 않습니다.

ENI 타임아웃이 350초라면 프로브를 240초 이전에 시작하도록 설정해 여유를 확보합니다. 240초는 350초까지 110초를 남기는 값입니다. 상대 호스트가 이미 응답하지 않아 프로브가 전부 실패해도 240 + 60 × 3 = 420초면 소켓이 정리됩니다. 리눅스 커널의 keepalive 기본 시작 시간은 7,200초(2시간)로, 클라우드 인프라의 타임아웃을 막기에는 너무 깁니다. 값 조정이 필수입니다.

net.ipv4.tcp_keepalive_time = 240    # 4분 유휴 후 프로브 시작
net.ipv4.tcp_keepalive_intvl = 60    # 60초 간격으로 프로브
net.ipv4.tcp_keepalive_probes = 3    # 3회 실패 시 연결 종료

소켓을 직접 다루는 코드에서는 파이썬 기준으로 옵션을 이렇게 지정합니다.

import socket

# TCP_KEEPIDLE 계열 상수는 Linux 전용 (macOS는 TCP_KEEPALIVE, Windows에는 없음)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 240)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 60)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)

TCP_KEEPIDLE 계열 옵션까지 함께 넣으면 sysctl 기본값을 소켓 단위로 덮어쓸 수 있습니다. 주요 애플리케이션은 저마다 keepalive 설정 항목을 따로 둡니다.

Redis의 tcp-keepalive 기본값은 300초라 350초 안에 들어오지만 여유가 50초뿐입니다. 명시적으로 더 낮춰 두는 편이 안전합니다.

Amazon EKS에서는 파드의 securityContext.sysctls로 net.ipv4.tcp_keepalive_* 값을 지정합니다.

spec:
  securityContext:
    sysctls:
      - name: net.ipv4.tcp_keepalive_time
        value: "240"
      - name: net.ipv4.tcp_keepalive_intvl
        value: "60"
      - name: net.ipv4.tcp_keepalive_probes
        value: "3"

이 sysctl들은 Kubernetes 1.29부터 safe sysctl로 승격되었기 때문에 1.29 미만 클러스터에서는 unsafe sysctl 허용 설정이 필요합니다. 버전과 무관하게 hostNetwork: true 파드에서는 net.* 계열 sysctl 지정이 허용되지 않아 파드가 기동에 실패합니다. 두 경우 모두 노드 userData나 DaemonSet으로 노드 전체에 적용하는 방법이 해법입니다.

한 가지 한계도 알아 두면 좋습니다. TCP keepalive는 인프라의 타임아웃을 막아 주지만 원격 애플리케이션이 응답 불능에 빠진 상황은 TCP 연결이 온전해도 감지하지 못합니다. 그래서 많은 워크로드가 keepalive와 애플리케이션 레벨 하트비트를 함께 운영합니다.

4.2 ENI 타임아웃 명시적 설정

keepalive를 적용할 수 없는 연결에 350초보다 긴 유휴가 필요하다면 기본값에 기대지 말고 값을 명시합니다. AWS CLI에서는 ModifyNetworkInterfaceAttribute 작업으로 설정합니다.

aws ec2 modify-network-interface-attribute \
  --network-interface-id eni-xxxxxxxx \
  --connection-tracking-specification TcpEstablishedTimeout=3600

시작 템플릿(launch template), 콘솔, AWS CloudFormation과 Terraform으로도 같은 값을 지정합니다. 신규 인스턴스에 적용하려면 시작 템플릿에 넣어야 하고, Karpenter와 Auto Scaling 그룹 경로도 마찬가지입니다. 다만 Karpenter의 EC2NodeClass에서 이 설정이 직접 노출되지 않을 수 있으니 사용 중인 버전의 지원 여부를 먼저 확인하고 지원되지 않으면 커스텀 시작 템플릿이나 keepalive 경로로 가는 편이 확실합니다.

4.3 연결 수명 주기 정리

연결 풀 설정을 함께 손보면 타임아웃과의 충돌 자체가 줄어듭니다. maxIdleTime을 350초보다 짧게 잡고, maxLifetime으로 연결을 주기적으로 교체하고 사용 전에 validation query나 health check로 살아 있는지 검증합니다. 풀 크기도 실제 동시성 요구에 맞게 줄입니다. 예를 들어 HikariCP에서는 두 값을 이렇게 잡습니다.

# HikariCP: 유휴 300초에 정리(350초보다 짧게), 30분마다 연결 교체
idleTimeout=300000
maxLifetime=1800000

이름은 풀마다 달라서 MongoDB 드라이버는 maxIdleTimeMS, R2DBC 풀은 maxIdleTime처럼 대응 항목을 찾아 적용합니다.

원칙: 연결은 keepalive가 있는 활성 상태이거나 닫힌 상태, 둘 중 하나여야 하고 무기한 유휴 상태로 두지 않습니다. 장시간 유휴가 예상되면 닫았다가 필요할 때 다시 엽니다.

4.4 스택 전체의 타임아웃 정렬

AWS가 권고하는 구조는 애플리케이션이 가장 먼저 닫는 배치입니다. 예를 들어 NLB 1,800초, ENI 350초, 애플리케이션 60초처럼 안쪽 계층일수록 타임아웃이 짧으면 유휴 연결을 애플리케이션이 가장 먼저 닫고, 종료 신호(FIN)가 ENI와 로드 밸런서를 거쳐 외부 계층으로 전파됩니다. 어느 인프라 계층도 연결을 조용히 버리지 않게 됩니다. 순서가 반대면 silent drop이 발생합니다. Application Load Balancer(ALB) 뒤라면 기본 유휴 타임아웃이 60초라서 보통 ENI보다 먼저 연결이 정리됩니다. 다만 값을 늘려 잡았다면(최대 4,000초) ENI 350초와의 순서가 뒤집히지 않았는지 확인합니다.

그래서 아키텍처에 존재하는 모든 타임아웃 값을 문서화해 두는 것이 좋습니다. 애플리케이션, 로드 밸런서, NAT 게이트웨이, EC2 ENI가 대상입니다. 가장 신뢰할 수 있는 방법은 체인에서 가장 짧은 타임아웃보다 더 짧은 keepalive를 구현해 정렬 문제 자체를 피하는 것입니다.

반대로 타임아웃을 오히려 낮춰야 하는 경우도 있습니다. 공개 API나 데이터베이스 서버처럼 클라이언트 동작을 통제할 수 없는 서비스라면 ENI 타임아웃을 350초 기본값 또는 그 이하로 두는 편이 맞습니다. 유휴 클라이언트 연결이 누적되어 할당량을 소진하는 쪽이 더 위험하기 때문입니다.

05탐지 및 모니터링

ENA 드라이버가 노출하는 연결 추적 지표로 상태를 직접 확인할 수 있습니다. 인터페이스 이름이 AMI에 따라 eth0(Amazon Linux 2)이나 ens5(AL2023 등 예측 가능한 이름 체계)로 다르므로 이름부터 확인하고 실행합니다.

ip -br link                       # 인터페이스 이름 확인
ethtool -S eth0 | grep conntrack  # 이름이 ens5라면 바꿔서 실행

두 지표의 해석은 다음 표와 같고, 값의 급격한 변화가 곧 신호입니다.

이 중 conntrack_allowance_available은 2023년에 추가된 네트워크 성능 지표라서 리눅스 ENA 드라이버 2.8.1 이상이 필요합니다. 오래된 AMI라면 ethtool -i eth0으로 드라이버 버전부터 확인하세요.

프로덕션에서는 CloudWatch 통합 에이전트(1.246396.0 이상) 설정에 ethtool 섹션을 추가해 두 지표를 게시합니다.

{
  "metrics": {
    "metrics_collected": {
      "ethtool": {
        "interface_include": ["eth0"],
        "metrics_include": [
          "conntrack_allowance_available",
          "conntrack_allowance_exceeded"
        ]
      }
    }
  }
}

게시된 지표에는 ethtool_ 접두사가 붙습니다. 그래프와 경보를 만들 때는 ethtool_conntrack_allowance_available이라는 이름으로 찾습니다. 인터페이스 이름이 ens5라면 interface_include 값도 그에 맞춥니다. 여기에 애플리케이션의 연결 오류와 재시도 횟수, 연결 풀 사용률과 지연, NLB의 TCP_ELB_Reset_Count를 함께 봅니다.

TCP_ELB_Reset_Count는 NLB가 생성한 RST 패킷 수를 집계하는 CloudWatch 지표라서 AWS CLI로 바로 조회합니다.

# --start-time의 date -d는 GNU 문법입니다. macOS/BSD에서는 date -u -v-1H 사용
aws cloudwatch get-metric-statistics \
  --namespace AWS/NetworkELB \
  --metric-name TCP_ELB_Reset_Count \
  --dimensions Name=LoadBalancer,Value=net/my-nlb/xxxxxxxxxxxxxxxx \
  --statistics Sum \
  --period 300 \
  --start-time "$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)"

이 값이 평소 수준을 넘어 계속 높아지면 유휴 타임아웃을 넘긴 연결로 트래픽이 유입되고 있다는 신호이므로 keepalive 적용 상태와 타임아웃 정렬부터 점검합니다. 클라이언트와 타깃이 보낸 RST는 TCP_Client_Reset_Count, TCP_Target_Reset_Count로 구분해 확인합니다.

06상황별 조치 요약

지금 무엇을 해야 하는지는 운영 중인 세대 구성에 따라 갈립니다.

07검증 시 주의 사항

지속 부하 테스트만으로는 이 문제가 재현되지 않습니다. 현실적인 유휴 구간을 포함한 테스트가 필요하고 아래 문제들은 수 시간을 운영해야 비로소 드러납니다.

• 연결 풀 동작이 시간이 지나며 드리프트합니다.
• 연결 10개에서 동작하던 재시도와 백오프 로직이 10,000개에서는 실패합니다.
• 파일 디스크립터, 메모리, 연결 추적 엔트리 같은 리소스가 임계치를 넘을 때까지 축적됩니다.
• 계층 간 타임아웃 상호작용은 지속적인 부하 아래에서만 표면화됩니다.

새 인스턴스 세대는 항상 대표성 있는 워크로드로 미리 테스트하고 카나리나 블루그린으로 점진 배포해 문제가 생기면 빠르게 롤백할 수 있게 준비합니다.

08마치며

글머리의 세 가지 증상으로 돌아가 보겠습니다. 주말 직후 첫 요청이 집중 실패하는 것은 350초를 넘긴 유휴 연결이 silent drop으로 끊긴 뒤 연결 풀이 죽은 연결을 재사용했기 때문입니다. 노드 교체 후에 시작된 연결 오류는 Karpenter나 속성 기반 선택이 워크로드를 Nitro V6로 옮기면서 기본값이 바뀐 결과일 가능성이 높습니다. 부하 테스트에서 재현되지 않는 것도 자연스러운 일입니다. 트래픽이 계속 흐르면 유휴 상태가 만들어지지 않기 때문입니다.

350초 기본값은 연결 추적 고갈이라는 더 큰 장애를 막기 위한 조정이고 SO_KEEPALIVE까지 포함해 keepalive를 제대로 적용하면 Nitro 세대와 무관하게 해결됩니다. ENI 타임아웃을 5일로 되돌리는 대응은 원래의 할당량 고갈 문제를 다시 불러오므로 권장하지 않습니다.

복원력 있는 구성은 세 계층에서 함께 동작합니다.

1. 애플리케이션 계층 - TCP keepalive나 하트비트를 구현합니다.
2. 인프라 계층 - 워크로드에 맞는 ENI 타임아웃을 설정하며 상위 로드 밸런서, NAT 게이트웨이와의 정렬을 검증합니다.
3. 모니터링 계층 - conntrack_allowance_available과 conntrack_allowance_exceeded, 연결 오류율을 함께 추적합니다.

이렇게 갖춰 두면 어떤 Nitro 세대, 어떤 인프라 계층에서도 애플리케이션이 동일하게 안정적으로 동작합니다.