편집

다음을 통해 공유


메시지 브로커 및 이벤트를 사용하여 엔터프라이즈 시스템 통합

Azure Event Grid
Azure Service Bus

이 아키텍처는 기본 엔터프라이즈 통합 아키텍처를 기반으로 하지만 엔터프라이즈 백 엔드 시스템을 통합하는 방법을 포함합니다. 이 아키텍처는 메시지 브로커 및 이벤트를 사용하여 확장성과 안정성을 높이기 위해 서비스를 분리합니다. 기본 통합 아키텍처의 디자인 및 구성 요소에 대해 잘 알고 있는지 확인합니다. 이러한 요소는 이 아키텍처의 핵심 구성 요소에 대한 기본 정보를 제공합니다.

아키텍처

이 디자인에서 참조하는 백 엔드 시스템에는 SaaS(Software as a Service) 시스템, Azure 서비스, 메시지 기반 서비스 및 엔터프라이즈의 기존 웹 서비스가 포함됩니다.

큐 및 이벤트를 사용하는 엔터프라이즈 통합에 대한 참조 아키텍처를 보여 주는 다이어그램

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

시나리오 정보

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

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

이 아키텍처는 백 엔드 서비스에 대한 직접 동기 호출을 만드는 대신 메시지 브로커를 통해 비동기 통신을 사용합니다. 비동기 통신은 다음과 같은 이점을 제공합니다.

폴링 또는 예약된 작업에 의존하지 않고 시스템의 다양한 구성 요소가 이벤트가 발생할 때 반응할 수 있도록 Event Grid를 사용합니다. 메시지 큐 및 토픽과 마찬가지로 Event Grid는 애플리케이션과 서비스를 분리하는 데 도움이 됩니다. 애플리케이션 또는 서비스에서 이벤트를 게시하는 경우 관심 있는 구독자에게 알림이 표시됩니다. 발신자를 업데이트하지 않고 새 구독자를 추가할 수 있습니다.

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

권장 사항

다음 권장 사항을 고려합니다. 자세한 권장 사항은 기본 엔터프라이즈 통합 아키텍처를 참조 하세요.

Service Bus

Service Bus에는 끌어오기 모델과 프록시된 푸시 모델이라는 두 가지 배달 모델이 있습니다.

  • 끌어오기 모델: 수신자가 새 메시지를 지속적으로 폴링합니다. 여러 큐 및 폴링 시간을 관리해야 하는 경우 폴링이 비효율적일 수 있습니다. 그러나 이 모델은 추가 구성 요소 및 데이터 홉을 제거하므로 아키텍처를 간소화할 수 있습니다.

  • 프록시 푸시 모델: 수신기는 처음에 Event Grid 토픽의 특정 이벤트 유형을 구독합니다. 새 메시지를 사용할 수 있는 경우 Service Bus는 Event Grid를 통해 이벤트를 발생시키고 보냅니다. 그런 다음, 이 이벤트는 수신기를 트리거하여 Service Bus에서 메시지의 다음 일괄 처리를 가져옵니다. 이 모델을 사용하면 시스템에서 거의 실시간으로 메시지를 수신할 수 있지만 리소스를 사용하지 않고도 새 메시지를 지속적으로 폴링할 수 있습니다. 이 아키텍처는 배포, 관리 및 보호해야 하는 추가 구성 요소를 사용합니다.

Service Bus 메시지를 사용하는 Standard Logic Apps 워크플로를 만들 때 Service Bus 기본 제공 커넥터 트리거를 사용하는 것이 좋습니다. 기본 제공 커넥터는 추가 비용을 추가하지 않고 대부분의 끌어오기 모델 구성을 추상화합니다. 이 기능은 커넥터가 Logic Apps 런타임 엔진 내에서 지속적으로 반복되므로 비용, 노출 영역 관리 및 보안 간의 적절한 균형을 제공합니다. 자세한 내용은 Service Bus 기본 제공 커넥터 트리거를 참조 하세요.

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

Event Grid

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

고려 사항

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

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성에 대한 디자인 검토 검사 목록을 참조하세요.

  • Microsoft Entra ID 는 전역적으로 분산되고 고가용성 SaaS 플랫폼입니다.

  • 비즈니스 요구 사항 및 비용 허용 오차에 따라 여러 고가용성 구성에서 API Management를 배포할 수 있습니다. 자세한 내용은 API Management 가용성 및 안정성을 확인하세요.

  • Logic Apps 소비 계층은 지역 중복 스토리지를 지원합니다. 자세한 내용은 Logic Apps에 대한 비즈니스 연속성 및 재해 복구를 참조 하세요.

  • 토픽, 시스템 토픽, 도메인 및 이벤트 구독 및 이벤트 데이터에 대한 Event Grid 리소스 정의는 지역의 가용성 영역에서 자동으로 복제 됩니다 . 가용성 영역 중 하나에 장애가 발생하면 Event Grid 리소스는 사용자의 개입 없이 다른 가용성 영역으로 자동으로 장애 조치(failover)합니다. 자세한 내용은 지역 간 재해 복구 및 비즈니스 연속성을 참조하세요.

  • Service Bus Premium은 지역 재해 복구가용성 영역을 지원합니다. Service Bus Standard는 복제를 지원합니다.

각 서비스의 보장된 가용성 세부 정보에 대한 자세한 내용은 온라인 서비스 SLA를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안성에 대한 디자인 검토 검사 목록을 참조하세요.

Service Bus를 보호하려면 Microsoft Entra 인증을 관리 ID와 페어링합니다. Service Bus 리소스에 대한 Microsoft Entra ID 통합은 리소스에 대한 클라이언트의 액세스를 세밀하게 제어하기 위한 Azure RBAC(역할 기반 액세스 제어)를 제공합니다. Azure RBAC를 사용하여 사용자, 그룹 또는 애플리케이션 서비스 주체와 같은 보안 주체에 권한을 부여할 수 있습니다. 이 시나리오의 애플리케이션 서비스 주체는 관리 ID입니다.

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

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

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

네트워크 보안

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

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화를 위한 디자인 검토 검사 목록을 참조하세요.

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

API Management

모든 API Management 인스턴스가 실행되면 요금이 청구됩니다. 강화한 다음 더 이상 해당 수준의 성능이 필요하지 않은 경우 수동으로 스케일 다운하거나 자동 크기 조정을 구성합니다.

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

Logic Apps

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

Service Bus 큐, 토픽 및 구독

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

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

Event Grid

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

자세한 내용은 Event Grid 가격 책정잘 설계된 프레임워크 비용 최적화를 참조하세요.

운영 효율성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 Operational Excellence에 대한 디자인 검토 검사 목록을 참조하세요.

기본 엔터프라이즈 통합 참조 아키텍처는 잘 설계된 프레임워크 운영 우수성 기둥에 부합하는 DevOps 패턴에 대한 지침을 제공합니다.

복구 작업을 최대한 자동화하여 운영 우수성을 향상시킵니다. 자동화를 염두에 두고 Azure 로그 모니터링을 Azure Automation결합하여 Service Bus 리소스의 장애 조치(failover)를 자동화할 수 있습니다. 장애 조치(failover)를 시작하는 자동화 논리의 예는 장애 조치 흐름을 참조 하세요.

성능 효율성

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

확장성을 높이기 위해 Service Bus 프리미엄 계층에서 메시징 단위 수를 확장할 수 있습니다. 자세한 내용은 Service Bus 프리미엄 및 표준 메시징 계층자동 크기 조정 기능을 참조하세요.

Service Bus 권장 사항에 대한 자세한 내용은 Service Bus 메시징을 사용하여 성능 향상에 대한 모범 사례를 참조 하세요.

다음 단계