Azure 아키텍처를 이해하는 것은 AZ-900 시험의 필수 과제입니다. Azure는 물리적 인프라(어디에 서버가 있는가)와 논리적 구조(리소스를 어떻게 묶고 관리하는가)로 나뉩니다. 전국 물류 네트워크와 회사 서류 정리 시스템 비유로 한 번에 이해해 봅시다.
전체 구조 한눈에 보기
Azure의 전체 인프라는 크게 두 차원으로 나뉩니다.
물리적 차원은 "Azure 서버가 전 세계 어디에 있는가"를 다룹니다. 데이터센터, 리전, 가용성 영역, 리전 쌍이 여기에 속합니다.
논리적 차원은 "Azure 리소스를 어떻게 묶고 관리하는가"를 다룹니다. 리소스, 리소스 그룹, 구독, 관리 그룹이 여기에 속합니다.
물리적 인프라 — 전국 물류 네트워크 비유
전국에 여러 도시에 물류센터를 운영하는 대형 택배 회사를 상상해 보세요. 서울, 부산, 대구, 인천에 각각 독립적인 물류센터가 있습니다. 한 도시의 물류센터에 문제가 생겨도 다른 도시의 물류센터는 정상적으로 운영됩니다. Azure 리전이 바로 이 물류센터에 해당합니다.
데이터센터 (Data Centers)
Azure의 모든 것은 물리적 데이터센터에서 시작합니다. 데이터센터는 실제 서버, 네트워크 장비, 스토리지가 모여있는 건물입니다. Azure는 전 세계에 수백 개의 데이터센터를 운영합니다. 각 데이터센터는 독립적인 전력 공급, 냉각 시스템, 네트워크 연결을 갖추고 있습니다. 보안을 위해 일반인은 접근할 수 없으며 정확한 위치도 공개되지 않습니다.
리전 (Region)
리전은 같은 지리적 지역 안에 위치한 여러 데이터센터의 집합입니다. Azure는 전 세계 60개 이상의 리전을 운영하며, 이는 다른 어떤 클라우드 공급자보다도 많습니다.
주요 리전 목록 (예시)
| 지역 | 리전 이름 | |------|---------| | 한국 | Korea Central (서울), Korea South (부산) | | 미국 | East US (버지니아), West US (캘리포니아), Central US (아이오와) | | 유럽 | North Europe (아일랜드), West Europe (네덜란드) | | 아시아 | East Asia (홍콩), Southeast Asia (싱가포르) | | 일본 | Japan East (도쿄), Japan West (오사카) |
리전 선택 시 고려할 사항
지연 시간 (Latency): 최종 사용자와 가장 가까운 리전을 선택하면 응답 속도가 빨라집니다. 예를 들어 한국 사용자를 위한 서비스라면 Korea Central 리전이 최선입니다. 데이터 주권 (Data Sovereignty): 일부 국가의 법률은 특정 종류의 데이터를 국내에서만 보관하도록 요구합니다. 예를 들어 EU의 GDPR은 유럽 시민 데이터를 유럽 내에 보관할 것을 요구할 수 있습니다. 서비스 가용성: 모든 Azure 서비스가 모든 리전에서 제공되지는 않습니다. 특정 서비스를 사용하려면 해당 서비스가 지원되는 리전을 선택해야 합니다. 비용: 리전마다 가격이 다를 수 있습니다. 미국 동부 리전이 일반적으로 가장 저렴한 편입니다. 규정 준수 (Compliance): 특정 산업(금융, 의료)에서는 특정 지역의 데이터센터를 사용해야 하는 규제가 있을 수 있습니다.
가용성 영역 (Availability Zones)
같은 물류센터(리전) 안에서도 여러 독립 건물을 운영한다고 생각해 보세요. 건물 A, 건물 B, 건물 C가 각각 독립적인 전기 배선, 냉방 시스템, 인터넷 연결을 갖추고 있습니다. 건물 A에 화재가 나도 건물 B와 C는 정상 운영됩니다. 이것이 가용성 영역입니다.
가용성 영역은 하나의 리전 안에서 물리적으로 분리된 데이터센터입니다. 각 가용성 영역은 독립적인 전원 공급 장치, 냉각 시스템, 네트워킹을 갖추고 있어 한 영역이 완전히 다운되어도 다른 영역에 영향을 주지 않습니다. 보통 하나의 리전에 3개의 가용성 영역이 있습니다.
가용성 영역 활용 방법
Zone-redundant 서비스: Azure가 자동으로 여러 영역에 데이터나 애플리케이션을 복제합니다. Azure Storage의 ZRS(Zone-Redundant Storage)가 대표적입니다. Zonal 서비스: 특정 영역에 리소스를 직접 배치합니다. 예를 들어 VM을 영역 1, 2, 3에 각각 하나씩 배치하면 하나의 영역이 다운되어도 서비스가 지속됩니다.
리전 쌍 (Region Pairs)
쌍둥이 물류센터 비유로 이해해 봅시다. 서울 물류센터와 부산 물류센터가 공식적으로 쌍을 이룹니다. 서울에 대규모 재해(지진, 홍수)가 발생하면, 부산 물류센터가 자동으로 서비스를 인수합니다. 두 센터는 항상 서로의 상태를 모니터링합니다. 이것이 리전 쌍입니다.
주요 리전 쌍 목록
| 리전 1 | 리전 2 | |-------|-------| | Korea Central (서울) | Korea South (부산) | | East US (미국 동부) | West US (미국 서부) | | North Europe (북유럽) | West Europe (서유럽) | | East Asia (동아시아) | Southeast Asia (동남아시아) | | Japan East (일본 동부) | Japan West (일본 서부) |
리전 쌍의 중요한 특징
두 리전은 같은 지리적 영역(같은 국가 또는 인접 국가) 내에서 최소 300km 이상 떨어져 있습니다. 대규모 재해 발생 시 한 리전에서 다른 리전으로 자동 페일오버가 이루어집니다. Azure는 플랫폼 업데이트를 진행할 때 리전 쌍 중 두 리전을 동시에 업데이트하지 않습니다. 먼저 하나를 업데이트하고 문제가 없으면 다른 하나를 업데이트합니다. 이로 인해 업데이트 중 전체 서비스 중단을 방지합니다. 데이터 복제 시 동일 국가 또는 인접 국가 내의 리전 쌍에 복제하여 데이터 주권 규정을 준수합니다.
가용성 영역 vs 리전 쌍 비교
| 구분 | 가용성 영역 | 리전 쌍 | |------|-----------|--------| | 범위 | 같은 리전 내 | 서로 다른 리전 (수백 km 거리) | | 거리 | 몇 km 이내 | 최소 300km 이상 | | 보호 대상 | 단일 데이터센터 장애 | 리전 전체에 영향을 미치는 재해 | | 일반적인 수 | 리전당 3개 | 리전마다 1개의 쌍 | | 활성 여부 | 둘 다 동시 활성 | 장애 시 하나가 대기에서 활성으로 전환 |
소버린 리전 (Sovereign Regions)
일반 Azure 상용 리전과 물리적, 논리적으로 완전히 격리된 특수 목적 리전입니다. 특정 정부나 규제 요건을 충족시키기 위해 존재합니다.
Azure Government: 미국 연방정부, 주정부, 지방정부 및 그 파트너 전용입니다. 미국 내에서만 접근 가능하며, 일반 Azure 계정으로는 절대 접근할 수 없습니다. 미국 정부의 FedRAMP, DoD 보안 규정을 준수합니다. Azure China: 중국 법률에 따라 중국 내에서만 운영되는 격리된 환경입니다. Microsoft가 아닌 중국 기업 21Vianet이 운영합니다.
시험에서 "특정 국가의 정부기관을 위한 특수 Azure 환경"이 언급되면 소버린 리전이 정답입니다.
논리적 구조 — 회사 서류 정리 시스템 비유
물리적 인프라가 "Azure 서버의 위치"라면, 논리적 구조는 "Azure 리소스를 어떻게 관리하는가"입니다. 회사 서류를 정리하는 방식에 비유하면 쉽게 이해됩니다.
리소스(Resource)는 문서 한 장입니다. VM 하나, 데이터베이스 하나, 네트워크 하나가 각각 하나의 리소스입니다.
리소스 그룹(Resource Group)은 파일 폴더입니다. 관련된 문서들을 하나의 폴더에 모읍니다. 예를 들어 "웹 프로젝트" 폴더에는 웹 서버 VM, 데이터베이스, 로드 밸런서를 모읍니다.
구독(Subscription)은 파일 서랍입니다. 하나의 서랍이 하나의 청구서를 만듭니다. 부서마다 다른 서랍을 사용하면 부서별 비용을 분리할 수 있습니다.
관리 그룹(Management Group)은 파일 캐비넷 전체입니다. 여러 서랍(구독)을 하나의 캐비넷으로 묶어 전체에 같은 보안 정책을 한 번에 적용합니다.
!Azure 리소스 계층 구조
전체 계층 구조
리소스 그룹 (Resource Groups)
리소스 그룹은 관련된 Azure 리소스를 하나의 단위로 묶어 관리하는 컨테이너입니다. 모든 Azure 리소스는 반드시 하나의 리소스 그룹에 속해야 합니다.
리소스 그룹의 중요한 특성
모든 Azure 리소스는 정확히 하나의 리소스 그룹에만 속할 수 있습니다. (동시에 두 그룹에 속하는 것은 불가능) 리소스 그룹을 삭제하면 그 안의 모든 리소스가 함께 삭제됩니다. 이것은 매우 강력한 기능이지만, 잘못 사용하면 데이터 손실로 이어질 수 있습니다. 리소스 그룹 자체는 비용이 발생하지 않습니다. 그룹 안의 리소스들만 비용이 발생합니다. 한 리소스 그룹의 리소스가 다른 리소스 그룹의 리소스와 자유롭게 통신할 수 있습니다. 리소스는 다른 리소스 그룹으로 이동할 수 있습니다. (일부 리소스 유형은 이동에 제한이 있음) 리소스 그룹에 태그(Tag)를 붙여 비용 추적이나 분류에 활용할 수 있습니다.
리소스 그룹 구성 패턴
프로젝트별: "프로젝트A-개발", "프로젝트A-운영" 환경별: "개발(Dev)-리소스그룹", "테스트(Test)-리소스그룹", "운영(Prod)-리소스그룹" 부서별: "마케팅팀-리소스그룹", "엔지니어링팀-리소스그룹" 수명 주기별: 같은 시기에 함께 삭제될 리소스들을 한 그룹에 모음
구독 (Subscriptions)
구독은 Azure 서비스를 사용하기 위한 계약 단위이자 청구 단위입니다. 모든 Azure 리소스는 반드시 하나의 구독에 속해야 합니다. 구독은 접근 제어의 경계 역할도 합니다.
구독의 주요 역할
청구 경계: 각 구독마다 별도의 청구서가 발행됩니다. 부서별로 구독을 분리하면 부서별 클라우드 비용을 정확하게 파악할 수 있습니다. 접근 제어 경계: 구독 단위로 Azure RBAC(역할 기반 접근 제어)를 적용할 수 있습니다. 특정 팀이 접근할 수 있는 구독을 별도로 분리합니다. 리소스 한도: 각 구독에는 리소스 생성 한도가 있습니다. 예를 들어 구독당 VM은 기본적으로 최대 20,000개로 제한됩니다. 한도 초과 시 새 구독을 만들거나 한도 증가를 요청할 수 있습니다.