VPC 내에서 유연한 시스템을 구축할 수 있는 베스트 프랙티스는 AZ를 활용하는 것이다. 하나의 AZ는 풍부한 파워, 네트워킹, 연결성을 가진 한 개 이상의 분리된 데이터 센터다. 동시여 여러 개의 AZ를 사용하면 하나의 단일 데이터 센터를 사용하는 거에 비해 고가용성을 높이고, 실패에 좀 더 유연하게 대처할 수 있으며 스케일링에 용이하게 작업할 수 있다. 하지만, 데이터를 서로 다른 AZ로 전달하는 것은 레이턴시와 비용 증가를 초래한다.
이 글은 "Availability Zone Affinity"(이하 AZA)라 불리는 아키텍처 패턴이 동시에 여러 AZ를 사용할 때의 이점을 지키면서 비용을 감소시키고 퍼포먼스를 향상할 수 있다는 것을 증명한다.
Cross Availability Zone effects
AZ는 하나의 AWS 리전 내에서 다른 AZ와 100 킬로미터 이내의 물리적 거리를 두고 있다. 이는 같은 리전, 서로 다른 AZ 간의 데이터 송수한 한번 당 수 밀리 세컨드의 지연을 발생시킨다. 그에 반해 같은 AZ 내에서 enhanced networking을 사용한다면, 데이터 송수신 한번당 발생하는 지연은 1 밀리 세컨드 미만이다. 만약 인스턴스들이 cluster placement gorups를 사용한다면 지연 시간은 더 단축된다. 게다가 데이터가 서로 다른 AZ 간에 전송된다면, 추가 비용(data transfer charge)이 데이터 송수신측 모두에게 부과된다.
위 설명을 더 잘 이해하기 위해 "foo servie"라는 가상의 서비스의 작업 과정을 살펴보자. foo service는 다음과 같이 여러 AZ를 이동한다.
foo service는 다른 작업을 위해 AWS 내에서 대량의 데이터를 저장하는 플랫폼을 제공한다. 요청은 항상 ALB(Application Load Balancer)가 처음 받아서 처리하며 ALB은 cross-zone load balancing을 사용해 균등하게 요청을 로드밸런싱 한다. 요청은 이제 ALB을 거쳐서 요청 라우터에 도달한다. 요청 라우터는 요청이 스토리지에 도달하기 전에 인증, 입력 검증 등 작업을 진행한다. 스토리지 단에서는 lead node - middle node - tail node 순으로 순차적으로 데이터를 복제(replicate) 한다. 이 세 개의 노드에 데이터를 모두 저장했다면 커밋된 것으로 간주한다. 응답은 tail node에서부터 요청 역순으로, 요청 라우터와 로드 밸런서를 거쳐서 클라이언트에 도달한다.
위 그림에서 보이는 워크 플로우는 최악의 케이스를 나타낸다. 무려 8번이나 AZ를 넘나들었다. 이 최악의 케이스에서 나올 수 있는 최선의 레이턴시를 계산해보자(zeroth percentil(p0)). 로드 밸런서, 요청 라우터와 스토리지가 요청을 받은 후 내부적으로 처리하는데 4ms가 소요된다 해보자. 만약 각 AZ 이동 간에 1ms의 지연이 발생한다면 최선의 경우 12ms가 소요된다. 만약 백분위수의 중간값(50th percentil - p50)으로 계산을 한다면, AZ 간 이동 한 번에 1.5ms가 소요된다. 요청 라우터, 로드밸런서, 스토리지의 내부 연산에는 8ms가 소요된다. 따라서 총 20ms가 소요된다. 또 한, 이 과정을 거치는 요청이 수백만 번 발생한다면, AZ 간 데이터 이동으로 발생하는 추가 비용은 시간에 따라 기하급수적으로 늘어난다. 만약 foo service를 사용하는 작업들이 20ms 이하의 지연을 가져야 한다면, 어떻게 해결할 수 있을까?
Availability Zone affinity
AZA 아키텍처 패턴은 AZ 간의 이동 횟수를 줄여준다. 위 예시에서 두 곳을 변경해 AZA 아키텍처를 적용할 수 있다.
1. ABL(Application Load Balancer)를 NLB(Network Load Balancer)로 바꾼다. NLB는 AZ 하나 당 정적 IP로 설정된 elastic network interface를 제공한다. 또 한, cross-zone load balancing이 디폴트로 비활성화되어있다. 따라서 요청이 오직 요청을 수신하는 elastic network interface와 같은 AZ에 있는 대상에게만 전송되는 것을 보장할 수 있다.
2. 각 elastic network interface에 DNS 엔트리가 생성되서 각 AZ ID를 이용한 AZ에 특화된 레코드를 제공한다. 클라이언트는 DNS 레코드를 사용해 클라이언트가 선택한 AZ 내에 있는 로드 밸런서와 통신한다. 따라서 foo.com과 같이 az를 가리지 않는 DNS 이름을 사용하는 대신, 1-az.foo.com과 같은 DNS 이름을 사용한다.
아래 그림은 AZA를 사용했을 때의 시스템을 나타낸다.
위 구조에서는 최악의 케이스가 AZ를 4번 이동한다. AZ 이동으로 인해 발생하는 추가 비용은 이전 아키텍처 대비 40% 감소했다. 백분위수 중간값(p50) 기준 하나의 AZ 내에서 통신하는데 발생하는 지연이 300 μs이면 (4 ×300μs)+(4 ×1.5ms)=7.2ms 만큼의 지연 시간이 발생한다. 위에서 언급했듯 스토리지의 내부 연산이 8ms가 소요된다고 하면, 총 15.2m의 지연이 발생한다. 따라서 네트워크 지연을 40% 감축시킬 수 있다. 만약 p90, p99, p99.9의 지연의 경우 지연 시간은 더욱 줄어든다.
아래 아키텍처는 한발 더 나아가 AWS Cloud Map을 사용한 방식을 사용한다. 이 방식을 사용하면 클라이언트가 로드 밸런서에 요청을 송신하기 위해 AZ에 대응하는 DNS 이름을 기억하지 않아도 된다. AWS Cloud Map은 DNS를 이용해 클라이언트가 송신 측 서비스의 IP와 port를 찾고 HTTP 기반 검색 API를 통해 URL 같은 추상화된 엔드포인트를 동적으로 찾을 수 있게 하는 서비스다. 서비스 검색은 로드 밸런서의 역할을 줄여서 비용과 지연을 감소시킨다.
클라이언트는 우선 자신들과 같은 AZ 내에 존재하는 서비스 인스턴스에 대한 상세 정보를 AWS Cloud Map 레지스트리에서 가져온다. 결과는 선택적 파라미터를 요청에 명시함으로서 클라이언트 AZ로 필터링된다. 그 후 클라이언트는 이 정보들을 활용해 찾은 요청 라우터로 요청을 보낸다.
Workload resiliency
AZA를 사용하는 새로운 아키텍처에서는 클라이언트가 자신들과 통신할 AZ를 선택해야 한다. 클라이언트는 하나의 AZ에 고정돼 있고, 여려 AZ에 걸쳐서 로드 밸런싱 되지 않기 때문에 이벤트 도중 해당 AZ의 AWS 인프라 또는 foo 서비스에 영향을 줄 수 있다.
이런 이벤트를 실행하면, 클라이언트는 exponential backoff를 이용해 재시도를 사거나 영향을 받지 않은 다른 AZ에 요청을 보낸다. 또는 클라이언트는 circuit breaker를 이용해 요청을 중단하고 다른 클라이언트를 사용한다. 두 방식 모두 일반 연산에서 AZA를 사용할 때 다중 AZ 시스템의 복원력을 사용할 수 있다.
Client libraries
서비스 검색, expotential backoff를 이용한 검색, circuit breaker, 페일오버의 프로세스를 달성하기 가장 쉬운 방식은 클라이언트 라이브러리나 SDK를 제공하는 것이다. 이 라이브러리는 유저를 위해 모든 로직을 처리하고 프로세스를 투명하게 만든다. 유저는 이를 사용할 수 있는 두 가지 선택지가 있다. low-level API와 high-level library이다.
Conclusion
이 포스팅은 AZA가 다중 AZ 시스템에서 고가용성을 높이면서 데이터 전송 비용과 지연을 줄일 수 있다는 것을 증명했다. 만약 자신의 시스템에서 청구되는 AZ 간 데이터 이동으로 발생하는 추가 비용을 알고 싶다면 Using AWS Cost Explorer to analyze data transfer costs를 참고하자.
만약 현재 작업량에 대한 지연을 조사하고 싶다면 AWS X-RAY와 Amazon CloudWatch를 이용해 시스템을 추적하고 관찰하는 것을 고려하라. AZA는 만능이 아니지만 AZ 간의 데이터 이동 비용이나 지연을 줄일 수 있는 방법이다.
원본 - Improving Performance and Reducing Cost Using Availability Zone Affinity