[신입일기 - API 이슈 정리] 서버에서 RST 패킷을 보냄.. 🤢
일주일간 API 이슈에 대해 생각했던 부분들을 순서대로 정리해보고자 한다~ 먼 훗날에 도움 될 게 분명하다.. 😂 (우리 팀장님, 타 팀 팀장님, 나, 타 팀 주임님 두 분과 함께 분석한 내용을 모두 정리해두었다!)
1. 타 팀 주임님에게 메신저로 문의 옴. (01/29 월)
"주임님, 매분 50~59초 사이에 응답이 안 오고, 요청이 failed 되는 것 같은데.. 혹시 해당 주기마다 갱신되는 로직이 있나요..?"라고 문의가 왔다. 서버 로그 찍힌 거 확인해 보니, 이벤트 조회할 때 특수문자가 포함된 게 있으면 에러가 발생하는 게 있어서.. 그거와 관련이 있는지 질문드렸는데 일단 아니었다.
현재 타 팀 서비스와 우리 팀 서비스 사이에 API 4개 제공 중인데,, 시간이 짧게 소요되는 API에서만 발생하더라.. 입력받은 값 이용해서 SELECT 문 만든 후, DB에 조회하는 게 전부인데.. 그렇게 오래 걸릴 리가 없어서 일단 그렇게 동작하지 않는다고 말씀드렸다.
2. 동일한 내용으로 다시 문의 옴. (01/30 화)
요번에는 쪽지로 통신 관련 문제가 발생하는 것으로 판단된다고 분석 요청 주셨다. 타 팀 팀장님께서, 해당 API 이용한 기타 보고서 시연이 조만간이기 때문에 우선순위 높여서 처리해 주시면 좋을 것 같다고도 덧붙여주셨다. ㅋㅋㅋ ㅠㅠ
하나의 API로 5초씩 요청하도록 했는데,, 우리 서비스가 설치되어 있는 서버에서 tcpdump 로그 떠보니, 5초에 한 번씩 요청이 들어오지 않고, 한 번씩 빠졌다. 5초에 들어오고, 10초에도 들어오고, 그다음에 20초에 들어오는 식으로... 이 날은 여기까지 파악했다.
3. 주요 원인 발견 (01/31 수)
내가 다른 주임님께 인수인계받는 사이에, 팀장님이 원인 분석을 해주셨다. 원인은 다음과 같다.
[통신 오류 발생 원인]
1. 타 팀 서비스에서 우리 서비스가 설치된 서버에 API 요청할 때, 통신을 끊지 않고 동일한 세션으로 통신을 시도함.
2. keep-alive 시간이 default 값인 5초로 설정되어 있음.
3. 5초 내로 들어오면 연결이 이어져서 응답값이 정상적으로 전달되지만, 5초가 지난 시점과 거의 비슷하게 API 요청을 해버리면 응답값을 주지 않고 통신을 종료해 버림.
우리는 Loopback API를 사용하는데, Loopback 은 nodejs 기반이라, keep-alive를 따로 설정하지 않으면 nodejs의 keep-alive default 값인 5초를 따른다더라. 처음 알았다. 그동안에는 스케줄을 돌면서 주기적으로 요청하던 게 없어서 이런 현상이 재현되지 않았던 걸로 추정된다.
원인은 어느 정도 알게 되어.. 타 팀에서 axios로 수정도 했지만... 여전히 동일한 현상이 재현되었다...~~ nodejs 가 이렇게 허술할 리가 없는데.. 하는 의문도 함께 존재하였지만.. 일단 그다음 날로 넘겼다.
4. "왜 서버에서 FIN 패킷과 RST 패킷을 보내지?" (02/01 목)
이 날은 패킷 분석을 계속했다. 인프라 운영팀 주임님에게 방화벽 세션 트래킹 파일 요청드리기도 하고.. 우리 서버에서 tcpdump 뜬 거 비교했다. 패킷 속에서 알게 된 건, 저 쪽에서는 요청하고 있는데 우리 서버에서 일방적으로 FIN 패킷도 보내고, RST 패킷도 보내서 연결을 끊어버리는 것이었다. 그렇게 끊어진 연결 때문에 응답값을 전달받지 못해 저 쪽에서 에러가 발생했던 거다.
쉽게 설명하면, 약간 이런 느낌이다. A가 클라이언트고, B가 서버다. 서버가 우리 팀꺼다.
A : 우리 이것 좀 보내줘~
B : 으응~~ 응답값 이거야~
A : 우리 이거 다른 건데 한 번 더 보내줘~
B : (엥.. 기다려도 뭐 요청 안 오네..) 우리 통신 끊을게~? (FIN 패킷)
A : 엥 어어 끊어~
타 팀 팀장님과 우리 팀장님은, 방화벽 어디선가 요청을 막고 있는 게 아닌가 하고 생각을 하셨다. 그 서비스와 우리 서비스 사이에 방화벽이 총 3개가 있다고 했다. 두 개의 방화벽은 연구소 서비스망, 메인 방화벽이고, 나머지 하나는 확인할 수 없는 다른 곳에 있는 방화벽이었다. 가로막고 있는 게 많지만 나머지 하나를 확인할 수 없으니, 전략을 다음과 같이 세웠다.
[방화벽 확인 전략]
1. 우리 서버 tcpdump 로그를 pcap 파일로 저장
2. 타 팀 서비스가 설치된 서버의 tcpdump 로그를 pcap 파일로 저장
3. 두 개의 방화벽에서 패킷을 확인하여, 어디선가 전달을 하지 못하고 있는 건 아닌 지 확인
이 부분을 확인하러 타 팀 팀장님과 주임님이 다른 층으로 내려가서 패킷 분석하고 오셨는데.. 방화벽에 막힌 게 없다더라. ㅋㅋㅋㅋㅋ 하하.. 이 날도 이렇게 지나갔다.
아... 그 테스트하려면 하나의 에러를 해결해야 했는데... ㅋㅋㅋㅋ 그건 다른 엔진 모듈의 문제였다. 데이터를 제대로 저장하지 않아.. API 동작 중 에러가 발생해서, 타 팀 서비스에 에러를 그대로 뱉어내는 이슈가 있었다. 그래서 그다음 날에 엔진 모듈에서 에러 발생할 경우를 대비해 에러 처리를 추가하였다.. 😋
5. " 두 서비스를 같은 곳에 설치해서, 방화벽 문제를 제거해 봅시다"(02/02 금)
오늘 새로 알게 된 사실은, 7번째 요청까지는 정상적으로 가는데 8번째부터 에러가 발생한다는 것이었다. 총 3개의 API를 한 세트로 요청을 하니,, 대략 21개 정도는 정상적으로 응답하고, 그 이후부터는 에러가 발생하는 것이다. 테스트를 위해 API 입력 개수를 줄이고 API 요청 간 sleep을 둬서 요청 간격을 늘리기로 했다.
또, 테스트를 위해 2개 API를 수정하였다. 다신 에러 안 찍히게 하려고 최대한 꼼꼼히 보고 수정했다. 그 이후 실제 사용 중인 서버에 부분패치 후 타 팀 주임님에게 말씀드렸다.
두 팀장님들께서는 두 서비스를 같은 곳에 설치하여.. 방화벽 문제를 없애버리자고 말씀하셨다. 요청이 유실되는 일이 없게, 방화벽이라는 변수를 제거하자는 것이었다. 지금 이 시간쯤이면 설치가 완료되었을 것이다. 아까 오전 중에는 또 장비 문제도 있어서 설치 시간이 늦어졌다. 우리 팀장님이 이거 문제 해결하는데, 별의별 문제가 다 나온다며 헛웃음..?ㅋㅋㅋㅋㅋ 을 지으셨다.ㅋㅋㅋ 그 특유의 웃음을 지으셨다.. 허허.. ^^.. 하시는 모습. ㅋㅋㅋㅋ
6. 앞으로 할 일 (02/05 월)
이제 월요일에는 방화벽 문제는 싹 사라졌으니, 그때 테스트를 다시 진행해 볼 예정이다. 이제 그때도 안되면, 원인 분석을 해야 한다. 서버에서 어떤 이유로 RST 패킷을 보내는 건지, 방화벽 이슈도 없는데 다른 변수가 무엇이 또 있을지 계속 생각해야 한다.
관련하여 2/7 (수)에 시연 진행 예정이라 월요일에는 무조건 해결이 되어야 한다고 하셨다. ㅋㅋㅋ 야근은 진짜 괜찮은데, 문제가 잘 해결될지.. 내가 여기서 더 뭘 할 수 있을지를 모르겠다. 루프백 쪽에서 keep-alive 시간 조정하는 방법이나 .. DB Connection Pool 때문일 수도 있으니 그것도 늘려보고 .. 또 뭐가 있을까... 일단 그거 말고도 방법이 있을 지 계속 생각해 봐야겠다. 😂
다 지나갈 거다.. ㅠ_ㅠ 얼른 웃으면서 글 보는 날이 오면 좋겠다. 오긴 올 거다. 내가 그 사이에 얼마나 갈려있을지는 모르겠지만.. ㅋㅋㅋㅋㅋㅋㅋ 파이팅해보자~ 🥰