[issue] Flask AWS close_wait 다중 발생

 

AWS EC2  t2.xlarge로 배포해놓은 서버에서 CLOSE_WAIT가 다중 발생하여, 서버 hang-up 현상이 있는 것을 발견

 

약 45번째 close_wait시 서버 hang-up 현상이 발생하였습니다.

 

 

 

[원인분석 참고자료]

https://tech.kakao.com/posts/321

CLOSE_WAIT & TIME_WAIT 최종 분석 - tech.kakao.com

 

출처 https://tech.kakao.com/posts/321

 

용어 설명

1. hang-up 현상 : 시스템이 느려지거나 멈추는 현상을 hang up이라고 함 
                            Server Instance는 실행   ->  아무런 응답 X

2. Active Close : 연결을 먼저 종료하려 하는 측
                           일반적으로 클라이언트

3. Passive Close : 종료 요청에 대응하는 측
                             일반적으로 서버

4. FIN 패킷 : Finish 패킷 
                     연결의 한쪽 에서 더 이상 데이터를 보내지 않겠다는 의사를 상대방에게 알리는데 사용

5. ACK 패킷 : Acknowledgment 패킷
                      TCP 통신으로 수신한 데이터 패킷을 잘 받았음을 알리기 위해 사용

 

[CLOSE_WAIT]의 목적

1. 자원 정리

2. 데이터 전송 완료

3. 정상적인 Process 종료 절차 보장

 

 

CLOSE_WAIT는 포트를 잡고 있는 프로세스의 종료 또는 재시작 이외에는 해결할 방법이 없음.

로컬 어플리케이션에서 정상적으로 close()하는것이 가장 좋은 방법이다.

즉 CLOSE_WAIT가 발생했다는 것은 명백한 오류가 있다는 뜻이다.

 

 

 

[조치 방안]

1. DB연결 cursor와 connection 중 close가 빠져있는 곳이 확인

2. 클라이언트 async 부분중에서도 await가 없는 곳이 있는지 확인 (확률 낮겠지만)

 

 

---

 

 

이참에 TIME_WAIT도 알아보자

 

[TIME_WAIT]

TIME_WAIT 이란 TCP 상태의 가장 마지막 단계
Active Close 즉, 먼저 close() 를 요청한 곳에서 최종적으로 남게 된다. (주로 클라이언트)
유효시간은 2*MSL(Maximum Segment Lifetime)동안 유지

 

 

[TIME_WAIT 목적]

1.지연된 패킷의 수신 보장,

2.이전 연결의 잔재 패킷 제거.

 

 

[TIME_WAIT를 찾기 힘든 이유]

Log level을 low까지 낮춰서 확인 하는 경우가 드뭄 

구현하는데 고난이도 기술이 필요하다

상대적으로 오래된 정보가  오해와 프레이밍 효과를 야기한다.

---

[과거의 오해] 

1. time_wait이 발생하면 메모리 부족을 야기한다.

 

틀린 말은 아니지만 1개의 TIME_WAIT당 168byte를 차지 -> 4만개의 TIME_WAIT 이면 10MB -> 메모리 차지 미비