클라이언트와 서버 포트로 인해 발생했던 보안 그룹 문제

개요

배포하고 조금씩 수정하면서 만져보던 중 초기 연결 1.3분이라는 말도안되는 현상을 발견했다.

하지만 초기 연결만 그렇고 한번 연결되면 통신 속도는 지극히 정상적으로 보였다. 아무래도 tcp로 서로 연결되어 그런건가 생각하고 해결책을 고민해봤다.

 

해결

chatGPT에 질문하고 하나씩 해결해보고자 했다.

 

서버 로그 확인

서버 로그를 확인한다는게 뭔지 잘 몰라서 배포되어있는 Nginx로그를 살펴봤다.

[26/Mar/2023:00:45:02 +0000] "GET / HTTP/1.1" 404 63 "-" "Linux Gnu (cow)”

[26/Mar/2023:01:09:31 +0000] "" 400 0 "-" "-”

 

이걸보고 성능 문제라고 (잘못) 생각해서 http/1.1이 아닌 http/2를 활용해야하는건가 하고 삽질을 했다.

하지만 http1.1, 2버전의 차이를 잘 생각해보면 1.3분에서 유의미한 성능 개선을 보일 수 있을까라고 생각해봤을 때 그건 아닐거같다는 생각이 들어 급히 회전했다.

 

서버 구성 확인

우선 Nginx 설정을 만져봤다. 위 사진에선 보이지 않았지만 keep_alive 설정을 몇 가지 조사해본 결과 keep alive는 tcp 커넥션을 유지하기 위한 옵션으로 연결을 계속 유지하면서 성능을 위한 옵션이지 단순히 초기 연결에 대한 문제를 해결해주지 못했다.

 

이후 로컬에서 서버를 다시 구성해보면서 도커 네트워크 구성 문제가 있는지 확인했다. 하지만 역시 문제는 없었다.

 

GCP CloudDNS 옵션

이후엔 배포 세팅을 조금 뒤져봤다

Slow initial connection to Google Cloud App Engine

답변들을 읽어보니까 인스턴스 그룹 포트 문제가 있었다는 것을 확인하고 포트와 도메인 설정들을 찾아보았다. 문제는 이전에 삽질하면서 만들어놓은 여러 인스턴스의 포트들이 열려있었다.
정리해보니 기존 인스턴스와 새로운 인스턴스간 레코드와 포트가 꼬여있었다. 하지만 로드밸런서는 이미 닫혀있던 포트의 security group 응답을 계속 대기하다가 응답없음이라는 에러를 띄우지않고 아예 리다이렉트 시켰기 때문에 발생했다.

  
http -> https 리다이렉션하는 설정이 있었는데 그 부분을 삭제하고 이후 80번 포트를 그냥 닫아버렸다.

443포트만 열어두고 어떤 동작을 하는지 이해하게 되었다.

 

이후 http secure로 모든 값들을 확인해보고 변경해주었다. 그렇게해보니 초기연결시간 문제 없이 잘 진행되었다.

 

회고

chatGPT가 잘 설명해주긴하는데 제대로 설명하지 못하면 도통 말이 통하지 않는다. 뿐만 아니라 잘못된 답변을 매우 빈번하게 해서 효율적으로 공부하기 위해서라도 답변과 제공해주는 자료의 크로스체크는 필수라고 생각한다