소개 Amazon Elastic File System(Amazon EFS)은 내부적으로 인프라 유지보수를 수행합니다. 정상적인 환경에서는 이 과정이 투명하게 처리되지만, EFS mount target에 연결된 security group의 기본 Outbound 규칙(Allow All)을 제거한 환경에서는 유지보수 시 NFS I/O가 수분간 hang되는 문제가 발생할 수 있습니다. 이 글에서는 실제 운영 환경에서 발생한 EFS NFS I/O hang 사례를 바탕으로, AWS EFS 서비스팀과의 협력을 통해 […] || 소개
Amazon Elastic File System(Amazon EFS)은 내부적으로 인프라 유지보수를 수행합니다. 정상적인 환경에서는 이 과정이 투명하게 처리되지만, EFS mount target에 연결된 security group의 기본 Outbound 규칙(Allow All)을 제거한 환경에서는 유지보수 시 NFS I/O가 수분간 hang되는 문제가 발생할 수 있습니다.
이 글에서는 실제 운영 환경에서 발생한 EFS NFS I/O hang 사례를 바탕으로, AWS EFS 서비스팀과의 협력을 통해 확인된 근본 원인의 정확한 메커니즘, tcpdump를 활용한 진단 방법, 그리고 해결 방안을 공유합니다.
Prerequisites
Amazon EFS 파일 시스템이 마운트된 Amazon EC2 인스턴스
EC2 인스턴스에 tcpdump 설치 (sudo yum install -y tcpdump 또는 sudo apt install -y tcpdump)
EFS Mount Target 및 EC2 인스턴스의 Security Group 수정 권한
문제 상황
한 고객 환경에서 EFS 유지보수 이후 특정 파일 시스템에 마운트된 EC2 인스턴스에서 NFS I/O hang이 발생했습니다.
주요 증상:
유지보수 전에는 정상 동작
유지보수 이후 하루 수십 회 NFS I/O hang이 반복 발생
매번 약 1~2분간 I/O가 멈춘 후 자동 복구 — 데이터 유실 없음
동일 EC2에서 다른 EFS 파일 시스템은 정상
커널 로그에서 다음과 같은 메시지가 확인되었습니다:
nfs: server 10.x.x.x not responding, still trying
nfs: server 10.x.x.x OK
배경: 왜 Security Group Outbound 규칙이 EFS에 영향을 주는가
이 문제를 이해하려면 세 가지를 알아야 합니다: TCP 연결의 기본 동작, Security Group의 stateful 특성, 그리고 EFS 유지보수 시 발생하는 특수한 상황.
TCP 연결과 RST
NFS는 TCP 위에서 동작합니다. TCP 연결은 3-Way Handshake(SYN → SYN,ACK → ACK)로 수립되며, 이후 모든 데이터 패킷에는 ACK 플래그가 포함됩니다 — “이전 패킷 잘 받았다”는 확인 신호입니다.
연결을 강제로 끊어야 할 때는 TCP RST(Reset) 패킷이 사용됩니다. RST는 “이 연결은 더 이상 유효하지 않다”는 즉시 종료 신호이며, ACK 플래그가 포함되지 않습니다.
Security Group의 stateful 동작
Security Group은 stateful입니다. Inbound로 허용된 연결의 응답 트래픽은 Outbound 규칙 없이도 자동으로 허용됩니다. 예를 들어 mount target의 security group에 “Inbound TCP 2049 허용” 규칙만 있어도, EFS에서 클라이언트로 돌아가는 NFS 응답([PSH, ACK])은 자동으로 통과합니다.
그런데 이 자동 허용에는 조건이 있습니다. EFS 서비스팀의 분석 결과, 기존 연결의 응답이 아닌 새로운 패킷 — 특히 ACK 없는 TCP RST — 은 이 자동 허용의 대상이 되지 않는 것으로 확인되었습니다.
EFS 유지보수 시 발생하는 특수한 상황
EFS 유지보수 시 백엔드 서버가 교체되면, 새로운 서버가 클라이언트에 RST를 보냅니다. 새 서버 입장에서 이 RST는 자신이 처리한 적 없는 연결에 대한