AWS Global Accelerator

AWS의 네트워킹 서비스 중 하나인 AWS Global Accelerator에 대해 소개 및 유사한 특징을 가진 서비스인 CloudFront와 어떤 차이가 있는지 소개해드리려합니다.

AWS Global Accelerator 서비스란

AWS Global Accelerator 서비스는 엣지 로케이션에 구성된, 2개의 고정 Anycast IP를 가진 Accelerator를 통해 사용자의 접속 위치가 가장 가까운 엔드포인트(ELB, EC2 등)로 트래픽을 라우팅합니다. 엣지 로케이션에서 엔드포인트까지의 트래픽은 AWS 글로벌 네트워크(AWS의 중첩된 100G 네트워크)를 이용하여 전송되기 때문에 Accelerator를 사용하지 않고 공공 인터넷망을 통해 엔드포인트에 접근하는 것에 비해 낮은 지연시간을 유지할 수 있습니다.

또한 하나의 Accelerator에 여러 리전에 구성된 엔드포인트 그룹을 생성하여 하나의 도메인으로 여러 리전에 구성된 엔드포인트로 사용자의 위치에 따라 트래픽을 라우팅할 수 있습니다.

CloudFront 와의 차이점

AWS Global Accelerator 와 클라우드프론트는 서비스의 특성상 분산된 엣지로케이션을 통해 오리진 리소스로의 트래픽을 가속화한다는 점에서 유사한 특징을 가지는데요. AWS Global Accelerator 와 클라우드프론트 간의 차이는 아래와 같습니다.

1. AWS Global Accelerator는 캐싱 기능이 없습니다. 정적 컨텐츠를 캐싱하는 기능은 클라우드프론트에만 있습니다.

2. 클라우드프론트는 Web 기반이지만 AWS Global Accelerator는 TCP, UDP 기반이기 때문에 처리할 수 있는 프로토콜의 폭이 더 넓습니다. AWS Global Accelerator는 게임, VoIP(인터넷 전화) 등 클라우드프론트에서는 처리가 불가능한 프로토콜도 수용이 가능합니다.

3. 클라우드 프론트는 CNAME 레코드를 통해 사용자의 지리적 위치, 네트워크 지연시간을 기준으로 다른 엣지로케이션으로 연결되나, AWS Global Accelerator 는 Anycast IP를 통해 사용자의 지리적 위치와 가까운 엣지로케이션으로 연결됩니다. 때문에 Accelerator의 아이피는 지리적 위치와 관계 없이 고정됩니다.

4. AWS Global Accelerator는 클라우드프론트에 비해 변경사항에 적용되어 전파되는 시간이 빠릅니다.

AWS Global Accelerator 구성

로드밸런서 생성 시 추가 서비스 부분에 AWS Global Accelerator에 대한 활성화 여부 옵션이 있기 때문에 로드밸런서 생성 시 Accelerator를 함께 생성 가능하며, AWS Global Accelerator 콘솔로 이동 시 로드밸런서와 함께 Accelerator가 생성된 것을 확인할 수 있습니다. (굳이 로드밸런서 생성 시 생성할 필요는 없으며, AWS Global Accelerator 콘솔에서 따로 Accelerator 생성해도 관계 없습니다.)

Accelerator 는 트래픽을 수신할 포트를 정의하는 리스너를 가집니다.

리스너에는 리전 별 ELB, EC2 등 엔드포인트가 포함된 엔드포인트 그룹이라는 개체가 포함되어 있으며, 엔드포인트 그룹을 추가로 생성하여 트래픽을 라우팅할 다른 리전의 리소스를 추가해줄 수 있습니다.

리스너 생성 시에는 동일한 클라이언트 아이피에서의 요청이 동일한 엔드포인트로 전달되도록 하는 설정인 Client affinity 설정을 활성화할 수도 있습니다.

테스트 환경에서는 버지니아 북부 리전과 서울 리전에 각각 구성된 로드밸런서로 사용자의 위치에 따라 접속이 되는 것을 확인해봅니다.

먼저 현재는 버지니아 북부 리전으로 설정된 엔드포인트 그룹만 생성되어 있으며, ALB를 엔드포인트로 추가했습니다.

Accelerator의 도메인인 http://ac32613862c2fbf4d.awsglobalaccelerator.com 으로 접속했을 때, 버지니아 북부 리전의 로드밸런서로 연결되며,

TTFB(Time To First Byte, 첫 바이트를 수신하기 까지의 소요시간)은 200ms 전후로 확인할 수 있습니다.

이제 Add endpoint groups 로 서울 리전의 엔드포인트 그룹을 생성하여, 서울 리전에 구성된 로드밸런서를 엔드포인트로 추가해줍니다.

이제 아래와 같이 엔드포인트 그룹이 버지니아 북부 리전과 서울 리전으로 구성된 것을 확인할 수 있습니다.

잠시 변경사항이 전파된 후 페이지를 새로고침해보면 서울 리전의 ELB로 연결되어 다른 화면이 보이는 것을 확인할 수 있습니다.

TTFB 값은 10ms 전후로 나타납니다. 버지니아 북부 리전으로 연결될 때에 비해 약 20배 차이가 있는 것을 확인할 수 있습니다. (리전 별, 접속자의 위치에 따라 어느정도 차이는 있을 것 같습니다.)

테스트 간 이해되지 않는 점

위의 테스트의 경우 2개 리전에 구성된 엔드포인트로 사용자의 접속 위치에 따라 다르게 연결되는 것을 보여줍니다. 하지만 다수 리전이 아닌 단일 리전으로 구성된 서비스의 경우에도, AWS 글로벌 네트워크를 통해 트래픽 가속(최대 60%까지)이 되는 것으로 내용을 파악하였으나,

실제로 단일 엔드포인트 그룹으로 구성하여 Accelerator를 통한 접속과 로드밸런서로 직접 접속을 비교하였을 때에 네트워크 지연시간의 별다른 차이가 없는 것으로 확인했습니다.

Accelerator를 통해 접속

로드밸런서 직접 접속

tracert 명령어로 라우팅 경로를 확인 시에는 홉수의 확연한 차이가 있는 것으로 보이는데, 실제 웹을 통해 접속시에는 별다른 차이가 없는 점이 조금 의아합니다.

Accelerator로 접속 경로

로드밸런서로 접속 경로

적용 상 한계점

AWS Global Accelerator 를 이용해 사용자의 접속 위치에 따라 다른 리전에 구성된 엔드포인트로 연결은 가능하지만, 리전간 사이트 회원정보의 통합이 필요한 경우

1) 하나의 DB에 데이터를 쌓도록 구성하거나,

2) 별도의 DB에 구성된 데이터를 동기화 시키는 작업이 필요하기 때문에

여러 리전에 걸쳐 동일한 사이트처럼 보이더라도 DB에 저장된 데이터에 대한 처리를 어떻게 할 지 고민이 필요할 것 같습니다.

결론

AWS Global Accelerator 를 한마디로 표현하자면 "여러 리전에 구성된 로드밸런서(혹은 EC2 등)로 트래픽을 로드밸런싱하는 서비스"라고 할 수 있을 것 같습니다. (단일 리전의 경우 트래픽 가속(지연시간 감소)에 대한 부분이 눈으로 확인되지 않았습니다.)