편집

다음을 통해 공유


메시지 broker 및 이벤트를 사용한 엔터프라이즈 통합

Azure Event Grid
Azure Service Bus

이 예제 아키텍처는 기본 엔터프라이즈 통합 아키텍처를 기반으로 빌드됩니다. 스케일링 성능과 안정성을 높이기 위해 서비스를 분리하는 데 메시지 브로커 및 이벤트를 사용하여 엔터프라이즈 백 엔드 시스템을 통합하는 방법을 보여 주기 위해 해당 아키텍처를 확장합니다. 기본 통합 아키텍처에서 사용되는 해당 디자인과 구성 요소에 대해 잘 알고 있어야 합니다. 이 아키텍처의 핵심 구성 요소에 대한 기본 정보를 제공하며 여기서는 재현되지 않습니다.

아키텍처

이 디자인에서 참조되는 백 엔드 시스템에는 SaaS(Software as a Service) 시스템, Azure 서비스 및 기업의 기존 웹 서비스가 포함될 수 있습니다.

큐 및 이벤트를 사용한 엔터프라이즈 통합에 대한 참조 아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

여기에 표시된 아키텍처는 기본 엔터프라이즈 통합에 표시된 더 단순한 아키첵처를 기반으로 합니다. 이 아키텍처는 Logic Apps를 사용하여 백 엔드 시스템에서 직접 워크플로를 오케스트레이션하고 API Management를 사용하여 API 카탈로그를 만듭니다.

이 버전의 아키텍처는 시스템의 안정성과 확장성을 높이는 데 도움이 되는 두 구성요소를 추가합니다.

메시지 브로커를 사용하는 비동기 통신은 백 엔드 서비스에 대한 직접적인 비동기 호출에 비해 다음 이점을 제공합니다.

  • 큐 기반 부하 평준화 패턴을 사용하여 워크로드 급증을 처리하는 부하 평준화를 제공합니다.
  • 게시자-구독자 패턴을 사용하여 여러 소비자에게 메시지 브로드캐스트를 제공합니다.
  • 여러 단계 또는 여러 애플리케이션과 관련된 장기 실행 워크플로의 진행률을 안정적으로 추적합니다.
  • 애플리케이션을 분리하는 데 도움이 됩니다.
  • 기존 메시지 기반 시스템과 통합됩니다.
  • 백 엔드 시스템을 사용할 수 없을 때 작업을 큐에 추가할 수 있습니다.

Event Grid는 폴링 또는 예약된 작업에 의존하기보다는 시스템의 다양한 구성 요소가 발생하는 이벤트에 대응하도록 지원합니다. 메시지 큐 및 토픽과 마찬가지로 애플리케이션 및 서비스를 분리하는 데 도움이 됩니다. 애플리케이션 또는 서비스는 이벤트를 게시할 수 있으며, 관련 구독자에게 알림이 전송됩니다. 보낸 사람을 업데이트하지 않고 새 구독자를 추가할 수 있습니다.

여러 Azure 서비스는 Event Grid로 이벤트 보내기를 지원합니다. 예를 들어 논리 앱은 BLOB 저장소에 새 파일이 추가되면 이벤트를 수신 대기할 수 있습니다. 이 패턴은 파일 업데이트 또는 큐에 메시지 추가로 인해 일련의 프로세스가 시작될 때 이에 대응하는 워크플로를 구현합니다. 이 프로세스는 특정 순서대로 또는 병렬로 실행될 수 있습니다.

권장 사항

기본 엔터프라이즈 통합에 설명된 권장 사항이 이 아키텍처에 적용됩니다.

Service Bus

Service Bus에는 풀 또는 프록시된 푸시라는 두 가지 배달 모드가 있습니다. 끌어오기 모델에서는 수신기가 새 메시지를 지속적으로 폴링합니다. 폴링은 비효율적일 수 있습니다. 여러 큐가 각각 소량의 메시지를 수신하거나 메시지 수신 간격이 긴 경우에 특히 그렇습니다. 프록시된 푸시 모델에서는 새 메시지가 있을 때 Service Bus가 Event Grid를 통해 이벤트를 보냅니다. 수신기는 이벤트를 구독합니다. 이벤트가 트리거되면 수신기가 Service Bus에서 메시지의 다음 배치를 끌어옵니다.

Service Bus 메시지를 사용하는 논리 앱을 만들 때는 Event Grid 통합을 통해 프록시된 푸시 모델을 사용하는 것이 좋습니다. 논리 앱이 Service Bus를 폴링할 필요가 없으므로 보다 비용 효율적인 경우가 많습니다. 자세한 내용은 Azure Service Bus-Event Grid 통합 개요를 참조하세요. 현재 Event Grid 알림을 위해서는 Service Bus 프리미엄 등급이 필요합니다.

PeekLock를 사용하여 메시지 그룹에 액세스합니다. PeekLock을 사용하는 경우, 논리 앱은 메시지를 완료하거나 중단하기 전에 각 메시지의 유효성을 검사하는 단계를 수행할 수 있습니다. 이 방법은 실수로 인한 메시지 손실을 방지합니다.

Event Grid

Event Grid 트리거가 실행되면 하나 이상의 이벤트가 발생했다는 의미입니다. 예를 들어 논리 앱이 Service Bus 메시지에 대한 Event Grid 트리거를 가져오면 여러 메시지를 처리할 수 있다고 가정해야 합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

  • Microsoft Entra ID: Microsoft Entra ID는 전역적으로 분산되고 고가용성 SaaS 플랫폼입니다. 보장된 가용성 세부 정보는 SLA를 참조하세요.
  • API Management: 비즈니스 요구 사항과 최대 허용 비용에 따라 여러 고가용성 구성으로 API Management를 배포할 수 있습니다. 옵션에 대한 전체 검토는 API Management 가용성 및 안정성 보장을 참조하세요. 또한 보장된 가용성 세부 정보는 SLA를 참조하세요.
  • Logic Apps: 지역 중복 스토리지는 사용량 플랜 계층의 Logic Apps에 사용할 수 있습니다. 비즈니스 연속성 및 재해 복구 솔루션 디자인에 대한 내용은 참고 자료를 참조하세요. 또한 보장된 가용성 세부 정보는 SLA를 참조하세요.
  • Event Grid: 토픽, 시스템 토픽, 도메인, 이벤트 구독 및 이벤트 데이터에 대한 Event Grid 리소스 정의는 해당 지역의 가용성 영역 3곳(사용 가능한 경우)에 걸쳐 자동으로 복제됩니다. 가용성 영역 중 하나에 장애가 발생하면 Event Grid 리소스는 사용자의 개입 없이 다른 가용성 영역으로 자동으로 장애 조치(failover)합니다. 다른 지역으로 장애 조치하기 위한 재해 복구 솔루션 디자인에 대한 참고 자료는 지역 간 지리적 재해 복구를 참조하세요. 또한 보장된 가용성 세부 정보는 SLA를 참조하세요.
  • Service Bus: Service Bus 프리미엄은 지리적 재해 복구가용성 영역을 지원합니다. 복제는 Service Bus 표준에 사용할 수 있습니다. 또한 보장된 가용성 세부 정보는 SLA를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

Service Bus를 보호하려면 관리 ID와 쌍을 이루는 Microsoft Entra 인증 사용합니다. Service Bus 리소스에 대한 Microsoft Entra 통합은 클라이언트의 리소스 액세스를 세부적으로 제어하기 위해 Azure RBAC(역할 기반 액세스 제어)를 제공합니다. Azure RBAC를 사용하여 사용자, 그룹 또는 애플리케이션 서비스 주체일 수 있는 보안 주체에 권한을 부여할 수 있습니다(이 경우 관리 ID).

Microsoft Entra ID를 사용할 수 없는 경우 SAS(공유 액세스 서명)를 사용할 수 있습니다. SAS 인증을 사용하여 특정 권한으로 Service Bus 리소스에 대한 액세스를 사용자에게 부여할 수 있습니다.

Service Bus 큐 또는 토픽을 HTTP 엔드포인트(예: 새 메시지 게시용)로 노출해야 하는 경우, API Management를 사용하여 큐가 엔드포인트를 향하도록 배치하여 큐를 보호합니다. 그런 다음, 인증서 또는 OAuth 인증을 적절히 사용하여 엔드포인트를 보호할 수 있습니다. 엔드포인트를 보호하는 가장 쉬운 방법은 HTTP 요청/응답 트리거가 있는 논리 앱을 중개자로 사용하는 것입니다.

Event Grid 서비스는 유효성 검사 코드를 통해 이벤트 전달을 보호합니다. Logic Apps를 통해 이벤트를 사용하는 경우, 유효성 검사가 자동으로 수행됩니다. 자세한 내용은 Event Grid 보안 및 인증을 참조하세요.

네트워크 보안

네트워크 보안은 디자인 전체에서 고려해야 합니다.

  • Service Bus 프리미엄은 VNet(가상 네트워크) 서브넷 서비스 엔드포인트에 바인딩되어 권한 있는 가상 네트워크의 트래픽만 허용하도록 네임스페이스를 보호할 수 있습니다. 또한 프라이빗 엔드포인트를 사용하여 Private Link를 통해 프라이빗 트래픽에 대한 VNet 트래픽을 잠급니다.
  • Logic Apps 표준 및 프리미엄 Logic Apps는 프라이빗 엔드포인트를 통해 인바운드 트래픽을 수락하고 VNet 통합을 통해 아웃바운드 트래픽을 보내도록 구성할 수 있습니다.
  • API Management는 Azure 가상 네트워크를 사용하여 API Management 인스턴스 및 API에 대한 액세스를 보호하는 몇 가지 옵션을 제공합니다. 옵션에 대한 철저한 검토는 Azure API Management에서 가상 네트워크 사용 설명서를 참조하세요. 프라이빗 엔드포인트도 지원됩니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

일반적으로 Azure 가격 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 다음과 같습니다.

API Management

실행되고 있는 모든 API Management 인스턴스에 대한 요금이 청구됩니다. 시스템을 스케일 업했는데 해당 성능 수준이 항상 필요한 것은 아닌 경우 수동으로 스케일 다운하거나 자동 스케일링을 구성합니다.

사용 워크로드가 적은 경우 저렴한 서버리스 옵션인 사용량 계층을 고려합니다. 사용량 계층은 API 호출당 요금이 청구되는 반면 다른 계층은 시간당 요금이 청구됩니다.

Logic Apps

Logic Apps는 서버리스 모델을 사용합니다. 청구는 작업 및 커넥터 실행에 따라 계산됩니다. 자세한 내용은 Logic Apps 가격 책정을 참조하세요.

Service Bus 큐, 토픽 및 구독

Service Bus 큐 및 구독은 메시지를 배달하기 위한 프록시된 푸시 및 풀 모델을 모두 지원합니다. 끌어오기 모델에서 모든 폴링 요청은 작업으로 계량됩니다. 30초(기본값)의 긴 폴링이 있더라도 비용이 높을 수 있습니다. 메시지를 실시간으로 배달해야 하는 경우가 아니면 프록시된 푸시 모델을 사용하는 것이 좋습니다.

Service Bus 큐는 모든 계층(기본, 표준 및 프리미엄 계층)에 포함됩니다. Service Bus 토픽 및 구독은 표준 및 프리미엄 계층에서 사용할 수 있습니다. 자세한 내용은 Azure Service Bus 가격 책정을 참조하세요.

Event Grid

Event Grid는 서버리스 모델을 사용합니다. 청구는 작업(이벤트 실행) 수를 기반으로 계산됩니다. 작업에는 도메인 또는 토픽에 대한 이벤트 수신, 고급 일치, 배달 시도 및 관리 호출이 포함됩니다. 최대 100,000개의 작업을 무료로 사용할 수 있습니다.

자세한 내용은 Event Grid 가격을 참조하세요.

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

운영 효율성

기본 엔터프라이즈 통합 참조 아키텍처는 Well-Architected Framework의 운영 우수성 핵심 요소에 맞게 조정된 DevOps 패턴에 대한 참고 자료를 제공합니다.

복구 작업을 최대한 자동화하는 것은 운영 우수성의 필수 구성 요소입니다. 자동화를 고려하여 Azure Log MonitoringAzure Automation과 결합하면 Service Bus 리소스의 장애 조치를 자동화할 수 있습니다. 장애 조치를 시작하는 자동화 논리의 예제는 장애 조치(failover) 흐름 설명서의 다이어그램을 참조하세요.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

확장성을 높이기 위해 Service Bus 프리미엄 계층에서 메시징 단위 수를 확장할 수 있습니다. 프리미엄 계층 혜택에 대한 검토는 Service Bus 프리미엄 및 표준 메시징 계층 설명서를 참조하세요. 또한 메시징 단위의 자동 스케일링을 구성하는 방법에 관해 알아보려면 자동 스케일링 기능 설명서를 참조하세요.

Service Bus에 대한 더 많은 권장 사항은 Service Bus 메시징을 사용하는 성능 향상 모범 사례에서 찾을 수 있습니다.

다음 단계

자세한 내용은 Service Bus 설명서를 참조하세요.