AZ-204에서 API Management와 이벤트 서비스는 통합 도메인의 핵심입니다. API를 안전하게 노출하고, 이벤트 기반 아키텍처를 구축하는 방법을 다룹니다.
Azure API Management (APIM)
APIM은 백화점의 안내 데스크와 같습니다. 방문객(클라이언트)이 백화점 내 어느 매장(백엔드 서비스)을 가든 안내 데스크를 거치면서 신분 확인, 안내, 기록이 이루어집니다.
APIM을 통해 여러 백엔드 API를 하나의 일관된 게이트웨이로 묶어서 외부에 노출할 수 있습니다.
| 기능 | 설명 | |------|------| | API 게시 | 백엔드 API를 외부에 안전하게 노출 | | 보호 | 인증, 속도 제한, IP 필터링 | | 변환 | 요청/응답 형식 변환, 헤더 추가/제거 | | 모니터링 | 호출 로그, 분석 대시보드 |
제품, 구독, 키
| 개념 | 설명 | 예시 | |------|------|------| | 제품 (Product) | API를 묶은 패키지 | "무료 플랜 API", "프리미엄 API" | | 구독 (Subscription) | 제품에 접근하기 위한 신청 | 개발자가 "무료 플랜"에 구독 신청 | | 구독 키 (Subscription Key) | API 호출 시 사용하는 인증 토큰 | 헤더 |
클라이언트는 구독 키를 HTTP 헤더 또는 쿼리 파라미터에 포함해서 API를 호출합니다.
APIM 정책 (Policies)
정책은 APIM 게이트웨이에서 요청 또는 응답을 가로채 처리하는 규칙입니다. XML 형식으로 작성합니다.
정책 파이프라인
요청과 응답은 4단계를 거칩니다:
인바운드 (Inbound): 클라이언트에서 게이트웨이로 들어온 요청 처리 백엔드 (Backend): 게이트웨이에서 백엔드로 요청 전달 전 처리 아웃바운드 (Outbound): 백엔드에서 받은 응답을 클라이언트로 보내기 전 처리 오류 처리 (On-Error): 오류 발생 시 처리
주요 정책 일람
| 정책 | 위치 | 설명 | |------|------|------| | rate-limit | 인바운드 | 호출 횟수 제한 (초과 시 429 반환) | | ip-filter | 인바운드 | IP 주소 허용/차단 | | set-header | 인/아웃바운드 | 헤더 추가, 수정, 삭제 | | rewrite-uri | 인바운드 | 백엔드로 보내는 URL 변환 | | mock-response | 인바운드 | 실제 백엔드 없이 가짜 응답 반환 | | cache-lookup / cache-store | 인/아웃바운드 | 응답 캐싱 |
Azure Event Grid
Event Grid는 우체국의 알림 서비스와 같습니다. 누군가(이벤트 소스)가 편지를 보내면, 우체국(Event Grid)이 받아서 해당 편지를 받기로 신청한 사람들(구독자)에게 전달합니다.
이벤트가 발생했을 때 반응하는 "반응형 아키텍처"를 구현할 때 사용합니다. 예를 들어 이미지가 Blob Storage에 업로드되면 자동으로 썸네일을 생성하는 Azure Function을 트리거할 수 있습니다.
핵심 구성 요소
| 구성 요소 | 역할 | 예시 | |---------|------|------| | 이벤트 소스 (Event Source) | 이벤트를 발생시키는 서비스 | Blob Storage, Resource Group, 사용자 정의 앱 | | 토픽 (Topic) | 이벤트가 전달되는 채널 | 시스템 토픽 (Azure 서비스 자동 생성) / 사용자 지정 토픽 | | 이벤트 구독 (Event Subscription) | 어떤 이벤트를 어느 핸들러로 보낼지 정의 | Blob 생성 이벤트 → Function App | | 이벤트 핸들러 (Event Handler) | 이벤트를 받아서 처리하는 서비스 | Azure Function, Logic App, Webhook, Event Hubs |
CloudEvents 형식을 표준으로 지원합니다.
Azure Event Hubs
Event Hubs는 대규모 공연장의 입장 게이트와 같습니다. 수만 명이 동시에 입장할 때 여러 게이트(파티션)로 나눠서 처리하고, 들어온 순서를 기록해 두었다가 나중에 다시 확인할 수 있습니다.
초당 수백만 건의 이벤트를 처리해야 하는 빅데이터 스트리밍 시나리오에 사용합니다.
핵심 개념
| 개념 | 설명 | |------|------| | 파티션 (Partition) | 이벤트를 병렬로 처리하기 위한 분할 단위 (기본 4개) | | 소비자 그룹 (Consumer Group) | 같은 이벤트 스트림을 독립적으로 읽는 소비자 집합 | | 캡처 (Capture) | 이벤트를 Blob Storage 또는 Data Lake에 자동 저장 | | 보존 기간 | 기본 1일, 최대 90일 |
Event Grid vs Event Hubs 비교
| 항목 | Event Grid | Event Hubs | |------|-----------|-----------| | 주요 용도 | 이벤트 발생 시 즉각 반응 (반응형) | 대규모 데이터 스트리밍 처리 | | 처리 방식 | 이벤트 하나씩 전달 (Push) | 스트림 형태로 순서대로 처리 | | 규모 | 최대 초당 수천 건 | 최대 초당 수백만 건 | | 보존 | 없음 (전달 후 삭제) | 최대 90일 보존 | | 사용 시나리오 | 파일 업로드 → 처리 트리거 | IoT 센서 데이터, 로그 스트리밍 |
!Event Grid vs Event Hubs
시험 핵심 정리
"여러 백엔드 API를 하나의 게이트웨이로 통합 관리" -- Azure API Management (APIM)
"API 호출 횟수를 분당 N회로 제한" -- rate-limit 정책 (인바운드)
"특정 IP만 API 접근 허용/차단" -- ip-filter 정책
"백엔드로 전달하는 URL 경로 변환" -- rewrite-uri 정책
"실제 백엔드 없이 테스트용 응답 반환" -- mock-response 정책
"정책 실행 순서" -- 인바운드 → 백엔드 → 아웃바운드 → 오류 처리
"이벤트 발생 시 Function 자동 트리거 (반응형)" -- Azure Event Grid
"Blob 업로드 이벤트를 구독하는 핵심 구성" -- 이벤트 구독 (Event Subscription)
"초당 수백만 건 대규모 스트리밍 처리" -- Azure Event Hubs
"Event Hubs 데이터를 Blob Storage에 자동 저장" -- 캡처 (Capture)
"같은 스트림을 여러 팀이 독립적으로 읽기" -- 소비자 그룹 (Consumer Group)