[AZ-900] 자격증 완벽정리_7편_리전, 가용성 존, 리소스 그룹 등 인프라 개념

2025.05.16 - [MS Azure, AI] - [AZ-900] 자격증 완벽 정리 1편_클라우드 컴퓨팅 개념과 Azure 소개

2025.05.17 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리 2편_Azure 핵심 서비스: 컴퓨팅, 스토리지, 네트워크

2025.05.18 - [MS Azure, AI] - [AZ-900] 자격증 완벽전리_3편_ Azure 관리 도구(포털, CLI, PowerShell)

2025.05.18 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_4편_보안, 컴플라이언스, 개인정보 보호

2025.05.19 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_5편_Azure 비용, 구독, 라이선스, SLA

2025.05.20 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_6편_Azure ID 및 액세스 제어(RBAC, Azure AD)

Azure 서비스를 살펴보다 보면 “리전(Region)”, “가용성 영역(Availability Zone)”, “리소스 그룹(Resource Group)” 등의 용어를 자주 접하게 됩니다. 이는 Azure가 물리적으로, 그리고 논리적으로 인프라를 구성하는 방식과 관련됩니다. 이번 글에서는 **Azure의 글로벌 인프라 구조(Region, Region Pair, Availability Zone)**와 리소스 조직을 위한 논리 단위(Subscription, Resource Group) 등을 초보자도 이해하기 쉽게 설명하고, AZ-900 시험 포인트를 짚어보겠습니다.

Azure 리전(Region)과 지역 쌍(Region Pair)

**Azure 리전(Region)**은 Azure 데이터센터들이 모여있는 지리적 지역을 의미합니다. 마이크로소프트는 전 세계에 걸쳐 수십 개 이상의 Azure 리전을 운영 중이며, 한 리전은 보통 특정 도시/권역 이름으로 불립니다 (예: East US, West Europe, Korea Central 등). 각 리전은 여러 데이터센터로 구성되어 있고, Azure의 기본적인 배포 단위입니다. 즉, Azure에서 VM이나 스토리지 계정을 만들 때 “어느 리전에 만들 것인가?”를 선택해야 하며, 그 리전 내의 데이터센터들 중 한 곳에 실제로 배치됩니다.

리전을 둔 이유는 전 세계 사용자에게 더 빠른 서비스를 제공하고, 재해 발생 시 다른 지역으로 서비스 확장/복구하기 위함입니다. 예를 들어 한국에 사용자가 많다면 Korea Central(서울) 리전에 리소스를 만들면 지연시간(latency)이 낮고, 미국에 서비스할 땐 East US 등 가까운 곳에 만드는 식입니다.

Azure 리전의 특징:

• 대부분 리전은 물리적으로 서로 수백 km 이상 떨어져 있습니다. 지역적인 재해 (지진, 정전 등)에 동시 영향받지 않도록 설계되었습니다.
• Azure는 Region Pair(지역 쌍) 개념이 있습니다. 각 리전은 같은 지역 내에 짝으로 둘씩 쌍을 이룹니다. 예를 들어 Korea Central(서울) – **Korea South(부산)**이 지역 쌍입니다. Azure는 업데이트나 장애 시 한 쌍 중 하나는 보호하는 정책을 가지고 있습니다. 예를 들어, 한 쌍의 리전에 동시에 업데이트를 가하지 않아서 한쪽에서 문제가 생기면 다른 쪽은 영향을 덜 받도록 합니다. 또 지리적 재해 복구를 위해 주로 쌍으로 데이터를 복제(예: GRS 스토리지)하거나 하는 최적화가 되어 있습니다.
• 주요 규제 준수: 일부 리전은 정부 전용 (예: US Gov), 중국 운영사 전용 (China region) 등 특수 목적도 있습니다만, 일반적으로 상용 리전은 Azure 글로벌 망으로 연결되어 유사한 서비스를 제공합니다. 다만 리전마다 제공 서비스나 가격이 약간씩 다를 수 있음은 참고해야 합니다.

시험 팁: “리전이 무엇인가?”를 묻는 문제가 나올 수 있고, 답은 **“Azure가 리소스를 배포하는 지리적 지역 단위로, 하나 이상의 데이터센터로 구성됨”**이 핵심입니다. 또한 **지역 쌍(Region Pair)**의 이점을 물으면 **“주요 재해 복구 및 업데이트 대비로 한 쌍의 리전이 논리적으로 연결되어 운영된다”**는 점을 언급할 수 있습니다.

가용성 세트(Availability Set)와 가용성 영역(Availability Zone)

Azure는 단일 리전 내에서 고가용성을 높이기 위한 개념으로 가용성 세트와 가용성 영역을 제공합니다:

• 가용성 세트(Availability Set): 같은 리전에 여러 VM을 배포할 때, 물리 호스트가 겹치지 않도록 묶어주는 논리 그룹입니다. 가용성 세트 내 VM들은 Azure가 서로 다른 **Fault Domain(폴트 도메인)**과 **Update Domain(업데이트 도메인)**에 분산시킵니다. Fault Domain은 전원/네트워크 등 공유하는 물리 요소 그룹을 의미하고, Update Domain은 Azure가 계획 업데이트(패치, 재부팅 등)를 동시에 수행하는 그룹을 뜻합니다. 예를 들어, 가용성 세트에 VM 3대를 넣고 Fault Domain 수=2, Update Domain 수=3으로 하면, Azure는 3대 VM을 2개의 다른 랙(전원, 네트워크 분리)에 분산시키고 3개의 업데이트 도메인에 걸쳐 배치합니다. 그 결과 한 랙이 장애 나도 1~2대 VM은 살아있고, Azure 패치로 한 번에 한대씩만 재부팅되도록 보장됩니다. 시험에서는 가용성 세트가 “VM들을 서로 다른 물리 호스트에 배치해 하드웨어/소프트웨어 장애 위험을 분산한다”라는 개념을 이해하는지 물을 수 있습니다.
• 가용성 영역(Availability Zone, AZ): 이는 리전 내의 물리적으로 분리된 데이터센터를 의미합니다azure.microsoft.com. Azure는 일부 리전에서 AZ 기능을 제공하며, 보통 3개 이상의 Zone(영역)이 정의됩니다. Zone 간에는 건물/전력/쿨링이 완전히 독립적이어서, 한 Zone의 데이터센터가 정전되어도 다른 Zone은 영향을 받지 않습니다. 사용자가 VM, 스토리지 등을 배포할 때 명시적으로 “Zone 1, Zone 2…”에 리소스를 만들어 분산할 수 있습니다. 이렇게 Zone을 활용하면 같은 리전 안에서도 데이터센터 단위 장애까지 견딜 수 있는 고가용성을 얻습니다. Azure는 Zone冗障(존 중복) 옵션을 통해 자동으로 복제해주는 서비스들도 있습니다 (예: Zone-redundant storage, ZRS).
  • 예: 만약 VM 3대를 Zone 1,2,3에 하나씩 만들고 부하분산하면, 한 Zone이 정전되어 1대 VM이 꺼져도 나머지 2대가 서비스 유지하게 됩니다. Azure VM SLA도 가용성 영역을 활용하면 99.99%까지 올라갑니다 (단일 VM SLA 99.9%보다 향상).
• 가용성 세트 vs 가용성 영역: 둘 다 고가용성 기능이지만, 가용성 세트는 같은 데이터센터 내 논리적 분산, 가용성 영역은 아예 다른 데이터센터로 물리적 분산이라는 차이입니다. 최신 시스템 설계에서는 가용성 영역 사용이 권장되는 추세이지만, 모든 리전에 AZ가 있는 건 아니므로 가용성 세트도 여전히 쓰입니다.

시험 포인트: “여러 VM을 고가용성 위해 Azure에 배포하려면?”, “Azure 가용성 영역이 뭐냐?” 등이 있을 수 있습니다. 답은 가용성 영역 = 같은 리전 내 독립된 데이터센터로, 장애 격리를 위해 사용azure.microsoft.com. 가용성 세트 = 물리 호스트/랙 수준 분산.
그리고 “SLA를 높이려면 VM을 가용성 영역/세트에 배포”라는 식으로 물어볼 가능성이 높습니다.

Azure 리소스 그룹(Resource Group)

**리소스 그룹(Resource Group)**은 Azure 리소스를 논리적으로 묶는 컨테이너입니다. Azure에서 생성되는 모든 리소스는 반드시 하나의 리소스 그룹에 속해야 합니다. 리소스 그룹의 특징과 용도:

• 수명주기 관리의 단위: 같은 리소스 그룹에 속한 자원들은 함께 배포되거나 삭제될 수 있습니다. 예를 들어, 웹앱, DB, VNet 등 관련 컴포넌트를 한 RG에 넣으면, RG를 통째로 삭제(delete)하면 안의 리소스들이 일괄 삭제되어 정리하기 편리합니다.
• 접근제어와 정책 적용 단위: Azure RBAC 권한이나 Azure Policy(정책)를 리소스 그룹별로 적용할 수 있습니다. 예컨대 개발팀 RG에는 개발자들에게 Contributor 권한을 주고, 운영팀 RG에는 Read 권한만 주는 식으로. 또한 비용 모니터링도 RG별로 할 수 있어, 프로젝트별 지출 파악에 도움이 됩니다.
• 지역성: 리소스 그룹 자체는 메타데이터가 저장되는 리전을 선택하게 되어 있습니다 (리소스 그룹 위치). 그러나 이는 RG 객체의 위치일 뿐이고, RG 안에 서로 다른 리전의 리소스들도 들어갈 수 있습니다. 즉, RG는 논리 폴더일 뿐 물리적 위치가 일치할 필요는 없습니다. 다만, Azure 권고는 RG 안 리소스들이 함께 배포/관리되는 경우가 많으니 관련된 것끼리 묶으라는 겁니다.
• Naming/Tagging과 함께 활용: RG 이름을 잘 지어서 구분하고, 추가로 리소스에 Tag(태그)를 붙여 비용센터나 환경(개발/운영) 등을 표기하면 나중에 관리가 수월해집니다. AZ-900에서도 태그(Tag) 개념이 나오는데, 태그는 리소스나 RG에 Key-Value 형태 메타데이터를 붙여 분류/검색/과금분석에 쓰는 기능입니다. 예: Department:Finance 태그를 모든 재무 프로젝트 리소스에 붙여서 비용을 부서별로 볼 수 있음.

시험 팁: “리소스 그룹의 용도는?” = **“Azure 리소스를 논리적으로 묶어 관리하고 권한/정책/삭제 등을 일괄 적용하기 위한 컨테이너”**입니다. 특히 리소스 그룹 단위 삭제로 손쉬운 정리가 장점이므로 잘 언급합니다.
Tag에 대해서는 “Azure Tag는 리소스에 추가하는 Key-Value 표식으로, 메타데이터 관리에 쓴다 (예: 환경=Dev)”라는 정도 알아두세요.

구독(Subscription)과 관리 그룹(Management Group)

이전 글(5편)에서 구독과 관리 그룹을 비용 측면에서 다뤘지만, 논리 구조 측면에서도 다시 언급합니다:

• 구독(Subscription): Azure 리소스를 생성하려면 반드시 속할 구독이 있어야 합니다. 구독은 리소스 그룹의 상위 계층입니다. 하나의 구독 안에 여러 RG가 있고, 그 아래 리소스들이 있는 구조입니다. 구독은 보통 **과금, 소유 주체(tenant)**를 기준으로 나뉘지만, 조직에서는 워크로드나 환경별로 여러 구독을 만들기도 합니다 (예: Dev/Test 구독, Prod 구독). 구독별로 최대 자원 할당량(quota)이나, RBAC 관리 등이 격리됩니다.
• 관리 그룹(Management Group): 구독이 여러 개 있을 때, 그것들을 묶어 상위 레벨에서 정책/권한을 일괄 관리하기 위한 계층입니다. 예를 들어 기업 전체 공통 규칙(모든 리소스는 특정 지역에만 생성 가능)을 관리 그룹에 Azure Policy로 적용하면, 하위 모든 구독에 일괄 적용됩니다. 관리 그룹은 트리 계층을 만들 수 있어, 회사 -> 사업부 -> 하위 부서 의 관리 그룹별로 구독 묶어 관리도 가능합니다.
• 계층 정리: Management Group > Subscription > Resource Group > Resource.

시험 팁: Management Group은 최근 AZ-900에도 포함되었을 수 있어요. 질문으로는 “Management Group의 역할” 같은 게 나오면 **“다수 구독을 묶어 상위에서 관리하기 위한 폴더 구조”**라고 답하면 됩니다. 또는 “구독 간의 정책/액세스를 일괄 관리할 수 있다”.

Azure Policy도 시험엔 종종 나오는데, Azure Policy는 정책을 정의하여 Azure 환경 설정의 일관성을 강제하는 서비스입니다. 예를 들어 “허용된 VM 타입은 D시리즈 뿐” 또는 “태그 없는 리소스 생성 금지” 등의 정책을 만들어 Subscription이나 RG에 적용하면, 그걸 어기는 자원 생성은 막거나 검사에서 Non-compliant로 표시합니다. AZ-900에서는 Policy를 “Azure 환경의 거버넌스를 위해 규정 준수 여부를 자동 검사/강제하는 도구” 정도로 이해하면 됩니다.

인프라 개념 간 관계

이제까지 나온 개념들을 작은 예로 종합해보겠습니다:

한 전자상거래 회사가 Azure를 사용한다고 가정:

• 회사는 Azure AD 테넌트를 하나 가지고, 그 아래 Prod 구독, Dev 구독 두 개를 운영. (관리 그룹으로 Prod/Dev 구독을 묶어 공통정책 적용 가능)
• Prod 구독 내에 “WebApp-RG”, “DB-RG”, “Networking-RG” 등으로 리소스 그룹을 분리. 웹앱 관련 자원, DB 관련 자원 등을 별도 RG에.
• WebApp-RG에는 East US 리전에 App Service, VM 등이 들어있음. DB-RG에는 East US의 SQL Database 등이.
• 회사 서비스는 고가용성 위해 East US를 주 리전, West US를 보조로 사용. (두 리전은 Region Pair) 따라서 중요한 데이터는 GRS로 West US까지 복제.
• 웹앱 VM은 East US 내 Availability Zone 1과 2에 분산하여 99.99% SLA 확보.
• Dev 구독에는 개발/테스트 리소스들이 있고, 비용 절감 위해 소규모로만 사용. 정책으로 Dev 구독 리소스는 낮은 SKU만 허용.
• Azure AD에서 Prod 운영 팀에게 Prod 구독 RG들에 Contributor RBAC 권한 부여, Dev팀에는 Dev 구독 Owner 권한 부여.
• 모든 자원에는 Tag 붙임: (Environment:Prod/Dev, Project:ShoppingApp 등) 추후 비용 분석이나 식별에 활용.

이 시나리오에서:

• Region/Zone: 물리 인프라 위치와 고가용성 전략.
• RG: 리소스 묶음으로 논리적 구성.
• Subscription: 청구/운영 분리 단위.
• Management Group: 상위 거버넌스 용도.
• RBAC: 접근 제어.
• Tag/Policy: 거버넌스/관리 보조.

이렇게 Azure 인프라 개념들이 유기적으로 사용됩니다.

마무리 요약

이번 글에서는 Azure의 물리/논리 인프라 개념들을 정리했습니다. 리전은 Azure 데이터센터들의 지역 단위이며, 가용성 영역은 리전 내 독립 데이터센터로 고가용성에 사용됩니다azure.microsoft.com. 가용성 세트는 동일 데이터센터 내 VM을 물리적으로 분리배치하여 장애 영향을 최소화하는 기능입니다. 리소스 그룹은 리소스를 논리적으로 묶어 관리/권한부여/삭제의 단위를 제공하고, 구독은 그 상위의 청구 단위이자 관리 범위입니다. 다수 구독이 있을 때 관리 그룹으로 상위 통제가 가능하며, 태그와 정책으로 리소스를 분류하고 표준화할 수 있습니다.

시험에서는 이런 용어들의 정의나 간단한 사례 적용을 묻습니다. 예를 들어:

• “리소스 그룹의 주요 이점은?” – (정답) 그룹 단위 일괄 관리/삭제, 권한과 정책 적용 단위.
• “서로 다른 지역에 복제하려면 Azure 어느 개념 활용?” – Region Pair / GRS storage.
• “가용성 향상을 위해 같은 VM 2대를 어떻게 배포?” – 가용성 영역 다른 곳에 각각 배포 또는 가용성 세트 구성.
• “조직에 여러 구독이 있을 때 공통 규칙 적용 방법?” – 관리 그룹 + Azure Policy 사용.

이러한 키 포인트들을 잘 이해하셨다면 AZ-900 인프라 개념 파트도 문제 없습니다.

 

 

2025.05.16 - [MS Azure, AI] - [AZ-900] 자격증 완벽 정리 1편_클라우드 컴퓨팅 개념과 Azure 소개

2025.05.17 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리 2편_Azure 핵심 서비스: 컴퓨팅, 스토리지, 네트워크

2025.05.18 - [MS Azure, AI] - [AZ-900] 자격증 완벽전리_3편_ Azure 관리 도구(포털, CLI, PowerShell)

2025.05.18 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_4편_보안, 컴플라이언스, 개인정보 보호

2025.05.19 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_5편_Azure 비용, 구독, 라이선스, SLA

2025.05.20 - [MS Azure, AI] - [AZ-900] 자격증 완벽정리_6편_Azure ID 및 액세스 제어(RBAC, Azure AD)