Microsoft AZ-204: Azure 이벤트 기반 및 메시지 솔루션 — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Developer Associate AZ-204 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure의 이벤트 및 메시징 포트폴리오는 서로를 보완하는 네 가지 서비스로 구성됩니다: 반응형 이벤트 처리를 위한 Event Grid, 대규모 스트리밍 수집을 위한 Event Hubs, 엔터프라이즈 메시징 및 워크플로 조정을 위한 Service Bus, 모바일 푸시를 위한 Notification Hubs. 이 서비스들을 완전히 익히려면 각 서비스의 핵심 추상화, 전달 및 재시도 의미 체계, 확장 모델을 알아야 하며, pub/sub, 명령 처리, 원격 분석 데이터 수집, 디바이스 또는 사용자 알림과 같은 일반적인 애플리케이션 패턴에서 어떤 서비스를 선호해야 하는지 이해해야 합니다.

Event Grid: 토픽, 구독, 스키마, 필터링 및 데드레터링

Event Grid는 개별 이벤트를 위한 완전 관리형 푸시 기반 pub/sub 패브릭입니다. 게시자는 이벤트를 토픽으로 보내고, 구독자는 토픽에 이벤트 구독을 등록하여 HTTPS 웹 후크, Azure Functions, Logic Apps, Service Bus, Storage Queues, Event Hubs와 같은 지원되는 처리기에서 일치하는 이벤트를 수신합니다. Event Grid는 두 가지 게시자 모델을 정의합니다. 시스템 토픽은 구독 또는 리소스 그룹 내에서 이벤트를 게시하는 자사 Azure 서비스를 나타내는 Azure 관리형 토픽 리소스입니다(예: Storage Blob 생성, Key Vault 비밀 순환 또는 Resource Manager 이벤트). 사용자 지정 토픽은 애플리케이션이 이벤트를 게시하는 사용자가 생성한 토픽 엔드포인트로, 자체 서비스 및 도메인 전반에 걸쳐 이벤트 기반 패턴을 활성화합니다. 시스템 토픽은 게시자 코드가 필요 없으며 Azure 리소스를 반응형 처리기에 연결하는 작업을 단순화합니다. 반면 사용자 지정 토픽은 이벤트 계약 및 수명 주기에 대한 완전한 제어권을 제공합니다.

Event Grid 이벤트는 네이티브 Event Grid 스키마 또는 CloudEvents v1.0 사양을 사용할 수 있습니다. Event Grid 스키마에서 각 이벤트는 id(고유 식별자), eventType(작업), subject(필터링을 지원하는 계층적 경로), eventTime(UTC), data(페이로드), dataVersion, metadataVersion, topic을 포함합니다. CloudEvents는 id, source, type, time, subject, data와 같은 표준화된 속성 집합을 제공합니다. CloudEvents를 선택하면 플랫폼 간 상호 운용성이 쉬워집니다. Event Grid 스키마는 Azure에서 발생한 이벤트와의 일관성을 유지하고 subject에 대한 풍부한 필터링 기능을 제공합니다.

이벤트 구독은 라우팅, 전달 옵션 및 필터를 정의합니다. 기본 필터에는 이벤트 유형 포함 및 subject 접두사/접미사(subjectBeginsWith, subjectEndsWith)가 있으며, 이는 계층적 리소스 이름 지정에 효율적입니다. 고급 필터는 최상위 이벤트 또는 데이터 내의 필드를 기준으로 일치시킵니다(예: 숫자 범위 비교, 대/소문자를 구분하지 않는 문자열 포함, 부울 같음, 배열 포함). 필터를 조합하여 정밀한 팬아웃 제어를 구현하고 다운스트림 작업 및 이그레스(egress)를 최소화할 수 있습니다.

전달은 최소 한 번(at-least-once) 전달 의미 체계를 사용하는 푸시 방식입니다. Event Grid는 지수 백오프를 사용하여 재시도합니다. 최대 재시도 횟수와 이벤트 TTL(Time-To-Live)을 구성할 수 있습니다. 전달이 최종적으로 실패하거나 이벤트가 만료되면 Event Grid는 구독에 지정한 Blob Storage 컨테이너로 이벤트를 데드레터(dead-letter) 처리할 수 있습니다. 데드레터링은 감사 또는 재처리를 위해 페이로드와 메타데이터를 보존합니다. 필요한 경우 별도의 프로세스를 사용하여 이벤트를 복원하고 재생할 수 있습니다. 웹 후크 엔드포인트는 소유권을 증명하기 위해 유효성 검사 핸드셰이크에 참여하며, 제한된 네트워크의 경우 퍼블릭 노출이 필요 없고 Azure AD 기반 권한 부여를 사용할 수 있는 관리형 Azure 엔드포인트(Functions, Service Bus, Storage Queue)를 선호할 수 있습니다.

Event Hubs: 파티션, 소비자 그룹, 처리량, 캡처 및 안정적인 소비

Event Hubs는 대용량 원격 분석 및 로그 스트림을 짧은 대기 시간으로 수집합니다. 데이터는 독립적이고 순서가 지정된 커밋 로그(commit log)인 파티션에 추가됩니다. 파티션은 생성 시 처리량을 병렬화하기 위해 선택됩니다. 생산자는 키별 순서를 보존하기 위해 파티션 키를 할당하고, 서비스는 이 키를 해시하여 파티션에 할당합니다. 여러 판독기가 파티션을 병렬로 처리할 수 있으며, 파티션 내에서는 순서가 보장됩니다.

소비자 그룹은 스트림에 대한 독립적인 뷰를 제공하여, 서로 다른 처리 애플리케이션이 서로 간섭하지 않고 각자 자신의 위치를 유지할 수 있도록 합니다(예: 실시간 이상 감지기와 보관 파이프라인). 판독기를 수평적으로 확장하려면 파티션 소유권 분산이 필요합니다. SDK의 EventProcessorClient는 인스턴스 간의 파티션 할당 및 재조정을 조정합니다.

표준(Standard) 계층의 처리량 단위(TU)는 용량을 정의합니다. 각 TU는 수신 및 송신 대역폭 할당량을 부여합니다. 자동 확장(Auto-inflate) 기능은 최고 사용량에 맞춰 TU를 자동으로 확장할 수 있습니다. 프리미엄(Premium) 계층은 전용 컴퓨팅과 예측 가능한 대기 시간을 제공하는 처리 단위를 사용합니다. 제한(throttling) 메트릭을 모니터링하여 프로비저닝이 적절한지 확인합니다. Event Hubs는 동일한 엔드포인트에서 Kafka 프로토콜을 지원하므로, 브로커를 직접 실행하지 않고도 Kafka 클라이언트의 리프트 앤 시프트(lift-and-shift)를 단순화할 수 있습니다.

생산자는 AMQP 또는 HTTPS를 사용할 수 있습니다. AMQP(443 포트의 AMQP-over-WebSockets 포함)는 다중화된 영구 연결과 효율적인 일괄 처리를 제공하며, 송수신 모두에 권장됩니다. HTTPS는 단순하거나 간헐적인 전송에는 적합하지만 수신은 지원하지 않습니다. 롱폴링(long-polling)은 사용할 수 없으며 효율성과 흐름 제어를 포기해야 합니다. 제한된 기업 네트워크에서는 AMQP-over-WebSockets를 사용하면 일반적인 아웃바운드 프록시를 통과하면서도 성능을 유지할 수 있습니다.

검사점 설정(Checkpointing) 및 오프셋 관리는 정확성을 위해 매우 중요합니다. 각 이벤트는 파티션별로 시퀀스 번호와 오프셋을 가집니다. 수신기는 스트림을 따라 진행하며, 배치를 성공적으로 처리한 후에는 일반적으로 EventProcessorClient를 통해 Azure Blob Storage 컨테이너와 같은 영구 스토리지에 자신의 위치를 검사점으로 저장합니다. 재시작 또는 장애 조치 시, 프로세서는 마지막 검사점부터 다시 시작하여 멱등성(idempotent) 핸들러를 통해 최소 한 번 이상(at-least-once) 처리를 달성합니다. 검사점이 없으면 소비자는 기본 위치(가장 최신 또는 가장 오래된)에서 시작하여 이벤트를 재처리하거나 건너뛸 위험이 있습니다.

캡처(Capture)는 구성 가능한 시간 또는 크기 창에 따라 일괄 처리된 추가 전용(append-only) Avro 파일을 Azure Blob Storage 또는 Azure Data Lake Storage Gen2에 자동으로 기록하여 서버 측 보관 기능을 제공합니다. 이를 통해 콜드 경로(cold-path) 분석을 위한 사용자 지정 일괄 처리기를 만들 필요가 없어지며, 다운스트림 도구(Spark, Synapse)가 캡처 파이프라인에 대해 정확히 한 번(exactly-once) 의미 체계를 갖는 불변의 스트림 세그먼트를 사용할 수 있게 됩니다.

Service Bus 및 Queue Storage: 명령, 워크플로, 세션 및 포이즌 메시지 처리

Service Bus는 풍부한 전송 보장이 필요한 명령, 워크플로, 통합 시나리오를 위한 엔터프라이즈급 메시지 브로커입니다. 큐는 지점 간 메시징을 구현하며, 하나의 경쟁 소비자가 각 메시지를 수신합니다. 구독이 있는 토픽은 게시/구독(pub/sub)을 지원합니다. 게시자는 토픽으로 메시지를 보내고, 독립적인 구독은 규칙에 따라 복사본을 수신합니다. 구독 규칙은 SQL 필터, 상관관계 필터 또는 부울 true 필터가 될 수 있으며, 메시지별 포함 여부를 계산하고 작업을 통해 메시지 속성을 추가하거나 수정할 수 있습니다.

세션은 관련된 메시지에 대해 순서가 보장되고 배타적인 처리를 제공합니다. 서로 관련된 메시지(예: 주문 123의 모든 단계)에 SessionId를 할당합니다. 수신자는 세션 잠금을 수락하고 해당 세션의 메시지를 도착 순서대로 처리하며, 선택적 세션 상태를 유지한 후 다음 소비자가 소유권을 가질 수 있도록 세션을 해제합니다. 이는 대규모 FIFO를 위한 선호되는 패턴입니다. 세션이 없으면 경쟁 소비자 간에 순서가 보장되지 않습니다.

Service Bus는 PeekLock 및 ReceiveAndDelete 모드를 지원합니다. PeekLock은 안정성을 위한 기본 모드입니다. 소비자는 잠금 기간 동안 메시지를 잠그고 처리한 다음 Complete로 처리 완료합니다. 처리에 실패하면 소비자는 Abandon(메시지를 다시 사용 가능하게 만듦), Defer(시퀀스 번호를 사용하여 나중에 검색하도록 연기) 또는 Dead-letter(이유 및 오류 설명과 함께 엔터티의 별도 배달 못한 편지 하위 큐로 이동)를 수행할 수 있습니다. ReceiveAndDelete는 수신 즉시 메시지를 제거하여 안정성을 처리량과 맞바꿉니다.

주요 속성은 수명 주기를 제어합니다. TTL(Time to Live)은 엔터티 기본값으로 설정하고 메시지별로 재정의할 수 있으며, 만료된 메시지는 구성에 따라 배달 못한 편지 큐로 이동되거나 삭제됩니다. 잠금 기간은 메시지가 처리되는 동안 잠겨 있는 시간을 제어합니다. SDK는 최대 한도 내에서 장기 작업에 대한 잠금을 자동으로 갱신할 수 있습니다. 최대 배달 횟수는 큐 또는 구독별로 구성됩니다. 이 횟수만큼 배달 시도(Abandon 또는 잠금 손실)가 실패하면 메시지는 자동으로 배달 못한 편지 큐(DLQ)로 이동됩니다. 운영자는 진단 또는 수정 로직을 사용한 재처리를 위해 DLQ의 메시지를 처리합니다.

Azure Queue Storage는 REST 인터페이스를 갖춘 더 간단하고 대규모로 확장 가능한 큐 서비스로, 기본적인 분리, 높은 팬아웃, 비용에 민감한 워크로드에 가장 적합합니다. 이 서비스는 한 번 이상 전송, 처리 중 메시지를 숨기는 표시 제한 시간, 메시지별 TTL(기본 7일, 만료되지 않도록 구성 가능)을 제공합니다. 개별 메시지 크기는 제한되며, 세션, 트랜잭션, 순서 보장, 중복 검색, 배달 못한 편지 하위 큐, 고급 필터와 같은 기능은 사용할 수 없습니다. 간단한 백그라운드 작업과 저비용으로 매우 높은 처리량이 필요한 경우 Queue Storage를 선택하십시오. 정교한 라우팅(토픽/구독), 세션을 통한 FIFO, 예약된 배달, 지연, 엔터티 간 트랜잭션, 중복 검색 기간, AMQP 지원이 필요하거나 통합 안정성 및 거버넌스가 중요한 경우 Service Bus를 선택하십시오. 일반적인 패턴은 Event Grid 또는 Queue Storage를 통해 경량 이벤트를 팬인(fan in)하고, Service Bus에서 비즈니스에 중요한 명령과 상태 전환을 조정하는 것입니다.

Notification Hubs: 푸시 라우팅 및 플랫폼 자격 증명 관리

Notification Hubs는 대규모 디바이스 등록을 관리하고 Apple(APNs), Android(FCM), Windows(WNS) 및 기타 플랫폼으로 타겟 알림을 라우팅하는 크로스 플랫폼 푸시 엔진입니다. 애플리케이션은 태그 및 태그 식을 사용하여 디바이스를 등록하므로, 정밀한 대상 그룹 선택(예: user:42 AND region:emea OR topic:promotions)이 가능합니다. 템플릿을 사용하면 플랫폼별 렌더러가 확장하는 단일 로컬라이즈된 페이로드를 보낼 수 있어 서버 로직을 줄이고 최소한의 백엔드 분기로 디바이스별 개인화를 지원합니다. 설치(Installation) 모델은 플랫폼 핸들, 태그, 템플릿을 디바이스당 단일 리소스에 캡슐화하여 디바이스 수명 주기 관리를 간소화합니다.

플랫폼 자격 증명 관리는 안정적인 전송의 핵심입니다. APNs의 경우, 인증서 기반 또는 토큰 기반 자격 증명(Key ID, Team ID, .p8 토큰 포함)을 업로드하고 허브 또는 네임스페이스별로 샌드박스 또는 프로덕션 엔드포인트를 선택하여 환경을 분리합니다. FCM의 경우, 적절한 서버 자격 증명(HTTP v1의 경우 OAuth2 범위를 가진 Google 서비스 계정 사용)을 구성합니다. WNS의 경우, 앱을 등록하여 패키지 SID와 클라이언트 시크릿을 얻습니다. 자격 증명은 주기적으로 순환됩니다. 순환을 예약하고 피드백 채널을 모니터링하여 유효하지 않은 디바이스 핸들을 확인하세요. Notification Hubs는 앱 서버로부터의 허브 수준 인증을 위해 SAS를 사용하며, Azure AD 역할은 관리 작업을 보호합니다. 태그 지정 규칙을 사용하여 다중 테넌트 앱을 분할하고, 예약 또는 일괄 푸시로 전송 속도를 조절하여 플랫폼 할당량을 준수하세요.

실제 문제 시나리오

스타벅스는 주문이 준비되면 고객에게 알리고, 바리스타 워크플로우 단계를 안정적으로 처리하며, 사전 예방적 유지보수를 위해 장비 텔레메트리를 분석해야 하는 글로벌 모바일 주문 경험을 출시하고 있습니다.

Event Grid로 이벤트 기반 주문 라이프사이클 연결

사용자 지정 Event Grid 토픽 OrderEvents를 생성하고 OrderPlaced, PaymentAuthorized, OrderReady와 같은 개별 도메인 이벤트를 게시합니다. /stores/{storeId}/orders/{orderId}와 같은 주체 경로를 사용하여 저장소별 접두사 필터링을 활성화합니다. 구독을 구성합니다: 하나는 워크플로우 처리를 위한 Service Bus 토픽으로, 다른 하나는 경량 보강을 위한 Azure Function으로 연결합니다. Event Grid는 낮은 지연 시간의 팬아웃, 스키마 정규화(CloudEvents), 그리고 불필요한 다운스트림 호출을 방지하는 효율적인 필터링을 위해 선택되었습니다.

Service Bus 토픽과 세션으로 바리스타 워크플로우 조정

처리 단계(준비, 전달)별 구독이 있는 Service Bus 토픽 Orders를 정의하고, 각 구독에는 eventType에 대한 상관 관계 또는 SQL 필터를 적용합니다. 주문별 FIFO를 보장하기 위해 SessionId = {orderId}를 사용하여 명령을 메시지로 게시합니다. 소비자는 자동 잠금 갱신 기능이 있는 PeekLock을 사용하고 성공 시 완료(Complete)합니다. 일시적인 실패 시에는 포기(Abandon)하여 재시도를 트리거하고, 영구적인 실패나 포이즌 메시지의 경우 최대 배달 횟수에 도달하면 나중에 검사할 수 있도록 DLQ로 이동시킵니다. 단계별 메시지에 TTL을 설정하여 매장 마감 후 오래된 작업이 처리되는 것을 방지합니다. Service Bus는 순서가 보장되는 안정적인 명령 처리, 풍부한 정산 기능, 규칙 기반 pub/sub을 위해 선택되었습니다.

Event Hubs로 장비 텔레메트리 수집 및 보관

deviceId별로 병렬화할 수 있도록 충분한 파티션이 있는 Event Hub Telemetry를 프로비저닝하고, 피크를 흡수하기 위해 TU 자동 확장을 활성화합니다. 디바이스 게이트웨이는 AMQP-over-WebSockets를 통해 전송하여 기업 프록시를 효율적으로 통과합니다. Blob Storage 체크포인팅과 함께 EventProcessorClient를 사용하여 거의 실시간으로 이상 감지 및 경고를 실행합니다. Synapse에서 오프라인 분석을 지원하는 변경 불가능한 Avro 아카이브를 위해 ADLS Gen2로 캡처 기능을 활성화합니다. Event Hubs는 영구 오프셋과 쉬운 콜드 경로 내보내기 기능을 갖춘 지속적인 고처리량 수집을 위해 선택되었습니다.

Notification Hubs로 타겟 푸시 알림 전송

설치(Installation) 모델을 사용하여 모바일 디바이스를 등록하고, 각 디바이스에 user:{userId}, store:{storeId} 및 플랫폼 태그를 지정합니다. iOS용 APNs 토큰 자격 증명과 Android용 FCM 서비스 계정을 업로드합니다. 개발 및 프로덕션 허브를 분리하여 자격 증명과 피드백을 격리합니다. OrderReady 이벤트가 도착하면 Azure Function은 user:{userId} AND store:{storeId} 태그를 대상으로 하는 단일 템플릿 알림을 Notification Hubs로 보냅니다. Notification Hubs는 플랫폼에 구애받지 않는 라우팅, 태그 식, 글로벌 규모의 중앙 집중식 자격 증명 관리를 위해 선택되었습니다.

관찰 가능성 및 복원력 보장

배달할 수 없는 이벤트를 감사 및 재생을 위해 보관하도록 Event Grid 배달 못한 편지 처리를 Blob 컨테이너로 구성합니다. Service Bus DLQ를 모니터링하고, 수정된 메시지를 분류하고 재큐(requeue)하는 운영자 워크플로우를 노출합니다. 메트릭을 통해 Event Hubs 소비자 지연을 추적하여 체크포인팅을 검증하고 백로그가 증가할 때 프로세서를 스케일 아웃합니다. 이 조합은 엔드투엔드 내구성을 제공합니다. 즉, 정상 경로(happy path)를 빠르고 비용 효율적으로 유지하면서 예외적인 상황에 대한 재생 경로를 통해 최소 한 번 이상 배달을 보장합니다.

이 아키텍처는 관심사를 명확하게 분리합니다. Event Grid는 반응형 오케스트레이션을 주도하고, Service Bus는 워크플로우의 정확성과 순서를 보장하며, Event Hubs는 대규모의 지속적인 텔레메트리를 처리하고, Notification Hubs는 최소한의 백엔드 복잡성으로 정확하고 플랫폼에 특화된 고객 알림을 전달합니다.

← Azure API 관리 · 모든 도메인 · Azure 캐싱 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →