Day 2 - AWS 글로벌 인프라

먼저, 왜 이런 구조가 필요했나

Day 1에서 "클라우드는 남의 서버를 빌려 쓰는 것"이라고 했다. 그런데 그 서버는 어딘가에 물리적으로 존재한다. 건물이 있고, 전기가 들어오고, 인터넷 회선이 꽂혀 있다. 여기서 세 가지 현실적인 문제가 생긴다.

1. 거리는 속도다 — 데이터도 빛보다 빠를 수 없다. 서울 사용자가 지구 반대편 서버에 요청을 보내면 왕복하는 데 물리적으로 시간이 걸린다. 화면이 "느리다"고 느껴지는 원인이 대부분 이것이다.
2. 나라마다 법이 다르다 — "우리나라 국민의 개인정보는 국내에 보관해야 한다" 같은 규정이 있다. 서버가 어느 나라에 있는지가 법적 문제가 된다.
3. 건물은 사고를 당한다 — 정전, 화재, 홍수, 지진. 서버를 한 건물에 몰아 두면 그 건물 사고가 곧 서비스 전체의 중단이다.

AWS의 글로벌 인프라는 이 세 문제에 대한 답이다. 리전은 1·2번(거리와 법)을, 가용 영역은 3번(사고)을, 엣지 로케이션은 다시 1번(거리)을 더 촘촘하게 푼다. 이 대응 관계만 잡아 두면 오늘 내용은 절반쯤 끝난 셈이다.

리전(Region): 세계 곳곳의 거점

• 리전 = AWS가 데이터센터를 모아 둔 지리적 지역. 서울, 도쿄, 버지니아 북부, 프랑크푸르트처럼 전 세계 여러 곳에 있다.
• 사용자는 서비스를 만들 때 어느 리전에 둘지 직접 고른다.
• 리전에는 ap-northeast-2(서울), us-east-1(버지니아 북부) 같은 코드가 붙는다. 콘솔·설정 파일에서 이 코드로 리전을 지정한다.

리전 코드는 지역-방향-번호 규칙으로 읽으면 쉽다. ap는 아시아 태평양(Asia Pacific), us는 미국, eu는 유럽을 뜻하고, 뒤에 northeast(북동), west(서) 같은 방향과 순번이 붙는다. 즉 ap-northeast-2는 "아시아 태평양 북동쪽 두 번째 리전"이라는 뜻이다. 외울 필요는 없지만, 문항에 코드가 등장했을 때 당황하지 않을 정도로만 익혀 둔다.

리전을 고를 때 보통 다음 4가지를 따진다.

4가지 기준을 실제 상황에 대입하면 이렇게 쓰인다.

⚠️ 함정: 네 기준 중 규정 준수는 협상 대상이 아니다. "지연 시간이 조금 늘더라도 법을 지켜야 하는가, 법을 어기더라도 빨라야 하는가"를 묻는 문항은 없다. 지문에 "데이터 주권", "국내 보관 의무", "특정 국가를 벗어나면 안 됨" 같은 표현이 나오면 비용·지연 시간 보기는 전부 오답이고 규정 준수가 답이다.

리전은 서로 완전히 독립적으로 운영된다. 한 리전에서 문제가 생겨도 다른 리전에는 영향을 주지 않도록 격리되어 있다. 그래서 중요한 서비스를 여러 리전에 나누어 두면, 한 지역 전체에 장애가 나도 다른 지역에서 계속 서비스할 수 있다. 이것이 재해 복구(DR) 설계의 기본 아이디어다.

이 독립성에는 중요한 부작용이 하나 있다. 리전이 격리되어 있다는 말은 "자동으로 복사되지 않는다"는 뜻이기도 하다. 서울 리전에 만든 가상 서버나 저장된 파일은 도쿄 리전에서 그냥 보이지 않는다. 다른 리전에서도 쓰고 싶다면 고객이 명시적으로 복제를 설정해야 한다. 이 점이 시험에서 자주 함정으로 쓰인다.

한국 사용자 대상 서비스라면 보통 서울 리전을 고른다. 그런데 이 회사가 동남아로 넓히면 고민이 시작된다 — 서울 하나로 갈지, 현지 리전을 추가할지. 판단은 앞의 4가지로 한다. 현지 개인정보 규정이 있는가(규정 준수), 체감 속도가 문제 될 만큼 먼가(지연 시간), 쓰던 서비스가 그 리전에 있는가(서비스 가용성), 두 리전 운영 비용을 감당할 수 있는가(비용). 시험도 이런 상황에서 "가장 중요한 고려 사항"을 고르라고 묻는다.

가용 영역(Availability Zone, AZ): 리전 안의 독립된 묶음

• 하나의 리전은 다시 여러 개의 가용 영역(AZ)으로 나뉜다.
• 각 AZ는 하나 이상의 물리적 데이터센터로 이루어진, 전력·냉방·네트워크가 독립된 시설이다.
• AWS의 모든 리전은 보통 3개 이상의 AZ를 가진다.
• 왜 나눠 두었나: 한 데이터센터에 정전이나 화재가 나도 다른 AZ는 멀쩡하도록, 즉 장애가 번지지 않도록 물리적으로 떨어뜨려 둔 것이다.
• 그러면서도 AZ끼리는 빠른 전용 네트워크로 연결되어 있어 데이터를 거의 실시간으로 주고받는다.

        [ 리전: 서울 (ap-northeast-2) ]
                     |
      +--------+--------+--------+--------+
      |        |        |        |
    AZ-a     AZ-b     AZ-c     AZ-d   ← 각 AZ는 독립된 전력·네트워크
      |        |        |        |
   데이터센터  데이터센터  데이터센터  데이터센터

핵심 활용법은 간단하다. 서비스를 한 AZ에만 두지 말고 2개 이상의 AZ에 나누어 두면, 한 AZ가 통째로 죽어도 서비스가 살아남는다 → 고가용성(High Availability) 설계.

AZ가 하나 죽으면 실제로 무슨 일이 벌어지나

말로만 "고가용성"이라고 하면 잘 와닿지 않는다. 같은 서비스를 두 가지 방식으로 만들어 놓고, AZ-a에 정전이 났다고 해 본다.

[ 나쁜 설계 ]  모두 AZ-a에                 [ 좋은 설계 ]  AZ-a / AZ-b 분산
   웹서버 2대 ─┐                              웹서버 1대 ──┐        ┌── 웹서버 1대
   DB 1대     ─┤ AZ-a  ← 정전               DB(주)  ──────┤ AZ-a   │ AZ-b  DB(대기)
              ─┘                                          └────────┘
   → 전부 동시에 중단. 복구 = AZ 복구 대기      → 살아 있는 AZ-b로 트래픽 이동, 서비스 지속

• 나쁜 설계: 서버를 아무리 여러 대 띄웠어도 전부 같은 AZ면 소용없다. 전력·냉방·네트워크를 공유하는 묶음이 통째로 내려가기 때문이다. "서버 대수"가 아니라 "어디에 흩어 놓았는가"가 생존을 가른다.
• 좋은 설계: 트래픽을 나눠 주는 장치(로드 밸런서)가 죽은 AZ를 빼고 살아 있는 쪽으로만 요청을 보낸다. 데이터베이스도 다른 AZ에 대기본을 두면 그쪽이 주 역할을 넘겨받는다.

즉 AZ는 "장애를 가두는 방화벽"이다. AWS가 AZ끼리 거리를 두는 이유도 여기 있다 — 같은 홍수·정전에 함께 당하지 않을 만큼은 떨어뜨리되, 데이터를 실시간으로 주고받을 만큼은 가깝게.

⚠️ 함정: "가용 영역을 여러 개 쓰면 재해 복구(DR)까지 된다"는 보기는 틀렸다. AZ 분산은 한 리전 안에서의 고가용성이다. 지진이나 광역 정전으로 그 지역 전체가 영향을 받으면 같은 리전의 AZ들은 함께 위험해질 수 있다. 도시·국가 규모의 재해에 대비하려면 다른 리전에 복제를 두어야 한다. 문항에서 "한 건물·한 시설 장애" → AZ 분산, "지역 전체 재해" → 멀티 리전으로 구분한다.

"리전 ≠ 데이터센터 한 곳"이고 "AZ ≠ 데이터센터 한 곳"이라는 점이 시험 포인트다. 리전은 여러 AZ의 묶음, AZ는 하나 이상의 데이터센터의 묶음이다. 즉 리전 > AZ > 데이터센터 순서의 3단 구조로 기억하면 된다.

엣지 로케이션(Edge Location): 사용자에게 더 가까이

• 리전·AZ보다 훨씬 많은 수로, 사용자와 더 가까운 곳에 흩어져 있는 콘텐츠 전달용 거점. 전 세계 수백 곳에 있다.
• 대표 용도는 CloudFront(콘텐츠 전송 네트워크, CDN).
  • 예: 미국 서버의 이미지를 한국 사용자가 볼 때 매번 미국까지 다녀오면 느리다.
  • 한국 근처 엣지 로케이션에 그 이미지를 미리 복사(캐싱)해 두면 사용자는 가까운 곳에서 빠르게 받아 본다.
• 이 외에 Route 53(DNS) 같은 서비스도 엣지에서 동작한다.

리전·AZ는 "데이터와 연산을 두는 곳"이고, 엣지 로케이션은 "사용자에게 빠르게 전달하는 곳"이라는 역할 차이를 기억한다. 엣지에 콘텐츠를 캐싱하면 응답 속도가 빨라질 뿐 아니라 원본 서버의 부담도 줄어든다.

엣지 로케이션이 푸는 문제를 생활 비유로 바꾸면 동네 편의점이다. 물류창고(리전)는 전국에 몇 곳뿐이라 물건을 받으려면 오래 걸린다. 그래서 자주 팔리는 물건은 미리 동네 편의점(엣지)에 갖다 놓는다. 손님은 가까운 편의점에서 바로 받아 가고(빠름), 창고는 주문이 줄어 한가해진다(부하 감소).

• 첫 요청은 캐시가 비어 있으니 원본까지 다녀온다(느림).
• 그다음 요청부터는 엣지에 남아 있는 사본을 바로 준다(빠름).
• 그래서 똑같은 콘텐츠를 많은 사람이 반복해서 받는 경우(이미지, 동영상, 정적 파일, 소프트웨어 배포)에 효과가 가장 크다.

국내에만 서버를 둔 쇼핑몰이 해외 판매를 시작했다고 가정한다. 해외 고객은 상품 이미지 하나를 볼 때마다 한국까지 왕복해야 해서 페이지가 눈에 띄게 느리다. 리전을 옮기면 이번엔 국내 고객이 느려진다. 이럴 때 답이 CDN이다. 원본은 서울 리전에 그대로 두고, 이미지·CSS·동영상 같은 정적 콘텐츠만 전 세계 엣지에 캐싱하면 양쪽 모두 빨라진다. "서버를 옮기지 않고 해외 사용자 체감 속도를 개선"이라는 지문이 나오면 정답은 거의 CloudFront다.

리전 · AZ · 엣지, 한눈에 구분하기

셋은 이름이 비슷해서 자꾸 섞인다. "무엇을 위해 존재하는가"로 나눠 기억하는 게 가장 안전하다.

여기에 하나 더, 시험에 이름이 등장할 수 있는 것이 있다.

• 로컬 존(Local Zone): 리전의 일부를 사용자가 많은 대도시 가까이로 확장해 둔 것. 엣지처럼 "가깝다"는 목적은 같지만, 엣지가 콘텐츠를 캐싱하는 곳이라면 로컬 존은 연산·저장을 실제로 돌리는 곳이라는 점이 다르다. 아주 낮은 지연 시간이 필요한 특수한 경우에 쓴다.

함정: "엣지 로케이션에 애플리케이션을 배포한다"는 보기는 기본적으로 틀렸다고 보면 된다. 엣지의 본래 역할은 콘텐츠 전달과 캐싱이지 서비스 실행 기반이 아니다. 애플리케이션과 데이터베이스는 리전 안의 AZ에서 돌아간다.

글로벌 서비스 vs 리전 서비스

AWS 서비스는 크게 두 종류로 나뉜다. 이 구분은 시험 범위에 든다.

• 대부분의 서비스는 "어느 리전에 둘지"를 골라야 하는 리전 서비스다.
• 반면 IAM(계정·권한 관리), Route 53(도메인 DNS), CloudFront(엣지 캐싱)처럼 본질적으로 전 세계에 걸쳐 동작해야 하는 것들은 글로벌 서비스다.

글로벌인지 리전인지 헷갈릴 때는 "이게 전 세계에 하나만 있어야 말이 되는가?"를 자문해 보면 대체로 맞는다.

• 사용자 계정과 권한(IAM)이 리전마다 따로 있으면? 서울에서는 관리자인데 도쿄에서는 아니라는 뜻이 된다 — 말이 안 된다. → 글로벌
• 도메인 이름(Route 53)이 리전마다 다르면? 접속하는 위치에 따라 다른 사이트가 뜬다 — 말이 안 된다. → 글로벌
• 엣지 캐싱(CloudFront)은 애초에 전 세계에 뿌리는 것이 목적이다. → 글로벌
• 반면 가상 서버(EC2)나 데이터베이스(RDS)는 "어디에 둘지"가 곧 지연 시간과 규정 준수 문제다. → 리전

S3는 헷갈리기 쉬운 예다. S3 버킷 이름은 전 세계에서 유일해야 하지만(글로벌 네임스페이스), 실제 데이터는 특정 리전에 저장된다. 즉 이름은 글로벌, 데이터는 리전이다. "버킷 이름이 글로벌하다고 데이터까지 전 세계에 복제되는 것은 아니다"라는 점을 꼭 구분한다.

시험에는 이렇게 나온다

글로벌 인프라 문항은 지문에 답의 힌트가 거의 그대로 들어 있다. 아래 대응만 익혀도 대부분 풀린다.

• 보기에 "모든 리전에 자동으로 복제된다"는 표현이 있으면 대개 오답이다. 리전 간 복제는 고객이 설정해야 한다.
• "AZ는 데이터센터 한 곳", "리전은 데이터센터 한 곳" 같은 보기도 오답이다. 둘 다 묶음이다.

다음 글에서는 이 인프라 위에서 "보안과 운영의 책임이 AWS와 고객 중 누구에게 있는가"를 정하는 공동 책임 모델을 본다.

📖 용어

• 리전(Region) : AWS가 데이터센터를 모아 둔 지리적 지역. 서울, 도쿄처럼 나라·도시 단위로 있다.
• 가용 영역(AZ) : 리전 안에 있는, 전력·냉방·네트워크가 서로 독립된 시설 묶음. 하나 이상의 데이터센터로 이루어진다.
• 엣지 로케이션 : 사용자 가까이에 콘텐츠를 미리 갖다 놓는 작은 거점. 리전보다 훨씬 많다.
• 캐싱 : 자주 쓰는 데이터를 가까운 곳에 미리 복사해 두고 빠르게 꺼내 쓰는 것.
• CDN(콘텐츠 전송 네트워크) : 전 세계 엣지에 콘텐츠를 뿌려 사용자에게 빠르게 전달하는 구조. AWS에서는 CloudFront.
• 고가용성(High Availability) : 일부가 고장 나도 서비스가 멈추지 않도록 만드는 설계. AZ 2개 이상에 나눠 두는 것이 기본.
• 재해 복구(DR) : 한 지역 전체가 마비돼도 다른 지역에서 서비스를 이어가도록 대비하는 것.
• 리전 서비스 vs 글로벌 서비스 : 특정 리전에 묶여 동작하는가(EC2·RDS·S3), 리전과 무관하게 전 세계 하나로 동작하는가(IAM·Route 53·CloudFront).
• 글로벌 네임스페이스 : 이름이 전 세계에서 딱 하나여야 하는 규칙. S3 버킷 이름이 그렇다(데이터 자체는 특정 리전에 저장된다).
• 지연 시간(Latency) : 요청을 보내고 응답이 올 때까지 걸리는 시간. 거리가 멀수록 커진다.
• 리전 코드 : ap-northeast-2(서울)처럼 리전을 가리키는 식별자. 지역-방향-번호 형태로 읽는다.
• 로드 밸런서 : 들어오는 요청을 여러 서버에 나눠 주는 장치. 죽은 AZ를 빼고 살아 있는 쪽으로 보낸다.
• 로컬 존(Local Zone) : 리전의 일부를 대도시 가까이로 확장한 것. 엣지와 달리 연산·저장을 실제로 수행한다.
• 데이터 주권 : 데이터가 어느 나라의 법 적용을 받는가의 문제. "국내 보관 의무"가 대표적이다.
• 멀티 AZ / 멀티 리전 : 여러 AZ에 분산(고가용성) / 여러 리전에 분산(재해 복구). 대비하는 사고의 규모가 다르다.
• 오리진(Origin) : CDN이 캐싱해 갈 원본이 있는 곳. 보통 리전 안의 서버나 스토리지다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

AWS 인프라의 구성 단위를 큰 것부터 작은 것 순으로 올바르게 나열한 것은?

• A가용 영역 > 리전 > 데이터센터
• B리전 > 가용 영역 > 데이터센터
• C데이터센터 > 리전 > 가용 영역
• D엣지 로케이션 > 리전 > 가용 영역

문제 2

한 AZ에 장애가 발생해도 서비스가 중단되지 않게 하려면 가장 적절한 방법은?

• A모든 자원을 하나의 AZ에 몰아서 배치한다
• B서비스를 2개 이상의 AZ에 나누어 배치한다
• C엣지 로케이션에만 서비스를 둔다
• D리전을 자주 변경한다

문제 3

미국 서버의 이미지를 한국 사용자에게 더 빠르게 전달하기 위해 사용자와 가까운 곳에 콘텐츠를 캐싱하는 데 쓰이는 인프라는?

• A가용 영역
• B리전
• C엣지 로케이션
• D데이터센터

문제 4

다음 중 리전과 무관하게 전 세계 하나로 동작하는 글로벌 서비스는?

• AEC2
• BRDS
• CIAM
• DEBS

문제 5

리전을 선택할 때 고려할 요소로 보기 어려운 것은?

• A사용자와의 거리에 따른 지연 시간
• B데이터를 국내에 보관해야 하는 규정 준수
• C해당 리전에서 제공되는 서비스 가용성
• D가용 영역의 색상