민스씨의 일취일장

TIssue | AWS EC2 작동중인데 연결 안되는 이슈 (Feat. 연결 추적 테이블 nf_conntrack table이 가득참) 본문

Projects/MetaPay

TIssue | AWS EC2 작동중인데 연결 안되는 이슈 (Feat. 연결 추적 테이블 nf_conntrack table이 가득참)

읻민스 2024. 8. 25. 17:44
반응형

AWS EC2 정상 작동중인데 접속이 안돼 확인해 보니, nf_conntract table이 가득찬 이슈가 있었다. 이 것에 대한 해결 과정에 대한 글이다.

EC2 nf_conntrack table 가득찬 이슈

상황

EC2가 정상작동 중인데 접속이 안되는 이슈가 발생했다. 재부팅을 해도 해결이 되지 않는다. 지난 번에도 동일한 증상이 있어서 중지하고 재실행 했었다. 이렇게 했을 경우 ElasticIP를 사용중이 아니라면 접속 IP가 변경되버리고, 해당 IP로 설정해 놓은 모든 곳의 설정을 변경해줘야 햐는 번거로움이 있다. 그래서 이번에는 어떻게든 문제를 찾아 보려고 이것 저것 하다가 새로운 문제를 발견하게 되었다.

원인

인스턴스 목록에서 문제를 일으킨 인스턴스를 선택한다. 그런다음 오른쪽 위 작업에서 '작업 > 모니터링 및 문제 해결 > 시스템 로그 가져오기' 순으로 들어간다.

AWS EC2 콘솔에서 시스템 로그에 접속하는 과정이다.
AWS EC2 콘솔

그럼 아래와 같은 콘솔창을 하나 볼 수 있다. 여기서 해당 인스턴스의 시스템 로그를 확인할 수 있다.

EC2 시스템 로그를 띄운 터미널 모습이다.
EC2 시스템 로그

위로 스크롤 해 올라가면 이런 메시지가 있었다.

nf_conntrack table full 오류 출력 모습이다.
오류 메시지 nf_conntrack

nf_conntrack: nf_conntrack: table full, dropping packet

nf_conntrack table은 연결 추적 테이블이라는 것이다. 연결 추적 테이블이 가득차게 되면 새로운 연결을 처리하지 못하고 패킷을 드롭해버린다.

해결방법

찾아본 해결 방법으로는 아래의 2가지가 있다.

1. nf_conntrack 테이블 크기 증가

가장 추천되는 방식이다. 이런 상황이 생겼다는 것은, 또 생길 수 있는 시스템이란 말이기 때문에 미리 해당 테이블의 크기를 키워서 감당 가능한 시스템으로 만드는 것이다.

sysctl -w net.netfilter.nf_conntrack_max=131072

2. 가득찬 nf_conntrack 테이블 비우기

추천되지는 않지만, 현재 가득한 nf_conntrack 테이블을 비우는 것이다. 임시 해결책이지만, 당장 효과는 있을 것이다.

sudo conntrack -F

해결방법

하지만 당장 이 방법을 사용해 보지 않을 것이다. 일단 추적을 위한 테이블이라는 건 무한대로 사용할 수 있는 공간이 아니기 때문에 자체적으로 제거 로직이 있을 것이라 생각 돼 하루 정도는 기다려 보기로 했다. 어제 저녁에 발생한 일인데, 오늘 오전까지 작동이 안되고 있었다. 이론 공부를 마치고 저녁에 서버를 아예 중단하고 다시 실행해야 겠다 생각하고 있었는데 갑자기 실행이 됐다.

그라파나 그래프를 확인해 보니 어제 약 21시경부터 먹통이던 CPU 사용률 측정이 17시 이후부터 되기 시작하는 것을 확인할 수 있었다. 그러니까 약 20시간이 지나니 해결되었다.

그라파나 CPU 사용률 그래프 모습이다.
그라파나 CPU 사용률

결국 해야할 힐

히지만 nf_conntrack 테이블관련된 일은 반드시 다시 하게 될 것이다. 왜냐하면 어제와 마찬가지로 오늘도 스트레스 테스트를 진행할 것이기 때문이다. 다른 조치를 취하게 된다면 포스팅을 이어서 작성해 보도록 하겠다.

 

728x90
반응형