[ByteByteGo] Multi-Region Architecture: Going Global Without Going Broke

도입부

어플리케이션이 지리적으로 확장됨에 따라 지연시간과 가용성을 개선하기 위해 두 번째 리전에서 서비스를 시작하는 것은 논리적이다.

 

그러나 어플리케이션에 두 번째 리전을 추가하면 오히려 리전이 하나일 때보다 더 느려지고 신뢰성이 떨어질 수 있다.

이는 더 많은 위치가 곧 더 빠른 서비스와 더 안정적인 가동 시간을 의미해야 한다는 직관에 반하는 결과이다.

 

하지만 동일한 데이터가 동시에 두 곳에 존재하게 되면, 멀티 리전 배포의 장점을 완전히 무색하게 만들 수 있는 새로운 문제가 발생한다.

 

ex)

미국 동부 해안의 서버와 프랑크푸르트의 서버가 각각 동일한 데이터에 대해 거의 같은 순간에 수정을 처리하는 상황에서, 두 리전 사이의 네트워크 연결이 끊어졌다고 가정해보자

 

두 수정 사항은 모두 각각의 로컬에 저장된다.

 

이제 각 리전은 어느 쪽이 먼저였는지에 대한 공유 기록 없이 서로 다른 버전의 데이터를 보유하게 된다.

연결이 복구되면 두 버전 중 하나를 다른 버전 대신 선택해야 한다.

시스템이 이 문제를 어떻게 처리하느냐는 글로벌 인프라를 구축하고 운영하는 데 드는 비용에 막대한 영향을 미친다.

 

글로벌화는 단 한번의 결정이라기보다는 점진적인 발전 과정으로 이해하는 것이 좋다.

 

이 글에서는 모든 리전 설계의 근간이 되는 핵심 개념인 빌딩 블록부터 시작해서, 백업 기능이 있는 단일 리전부터 모든 리전을 동시에 가동하는 방식에 이르기까지 일반적인 구성들을 살펴볼 것이다.

 

각 단계마다 더 낮은 지연 시간, 더 높은 가용성, 또는 국가 국경 내에 데이터를 유지하는 능력 등 구체적인 이점을 얻을 수 있다.

 

동시에 각 단계는 금전적 비용과 더불어 데이터 일관성 측면의 트레이드오프라는 대가를 수반한다.

 

Foundation(기반 개념)

• Region(지역)
  • 지리적 영역으로 인프라를 지리적으로 나누어 배포하는 것을 의미한다.
  • 사용자의 요청이 리전이 가까울수록 네트워크 지연을 최소화 할 수 있다.
  • 실제 서비스를 사용하는 사용자들과 가장 가까운 리전을 선택해서 해당 인프라를 사용하는것이 적당하다.
• Availability Zone(가용 영역)
  • 리전 내부의 독립된 데이터 센터로 하나의 리전 내부에서 물리적으로 완전히 분리되어 있는 데이터 센터의 집합이다.
  • 모든 가용 영역은 특정 반드시 특정 리전에 속해 있다.

 

애플리케이션을 여러 가용 영역에 분산시키면 단일 데이터 센터의 가동 중단으로 서비스를 보호할 수 있다. 

리전 간 분산은 완전히 다른 이야기이며 다음과 같은 구체적인 이유 때문에 수행된다.

 

• 메인 리전에서 멀리 떨어진 사용자들의 지연 시간을 줄이기 위해
• 특정 지역 전체가 오프라인 상태가 되더라도 서비스를 계속 운영하기 위해
• 데이터가 물리적으로 저장되는 위치에 대한 법적 요구사항을 충족하기 위해

단일 리전 내의 여러 가용 영역에 분산된 시스템은 멀티 리전 배포가 아니다.

 

왼쪽 US-EAST는 하나의 리전에 3개의 가용영역이 존재하며 현재 AZ3 데이터 센터가 문제가 생겨 다운된 상태이다. 하지만 각 데이터 센터는 격리되어 있기에 전체 서비스는 끊기지 않는다. 오른쪽 EU-WEST는 하나의 리전에 여러 데이터센터가 존재한다 이때 US-EAST에 자연재해가 발생해서 모든 리전 전체가 마비되도 EU-WEST는 영향을 받지 않는다.

 

어플리케이션 서버는(WAS ex) Spring Boot)는 상태가 없다.

 

즉 서버는 요청과 요청 사이에 자체적인 영구 데이터를 유지하지 않으므로 새 리전에 만든 복사본도 원본과 완전히 동일하게 작동한다.

 

반면 데이터베이스(ex) MySQL, PostgreSQL), 파일 저장소, 사용자 세션은 상태를 유지하며(Stateful), 이는 다른 모든 구성 요소가 의존하는 데이터를 보유하고 있음을 의미한다.

 

여기서 어플리케이션 서버와 데이터베이스를 복제하는데에 있어 차이가 있다.

 

Web Servers는 무상태(stateless)하기에 복제하기에 오랜 시간이 소요되지 않는다. 하지만 데이터베이스는 stateful 하기에 복제하는데 많은 시간이 걸린다.

 

상태가 없는 어플리케이션 서버는 몇 분 만에 복제할 수 있다(데이터를 동기화할 필요가 없기 때문에 똑같은 소스 코드를 실행하기만 하면됨) 하지만 복제하기 어려운 것은 계정 기록과 장바구니 콘텐츠이다(데이터베이스 -> stateful하며 데이터의 의존관계가 존재함)

 

Replication(복제)

데이터가 둘 이상의 리전에 존재해야 한다면 그곳으로 데이터를 복사해야 한다. 이 복사 과정을 복제(Replication)이라고 한다.

복제에는 동기(Synchronous)와 비동기(Asynchronous) 두가지 형태가 존재한다.

 

• 동기(Synchronous)
  • 동기 복제 방식에서는 쓰기 작업이 대기한다.
  • 변경 사항이 들어오면 시스템은 이를 다른 리전으로 전송하고, 해당 리전이 복사본을 수신했다고 확인할때까지 쓰기 작업을 완료하지 않고 붙잡아 두며 이후 쓰기 작업이 성공한 것으로 간주한다.
  • 장점 : 리전들은 완벽히 동기화된 상태로 유지하므로 어느 곳에서 읽기 작업을 수행하든 동일한 값을 반환한다.
  • 단점 : 모든 단일 쓰기 작업에 발생되며 각 쓰기 작업마다 리전 간의 거리를 오가는 왕복비용을 치러야 하기에 느리다.
• 비동기(Asynchronous)
  • 로컬에서 즉시 쓰기가 성공하고, 복사본은 백그라운드에서 다른 리전으로 이동한다.
  • 복제가 완료될 때까지 기다릴 필요가 없기 때문에 쓰기 속도가 빠르게 유지된다.
  • 장점 : 복제가 완료될때까지 기다릴 필요가 없기에 쓰기 속도가 빠르다.
  • 단점 : 백그라운드로 동작하기에 아직 반영이 되지 않은 리전이 존재하면 이전(과거)의 값을 응답받을 수 있으며
    쓰기 작업이 복제되기도 전에 메인 리전에 장애가 발생하면 쓰기 데이터는 유실될 수 있음

Synchronous(동기)와 Asynchronous(비동기)의 차이

 

이처럼 동기와 비동기는 서로가 장점과 단점이 확실하게 나눠져 있기에 Tradeoff 관계에 있다.

 

즉 쓰기 속도를 느리게하는 것을 감수할 것인가, 아니면 최신이 아닌 데이터를 읽는것을 감수할 것인가의 차이다.

 

Consistency(일관성)

읽기 작업이 발생했을 때 가장 최근의 쓰기 내용이 반영되도록 보장할 것인가, 약간 과거의 데이터를 반환해도 될 것인가가 위에서 언급했던 동기화, 비동기화 방식의 읽기 반환이다.

 

이러한 보장을 의미하는 것이 일관성이며 시스템은 두 방식에서 하나의 방식을 사용하게 된다.

 

• Strong consistency(강한 일관성)
  • 어떤 리전이 응답하든 모든 읽기 작업이 가장 최신의 쓰기 결과를 반환하도록 보장한다.
  • 장점 : 읽기 요청을 보낼때마다 가장 최신의 데이터를 가져오기에 신뢰성이 보장된다. (안전하고 직관적)
  • 단점 : 모든 리전을 최신 상태로 유지하기 위해 리전 간 왕복 통신을 기다려야 한다 (지연 시간 증가)
• Eventual consistency(최종 일관성)
  • 리전 간의 데이터 합의는 빠르게 이루어지지만 쓰기 직후에 수행된 읽기 작업은 여전히 잠깐동안 과거 값을 반환할 수 있다.
  • 장점 : 읽기와 쓰기 속도가 매우 빠르게 유지된다.
  • 단점 : 쓰기 직후 읽기 작업을 수행할때 과거의 값을 조회할 수 있다.

Strong consistency VS Eventual consistency

 

이렇게 봤을때 어느 한쪽만이 정답이라고 할 수는 없다 따라서 선택하게 된다면 운영하는 서비스의 성질을 고려해야 한다.

 

예를 들어 SNS 시스템과 금융 시스템이라고 가정하면

 

SNS 시스템은 프로필 소새글이 몇 초 늦게 반영되는 것은 크게 문제가 되지 않는다 따라서 비동기 방식을 사용해서 사용자에게 빠른 응답을 제공하는 것이 적절하다

하지만 금융 시스템에서는 계좌의 잔액이 실제있는 것보다 적게 조회가 된다면, 거절되어야 할 결제가 승인이 되는 상황이 발생할 수 있다. 즉 이러한 시스템에서는 동기 방식을 사용해서 사용자에게 응답을 늦게 준다 하더라도 데이터의 신뢰성이 보장이 되어야 한다.

 

 

Routing(라우팅)

사용자가 어느 리전에 도달할지에 대해 결정하는 것도 필요하다. 이러한 역할을 하는 것이 지리적 라우팅(Geo-Routing)이며 이는 고정된 리전이 아니라 가장 가깝고 상태가 정상적인 리전으로 요청을 안내하는 작업을 한다.

 

Geo-DNS는 사용자 IP 주소를 기반으로 위치를 추정하여 가장 가까운 서버의 IP 주소로 도메인을 변환하는 작업을 수행한다.

 

즉 유럽에서 보낸 요청은 유럽 리전에 도달하고, 북미에서 보낸 요청은 북미와 더 가까운 리전에 도달하게 된다.

이는 읽기 요청 처리에 큰 도움이 되며 자주 변하지 않는 캐시된 페이지, 이미지, 기타 콘텐츠를 가까운 리전에서 제공하면 지연 시간이 크게 감소하게 된다.

 

 

Active-Passive(액티브 패시브)

액티브 패시브 구성은 첫 번째 리전에 장애가 발생했을 때 두번째 리전이 전체 업무를 완전히 넘겨받을 수 있도록 하기 위해 존재한다.

 

하나의 리전(Active)가 모든 쓰기 작업을 독점해서 처리하며 하나 이상의 패시브 리전은 지속적으로 복제 스트림을 전달받는다.

 

패시브 리전은 최신 복사본을 보유한 채 아무런 서비스를 제공하지 않거나, 오직 읽기 요청만 처리하며 대기 상태를 유지한다.

액티브 리전에 장애가 발생하면 패시브 리전이 그 자리를 대체하도록 승격된다.

 

이러한 전환 과정을 장애 조치(failover)이라고 하며 장애 조치에서도 해결해야할 과제들이 존재한다.

 

액티브 리전이 다운된 순간부터 패시브 리전이 서비스를 온전히 제공하기 시작할 때까지 공백이 존재한다.

 

이 공백은 장애를 감지하고, 전환을 결정하고, 트래픽을 재라우팅하는 데 걸리는 시간에 따라 결정된다.

장애를 명확하게 감지하는 것이 까다롭고 잠시 동안 네트워크 깜빡임이 리전 전체가 죽은 상태와 똑같이 보일 수 있으며, 오탐에 빨리 반응하면 그 자체로 또 다른 서비스 중단을 초래할 수 있다.

 

왼쪽은 기본 작동, 오른쪽은 장애상황 발생시 리전 B가 승격되어 액티브 상태가되어 읽기,쓰기 작업 수행

 

공백 기간 동안 쓰기 작업이 일시 중단될 수 있으며, 복제가 아직 완료되지 않은 모든 쓰기 데이터는 유실될 위험에 처할 수 있다.

또한 장애가 발생한 리전이 다시 복구된 후도 고려해야한다.

 

기존 리전이 회복되면 트래픽을 다시 원래대로 되돌려야 하는데, 이때 승격된 패시브 리전이 권한을 쥐고 있는 동안 받아들인 모든 변경 사항을 먼저 기존 리전과 동기화해야 한다.

 

이러한 과정을 장애 복구(Failback)이라고 한다.

마지막으로 대기 용량(Standby capacity)도 공짜가 아니다. 패시브 리전은 계속 가동 중이면서 정작 거의 발생하지 않을 수 있는 장애 상황에만 쓰이기 때문이다.

 

Active-Active(액티브-액티브)

유휴 대기 상태와 장애 조치 시의 공백을 없앤다는 것은 모든 리전이 동시에 쓰기 작업을 수용할 수 있도록 함을 의미하며 이러한 구성을 Active-Active 라고 한다.

 

이는 모든 리전이 로컬에서 직접 서비스를 제공하고 변경 사항을 접수하며 가장 강력하고 고도화된 구성이다.

이를 통해 멀티 리전이 줄 수 있는 최고의 장점을 누리게 된다.

 

모든 지역의 사용자가 자신과 가까운 리전에 데이터를 쓰고, 전반적인 지연 시간이 대폭 감소하며, 낭비되는 유휴 용량도 사라진다.

하지만 두 리전 모두 쓰기를 수용할 수 있게 되면, 서로 다른 장소에 있는 두 사람이 거의 동시에 동일한 레코드를 수정할 수 있다.

 

이러한 경우 데이터 버전이 2개가 되며 어느쪽 데이터를 최종적으로 선택할지 결정해야 한다. 이러한 결정을 Conflict resolution 이라고 한다.

 

가장 간단한 규칙은 최종 쓰기 승리 방식으로 더 늦은 타임스탬프를 가진 변경 사항을 유지하고 다른 쪽은 버리는 것이다.

 

두 변경 사항을 모두 보존하거나 정교하게 병합하는 접근 방식도 존재한다.

 

 

어떤 방법을 선택하던, 충돌 해결은 언제나 데이터의 무언가를 포기해야 한다. 또한 액티브-액티브 구성에는 추가적인 문제를 일으킬 수 있는 특수한 상황이 존재한다.

 

두 액티브 리전 사이의 네트워크 연결이 끊어지면 양쪽 모두 계속 쓰기를 받아들이는데, 상대방 리전 변경 사항을 전혀 알 수 없다.

네트워크 단절이 지속되는 동안 두 데이터 복사본은 서로 완전히 다른 방향으로 멀어지게 된다. 연결이 다시 복구되었을 때 남는 것은 서로 갈라진 두 개의 기록 뿐이며 이를 완벽하게 병합할 방법은 없다.

 

이러한 상태를 스플릿 브레인이라고 하며 많은 개발자들이 의도적으로 액티브-패시브 구성을 선택하는 가장 큰 이유이기도 하다.

 

Residency(데이터 거주)

여러 리전에 서비스를 분산하는 이유가 언제나 속도나 가동 시간 때문은 아니다.

 

때로는 규제와 법령이 이러한 방향을 결정하기도 하며

현재 몇몇 국가들은 자국 거주자의 데이터를 물리적으로 국경 내에 보존하도록 법으로 요구하고 있다.

 

이것을 data residency라고 하며 이는 아키텍쳐 접근 방식 전체를 바꾸어 놓는다.

 

이때의 원동력은 더 이상 지연 시간이나 가용성이 아닌 법적 규제 준수이며, 이는 서비스 규모와 상관없이 모든 애플리케이션에 적용될 수 있다.

 

엄격한 사법권 아래에 있는 수천 명 수준의 소규모 서비스라 할지라도 성능 목적만으로는 전혀 필요 없었을 현지 인프라를 무조건 운영해야 할 수 있다.

이에 따른 설계적 결과로, 특정 데이터는 특정 리전에만 묶이게 되며 다른 모든 곳으로 자유롭게 복제될 수 없다.

 

실무적으로 이는 규제 대상 시장별로 독립된 저장소를 운영함을 의미하며, 하나의 거대한 글로벌 데이터베이스로 통합하기보다는 시스템의 나머지 부분과 완전히 분리되여 관리하게 된다.

 

이러한 제약은 라우팅 및 복제 방식 선택에 큰 영향을 미친다. 법적으로 한 장소에 묶여 있는 데이터를 단지 더 빠르다는 기술적 이유로 다른 곳에 복사할 수 없기 때문이다.

 

Cost(비용)

아키텍쳐 단계를 거듭할수록 비용이 증가하며, 비용의 가장 큰 부분은 처음에 미리 파악하기 어려울 수 있다.

 

이러한 비용은 크게 3가지로 나뉜다.

 

• 인프라 중복
  • 여러 리전에서 운영한다는 것은 각 리전의 용량만큼 비용을 지불해야 한다는 것을 의미한다.
  • 액티브-패시브 구성에서는 이 용량의 상당 부분이 올해 안에 일어나지 않을지도 모르는 장애에 대비해 그저 유휴 상태로 대기한다.
• 리전 간 데이터 전송
  • 데이터 복제는 공짜가 아니며, 리전 간에 끊임없이 흐르는 트래픽은 대개 전송량 기준으로 요금이 부과된다.
  • 규모가 커지면 이 비용이 실제 컴퓨팅 작업을 수행하는 서버 비용보다 더 커질 수 있다.
• 운영 부담
  • 모든 장애 상황이 여러 리전에 걸쳐 발생하고, 디버깅 시 확인해야 할 곳이 늘어나며, 복제 지연이나 네트워크 단절 현상을 추론하는 작업은 고도의 전문성을 요구하는 까다로운 작업이 된다.
  • 이러한 부담은 엔지니어들의 시간적 비용을 크게 증가시킨다.

 

이것이 바로 가장 최신의 최첨단 구성이 정답이 아닌 이유이다.

 

대부분 애플리케이션은 한 두개 리전에 집중된 사용자들을 대상으로 하고, 데이터 거주성 규제를 받지 않으며 잘 관리된 단일 리전이 수반할 수 있는 드물고 일시적인 짧은 장애 정도는 충분히 감내할 수 있다.

 

이러한 서비스들에게 지나치게 진보된 설계는 자신들이 겪고 있지 않은 문제를 해결하려 들면서 실제 비용과 복잡성과 가중시킬 뿐이다.

 

아키텍쳐 구성은 지연 시간, 가용성, 데이터 보존 등 서비스의 실제 요구사항에 정확히 부합해야 하며 그 이상일 필요는 전혀 없다.

 

Summary(정리)

 

• 글로벌화는 단 하나의 스위치를 켜는 것이 아니라 trade-off를 조율해 가는 점진적인 과정이며, 올바른 구성이란 가장 고도화된 기술이 아니라 문제 본연에 부합하는 구성이다.
• 컴퓨팅 자원은 쉽게 복제되므로, 멀티 리전의 진짜 비용과 난제는 데이터 계층에 존재한다 (DB)
• Replication은 일관성을 완벽히 유지하지만 리전 간 왕복 비용을 치르는 '동기 방식'과, 속도는 빠르지만 데이터 반영이 약간 뒤처지는 '비동기 방식' 사이의 선택이다.
• 강한 일관성은 지연 시간이라는 대가를 치르고 데이터 불일치 기간을 없애는 반면, 최종 일관성은 빠른 속도를 유지하기 위해 잠깐의 불일치 기간을 허용합니다.
• 물리적 거리는 어떠한 엔지니어링 기술로도 제거할 수 없는 지연 시간의 하한선을 설정하며, 이것이 바로 Latency tax 이다.
• Geo-Routing은 가장 가까운 리전에서 데이터를 제공함으로써 비용 효율적으로 읽기 속도를 높여주지만, 쓰기 작업은 여전히 느려 해결하지 못한 난제이다.
• Active-Active는 가용성을 확보하는 대신 Failover 공백을 유발하며, 상대적으로 더 어렵고 평소 연습이 부족하기 마련인 FailBack이라는 과제를 안겨준다.
• Active-Active는 모든 곳에서 로컬 쓰기가 가능하게 해주지만, 충돌 해결 및 네트워크 단절 시 Split-Brain 위험이라는 막중한 대가를 요구한다.
• Data residency는 서비스의 규모나 트래픽과 무관하게 오직 법적인 이유만으로 멀티 리전 설계를 강제할 수 있습니다.
• 가장 큰 비용을 차지하는 것은 대부분의 예산안이 계획하는 서버 복제 비용이 아니라, 리전 간 데이터 전송료와 운영 복잡성이다.