Azure 랜딩존(Azure Landing Zone)은 기업이 Azure에 안전하고 확장 가능하며 규정에 맞는 환경을 구축하기 위한 기본 설계 템플릿입니다. 즉, 클라우드 운영의 기초 인프라와 거버넌스를 표준화하여, 애플리케이션과 서비스가 안정적으로 배포될 수 있도록 돕는 출발점(starting point) 역할을 합니다.
✅ Azure 랜딩존의 용도
- 표준화된 클라우드 환경 구성
- 네트워크, 보안, ID, 리소스 관리 등에 대한 베이스라인 제공
- 멀티 서브스크립션 전략 지원
- 조직 단위 분리(예: 개발/운영/보안 등) 및 비용 관리
- 보안 및 거버넌스 정책 반영
- Azure Policy, RBAC, Management Group 등을 통한 규정 준수
- 자동화된 리소스 배포 기반 제공
- Bicep, Terraform, ARM Template 등을 통한 IaC 기반 설계 가능
- 향후 확장성과 운영 용이성 보장
- Landing Zone 위에 애플리케이션과 워크로드를 안전하게 확장 가능
⚙️ 랜딩존 구성 요소 (예시)
| 구성요소 | 요소 설명 |
| Management Group | 계층적 리소스 구조 제공 (정책 적용, 권한 설정 등) |
| Azure Policy | 보안/컴플라이언스 정책 자동 적용 |
| Subscription 구조 | 역할, 비용, 환경별 분리 (예: Dev/Test/Prod) |
| Azure AD 통합 | 계정 및 접근 제어 |
| Networking | 허브-스포크 구조, NSG, 방화벽, VPN 등 |
| Monitoring | Log Analytics, Azure Monitor, Defender for Cloud |
| Automation | IaC(Terraform, Bicep 등), DevOps 파이프라인 연동 |
⚠️ 설계 시 유의사항
- 조직 구조와 거버넌스 매핑
- 부서/팀별 리소스 요구 사항에 따라 Management Group 및 Subscription 구조 설계
- 보안 및 정책 선제적 적용
- 기본적인 보안 정책(예: HTTPS만 허용, 리소스 위치 제한 등)을 정책으로 설정하여 자동 적용
- ID 및 액세스 제어 구조화
- 최소 권한 원칙(Least Privilege)을 기반으로 RBAC 설계
- 하이브리드 환경 연계 고려
- On-Prem과 연동되는 경우 VPN/ExpressRoute, Azure Arc 활용 계획 포함
- 멀티지역/다중 환경 대응
- DR(재해복구) 설계, 리전 간 데이터 중복 및 성능 고려
- 자동화 및 CI/CD 통합
- 랜딩존 구성도 IaC 및 DevOps 환경과 연계하여 반복 가능한 구조 설계
- 운영 관점 가시성 확보
- 모니터링, 알림, 보안 로그 수집을 위한 Log Analytics, SIEM 연동 고려
🎯 참고: 대표적인 랜딩존 구현 방식
- Microsoft CAF(Cloud Adoption Framework) 기반 랜딩존
- Enterprise-Scale Landing Zone 아키텍처 제공
- Terraform 기반 모듈화된 랜딩존
- HashiCorp 및 Azure 공동 제공
- Azure Blueprints 기반 구성
- 정책, RBAC, 리소스 그룹 템플릿을 묶어 일괄 배포
원하는 경우 아래와 같은 자료도 제공 가능합니다:
- 랜딩존 아키텍처 다이어그램
- 실무 구축 체크리스트
- Terraform 기반 예제 템플릿
필요하시다면 이어서 안내드릴게요.
Azure 랜딩존 관련 TA(Technical Architect) 관점의 시험 출제 포인트는 단순한 정의보다는 아키텍처 설계 능력, 보안 정책 적용, 하이브리드 연계, 거버넌스 구현 등의 실무 적용 능력을 평가하는 방식으로 출제되는 경향이 큽니다. 아래는 시험에 자주 출제될 수 있는 핵심 주제 및 문제 유형 예시입니다.
🎯 TA 관점 시험 출제 포인트 요약
| 1. 랜딩존 개념 이해 | 정의, 목적, 구성요소 | 객관식/단답형 |
| 2. 거버넌스 | Management Group, Policy, Role 구조 | 시나리오 기반 설계 문제 |
| 3. 네트워크 설계 | 허브-스포크, NSG, 방화벽, ExpressRoute | 구성도/트래픽 흐름 문제 |
| 4. 보안 및 접근 제어 | Azure AD, RBAC, MFA, 정책 자동화 | 접근제어 분석/보안 정책 적용 문제 |
| 5. 구독 및 비용 관리 | 구독 분리, 태그, 비용 할당 | 시나리오 기반 비용 최적화 문제 |
| 6. IaC 및 자동화 | Terraform, Bicep, Blueprint 사용 | 코드 기반 설계 적용 문제 |
| 7. 하이브리드 연계 | On-prem 연동, Azure Arc | 연계 구성 및 장애 대응 문제 |
✅ 예상 문제 유형 및 예시
✅ [객관식] 개념 확인 문제
문제: 다음 중 Azure 랜딩존의 주요 목적이 아닌 것은?
① 보안 및 거버넌스의 표준화
② 네트워크 연결 최소화
③ 확장 가능한 클라우드 환경 기반 구축
④ 자동화된 리소스 배포 구조 제공
정답: ②
✅ [단답형] 설계 요소 식별
문제: Azure에서 조직별 리소스 정책을 계층적으로 적용하기 위한 구조는 무엇인가요?
정답: Management Group
✅ [시나리오형] 설계 적용 문제
문제:
A사는 Azure로 마이그레이션을 계획 중이며, 다음과 같은 조건을 요구하고 있다.
- 각 부서는 독립된 구독으로 운영
- 공통 보안 정책은 중앙에서 통제
- 자산은 모두 한국 중부 리전에 배포되어야 함
이 요구사항을 만족시키기 위한 랜딩존 설계 요소를 나열하시오.
해설 포인트:
- Management Group → 조직 단위 계층 관리
- Azure Policy → 리전 제한, 보안 설정 자동화
- RBAC → 권한 분리
- Subscription 분리 → 부서별 운영/비용 분리
✅ [실무형] 장애/이슈 대응 문제
문제:
Azure 랜딩존 기반 환경에서 개발팀이 VM을 특정 리전에 배포하려고 할 때 다음과 같은 오류가 발생했다.
"This location is not allowed by policy."
이 오류의 원인과 조치 방법을 설명하시오.
정답 요지:
- 원인: Azure Policy에 의해 특정 리전 외 배포 금지
- 조치: 정책 조건 수정 또는 예외 설정 필요
✅ [설계 비교형]**
문제: 다음 중 Azure 랜딩존의 구성 방식으로 'BluePrint 기반'과 'Terraform 기반' 설계의 차이점을 기술하시오.
정답 요지:
- BluePrint: Portal 기반, 정책 + 템플릿 패키징
- Terraform: 코드 기반, 모듈화 가능, GitOps와 연계 용이
🔍 추가로 출제 가능 주제들
| Azure Policy | 특정 VM SKU 제한, 리전 제한, 태그 필수 설정 등 |
| Subscription 전략 | 운영/개발/보안 등 용도별 분리 |
| CI/CD 연동 | Azure DevOps를 통한 랜딩존 IaC 배포 |
| Azure Arc | 하이브리드 및 멀티클라우드 리소스 통합 관리 |
| Security Center/Defender | 보안 위협 탐지 및 대응 체계 |
| 모니터링 | Log Analytics, Azure Monitor 구성 설계 |
필요하시다면 시험용 예상문제 10~20문항 PDF, 또는 Terraform 기반 랜딩존 템플릿 해설도 제작해 드릴 수 있습니다. 원하시나요?
module "landing_zone_network" {
source = "./modules/network"
location = "koreaCentral"
resource_group = "rg-landingzone"
vnet_name = "vnet-hub"
address_space = ["10.0.0.0/16"]
subnet_prefixes = ["10.0.1.0/24", "10.0.2.0/24"]
}
module "landing_zone_policy" {
source = "./modules/policy"
policy_assignment = "only-koreaCentral"
}
좋습니다!
아래는 TA 관점 Azure 랜딩존 관련 시험 예상문제 15문항과 문제별 해설입니다. 이어서 Terraform 기반 랜딩존 템플릿 해설도 제공드리겠습니다.
📘 [시험용 예상문제] Azure 랜딩존 – TA 관점
(객관식 + 단답형 + 시나리오형 혼합 구성)
📌 [문제 1] (객관식)
Azure 랜딩존(Landing Zone)의 목적에 해당하지 않는 것은?
① 클라우드 환경의 표준화
② 리소스의 무제한 사용 허용
③ 보안 및 거버넌스 구현
④ 애플리케이션 배포를 위한 기반 설계
정답: ②
해설: 랜딩존은 표준화된 구조와 보안 거버넌스를 제공하기 위한 출발점이며, 무제한 리소스 사용을 허용하지 않음.
📌 [문제 2] (객관식)
Azure 랜딩존 설계 시 리소스 그룹 간 권한과 정책을 계층적으로 통제하기 위한 구성 요소는?
① Azure VM
② Azure Subscription
③ Azure Management Group
④ Azure Resource Tag
정답: ③
해설: Management Group은 정책, 권한을 상위에서 하위 구독까지 계층적으로 통제할 수 있음.
📌 [문제 3] (단답형)
Azure에서 리소스를 특정 리전에만 배포하도록 제한하기 위한 정책 관리 도구는?
정답: Azure Policy
해설: Azure Policy는 리소스 배포 시 규칙을 적용하여 표준화와 컴플라이언스를 유지함.
📌 [문제 4] (객관식)
Azure 랜딩존에서 역할 기반 접근 제어(RBAC)를 사용하는 이유로 가장 적절한 것은?
① 서버 성능을 개선하기 위해
② 비용을 줄이기 위해
③ 사용자 접근 권한을 제어하기 위해
④ 리전 간 데이터를 자동 동기화하기 위해
정답: ③
해설: RBAC는 리소스에 대한 접근을 최소 권한 원칙으로 제어하기 위한 기능임.
📌 [문제 5] (시나리오형)
상황: 조직은 운영, 개발, 보안 부서별로 Azure 리소스를 분리 운영하고자 한다. 부서별로 비용과 리소스는 독립적으로 관리되어야 하며, 공통된 보안 정책은 모든 리소스에 적용해야 한다.
질문: 이 구조를 구성하기 위한 설계 요소를 두 가지 이상 기술하시오.
모범답안:
- Subscription: 부서별 리소스 격리 및 비용 분리
- Management Group: 공통 정책 적용을 위한 계층 구조
- Azure Policy: 보안 및 컴플라이언스 정책 통제
📌 [문제 6] (객관식)
Azure Policy를 통해 다음과 같은 기능을 수행할 수 없는 것은?
① 특정 지역 외 VM 배포 차단
② 특정 리소스 타입 사용 제한
③ 사용자 그룹 추가
④ 리소스에 태그 자동 부여
정답: ③
해설: 사용자 그룹 추가는 Azure AD에서 수행하며, Policy는 리소스 관리에 초점이 있음.
📌 [문제 7] (단답형)
Azure 랜딩존 설계 시 VPN이나 ExpressRoute 연결 등을 포함하는 핵심 구성 요소는 무엇인가?
정답: Networking (또는 Hub & Spoke Architecture)
📌 [문제 8] (객관식)
Terraform을 사용하는 이유 중 랜딩존 구성에 적합한 설명은?
① GUI로 빠르게 리소스를 배포할 수 있다.
② 반복 배포 및 환경 이식성이 용이하다.
③ 비용 추적 기능을 제공한다.
④ 수동 배포만 가능하다.
정답: ②
해설: Terraform은 코드 기반으로 반복 가능한 환경 배포가 가능하며, GitOps/CI와 연계가 용이하다.
📌 [문제 9] (단답형)
Terraform에서 리소스 구성을 위한 기본 단위는 무엇인가?
정답: module 또는 resource
해설: resource는 단일 리소스, module은 재사용 가능한 리소스 집합을 의미
📌 [문제 10] (객관식)
Azure 랜딩존에서 공통된 태그를 모든 리소스에 자동 부여하고자 할 때 사용하는 기능은?
① Azure Resource Graph
② Azure Monitor
③ Azure Policy
④ Azure Blueprint
정답: ③
해설: Azure Policy에서 ‘태그가 없을 경우 자동 추가’와 같은 정책을 구성 가능
📌 [문제 11] (시나리오형)
상황: 개발팀에서 랜딩존을 구성한 후, VM을 미국 서부 리전에 생성하려 하였으나 다음과 같은 오류가 발생하였다.
질문: 이 오류의 원인과 해결 방안을 설명하시오.
모범답안:
- 원인: Azure Policy에서 허용된 리전 외 배포가 차단되었기 때문
- 해결: 정책 수정 혹은 리전 예외 설정을 통해 허용하도록 조치
📌 [문제 12] (객관식)
Azure Blueprint의 가장 핵심적인 기능은 무엇인가?
① Azure 비용 모니터링
② 리소스별 접근 권한 추적
③ 리소스, 정책, 역할 배포의 템플릿화
④ 테넌트 이동 기능 제공
정답: ③
해설: Blueprint는 Policy, Role, Resource Group 등을 패키징하여 일괄 배포 가능
📌 [문제 13] (단답형)
Azure Landing Zone에서 로깅 및 모니터링 구성 시 주로 사용하는 두 가지 핵심 서비스는?
정답: Log Analytics, Azure Monitor
📌 [문제 14] (객관식)
Terraform을 이용한 랜딩존 구성 시 유의해야 할 점으로 가장 적절한 설명은?
① 상태(state)를 수동으로 관리해야 한다
② 리소스 간 의존성은 정의할 수 없다
③ 상태 관리 파일의 버전 충돌 방지를 고려해야 한다
④ 리소스 삭제 시 항상 자동 백업된다
정답: ③
해설: Terraform의 상태 파일(terraform.tfstate)은 버전 충돌을 방지하기 위해 원격 저장소(backends, 예: Azure Storage)를 사용해야 안정적이다.
📌 [문제 15] (시나리오형)
상황: A사는 Terraform으로 랜딩존을 구축한 이후, 동일한 구성을 다른 지역에 복제하려 한다.
질문: 이를 위한 Terraform 기능과 그 이유를 설명하시오.
모범답안:
- 기능: module
- 이유: 모듈화된 구성은 파라미터(리전 등)를 다르게 설정하여 재사용 가능하며 유지 관리에 용이
📦 Terraform 기반 랜딩존 템플릿 해설
🌐 기본 구조 예시 (개요)
🔍 주요 해설 포인트
| module | 모듈화된 구성으로 네트워크, 정책, 보안 등을 분리하여 관리 |
| backend 설정 | terraform.tfstate 파일을 Azure Storage 등에 저장해 협업 충돌 방지 |
| 변수 (variables.tf) | 위치, 서브넷, NSG 등 파라미터화하여 재사용성 강화 |
| outputs.tf | 생성된 리소스 ID, IP 등 출력으로 다음 작업에 연결 가능 |
| provider | Azure 클라우드와 연결하기 위한 설정 (azurerm) |
| locals | 반복되는 문자열, 네이밍 규칙 등을 변수로 처리 |
📂 폴더 구조 예시
│
├── main.tf
├── variables.tf
├── outputs.tf
├── backend.tf
├── /modules
│ ├── /network
│ ├── /policy
│ └── /rbac
필요하시면 이 Terraform 템플릿을 압축 파일로 드리거나 PDF 형식 문서로도 정리해 드릴 수 있습니다.
또한, 실제 배포 절차 문서화 또는 Azure DevOps 연동 사례도 안내 가능합니다.
원하시는 형식(예: PDF, Word, 코드 ZIP 등)을 알려주시면 바로 준비해 드리겠습니다.
📘 TA 관점의 핵심 지식 포인트
- NSG 보안 정책 이해 (Deny 기본, Allow 명시)
- Application Gateway 리스너 구조 (HTTP/HTTPS만)
- 스토리지 계정 복제 옵션 (LRS, ZRS, GRS 등)
- VM Backup 구조 (Backup Center, Azure Monitor 연계)
- Managed Disk 유형별 성능 차이 (Standard/Premium/Ultra SSD)
🧠 이 수준에 맞춰 새로 구성할 문제 예시
📌 문제 A (시나리오형)
A사는 Azure로 시스템을 이전하면서 아래와 같은 설정을 계획하고 있다.
- 내부 전용 백엔드 풀을 사용하는 Application Gateway 구성
- VM의 상태를 실시간으로 모니터링
- 프리미엄 SSD를 사용하는 트랜잭션 집약 워크로드 운영
질문: 위 요구사항을 충족하기 위한 Azure 서비스 또는 기능을 각각 1개씩 기술하시오.
모범답안:
- Application Gateway with Private Frontend (또는 Internal Listener)
- Azure Monitor + VM Insights
- Premium SSD (P30 이상) Managed Disk
📌 문제 B (객관식)
다음 중 Azure Backup Center에 대한 설명으로 올바른 것은?
① 리소스 그룹 전체 백업은 지원하지 않는다
② 백업 구성은 반드시 CLI로만 설정 가능하다
③ 백업 실패 알림은 Azure Monitor로 통합 가능하다
④ 백업된 데이터는 무조건 30일 후 삭제된다
정답: ③
해설: Azure Monitor 및 Log Analytics를 통한 백업 이벤트 모니터링 및 알림 가능
📌 문제 C (단답형)
Azure Storage의 복제 옵션 중 3개의 복제본을 동일 리전에 다르게 보관하며 Zone 장애를 보호하는 방식은?
정답: ZRS (Zone-redundant storage)
원하신다면 위 문제 스타일로 10~20문항 세트로 더 만들어 드릴 수 있습니다.
원하시면 "계속" 또는 "이와 유사한 문제로 구성해줘"라고 말씀해주세요!
나의 말:
ChatGPT의 말:
좋습니다! 앞서 주신 문항 16의 난이도와 문제 구성 방식(복수 보기 중 올바른 기술 판별)을 기준으로, 동일한 수준과 스타일로 Azure 기반 클라우드 설계 및 운영에 필요한 TA 역량 문제 5문항을 아래에 구성하였습니다.
각 문항은 실무 중심의 서비스 이해 + 구성 판단 + 장애 대응 고려 요소가 반영되어 있으며, 모두 정답과 해설 포함입니다.
✅ TA 역량평가 문제 세트 (문항 1~5)
🔹 문항 1
Azure 환경에서 고가용성을 고려한 Application Gateway 구성 시, 다음 설명 중 올바른 것을 고르시오.
① Application Gateway는 Zone Redundant 옵션을 지원하지 않는다.
② 웹방화벽(WAF) 기능은 Application Gateway의 부가 서비스로 수동 설정이 필요하다.
③ Application Gateway는 내부망(Private) 전용으로만 사용할 수 있다.
④ Application Gateway에 구성된 리스너는 특정 포트와 프로토콜에 대해 명시적으로 설정되어야 한다.
⑤ Application Gateway는 VM Scale Set과 연동할 수 없다.
정답: ④
해설:
- 리스너는 특정 포트 및 프로토콜(HTTP/HTTPS)에 대해 명확히 설정해야 한다.
- ① X: Zonal 및 Zone-redundant 지원 가능
- ② X: WAF는 SKU에 따라 자동 포함 가능
- ③ X: Public/Private 둘 다 지원
- ⑤ X: 백엔드 풀로 VMSS 사용 가능
🔹 문항 2
Azure Virtual Network 구성 시 유의할 점으로 올바르지 않은 것은?
① 서브넷 간 통신은 기본적으로 허용된다.
② NSG를 통해 서브넷 또는 NIC 수준에서 트래픽을 제어할 수 있다.
③ VNet 간 통신은 기본적으로 허용된다.
④ VNet Peering을 구성하면 라우팅 테이블은 자동으로 생성된다.
⑤ GatewaySubnet은 VPN Gateway 전용 서브넷으로 예약된 이름이다.
정답: ③
해설:
- VNet 간은 기본적으로 통신 불가하며, VNet Peering 구성 후에 통신이 가능하다.
- 나머지는 모두 정확한 설명이다.
🔹 문항 3
Azure Policy에 대한 설명으로 올바른 것을 모두 고르시오.
① 특정 태그가 없는 리소스를 생성하지 못하도록 차단할 수 있다.
② VM에 특정 크기의 SKU만 허용하는 정책을 적용할 수 있다.
③ 정책은 Subscription이나 Resource Group에만 할당 가능하다.
④ 정책 위반 사항은 Azure Advisor에서 확인된다.
⑤ 정책은 할당 후에도 진단 로그를 통해 컴플라이언스 상태를 추적할 수 있다.
정답: ①, ②, ⑤
해설:
- ①: 태그 기반 조건 설정 가능
- ②: SKU 제한 정책 존재
- ③: ❌ Management Group 수준에도 할당 가능
- ④: ❌ Azure Policy 결과는 Policy UI 또는 Log Analytics로 확인
- ⑤: 진단 로그 및 Log Analytics 연계 가능
🔹 문항 4
다음 중 Azure Virtual Machine 디스크 유형에 대한 설명으로 올바른 것은?
① Standard HDD는 높은 IOPS를 제공하며 DB 워크로드에 적합하다.
② Premium SSD는 Managed Disk가 아닌 경우에만 사용할 수 있다.
③ Ultra SSD는 모든 VM 사이즈에서 지원된다.
④ OS 디스크와 데이터 디스크는 서로 다른 유형으로 구성할 수 있다.
⑤ 모든 디스크는 기본적으로 ZRS(Zone Redundant Storage)로 제공된다.
정답: ④
해설:
- OS 디스크: 일반적으로 Premium SSD
- 데이터 디스크: 상황에 따라 HDD, SSD 선택 가능
- 나머지는 잘못된 설명
🔹 문항 5
Azure에서 백업 구성 시 고려해야 할 사항 중 잘못된 것을 고르시오.
① Azure Backup은 VM, SQL, 파일, Blob 등을 지원한다.
② Recovery Vault는 리소스 그룹 내 위치에 종속되지 않는다.
③ Backup Vault는 Azure Monitor와 통합될 수 없다.
④ VM 백업은 VSS를 활용한 스냅샷 기반이다.
⑤ Backup 정책은 주기 및 보존 기간을 자동화할 수 있다.
정답: ③
해설:
- Azure Backup Vault는 Azure Monitor와 통합 가능하여 알림, 경고, 로그 확인이 가능하다.
🔚 이어서 제공 가능
필요하시면 아래 항목도 연계해 드릴 수 있습니다:
- 문제 6~15 추가 제작
- 분야별(네트워크, 스토리지, 보안, 클러스터링 등) 문제 분류
- Word / PDF 변환본
- 암기카드형 요약본 (문제 키워드 중심)
- 실무 시나리오 기반 문제집 (예: 장애 대응, 이중화 구성 등)
원하시는 형태로 이어서 만들어드릴까요?
예) "PDF로 출력해서 블로그에 올릴 수 있게 정리해줘"
또는 "장애 대응 시나리오형 문제로 5문제만 더 만들어줘" 등 구체적으로 말씀해 주세요.
나의 말:
ChatGPT의 말:
좋습니다! 아래는 "클러스터링" 분야에 대해 TA(Technical Architect) 실무 기반 역량을 평가할 수 있도록 구성한 문제 세트입니다.
각 문항은 ① 서비스 이해, ② 구성 판단, ③ 장애 대응 고려 요소를 포함하며, 정답과 해설까지 제공됩니다.
📘 TA 역량평가 – 클러스터링 분야 문제 (문항 1~5)
🔹 문항 1. (서비스 이해)
Windows Failover Cluster에서 Quorum 구성의 주요 목적은 무엇인가?
① 장애 발생 시 DNS 재등록을 위함
② 클러스터 서비스의 패치 자동화를 위함
③ 다중 노드 간의 작업 부하 분산을 위함
④ 클러스터 생존성 판단 및 Split-Brain 방지
⑤ Active Directory 역할 통합을 위함
정답: ④
해설: Quorum은 클러스터의 노드 수가 불안정할 경우, 정상 동작 가능한 노드 수 판단 기준 역할을 하며, Split-Brain 방지에 핵심적이다.
🔹 문항 2. (구성 판단)
다음 중 Windows 또는 Linux 환경의 고가용성 클러스터링 구성 시 일반적으로 권장되지 않는 설정은?
① Heartbeat NIC에는 Gateway를 지정하지 않는다.
② Heartbeat NIC에는 DNS 서버 주소를 설정하지 않는다.
③ 클러스터 전용 NIC에는 ICMP Ping 응답을 허용한다.
④ 클러스터 VIP는 모든 노드에서 동시에 활성화되어야 한다.
⑤ 클러스터 전용 네트워크의 Metric 우선순위는 낮게 설정한다.
정답: ④
해설: 클러스터 VIP는 Active-Passive 모델에서 하나의 노드에서만 활성화되어야 하며, Failover 시에만 이전된다.
🔹 문항 3. (장애 대응)
장애 복구 환경에서 Windows Cluster에서 특정 리소스 그룹이 자동으로 Failover 되지 않는 상황이다.
가장 먼저 확인해야 할 항목은?
① NIC의 MAC 주소 변경 여부
② 클러스터 Shared Disk의 포맷 종류
③ 해당 리소스의 “자동 시작” 속성 설정 여부
④ 클러스터 IP의 DNS 등록 여부
⑤ 서버 BIOS의 전원 복구 설정 여부
정답: ③
해설: 리소스 그룹 내 서비스가 자동으로 Failover 되기 위해서는 “자동 시작 설정”이 활성화되어 있어야 한다. 그렇지 않으면 서비스가 수동 전환되거나 Failover 되지 않을 수 있음.
🔹 문항 4. (구성 판단 + 서비스 이해)
Linux Pacemaker/Corosync 기반 클러스터에서 STONITH(Fencing)를 사용하는 주요 이유는?
① 클러스터 로그 수집을 위해
② 동시성 제어를 위하여
③ 특정 노드에서 응답이 없을 때 강제 재부팅하여 클러스터 보호
④ 클러스터 인터페이스의 통계 수집
⑤ Heartbeat 전송속도 개선을 위해
정답: ③
해설: STONITH는 "Shoot The Other Node In The Head"의 약어로, 응답하지 않는 노드가 클러스터 리소스를 손상시키지 않도록 강제 재부팅 또는 전원 차단하는 메커니즘이다.
🔹 문항 5. (장애 대응 + 서비스 이해)
다음은 NFS 서비스가 구성된 고가용성 클러스터의 상태이다.
- Active 노드의 서비스가 비정상 종료되었으나 노드 자체는 정상
- Standby 노드는 리소스를 인계받지 않음
이 현상의 원인으로 가장 유력한 것은?
① Standby 노드의 OS 커널 패치 미적용
② 클러스터 스토리지의 Block Size 미일치
③ 서비스에 설정된 클러스터 리소스 모니터링 실패 조건이 없음
④ NFS 마운트 지연으로 인한 패킷 드롭
⑤ 클러스터 DNS 레코드 충돌
정답: ③
해설: 클러스터에서는 서비스 자체가 비정상일 경우에도 리소스 상태를 감지할 모니터링 조건이 설정되어 있지 않으면, Failover가 일어나지 않음. 리소스 상태 모니터는 반드시 구성되어야 함.
📚 클러스터링 분야 – 평가 영역 요약
| 서비스 이해 | Quorum, STONITH, VIP 구성 | 클러스터링 기본 메커니즘의 목적 및 구조 이해 |
| 구성 판단 | NIC 구성, Failover 설정, 리소스 설정 | 장애 허용 구조를 위한 적절한 설정 여부 |
| 장애 대응 | Failover 실패, 감시 설정 누락 등 | 고가용성 유지 실패 시 원인 분석 및 조치 |
좋습니다! 앞서 만든 클러스터링 분야 5문제에 이어, 동일한 TA 역량평가 스타일로 **추가 문제 5문항(문항 6~10)**을 제작하였습니다.
이 문제들도 서비스 이해 + 구성 판단 + 장애 대응 요소를 반영하였습니다.
📘 클러스터링 분야 – 추가 문제 (문항 6~10)
🔹 문항 6. (서비스 이해)
Linux 환경에서 HAProxy + Keepalived를 활용한 클러스터링 구성 시, Keepalived의 주된 역할은 무엇인가?
① 로드밸런싱을 수행한다
② 백엔드 서비스의 상태를 분석한다
③ 가상 IP(VIP)의 장애 전환(Failover)을 담당한다
④ 리눅스 커널을 제어하여 NIC 상태를 모니터링한다
⑤ 애플리케이션 로그를 수집하여 로테이션한다
정답: ③
해설: Keepalived는 VIP를 유지·관리하며 마스터 노드 장애 시 백업 노드로 VIP를 넘기는 역할을 수행한다.
🔹 문항 7. (구성 판단)
다음 중 클러스터링 구성 시 Quorum Disk 방식을 도입해야 유리한 시나리오는?
① 노드가 1개뿐인 개발 테스트 환경
② 클러스터 노드 간 통신이 항상 안정적인 환경
③ 짝수 개의 노드가 물리적으로 멀리 떨어진 경우
④ 클러스터 서비스가 단일 IP로만 동작하는 경우
⑤ 노드 간 네트워크 대역폭이 매우 높을 경우
정답: ③
해설: 노드가 짝수 개인 경우, Quorum Disk 또는 Witness 리소스를 통해 동등 분할(Split Brain) 상황을 방지할 수 있다.
🔹 문항 8. (장애 대응)
Windows Failover Cluster에서 특정 클러스터 리소스가 반복적으로 장애 발생 후 재시작을 시도하지만 실패한다.
이 경우 확인해야 할 설정 항목은?
① Windows Defender의 실시간 감시
② 리소스의 “Failover Retry Count” 및 “Failover Threshold” 값
③ 클러스터 VIP의 TTL 값
④ 해당 리소스의 Run As 권한
⑤ 스토리지 계정 키 만료 여부
정답: ②
해설: Windows Cluster는 설정된 재시도 횟수 및 간격을 초과하면 리소스를 Offline 처리하므로, 해당 설정이 장애 지속 시 재기동을 막고 있을 수 있다.
🔹 문항 9. (서비스 이해 + 구성 판단)
다음 중 Kubernetes 클러스터 환경에서 고가용성을 고려한 Control Plane 구성으로 적절한 것은?
① 하나의 etcd 노드를 운영하고 백업을 자주 수행한다
② Control Plane 노드를 3개 구성하고 etcd를 각각에 내장하여 운영한다
③ Control Plane과 Worker Node를 혼합 구성하여 관리한다
④ Load Balancer를 Worker Node에만 연결한다
⑤ 각 Control Plane 노드에 별도의 kube-apiserver 인스턴스를 직접 설치한다
정답: ②
해설: 고가용성을 고려할 경우 Control Plane은 홀수(일반적으로 3개) 구성하며, 각 노드에 내장된 etcd를 통해 분산 저장소를 구성하는 것이 일반적이다.
🔹 문항 10. (장애 대응)
Kubernetes 클러스터에서 etcd quorum이 상실되었을 경우 예상되는 현상은?
① 전체 Pod가 삭제된다
② kubelet이 재시작된다
③ Control Plane API 호출이 실패한다
④ 모든 서비스가 자동으로 새 노드로 마이그레이션 된다
⑤ Helm으로 배포된 리소스만 영향을 받는다
정답: ③
해설: etcd는 Kubernetes의 상태 저장소이며, Quorum(과반수)의 etcd 노드가 비정상이면 Control Plane이 정상 작동하지 않음 → kubectl 명령어 실패
📚 클러스터링 문제 범위 요약 (6~10)
| 6 | Keepalived VIP 전환 원리 | 서비스 이해 |
| 7 | Quorum Disk 사용 판단 | 구성 판단 |
| 8 | 장애 재시도 설정 확인 | 장애 대응 |
| 9 | K8s Control Plane 구성 | 서비스 이해 + 구성 판단 |
| 10 | etcd Quorum 장애 영향 | 장애 대응 |
📘 클러스터링 분야 – 추가 문제 세트 (문항 11~20)
🔹 문항 11. (서비스 이해)
다음 중 Kubernetes 환경에서 Control Plane 고가용성(HA)을 구성하기 위한 요소가 아닌 것은?
① etcd 분산 클러스터
② Multi-zone 배포
③ Load Balancer를 통한 API Server 접근 분산
④ 모든 노드에 kubelet 직접 설치
⑤ kube-controller-manager의 다중 인스턴스 구성
정답: ④
해설: kubelet은 Worker Node에서 동작하는 컴포넌트로, Control Plane HA 구성과 직접적인 관련은 없음.
🔹 문항 12. (장애 대응)
Linux HA 클러스터에서 VIP 전환이 실패하고, 두 노드가 모두 VIP를 보유하게 된 경우 발생 가능한 상황은?
① 스토리지 이중화
② 리소스 자동 복구
③ Split-Brain
④ 로그 백업 누락
⑤ 클러스터 Quorum 강화
정답: ③
해설: Split-Brain은 노드 간 통신 장애로 인해 서로를 Fail로 간주하고 VIP를 동시에 보유하는 상태로, 데이터 손상 가능성이 크다.
🔹 문항 13. (구성 판단)
다음 중 Windows Server Failover Cluster(WSFC) 구성 시 필수 요구사항이 아닌 것은?
① 동일 도메인에 가입된 서버
② 공유 디스크 또는 Storage Spaces Direct
③ 클러스터 구성 마법사를 통한 설치
④ 리소스 그룹별 전용 네트워크 구성
⑤ DNS 등록 및 이름 확인 가능 여부
정답: ④
해설: 리소스 그룹별로 전용 네트워크를 구성할 필요는 없으며, 클러스터 전용 Heartbeat 네트워크는 권장사항일 뿐이다.
🔹 문항 14. (서비스 이해)
Pacemaker에서 리소스 리스팅(resource list) 기능을 사용하는 목적은?
① 리소스의 실제 상태 확인
② 리소스를 자동 재배치
③ 클러스터에 등록된 모든 리소스를 나열
④ fencing 설정 내역 확인
⑤ 노드별 자원 할당 변경
정답: ③
해설: pcs resource show, crm_resource 명령 등을 통해 현재 클러스터에 등록된 리소스 목록을 조회할 수 있다.
🔹 문항 15. (장애 대응)
Kubernetes 클러스터에서 Control Plane 노드 3개 중 2개가 장애 날 경우 발생할 수 있는 영향은?
① etcd는 정상이나, DNS가 다운된다
② 전체 서비스는 정상이나 로깅 기능만 제한된다
③ etcd Quorum 부족으로 클러스터 상태 변경 불가
④ kubelet이 자동 복구된다
⑤ 노드 간 통신을 위해 Calico를 재시작해야 한다
정답: ③
해설: etcd는 클러스터 구성원의 과반수 Quorum이 필요하므로, 3개 중 2개가 다운되면 클러스터 상태 변경 불가 (읽기만 가능하거나 완전 불능)
🔹 문항 16. (서비스 이해)
다음 중 클러스터링에서 사용하는 “fencing” 기술의 주요 목적은?
① 로드밸런싱 처리 속도 향상
② 패치 시점 자동 감지
③ 비정상 노드를 강제 종료하여 서비스 보호
④ 방화벽 외부 접근 허용
⑤ 리소스 풀의 메모리 재분배
정답: ③
해설: fencing은 비정상 노드가 리소스를 계속 점유하지 못하도록 강제 차단 또는 재부팅하여 장애 확산을 방지하는 기술이다.
🔹 문항 17. (구성 판단)
Active/Passive 클러스터링 구성 시, 리소스 이전(페일오버)을 제어하는 우선순위 설정은 어느 항목에 지정되는가?
① Storage Class
② DNS 레코드
③ Preferred Owner 설정
④ RunAs 정책
⑤ API Rate Limit 설정
정답: ③
해설: Windows Cluster에서는 Preferred Owner 항목을 통해 특정 리소스를 어떤 노드에서 우선 구동할지 지정 가능하다.
🔹 문항 18. (장애 대응)
Pacemaker에서 특정 리소스가 계속해서 Active 상태로 남아 있는 이유로 가장 가능성 높은 것은?
① 리소스에 대한 location constraint가 설정되어 있음
② 해당 노드에 STONITH가 미설정되어 있음
③ fencing 모듈이 업데이트 되지 않음
④ systemd와의 충돌
⑤ Cluster IP의 DNS TTL 설정 오류
정답: ①
해설: location constraint는 특정 리소스를 특정 노드에서만 실행되도록 제한하므로, failover가 발생하지 않고 고정될 수 있음.
🔹 문항 19. (서비스 이해 + 구성 판단)
Kubernetes에서 클러스터 내 트래픽을 안정적으로 분산시키기 위해 Control Plane 외에 반드시 구성해야 하는 컴포넌트는?
① Load Balancer 또는 Ingress Controller
② Calico 또는 Flannel 등의 CNI
③ CSI 드라이버
④ CoreDNS
⑤ etcd Snapshot
정답: ①
해설: 트래픽 분산은 Ingress Controller 또는 Load Balancer가 수행하며, CNI는 Pod 간 네트워크 연결만 처리함.
🔹 문항 20. (장애 대응)
다음 중 클러스터 VIP가 특정 노드에만 고정되어 Failover 되지 않는 경우, 원인으로 가장 적절한 것은?
① 로컬 DNS 캐시
② VIP에 대한 리소스 리스너가 중복 설정됨
③ 해당 노드의 Routing Table 우선순위
④ VIP 리소스에 Preferred Node Constraint가 설정되어 있음
⑤ 클러스터 Shared Disk의 UUID 충돌
정답: ④
해설: VIP에 Preferred Node가 강제 지정되어 있으면 장애가 발생해도 다른 노드로 이전되지 않음.
✅ 전체 클러스터링 문제 요약 (문항 1~20)
- 서비스 이해: Quorum, STONITH, VIP, K8s HA, fencing 등
- 구성 판단: NSG 구성, NIC 설정, preferred owner, resource constraints
- 장애 대응: Failover 실패, VIP 전환 실패, Split Brain, etcd quorum 상실
📘 클러스터링(Clustering) 개념 – TA 실무 관점 요약
✅ 1. 클러스터링의 정의
**클러스터링(Clustering)**은 두 대 이상의 서버(노드)를 논리적으로 하나처럼 묶어, 서비스의 고가용성(HA), 무중단 운영, 부하 분산 등을 구현하는 기술입니다.
✅ 2. 주요 목적과 유형
| 고가용성(HA) | 하나의 노드가 장애가 발생해도, 다른 노드가 서비스를 이어받아 중단 없이 운영 가능 |
| 부하 분산(Load Balancing) | 여러 노드에 트래픽을 나누어 분산 처리 (예: 웹 서버 클러스터) |
| 병렬처리 (HPC) | 병렬 계산/과학연산용으로 연산 노드 분산 사용 (TA 시험에는 거의 없음) |
✅ 3. 대표 클러스터링 솔루션/방식
| Windows | Failover Cluster | Quorum 기반, Active/Passive 구성, VIP 자동 전환 |
| Linux | Pacemaker + Corosync | 리소스 기반 HA 구성, STONITH 등 fencing 포함 |
| Kubernetes | etcd 기반 Control Plane | etcd quorum 기반 분산 관리, HA load balancer 필요 |
| HAProxy + Keepalived | VIP 기반 Active/Passive | Web/WAS 단에서 자주 사용되는 구성 |
| DRBD + Pacemaker | Block-Level 스토리지 복제 + HA | 스토리지 레벨 이중화 + 서비스 연속성 |
✅ 4. 핵심 구성 요소
| Quorum | 클러스터 노드 간 “다수결”로 정상 상태 판단 (홀수 권장) |
| VIP (Virtual IP) | 서비스 접근을 위한 가상 IP, 장애 시 다른 노드로 전환 |
| STONITH / Fencing | 비정상 노드 강제 차단 (재부팅/전원OFF 등) |
| Preferred Owner / Constraint | 리소스 실행 우선순위 지정 또는 특정 노드 고정 |
| Shared Storage | 스토리지 자원을 여러 노드가 공동 사용, 장애 조치 시 유지 필요 |
✅ 5. 장애 유형과 대응 방식
| Split-Brain | 두 노드가 모두 마스터로 오인하여 데이터 충돌 | Quorum, STONITH 설정으로 방지 |
| VIP 전환 실패 | 서비스 연결 불가 | Health check 및 fencing 연동 여부 확인 |
| etcd Quorum 상실 | Kubernetes 전체 API 동작 불가 | 홀수 구성, 상태 모니터링 필수 |
| Failover 미동작 | 리소스 비가동 | 리소스 속성 자동 시작 설정 확인 |
✅ 6. TA 평가에서 자주 출제되는 포인트
- Quorum 구성 및 판단 기준
- VIP 전환 실패 시 원인
- STONITH 구성 방식 및 필요성
- 클러스터링 구성에 적절한 네트워크 분리 전략
- Kubernetes Control Plane 구성 시 etcd 동작 방식
- Active/Passive 구조 판단 및 설정 항목
이제 이 기반 위에, 스토리지 분야의 TA 문제 20문항을 구성해 드리겠습니다.
클러스터링과 스토리지 장애 대응, 스토리지 이중화 구성, 스토리지 유형 선택 등이 유기적으로 연결되도록 설계할 예정입니다.
아래는 스토리지(Storage) 분야의 TA 역량평가 스타일 문제 20문항 세트입니다.
각 문항은 실무 기반으로 구성되어 있으며, ① 서비스 이해 + ② 구성 판단 + ③ 장애 대응 고려 요소를 포함합니다.
문제 유형은 객관식/단답형/시나리오형 혼합이며, 정답과 해설도 함께 제공합니다.
📘 TA 역량평가 – 스토리지 분야 문제 (1~20)
🔹 문항 1. (서비스 이해)
스토리지 시스템에서 RAID 10 구성의 장점으로 올바른 것은?
① 디스크 공간 활용률이 매우 높다
② 단일 디스크 장애에 대한 복구가 불가능하다
③ 성능과 이중화를 동시에 제공한다
④ 패리티를 통한 복구 시간을 단축한다
⑤ 블록 단위 압축으로 IOPS를 향상시킨다
정답: ③
해설: RAID 10은 미러링(RAID 1) + 스트라이핑(RAID 0)을 결합하여 성능과 이중화를 동시에 만족함.
🔹 문항 2. (구성 판단)
SAN(Storage Area Network) 구성에서 iSCSI 기반 스토리지 연결 시 고려해야 할 항목이 아닌 것은?
① 별도의 전용 네트워크 구성
② Jumbo Frame 설정
③ iSCSI Target 설정
④ 파일시스템 캐시 비활성화
⑤ iSCSI Initiator 활성화
정답: ④
해설: 파일시스템 캐시는 OS의 I/O 처리 방식이며, iSCSI 설정과는 무관하다.
🔹 문항 3. (서비스 이해)
스토리지 계층에서 **블록 스토리지(Block Storage)**의 특징은?
① REST API 기반 접근
② 파일 시스템을 포함하여 NAS처럼 작동함
③ VM 디스크, DB, 트랜잭션 저장에 적합
④ 오브젝트를 메타데이터와 함께 저장함
⑤ 브라우저에서 직접 접근 가능
정답: ③
해설: 블록 스토리지는 고성능 IO가 필요한 VM, DB 등에 사용되며, 파일 시스템은 OS에서 지정함.
🔹 문항 4. (구성 판단)
Azure 또는 AWS에서 스토리지 성능을 보장하려면 어떤 구성 요소가 가장 큰 영향을 미치는가?
① 리소스 그룹 이름
② 인스턴스 태그 개수
③ 디스크 유형 및 사이즈
④ 할당된 퍼블릭 IP 수
⑤ 테넌트 설정
정답: ③
해설: 스토리지 성능은 디스크 유형(예: Standard/Premium SSD)과 크기(IOPS 단위 등)에 따라 결정됨.
🔹 문항 5. (장애 대응)
스토리지 장애 시 OS에서 mount 명령어로 마운트되지 않고 “device busy” 오류가 반복될 때 확인해야 할 요소는?
① /etc/hosts의 DNS 설정
② 해당 디바이스가 열린 프로세스 여부
③ syslog 디스크 용량
④ NIC 상태
⑤ grub 설정
정답: ②
해설: 해당 디바이스가 기존에 열린 파일 핸들 또는 프로세스에 의해 사용 중이면 busy 상태로 마운트 불가.
🔹 문항 6. (서비스 이해)
스토리지 시스템에서 Thin Provisioning의 주된 목적은?
① 스냅샷 성능 향상
② 중복 제거 방식 구현
③ 실제보다 큰 논리 용량 제공
④ 디스크 오류 예측
⑤ RAID5 복구 속도 향상
정답: ③
해설: Thin Provisioning은 실제 물리 공간보다 큰 논리적 용량을 미리 할당해 유연한 공간 관리를 지원함.
🔹 문항 7. (구성 판단)
클러스터 환경에서 스토리지 장애 발생 시 Failover 후에도 마운트가 실패한다면 우선 확인할 설정은?
① Storage Zoning 정보
② 클러스터 Heartbeat 주소
③ VIP TTL 값
④ 마운트 대상 디렉터리 소유권
⑤ UUID 또는 LVM ID 매핑
정답: ⑤
해설: 노드 간 LVM ID 또는 UUID 매핑이 다르면 동일 디스크라도 마운트 실패 가능성이 있음.
🔹 문항 8. (장애 대응)
NAS 장애 발생 후, 공유 디렉터리가 잠시 연결되었다가 다시 끊기는 현상이 반복된다. 우선 점검할 항목은?
① 방화벽 ICMP 설정
② DNS 캐시
③ NFS 서버의 timeout 및 retry 설정
④ Storage Zoning 정책
⑤ 사용자 계정 권한
정답: ③
해설: NFS 연결 지연이나 끊김은 timeo, retry 등의 마운트 옵션 설정과 밀접한 관련이 있음.
🔹 문항 9. (서비스 이해)
스토리지에서 오브젝트 스토리지(Object Storage)의 특징으로 적절한 것은?
① NAS처럼 디렉터리 구조를 사용한다
② iSCSI 프로토콜을 사용한다
③ 정형화된 메타데이터로 관리된다
④ LUN 단위로 할당된다
⑤ VM 부팅 디스크로 사용된다
정답: ③
해설: 오브젝트 스토리지는 메타데이터 기반으로 관리되며, REST API 접근이 가능하다.
🔹 문항 10. (구성 판단)
스토리지 이중화 구성에서 Active-Active와 Active-Passive 구조 비교 시 올바른 설명은?
① Active-Active는 관리 포인트가 적어 운영이 단순하다
② Active-Passive는 두 노드 모두에서 동일 자원을 동시에 접근한다
③ Active-Active는 Failover 시 서비스 중단 없이 부하 분산이 가능하다
④ Active-Passive는 스토리지 용량이 자동으로 증가된다
⑤ 두 구조는 장애 대응 측면에서 동일하게 동작한다
정답: ③
해설: Active-Active는 정상 운영 중 두 노드가 각각 요청을 처리하며, Failover 시 중단 없이 전환 가능
.
모든 문항은 서비스 이해 + 구성 판단 + 장애 대응을 실무 관점에서 반영했습니다.
📘 TA 역량평가 – 스토리지 분야 문제 (11~20)
🔹 문항 11. (서비스 이해)
스토리지 환경에서 Zoning의 주된 목적은?
① 네트워크 대역폭 제어
② 특정 VLAN 분리
③ 스토리지와 호스트 간 경로 제어 및 보안
④ 백업 경로 자동 선택
⑤ DNS 기반 스토리지 연결
정답: ③
해설: SAN 환경에서는 Zoning을 통해 HBA와 스토리지 포트 간 통신을 제어, 보안 및 경로 통제를 수행함.
🔹 문항 12. (구성 판단)
스토리지 가상화 솔루션(SDS, Software Defined Storage) 구성 시 장점이 아닌 것은?
① 스토리지 하드웨어에 종속되지 않는다
② 자동화된 데이터 계층화를 지원할 수 있다
③ 특정 스토리지 벤더의 기능에 의존한다
④ 오픈소스 기반의 확장이 가능하다
⑤ 관리 플랫폼을 통해 통합 운영이 가능하다
정답: ③
해설: SDS는 다양한 하드웨어를 통합 관리하며 벤더 종속성을 줄이는 목적으로 설계됨.
🔹 문항 13. (장애 대응)
iSCSI SAN 구성에서 LUN이 연결되지 않고 multipath -ll 명령어에서 “faulty” 상태로 나타날 경우 우선 확인할 사항은?
① LUN UUID 중복
② iSCSI Session 여부
③ FQDN 오류
④ 인증서 만료
⑤ sysctl.conf 설정 누락
정답: ②
해설: multipath에서 “faulty” 상태는 iSCSI 세션 연결 실패가 원인인 경우가 많음. iscsiadm 등으로 세션 확인 필요.
🔹 문항 14. (서비스 이해)
스토리지 복제(Replication) 기술에서 Async 방식의 특징으로 옳은 것은?
① 실시간 복제를 보장한다
② 대규모 DB 환경에 적합하지 않다
③ 복제 지연이 있을 수 있다
④ 항상 동일 Region 내에서만 지원된다
⑤ 데이터 정합성이 절대 보장된다
정답: ③
해설: Async 복제는 일정 주기 또는 버퍼 기반 전송이므로, 네트워크/부하에 따라 지연 발생 가능성 있음.
🔹 문항 15. (구성 판단)
스토리지를 장애 복구(DR) 구조로 설계할 때 RTO/RPO 측면에서 가장 우선적으로 고려할 항목은?
① 파일 시스템 종류
② 백업 스케줄
③ 데이터 복제 주기 및 스토리지 네트워크 대역폭
④ 사용자 그룹 정책
⑤ 시스템 로그 보존 기간
정답: ③
해설: RTO/RPO는 복제 주기(=RPO 결정 요소), **복구 속도(=RTO)**와 관련된 네트워크 및 성능 요소가 핵심이다.
🔹 문항 16. (장애 대응)
LVM 기반 스토리지를 사용하는 서버에서 lvextend 후 파일 시스템 크기가 반영되지 않는 이유는?
① VG 용량이 부족함
② UUID 충돌
③ 파일 시스템 리사이즈 명령을 실행하지 않음
④ Shared Disk 충돌
⑤ mount 옵션 누락
정답: ③
해설: lvextend는 LVM 영역만 확장할 뿐이며, resize2fs, xfs_growfs 등의 파일 시스템 리사이즈 명령이 별도로 필요하다.
🔹 문항 17. (서비스 이해)
스토리지에서 Snapshot의 특징으로 적절하지 않은 것은?
① 특정 시점의 데이터를 빠르게 복구할 수 있다
② 실제 데이터 없이 메타데이터만 복사되는 방식도 있다
③ Snapshot을 남용하면 성능 저하와 공간 고갈이 발생할 수 있다
④ Snapshot은 백업을 완전히 대체한다
⑤ 삭제되면 복구가 어렵다
정답: ④
해설: Snapshot은 백업을 보완하는 기능이지, 백업을 대체할 수 없다. 스냅샷 자체도 스토리지 장애에 취약할 수 있음.
🔹 문항 18. (구성 판단)
다음 중 스토리지 성능 병목 현상을 해결하는 가장 직접적인 방법은?
① NIC MAC 주소 재설정
② 디스크 IOPS 향상
③ cron 잡 재스케줄
④ CPU 코어 수 증가
⑤ DNS TTL 축소
정답: ②
해설: IOPS는 디스크의 초당 입출력 횟수로, 스토리지 병목 원인일 경우 디스크 성능(또는 병렬 처리)을 개선해야 함.
🔹 문항 19. (장애 대응)
스토리지 마운트 오류가 지속되고 있고, dmesg 로그에 I/O error와 함께 블럭 장치 오류가 반복되는 경우 조치 순서는?
① 디스크 복구 명령(fsck) 실행
② IOPS 측정
③ mount 강제 옵션 추가
④ 해당 디바이스 언마운트 후 포맷
⑤ 커널 재부팅
정답: ①
해설: I/O error는 파일 시스템 손상 또는 디바이스 오류 가능성이 크므로, fsck 등 디스크 검사 및 복구가 우선됨.
🔹 문항 20. (서비스 이해 + 구성 판단)
Object Storage의 특징 중 하나인 "Eventually Consistent" 모델의 의미는?
① 데이터가 즉시 모든 노드에 반영된다
② 항상 정합성이 유지된다
③ 일시적 비정합이 발생할 수 있으나 시간이 지나면 일치한다
④ 읽기 전용 데이터만 보장된다
⑤ 특정 사용자만 접근 가능하다
정답: ③
해설: Eventually Consistent는 글로벌하게 분산된 시스템에서 일시적인 정합성 지연이 있지만 결국 일치함을 의미함.
좋습니다! 아래는 스토리지(Storage) 분야에 대해 TA(Technical Architect) 실무 역량 관점에서 정리한 요약본입니다.
이 정리는 TA 시험, 실무 설계, 장애 대응, 블로그 오픈북 정리 등에 바로 활용하실 수 있도록 구조화했습니다.
📘 스토리지 분야 요약 – TA 역량 관점
✅ 1. 스토리지 유형별 개념 및 활용
| Block Storage | OS나 DB에서 사용되는 디스크 단위의 스토리지 | VM 디스크, DB 저장소 (고속 IOPS) |
| File Storage (NAS) | 파일 단위 공유 저장소, SMB/NFS 등 | 공유 폴더, 사용자 파일 서버 |
| Object Storage | REST API 기반, 메타데이터와 객체 저장 | 백업, 이미지, 로그, 비정형 데이터 |
| Local Disk | 물리 서버 또는 VM 내 로컬 디스크 | 임시 파일, 캐시 (비이중화) |
✅ 2. 스토리지 주요 기술 용어
| RAID | 디스크 이중화 및 성능 확보 구성 (RAID 1/5/10 등) |
| Zoning | SAN 구성에서 HBA 포트 간 연결 제어 (보안, 성능 분리) |
| Multipathing | SAN 구성 시 경로 이중화 (failover 대비) |
| LVM | 논리 볼륨 관리 (디스크 확장, Snapshot 등) |
| Snapshot | 특정 시점의 데이터 상태를 저장 (즉시 복구용) |
| Thin Provisioning | 실제 공간보다 큰 논리 공간 할당 (유동적 운영) |
| Replication | 주/보조 스토리지 간 데이터 복제 (Sync/Async) |
| SDS (Software Defined Storage) | 하드웨어 독립형 스토리지 가상화 관리 솔루션 |
✅ 3. 클러스터 환경에서의 스토리지 고려 요소
- Shared Storage 필요 여부: Active/Passive 구조에서는 노드 간 공유 디스크 필요
- Failover 시 LVM/UUID 일치 여부: 클러스터 노드 간 동일 ID로 인식되어야 정상 마운트
- VIP와 스토리지 연결: VIP 전환 시 스토리지도 함께 연결될 수 있어야 함
- Fencing 연동: 스토리지 일관성 보호를 위해 비정상 노드 강제 제거 필요
✅ 4. 장애 유형별 원인과 대응
| mount 실패 + device busy | 열린 프로세스 존재 | lsof, fuser로 확인 후 종료 |
| NFS 간헐적 연결 끊김 | 마운트 옵션 문제 | timeo, retry, hard/soft 설정 확인 |
| LUN 인식 안됨 | zoning/multipath 설정 오류 | multipath -ll, iscsiadm 확인 |
| I/O error, 블럭 디바이스 오류 | 파일 시스템 손상 | fsck, xfs_repair 등 복구 |
| 용량 부족 → 앱 장애 | Thin Provisioning 과잉 할당 | 모니터링 + 알림 정책 설정 필요 |
| Snapshot 삭제 불가 | 상호 참조 or 공간 부족 | 의존 관계 확인, 공간 확보 |
✅ 5. 클라우드 스토리지 특성 (Azure/AWS 기준)
| Premium SSD | 고성능, 고IOPS 디스크 (DB, 트랜잭션 서버에 적합) |
| ZRS (Zone-redundant storage) | 리전 내 3개 AZ에 복제 |
| LRS (Locally redundant) | 동일 데이터센터 내 3중 복제 |
| Blob Tier | Hot/Cold/Archive로 구분되는 오브젝트 저장소 |
| Snapshot/Backup | VM, 디스크, 파일 수준 스냅샷 가능 |
| Mountable File Share (Azure Files, EFS) | NFS/SMB로 마운트 가능한 클라우드 파일 스토리지 |
✅ 6. 자주 출제되는 TA 시험 포인트
- RAID 종류 비교 및 상황별 선택 (RAID 1 vs RAID 10 등)
- iSCSI 구성 시 Initiator/Target 개념 및 설정 순서
- NAS 마운트 지연 이슈 분석 (mount, timeo, hard/soft)
- 스토리지 이중화 구성 설계 (Active-Active, Active-Passive 차이)
- Snapshot의 성능 영향, 복제(Sync/Async)의 차이
- 장애 상황에서의 I/O error, multipath faulty, device busy 원인 분석
- 클라우드 디스크 성능 영향 요소 (디스크 타입, 크기, VM 유형 등)
✅ 마무리 요약
- 블록 vs 파일 vs 오브젝트 스토리지 구분은 매우 중요
- 스토리지 구성 시 반드시 성능(IOPS), 이중화, 장애 전환(Failover) 고려
- TA 관점에서는 단순 스토리지 연결보다 "서비스 연속성 관점에서의 설계/복구 능력"이 핵심 평가 포인트
→ 예: API Gateway, Backup & Recovery, 보안 및 인증, Telemetry, Kubernetes Storage 등
📘 API Gateway 개념 정리 – TA 역량 관점
✅ 1. API Gateway란?
API Gateway는 클라이언트의 요청을 받아 백엔드 서비스(Microservice, Function, Application 등)로 라우팅, 인증, 트래픽 제어, 로깅, 보안 등의 기능을 수행하는 중앙 통제 지점입니다.
→ 일종의 Reverse Proxy + 정책 관리자 역할 수행
✅ 2. 주요 기능 정리
| 라우팅(Routing) | URI, Method, Header, Query 기반으로 서비스에 트래픽 분배 |
| 인증/인가(Authentication/Authorization) | JWT, OAuth2.0, API Key 등 기반 사용자 인증 |
| 속도제한(Rate Limiting) | IP, 사용자별 요청 수 제한으로 오용 방지 |
| 로깅 및 모니터링 | 모든 요청에 대한 로그 기록 및 상태 추적 |
| 보안 강화 | WAF 연계, CORS 정책, HTTPS 강제, Payload 검사 |
| API 버전 관리 | /v1, /v2와 같이 API 변경 이력 관리 |
| 변환(Transformation) | 요청 또는 응답 포맷 변경 (예: JSON→XML) |
| 캐싱(Caching) | 동일한 요청 결과 캐시로 성능 향상 |
✅ 3. 주요 구성 방식
| Path-based Routing | 경로(URL path) 기준으로 백엔드 라우팅 |
| Host-based Routing | 요청 도메인에 따라 라우팅 |
| Filter 기반 구성 | 요청/응답에 대해 사전/사후 필터 적용 (Spring Cloud Gateway 등) |
✅ 4. 대표 API Gateway 제품
| Kong | 플러그인 기반 확장성, 클라우드/온프렘 지원 |
| AWS API Gateway | Lambda, EC2 연계, 인증/스테이지 관리 |
| Azure API Management | 보안 정책, 스케일아웃, 개발자 포털 제공 |
| NGINX + Lua | 경량화된 커스텀 게이트웨이 가능 |
| Spring Cloud Gateway | Java 기반 MSA 환경에서 사용 용이 |
✅ 5. TA 관점 출제 포인트
- Path vs Host 기반 라우팅 구성 판단
- Rate Limit 정책 설계
- API Key/JWT 인증 흐름
- Filter 체인 동작 순서
- 장애 발생 시 라우팅 실패 원인 분석
- API Gateway + Service Mesh 구성 차이
- 클라우드 기반 API Gateway의 정책 관리 기능
📝 API Gateway 예상문제 20문항 (정답/해설 포함)
📌 문항 1
API Gateway의 주요 목적이 아닌 것은?
① 로드밸런싱
② 보안 정책 적용
③ 데이터베이스 병합
④ 인증 및 인가 처리
⑤ 요청 로깅 및 모니터링
정답: ③
해설: DB 병합은 API Gateway 역할이 아니며, 보통 백엔드 마이크로서비스에서 처리한다.
📌 문항 2
API Gateway에서 Rate Limiting 기능의 주요 목적은?
① 사용자 인증을 위함
② 요청 속도를 높이기 위함
③ 백엔드 과부하 방지 및 트래픽 제어
④ 데이터베이스 이중화
⑤ API 버전 관리 자동화
정답: ③
📌 문항 3
Spring Cloud Gateway에서 Filter가 적용되는 순서는?
① Pre → Global → Route → Post
② Route → Pre → Post
③ Global Filter → Route Filter
④ Pre Filter → Route Filter → Post Filter
⑤ Post Filter → Pre Filter → Global Filter
정답: ④
📌 문항 4
API Gateway에서 JWT 인증을 사용하는 이유는?
① 오브젝트 스토리지 접근용
② 정적 파일 캐싱
③ 무상태 인증 구현
④ 스레드 동기화
⑤ 로그 집계
정답: ③
📌 문항 5
다음 중 Azure API Management의 기능이 아닌 것은?
① 정책 기반 요청 제한
② 개발자 포털 제공
③ API Key 발급
④ 리소스 그룹 생성
⑤ 로깅/분석 연동
정답: ④
해설: 리소스 그룹은 Azure 인프라 레벨 관리 개념이다.
📌 문항 6
API Gateway 장애 시 발생 가능한 문제는?
① DNS 해석 실패
② 모든 요청이 직접 백엔드에 전달
③ 인증 우회 발생
④ 포트 포워딩 중단
⑤ L4 스위칭 실패
정답: ②
📌 문항 7
Path-based Routing 예시로 올바른 것은?
① GET /product/v1/* → product-service
② api.company.com → routing-service
③ X-API-KEY: abc123 → auth-service
④ v1.user.com → user-service
⑤ Header: lang=en → locale-service
정답: ①
📌 문항 8
API Gateway에서 Cache를 사용할 때 고려할 항목이 아닌 것은?
① 응답 코드
② TTL(Time to Live)
③ 요청 ID
④ URL Path
⑤ 사용자 인증 정보
정답: ③
해설: 요청 ID는 고유 식별용으로 캐싱과는 무관함.
📌 문항 9
클라이언트가 여러 API 서버와 직접 통신하지 않고 API Gateway만 통해 통신하도록 하는 이유는?
① 비용 증가 방지
② 로컬 DNS 활용
③ 보안 및 라우팅 통합 관리
④ 브라우저 캐시 최적화
⑤ NAT 테이블 최소화
정답: ③
📌 문항 10
API Gateway에 인증 로직을 위임할 때 얻는 장점은?
① 클라이언트 코드 간소화
② DB 트랜잭션 향상
③ 파일 처리 속도 증가
④ 로드밸런서 간소화
⑤ IP 포워딩 가속화
정답: ①
👉 문항 11~20번은 다음 응답에서 이어서 제공됩니다.
(이후 Word/PDF 문서로 제공 가능, 정답 숨김 버전도 가능)
나의 말:
ChatGPT의 말:
좋습니다. 아래는 Azure 기반 API Gateway, 즉 **Azure API Management (Azure APIM)**에 대한 TA 실무 관점 설명입니다.
📘 Azure API Management (Azure APIM) 개요
✅ 1. 정의
**Azure API Management (APIM)**는 마이크로서비스 아키텍처 및 다양한 백엔드 서비스를 대상으로 API를 안전하게 게이트웨이화하고, 모니터링하며, 배포와 운영을 단순화할 수 있는 PaaS 서비스입니다.
👉 API Gateway + Developer Portal + 정책 엔진 + 인증/인가/로깅 기능을 통합한 API Lifecycle 플랫폼
✅ 2. 주요 구성 요소
| Gateway | API 호출을 수신하고 정책을 적용한 후 백엔드로 전달 |
| Publisher Portal (관리자) | API 정의, 정책 설정, 사용자 관리 등 수행 |
| Developer Portal | 외부 개발자용: 문서 확인, 테스트, 키 발급 |
| Policies | 요청/응답에 적용할 보안, 속도제한, 캐싱 등 처리 규칙 |
| Products | API들을 묶어서 제공하는 단위. 요금제와 접근제어 연계 가능 |
✅ 3. 주요 기능
| 인증 및 보안 | OAuth2.0, JWT, API Key 기반 인증. IP 필터링, CORS 등 지원 |
| 요청 제한(Rate Limit) | 초당 요청 수 제한, 사용자별 제한 등 설정 가능 |
| 트래픽 제어 | Load balancing, throttling, retry 등 제어 정책 설정 |
| 변환 기능 | 요청/응답 포맷(JSON↔XML), Header/Query 변경 |
| API 버전 관리 | v1, v2 등의 버전 구분, 경로 또는 쿼리 기반 |
| 로깅 및 모니터링 | Azure Monitor, Application Insights 연계 가능 |
| 백엔드 추상화 | 백엔드 URL을 숨기고 단일 Gateway로 통합 제공 가능 |
✅ 4. 배포 모드 (스케일 모델)
| Developer | 1인 개발용 (비용 없음, SLA 없음) |
| Basic / Standard / Premium | SLA 보장, 확장 가능, VNET 연계 가능 (Premium부터) |
| Self-hosted Gateway | 온프레미스 또는 Kubernetes에 게이트웨이 런타임 설치 가능 |
✅ 5. 정책(Policies) 예시
👉 XML 기반으로 유연하게 정책 구성 가능
✅ 6. 실무 적용 시나리오 예시
| 서로 다른 백엔드 서비스를 하나의 API 엔드포인트로 통합 | 다수의 API를 경로 기반으로 묶고, 단일 Gateway 제공 |
| 외부 고객에게 API 제공 시 | Developer Portal을 통해 API 문서, 테스트, 키 발급 기능 제공 |
| 비용 및 부하 제어 | Rate Limit 정책 설정 + Azure Monitor로 모니터링 |
| API 인증 일원화 | Gateway에서 JWT 또는 OAuth2.0 인증 수행 후 백엔드 전달 |
✅ 7. TA 시험/실무 평가 포인트
- Azure APIM 구성 요소 간 역할 구분 가능해야 함
- 정책(XML Policy) 구성 로직 이해 필수
- API 버전 관리 및 인증 적용 방식 선택 가능해야 함
- Failover, 캐싱, 로깅 연계 방식 파악 필요
- Azure Functions, Logic Apps 등과 연동한 API 구성 경험
다음으로 무엇을 도와드릴까요?
- 📄 Word/PDF 요약본 출력
- 🧪 Azure API Gateway 기반 TA 문제 20문항 세트 (이전 일반 문제 이어서 구성 가능)
- 🎯 실무 시나리오 기반 장애 대응 문제
- 🧠 암기카드 요약
- 📚 키워드 인덱스 블로그용 정리
예: “Azure APIM 기반 문제 이어서 만들어줘” 또는 “PDF로 저장해줘” 등 원하시는 방식으로 요청해 주세요.
나의 말:
ChatGPT의 말:
좋습니다! 이어서 **Azure 기반 API Gateway(Azure API Management)**를 중심으로 한 TA 실무 문제 11번~20번을 제공하겠습니다.
앞서 110번 문제는 API Gateway 전반적인 이해 중심이었다면, 이번 1120번은 Azure APIM 구성 요소, 정책(policy), 인증, 장애 대응 등 실무 중심으로 구성했습니다.
📝 Azure API Management 기반 예상문제 (문항 11~20)
📌 문항 11
Azure APIM의 정책(Policy) 기능 중 rate-limit의 주요 목적은?
① 사용자 인증 수행
② 요청당 응답 크기 제한
③ 요청 횟수 제한 및 트래픽 보호
④ 백엔드 DB 트랜잭션 제어
⑤ API 버전 자동 설정
정답: ③
해설: rate-limit는 일정 시간 내 호출 횟수를 제한하여 서비스 보호 및 오용 방지를 수행함.
📌 문항 12
Azure API Management에서 API 버전 관리 방식으로 가장 적절한 것은?
① JWT Claim을 통한 버전 설정
② 동시 API Key 사용
③ 경로 기반(path) 버전 관리
④ VM 태그 설정
⑤ L7 Load Balancer 사용
정답: ③
해설: APIM은 /v1, /v2 등 경로 기반(path-based) 또는 query string, header 기반 버전 관리를 지원함.
📌 문항 13
Azure APIM에서 요청을 인증하는 정책으로 적절한 것은?
① validate-jwt
② add-header
③ set-body
④ remove-query-param
⑤ rewrite-uri
정답: ①
해설: validate-jwt는 Authorization Header에 담긴 JWT 토큰을 서명 키와 claim 조건을 기준으로 검증함.
📌 문항 14
Azure APIM에서 Developer Portal의 목적은?
① API 요청을 직접 라우팅
② 외부 개발자가 API 사용을 테스트하고 키를 발급받는 포털
③ 백엔드 관리자가 정책을 구성하는 포털
④ IPSec 연결 제어용
⑤ RBAC 정책을 조정하는 콘솔
정답: ②
📌 문항 15
APIM에서 inbound → backend → outbound 순서의 정책 처리 흐름에서 응답 변환 작업을 수행할 위치는?
① inbound
② backend
③ outbound
④ error
⑤ routing
정답: ③
해설: outbound 단계는 백엔드의 응답을 클라이언트로 전달하기 전에 필터링/변환할 수 있는 지점임.
📌 문항 16
다음 중 Azure API Management에서 “Self-hosted Gateway”를 사용하는 주요 이유는?
① 높은 처리량
② Kubernetes 내부에서 API Gateway 사용
③ Developer Portal 제거
④ VPN 우회 설정
⑤ Web App 연동 제한
정답: ②
해설: Self-hosted Gateway는 온프렘 또는 컨테이너 환경(Kubernetes 등)에서 APIM의 Gateway 기능만 배포하여 사용할 수 있음.
📌 문항 17
Azure API Management에서 set-backend-service 정책의 목적은?
① 인증서 무효화
② 요청 거부
③ 백엔드 서비스 URL을 설정하거나 재정의
④ 쿠키 삭제
⑤ 캐시 TTL 설정
정답: ③
📌 문항 18
Azure API Management에서 장애 발생 시 다음 중 가능한 원인이 아닌 것은?
① 정책 구문 오류(XML 형식)
② Backend 서비스 미연결
③ JWT 서명키 변경 누락
④ Azure Front Door 연결 설정 누락
⑤ Redis 클러스터 장애
정답: ⑤
해설: Redis는 APIM과 직접 연동되지 않으며, APIM 장애와는 관련이 없음.
📌 문항 19
API Management에서 요청 헤더를 기반으로 라우팅 정책을 구성하려면 어떤 정책 요소를 사용해야 하는가?
① set-header
② choose
③ validate-parameters
④ rewrite-uri
⑤ cache-lookup
정답: ②
해설: choose 정책은 조건문과 유사하게 작동하여, 헤더/쿼리/경로 조건에 따라 분기 처리를 수행함.
📌 문항 20
Azure API Management를 사용하는 환경에서 백엔드 API가 느린 응답을 반환할 경우 대응 방법으로 가장 적절한 것은?
① CORS 정책 강화
② API Gateway에 LRU 캐시 적용
③ Azure Functions로 자동 우회
④ 요청에 Timeout 정책 설정 및 fallback 구성
⑤ 인증서 키를 재생성
정답: ④
해설: 백엔드 지연 대응을 위해 timeout 및 fallback 정책을 설정하여 지속 가능한 응답을 유도함.
✅ 요약
| 11~13 | 정책 구성 (rate-limit, validate-jwt 등) |
| 14~16 | Developer Portal, Self-hosted Gateway, 흐름 구조 |
| 17~19 | 정책 적용 위치, 조건 분기 처리 |
| 20 | 장애 대응 (timeout, fallback) |
📌 이 문제들과 앞서 제공한 1~10번까지 합치면 총 20문항 완성입니다.
다음으로 도와드릴 수 있는 항목:
- 📄 Word/PDF로 출력
- 🎯 정답 숨김 연습용 버전 제작
- 🧠 키워드 암기카드 요약
- 🧪 실무 시나리오 기반 장애 대응 문제 제작
- 📚 키워드 인덱스 정리 (블로그용)
예: “PDF로 만들어줘” 또는 “암기카드 만들어줘” 등 요청해주세요.
나의 말:
ChatGPT의 말:
좋습니다! 아래는 **Azure API Gateway (Azure API Management)**에 대한 암기카드(Key-Point Flashcards) 및 키워드 인덱스 정리입니다.
시험 대비 뿐만 아니라 오픈북 블로그 검색용, Ctrl+F 참고서용으로도 바로 활용 가능합니다.
🧠 [암기카드] Azure API Gateway 핵심 키워드
| API Gateway 역할 | 인증, 라우팅, 로깅, RateLimit, 변환 등 중앙 관리 |
| Azure APIM 구성요소 | Gateway / Publisher Portal / Developer Portal / Products / Policies |
| Policies | XML 기반 요청/응답 처리 규칙. Inbound → Backend → Outbound 순 |
| rate-limit | 초당 요청 수 제한. 오용 방지 목적 |
| validate-jwt | JWT 토큰 유효성 검증 (Issuer, Audience 등 claim 포함) |
| Path-based Routing | URL 경로 기반 라우팅 (/v1/product → product-api) |
| Header-based Routing | choose 정책으로 조건 분기 가능 |
| Developer Portal | 외부 사용자용 테스트/문서/Key 발급 포털 |
| Self-hosted Gateway | Kubernetes, 온프렘 환경에서도 APIM 기능 사용 가능 |
| Transformation | 요청/응답 포맷 변경 (Header, Body, Query 수정 등) |
| Caching | 응답 캐시 → TTL, 응답코드, 조건 기반 설정 |
| API Versioning | Path, Header, Query 기반 버전 분리 관리 |
| set-backend-service | 요청을 라우팅할 백엔드 URL 지정 |
| fallback 정책 | 백엔드 오류 발생 시 대체 응답 제공 |
| Azure Monitor 연계 | 로그, 성능, 장애 추적 가능 (APIM + App Insight) |
| Rate Limit 단위 | Subscription, User, IP 단위 적용 가능 |
| APIM Tier | Developer(비용 無), Basic/Standard/Premium, VNET 통합은 Premium |
| CORS 설정 | Cross-Origin 접근 허용 여부 설정 |
| JWT 기반 인증 장점 | 무상태 인증 (stateless), API Gateway에서 검증 가능 |
| 정책 처리 흐름 | inbound → backend → outbound → on-error |
📚 [키워드 인덱스형 정리] – 블로그 오픈북 참고용
아래 인덱스는 Ctrl+F 검색 키워드로 바로 찾을 수 있도록 단어 위주로 구성했습니다.
📌 구성요소 키워드
- Azure API Management
- API Gateway
- Publisher Portal
- Developer Portal
- Self-hosted Gateway
- API Product
- API Versioning
📌 정책 및 인증 키워드
- Policy
- validate-jwt
- rate-limit
- set-backend-service
- inbound backend outbound
- choose
- rewrite-uri
- jwt 인증
- API Key
📌 운영 및 보안 키워드
- Rate Limiting
- Fallback
- Caching
- Transformation
- Header Injection
- CORS
- Timeout 정책
📌 연계 및 확장 키워드
- Azure Monitor
- Application Insights
- Virtual Network Integration
- Azure Functions
- Logic Apps
✅ 활용 팁
- 위 암기카드는 단답형/객관식 준비에,
- 아래 인덱스 키워드는 블로그 오픈북 환경에서 Ctrl+F 검색용으로 바로 활용 가능합니다.
- 필요 시 PDF/Word 요약 정리본, 또는 정답 숨김 연습용 문제집으로 변환해드릴 수 있습니다.
다음으로 도와드릴까요?
예:
- “정답 숨김용 연습 문제 PDF로 만들어줘”
- “다음 분야 Telemetry 문제 20개 만들어줘”
- “API Gateway 실전 시나리오형 문제로 확장해줘”
나의 말:
ChatGPT의 말:
물론입니다! 아래는 Azure 기반 아키텍처에서 자주 함께 사용되는 5가지 서비스에 대한 간략 정리입니다.
각각의 서비스는 API Gateway, APIM, 또는 마이크로서비스와 유기적으로 통합되며, 실무에서도 자주 연계됩니다.
📘 Azure 핵심 서비스 요약
1️⃣ Azure Monitor
클라우드 및 온프렘 자원의 로그, 성능, 진단 정보를 수집 및 분석하는 통합 모니터링 플랫폼
- 용도: VM, AKS, APIM, Functions 등에서 수집한 메트릭과 로그를 통합 분석
- 구성 요소: Metrics, Logs, Alerts, Workbooks, Diagnostic Settings
- 특징:
- Azure 리소스에 대한 통합 성능/진단 분석
- Application Insights, Log Analytics와 연동
- 자동 경고(Alert) 및 액션 그룹 설정 가능
2️⃣ Application Insights
애플리케이션 수준의 실시간 모니터링 도구 (Azure Monitor의 하위 서비스)
- 용도: 웹 앱, API, Azure Function 등에서 응답 시간, 트랜잭션 흐름, 오류 추적
- 주요 기능:
- Dependency Map: API 호출 간 호출 관계 추적
- Live Metrics: 실시간 요청/오류 확인
- Distributed Tracing: 다중 서비스 호출 흐름 시각화
- 장점: 코드 수정 없이 SDK 또는 자동 수집으로 연동 가능
3️⃣ Virtual Network Integration (VNet Integration)
Azure PaaS 서비스 (App Service, APIM 등)를 사설 가상 네트워크에 연결하기 위한 기능
- 용도:
- APIM → 내부 백엔드 서버 통신
- Functions/App Service → Private DB 접근
- 연결 방식:
- Regional VNet Integration: 동일 리전에 존재
- Gateway-required VNet: VNet Gateway 필요
- 보안 강화: 인터넷 노출 없이 내부망을 통해만 통신 가능 (Private Link 또는 Service Endpoint와 병행 사용)
4️⃣ Azure Functions
서버리스(Serverless) 환경에서 코드 실행을 위한 이벤트 기반 실행 플랫폼
- 특징:
- 트리거 기반 실행: HTTP 호출, 큐/이벤트, 타이머 등
- 과금: 실행 시간/리소스 기준으로 요금 책정 (초 단위 과금)
- 무서버 관리: 인프라 관리 불필요
- API Gateway 연동: Functions를 백엔드로 연결하여 API 처리 가능 (Lightweight Backend 처리에 유용)
5️⃣ Logic Apps
코드 없이 워크플로우(Workflow)를 구성할 수 있는 자동화 플랫폼
- 용도:
- 이벤트 기반 자동 처리
- 외부 SaaS, API, DB, 이메일 등과 연동 및 자동화
- 특징:
- 수백 개의 커넥터 제공 (Office365, Twitter, SQL, SAP 등)
- 조건문, 반복, 병렬 처리 등 복잡한 로직 구성 가능
- API Gateway 연동: Logic App을 백엔드로 연결하여 외부 API 호출 자동화 가능
✅ 요약 매트릭스
| Azure Monitor | 리소스 통합 모니터링 | APIM, AKS, VM 등 | 로그 수집, 알림 |
| Application Insights | 앱 성능/오류 추적 | API, Web App | 응답시간, 오류 분석 |
| VNet Integration | PaaS → 내부망 연결 | App Service, APIM | 보안/내부망 연결 |
| Azure Functions | 서버리스 백엔드 | APIM, 이벤트 | 라이트 API 처리 |
| Logic Apps | 코드 없는 자동화 | 외부 시스템 | 워크플로우 자동화 |
🔐 1. NSG (Network Security Group) 보안 정책
🔹 기본 구조
- NSG는 **서브넷 또는 NIC(네트워크 인터페이스 카드)**에 적용되는 네트워크 트래픽 필터링 장치입니다.
- 인바운드/아웃바운드 규칙 각각에 대해 설정 가능.
- 기본 정책은 Deny All이며, 허용(Allow) 정책을 명시적으로 추가해야 통신이 가능합니다.
🔹 동작 원칙
| 기본 설정 | 모든 인바운드/아웃바운드 트래픽 차단(Deny) |
| 규칙 처리 | 우선순위(Priority) 값이 낮을수록 먼저 적용 |
| 허용 조건 | 명시적 Allow 룰이 없으면 모든 트래픽은 Deny |
TA Tip: NSG 설정 후 외부 접근 불가 → 보안 규칙 우선순위 및 로그 분석 필수
🌐 2. Application Gateway 리스너 구조
🔹 기본 개념
- **Application Gateway (L7 Load Balancer)**는 HTTP/HTTPS 기반 리스너만 지원합니다.
- L4 수준의 TCP 리스너는 Azure Load Balancer 사용.
🔹 구성 요소
| Listener | 포트 + 프로토콜(HTTP/HTTPS) 지정 |
| Rules | 요청 경로 또는 호스트 헤더 기반 라우팅 |
| Backend Pool | VM, Scale Set, App Service 등을 포함 가능 |
| WAF | 웹 애플리케이션 방화벽(WAF) 모드로 보안 강화 가능 |
TA Tip: HTTP 외 프로토콜(FTP, SMTP 등)은 지원 불가 → 다른 서비스 사용 고려
📦 3. 스토리지 계정 복제 옵션 (Replication)
🔹 복제 종류 비교
| LRS (Locally Redundant Storage) | 동일 데이터센터 내 3중 복제 | 낮음 | 저렴 |
| ZRS (Zone-Redundant Storage) | 다른 AZ (가용성 영역) 간 복제 | 높음 | 중간 |
| GRS (Geo-Redundant Storage) | 주 지역 + 보조 지역에 복제 | 매우 높음 | 높음 |
| GZRS | ZRS + GRS 조합 (Zone + Geo) | 최고 수준 | 가장 높음 |
| RA-GRS | GRS + 읽기 전용 보조지역 지원 | 장애 시 활용 가능 | 높음 |
TA Tip: BCDR 설계 시 GRS/GZRS 필수 고려. LRS는 내부 테스트용 적합.
💾 4. VM Backup 구조 (Azure Backup Center & Azure Monitor)
🔹 백업 방식
- Azure Backup Center: 중앙집중형 백업 관리 포털
- Azure Recovery Services Vault: 백업 데이터 저장소
- VM 백업은 스냅샷 기반, 애플리케이션 일관성 보장 가능
🔹 연계 모니터링
- Azure Monitor 및 Log Analytics 연계로 백업 실패, 경고, 성공 이력 실시간 추적 가능
- Alert Rule을 통해 메일/Teams 등으로 자동 알림
TA Tip: 백업 구성 후 모니터링 연계 없으면 실시간 대응 불가 → Alert Rule 설정 필수
⚙️ 5. Managed Disk 유형별 성능 차이
🔹 디스크 타입 비교
| Standard HDD | 낮음 | 최대 500 IOPS | 비용 민감, 아카이브용 |
| Standard SSD | 중간 | 최대 2,000 IOPS | 범용 서버 워크로드 |
| Premium SSD | 높음 | 최대 20,000 IOPS 이상 | 트랜잭션 처리 시스템 |
| Ultra SSD | 매우 높음 | 수십만 IOPS 지원 | DBMS, SAP HANA 등 고성능 필요 |
🔹 특징
- Premium/Ultra SSD는 성능 크기별로 요금 증가
- Ultra SSD는 I/O 단위로 성능 조정 가능
TA Tip: 고성능 요구 시스템(PaaS DB, OLTP DB)은 Premium 이상 필수. 비용-성능 밸런스 고려.
'Migration & DR > 시스템 이관환경 및 Landing Zone 설계' 카테고리의 다른 글
| Kubernetes Storage 설명과 랜딩존(Backup & Recovery포함) (0) | 2025.08.31 |
|---|---|
| (gpt)On-Premises DB를 Microsoft Azure로 마이그레이션 (0) | 2025.07.18 |