BLOG
Amazon Virtual Private Cloud(VPC) 네트워크에서 복원력 있는 시스템을 구축할 때의 모범 사례 중 하나는 여러 가용 영역(AZ)을 사용하는 것입니다. AZ는 예비 전원, 네트워킹 및 연결이 있는 하나 이상의 개별 데이터 센터를 의미합니다. 이러한 여러 AZ를 사용하면 단일 데이터 센터에서 가능한 것보다 더 높은 가용성, 내결함성 및 확장성이 있는 워크로드를 운영할 수 있지만, 지연 시간과 비용이 추가된다는 단점이 있습니다. 이번 포스팅에서는 다중 AZ 아키텍처의 이점을 유지하면서 성능을 개선하고 비용을 절감하는 ‘Availability Zone Affinity’라는 아키텍처 패턴을 알아보겠습니다.
교차 가용 영역 효과
AZ는 물리적으로 동일한 AWS 리전의 다른 AZ와 서로 60마일(100km) 이내에 유의미한 거리만큼 떨어져 있습니다. 이로 인해 동일한 리전의 AZ 간에 일반적으로 1-2밀리초(ms) 미만의 왕복 지연 시간이 발생합니다. 동일한 AZ에 있는 두 인스턴스 간의 왕복 지연 시간은 향상된 네트워킹을 사용할 때 100-300마이크로초(µs)에 가깝습니다. 1인스턴스가 클러스터 배치 그룹을 사용하는 경우 이 값은 더 낮아질 수 있습니다. 또한, 두 AZ 간에 데이터를 전송하는 경우에는 양방향으로 데이터 전송 요금이 부과됩니다. 이러한 효과를 더 잘 이해하기 위해 그림 1에 표시된 가상 워크로드인 ‘foo 서비스’를 분석해 보겠습니다. foo 서비스는 데이터를 중복 저장하기 위해 AWS의 다른 워크로드용 스토리지 플랫폼을 제공하고 있습니다.
요청은 먼저 ALB(Application Load Balancer)에서 처리되는데요, ALB는 항상 교차 영역 로드 밸런싱을 사용하여 요청을 모든 대상에 고르게 분배합니다. 다음으로 요청은 로드 밸런서에서 요청 라우터로 전송됩니다. 요청 라우터는 스토리지 계층으로 보내기 전에 권한 부여 확인 및 입력 유효성 검사와 같은 몇 가지 작업을 수행합니다. 스토리지 계층은 리드 노드에서 중간 노드, 마지막으로 테일 노드로 데이터를 순차적으로 복제합니다. 데이터가 세 노드 모두에 기록되면 커밋된 것으로 간주됩니다. 응답은 꼬리 노드에서 요청 라우터로 다시 전송됩니다.
그림 1. AZ 간에 데이터를 전송하는 예시 시스템
그림 1에서 최악의 경우 요청이 AZ 경계를 8번 통과했음을 알 수 있습니다. 가장 빠른 0번째 백분위수(p0)를 계산해 보겠습니다. 지연 시간, 로드 밸런서, 요청 라우터 및 스토리지 계층에서 네트워크가 아닌 요청을 처리하는 데 가장 좋은 시간은 4ms라고 가정해 봅시다. 각 AZ 순회에 대해 추가되는 최소 네트워크 대기 시간으로 1ms를 고려하면 8개의 AZ 순회라는 최악의 시나리오에서 총 처리 시간은 12ms보다 빠를 수 없습니다. 중앙값을 의미하는 50번째 백분위수(p50)에서 교차 AZ 지연 시간이 1.5ms이고 비네트워크 처리가 8ms라고 가정하여 전체 처리에 총 20ms가 소요됩니다.
또한, 이 시스템이 수백만 건의 요청을 처리하는 경우에는 시간이 지남에 따라 데이터 전송 요금이 상당히 늘어날 수 있습니다. 그렇다면 foo 서비스를 사용하는 워크로드가 20ms 미만의 p50 대기 시간으로 작동해야 한다고 가정해 보겠습니다. foo 서비스는 이 목표를 달성하기 위해 시스템 설계를 어떻게 변경할 수 있을까요?
가용 영역 선호도
AZ 선호도 아키텍처 패턴은 AZ 경계가 교차하는 횟수를 줄입니다. 그림 1에서 살펴본 예제 시스템에서 AZ Affinity는 두 가지 변경 사항으로 구현할 수 있습니다.
1.먼저, ALB를 NLB(Network Load Balancer)로 교체합니다. NLB는 고정 IP로 구성된 AZ당 탄력적 네트워크 인터페이스를 제공합니다. NLB에는 기본적으로 교차 영역 로드 밸런싱이 비활성화되어 있습니다. 이렇게 하면 요청을 수신하는 탄력적 네트워크 인터페이스와 동일한 AZ에 있는 대상에만 요청이 전송됩니다.
2. 다음으로는 계정 간에 일관된 AZ ID를 사용하여 AZ 별 레코드를 제공하기 위해 각 탄력적 네트워크 인터페이스에 대해 DNS 항목이 생성 됩니다. 클라이언트는 해당 DNS 레코드를 사용하여 선택한 AZ의 로드 밸런서와 통신합니다. 따라서 foo.com과 같은 DNS 이름을 사용하여 리전 전체 서비스와 상호 작용하는 대신 use1-az1.foo.com을 사용합니다.
그림 2는 AZ Affinity가 있는 시스템을 보여줍니다. 최악의 경우 각 요청이 AZ 경계를 네 번만 횡단한다는 것을 알 수 있습니다. 데이터 전송 비용은 이전 구현에 비해 약 40% 감소합니다. AZ 내 통신을 위한 p50 지연 시간으로 300μs를 사용하면 이제 (4× 300μs )+(4× 1.5ms )=7.2ms가 됩니다 . 중앙값 8ms 처리 시간을 사용하면 전체 대기 시간 중앙값이 15.2ms가 됩니다. 이는 중간 네트워크 대기 시간이 40% 감소했음을 나타냅니다. p90, p99 또는 p99.9 대기 시간을 고려할 때 이 감소는 훨씬 더 중요할 수 있습니다.
그림 2. 이제 시스템에서 AZ Affinity를 구현합니다.
그림 3은 서비스 검색을 사용하여 이 접근 방식을 한 단계 더 발전시킬 수 있는 방법을 보여줍니다. 클라이언트가 로드 밸런서의 AZ별 DNS 이름을 기억하도록 요구하는 대신 AWS Cloud Map 을 서비스 검색에 사용할 수 있습니다. AWS Cloud Map은 클라이언트가 DNS를 사용하여 서비스 인스턴스의 IP 주소 및 포트 조합을 조회하고 HTTP 기반 서비스 Discovery API를 통해 URL과 같은 추상 엔드포인트를 동적으로 검색할 수 있는 완전 관리형 서비스입니다. 서비스 검색은 로드 밸런서의 필요성을 줄여 비용과 추가 지연 시간을 제거할 수 있습니다. 클라이언트는 먼저 AWS Cloud Map 레지스트리에서 해당 AZ의 서비스 인스턴스에 대한 세부 정보를 검색합니다. 요청에 선택적 매개변수를 지정하여 결과가 클라이언트의 AZ로 필터링됩니다. 그런 다음 해당 정보를 사용하여 검색된 요청 라우터에 요청을 보냅니다.
그림 3. 서비스 검색을 위해 AWS Cloud Map을 사용하여 구현된 AZ Affinity
워크로드 탄력성
AZ Affinity를 사용하는 새로운 아키텍처에서 클라이언트는 통신할 AZ를 선택해야 합니다. 단일 AZ에 ‘고정’되어 있고 여러 AZ에 걸쳐 로드 밸런싱되지 않기 때문에 이벤트 중에 해당 AZ의 AWS 인프라 또는 foo 서비스에 영향을 미칠 수 있습니다. 이러한 종류의 이벤트 동안 클라이언트는 지수 백오프와 함께 재시도를 사용 하거나 영향을 받지 않는 다른 AZ에 요청을 보낼 수 있습니다 . 또는 영향을 받는 AZ에 있는 클라이언트의 요청을 중지하고 다른 AZ에 있는 클라이언트만 사용하도록 회로 차단기를 구현할 수 있습니다. 두 접근 방식 모두 정상 작동 중에 AZ 선호도를 활용하면서 다중 AZ 시스템의 복원력을 사용할 수 있습니다.
클라이언트 라이브러리
서비스 검색, 지수 백오프를 통한 재시도, 회로 차단기 및 장애 조치 프로세스를 달성하는 가장 쉬운 방법은 클라이언트 library/SDK를 제공하는 것입니다. 라이브러리는 사용자를 위해 이 모든 로직을 처리하고 AWS SDK 또는 CLI가 하는 것처럼 프로세스를 투명하게 만들고, 용자는 저수준 API와 고수준 라이브러리라는 두 가지 옵션을 얻게 됩니다.
결론
오늘 포스팅에서는 AZ 선호도 패턴이 다중 AZ 시스템의 지연 시간과 데이터 전송 비용을 줄이는 동시에 고가용성을 제공하는 방법을 살펴보았습니다. 데이터 전송 비용에 대해 더 알아보려면 AWS 비용 탐색기를 사용하여 데이터 전송 비용 분석 블로그에서 AWS 비용 탐색기를 사용한 접근 방식을 확인해 보세요. 워크로드의 지연 시간을 조사하려면 시스템의 추적 및 관측 가능성을 위해 AWS X-Ray 및 Amazon CloudWatch 를 사용하는 것이 좋습니다. AZ Affinity는 모든 워크로드에 적합한 솔루션은 아니지만, AZ 간 데이터 전송 비용을 줄이거나 지연 시간을 개선해야 하는 경우 확실히 고려해야 할 접근 방식입니다.
- 이 추정치는 AZ 간에 ping 요청을 보내는 t4g.small 인스턴스를 사용하여 이루어졌습니다. 테스트는 us-east-1, us-west-2 및 eu-west-1 리전에서 수행되었습니다. 이러한 결과는 수집 당시 해당 리전의 p0(가장 빠름) 및 p50(중앙값) AZ 내 지연 시간을 나타내지만 어떤 위치에서든 두 인스턴스 간의 지연 시간을 보장하지는 않습니다. AZ Affinity가 제공하는 성능 향상을 계산하려면 자체 테스트를 수행해야 합니다.
메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.