서론
부트 캠프에서 팀 프로젝트를 배포하기 위해서 AWS의 Route53 + EC2를 사용했었다. 첫 가입 시에 주는 크레딧으로 배포 환경 개발과 프로젝트 발표까지 마쳤지만 리팩토링, 디자인과 성능 개선을 하려고 계속 배포해놓기 위해 GCP를 사용했다.
뭐야 이거 왜 이래?
AWS로 배포할 땐 인스턴스에 레포를 클론해 빌드했었고 매끄럽게 잘 작동했는데 GCP로 옮기자마자, 랜딩 페이지에서부터 미친듯이 느려진 렌더링 속도, 렌더링이 랜덤으로 되는 비디오 등 여러가지 문제가 발생했다.
추측해보기
이전에 배포했을 때와의 차이점을 생각해보면서 하나씩 소거해나갔다. 이전 프로젝트 배포 때와 크게 달라진 점은 도커 도입과 플랫폼 변경이었다.
도커 킷사마!
이 때 가장 처음 생각난 것은, 바로 도커였다. 이전 AWS의 EC2에 그대로 배포할 때와는 달리, 이번에는 인스턴스에 도커를 올리고 도커 위에 배포를 했기 때문이다.
이미지와 컨테이너를 전부 지우고 도커 파일을 다시 확인하고, 포트 설정을 정확하게 다시 해봤지만, 이슈는 고쳐지지 않았다. 혹시나 싶어 도커 컨테이너의 상태를 살펴봤지만, 과부하가 일어나는 곳은 보이지 않았다.
GCP... 너냐...?
그 다음 타겟은 플랫폼 변경, GCP였다.
결론부터 말하자면, 원인은 GCP가 맞았다. (결국 내가 잘못한 거지만)
처음에는 GCP의 인스턴스가 문제라고 생각했다. AWS에 비해서 성능이 떨어졌었나? 싶었고 다시 확인해본 결과, AWS에서 프리티어로 제공해주는 인스턴스 중 t2.micro가 성능이 제일 좋은데 GCP에서 사용한 기본값인 e2-medium이 수치를 대충 봐도 몇 배는 더 좋아보인다...
(위에서부터 아래로 AWS, GCP의 인스턴스이다.)
그래도 이번에는 도커를 추가했고 혹시 그 때문에 VM에 과부하가 걸려서 사이트가 저런가 싶어서 인스턴스의 상태를 모니터링해봤다. GCP 콘솔에서는 VM 모니터링을 통해 인스턴스의 상태를 쉽게 살펴볼 수 있게 되어있다. 그리고 확인해본 결과, VM 상태는 전혀 문제가 없었다.
해결
배포에 대한 지식이 1도 없던 내가 AWS나 GCP를 이용하여 배포를 할 수 있었던 건, 부트 캠프의 수업과 수업 자료 덕분이었다.
자료를 보며 초기 설정을 진행할 때 실수한 것이 있는지 하나하나 찾아보다가 차이점을 발견했던 곳은 바로 로드 밸런서의 백엔드 서비스 구성에 있는 health-check(상태 확인) 부분이었다.
자료에는 health-check의 포트 설정을 TCP로 설정하라고 나와있었고 나의 health-check 포트 설정은 HTTP로 되어 있었다. 포트를 TCP로 변경하자마자, 사이트가 매우 빠른 속도로 응답을 보내주기 시작했다.
해결을 먼저하고 검색해서 찾아보니 공식문서에서도 내가 사용한 전역 외부 HTTP(S) 부하분산기를 사용할 경우 TCP 포트를 지정하라고 나와있다.
후기
정말 사소한 실수여서 황당했지만, 그만큼 다행이라는 생각도 들었다. 플랫폼을 옮기는 과정에서 프로젝트가 무거워졌던 거라서 최적화를 해줘야하는 건가, 그냥 도커를 빼버릴까, AWS 계정을 하나 새로 파서 올리는 게 나으려나 등 정말 오만가지 생각을 다했던 것 같다.
그리고 이번 기회에 TCP와 HTTP의 차이점, GCP의 health checker 동작 방식을 면밀히 알아볼 생각이다.
