Cloudflare에서 성능저하가 심하게 발생한다! ( AWS EC2 + ACM + CloudFront + Route53 + WAF 로 전환하기 )

TLDR

또 한 번 AWS를 활용하여 웹서버 배포하는 방법입니다. 이전에는 CloudFront를 활용하여 https 웹 서버를 배포하였지만, 여기에 중요한 이슈가 발생했습니다.

Cloudflare의 속도 저하

위 사진처럼 api response를 받는데 평균적으로 350ms정도 소요되었고, 이게 웹뷰 앱으로 구성된 저희 앱으로 가게 되면 비교적 네트워크 속도가 느린 모바일에서 로딩이 좀 더 길어지게 되었습니다. 유저가 이탈할 거라고 우려될 수준으로 치명적인 속도였고, 개선을 위해 코드/DB 등의 개선을 진행했으나, 저 속도저하의 본질은 Cloudflare라는 것을 뒤늦게 알게 되었습니다.

Cloudflare는 CDN 서비스를 제공합니다. 전세계 각국에서 접근했을 때, 가장 가까운 edge server에서 캐시 된 파일을 전달해 주는 이 CDN 기능에 한국 서버가 없습니다. 정확히는 한국 서버가 있으나 이를 이용하기 위해서는 가격 정책 중 가장 비싼 정책을 선택해야지 지원받을 수 있었기에 보다 저렴한 비용으로 운용할 수 있는 AWS CloudFront를 활용하기로 했습니다.

Cloudflare 대체하기

Cloudflare를 이용하는 것만으로도 받았던 혜택을 이제는 직접 구현해야만 했습니다. 직접 구현/설정 할 기능을 크게 아래 세 가지로 정의했습니다.

1. SSL/TLS 인증서 발급을 통해 https 지원
2. CDN 서비스
3. DDos, Bad Bot 차단과 같은 보안 

각각의 기능을 구현하기 위해 AWS의 ACM / CloudFront / WAF 로 Cloudflare를 대체한 방법에 대해 소개해 드리려고 합니다. ( CloudFront와 WAF 는 부가적인 비용이 발생합니다 )

 

Route53 호스팅 영역 생성

저는 이미 구현된 웹서버의 CloudFlare를 걷어내고 하는 작업이라 이미 선행되어 있는 부분이라 따로 이미지를 첨부하지는 못했습니다. Route53에서 호스팅 영역을 생성하고 DNS에서 구매하거나 갖고 있는 도메인을 집어넣습니다.

이후 Route53에 들어가면 유형이 NS로 된 4개의 값이 들어있는 컬럼이 있을 건데, 해당 4개의 값을 DNS 관리 사이트의 네임서버란에 입력해 줍니다. 또한 해당 도메인을 레코드 이름으로 웹 서버 배포 설정을 마친 EC2 인스턴스의 Public IP를 값으로 레코드를 하나 생성해 줍니다. ( 여기서 관련 내용을 자세히 작성하지 않습니다. 제 이전 포스트를 참고해주시면 될 것 같습니다 )

 

인증서 발급받기

그리고 SSL/TLS 인증서를 발급받아야 합니다. ACM을 통해서 받은 인증서는 CloudFront를 구현하는데 필요하기 때문에 인증서를 발급받는 방법에 대해 소개해드리겠습니다.

우선 인증서를 발급받을 때, 지역은 버지니아 북부 ( us-east-1 )로 생성해야 합니다. ( cloudflare에서 사용하는 acm 은 해당 region에서만 가능하기 때문입니다 )

ACM 인증서 생성

ACM 도메인 설정

AWS ACM에 들어가 다음과 같은 과정을 통해 생성을 진행합니다. 도메인은 구매한 도메인을 입력하면 되는데, 만약 저희 서비스처럼 도메인 내에 서브도메인으로 분리된 서버가 있다면, 해당 도메인을 전부 작성하거나 제가 적은 것처럼 *. domain.com을 해서 인증서를 발급받습니다.

인증서 생성이 완료되었으면 " Route 53에서 레코드 생성" 버튼을 눌러서 Route53에 레코드를 자동으로 생성하고, 승인되기를 기다립니다. ( 여기서 제 체감상 승인이 5분 내로 완료되었습니다. 만약 10분 이상 걸린다면 저는 삭제하고 다시 한번 살펴보고 수정한 후 재 생성 했습니다 )

 

CloudFront 설정하기

ACM을 통해 인증서를 발급받고 승인 완료 되었다면, CloudFront를 설정하고 배포할 준비가 끝났습니다. CloudFront에서 배포를 하고 아래 내용을 저는 설정했습니다.

• Origin Domain : EC2 IPv4 DNS를 복사 붙여 넣기
• 프로토콜 : HTTP만 해당
• 뷰어 프로토콜 정책 : Redirect HTTP to HTTPS
• 허용된 HTTP 방법 : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
• 가격 분류 : 모든 엣지 로케이션에서 사용
• 대체 도메인 이름 : 사용하는 도메인 및 서브도메인 전부 작성
• Custom SSL certificate : ACM 발급받은 인증서 설정

 

Route53에 서브 도메인 및 도메인 값 수정

CloudFront 배포를 마쳤으면, Route53으로 들어가서 서브도메인 및 도메인 값을 수정합니다. 기존 도메인 값은 EC2의 IPv4 값이 들어 있었지만, A 유형의 별칭을 통해 CloudFront를 선택할 수 있습니다. 다른 서브도메인도 CNAME으로 하면 별칭을 선택할 수 없어서 A 유형의 별칭을 통해 CloudFront를 선택합니다.

 

WAF

모든 배포과정이 끝났다면, 여기서 WAF을 바로 안 넣고 웹서버의 기능이 정상적으로 구현하는지 테스트해보아도 됩니다. 이미 모든 기능 구현이 완료되고 방화벽만 넣지 않았기 때문에 모든 기능이 잘 동작하는지 확인하고 마지막으로 WAF을 넣으면 제 작업은 마무리됩니다.

Web ALCs에 접속해서 Global(CloudFront)를 선택해서 Create web ACL을 통해 ACL을 생성합니다.

• name 입력
• Add AWS resources에서 CloudFront선택

이후 Rules를 선택할 수 있으니, 필요에 맞게 적용하시면 됩니다.(적용되는 RuleSet 에 따라 비용이 추가적으로 뜨니 예산에 맞게 설정하시면 됩니다.) 

 

마무리

이렇게 AWS EC2 + ACM + CloudFront + Route53 + WAF로 웹 서버를 배포하는 방법에 대해 작성했습니다.

CloudFlare의 성능 문제가 생각이상으로 심각했습니다. 유저입장에서는 앱이 멈췄나? 버그인가 싶을 정도의 버벅거림이 있었고 특히 앱을 처음 키고 접속하고 웹페이지가 로드될 때까지 모바일 네트워크속도가 조금이라도 느리다면, 치명적으로 느껴졌습니다.

그래서 앱이 서비스가 진행되던 중 새벽 시간을 이용해 CloudFront로 변경 작업을 진행했습니다. 블로그에는 간략하게 적혔으나, 2시간 예정되어 있던 작업은 2시간 반 조금 넘게.. 진행되었지만 어느 정도 잘 마무리된 것 같습니다