리전과 가용 영역

애플리케이션이 단일 데이터 센터의 단일 서버에서 실행될 때, 모든 장애는 곧 전체 중단입니다. 정전? 중단. 네트워크 단절? 중단. 냉각 시스템 고장? 중단. 이런 일이 생겼을 때 운이 나쁜 게 아닙니다—무방비 상태인 겁니다. 모든 의존성이 단일 장애점이 됩니다.

클라우드 인프라는 이 문제를 해결하기 위해 존재합니다. 하지만 해결책은 단순히 "서버를 더 많이"가 아닙니다. 독립적인 서버—동일한 장애 원인을 공유하지 않는 머신—가 필요합니다. 리전과 가용 영역은 클라우드 공급자가 독립성을 제공하는 방식입니다.

실제로 구매하는 것

리전은 클라우드 공급자가 인프라를 운영하는 지리적 영역입니다. AWS는 버지니아 북부에 us-east-1, 아일랜드에 eu-west-1, 싱가포르에 ap-southeast-1을 운영합니다. 각 리전은 완전히 독립적입니다—다른 건물, 다른 전력망, 다른 네트워크 연결, 모든 것이 다릅니다.

각 리전 내에서 공급자는 여러 가용 영역(AZ)을 운영합니다. 이것들은 별도의 데이터 센터—종종 수 킬로미터 떨어진 다른 건물들—로, 빠른 저지연 링크로 연결되어 있습니다. 리전에는 일반적으로 2~6개의 가용 영역이 있습니다.

핵심은 이것입니다: 가용 영역은 하나의 장애가 다른 영역에 영향을 주지 않도록 설계되어 있습니다. 서로 다른 전원, 서로 다른 냉각 시스템, 서로 다른 네트워크 경로. AZ-a에 홍수가 나도, AZ-b와 AZ-c는 계속 운영됩니다.

동반 장애에 대한 유일한 방어책은 물리적 분리입니다. 같은 건물이면 같은 홍수. 같은 전력망이면 같은 정전. 같은 리전이면 같은 허리케인.

리전: 거리와 관할권

리전을 선택한다는 것은 두 가지를 결정하는 것입니다: 서버가 물리적으로 위치할 곳, 그리고 어떤 법률이 적용될지.

지연 시간은 물리 법칙입니다. 데이터는 광섬유를 통해 빛의 속도로 이동하지만, 빛도 대륙을 가로지르기에는 느립니다. 런던에서 버지니아 서버까지 요청은 처리 전에 왕복 약 80ms가 걸립니다—순전히 빛의 속도만으로도요. 아일랜드의 서버라면 이를 크게 줄일 수 있습니다.

대부분의 웹 애플리케이션에서 50~100ms의 추가 지연은 느껴지긴 해도 감내할 만합니다. 하지만 화상 통화, 게임, 금융 거래 같은 실시간 애플리케이션에서는 사용 가능과 불가능의 차이가 됩니다.

데이터 레지던시는 법의 영역입니다. GDPR은 유럽 사용자 데이터를 유럽 내에 보관하도록 요구할 수 있습니다. 금융 규정은 데이터를 국경 안에 유지하도록 강제할 수 있고, 의료 데이터는 별도의 요건이 있습니다. 리전 선택은 단순한 기술적 결정이 아닙니다—법적 결정이기도 합니다.

비용은 리전마다 다르며, 때로는 상당한 차이가 납니다. 미국 리전이 일반적으로 가장 저렴합니다. 사용자가 전 세계에 분산되어 있고 지연이 중요하지 않다면 비용을 우선시할 수 있습니다. 사용자가 특정 지역에 집중되어 있다면 지연 시간을 최적화하는 것이 맞습니다.

가용 영역: 최악의 상황에서 살아남기

99.999% 가동률의 단일 서버도 연간 약 5분은 다운됩니다. 하지만 그 5분이 블랙 프라이데이에, 제품 출시 순간에, 가장 중요한 그 순간에 발생한다면—5분을 잃은 것이 아닙니다. 그 순간이 가져올 모든 것을 잃은 겁니다.

가용 영역은 그렇지 않으면 치명적이었을 장애에서 살아남게 해줍니다.

멀티 AZ 배포는 여러 가용 영역에 걸쳐 동시에 애플리케이션을 실행하는 것입니다. 한 AZ에 서버 6대를 두는 대신, 3개의 AZ에 각각 2대씩 운영합니다. AZ 전체가 장애를 겪을 때—실제로 그런 일이 일어납니다—전체가 아닌 용량의 3분의 1만 잃게 됩니다.

로드 밸런서는 자동으로 AZ에 걸쳐 트래픽을 분산합니다. AZ가 비정상이 되면 트래픽이 나머지 AZ로 전달됩니다. 사용자는 약간의 성능 저하를 경험할 수 있지만, 서비스는 계속됩니다.

AZ에 걸친 데이터베이스 복제는 AZ 장애에서 데이터를 보호합니다. AZ-a의 기본 데이터베이스는 AZ-b의 대기 서버로 지속적으로 복제됩니다. AZ-a가 장애를 겪으면 데이터베이스가 자동으로 AZ-b로 페일오버됩니다. 데이터는 안전하고, 서비스는 계속됩니다.

AZ 간 네트워크는 빠릅니다—일반적으로 2ms 미만의 지연 시간. 인터넷이 아닌 전용 고대역폭 링크입니다. 의미 있는 성능 손실 없이 AZ에 걸친 아키텍처를 설계할 수 있습니다.

멀티 리전: 글로벌 규모와 진정한 재해 복구

멀티 AZ는 데이터 센터 장애로부터 보호합니다. 멀티 리전은 지역 단위의 재해로부터 보호하며, 전 세계 사용자 기반에 효과적으로 서비스를 제공합니다.

액티브-액티브 배포는 여러 리전에서 동시에 트래픽을 처리합니다. 유럽 사용자는 유럽 서버에 접속합니다. 아시아 사용자는 아시아 서버에 접속합니다. 모든 사용자가 낮은 지연 시간을 경험합니다. 리전 전체가 장애를 겪으면 사용자는 남은 리전으로 라우팅됩니다. 이것이 글로벌 애플리케이션의 가장 이상적인 형태입니다.

복잡하기도 합니다. 데이터는 리전 간에 동기화되어야 합니다. 충돌을 해결해야 합니다. 라우팅이 지능적이어야 합니다. 엔지니어링 비용이 상당합니다.

액티브-패시브 배포는 더 단순합니다. 하나의 리전이 모든 트래픽을 처리합니다. 다른 리전은 모든 데이터의 동기화된 복사본을 유지하지만 트래픽은 처리하지 않습니다. 기본 리전이 치명적인 장애를 겪으면 패시브 리전으로 페일오버합니다.

인근 리전에서 서비스를 제공하는 지연 시간 이점은 포기하지만, 진정한 멀티 리전 운영의 복잡성 없이 재해 복구를 갖출 수 있습니다.

독립성의 비용

독립성은 공짜가 아닙니다.

데이터 전송 비용은 AZ나 리전 간에 데이터가 이동할 때마다 쌓입니다. 데이터베이스 복제, 캐시 동기화, 분산된 위치에서의 서비스 제공—이 모든 것이 전송 요금을 발생시킵니다. 대용량 애플리케이션은 상당한 비용이 생길 수 있습니다.

일관성 문제는 데이터가 여러 곳에 존재할 때 발생합니다. 사용자가 us-east-1에서 프로필을 업데이트하고 즉시 eu-west-1에서 조회하면 업데이트된 내용을 볼 수 있을까요? 분산 시스템은 일관성과 가용성 사이에서 선택을 강요합니다. CAP 정리는 권고 사항이 아닙니다—법칙입니다.

운영 복잡성은 추가하는 장애 도메인마다 증가합니다. 모니터링은 부분적인 장애를 감지해야 합니다. 자동화는 올바르게 대응해야 합니다. 테스트는 3개 AZ 중 1개가 저하될 때의 동작을 검증해야 합니다. 비상 대기 엔지니어는 장애 도메인에 걸친 아키텍처를 이해해야 합니다.

선택하기

사용자부터 생각하세요. 사용자가 어디에 있나요? 기본 리전을 거기에 두세요. 전 세계에 분산되어 있다면, 결국 여러 리전이 필요합니다.

규정 준수를 확인하세요. 일부 데이터는 특정 관할권에 있어야 합니다. 이것은 선택이 아닙니다—다른 무엇보다 먼저 선택지를 제한합니다.

처음부터 AZ에 걸쳐 배포하세요. 멀티 AZ는 프로덕션 애플리케이션의 기본 전제입니다. 비용은 미미하고, 보호 효과는 상당합니다. 단일 AZ에서 프로덕션 워크로드를 실행할 마땅한 이유가 없습니다.

필요할 때 리전을 추가하세요. 멀티 리전은 상당한 복잡성을 더합니다. 섣불리 추가하지 마세요. 하지만 글로벌 성능이나 진정한 재해 복구가 필요해지면, 멀티 리전이 그 해답입니다.

엣지 로케이션: 마지막 구간

리전과 AZ를 넘어, 클라우드 공급자는 전 세계에 수백 개의 엣지 로케이션을 운영합니다. 사용자 가까이에 콘텐츠를 캐싱하는 소형 시설들입니다.

엣지 로케이션에서 애플리케이션을 직접 실행하지는 않습니다. 리전에서 애플리케이션을 실행하고, 엣지 로케이션을 통해 정적 콘텐츠—이미지, 동영상, CSS, JavaScript—를 사용자 가까이에서 제공합니다. 도쿄의 사용자가 이미지를 요청하면 us-east-1 서버가 아닌 도쿄 엣지 로케이션에서 받게 됩니다.

이것이 CDN(콘텐츠 전송 네트워크)이 하는 일입니다. 리전과 AZ를 대체하는 것이 아닙니다—동적으로 생성할 필요 없는 콘텐츠의 지연 시간 문제를 해결함으로써 이를 보완합니다.

복원력의 아키텍처

리전과 가용 영역은 목록에서 체크하는 기능이 아닙니다. 복원력 있는 아키텍처의 토대입니다.

배포하는 모든 리소스는 물리적으로 어딘가에 존재합니다. 그 어딘가는 장애를 겪을 수 있습니다. 문제는 그 장애가 서비스를 중단시키느냐—아니면 충분한 독립성을 확보해 장애를 극복 가능한 수준으로 만드느냐입니다.

무상태성이 도움이 됩니다. 애플리케이션 서버가 세션 상태를 로컬에 저장하지 않으면, AZ를 잃는 것은 단지 용량 손실을 의미할 뿐 사용자 세션을 잃는 게 아닙니다. AZ에 걸쳐 있는 복제된 데이터베이스와 캐시에 상태를 저장하세요.

자동화가 도움이 됩니다. 사람이 AZ 장애에 충분히 빠르게 대응하는 것은 불가능합니다. 로드 밸런서, 상태 확인, 자동 확장이 장애를 감지하고 자동으로 대응해야 합니다.

테스트가 도움이 됩니다. AZ 장애를 한 번도 테스트해본 적 없다면, 실제로 살아남을 수 있는지 알 수 없습니다. 카오스 엔지니어링—의도적으로 장애를 주입하는 것—은 실제 장애가 발생하기 전에 약점을 드러냅니다.

목표는 완벽한 가동률이 아닙니다. 그것을 달성하는 방법은 없습니다. 목표는 반드시 찾아올 장애에서 살아남는 것—그리고 사용자가 거의 눈치채지 못할 만큼 빠르게 복구하는 것입니다.

리전과 가용 영역에 관한 자주 묻는 질문

가용 영역과 데이터 센터의 차이는 무엇인가요?

가용 영역은 클라우드 공급자 관점에서 함께 장애를 겪는 하나 이상의 데이터 센터입니다. 공급자는 AZ가 독립적으로 장애를 겪도록 보장합니다—다른 전원, 다른 네트워크, 다른 물리적 위험. AZ가 하나의 건물인지 여러 건물인지는 구현 세부 사항입니다. 중요한 것은 독립성 보장입니다.

멀티 리전 배포가 필요한지 어떻게 알 수 있나요?

다음 경우에 멀티 리전이 필요합니다: (1) 사용자가 전 세계에 분산되어 있고 지연 시간이 중요한 경우, (2) 규정이 특정 관할권에 데이터를 요구하는 경우, (3) 리전 전체의 장애에서도 살아남아야 하는 경우. 대부분의 애플리케이션은 단일 리전, 멀티 AZ로 시작하여 요구사항에 따라 리전을 추가합니다.

멀티 AZ 배포는 비용을 두 배로 만드나요?

반드시 그렇지는 않습니다. 동일한 총 용량에 대해 비용을 지불하는 것이며, 단지 다르게 분산될 뿐입니다. AZ 간 데이터 전송이 비용을 추가하지만, 전체 인프라 지출에 비하면 일반적으로 미미한 수준입니다. 신뢰성 향상은 대개 추가 비용을 충분히 정당화합니다.

리전 전체가 장애를 겪을 수 있나요?

드물지만 가능합니다. 주요 클라우드 공급자들도 리전 전체의 성능 저하나 장애를 경험했습니다. 리전 장애를 절대 허용할 수 없는 애플리케이션—다운타임이 시간당 수백만 달러의 비용을 초래하는 경우—이라면 멀티 리전 배포가 필요합니다. 대부분의 애플리케이션에서 멀티 AZ는 충분한 복원력을 제공합니다.