Microsoft AZ-305: 통합 및 메시징 아키텍처 — 학습 가이드

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

개요

Azure의 통합 및 메시징 아키텍처는 명령, 이벤트, 데이터 이동 시맨틱에 적합한 서비스를 선택하고, 안정성, 순서, 확장성을 고려하여 설계하며, 하이브리드 시스템을 안전하게 통합하는 것이 핵심입니다. 핵심 구성 요소에는 풍부한 기능을 갖춘 브로커를 통한 엔터프라이즈 메시징을 위한 Azure Service Bus, 반응형 이벤트 라우팅을 위한 Azure Event Grid, 대규모 처리량의 스트리밍 수집을 위한 Azure Event Hubs, 간단한 큐잉을 위한 Storage Queues가 포함됩니다. 이를 보완하는 서비스로는 프로세스 자동화를 위한 Azure Logic Apps, 거버넌스 및 개발자 경험을 위한 API Management, ETL/ELT를 위한 Azure Data Factory, 방화벽 친화적인 온프레미스 연결을 위한 Azure Relay, 모바일 푸시를 위한 Azure Notification Hubs가 있습니다. 좋은 설계는 작업에 적합한 서비스를 사용하고, 계약과 장애 모드를 명시적으로 모델링하며, 적절한 경우 오케스트레이션 또는 코레오그래피 패턴을 적용합니다.

Azure의 메시징 및 이벤트 처리

Azure Service Bus는 순서 보장 전달, 트랜잭션, 그룹 내 FIFO, 배달 못한 편지 처리가 필요한 명령 및 워크플로를 위한 엔터프라이즈 브로커입니다. 큐는 하나의 생산자와 하나의 경쟁적 소비자 그룹 간에 지점 간 메시징을 제공합니다. 토픽은 SQL과 유사한 필터 및 작업을 사용하여 메시지를 필터링하고 라우팅할 수 있는 여러 독립적인 구독을 통해 게시/구독(pub/sub)을 지원합니다. 메시지 세션은 sessionId 하에 관련 메시지를 그룹화하여 그룹별 FIFO 및 상태 기반 처리를 가능하게 합니다. 세션 잠금은 한 번에 하나의 소비자만 세션을 처리하도록 보장합니다. 배달 못한 편지 큐는 최대 전달 횟수를 초과하거나, TTL이 만료되거나, 명시적으로 배달 못한 편지로 처리될 때 포이즌 메시지를 캡처하여 격리 및 추후 검사를 가능하게 합니다. 각 큐 또는 구독에는 $DeadLetterQueue 하위 큐가 있습니다. 트랜잭션은 동일한 네임스페이스 내의 엔터티 전반에 걸쳐 원자적인 전송/수신/완료 작업을 허용하여, 예를 들어 후속 메시지가 성공적으로 전송된 경우에만 메시지가 완료되도록 보장합니다(send-via는 엔터티 간 워크플로를 지원합니다).

Azure Event Grid는 반응형, 푸시 기반 패턴을 위한 완전 관리형 이벤트 라우터입니다. 네이티브 Event Grid 스키마 또는 CloudEvents 1.0을 사용합니다. 이벤트 구독은 Functions, Logic Apps, Service Bus, Event Hubs, WebHooks, Storage Queues와 같은 엔드포인트를 대상으로 하며, 제목 및 고급 필터를 사용하여 노이즈를 줄입니다. 지수 백오프를 사용하여 전달이 재시도됩니다. 구독은 구성 가능한 재시도 정책(최대 전달 시도 횟수 및 이벤트 TTL)을 지원하며, 전달할 수 없는 이벤트는 Storage 계정으로 배달 못한 편지 처리할 수 있습니다. 핸드셰이크 유효성 검사는 WebHook 엔드포인트를 보호하고, 관리 ID는 Azure 엔드포인트로의 게시 및 전달을 단순화합니다.

Azure Event Hubs는 분할된 로그를 사용하여 대규모로 원격 측정 및 스트리밍 데이터를 수집합니다. 파티션은 파티션 내에서 병렬 처리와 순서 보장을 제공합니다. 관련 이벤트의 순서를 유지하려면 파티션 키를 선택해야 합니다. 파티션 수는 확장성을 결정하며 생성 후에는 줄일 수 없으므로, 미래의 처리량을 고려하여 크기를 정해야 합니다. 소비자 그룹은 서로의 오프셋에 영향을 주지 않으면서 여러 다른 애플리케이션을 위해 이벤트 스트림에 대한 독립적인 뷰를 제공합니다. Capture 기능은 시간/크기 창을 기반으로 거의 실시간으로 데이터를 Azure Blob Storage 또는 Data Lake Storage에 영구적으로 오프로드하며, 일반적으로 Avro 형식을 사용합니다. 이를 통해 수집에 영향을 주지 않으면서 배치 분석을 수행할 수 있습니다. 내장된 Schema Registry는 버전 관리 및 호환성 정책과 함께 Avro/JSON 스키마를 저장하여, 생산자와 소비자가 계약을 안전하게 검증하고 발전시킬 수 있도록 합니다.

Storage Queues는 비표시 시간 제한과 메시지 TTL 및 애플리케이션 관리 포이즌 처리를 통한 기본 배달 못한 편지 처리 기능을 갖춘, 간단하고 비용 효율적인 최소 한 번 전달을 제공합니다. 트랜잭션, 세션, 고급 라우팅 기능은 없지만, 기본 분리 및 저비용의 대규모 팬아웃에 탁월합니다.

언제 어떤 것을 선택해야 하는가:

FIFO(세션을 통해), 트랜잭션, 지연, 중복 탐지, 배달 못한 편지 감사가 필요한 명령, 워크플로, 통합 시나리오에는 Service Bus를 사용합니다.
세분화된 필터링과 거의 실시간 반응이 필요한 Azure 서비스 또는 사용자 지정 앱의 경량 푸시 기반 팬아웃 알림에는 Event Grid를 사용합니다.
독립적인 소비자와 다운스트림 분석이 필요한 대규모 처리량의 스트리밍 원격 측정 및 로그 수집에는 Event Hubs를 사용합니다.
고급 브로커 기능이 불필요하고 비용 단순성이 가장 중요한 간단한 생산자/소비자 분리에는 Storage Queues를 사용합니다.

통합, API 및 하이브리드 연결

Azure Logic Apps는 수백 개의 커넥터를 사용하여 관리형 워크플로 자동화를 제공합니다. 소비(다중 테넌트) 플랜에서는 자동 확장 및 다중 테넌트 커넥터를 사용하며 작업당 요금을 지불하므로, 폭증하는(bursty) 사용량에 이상적입니다. 표준(단일 테넌트) 플랜은 Functions 런타임에서 실행되며, 상태 저장/상태 비저장 워크플로, 더 높은 처리량, 사용자 지정 커넥터 및 인프로세스(in-process)로 실행되는 기본 제공 커넥터, 컨테이너화, 로컬 개발, VNET/프라이빗 엔드포인트 통합을 지원합니다. 이는 엔터프라이즈 수준의 격리 및 예측 가능한 용량에 이상적입니다. ISE(Integration Service Environment)는 프라이빗 네트워킹 및 데이터 지역성을 위한 레거시 전용 스탬프입니다. 새로운 설계에서는 일반적으로 VNET 통합을 사용하는 Logic Apps 표준 플랜이나 App Service Environment v3로의 배포를 선호합니다.

Azure API Management(APIM)는 API 위에 추상화 및 거버넌스 계층을 제공합니다. 정책은 인바운드, 백엔드, 아웃바운드 단계에 적용되어 validate-jwt, rate-limit-by-key, quota, set-header, retry, cache-lookup/store, 동적 라우팅을 위한 set-backend-service와 같은 횡단 관심사(cross-cutting concerns)를 강제합니다. 제품(Product)은 하나 이상의 API를 그룹화하고 정책 동작을 번들로 묶으며, 특정 그룹에 게시할 수 있습니다. 구독(Subscription)은 소비자별 또는 제품별로 키를 발급하여 액세스를 측정하고 제어합니다. 키는 교체(rotate)할 수 있으며 할당량에 연결할 수 있습니다. 개발자 포털은 셀프서비스 검색, 문서화, 테스트(try-it), 온보딩 워크플로를 지원하며, 자체 호스팅 게이트웨이는 온프레미스나 다른 클라우드를 위한 하이브리드 컨트롤 플레인/에지 배포를 가능하게 합니다.

Azure Relay는 인바운드 방화벽 포트를 열지 않고도 온프레미스 서비스에 대한 인바운드 연결을 가능하게 합니다. 하이브리드 연결(Hybrid Connections)은 TLS 443을 통한 WebSockets를 사용하여 범용 양방향 소켓 통신을 제공합니다. 이 통신은 온프레미스에서 아웃바운드로 시작되고 클라이언트에서 Relay로 연결되며, WebSockets를 통해 캡슐화된 HTTP 및 임의의 프로토콜에 유용합니다. WCF Relay는 전송 또는 메시지 수준 보안 및 클레임 기반 액세스를 통해 온프레미스 WCF 엔드포인트(NetTcp/HTTP)를 릴레이를 통해 노출합니다. 이는 안전하고 방화벽 친화적인 노출이 필요한 기존 WCF 서비스에 이상적입니다.

Azure Notification Hubs는 플랫폼 알림 시스템(PNS)(iOS용 APNs, Android용 FCM, Windows용 WNS, Amazon용 ADM)을 추상화하는 크로스 플랫폼 푸시 브로커입니다. 백엔드는 태그와 템플릿을 사용하여 디바이스 또는 설치를 등록하여 대규모로 알림을 타겟팅하고 개인화합니다. PNS별로 플랫폼 자격 증명이 필요합니다: APNs p8 키 또는 인증서, FCM 서버 키/자격 증명, WNS 패키지 SID/비밀 키. Notification Hubs는 팬아웃, 제한(throttling), 토큰 관리를 처리하므로 애플리케이션 코드는 PNS에 종속되지 않은 상태를 유지할 수 있습니다.

데이터 이동 및 스트리밍 분석

Azure Data Factory(ADF)는 하이브리드 환경 전반의 데이터 통합을 오케스트레이션합니다. 통합 런타임(IR)은 작업을 위한 컴퓨팅을 호스팅합니다. Azure IR은 Azure 내에서 서버리스 복사 및 데이터 흐름을 위한 것이고, Self-hosted IR은 인바운드 포트를 열지 않고 프라이빗 네트워크 내에서 데이터 이동/컴퓨팅을 위한 것이며, Azure-SSIS IR은 SSIS 패키지를 관리형 클러스터로 리프트 앤 시프트(lift-and-shift)하기 위한 것입니다. 파이프라인은 제어 흐름(종속성, 루프, 분기, 트리거)과 재사용을 위한 매개 변수화를 통해 작업을 오케스트레이션합니다. 매핑 데이터 흐름(Mapping Data Flows)은 스키마 드리프트 처리 및 파티셔닝 제어 기능을 갖춘 코드 없는 Spark 기반 변환을 대규모로 제공합니다. 변환이 복잡하지만 관리형 컴퓨팅을 원할 때 사용합니다. 연결된 서비스(Linked service)는 원본, 싱크, 컴퓨팅에 대한 연결 메타데이터와 자격 증명을 정의합니다. 데이터 세트와 데이터 흐름 원본/싱크는 이를 참조하여 안전한 재사용과 RBAC를 가능하게 합니다.

Event Hubs는 Capture 기능을 통해 영구 스토리지에 데이터를 저장하여 분석 서비스와 통합되며, 이후 Azure Synapse나 Databricks에서 Avro 파일을 마이크로 배치로 처리할 수 있습니다. Schema Registry는 계약(contract)을 중앙 집중화하여 스트리밍 작업에서의 역직렬화와 스키마 진화를 단순화하고, 생산자와 소비자 간의 깨지기 쉬운 암시적 타이핑을 방지합니다.

안정성 및 이벤트 기반 패턴

안정성을 위한 설계는 명시적인 장애 처리에서 시작됩니다. Service Bus는 엔터티별로 데드-레터 큐(DLQ)를 제공합니다. 소비자는 DLQ를 모니터링하고 분류해야 하며, 선택적으로 분석 큐로 자동 전달할 수 있습니다. 중복 처리를 방지하려면 중복 검색 및 멱등성 핸들러를 사용하십시오. 트랜잭션을 활용하여 수신을 원자적으로 처리하고 아웃박스 메시지를 보내고, 세션을 사용하여 세션 간 확장을 하면서 비즈니스 엔터티별로 순서가 보장된 처리를 수행하십시오. Event Grid의 재시도 정책은 구성 가능한 제한이 있는 지수 백오프를 사용합니다. 감사 가능성을 위해 Storage로 데드-레터링을 구성하고 재생 도구를 구축하십시오. Event Hubs는 최소 한 번 이상 전송을 보장합니다. SDK(또는 Azure Functions 트리거)를 통한 체크포인팅은 파티션/소비자 그룹별 진행 상황 추적을 보장합니다. Storage Queues는 사용자가 명시적으로 구현하는 표시 제한 시간 및 포이즌 메시지 패턴에 의존합니다.

이벤트 기반 아키텍처는 일반적으로 코레오그래피 또는 오케스트레이션을 사용합니다. 코레오그래피는 동료 서비스의 이벤트에 반응하는 서비스들 간에 조정을 분산시킵니다. 이는 느슨하게 결합되어 있고 확장 가능하며 부분적인 장애에 대한 복원력이 있지만, 시각화하고 관리하기 어려워질 수 있으며 보상 트랜잭션이 분산됩니다. 오케스트레이션은 Azure Durable Functions, Logic Apps 또는 워크플로 엔진과 같은 오케스트레이터에서 흐름 제어를 중앙 집중화하여, 오케스트레이터와의 더 긴밀한 결합을 대가로 관찰 가능성, 시간 초과/보상 로직, 사람의 개입이 필요한 단계를 개선합니다. 사가 패턴은 2단계 커밋 대신 보상 작업을 사용하여 장기 실행, 다단계 트랜잭션을 구현합니다. 코레오그래피에서는 각 서비스가 도메인 이벤트를 수신하고 필요에 따라 보상 트랜잭션을 내보냅니다. 오케스트레이션에서는 오케스트레이터가 활동을 호출하고 실패 또는 시간 초과 시 보상 트랜잭션을 트리거합니다. Azure에서는 안정적인 명령 전달을 위해 Service Bus와 함께 Durable Functions(상태 저장 오케스트레이션, 재시도, 시간 초과, 보상 패턴)를 사용하거나, 견고한 엔터프라이즈 워크플로 및 기본 제공 커넥터를 위해 Logic Apps Standard를 사용하여 사가를 구현합니다.

실제 문제 시나리오

Contoso Retail은 온프레미스 ERP, 전자 상거래 사이트, 모바일 앱, 다운스트림 분석 전반에 걸쳐 주문 처리를 현대화합니다. 이 솔루션은 파트너 알림, 실시간 원격 분석, 보안 온프레미스 액세스, 모바일 푸시를 지원해야 하며, 결제 및 재고에 대한 엄격한 순서 보장과 보상 트랜잭션이 필요합니다.

수집 및 명령 워크플로

주문 명령에 Azure Service Bus 토픽을 사용합니다. 구독을 통해 처리(결제, 재고, 배송)를 분할합니다. OrderId를 키로 하는 메시지 세션을 활성화하여 주문별 FIFO 및 단일 동시성을 보장합니다. 근거: Service Bus는 순서가 보장되고 안정적인 비즈니스 워크플로에 필요한 세션, 트랜잭션, 데드-레터링을 제공합니다.

오케스트레이션 및 보상 트랜잭션

Azure Durable Functions로 사가를 구현합니다. 활동(Activity)은 결제 게이트웨이를 호출하고, 재고를 예약하며, 배송을 생성합니다. 보상 트랜잭션은 실패 시 환불하거나 재고를 복원합니다. 트랜잭션 범위 내에서 Service Bus 트리거와 출력을 사용하여 수신 메시지를 원자적으로 완료하고 후속 조치를 게시합니다. 근거: 중앙 집중식 오케스트레이션은 브로커의 안정성을 유지하면서 시간 초과, 재시도, 보상 트랜잭션을 단순화합니다.

이벤트 기반 알림

OrderPlaced, OrderShipped와 같은 도메인 이벤트를 Azure Event Grid 사용자 지정 토픽에 게시합니다. 파트너 및 내부 앱은 제목 접두사 필터를 사용하여 구독합니다. Storage 계정으로의 데드-레터링과 시도 횟수가 제한된 재시도 정책을 구성합니다. 근거: Event Grid는 광범위한 팬아웃(fan-out)을 위해 세분화된 필터링과 데드-레터 감사를 포함한 저지연 푸시를 제공합니다.

원격 분석 스트리밍 및 분석

클릭스트림 및 앱 원격 분석 데이터를 사용자 세션을 키로 하는 8개의 파티션이 있는 Azure Event Hubs로 보냅니다. 5분 또는 100MB마다 Data Lake Storage로 Capture를 활성화합니다. Schema Registry에 Avro 스키마를 등록하고 스키마 호환성을 강제합니다. 근거: Event Hubs는 소비자로부터 독립적으로 수집 규모를 조정하고, Capture는 분석을 분리하며, Schema Registry는 계약 규율을 유지합니다.

데이터 통합

온프레미스에 설치된 Self-hosted Integration Runtime과 함께 Azure Data Factory를 사용하여 ERP 데이터를 안전하게 추출하고, Azure IR을 사용하여 큐레이션된 데이터를 Synapse에 저장합니다. Event Hubs Capture 파일로 SCD 처리 및 보강을 위한 파이프라인과 매핑 데이터 흐름을 구축합니다. 근거: ADF는 연결된 서비스(linked services)를 통해 관리형 컴퓨팅 및 통제된 연결을 사용하여 하이브리드 데이터 이동 및 변환을 오케스트레이션합니다.

API 및 파트너 거버넌스

모든 파트너 대상 엔드포인트를 Azure API Management 앞에 배치합니다. 주문 상태 및 웹훅 등록 API를 노출합니다. 정책 적용: 파트너가 발급한 토큰에 대한 validate-jwt, 더 엄격한 파트너 스로틀링을 위한 rate-limit-by-key, 코드 변경 없이 기존 Logic Apps로 라우팅하기 위한 rewrite/set-backend-service. 구독과 키가 필요한 파트너를 위해 제품을 게시하고, 개발자 포털을 통해 온보딩합니다. 근거: APIM은 백엔드 로직을 건드리지 않고 보안, 스로틀링을 강제하고 셀프서비스 온보딩을 제공합니다.

워크플로 자동화 및 커넥터

백오피스 자동화(예: 이메일 전송, Dynamics 업데이트)를 위해 기본 제공 커넥터와 VNET 통합 기능이 있는 Azure Logic Apps Standard를 사용합니다. 근거: 단일 테넌트 성능, 프라이빗 연결, 엔터프라이즈급 커넥터는 SaaS 및 기간 업무(LOB) 앱과의 통합을 단순화합니다.

하이브리드 연결

기존 WCF 엔드포인트에는 Azure Relay WCF Relay를, 경량 HTTP/WebSocket 애플리케이션에는 Hybrid Connections를 통해 선택적인 온프레미스 ERP 서비스를 노출하여 인바운드 방화벽 변경을 피합니다. 근거: Relay는 VPN의 복잡성 없이 안전한 아웃바운드 시작 연결을 제공합니다.

모바일 푸시

Azure Notification Hubs를 통해 배송 업데이트를 보내고, 태그를 사용하여 디바이스/사용자를 분류하고 템플릿을 사용하여 현지화합니다. APNs 토큰 자격 증명과 FCM 키를 구성합니다. 근거: Notification Hubs는 PNS(플랫폼 알림 서비스) 간의 차이점을 추상화하고 푸시 전송을 확장합니다.

이 설계는 각 요구 사항을 특정 목적에 맞게 구축된 서비스에 매핑합니다: 안정적인 명령을 위한 Service Bus, 오케스트레이션된 사가를 위한 Durable Functions, 푸시 알림을 위한 Event Grid, 스트리밍 분석을 위한 Event Hubs + Capture + Schema Registry, 하이브리드 ETL/ELT를 위한 ADF, 거버넌스를 위한 APIM, 엔터프라이즈 자동화를 위한 Logic Apps, 온프레미스 액세스를 위한 Relay, 모바일 참여를 위한 Notification Hubs.

← 보안 아키텍처 및 제로 트러스트 · 모든 도메인 · 모니터링 →

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