장애 대처법
일단 마음을 가라앉힌다
가능하다면 이미 내 모듈에다가 상태를 파악할 수 있는 수단을 만들어뒀기를 기도한다.
그 수단 (상태 확인용 API라던가..) 을 사용해서 우선 내 API 상태가 정상인지 확인한다.
그런 수단이 없다면 서버로 들어가서 로그를 먼저 본다.
로그에 딱히 이상한게 없다면 이번엔 문제 기능을 직접 호출해서 테스트해본다.
문제가 없다면 이번엔 외부의 다른 위치에서도 정상적으로 작동하는지 확인해본다. 다른 IDC, 한국이면 한국, 일본이면 일본 등 되도록 다양한 위치에서 확인한다.
이래도 저래도 내 문제가 아닌 것 같다면 내 모듈을 사용하는 쪽에다가 확인용 API 등을 보내서 curl 같은걸로 테스트 해달라고 한다.
그 쪽에서 확인 결과 정상 작동한다고 하면 이제 이건 내 문제가 아니고 그쪽 클라이언트 문제이므로 그렇게 말하면 된다.
그런데 이 때, 정상작동하지 않으면 이건 네트워크, 인프라의 문제일 가능성이 있으므로 조사할 필요가 있다.
ACL, 라우팅, L4 등 다양한 가능성이 있으므로 하나하나 찾아봐야한다.
사례 정리
1. Feedback API 호출 실패
상황
내 Rest API 사용하는 클라이언트가 어느 시점부터 Connection 오류가 뜬다고 연락이 옴. 확인해보니 로컬, 다른 한국쪽 서버, 다른 일본쪽 서버에서 시도해봤을 때 모두 정상적으로 호출됨. 사용자의 해당 서버에서 curl로 시도했을 때도 문제없이 동작.
원인
알고보니 L4서버와 내 Rest API 서버간 tcp connection은 timeout이 30분인데 내 서버에 별도 알림 없이 그냥 connection을 끊어버림. 보통은 이런 경우 새로 connection을 맺어서 사용하기 때문에 문제가 발생하지 않는데, 해당 클라이언트에서는 내 API를 호출할 때 connection을 pooling 해두고, 또 그 클라이언트의 timeout 세팅이 30분보다 길었기 때문에 문제가 발생함. 이 때 클라이언트 - L4 사이의 connection은 살아있는 것으로 간주되어 계속 그 connection을 사용하려고 시도함. 그러나 API 호출이 30분 이상 없어서 L4에서는 내 서버로 connection을 끊어버린 상황. 그러므로 당연히 정상 동작하지 않음.
해결책
클라이언트 서버의 커널 tcp connection timeout 설정을 30분 미만으로 수정. 이렇게 하면 30분 이상 요청이 없을 때 클라이언트가 connection을 정리하므로 재발 방지
클라이언트에서 api를 호출할 때 connection 오류가 뜨면 새로운 connection을 맺어서 retry하도록 로직 추가.
딱히 내가 뭘 어떻게 할 수 있는 부분은 없었음.
Last updated