이전에 AWS EC2를 활용하여 서버를 배포해 본 경험이 있었지만, 이번 프로젝트를 진행하면서 예상을 뛰어넘는 에러가 발생하여 고전했던 경험이 있었다. 이번 프로젝트를 경험으로 여러 문제를 겪고, 이를 해결한 과정에 대해서 기술하고자 한다.
EC2 서버 성능 문제
docker build 과정에서 만난 Killed
이번 프로젝트에서 EC2 인스턴스를 프리티어 버전(cpu: 1core, ram: 1g)을 사용하였다. 이전에 사용했던 인스턴스의 성능은 유료버전을 사용했었는데(cpu: 2core, ram: 4g), 프리티어로 build를 진행하던 도중 진행상태가 멈춰버리고 결국에는 Killed가 뜨면서 강제로 build가 멈춰버렸다. 이러한 경우는 처음이었고 로컬환경에서 build를 진행하였을때는 전혀 문제가 없었는데 갑자기 배포 서버에서 이러한 에러가 난 이유를 알 수 없었다.
곰곰히 생각하다 Killed 자체의 이유를 생각해 보았다. 결국 강제로 프로세스가 종료되었다는 것인데 이러한 이유 대부분은 cpu나 ram사용량을 초과하여 일어나는 것임을 추측할 수 있었다. 하지만 이정도 크기의 프로젝트에서 Killed가 발생할 정도라고 생각하기에는 납득이 쉽지 않았지만, 일단 프로젝트 크기를 줄이는게 맞다고 생각하였다. 이 생각을 하기 전에 했던 뻘짓은 Dockerfile 안에 option으로 컴퓨터의 cpu, ram 자원 사용량의 limit를 최대로(--cpus=1 --memory=1) 해 보았지만 의미는 없었다. 어짜피 최대한 뽑아서 쓸라고 했겠지만 터진거 였을테니..
그래서 우리 프로젝트에서 사용중인 라이브러리 중, 대체가 가능하거나 크게 필요하지 않는 라이브러리는 삭제하는 작업부터 들어갔다. 프로젝트를 진행하면서 팀원들끼리 라이브러리 추가 설치에 대해 알리고 서로 인지하고 있었지만 하나 둘 추가하다보니 너무 많아진 부분이 있었고, 중복설치나 유사한 기능의 라이브러리들을 하나로 통합하였다. 예를 들어 icon을 react-icons와 antd 를 사용하고 있었는데 antd로 통일시키거나 중간에 다른 팀원이 사용하지 않는 라이브러리들을 삭제하였다.
적용 후에 다시 build를 진행하였고, 무사히 빌드가 완성되어 up 시켜 사이트에 접속했을때 메인페이지가 나오게 되었다. 하지만...
성능 문제는 끝나지 않았다
배포된 서버로 접속하고 다른 페이지로 넘어가자마자 바로 페이지가 프론트 서버와 연결이 끊겨버리는 문제가 발생한 것이다. 이런 문제가 발생한 원인 자체를 알 길이 없었다. 이번에는 Killed 라는 에러 메세지도 나오지 않았고, 그냥 up 시켰던 도커 컨테이너 자체가 사라져버리는 것이다.
그리하여 원인을 찾던 중.. docker stats 라는 명령어를 치면 docker container에서 사용하고 있는 cpu, ram 사용량을 실시간으로 추적할 수 있는 기능을 알게 되고, up 시킨 후에 바로 명령어를 쳐서 컨테이너의 상태를 보고 있었다.
배포한 사이트에 들어가자마자 cpu 사용량이 급증하더니 결국에는 90% 이상에서 100%가 뜨더니 컨테이너가 사라져 버렸다. 이런 원인은 결국 최초 사이트 진입시 요청되는 이미지들의 용량과 양이 많아 처리를 하다 터져버린 것이라고 생각했다.
그리하여 이미지 확장자를 .webp 로 전면 교체하고 그래도 용량이 좀 크다 싶은 것은 전부 새로운 이미지로 교체하였다. 사실 이러한 이미지 용량에 대해 별 큰문제 없이 생각했다. 내 로컬 환경에서는 잘 돌아갔으니까. 하지만 EC2 에서 빌린 성능은 좋지 않았기 때문에, 이러한 문제에 대해 반성하는 기회가 되었다.
다시 개선 후 stats를 보니.. 접속해도 순간 cpu가 50%~60% 사이로 뛰더니 금방 10%대 아래로 줄어들게 되었고, 사이트는 정상적으로 작동하였다. 이러한 경험은 처음 있는 일이었기 때문에 고생도 많이 했지만 나에게 있어 최적화의 중요성을 피부로 와닫게 해 준 경험이었다.
HTTPS SSL 인증서 문제
HTTP로의 접속은 가능해 졌지만, HTTPS로 접속하기 위해서는 SSL 인증서 발급을 받아야 가능하다. 이전에 AWS EC2에서 HTTP, HTTPS 규칙 설정에서는 SSL 인증서가 따로 이미 만들어진 것이 있어 그대로 사용했기 때문에 문제가 되지 않았지만, 이번 프로젝트에서는 새로 발급을 받아야 했다. 하지만 발급 신청을 누르고 몇 시간이 지나도 심사중이라는 상태였기 때문에 이상하다는 느낌을 받았다. 왜 그런가 문제를 찾던 중, 로드밸런서의 라우팅을 Route 53 에서 편집을 해야한다는 것이었다.
Route 53 의 호스팅 영역에 들어가 레코드 영역에서 유형들을 편집해야한다.
레코드 속성중에 유형이 A 인 레코드의 값을 EC2 -> Load balancers -> 생성한 로드밸런서의 DNS name의 값으로 적용시켜야 하는 것이다.
여기서 로드밸런서를 통해 통신할 때 IPv4 or IPv6 주소를 둘다 사용하는 DualStack 로드밸런서를 구성한다면, dualstack.(만든 로드밸런서 이름 + 맵핑 지역) 의 방식으로 A 레코드의 값을 변경시켜주면 정상적으로 인증서 발급이 완료되고 HTTPS 접속이 가능해진다.
이 뿐만 아니라, HTTP 연결시도시 리다이렉팅 설정으로 HTTPS 로 접속하도록 설정해 놓았다.
외부 도메인을 AWS Route 53에 등록하기
이전에 사용했던 방법은 AWS Route 53에서 도메인을 직접 구입해서 사용했지만, 이번에는 가비아에서 도메인을 구입하고, 도메인 관리를 AWS에 위탁하여 적용하게 되었다. 방법은 의외로 간단하다.
도메인을 구입 후, 상세 설정에서 네임서버를 Route 53 레코드 영역에서 NS 유형의 레코드의 라우팅 대상의 값을 가비아의 네임서버에서 수정하여 Route 53 에서 관리하도록 설정해주면 끝이다.
GCP, AWS 둘 다 프론트 서버 배포를 해본 경험이 있었지만, 야매로 배운것 같아 이번 프로젝트에서 다시 배포를 시도했을 때, 문제점을 찾고 해결하는데 시간이 좀 걸렸던 것 같다. 이번 배포를 통해서 배포시 설정해야 되는 것들에 대해 자세히 숙지할 수 있는 기회였고, 경험해보지 못한 에러를 만나 배울 수 있는 점이 있어서 좋았다.
