[infra] Heroku, AWS 이전

Heroku에서 AWS로 이전하기

회사에서 기존에 설정된 인프라로 Heroku 로 사용하고 있다가 aws 로 이전을 시도했다.

최근 웹 프론트엔드 일을 하게 되면서 웹사이트의 응답 속도에 대해서 관심을 기울였다. 일반적으로 공백 줄이고 파일 크기 줄이는 min 등의 파일 최적화라던가 사용하고 있는 라이브러리 CDN이라던가 그런 asset 최적화야 당연한 것이지만 실제 적용했을 때 원래 네트워크 레이턴시가 느린 경우에 비해서 속도 향상이 작다는 결론을 내렸다.

물리적으로 Heroku의 Public Region이 유럽, 미국으로 제한되어 있어서 한국에서 느리다는 것이 주요 문제였다.

얼마나 느린지는 국내에서 ab를 기준으로 간단히 측정했다.(Firebase 정적 호스팅도 검토했다.)

Heroku(US Region)

0.5~0.656초

Firebase(Static Hosting)

0.3~0.418초

AWS(Seoul S3 기준)

0.02~0.040초

테스트 해보니 대략적으로 어느 클래스인지 차이가 나는지 비교가 되었다.

Heroku

헤로쿠의 경우 Public Region 외에 도쿄 등의 Private Region이 존재한다. 프라이빗 리전을 사용하기 위해서는 엔터프라이즈 회원이 되어야 하는데 연간 $20800 이상의 소비를 할 수 있는 서비스여야 가능하다고 담당자에게 메일로 회신을 받았다.

Firebase

파이어베이스의 경우 헤로쿠 못지 않는 정적 호스팅을 서비스를 제공하지만 동영상 광고로 보여주고 있는 CDN이라고 생각하기에는 예상 외로 많이 느렸다. 차라리 주요 서비스 지역은 지역별 아마존 EC2를 쓰고 나머지 지역에는 클라우드 프론트를 쓰는 것이 낫겠다는 생각이 든다.

AWS

Heroku 처럼 편리하게 디플로이 하려면 Elastic Beanstalk 가 적당하겠다는 생각을 했다. 빈트토크는 내부적으로 Cloud Formation 으로 셋팅을 하고 설정에 따라서 ELB + EC2 를 엮어 준다.

(1) 언어별로 aws 가 제공하는 기본 배포 방식이 있다. 다만 특정 언어 버전의 제약사항이 존재한다. 예를 들면 루비 2.3.0 으로 고정이다. 취향에 따라서 docker 형태로 배포 가능하다.

(2) 삽질 주의사항으로 VPC가 있어야 한다. 보통 Default VPC로 자동으로 셋팅을 해서 존재를 생각할 필요가 없지만 Default VPC가 없으면 만들어서 지정해줘야 한다. VPC설정을 제대로 하지 않으면 ElasticBeansTalk 생성시 EC2 -> ELB 통신이 되지 않아서 런칭하는데 실패하게 된다.

(3) eb는 사용해보면 정말 편하다. zip 파일로 압축해서 S3에 업로드, EC2 배포 되는 구조인데 트래픽에 따른 오토스케일링도 가능하다.

(4) 현재 docker 를 사용해서 서버 배포하고 있는데 heroku 에 비해서 로그 확인하기가, 정확히는 필터링하기가 번거롭다. 물론 스크립트를 짜서 확인하면 되기는 하지만, docker 로 래핑되어 있으면 더더구나 헤매는 것 같다.