BizTalk Server에서 Azure 통합 서비스로 마이그레이션하는 이유는 무엇인가요?
이 가이드에서는 온-프레미스 BizTalk Server에서 클라우드 기반 Azure 통합 서비스로 마이그레이션을 시작하는 데 도움이 되는 이유와 이점, 제품 비교, 기능 및 기타 정보에 대한 개요를 제공합니다. 이 가이드에 따라 마이그레이션 전략, 계획 고려 사항 및 성공적인 결과를 제공하는 데 도움이 되는 모범 사례와 함께 시나리오에 가장 적합한 서비스를 선택하는 방법을 다루는 더 많은 가이드를 찾을 수 있습니다.
이유 및 이점
통합 워크로드를 Azure 통합 서비스로 마이그레이션하면 다음과 같은 주요 이점을 얻을 수 있습니다.
| 장점 | 설명 |
|---|---|
| 최신 iPaaS(Integration Platform as a Service) | Azure 통합 서비스는 BizTalk Server가 처음 빌드되었을 때 아직 구현되지 않은 기능을 제공합니다. 예를 들면 다음과 같습니다. - REST API를 만들고 관리하는 기능 - 확장 가능한 클라우드 인프라 - 최신의 더 안전하고 구현하기 쉬운 인증 체계 - 여러 웹 브라우저 기반 환경을 포함한 간소화된 개발 도구 - 자동 플랫폼 업데이트 및 다른 클라우드 네이티브 서비스와의 통합 |
| 사용량 기반 가격 책정 | 기존 미들웨어 플랫폼을 사용하면 라이선스 및 인프라 조달에 상당한 자본 투자를 해야 하는 경우가 많아 "최대치를 위한 빌드"를 강요하고 비효율성을 초래합니다. Azure 통합 서비스는 일반적으로 사용한 만큼만 비용을 지불하는 여러 가격 책정 모델을 제공합니다. 일부 가격 책정 모델은 고급 기능을 활성화하고 이에 대한 액세스를 제공하지만 사용량에 대한 비용을 유연하게 지불할 수 있습니다. |
| 진입 장벽 낮추기 | BizTalk Server 매우 유능한 미들웨어 broker이지만 학습하고 숙달하는 데 상당한 시간이 필요합니다. Azure 통합 서비스는 솔루션을 시작, 학습, 빌드 및 제공하는 데 필요한 시간을 줄입니다. 예를 들어 Azure Logic Apps에는 선언적 워크플로를 빌드하기 위한 코드 없음 또는 로우 코드 환경을 제공하는 시각적 디자이너가 포함되어 있습니다. |
| SaaS 연결 | REST API가 애플리케이션 통합의 표준이 되면서 더 많은 SaaS 회사에서 데이터를 교환하기 위해 이 접근 방식을 채택했습니다. Microsoft는 수백 개의 API를 사용하여 광범위하고 지속적으로 성장하는 커넥터 에코시스템을 구축하여 Microsoft 및 비 Microsoft 서비스, 시스템 및 프로토콜과 함께 작동합니다. Azure Logic Apps에서는 워크플로 디자이너를 사용하여 이러한 커넥터에서 작업을 선택하고, 연결을 쉽게 만들고 인증하고, 사용하려는 작업을 구성할 수 있습니다. 이 기능은 개발을 가속화하고 OAuth2를 사용하여 이러한 서비스에 대한 액세스를 인증할 때 더 많은 일관성을 제공합니다. |
| 여러 지리적 배포 | Azure는 현재 다른 클라우드 공급자보다 많은 60개 이상의 공지된 지역을 제공하므로 사용자와 고객에게 적합한 데이터 센터와 지역을 쉽게 선택할 수 있습니다. 이러한 범위를 통해 여러 지역에 걸쳐 일관된 방식으로 솔루션을 배포할 수 있으며 확장성 및 중복성 관점에서 기회를 제공합니다. |
Azure 통합 서비스란?
Azure 통합 서비스에는 포괄적인 통합 솔루션을 만들고 기존 BizTalk Server 솔루션을 마이그레이션할 수 있는 다음과 같은 클라우드 기반, 서버리스, 확장 가능 및 Microsoft 관리형 구성 요소가 포함되어 있습니다.
| 서비스 | 설명 |
|---|---|
| Azure Logic Apps | 앱, 데이터, 서비스 및 시스템을 통합하는 자동화된 논리 앱 워크플로를 만들고 실행합니다. 엔터프라이즈 및 B2B(Business-to-Business) 시나리오를 위한 확장성이 뛰어난 통합 솔루션을 신속하게 개발할 수 있습니다. 시각적 워크플로 디자이너를 사용하여 마이크로 서비스, API 오케스트레이션 및 기간 업무 통합을 사용하도록 설정합니다. 중요 비즈니스용 워크플로를 자동화하면서 확장성과 이식성을 높이려면 Kubernetes가 실행할 수 있는 모든 곳에 배포하고 실행합니다. 사용량 또는 표준 논리 앱 리소스를 만들 수 있습니다. 사용량 논리 앱에는 다중 테넌트 Azure Logic Apps에서 실행되는 상태 저장 워크플로가 하나만 포함됩니다. 표준 논리 앱에는 단일 테넌트 Azure Logic Apps, App Service Environment v3 또는 Azure Arc 지원 Logic Apps에서 실행되는 여러 상태 저장 또는 상태 비저장 워크플로가 포함될 수 있습니다. Azure Integration Services 내에서 Azure Logic Apps를 배치하기 위해 이 가이드에서는 엔터프라이즈 기능, 비용 및 민첩성 간에 최상의 균형을 제공하는 표준 논리 앱에 중점을 둡니다. 자세한 내용은 Azure Logic Apps를 참조하세요. |
| Azure 기능 | 코드를 적게 작성하고, 인프라를 적게 유지 관리하고, 애플리케이션을 실행하는 데 드는 비용을 절감합니다. 서버를 배포하고 유지 관리할 필요 없이 클라우드 인프라는 애플리케이션을 계속 실행하는 데 필요한 모든 최신 리소스를 제공합니다. 자세한 내용은 Azure Functions를 참조하세요. |
| Azure Data Factory | 유지 관리가 필요 없는 90개 이상의 기본 제공 커넥터를 추가 비용 없이 사용하여 모든 데이터 원본을 시각적으로 통합합니다. ETL(추출, 변환 및 로드)을 쉽게 구성하고 ELT(추출, 로드 및 변환)는 직관적인 환경에서 코드 없는 프로세스를 처리하거나 고유한 코드를 작성할 수 있습니다. 비즈니스 인사이트의 잠금을 해제하려면 Azure Synapse Analytics에 통합 데이터를 제공합니다. 자세한 내용은 Azure Data Factory를 참조하세요. |
| Azure Service Bus | 매우 신뢰할 수 있는 이 엔터프라이즈 메시지 broker를 사용하여 오프라인인 경우에도 애플리케이션과 서비스 간에 데이터를 메시지로 전송합니다. 구조화된 FIFO(선입선출) 메시징, 게시-구독 기능 및 비동기 작업을 사용하여 클라이언트와 서버 간에 메시지를 조정하는 경우 유연성을 높일 수 있습니다. 자세한 내용은 Azure Service Bus를 참조하세요. |
| Azure Event Grid | Event Broker에서 제공하는 이벤트를 사용하여 Azure 서비스, 다른 애플리케이션 또는 Event Grid에 네트워크 액세스 권한이 있는 엔드포인트와 같은 구독자 대상에 애플리케이션을 통합합니다. 이벤트 원본에는 다른 애플리케이션, SaaS 서비스 및 Azure 서비스가 포함될 수 있습니다. 자세한 내용은 Azure Event Grid를 참조하세요. |
| Azure API Management | API 게이트웨이를 나란히 배포하고 Azure, 다른 클라우드 및 온-프레미스에서 호스트되는 API를 사용하여 트래픽 흐름을 최적화합니다. 보안 및 규정 준수 요구 사항을 충족하는 동시에 모든 내부 및 외부 API에서 통합 관리 환경과 완전한 가시성을 누릴 수 있습니다. 자세한 내용은 API Management 정책을 참조하세요. |
보완 Azure 서비스
이전에 설명한 서비스 외에도 Microsoft는 Azure 통합 서비스에 대한 기본 기능을 제공하고 마이그레이션 프로젝트에서 사용할 수 있는 다음과 같은 보완 서비스도 제공합니다.
| 서비스 | 설명 |
|---|---|
| Azure Storage | 클라우드의 다양한 데이터 개체에 대해 가용성이 높고, 확장성이 뛰어나며, 내구성이 좋고 안전한 최신 스토리지를 제공합니다. REST API를 사용하여 HTTP 또는 HTTPS를 통해 전 세계 어디에서나 이러한 데이터 개체에 액세스할 수 있습니다. Azure Integration Services는 이러한 기능을 사용하여 트랜잭션이 플랫폼을 통과하는 동안 구성 및 원격 분석 데이터를 안전하게 저장합니다. 자세한 내용은 Azure Storage를 참조하세요. |
| Azure RBAC(Azure 역할 기반 액세스 제어) | 클라우드를 사용하는 모든 조직에 중요한 기능인 클라우드 리소스에 대한 액세스를 관리합니다. Azure RBAC는 Azure 리소스에 대한 액세스를 세밀하게 관리할 수 있는 Azure Resource Manager 기반의 권한 부여 시스템입니다. Azure 리소스에 액세스할 수 있는 사용자, 해당 리소스로 수행할 수 있는 작업 및 액세스할 수 있는 영역을 관리할 수 있습니다. 자세한 내용은 Azure RBAC를 참조하세요. |
| Azure Key Vault | 비밀 관리, 키 관리 및 인증서 관리와 관련된 문제를 해결하는 데 도움이 되는 기능을 제공합니다. Azure 통합 서비스는 애플리케이션 구성 설정 및 커넥터를 통해 Azure Key Vault와의 통합을 제공합니다. 이 기능을 사용하면 비밀, 자격 증명, 키 및 인증서를 안전하면서도 편리한 방식으로 저장할 수 있습니다. 자세한 내용은 Azure Key Vault를 참조하세요. |
| Azure Policy | 확장 가능한 방식으로 조직 표준을 적용하고 규정 준수를 평가하는 데 도움이 되는 기능을 제공합니다. 규정 준수 대시보드를 통해 리소스별, 정책별 세분성으로 드릴다운할 수 있는 기능으로 환경의 전체 상태를 평가할 수 있도록 집계된 보기를 얻을 수 있습니다. Azure 통합 서비스는 Azure Policy와 통합되므로 광범위한 거버넌스를 효율적으로 구현할 수 있습니다. 자세한 내용은 Azure Policy를 참조하세요. |
| Azure 네트워킹 | 연결, 애플리케이션 보호 서비스, 애플리케이션 제공 서비스 및 네트워킹 모니터링을 비롯한 다양한 네트워킹 기능을 제공합니다. Azure 통합 서비스는 이러한 기능을 사용하여 가상 네트워크 및 프라이빗 엔드포인트를 사용하는 서비스 간 연결을 제공합니다. 자세한 내용은 Azure 네트워킹을 참조하세요. |
| Azure Event Hubs | 간단하고 신뢰할 수 있으며 확장 가능한 완전 관리형 실시간 데이터 수집 서비스를 사용하여 모든 원본에서 초당 수백만 개의 이벤트를 스트리밍하여 동적 데이터 파이프라인을 빌드하고 비즈니스 문제에 즉시 대응합니다. API Management는 Azure에서 분리된 추적 솔루션을 구현할 때 최상의 솔루션 중 하나인 Event Hubs를 사용하여 사용자 지정 로깅을 수행합니다. 자세한 내용은 Azure Event Hubs를 참조하세요. |
| Azure SQL Database | 경우에 따라 통합 솔루션을 지원하기 위해 사용자 지정 로깅 전략이나 사용자 지정 구성을 만들어야 할 수 있습니다. SQL Server는 일반적으로 이 목적을 위해 온-프레미스에서 사용되지만 Azure SQL Database는 온-프레미스 SQL Server 데이터베이스를 클라우드로 마이그레이션할 때 실행 가능한 솔루션을 제공할 수 있습니다. 자세한 내용은 Azure SQL Database를 참조하세요. |
| Azure App Configuration | 애플리케이션 설정 및 기능 플래그를 중앙에서 관리합니다. 최신 프로그램, 특히 클라우드에서 실행되는 프로그램은 일반적으로 많은 분산 구성 요소를 가지고 있습니다. 이러한 구성 요소 간에 구성 설정을 분산하면 애플리케이션 배포 중에 문제 해결이 어려운 오류가 발생할 수 있습니다. App Configuration을 사용하면 애플리케이션에 대한 모든 설정을 저장하고 해당 액세스 권한을 한 곳에서 보호할 수 있습니다. 자세한 내용은 Azure App Configuration을 참조하세요. |
| Azure Monitor | Azure Monitor의 일부인 Application Insights는 라이브 앱에 대한 애플리케이션 성능 관리 및 모니터링을 제공합니다. 애플리케이션 원격 분석을 저장하고 통합 플랫폼의 전반적인 상태를 모니터링합니다. 또한 임계값을 설정하고 성능이 구성된 임계값을 초과할 때 경고를 받을 수 있는 기능도 있습니다. 자세한 내용은 Application Insights를 참조하세요. |
| Azure Automation | Azure 관리 작업을 자동화하고 Azure 내의 외부 시스템에서 작업을 오케스트레이션합니다. 이 언어의 여러 기능을 사용할 수 있도록 PowerShell 워크플로를 기반으로 구축되었습니다. 자세한 내용은 Azure Automation을 참조하세요. |
지원되는 개발자 환경
이 섹션에서는 BizTalk 서버 및 Azure 통합 서비스에서 지원하는 개발자 도구에 대해 설명합니다.
| 제품 | 지원되는 도구를 사용하는 제품 또는 서비스 |
|---|---|
| BizTalk Server | 각 BizTalk Server 버전은 특정 버전의 Visual Studio를 지원합니다. 예를 들어 BizTalk Server 2020은 Visual Studio 2019 Enterprise 또는 Professional을 지원합니다. 그러나 Visual Studio Community 에디션은 지원되지 않습니다. |
| Azure 통합 서비스 | - Azure Logic Apps(표준): Azure Portal 및 Visual Studio Code - Azure Logic Apps(사용량): Azure Portal, Visual Studio Code 및 Visual Studio 2019, 2017 또는 2015 - Azure Functions: Azure Portal, Visual Studio Code 및 Visual Studio 2022 - Azure API Management: Azure Portal 및 Visual Studio Code - Azure Service Bus: Azure Portal 및 Service Bus Explorer - Azure Data Factory: Azure Portal 및 Visual Studio 2015 또는 2013 |
BizTalk Server와 Azure 통합 서비스 비교
BizTalk Server와 Azure 통합 서비스를 비교하고 마이그레이션 방법을 논의하기 위해 먼저 BizTalk Server가 수행하는 작업을 간략하게 요약해 보겠습니다. 2000년에 처음 출시된 BizTalk Server는 어댑터를 사용하여 다양한 시스템을 연결하는 안정적인 온-프레미스 미들웨어 플랫폼입니다. 이 플랫폼은 기업, 시스템 또는 애플리케이션 간의 broker로 작동하며 이제 잘 확립된 통합 플랫폼입니다. 다양한 언어로 개발되고 서로 다른 프로토콜 및 형식을 사용하여 연결할 수 있는 다양한 시스템을 결합하는 문제를 간소화하기 위해 BizTalk Server는 다음과 같은 주요 기능을 제공합니다.
오케스트레이션(비즈니스 흐름)
오케스트레이션 또는 그래픽으로 정의된 비즈니스 프로세스를 만들고 실행하는 기능을 제공합니다.
메시지
다양한 소프트웨어 애플리케이션과 통신할 수 있는 기능을 제공합니다. 어댑터를 사용하면 BizTalk Server의 메시징 구성 요소가 다양한 프로토콜 및 데이터 형식과 상호 작용할 수 있습니다.
BizTalk Server 엔진에는 다음 구성 요소가 포함되어 있습니다.
| 구성 요소 | 설명 |
|---|---|
| BRE(비즈니스 규칙 엔진) | 복잡한 규칙 세트를 평가합니다. |
| Enterprise SSO(Single Sign-On) | Windows와 비 Windows 시스템 간에 인증 정보를 매핑하는 기능을 제공합니다. |
| Business Activity Monitoring(BAM: 비즈니스 활동 모니터링) | 정보 작업자가 실행 중인 비즈니스 프로세스를 모니터링할 수 있도록 합니다. |
| 그룹 허브 | 지원 담당자가 실행되는 엔진과 오케스트레이션을 관리할 수 있도록 합니다. |
BizTalk Server는 어떻게 작동하나요?
BizTalk Server는 MessageBox 데이터베이스를 중심으로 게시-구독 메시징 엔진 아키텍처를 사용합니다. MessageBox는 메시지, 메시지 속성, 구독, 오케스트레이션 상태, 추적 데이터 및 기타 정보를 저장합니다.
BizTalk Server가 메시지를 받으면 서버는 파이프라인을 통해 메시지를 전달하고 처리합니다. 이 단계에서는 메시지를 정규화하고 MessageBox에 게시합니다. 그런 다음, BizTalk Server는 기존 구독을 평가하고 메시지 컨텍스트 속성에 따라 메시지의 수신자를 결정합니다. 마지막으로 BizTalk Server 구독 또는 필터에 따라 메시지를 의도한 수신자에게 라우팅합니다. 이 수신자는 오케스트레이션 또는 송신 포트로, BizTalk Server에서 메시지를 보내는 대상 또는 BizTalk Server에서 메시지를 수신할 수 있는 원본입니다. BizTalk Server는 송신 파이프라인을 통해 메시지를 전달하여 송신 포트를 통해 메시지를 전송합니다. 송신 파이프라인은 어댑터를 통해 메시지를 보내기 전에 수신자가 예상하는 네이티브 형식으로 메시지를 직렬화합니다.
MessageBox 데이터베이스에는 다음과 같은 구성 요소가 있습니다.
메시징 에이전트
BizTalk Server는 메시지 게시, 메시지 구독, 메시지 검색 등을 위한 인터페이스를 제공하는 이 에이전트를 사용하여 MessageBox와 상호 작용합니다.
하나 이상의 SQL Server 데이터베이스
이러한 데이터베이스는 메시지, 메시지 파트, 메시지 속성, 구독, 오케스트레이션 상태, 추적 데이터, 라우팅을 위한 호스트 큐 등에 대한 영구적 저장소를 제공합니다.
다음 이미지는 BizTalk Server 메시징 엔진의 작동 방식을 보여 줍니다.
수신 포트가 메시지를 수신하면 MessageBox는 비즈니스 프로세스에서 처리하거나 특정 메시지에 대한 구독이 있는 송신 포트로 라우팅하기 위해 해당 메시지를 저장합니다.
자세한 내용은 이 가이드의 뒷부분에 있는 게시-구독 아키텍처를 참조하세요.
비즈니스 프로세스
이 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 실행할 수 있는 비즈니스 프로세스를 디자인하고 빌드하기 위한 옵션에 대해 설명합니다.
BizTalk Server
BizTalk Server에서 오케스트레이션은 MessageBox 데이터베이스를 통해 메시지를 구독(수신)하고 메시지를 게시(전송)할 수 있는 실행 가능한 비즈니스 프로세스입니다. 오케스트레이션은 새 메시지를 구성할 수 있고 구독 및 라우팅 인프라를 사용하여 메시지를 받을 수 있습니다. MessageBox가 오케스트레이션에 대한 구독을 채우면 새 인스턴스(오케스트레이션 실행)가 활성화되고 MessageBox가 메시지를 전달합니다. 필요한 경우 인스턴스가 리하이드레이션되고 메시지가 배달됩니다. 메시지가 오케스트레이션에서 전송되면 라우팅을 위해 데이터베이스에 추가된 적절한 속성을 사용하여 수신 위치에 도착하는 메시지와 동일한 방식으로 MessageBox에 게시됩니다.
게시-구독 메시징을 사용하도록 설정하기 위해 오케스트레이션은 구독을 만드는 데 도움이 되는 바인딩을 사용합니다. 오케스트레이션 포트는 상호 작용을 설명하는 논리 포트입니다. 메시지를 전달하려면 이러한 논리 포트를 실제 포트에 바인딩해야 하지만 이 바인딩 프로세스는 메시지 라우팅을 위해 구독을 구성할 뿐입니다.
BizTalk Server는 다음과 같은 예제 이점을 제공합니다.
디자이너 중심(선언적)
이해하기 쉬운 디자인 도구를 사용하여 코드에서 구현하기 어려울 수 있는 패턴과 워크플로를 구현함으로써 복잡한 프로세스를 디자인합니다.
최종 시스템을 사용한 추상화
최종 시스템이 아닌 메시지에 초점을 맞춘 프로세스를 디자인합니다. 예를 들어 솔루션을 개발하는 동안 FILE 어댑터를 사용할지 또는 FTP 어댑터를 사용할지 여부를 걱정할 필요가 없습니다. 대신 단방향이든 요청-응답이든 통신 유형과 처리하려는 메시지 유형에 중점을 둡니다. 나중에 솔루션을 배포할 때 어댑터와 최종 시스템을 지정할 수 있습니다.
Azure 통합 서비스
Azure Logic Apps에서는 시각적 디자이너와 함께 프로그래밍하는 "빌딩 블록" 방법을 사용하고 수백 개의 커넥터에서 미리 빌드된 작업을 수행하여 최소한의 코드가 필요한 실행 가능한 비즈니스 프로세스 및 애플리케이션을 논리 앱 워크플로로 만들 수 있습니다. 논리 앱 워크플로는 트리거 작업으로 시작하고 각 작업은 워크플로 구현 프로세스에서 논리적 단계로 작동하는 하나 이상의 작업으로 시작합니다. 워크플로는 작업을 사용하여 외부 소프트웨어, 서비스 및 시스템을 호출할 수 있습니다. 일부 작업은 조건부(if 문), 루프, 데이터 작업, 변수 관리 등과 같은 프로그래밍 작업을 수행합니다.
Azure Logic Apps는 다음과 같은 예제 이점을 제공합니다.
디자이너 중심(선언적)
이해하기 쉬운 디자인 도구를 사용하여 코드에서 구현하기 어려울 수 있는 패턴과 워크플로를 구현함으로써 복잡한 프로세스를 디자인합니다.
유연성 및 확장성
Azure Logic Apps는 진화하는 비즈니스 요구 사항에 맞게 자동으로 크기를 조정하고 적응하는 클라우드 기반의 서버리스이며 확장성이 뛰어난 컴퓨팅 서비스입니다.
모든 항목에 연결
수백 개의 미리 빌드된 커넥터가 포함된 지속적으로 확장되는 갤러리에서 선택하여 워크플로를 빌드합니다. 커넥터는 워크플로의 단계로 사용할 수 있는 작업을 제공합니다. BizTalk Server, Salesforce, Office 365, SQL 데이터베이스, Azure Functions, Azure Storage, Azure Service Bus 등 대부분의 Azure 서비스와 온-프레미스 애플리케이션 또는 시스템, 메인프레임, SaaS 및 API를 비롯한 Microsoft 및 파트너의 대부분의 서비스와 시스템에 대한 통합 솔루션을 빌드할 수 있습니다. 액세스하려는 리소스에 대해 미리 빌드된 커넥터가 없는 경우 일반 HTTP 작업을 사용하여 서비스와 통신하거나 사용자 지정 커넥터를 만들 수 있습니다.
재사용 가능한 구성 요소
통합 플랫폼은 일관되고 통합된 방식으로 문제를 해결하는 방법을 제공하며, 재사용 가능한 구성 요소를 통해 달성할 수 있는 경우가 많습니다. 이 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 구성 요소를 다시 사용하는 방법을 설명합니다.
BizTalk Server
오케스트레이션
내부적으로 동일한 애플리케이션 내에서 또는 여러 애플리케이션을 사용하여 다양한 워크플로 전반에 걸쳐 공통 비즈니스 논리를 오케스트레이션으로 만들고 공유할 수 있습니다. BizTalk Server에서 네이티브 게시-구독 메커니즘을 사용하거나(분리된 방식으로) 동기 호출에 대해 호출 오케스트레이션이라는 오케스트레이션 셰이프를 사용하거나 비동기 호출에 대해 시작 오케스트레이션을 사용하여 오케스트레이션을 트리거할 수 있습니다.
어댑터
어댑터는 일반적으로 인식되는 데이터 프로토콜 및 문서 형식을 사용하여 BizTalk Server와 거래 업체 간에 연결을 제공하는 소프트웨어 구성 요소입니다. 이러한 구성 요소는 SMTP, FTP, HTTP 등과 같이 일반적으로 인식되는 표준을 준수하는 배달 메커니즘을 사용하여 메시지를 더 쉽게 보내고 받을 수 있도록 해줍니다. 어댑터는 핵심 플랫폼의 일부이므로 기존의 모든 애플리케이션에서 공유합니다. BizTalk 어댑터 프레임워크를 사용하여 네이티브 또는 WCF(Windows Communication Foundation) 기반의 사용자 지정 어댑터를 만들어 이 계층을 확장할 수도 있습니다.
스키마
XSD(XML 스키마 정의) 스키마를 사용하면 BizTalk Server에서 계약 기반 메시징을 사용할 수 있습니다. 중복 스키마 생성을 방지하려면 컴파일된 어셈블리에서 스키마를 참조하면 됩니다. 공유 스키마를 사용하려면 BizTalk 프로젝트에서 공유 어셈블리에 대한 참조를 추가해야 합니다.
이 단계는 간단해 보일 수 있지만 종속성 체인으로 인해 공유 어셈블리의 변경 내용을 관리하기가 어려울 수 있습니다. 공유 어셈블리에 업데이트가 필요한 경우 BizTalk Server에서 공유 어셈블리를 참조하는 모든 프로젝트를 제거하여 업데이트를 설치해야 합니다. 그러나 이러한 제약 조건을 방지하기 위해 기존 솔루션을 중단하지 않고 스키마 또는 공유 스키마에 대한 새 버전을 배포하는 어셈블리 버전 관리 기능을 구현할 수 있습니다.
Maps 및 사용자 지정 펑토이드
Maps를 사용하면 BizTalk Server에서 XML 메시지 변환이 가능합니다. 맵을 공유할 수 있지만 공유 스키마와 마찬가지로 공유 맵에도 유사한 주의 사항이 적용됩니다. 종속성 체인으로 인해 신중하게 진행하고 변경 사항을 관리할 수 있는 완성도 높은 소프트웨어 개발 수명 주기가 있는지 확인합니다.
맵에서 펑토이드는 미리 정의된 수식과 인수라는 특정 값을 사용하여 계산을 수행합니다. BizTalk Server는 다양한 작업을 지원하기 위해 많은 펑토이드를 제공합니다. 사용자 지정 펑토이드는 BizTalk Server 매핑 환경에서 사용 가능한 작업의 범위를 확대할 수 있는 방법을 제공합니다.
많은 맵을 만들기 시작하면 비슷한 논리를 반복적으로 구현하고 있다는 것을 알게 됩니다. 따라서 일반적으로 복사하여 지도 내 또는 지도의 여러 위치에 붙여넣는 여러 개의 동일한 코드 조각을 유지 관리하는 데 시간을 할애하게 됩니다. 이러한 코드 조각을 사용자 지정 펑토이드로 변환하는 것이 좋습니다. 이렇게 하면 펑토이드를 한 번만 만들 수 있지만 원하는 만큼 맵에서 펑토이드를 다시 사용하고 한 곳에서만 펑토이드를 업데이트할 수 있습니다. 각 사용자 지정 펑토이드는 Microsoft.BizTalk.BaseFunctoids 네임스페이스에서 파생된 클래스를 사용하여 .NET 어셈블리로 배포됩니다. 단일 어셈블리에는 둘 이상의 사용자 지정 펑토이드가 포함될 수 있습니다.
.NET Fx 어셈블리
BizTalk Server 프로젝트에서 이러한 어셈블리를 공유할 수 있습니다. 이러한 어셈블리는 종속성 관점에서 보다 쉽게 관리할 수 있습니다. 호환성이 손상되는 변경 내용이 없는 경우 .NET Fx 어셈블리를 업데이트하려면 GAC(전역 어셈블리 캐시)에서 DLL을 업데이트해야 하며, 이를 통해 변경 내용을 다른 어셈블리에서 자동으로 사용할 수 있습니다. 호환성이 손상되는 변경 내용이 있는 경우 .NET Fx 어셈블리의 변경 내용을 수용하도록 종속 프로젝트도 업데이트해야 합니다.
사용자 지정 파이프라인 및 파이프라인 구성 요소
BizTalk Server가 메시지를 받고 보낼 때 비즈니스상의 이유로 인해 서버는 메시지 입력 및 종료를 준비하고 변환해야 할 수도 있습니다. BizTalk Server에서 파이프라인은 파이프 및 필터 통합 패턴 구현을 제공하며 JSON 인코더 및 디코더, MIME 또는 SMIME 디코더 등과 같은 많은 기능을 포함합니다.
파이프라인 사용자 지정이 필요한 메시지 컨텍스트에 정보를 추가해야 하는 경우 BizTalk Server는 사용자 지정 파이프라인 구성 요소를 만들어 이러한 파이프라인을 사용자 지정할 수 있는 기능을 제공합니다. 사용자 지정 파이프라인 구성 요소는 여러 BizTalk 인터페이스를 구현한 다음, 사용자 지정 파이프라인의 여러 단계 내에서 사용하는 a.NET 클래스입니다. 이러한 구성 요소에 대한 코드를 작성하려면 C# 또는 .NET용 Visual Basic을 사용할 수 있습니다.
규칙 엔진 정책
비즈니스 규칙 엔진 정책은 동일한 BizTalk 그룹 내에 배포된 BizTalk Server 애플리케이션 간에 공유할 수 있는 또 다른 종류의 아티팩트입니다. 예를 들어 메시지 라우팅과 관련된 일반적인 비즈니스 규칙 엔진 규칙이 있는 경우 이러한 규칙을 한 위치에서 관리하고 설치된 BizTalk 애플리케이션 전체에서 널리 공유할 수 있습니다. 비즈니스 규칙 엔진은 이러한 규칙을 캐시하므로 이러한 규칙을 업데이트하는 경우 비즈니스 규칙 엔진 업데이트 서비스를 다시 시작해야 합니다. 그렇지 않으면 다음 캐시 시간 제한에서 변경 내용이 선택됩니다.
Azure 통합 서비스
통합 계정
Azure Logic Apps의 경우 통합 계정은 재사용 가능한 아티팩트에 대한 중앙 집중식 액세스를 제공하는 클라우드 기반 컨테이너 및 Azure 리소스입니다. 소비 논리 앱 워크플로의 경우 이러한 아티팩트에는 거래 파트너, 계약, XSD 스키마, XSLT 맵, Liquid 템플릿 기반 맵, 인증서, 일괄 처리 구성 및 .NET Fx 어셈블리가 포함됩니다.
표준 논리 앱 워크플로의 경우 Azure Logic Apps는 최근 통합 계정을 요구하지 않고 XSLT 변환에서 .NET Fx 어셈블리를 호출하기 위한 지원을 도입했습니다. 또는 Visual Studio Code의 표준 논리 앱 프로젝트에 스키마, 맵 및 어셈블리를 추가한 후 Azure에 배포할 수 있습니다.
API
API는 디지털 환경을 구현하고, 데이터 및 서비스를 재사용 가능하고 보편적으로 액세스할 수 있게 하며, 애플리케이션 통합을 간소화하고, 새로운 디지털 제품을 뒷받침합니다. API에 대한 종속성이 확산되고 증가함에 따라 조직은 수명 주기 내내 이러한 종속성을 고급 자산으로 관리해야 합니다.
Azure 통합 서비스 내에서 API, 특히 Azure API Management로 관리되는 API를 다시 사용할 수 있습니다. Azure API Management에 API를 추가한 후에는 소비 논리 앱 워크플로와 함께 API Management 커넥터를 사용하여 관리되고 제어되는 방식으로 API에 쉽게 액세스할 수 있습니다. 또한 Azure Logic Apps는 조직이 엔터프라이즈 전체에서 재사용을 촉진하고 개발자가 만들 수 있는 불필요한 중복 커넥터를 방지할 수 있도록 사용자 지정 API 만들기 및 사용을 지원합니다. 또한 사용자 지정 API는 개발자가 특정 API를 사용하는 메커니즘을 파악하지 않고 이러한 API를 사용할 수 있는 사용자를 민주화합니다.
사용자 지정 커넥터
사용하려는 API에 대해 미리 빌드된 커넥터가 없는 경우 OpenAPI 스키마로 외부 또는 외부 API를 래핑하여 사용자 지정 커넥터를 만들고 적절한 권한으로 소비 논리 앱 워크플로에서 해당 커넥터에 액세스할 수 있습니다. 사용자 지정 커넥터는 요청 메시지의 쉬운 어셈블리를 허용하고 Azure Logic Apps가 다운스트림 작업에서 사용할 수 있는 형식화된 응답을 받을 수 있도록 Azure Logic Apps와 API 간에 계약을 만듭니다. REST API와 SOAP API는 모두 지원되며 로컬 네트워크에 있는 공용 API 또는 프라이빗 API를 참조할 수 있습니다. Microsoft Power Automate 및 Microsoft Power Apps에서 사용자 지정 커넥터를 사용할 수도 있습니다.
표준 논리 앱 워크플로의 경우 서비스 공급자를 기반으로 하는 고유한 기본 제공 사용자 지정 커넥터를 만들 수 있습니다.
사용자 지정 커넥터를 구현하면 요청 메시지를 보내고 형식화된 응답을 받기 위한 공통 인터페이스를 만들어 개발 환경을 간소화할 수 있습니다. 자세한 내용은 사용자 지정 커넥터 및 API를 참조하세요.
어댑터 및 커넥터
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 어댑터 및 커넥터 개념을 각각 설명합니다.
BizTalk Server
외부 시스템, 애플리케이션 및 엔터티와 메시지를 교환하기 위해 BizTalk Server는 다양한 통신 프로토콜을 사용하여 파일 시스템, 데이터베이스 및 사용자 지정 비즈니스 애플리케이션과 같은 비즈니스 엔드포인트 간에 메시지를 전송하는 COM 또는 .NET Fx 구성 요소인 어댑터를 제공합니다. BizTalk Server는 다양한 프로토콜을 지원하는 네이티브 어댑터를 제공합니다. 예를 들면 다음과 같습니다.
- 파일 위치에서의 메시지 송수신을 지원하는 파일 어댑터
- EDI, FTP, HTTP, MSMQ, SMTP, POP3 및 SOAP 프로토콜용 어댑터
- Windows SharePoint Services용 어댑터
BizTalk 어댑터 프레임워크는 모든 어댑터가 BizTalk Server 메시징 엔진에서 작업을 구현하거나 작업에 액세스할 수 있도록 지원하는 안정적인 개방형 메커니즘을 제공합니다. Microsoft.BizTalk.Adapter.Framework 네임스페이스의 인터페이스를 사용하면 어댑터가 구성 속성 페이지를 수정할 수 있습니다. BizTalk 어댑터 프레임워크는 서비스와 스키마를 BizTalk 프로젝트로 가져오는 기능도 제공합니다. 파트너 어댑터는 다양한 공급업체 및 커뮤니티 구성원에서도 사용할 수 있습니다. 알려진 어댑터 목록은 BizTalk Server: 타사 어댑터 목록을 참조하세요.
Azure 통합 서비스
Azure Logic Apps를 사용하여 워크플로를 빌드하는 경우 미리 빌드된 커넥터를 사용하면 일반적으로 코드를 작성하지 않고도 다른 앱, 서비스, 시스템, 프로토콜 및 플랫폼의 데이터, 이벤트 및 리소스를 쉽고 빠르게 작업할 수 있습니다. Azure Logic Apps는 사용할 수 있는 수백 개의 커넥터가 포함된 지속적으로 확장되는 갤러리를 제공합니다. Microsoft 및 파트너(예: BizTalk Server, Salesforce, Office 365, SQL 데이터베이스, 대부분의 Azure 서비스, 메인프레임, API 등)에서 클라우드 기반 또는 온-프레미스의 많은 서비스 및 시스템에 대한 통합 솔루션을 빌드할 수 있습니다. 일부 커넥터는 조건부(if) 문, 루프, 데이터 작업, 변수 관리 등과 같은 프로그래밍 작업을 수행하는 작업을 제공합니다. 원하는 리소스에 사용할 수 있는 커넥터가 없는 경우 일반 HTTP 작업을 사용하여 서비스와 통신하거나 사용자 지정 커넥터를 만들 수 있습니다.
기술적으로 커넥터는 기본 서비스 또는 시스템이 Azure Logic Apps와 통신하는 데 사용하는 API 주변의 프록시 또는 래퍼입니다. 이 커넥터는 워크플로에서 작업을 수행하는 데 사용하는 작업을 제공합니다. 작업은 구성할 수 있는 속성이 있는 트리거 또는 작업으로 사용할 수 있습니다. 또한 일부 트리거 및 작업을 수행하려면 먼저 기본 서비스 또는 시스템에 대한 연결을 만들고 구성해야 합니다. 필요한 경우 사용자 계정에 대한 액세스도 인증합니다.
Azure Logic Apps의 대부분의 커넥터는 기본 제공 커넥터 또는 관리형 커넥터입니다. 일부 커넥터는 두 버전 모두에서 사용할 수 있습니다. 사용 가능한 버전은 소비 논리 앱 워크플로 또는 표준 논리 앱 워크플로를 만드는지 여부에 따라 달라집니다.
기본 제공 커넥터는 기본적으로 Azure Logic Apps 런타임에서 실행되도록 설계되었으며 일반적으로 관리되는 커넥터에 비해 더 나은 성능, 처리량, 용량 또는 기타 이점을 제공합니다.
관리형 커넥터는 Microsoft가 Azure에서 배포, 호스팅 및 관리합니다. 이러한 커넥터는 클라우드 서비스, 온-프레미스 시스템 또는 둘 다에 대한 트리거 및 작업을 제공합니다. 표준 논리 앱 워크플로에서 모든 관리형 커넥터는 Azure 커넥터로 그룹화됩니다. 그러나 소비 논리 앱 워크플로에서 관리되는 커넥터는 가격 수준에 따라 표준 또는 엔터프라이즈로 그룹화됩니다.
자세한 내용은 다음 설명서를 참조하세요.
애플리케이션 연결
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 다른 애플리케이션과 연결하는 옵션을 설명합니다.
BizTalk Server
어댑터는 BizTalk Server에 연결 기능을 제공하고 보내기 또는 받기 작업을 수행하는 BizTalk 서버에서 로컬로 실행됩니다. 약 30개의 기본 제공 어댑터를 사용할 수 있으며, ISV 어댑터의 작은 에코시스템은 추가 기능을 제공합니다. 이러한 어댑터가 로컬로 실행되면 Windows 인증이 널리 사용되는 인증 방법입니다. 일반적으로 사용되는 어댑터에는 FILE, SFTP, SQL, WCF(Basic-HTTP), HTTP 및 SMTP가 포함됩니다. 이 목록에서 BizTalk Server의 어댑터가 대부분 프로토콜 어댑터인지 확인할 수 있습니다. 따라서 어댑터는 일반적으로 데이터를 최종 데이터 저장소에 로드하기 전에 해당 시스템이 데이터 구문 분석을 담당하는 다른 시스템과 완전한 메시지가 교환되는 메시지 지향 메시징 패턴을 사용합니다.
Azure 통합 서비스
커넥터는 Azure Logic Apps에 연결 기능을 제공하고 일반적으로 기본 SaaS 시스템에서 소유하는 API를 기반으로 추상화 기능을 제공합니다. 예를 들어 SharePoint와 같은 서비스는 API 우선 접근 방식을 사용하여 빌드됩니다. 여기서 API는 최종 사용자를 위해 서비스에 기능을 제공하지만 다른 시스템이 API를 통해 호출할 수 있도록 동일한 기능이 노출됩니다. 이러한 API 호출을 간소화하기 위해 커넥터는 메타데이터를 사용하여 개발자가 요청 및 응답에서 예상되는 데이터를 알 수 있도록 메시징 계약을 설명합니다.
다음 스크린샷은 단일 테넌트 Azure Logic Apps의 표준 논리 앱 워크플로에 대한 커넥터 검색 환경을 보여 줍니다. 기본 제공 탭을 선택하면 Azure Functions, Azure Service Bus, SQL Server, Azure Storage, 파일 시스템, HTTP 등과 같은 기본 제공 커넥터를 찾을 수 있습니다. Azure 탭에서는 다른 Microsoft SaaS 커넥터, 파트너 SaaS 커넥터 등을 포함하여 800개가 넘는 커넥터를 찾을 수 있습니다.
웹 서비스 및 API 연결
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 웹 서비스 및 API 연결 지원을 설명합니다.
BizTalk Server
웹 서비스 지원은 BizTalk Server 널리 사용되는 기능이며 WCF(Windows Communication Foundation)와 통합하여 사용할 수 있습니다. BizTalk에서의 이러한 지원은 WCF 서비스 게시 및 사용이라는 두 가지 범주로 구분됩니다.
WCF 어댑터는 WS-Addressing, WS-Security 및 WS-AtomicTransaction과 같은 WS-* 표준을 지원할 수 있습니다. 그러나 WS-ReliableMessaging은 이 릴리스의 WCF 어댑터에서 지원되지 않습니다.
WCF 어댑터는 가장을 통해 SSO(Single Sign On)를 지원하고 WCF 어댑터에서 SSO를 사용하기 위한 Enterprise SSO 티켓을 획득합니다. 이 기능을 사용하면 사용자 컨텍스트가 시스템 간에 흐를 수 있습니다. 인증 관점에서 서비스 인증은 None, Windows 및 인증서 형식을 지원합니다. 클라이언트 인증은 익명, 사용자 이름, Windows 및 인증서 유형을 지원합니다. 지원되는 보안 모드에는 전송, 메시지 및 혼합 형식이 포함됩니다.
WCF는 WCF-WsHttp, WCF-NetTcp 및 WCF-NetMsmq와 같은 WCF 어댑터에서 찾을 수 있는 WS-AutomicTransaction 프로토콜을 사용하는 트랜잭션을 지원합니다. 이 기능은 다음 시나리오에서 지원됩니다.
- MessageBox 데이터베이스에 메시지를 트랜잭션 방식으로 제출
- 메시지를 MessageBox에서 트랜잭션 대상으로 트랜잭션 전송
트랜잭션 범위는 MessageBox 구성 요소에 따라 제한됩니다. 예를 들어 BizTalk 오케스트레이션은 클라이언트의 트랜잭션에 참여할 수 없습니다. 마찬가지로 대상 엔드포인트는 BizTalk 오케스트레이션에서 시작되는 트랜잭션에 참여할 수 없습니다.
WCF 확장성은 WCF 사용자 지정 바인딩을 통해 사용할 수 있습니다. GAC(전역 어셈블리 캐시)에 사용자 지정 코드를 컴파일하고 추가해야 합니다. 또한 새 확장을 포함하도록 machine.config 파일을 업데이트해야 합니다. 바인딩이 설치되면 WCF-Custom 및 WCF-CustomIsolated 어댑터에 확장이 표시됩니다.
BizTalk Server는 BizTalk 관리 콘솔을 사용할 때 WCF-BasicHTTP 수신 위치를 Azure API Management 내의 엔드포인트로 노출할 수 있습니다. Azure Portal에서 API Management를 사용하여 BizTalk Server의 API Management를 통해 SOAP 엔드포인트를 노출할 수도 있습니다. 자세한 내용은 API Management에서 BizTalk WCF-BasicHTTP 엔드포인트 게시를 참조하세요.
Azure 통합 서비스
Azure 통합 서비스의 연결 모델은 부분적으로 API 경제의 진화로 인해 BizTalk Server와 다릅니다. 더 많은 조직이 기본 시스템 및 데이터에 대한 액세스를 노출함에 따라 플랫폼에 구애받지 않은 접근 방식이 필요했습니다. REST는 이제 최신 웹 서비스를 디자인하는 주요 아키텍처 접근 방식입니다.
Azure Logic Apps에서 REST는 시스템을 연결하는 기본 방법입니다. Microsoft 및 기타 소프트웨어 공급업체는 시스템 및 데이터 위에 RESTful 서비스를 노출하므로 Azure Logic Apps는 이러한 유형의 정보를 노출하고 사용할 수 있습니다. OpenAPI 사양을 사용하면 사용자와 컴퓨터 모두 메타데이터를 통해 클라이언트와 서버 간의 상호 작용을 이해할 수 있습니다. 이러한 이해의 일환으로 요청 및 응답 페이로드가 모두 파생됩니다. 즉, 동적 콘텐츠를 사용하여 워크플로 작업의 입력을 채우고 다운스트림 작업에서 응답의 출력을 사용할 수 있습니다.
커넥터가 호출하는 기본 서비스를 구현하는 소프트웨어 공급업체에 따라 인증 체계는 커넥터마다 다를 수 있습니다. 일반적으로 이러한 체계에는 다음 형식이 포함됩니다.
Microsoft는 미사용 및 전송 중 데이터 암호화를 통해 강력한 보호 계층을 제공합니다. Azure 고객 트래픽이 Microsoft가 제어하지 않는 물리적 경계 또는 Microsoft를 대신하여 데이터 센터 간에 이동할 때 IEEE 802.1AE MAC 보안 표준(MACsec)을 사용하는 데이터 링크 계층 암호화 방법은 기본 네트워크 하드웨어에 걸쳐 지점 간에 적용됩니다.
Microsoft는 클라우드 서비스와 고객 간에 이동하는 데이터를 보호하기 위해 TLS(전송 계층 보안) 프로토콜을 사용할 수 있는 옵션을 제공합니다. Microsoft 데이터 센터는 Azure 서비스에 연결되는 클라이언트 시스템과 TLS 연결을 협상합니다. TLS는 상호 운용성, 알고리즘 유연성, 배포 및 사용 용이성과 함께 메시지 변조, 가로채기 및 위조를 감지할 수 있는 강력한 인증, 메시지 개인 정보 보호 및 무결성을 제공합니다.
이 섹션에서는 커넥터를 통한 RESTful 연결에 중점을 두지만 사용자 지정 커넥터 환경을 통해 SOAP 웹 서비스 연결을 구현할 수 있습니다.
어댑터 또는 커넥터 사용 차단
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 각각 어댑터 또는 커넥터 사용을 방지하는 옵션을 설명합니다.
BizTalk Server
BizTalk Server는 다른 애플리케이션에서 특정 어댑터를 차단하는 개념을 포함하지 않지만 환경에서 해당 어댑터를 제거하여 애플리케이션에서 해당 어댑터의 사용을 "차단"할 수 있습니다. BizTalk Server의 어댑터는 플랫폼 설정의 일부이므로 설치된 어댑터는 누구나 사용할 수 있습니다. 각 어댑터에 대한 특정 수신 및 송신 처리기를 정의할 수도 있습니다. 이는 해당 처리기를 실행하거나 처리할 수 있는 BizTalk 그룹에 속하는 컴퓨터를 정의합니다.
Azure 통합 서비스
조직에서 Azure Logic Apps의 관리형 커넥터를 사용하여 제한되거나 승인되지 않은 리소스에 연결하는 것을 허용하지 않는 경우 논리 앱 워크플로에서 해당 연결을 만들고 사용하는 기능을 차단할 수 있습니다. Azure Policy를 사용하여 차단하려는 커넥터에 대한 연결을 만들거나 사용하지 못하게 하는 정책을 정의하고 적용할 수 있습니다. 예를 들어, 보안상의 이유로 특정 소셜 미디어 플랫폼 또는 다른 서비스와 시스템에 대한 연결을 차단할 수 있습니다.
메시지 내구성
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 메시지 지속성에 대해 설명합니다.
BizTalk Server
MessageBox 데이터베이스는 엔드포인트로 보내기 전에 메시지가 스토리지에 유지되도록 하는 지속성 지점 역할을 함으로써 또 다른 이점을 제공합니다. 구성된 재시도 횟수를 모두 사용한 후 메시지 전송에 실패하면 메시지가 일시 중단되고 MessageBox에 저장됩니다.
관리자는 BizTalk 관리 콘솔에서 일시 중단된 메시지를 다시 시작할 수 있습니다. 오케스트레이션을 사용할 때도 동일한 동작이 발생합니다. 오케스트레이션 런타임은 비즈니스 논리를 유지하며, 문제가 발생하면 다시 시작할 수 있습니다. 예를 들어 다음 시나리오에서는 오케스트레이션에서 메시지를 다시 시작할 수 있습니다.
- 비원자성 범위 내에서 보낸 메시지
- 트랜잭션 범위의 끝에서
- 새 오케스트레이션 인스턴스를 시작할 때(오케스트레이션 셰이프 시작)
- 디버그 중단점에서
- 엔진이 디하이드레이션하기로 결정한 경우
- 오케스트레이션이 완료되는 경우
- 시스템이 종료되는 경우
BizTalk Server 이러한 모든 기능을 기본 제공합니다. BizTalk Server가 이를 처리하므로 지속성 구현에 대해 걱정할 필요가 없습니다.
Azure 통합 서비스
Azure Logic Apps는 다음과 같은 방법으로 메시지 내구성을 제공합니다.
소비 논리 앱의 기본값이며 표준 논리 앱에서 사용할 수 있는 상태 저장 워크플로에는 워크플로 상태를 추적하고 워크플로 작업을 통과할 때 메시지를 저장하는 검사점이 있습니다. 이 기능을 사용하면 자세한 입력 및 출력 값을 검토할 수 있는 트리거 및 워크플로 인스턴스 실행 기록에 저장된 풍부한 데이터에 액세스할 수 있습니다.
Azure Portal 또는 API를 통해 실행 인스턴스를 다시 처리할 수 있습니다. 이 때 이전 실행에서 실패가 발생한 위치에 상관없이 전체 실행 인스턴스가 실행됩니다. 이 동작은 메시지가 한 번 이상 전달되고 소비자에서 멱등 처리가 발생한다는 것을 의미합니다.
Azure Service Bus에서 사용할 수 있는 피킹 잠금 메시징을 사용하면 메시지 실행 성공 후 메시지를 커밋하거나 오류 발생 시 메시지를 중단할 수 있습니다. Azure Logic Apps에서 이 기능을 사용하려면 Azure Service Bus 커넥터를 선택합니다. 커밋된 메시지는 메시지 큐에서 제거되지만 중단된 메시지는 잠금 해제되고 클라이언트에서 처리할 수 있습니다. 피킹 잠금은 "정확히 한 번" 메시징을 달성할 수 있는 좋은 방법입니다.
게시-구독 아키텍처
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 게시-구독 패턴을 구현하는 옵션을 설명합니다.
BizTalk Server
게시-구독(pub-sub) 기능은 MessageBox 데이터베이스를 통해 존재합니다. 이에 대해서는 BizTalk Server 작동 방식 섹션의 앞부분에서 설명했습니다. 구독을 만드는 일반적인 방법은 정의된 메시지 스키마의 특정 요소나 특성을 승격된 속성으로 식별할 수 있는 승격된 속성을 사용하는 것입니다. 그런 다음, 승격된 속성에 대한 특정 기준에 따라 메시지를 필터링하는 구독을 설정할 수 있습니다. 예를 들어 City라는 스키마 요소를 승격한 경우 특정 도시에 대한 City 요소를 필터링하는 구독을 만들 수 있습니다. 조건이 충족되면 구독, 송신 포트 또는 오케스트레이션이 메시지 복사본을 받습니다.
Azure 통합 서비스
BizTalk Server와 완전히 다른 아키텍처를 사용하는 Azure 통합 서비스의 대부분의 서비스는 이벤트 기반입니다. 게시-구독 솔루션을 구현해야 하는 경우 Azure Service Bus를 사용할 수 있습니다. 이 서비스는 네임스페이스에 메시지 큐 및 게시-구독 토픽이 있는 완전 관리형 엔터프라이즈 메시지 broker입니다. Azure Service Bus를 사용해 애플리케이션과 서비스를 서로 분리하여 다음과 같은 이점을 제공할 수 있습니다.
- 경쟁 작업자 간에 작업 부하를 분산합니다.
- 서비스 및 애플리케이션 경계를 넘어 제어하여 데이터를 안전하게 라우팅하고 전송합니다.
- 높은 수준의 안정성이 요구되는 트랜잭션 작업을 조정합니다.
Azure Logic Apps에는 메시지를 게시하고 구독하는 데 사용할 수 있는 Azure Service Bus 커넥터가 포함되어 있습니다. Service Bus를 사용하는 이점은 워크플로와 독립적으로 메시징을 사용할 수 있다는 것입니다. BizTalk Server와 달리 메시징은 워크플로 플랫폼에서 분리됩니다. 메시징 및 워크플로 기능은 Azure 통합 서비스에서 분리되어 있지만 메시지 속성(사용자 속성)을 지원하는 Azure Service Bus에서 메시지 구독을 만들 수 있습니다. 이러한 속성을 사용하여 토픽 구독에서 만든 필터로 평가되는 키-값 쌍을 제공합니다. 하나 이상의 키-값 쌍을 추가하여 Azure Service Bus 작업을 설정할 때 이러한 사용자 속성을 정의합니다. 데모를 보려면 Azure 통합 서비스를 사용한 Pub 하위 메시징 - 2부 콘텐츠 기반 라우팅 비디오를 참조하세요.
Azure 통합 서비스 외부에서 Azure Cache for Redis를 사용하여 게시-구독 시나리오를 구현할 수도 있습니다.
비즈니스 규칙 엔진
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 비즈니스 규칙을 설정하는 옵션을 설명합니다.
BizTalk Server
BizTalk Server에는 시각적 편집기를 사용하여 "if-then-else" 규칙을 생성할 수 있는 정방향 체인 규칙 엔진이 포함되어 있습니다. IT 환경의 다른 환경으로 전송할 수 있는 정책 내에서 이러한 규칙을 번들로 묶을 수 있습니다. 이러한 정책은 XSD 스키마, .NET Fx 코드 및 SQL Server 데이터베이스 테이블에 액세스하여 데이터를 조회하고 출력을 보강할 수도 있습니다.
Azure 통합 서비스
현재 Azure에는 동등한 규칙 엔진 기능이 없지만 고객은 Azure Functions를 사용하여 사용자 지정 코드를 통해 규칙을 구현하는 경우가 많습니다. 그런 다음, Azure Logic Apps의 기본 제공 Azure Functions 커넥터를 사용하여 이러한 규칙에 액세스합니다.
이 분야의 향후 투자에 대한 자세한 내용은 이 가이드의 뒷부분에 있는 로드맵 섹션을 참조하세요.
데이터 변환
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 데이터 변환 기능에 대해 설명합니다.
BizTalk Server
XML 메시지를 한 형식에서 다른 형식으로 변환할 수 있는 다양한 도구를 제공합니다. 데이터 변환은 이러한 맵의 중간에 사용자 지정 .NET Fx 코드를 삽입할 수 있는 확장 개체를 지원하는 XSLT 맵을 사용합니다. 풍부한 맵을 빌드하는 데 도움이 되는 재사용 가능한 기능을 제공하는 기본 펑토이드를 사용할 수도 있습니다.
핵심 XML 변환 외에도 BizTalk Server는 CSV 및 JSON 형식에 대한 인코딩 및 디코딩을 제공하므로 이러한 형식과 XML 간에 변환이 가능하기 때문에 다양한 형식을 지원할 수 있습니다.
Azure 통합 서비스
엔터프라이즈 통합 팩
이 구성 요소는 BizTalk Server의 유사한 개념을 따르며 Azure Logic Apps에서 B2B 기능을 쉽게 사용할 수 있도록 합니다. 그러나 한 가지 주요 차이점은 엔터프라이즈 통합 팩이 통합 계정을 기반으로 한다는 것입니다. 이러한 계정은 B2B 시나리오에 대해 거래 업체, 계약, 맵(XSLT 또는 Liquid 템플릿), 스키마 및 인증서와 같은 아티팩트를 저장, 관리 및 사용하는 방법을 간소화합니다.
유동 템플릿
논리 앱 워크플로의 기본 JSON 변환의 경우 작성 작업 또는 JSON 구문 분석 작업과 같은 기본 제공 데이터 작업을 사용할 수 있습니다. 그러나 일부 시나리오에는 반복, 제어 흐름 및 변수와 같은 요소를 포함하는 복잡한 고급 변환이 필요할 수 있습니다. JSON에서 JSON으로, JSON에서 텍스트로, XML에서 JSON으로 또는 XML에서 텍스트로 변환의 경우 Liquid 오픈 소스 템플릿 언어를 사용하여 필요한 매핑 또는 변환을 설명하는 Liquid 템플릿을 만들 수 있습니다.
EDI 스키마
EDI 문서 스키마는 EDI 트랜잭션 문서 형식의 본문을 정의합니다. 논리 앱 워크플로의 경우 Microsoft 통합 GitHub 리포지토리의 모든 BizTalk EDI 스키마를 공개적으로 사용할 수 있습니다.
표준 논리 앱
Azure Portal에서는 맵과 스키마를 표준 논리 앱 리소스에 직접 업로드할 수 있습니다. Visual Studio Code에서 표준 논리 앱 프로젝트를 사용하는 경우 통합 계정을 사용하지 않고도 Artifacts 폴더 내의 해당 폴더에 이러한 아티팩트를 업로드할 수 있습니다. XSLT 맵에서 사용자 지정 컴파일된 어셈블리를 호출할 수도 있습니다.
Azure 기능
C# 또는 다른 프로그래밍 언어를 사용하여 XSLT 또는 Liquid 템플릿 변환을 실행하여 Azure API Management 또는 Azure Logic Apps로 호출할 수 있는 Azure 함수를 만들 수 있습니다.
네트워크 연결
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 네트워크 연결 기능에 대해 설명합니다.
BizTalk Server
BizTalk Server가 항상 서버 환경에 설치되어 있으면 네트워크 연결은 기본 서버의 네트워크 구성에 따라 달라집니다. BizTalk Server에 대한 네트워크 연결을 설정할 때 일반적으로 다음 영역을 구성해야 합니다.
- 종속성
- 최종 시스템에 대한 인바운드 및 아웃바운드 연결
종속성 구성
다중 서버 환경에서 BizTalk Server를 완전히 구성하려면 일반적으로 잘 알려진 서비스 또는 프로토콜에 대해 TCP 및 UDP 포트를 사용하도록 설정하는 방화벽 구성과 관련된 모든 네트워크 연결 종속성에 특히 주의해야 합니다. 예를 들어 이러한 서비스 및 프로토콜에는 SQL Server 엔진에 대한 액세스, MSDTC(Microsoft Distributed Transaction Coordinator), 클러스터형 네트워크 드라이브, 다른 서버에 설치된 경우 SSO 서비스에 대한 액세스가 포함되며 SharePoint는 연결을 구현하기 위해 인바운드 및 아웃바운드 규칙을 만들어 구성해야 하는 모든 서비스입니다.
인바운드 및 아웃바운드 연결 구성
BizTalk Server를 완전히 설정하고 애플리케이션 배포를 준비한 후에는 호스트 인스턴스가 내부 또는 외부 네트워크에 속해 있는지 여부에 관계없이 다른 서비스에 연결하고 액세스할 수 있도록 하는 방화벽 규칙을 구현해야 합니다. 조직 네트워크 외부의 최종 시스템에 대한 연결을 고려할 때 보안 고려 사항도 포함해야 합니다. 다양한 시스템은 허용된 IP 주소 목록을 첫 번째 방어선으로 정의하는 데 의존하므로 이상적으로 BizTalk Server는 잘 정의된 공용 IP 주소 목록을 통해 모든 아웃바운드 통신을 라우팅합니다.
파트너 서비스가 BizTalk Server에 연결하려고 할 때 핵심 조직 서비스를 사용할 수 있는 조직의 네트워크 또는 내부 계층 내에 있는 인스턴스에 연결되지 않았는지 확인합니다. 대신, 파트너 서비스에 조직 네트워크의 가장 바깥쪽 경계인 DMZ(완충 영역)라고도 하는 경계 네트워크 내에 있는 엔드포인트에 대한 액세스 권한을 부여합니다. 그러나 BizTalk Server에서 메시지를 라우팅해야 하는 서비스는 일반적으로 조직의 네트워크 내에 있으므로 해당 내부 계층에 액세스할 수 있어야 합니다.
이러한 시나리오를 달성하기 위해 다음과 같은 여러 접근 방식이 있습니다.
- 경계 네트워크에서 BizTalk Server를 구현하고 자체 서비스 또는 호스트 인스턴스만 조직의 네트워크에 액세스하도록 허용
- 두 개의 BizTalk Server를 하나는 경계 네트워크에, 다른 하나는 조직의 네트워크에 설정합니다. 그런 다음, 경계 네트워크의 서버는 조직 네트워크의 서버에서 사용하는 메시지를 게시합니다.
- 역방향 프록시 역할을 할 수 있는 NetScaler 및 F5와 같은 사용자 지정 애플리케이션 또는 어플라이언스 소프트웨어를 개발하고, 경계 네트워크 내에서 BizTalk를 대신하여 메시지를 수신하고, 이러한 호출을 BizTalk Server로 리디렉션합니다.
Azure 통합 서비스
인바운드 및 아웃바운드 연결
Azure는 네트워크 경계 내에서 서비스를 격리하고 온-프레미스 및 클라우드 워크로드에 연결하는 여러 가지 방법을 제공합니다. 다음 목록에서는 네트워크 경계 내의 리소스와 Azure 리소스를 통합할 수 있는 다양한 방법을 설명합니다.
온-프레미스 데이터 게이트웨이
이 게이트웨이는 Azure와 네트워크 경계 내 리소스 간의 브리지 역할을 하여 온-프레미스 데이터와 다양한 Microsoft 클라우드 서비스 간에 빠르고 안전한 데이터 전송을 제공합니다. 이러한 서비스에는 Azure Logic Apps, Microsoft Power BI, Microsoft Power Apps, Microsoft Power Automate 및 Azure Analysis Services가 포함됩니다. 이 게이트웨이를 사용하면 데이터베이스 및 기타 데이터 원본을 온-프레미스 네트워크 내에 유지하고 클라우드 서비스에서 해당 온-프레미스 데이터를 안전하게 사용할 수 있습니다.
하이브리드 연결
Azure 서비스와 Azure App Service의 기능인 하이브리드 연결은 시나리오를 지원하고 Azure App Service에서 사용되는 것 이상의 기능을 제공합니다. Azure App Service 외부 사용량에 대한 자세한 내용은 Azure Relay 하이브리드 연결을 참조하세요. Azure App Service 내에서 하이브리드 연결을 사용하여 포트 443을 통해 Azure에 아웃바운드 호출을 수행할 수 있는 모든 네트워크의 애플리케이션 리소스에 액세스할 수 있습니다. 하이브리드 연결은 앱에서 TCP 엔드포인트로의 액세스를 제공하며 앱에 액세스하는 새로운 방법을 사용하도록 설정하지 않습니다. Azure App Service에서 각 하이브리드 연결은 단일 TCP 호스트 및 포트 조합과 상관 연결됩니다. 이 기능을 사용하면 TCP 엔드포인트가 있는 경우 앱이 모든 OS의 리소스에 액세스할 수 있습니다. 하이브리드 연결은 애플리케이션 프로토콜 또는 액세스하려는 항목을 모르거나 신경 쓰지 않습니다. 이 기능은 네트워크 액세스만 제공합니다.
가상 네트워크 통합
Azure Virtual Network 통합을 사용하면 Azure 리소스를 Azure에 구성된 가상 네트워크에 연결하여 앱에 해당 가상 네트워크의 리소스에 대한 액세스 권한을 부여할 수 있습니다. Azure Logic Apps의 가상 네트워크 통합은 Azure 리소스에서 가상 네트워크로 아웃바운드 호출을 수행하는 데만 사용됩니다.
가상 네트워크 피어링을 사용하면 온-프레미스 네트워크를 Azure에 연결하여 온-프레미스 리소스와 Azure 서비스 간에 양방향 연결을 제공합니다. Azure 통합 서비스는 하이브리드 통합을 허용하는 가상 네트워크 연결을 제공합니다. 다음 이미지는 아웃바운드 트래픽 상자에 강조 표시된 대로 네트워킹 페이지가 열리고 가상 네트워크 통합이 활성화된 표준 논리 앱 리소스를 보여 줍니다. 이 구성을 사용하면 모든 아웃바운드 트래픽이 이 가상 네트워크에서 나가도록 합니다.
프라이빗 엔드포인트
프라이빗 엔드포인트는 가상 네트워크의 개인 IP 주소를 사용하는 네트워크 인터페이스입니다. 이 네트워크 인터페이스는 Azure Private Link로 구동되는 Azure 리소스에 비공개로 안전하게 연결됩니다. 프라이빗 엔드포인트를 사용하도록 설정하면 해당 Azure 리소스를 가상 네트워크로 가져오고 네트워크의 리소스가 Azure 리소스에 대한 인바운드 호출을 수행할 수 있습니다.
다음 표에서는 각 Azure 통합 서비스 리소스에서 사용할 수 있는 네트워크 연결 방법을 보여 줍니다.
| 리소스 | 온-프레미스 데이터 게이트웨이 | 하이브리드 연결 | 가상 네트워크 통합 | 프라이빗 엔드포인트 |
|---|---|---|---|---|
| Azure API Management | ✅ | ✅ | ✅ | |
| Azure Logic Apps(사용량) | ✅ | |||
| Azure Logic Apps(표준) | ✅ (Azure 커넥터 사용) |
✅ (기본 제공 커넥터 사용) |
✅ (기본 제공 커넥터 사용) |
✅ |
| Azure Service Bus | ✅ | ✅ | ||
| Azure Event Grid |
사용자 지정 코드
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 사용자 고유의 코드를 작성하고 실행하는 옵션을 설명합니다.
BizTalk Server
사용자 지정 .NET Fx 코드를 사용하여 여러 가지 방법으로 BizTalk를 확장할 수 있습니다. 예를 들면 다음과 같습니다.
| 기능 | 설명 |
|---|---|
| 인라인 코드 | 오케스트레이션 셰이프 내에서 인라인 C# 코드를 작성할 수 있습니다. BizTalk 맵 내에서 인라인 코드를 작성할 수도 있습니다. 두 시나리오 모두에서 코드 조각은 일반적으로 간단하며 디버그할 수 없습니다. |
| 컴파일된 어셈블리 | 다음 위치에서 이러한 어셈블리를 호출할 수 있습니다. - 오케스트레이션의 식 셰이프 - 스크립팅 펑토이드를 사용하는 BizTalk 맵 - 비즈니스 규칙 엔진 정책 - 사용자 지정 파이프라인 구성 요소로서의 파이프라인 Visual Studio 디버거를 적절한 호스트 인스턴스 Windows 프로세스에 연결하여 컴파일된 어셈블리를 디버그할 수 있습니다. |
| 사용자 지정 어댑터 | BizTalk Server에는 기본 제공 어댑터가 많이 포함되어 있지만 필요한 경우 언제든지 고유한 어댑터를 만들 수 있습니다. |
| 사용자 지정 WCF 동작 | BizTalk Server에는 WCF(Windows Communication Foundation)를 기반으로 하는 대부분의 기본 어댑터가 포함되어 있습니다. 경우에 따라 시스템 통신에 OAuth 헤더를 적용하는 것과 같은 사용자 지정 동작을 개발하여 기능을 확장해야 할 수도 있습니다. |
| BizTalk Server 맵의 확장성 | - C#, JScript, Visual Basic, XSLT 또는 XSLT 호출 템플릿을 사용하여 인라인 코드를 만들어 기본 펑토이드 사용 시 몇 가지 제한 사항이나 어려움을 줄일 수 있습니다. - 스크립팅 펑토이드를 사용하여 외부 어셈블리를 호출할 수 있습니다. - 모든 맵에서 사용할 사용자 지정 펑토이드를 만들 수 있습니다. |
Azure 통합 서비스
Azure Functions는 Azure Logic Apps의 Azure Functions 커넥터에서 실행할 수 있는 코드를 작성할 수 있는 기능을 제공합니다. Functions 플랫폼은 다양한 프로그래밍 언어와 런타임을 지원하므로 유연성이 뛰어납니다. 이러한 함수는 일반적으로 실행 시간이 짧도록 설계되었으며 로컬 개발 및 디버깅을 지원하는 다양한 개발자 도구 세트가 있습니다.
Azure Logic Apps에서 인라인 코드 커넥터는 JavaScript 코드 실행이라는 작업을 제공합니다. 이 작업을 사용하여 JavaScript에서 작은 코드 조각을 작성할 수 있습니다. 또한 이러한 코드 조각은 실행 시간이 짧고 동적 콘텐츠 입력 및 출력을 지원해야 합니다. 코드가 실행되면 워크플로의 다운스트림 작업에 출력을 사용할 수 있습니다. 현재 이 작업에 대한 직접적인 디버깅 지원은 없지만 워크플로 인스턴스의 실행 기록에서 입력 및 출력을 볼 수 있습니다.
재사용 가능한 구성 요소 섹션에서 설명한 대로 XSLT 맵에서 .NET Fx 어셈블리 호출에 대한 지원은 현재 해당 어셈블리를 통합 계정에 업로드할 때 소비 논리 앱 워크플로에서 사용할 수 있습니다. 이 기능은 사용자 지정 데이터 변환 규칙을 지원하는 데 도움이 됩니다. 표준 논리 앱 워크플로의 경우 Azure Logic Apps 팀은 최근 통합 계정 없이 XSLT 맵에서 .NET Fx 코드를 호출하는 지원을 릴리스했습니다. Visual Studio Code의 표준 논리 앱 프로젝트에 어셈블리 및 맵을 추가한 후 Azure에 배포할 수도 있습니다. 자세한 내용은 Azure Logic Apps(표준) XSLT 변환에 추가된 .NET Framework 어셈블리 지원 및 로드맵 섹션을 참조하세요.
Azure API 앱 또는 Azure App Service로 생성된 웹앱을 포함하여 워크플로를 확장할 수도 있습니다. 웹앱, REST API 및 모바일 백 엔드를 호스트해야 하는 요구 사항이 있는 경우 Azure App Service는 적합한 HTTP 기반 솔루션입니다. Azure App Service에서 호스트되는 앱을 온-프레미스 또는 클라우드 서비스와 통합할 수 있습니다. 이 플랫폼은 Windows 및 Linux 기반 환경을 모두 지원하여 ASP.NET Core, Java, Ruby, Node.js, PHP 및 Python과 같은 다양한 언어 및 프레임워크와 함께 애플리케이션을 실행하고 크기를 조정합니다.
애플리케이션 그룹
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 워크로드를 구성하는 옵션을 설명합니다.
BizTalk Server
소프트웨어 개발 수명 주기의 일부에는 논리 패키지에서 코드 및 아티팩트를 빌드하고 관리하는 작업이 포함됩니다. BizTalk Server는 Visual Studio 솔루션을 BizTalk 애플리케이션에 배포할 수 있도록 애플리케이션의 개념을 지원합니다. 따라서 리소스를 공유해야 하는 시나리오가 있는 경우 다른 애플리케이션을 참조할 수 있습니다.
BizTalk Server는 컴파일된 어셈블리에 참조를 추가할 수 있는 명시적 공유 모델을 사용합니다. 이러한 어셈블리가 GAC(전역 어셈블리 캐시)에 있는 경우 BizTalk 런타임은 필요에 따라 어셈블리를 찾아 로드합니다. 한 가지 단점은 공유 어셈블리를 업데이트해야 할 때 버전 관리 체계를 구현하지 않는 한 업데이트하기 전에 어셈블리를 참조하는 모든 BizTalk 프로젝트를 제거해야 한다는 것입니다. 이러한 제한으로 인해 배포 타임라인이 길어지고 여러 설치 및 제거 관리가 복잡할 수 있습니다.
Azure 통합 서비스
Azure Logic Apps에서 소비 논리 앱 리소스에는 단일 상태 저장 워크플로만 포함됩니다. 즉, 애플리케이션인 워크플로 및 논리 앱 리소스는 항상 일대일 관계를 가집니다. 표준 논리 앱 리소스를 통해 애플리케이션 개념이 발전했습니다. 표준 논리 앱 리소스는 여전히 애플리케이션이지만 이 리소스를 사용하여 여러 워크플로를 포함 및 실행하여 일대다 관계를 만들 수 있습니다. Visual Studio Code의 표준 논리 앱 프로젝트에서 로컬로 작업하는 경우 논리 앱 리소스는 이 단일 프로젝트에 매핑됩니다. 이 방법을 사용하면 동일한 프로젝트에서 관련 워크로드, 코드 및 아티팩트를 쉽고 논리적으로 그룹화하고 해당 프로젝트를 단일 단위로 배포할 수 있습니다.
클라우드 아키텍처는 BizTalk와 같은 서버 기반 패러다임과 다르게 작동합니다. Azure Logic Apps(표준)는 풀 모델을 사용하여 코드 및 아티팩트를 가져옵니다. 따라서 필요한 추가 아티팩트를 프로젝트에 복사한 후 코드 및 기타 아티팩트와 함께 배포됩니다. 경우에 따라 필요한 코드 및 아티팩트를 모두 복사하지 않아도 됩니다. 이 경우 이 기능을 별도로 관리할 수 있지만 워크플로에서 호출할 수 있는 서비스로 전환하는 것이 좋습니다.
예를 들어 조직에서 널리 사용되는 데이터 변환이 있다고 가정해 보겠습니다. 여러 논리 앱 프로젝트에 걸쳐 변환에 대한 맵을 포함하는 대신 변환을 서비스로 제공하는 인터페이스를 구현할 수 있습니다. 그런 다음, 논리 앱 프로젝트와 별도로 해당 서비스의 수명 주기를 관리하고 워크플로에서 해당 서비스를 호출할 수 있습니다.
표준 논리 앱 프로젝트에 여러 워크플로를 포함할 수 있으므로 프로젝트 내에서 또는 여러 프로젝트에서 이러한 워크플로를 구성하는 방법을 물어볼 수 있습니다. 답변은 일반적으로 요구 사항에 따라 달라집니다. 예를 들면 다음과 같습니다.
- 비즈니스 프로세스 선호도
- 엔드투엔드 모니터링 및 지원
- 보안, 역할 기반 액세스 제어 및 네트워크 격리
- 성능 및 비즈니스 중요도
- 지리적 위치 및 지역 중복성
자세한 내용은 Azure Logic Apps(표준)에서 논리 앱 워크플로 구성을 참조하세요.
보안 및 거버넌스
보안 및 거버넌스는 통합 솔루션을 빌드할 때 당연히 중요합니다. 정의에 따르면 미들웨어는 둘 이상의 시스템 사이에 있습니다. 연결을 설정할 때 이러한 시스템에 연결하고 액세스하려면 자격 증명 또는 비밀을 전달해야 하는 경우가 많으므로 이 중요한 정보를 관리하는 데 고려해야 합니다.
BizTalk Server
BizTalk에는 어댑터에서 사용하는 암호화된 자격 증명을 저장, 매핑 및 전송할 수 있는 Enterprise SSO(Single Sign-On)가 포함되어 있습니다. 이 암호화된 정보는 SSO 데이터베이스에 저장됩니다. 연결하려는 시스템 또는 기간 업무 시스템을 나타내는 논리적 엔터티인 SSO 관련 애플리케이션을 구성할 수도 있습니다.
Azure 통합 서비스
Azure Logic Apps는 다음과 같은 보안 기능을 지원합니다.
Azure Key Vault
Azure Key Vault를 사용하여 자격 증명, 비밀, API 키 및 인증서를 저장할 수 있습니다. Azure Logic Apps에서는 Azure Key Vault 커넥터를 사용하여 이 정보에 액세스하고 보안 입력 및 출력 기능을 사용하여 플랫폼의 로그 및 실행 기록에서 이 정보를 제외할 수 있습니다.
추적 섹션의 뒷부분에 있는 이 가이드에서는 워크플로 실행의 단계별 재생을 제공하는 실행 기록 기능에 대해 설명합니다. Azure Logic Apps는 워크플로 실행에서 모든 입력 및 출력을 캡처하는 가치 제안을 제공하지만 중요한 데이터에 대한 액세스를 보다 세밀하게 관리해야 하는 경우도 있습니다. 트리거 및 작업에서 보안 입력 및 출력 기능을 사용해 이 데이터에 대한 난독화를 설정하여 이러한 콘텐츠를 실행 기록에서 숨기고 이 데이터를 Azure Monitor, 특히 Log Analytics 및 Application Insights로 보내는 것을 방지할 수 있습니다. 다음 이미지는 실행 기록에서 보안 입력 및 보안 출력을 사용하도록 설정한 결과의 예를 보여 줍니다.
OAuth 기반 통합
대부분의 커넥터는 연결을 만들 때 이 인증 유형을 사용합니다. 이 방법을 사용하면 이메일 주소와 암호를 제공하는 것만큼 쉽게 많은 SaaS 서비스와 통합할 수 있습니다. Azure API Management는 OAuth도 지원하므로 통합 인증 체계를 제공하여 두 서비스를 함께 사용할 수 있습니다.
이 기능은 BizTalk Server에서는 기본적으로 사용할 수 없습니다.
관리 ID
일부 커넥터는 Microsoft Entra ID로 보호되는 리소스에 대한 액세스를 인증하기 위해 관리 ID 사용을 지원합니다. 관리 ID를 사용하여 연결을 인증할 때 자격 증명, 비밀 또는 Microsoft Entra 토큰을 제공할 필요가 없습니다.
애플리케이션 관리 및 액세스 관리
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 애플리케이션 및 액세스를 관리하기 위한 옵션을 설명합니다.
BizTalk Server
관리자는 BizTalk Server 관리자 콘솔을 사용하여 BizTalk Server 애플리케이션을 관리합니다. 이 도구는 관리자가 애플리케이션을 배포하고, 이전 트랜잭션, 활성 트랜잭션 및 큐에 대기된 트랜잭션을 검토하고, 추적 검토 및 트랜잭션 다시 제출과 같은 심층적인 문제 해결 작업을 수행하는 데 사용할 수 있는 MMC(Microsoft Management Console) Thick 클라이언트 애플리케이션입니다.
Azure 통합 서비스
Azure Portal은 관리자와 지원 담당자가 인터페이스의 상태를 보고 모니터링하는 데 사용하는 일반적인 도구입니다. Azure Logic Apps의 경우 이 환경에는 실행 기록을 통해 사용할 수 있는 풍부한 트랜잭션 추적이 포함됩니다.
세분화된 RBAC(역할 기반 액세스 제어)도 사용할 수 있으므로 다양한 수준에서 Azure 리소스에 대한 액세스를 관리하고 제한할 수 있습니다.
스토리지
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스의 데이터 스토리지 옵션에 대해 설명합니다.
BizTalk Server
BizTalk Server는 데이터 저장소 및 데이터 연속성을 위해 SQL Server를 많이 사용합니다. BizTalk Server의 다른 모든 구성 요소 및 호스트는 메시지 수신, 처리 또는 라우팅과 같은 서로 다른 비즈니스 애플리케이션을 통합하는 데 특정 역할을 합니다. 그러나 데이터베이스 컴퓨터는 이 작업을 캡처하고 디스크에 유지합니다. 예를 들어 BizTalk Server가 들어오는 메시지를 받으면 수신 호스트는 다른 호스트가 오케스트레이션 처리 및 전송을 위해 메시지를 검색하기 전에 해당 메시지를 MessageBox 데이터베이스에 유지합니다.
SQL 데이터베이스를 프로비전하고 관리하는 업무를 담당하는 경우 고가용성은 가동 시간을 보장하는 중요한 아키텍처 구성 요소입니다. BizTalk Server 데이터베이스에 고가용성을 제공하기 위해 고객은 Windows 클러스터링을 사용하여 SQL Server를 실행하는 두 대 이상의 컴퓨터로 구성된 서버 클러스터를 만드는 경우가 많습니다. 이 서버 클러스터는 BizTalk Server 데이터베이스에 대한 중복성 및 내결함성을 제공합니다. 컴퓨터 그룹이 함께 작동하여 가용성과 확장성을 높이는 부하 분산 클러스터링과 달리, 서버 클러스터링에는 일반적으로 한 컴퓨터가 다른 컴퓨터에 백업 리소스를 제공하도록 활성-수동 구성의 데이터베이스 컴퓨터 쌍이 포함됩니다.
Azure 통합 서비스
Azure Logic Apps는 Azure Storage를 사용하여 자동으로 미사용 데이터를 암호화하고 저장합니다. 이 암호화는 데이터를 보호하고 조직의 보안 및 규정 준수 노력에 부합하는 데 도움이 됩니다. 기본적으로 Azure Storage는 Microsoft 관리형 키를 사용하여 데이터를 암호화합니다. 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
Azure Portal을 통해 Azure Storage로 작업하는 경우 모든 트랜잭션은 HTTPS를 통해 수행됩니다. HTTPS를 통해 Storage REST API를 사용하여 Azure Storage로 작업할 수도 있습니다. REST API를 호출하여 스토리지 계정의 개체에 액세스할 때 HTTPS를 사용하도록 설정하려면 스토리지 계정에 필요한 보안 전송을 사용하도록 설정합니다.
데이터 구성
코드를 다시 컴파일하거나 다시 조립하지 않고도 환경 간에 통합 솔루션을 이동하려는 경우 구성과 코드를 분리하는 것이 중요합니다. 구성 정보는 일반적으로 환경에 따라 달라지므로 환경 전체에 솔루션을 배포할 때 변경해야 하는 엔드포인트 및 기타 세부 정보를 정의할 수 있습니다.
BizTalk Server
BizTalk NT 서비스 실행 파일
이 실행 파일은 BTSNTSvc.exe.config라는 app.config 파일을 호출합니다. 이 파일은 명확한 텍스트 구성 정보를 저장할 수 있도록 키-값 쌍을 제공합니다. 그러나 다음 고려 사항에 따라 이 파일을 신중하게 사용합니다.
BizTalk 그룹 내의 모든 컴퓨터에서 구성을 신중하게 복제해야 합니다.
구성을 변경하려면 호스트 인스턴스를 다시 시작하여 이 구성 파일의 최신 값을 선택해야 합니다.
이 구성 파일에 도입된 구문 오류로 인해 호스트 인스턴스가 시작되지 않고 가동 중지 시간이 발생합니다.
Enterprise SSO 도구
이 도구를 구성 저장소로 사용할 수도 있습니다. 커뮤니티 도구는 Enterprise SSO를 사용하여 데이터 관리를 사용하도록 설정할 수도 있습니다. 이후에 SDK 도구를 통해 이 데이터에 액세스하여 런타임 시 이 데이터를 검색할 수 있습니다.
사용자 지정 캐시 구성 요소
이러한 구성 요소는 키-값 쌍 이외의 사용 사례를 해결할 수 있도록 자주 도입됩니다. 예를 들어 SQL Server 데이터베이스에 테이블 형식 데이터를 저장하고 호스트 인스턴스가 시작될 때 해당 데이터를 메모리에 로드하려고 하는 경우를 가정해 보겠습니다. 이 구현을 통해 BizTalk Server는 사용자 지정 .NET Fx 코드를 실행하여 런타임 시 이 정보를 가져올 수 있습니다. 그런 다음, 오케스트레이션, BizTalk 맵 및 사용자 지정 파이프라인 구성 요소에서 이 데이터에 액세스할 수 있습니다.
사용자 지정 데이터베이스
데이터베이스는 개발자와 관리자 모두에게 잘 알려진 기술 및 언어이므로 사용자 지정 데이터베이스는 애플리케이션 구성 데이터를 저장하기 위한 또 다른 일반적인 옵션입니다.
BRE(비즈니스 규칙 엔진)
기본 사용 사례는 아니지만 BRE는 구성 저장소 역할을 할 수도 있습니다. 오케스트레이션 또는 파이프라인 구성 요소에서 엔진을 호출하든 관계없이 BRE 정책에서 환경별 정보를 정의한 다음, 해당 정책을 관련 환경에 배포할 수 있습니다. 런타임 시 오케스트레이션 또는 파이프라인 구성 요소는 맵과 같은 다운스트림 함수 또는 라우팅 상황에서 이 정보에 액세스하여 사용할 수 있습니다.
사용자 지정 구성 파일
사용자 지정 구성(.config) 파일을 사용하여 애플리케이션 구성 데이터를 저장할 수 있지만 이 방법은 모든 환경에서 이러한 파일에 대한 고정 및 고정 위치를 유지해야 하기 때문에 일반적이지 않습니다.
Windows 레지스트리
Windows 레지스트리를 애플리케이션 구성 값을 저장하는 유효한 옵션으로 사용할 수 있습니다. 이 레지스트리는 Microsoft Windows 운영 체제에서 하나 이상의 사용자, 애플리케이션 및 하드웨어 디바이스에 대해 시스템을 구성하는 데 필요한 정보를 저장하는 데 사용하는 중앙 계층적 데이터베이스입니다. 레지스트리에는 하이브, 키 및 값과 같은 기본 요소가 포함되어 있습니다. 그러나 여러 레지스트리가 있는 대규모 환경에서는 레지스트리에 저장된 값을 유지 관리하는 것이 어려울 수 있으며 개별 애플리케이션 설정을 백업하는 데도 어려움이 있습니다.
Azure 통합 서비스
Azure Key Vault
이 서비스는 애플리케이션 및 클라우드 서비스에서 사용하는 암호화 키 및 기타 비밀을 저장하고 보호합니다. 보안 키 관리는 클라우드의 데이터를 보호하는 데 필수적이므로 Azure Key Vault를 사용하여 암호와 같은 키와 비밀을 암호화하고 저장합니다.
Azure App Configuration
이 서비스는 애플리케이션 설정 및 기능 플래그를 중앙에서 관리합니다. 모든 Azure 앱에 대한 구성을 범용 호스트된 위치에 저장할 수 있습니다. 시간이 많이 걸리는 재배포를 방지하여 고객에게 영향을 주지 않고 실시간으로 구성을 효과적이고 안정적으로 관리합니다. Azure App Configuration은 속도, 확장성 및 보안을 위해 빌드되었습니다.
Azure Cosmos DB
이 서비스는 한 자릿수 밀리초 응답 시간과 모든 규모의 속도를 보장하는 자동 및 즉각적인 확장성을 갖춘 최신 앱 개발을 위한 완전 관리형 NoSQL 데이터베이스입니다. 구성 데이터를 Azure Cosmos DB에 로드한 다음, Azure Logic Apps의 Azure Cosmos DB 커넥터를 사용하여 해당 데이터에 액세스할 수 있습니다.
Azure Table Storage
이 서비스는 구성 데이터를 저렴한 비용으로 유지하는 또 다른 스토리지 기능을 제공합니다. Azure Logic Apps에서 Azure Table Storage 커넥터를 사용하여 이 데이터에 쉽게 액세스할 수 있습니다. 자세한 내용은 Azure Table Storage를 참조하세요.
사용자 지정 캐싱
Azure 통합 서비스를 사용하여 사용자 지정 캐싱 솔루션을 구현할 수도 있습니다. 널리 사용되는 방법에는 Azure API Management 및 Azure Cache for Redis의 캐싱 정책 사용이 포함됩니다.
사용자 지정 데이터베이스
데이터베이스는 개발자와 관리자 모두에게 잘 알려진 기술 및 언어이므로 사용자 지정 데이터베이스는 애플리케이션 구성 데이터를 저장하기 위한 또 다른 일반적인 옵션입니다.
대용량 파일 처리
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 대용량 파일을 처리하는 옵션을 설명합니다.
BizTalk Server
대용량 파일 처리를 해결하기 위해 BizTalk Server에는 다음 프로필을 기반으로 하는 최적화가 포함됩니다.
메시지 라우팅만 해당
승격된 메시지 속성을 기반으로 메시지를 라우팅하는 데에만 BizTalk Server를 사용하는 경우 메시지는 .NET XmlReader 인터페이스를 사용하여 MessageBox 데이터베이스로 스트리밍됩니다. BizTalk Server는 개별 메시지 부분을 메모리에 로드하지 않으므로 이 시나리오에서는 메모리 부족 오류가 문제가 되지 않습니다. 그러나 주요 고려 사항은 MessageBox 데이터베이스에 매우 큰 메시지(100MB 초과)를 작성하는 데 필요한 시간입니다. BizTalk Server 개발 팀은 라우팅만 수행할 때 최대 1GB의 메시지 처리를 성공적으로 테스트했습니다. 자세한 내용은 파이프라인 성능 최적화를 참조하세요.
맵을 사용하여 데이터 변환
BizTalk Server가 맵을 사용하여 문서를 변환할 때 메모리 집약적일 수 있는 이 작업은 XSL 스타일 시트를 로드하는 .NET XslCompiledTransform 클래스에 메시지를 전달합니다. 로드 작업이 성공적으로 완료되면 여러 스레드가 Transform 메서드를 동시에 호출할 수 있습니다. 자세한 내용은 XslCompiledTransform 클래스를 참조하세요.
BizTalk Server는 변환 중에 문서를 메모리로 로드하기 위한 구성 가능한 메시지 크기 임계값을 구현하여 큰 문서의 메모리 관리를 크게 향상시킵니다. 기본적으로 메시지 크기 임계값은 1MB입니다. 이 임계값보다 크기가 작은 메시지의 경우 BizTalk Server는 메모리 내에서 메시지를 처리합니다. 이 임계값보다 큰 크기의 메시지에 대한 메모리 요구 사항을 줄이기 위해 BizTalk Server는 메시지를 파일 시스템에 버퍼링합니다.
Azure 통합 서비스
BizTalk Server와 같은 온-프레미스 미들웨어 플랫폼과 Azure Logic Apps와 같은 PaaS 제품을 사용하여 대용량 파일을 처리하는 것 사이에는 몇 가지 근본적인 차이점이 있습니다. 예를 들어 최신 클라우드 환경에서는 이 문제를 해결하기 위한 다른 방법이 잠재적으로 존재하기 때문에 대용량 메시지 시나리오를 신중하게 면밀히 조사하여 올바른 솔루션을 찾습니다.
파일 크기 제한
Azure에서는 일관되고 안정적인 환경을 보장하기 위해 파일 크기 제한이 있습니다. 시나리오의 유효성을 검사하려면 Azure Logic Apps에 대한 서비스 제한 설명서를 검토해야 합니다. 일부 커넥터는 커넥터에 따라 달라지는 기본 메시지 크기 제한을 초과하는 메시지에 대해 메시지 청크를 지원합니다. 메시지 청크는 큰 메시지를 더 작은 메시지로 분할하여 작동합니다.
Azure Logic Apps는 메시지 크기 제한이 있는 유일한 서비스가 아닙니다. 예를 들어 Azure Service Bus에도 이러한 제한이 있습니다. Azure Service Bus에서 대용량 메시지를 처리하는 방법에 대한 자세한 내용은 대용량 메시지 지원을 참조하세요.
클레임 확인 패턴
파일 크기 제한을 방지하기 위해 대용량 메시지를 클레임 검사 및 페이로드로 분할하여 작동하는 클레임 확인 패턴을 구현할 수 있습니다. 클레임 확인을 메시징 플랫폼으로 보내고 페이로드를 외부 서비스에 저장합니다. 이렇게 하면 메시지 버스와 클라이언트를 오버로드로부터 보호하면서 대용량 메시지를 처리할 수 있습니다. 또한 이 패턴은 스토리지가 일반적으로 메시징 플랫폼에서 사용하는 리소스 단위보다 저렴하기 때문에 비용을 절감하는 데 도움이 됩니다.
Azure Data Factory
Azure Data Factory는 대용량 파일을 처리하기 위한 또 다른 옵션을 제공합니다. 이 서비스는 직관적인 작성과 단일 창 모니터링 및 관리를 위한 코드 없는 시각적 환경을 통해 확장 가능한 서버리스 데이터 통합 및 데이터 변환을 위한 Azure의 ELT 제품입니다. 또한 기존 SSIS(SQL Server Integration Services) 패키지를 Azure로 리프트 앤 시프트하고 Azure Data Factory에서 완전한 호환성을 통해 실행할 수 있습니다. SSIS Integration Runtime은 완전 관리형 서비스를 제공하므로 인프라 관리에 대해 걱정할 필요가 없습니다. 자세한 내용은 SQL Server Integration Services 워크로드를 클라우드로 리프트 앤 시프트를 참조하세요.
온-프레미스 아키텍처에서 SSIS는 데이터베이스에 대용량 파일 로드를 관리하는 데 널리 사용되는 옵션이었습니다. 해당 아키텍처에 해당하는 클라우드와 마찬가지로 Azure Data Factory는 파일 시스템, 데이터베이스, SAP, Azure Blob Storage, Azure Data Explorer, Oracle, DB2, Amazon RDS 등과 같은 다양한 데이터 원본에서 대규모 데이터 세트의 변환 및 이동을 해결할 수 있습니다. 대규모 데이터 처리 요구 사항이 있는 경우 Azure Logic Apps 및 Azure Service Bus보다 더 나은 옵션으로 Azure Data Factory를 사용하는 것이 좋습니다.
모니터링 및 경고
BizTalk Server
-
이 도구는 BizTalk Server 환경의 상태를 모니터링하고 유지 관리 작업을 수행하는 데 사용할 수 있는 MMC 스냅인입니다. 기능에는 MBV(MsgBox Viewer) 보고서, 종결자 도구 작업, 메일 알림, 보고서 컬렉션 및 성능 통합이 포함됩니다.
-
또한 이 도구는 관리자가 오류, 일시 중단된 인스턴스, 현재 재시도 중인 트랜잭션, 상태 등을 검색할 수 있는 MMC 스냅인입니다. 최신 정보를 검토하기 위해 콘솔을 지속적으로 새로 고쳐야 하기 때문에 도구 환경은 본질적으로 매우 반응적입니다.
-
BizTalk Server 환경을 완전히 제어할 수 있는 외부 웹 솔루션입니다. 이 단일 도구는 BizTalk Server에 대한 작업, 모니터링 및 분석 기능을 제공합니다.
Azure 통합 서비스
-
Azure 리소스를 모니터링하려면 이 서비스와 Log Analytics 기능을 클라우드 및 온-프레미스 환경에서 원격 분석 데이터를 수집, 분석 및 작동하기 위한 포괄적인 솔루션으로 사용할 수 있습니다.
Azure Logic Apps에서는 다음 옵션을 사용할 수 있습니다.
소비 논리 앱 워크플로의 경우 Azure Portal에 Logic Apps 관리 솔루션(미리 보기)을 설치하고 진단 데이터를 수집하도록 Azure Monitor 로그를 설정할 수 있습니다. 해당 데이터를 Azure Log Analytics 작업 영역으로 보내도록 논리 앱을 설정한 후 원격 분석은 Logic Apps 관리 솔루션이 상태 시각화를 제공할 수 있는 위치로 이동합니다. 자세한 내용은 Azure Monitor 로그 설정 및 Azure Logic Apps에 대한 진단 데이터 수집을 참조하세요. 진단을 사용하도록 설정하면 Azure Monitor를 사용하여 트리거 또는 실행이 실패하는 경우와 같은 다양한 신호 형식에 따라 경고를 보낼 수도 있습니다. 자세한 내용은 실행 상태 모니터링, 트리거 기록 검토 및 Azure Logic Apps에 대한 경고 설정을 참조하세요.
표준 논리 앱 워크플로의 경우 논리 앱 리소스 생성 시 Application Insights를 사용하도록 설정하여 논리 앱의 워크플로에서 진단 로깅 및 추적을 보낼 수 있습니다. Application Insights에서 애플리케이션 맵을 보고 인터페이스의 성능 및 상태 특성을 더 잘 이해할 수 있습니다. Application Insights에는 엔드포인트를 사전에 호출한 다음, 특정 HTTP 상태 코드 또는 페이로드에 대한 응답을 평가하는 가상 테스트를 구성하는 데 가용성 기능도 포함되어 있습니다. 구성된 기준에 따라 관련자에게 알림을 보내거나 추가 오케스트레이션 기능을 위해 웹후크를 호출할 수 있습니다.
서버리스 360은 Azure Logic Apps, Azure Service Bus, Azure API Management 및 Azure Functions와 같은 Azure 서비스 매핑을 통해 모니터링 및 관리를 제공하는 Kovai의 외부 솔루션입니다. Azure Service Bus에서 배달 못 한 편지 큐를 사용하여 메시지를 다시 처리하고, 간헐적인 서비스 중단을 해결하기 위해 자동 복구를 사용하도록 설정하고, 가상 트랜잭션을 통해 사전 모니터링을 설정할 수 있습니다.
포털 환경에서 사용자 지정 모니터링 규칙을 구성하고 로그를 볼 수 있습니다. 이메일, Microsoft Teams 및 ServiceNow와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. 인터페이스의 상태를 시각적으로 확인하기 위해 서비스 맵을 사용할 수 있습니다.
비즈니스 활동 모니터링
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 워크로드에 대한 원격 분석을 모니터링하고 수집하는 옵션을 설명합니다.
BizTalk Server
BizTalk Server에는 개발자와 비즈니스 분석가가 오케스트레이션에 적용할 수 있는 추적 프로필을 정의할 수 있는 BAM(비즈니스 활동 모니터링)이라는 기능이 포함되어 있습니다. 메시지가 수신 및 송신 포트를 통해 이동하면 데이터 특성이 캡처되어 BAM 데이터베이스에 저장됩니다. 사용자 지정 구현은 .NET Fx API를 통해서도 사용할 수 있습니다.
Azure 통합 서비스
Azure에는 동등한 비즈니스 활동 모니터링 기능이 없지만 Application Insights 또는 기타 데이터 플랫폼과 같은 기능을 사용하여 사용자 지정 솔루션을 빌드할 수 있습니다. 워크플로를 실행하는 동안 코드 또는 구성을 계측하여 관련 정보를 이러한 데이터 저장소에 보낼 수 있습니다. 여기서 Power BI를 사용하여 추가 분석 및 시각화를 수행할 수 있습니다. 이 분야의 향후 투자에 대한 자세한 내용은 이 가이드의 뒷부분에 있는 로드맵 섹션을 참조하세요.
또 다른 옵션은 서버리스 360이라는 Kovai의 외부 솔루션을 사용할 수 있다는 것입니다. 모니터링 플랫폼과 함께 클라우드 네이티브 및 하이브리드 통합에서 비즈니스 프로세스 흐름에 대한 엔드투엔드 추적을 제공하는 비즈니스 활동 모니터링 기능을 사용할 수 있습니다. 이 기능에는 개발자가 코드를 계측하고 중요한 비즈니스 데이터를 캡처하는 데 사용할 수 있는 관리형 커넥터가 포함되어 있습니다. 관리자는 이후에 대시보드를 빌드하고 비즈니스 분석가와 공유할 수 있습니다.
추적
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에서 성능 모니터링 및 상태 분석을 위한 아티팩트를 추적하는 옵션을 설명합니다.
BizTalk Server
메시지 추적
BizTalk Server 관리자는 메시지 본문 추적을 사용하여 문제 해결 및 감사 목적으로 메시지 본문을 스토리지에 유지할 시기를 나타낼 수 있습니다. 메시지 추적은 성능 및 스토리지 관점에서 비용이 많이 드는 작업이므로 이 기능을 선택적으로 사용하여 성능 문제를 방지합니다. 수신 및 송신 포트에서 메시지 본문 추적을 사용하도록 설정하면 BizTalk Server는 TrackedMessages_Copy_<message-box-name>이라는 SQL Server 에이전트 작업을 사용하여BizTalk 추적 데이터베이스(BizTalkDTADb)에 데이터를 복사합니다.
오케스트레이션, 파이프라인, 수신 포트, 송신 포트, 스키마 및 비즈니스 규칙을 포함하여 거의 모든 BizTalk Server 아티팩트에서 추적을 적용할 수 있습니다. 이러한 옵션은 코드(솔루션)에 영향을 주거나 다시 시작하지 않고 런타임에 사용하거나 사용하지 않도록 설정됩니다.
HAT(상태 및 활동 추적)
2009 버전부터 HAT 도구가 BizTalk Server에서 제거되었지만 이 기능은 여전히 BizTalk 관리 콘솔 내에 있습니다. 관리자는 그룹 개요 환경 내의 새 쿼리 인터페이스를 통해 데이터를 검색할 수 있습니다. 이벤트 유형, 포트 이름, URI, 스키마 이름 등을 비롯한 다양한 조건에 따라 쿼리를 조정할 수 있습니다. 수신 또는 보내기 포트를 통해 이동한 메시지 본문을 검토하려면 포트 수준 추적을 사용하도록 설정한 경우 이 정보에 액세스할 수 있습니다. 자세한 내용은 상태 및 활동 추적을 참조하세요.
Application Insights 및 Azure Event Hubs와 통합
BizTalk Server 2016 기능 팩 1을 기준으로 Azure Monitor의 Application Insights 또는 Azure Event Hubs에 원격 분석을 게시할 수 있습니다. 이 방법은 SQL Server 디스크 용량 문제를 방지하므로 Application Insights, Log Analytics 및 Azure Logic Apps의 실행 기록과 같은 탄력적 클라우드 기반 데이터 저장소를 대신 사용할 수 있습니다.
Azure 통합 서비스
Azure Logic Apps는 개발자와 지원 분석가가 처리된 모든 입력 및 출력을 포함하여 작업 원격 분석을 통해 작업을 검토할 수 있도록 풍부한 실행 기록을 제공합니다. 중요한 데이터를 보호하기 위해 워크플로의 개별 작업에 보안 입력 및 출력을 사용하도록 설정할 수 있습니다. 이 기능은 누출을 방지하기 위해 로그 및 워크플로 실행 기록의 데이터를 난독 처리하거나 숨깁니다.
데이터 난독 처리 외에도 Azure RBAC 규칙을 사용하여 데이터 액세스를 보호할 수 있습니다. Azure RBAC에는 특히 Azure Logic Apps를 위한 두 가지 기본 제공 역할인 논리 앱 기여자 및 논리 앱 운영자가 포함되어 있습니다.
Azure RBAC 외에도 IP 주소 범위별로 Azure Logic Apps의 실행 기록에 대한 액세스를 제한할 수도 있습니다.
호스팅
다음 섹션에서는 BizTalk Server 및 Azure 통합 서비스에 대한 호스팅 옵션을 설명합니다.
BizTalk Server
BizTalk Server 2020은 다음 Microsoft 플랫폼 및 제품을 지원합니다.
- Windows Server 2019, Windows Server 2016 및 Windows 10
- Visual Studio 2019 Enterprise 및 Visual Studio 2019 Professional
- SQL Server 2019, SQL Server 2017 및 SQL Server 2016 SP2
- Office 2019 및 Office 2016
사용자 고유의 하드웨어, 온-프레미스 가상 머신 또는 Azure 가상 머신에 BizTalk Server를 설치하고 실행할 수 있습니다. Azure 가상 머신은 BizTalk Server, Windows Server, SQL Server 등을 지원하는 광범위한 컴퓨팅 솔루션에 대한 가상화의 유연성을 제공합니다. 모든 현재 세대 가상 머신에는 부하 분산과 자동 크기 조정이 비용 없이 포함됩니다.
Azure 통합 서비스
Azure Logic Apps
호스팅 계획
단일 테넌트 Azure Logic Apps에서 표준 논리 앱은 단일 워크플로 서비스 계획을 사용하여 여러 표준 논리 앱을 호스트할 수 있는 Azure 함수 또는 웹앱과 유사합니다. 이러한 유사성은 단일 표준 논리 앱 리소스에 모든 워크플로를 배포할 필요가 없음을 의미합니다. 대신 이러한 워크플로를 논리 그룹(논리 앱)으로 구성하여 솔루션의 다른 측면을 더 효과적으로 관리할 수 있습니다. 이 방법을 사용하면 워크플로 서비스 계획을 최대한 활용하고 애플리케이션을 미래 지향적으로 구현하여 개별적으로 확장할 수 있습니다.
표준 논리 앱에는 WS1, WS2 및 WS3 가격 책정 계층이 있습니다. 기능적으로 각 계층은 동일한 기능을 제공합니다. 컴퓨팅 및 메모리에 대한 요구 사항은 시나리오에 가장 적합합니다. 예를 들면 다음과 같습니다.
가격 책정 계층 vCPU(가상 CPU) 메모리(GB) WS1 1 3.5 WS2 2 7 WS3 4 14 최신 정보는 표준 모델의 가격 책정 계층을 참조하세요.
가용성 및 중복성
Azure에서 가용성 영역은 복원력, 분산 가용성 및 활성-활성-활성 영역 확장성을 제공합니다. 논리 앱 워크로드의 가용성을 높이기 위해 가용성 영역 지원을 사용하도록 설정할 수 있지만 논리 앱을 만들 때만 가능합니다. 영역 중복을 지원하고 사용하도록 설정하는 모든 Azure 지역에는 3개 이상의 개별 가용성 영역이 필요합니다. Azure Logic Apps 플랫폼은 이러한 영역과 논리 앱 워크로드를 이러한 영역에 분산합니다. 이 기능은 복원력 있는 아키텍처를 사용하도록 설정하고 지역에서 데이터 센터 오류가 발생하는 경우 고가용성을 제공하기 위한 주요 요구 사항입니다. 자세한 내용은 가용성 영역을 사용하여 고가용성을 위한 솔루션 빌드를 참조하세요.
격리된 전용 환경
표준 논리 앱의 경우 배포 환경에 대해 ASE(App Service Environment) v3를 선택할 수 있는 옵션이 있습니다. ASE v3를 사용하면 완전히 격리된 전용 환경을 통해 예측 가능한 가격 책정으로 대규모로 애플리케이션을 실행할 수 있습니다. 만들고 실행하는 논리 앱 수에 관계없이 ASE App Service 요금제에 대해서만 비용을 지불합니다.
Azure Service Bus
Azure Service Bus는 요구 사항에 맞는 최상의 계층을 선택할 수 있도록 다양한 가격 책정 계층을 제공합니다. 엔터프라이즈 환경의 경우 고객은 일반적으로 프리미엄 또는 표준 계층을 선택합니다. 예측 가능한 성능과 고급 네트워킹 지원을 통해 높은 처리량이 필요한 고객의 경우 프리미엄 계층이 더 나은 옵션입니다. 또는 가변 처리량과 더 작은 메시지 처리를 허용할 수 있는 경우 표준 계층이 더 합리적일 수 있습니다. 다음 표에는 두 계층이 요약됩니다.
| 프리미엄 계층 | 표준 계층 |
|---|---|
| 높은 처리량 | 가변 처리량 |
| 예측 가능한 성능 | 가변 대기 시간 |
| 고정된 가격 책정 | 종량제 가변 가격 |
| 작업을 확장 및 축소하는 기능 | 사용할 수 없음 |
| 최대 100MB의 메시지 크기. 큰 메시지 지원을 참조하세요. | 최대 256KB의 메시지 크기 |
최신 정보는 Service Bus 프리미엄 및 표준 메시징 계층을 참조하세요.
Azure API Management
Azure API Management는 요구 사항에 맞는 최상의 계층을 선택할 수 있도록 다양한 가격 책정 계층을 제공합니다. 각 계층에는 고유한 기능이 있으며 Consumption, Developer, Basic, Standard 및 Premium이라는 이름이 지정됩니다.
이러한 계층의 기능은 Microsoft Entra 통합, Azure 가상 네트워크 지원, 기본 제공 캐시, 자체 호스팅 게이트웨이 등에 이르기까지 다양합니다. 이러한 계층 및 해당 기능에 대한 자세한 내용은 Azure API Management 계층의 기능 기반 비교를 참조하세요.
Azure Data Factory
Azure Data Factory는 요구 사항에 맞는 최상의 모델을 선택할 수 있도록 다양한 가격 책정 모델을 제공합니다. 옵션은 Azure Integration Runtime, Azure Managed VNET Integration Runtime 및 자체 호스팅 통합 런타임을 포함하는 런타임 유형에 따라 달라집니다. 각 런타임 제품 내에서 오케스트레이션, 데이터 이동 작업, 파이프라인 작업 및 외부 파이프라인 작업에 대한 지원을 고려합니다. 비용 계획 및 가격 책정에 대한 자세한 내용은 Azure Data Factory의 비용 관리 계획 및 예제를 통해 Data Factory 가격 책정 이해를 참조하세요.
배포
BizTalk Server
BizTalk Server의 네이티브 배포 패키징은 환경 구성 또는 바인딩 파일과 결합된 MSI(Microsoft Installer) 파일을 기반으로 합니다. 이 두 파일은 다음 BizTalk Server 리포지토리에 배포되고 엔드포인트, 비밀, 파이프라인 구성 등을 포함하여 포트 및 파이프라인 수준에서 설정을 정의하는 구성 요소 설치 간에 분리를 만듭니다.
- 관리 DB
- BizTalk Server 로컬 폴더
- .NET 전역 어셈블리 캐시
이 프로세스가 효과적일 수 있지만 각 개별 환경 구성을 코드와 별도로 관리해야 합니다. BizTalk Deployment Framework(BTDF) 오픈 소스 프로젝트는 이 문제에 대한 하나의 솔루션을 제공합니다. 이 도구를 사용하면 디자인 타임에 만드는 토큰화된 바인딩 파일과 각 환경에 대해 Excel 파일로 만드는 토큰 매트릭스를 사용하여 BizTalk Server 솔루션의 일부로 환경 구성을 유지 관리할 수 있습니다.
그런 다음, 빌드 프로세스는 통합되고 버전이 지정된 MSI 파일을 만듭니다. 이 파일은 동일한 패키지의 구성 요소 배포 및 환경 구성을 지원하므로 환경 전반에 걸쳐 구현하려는 솔루션의 버전을 더 잘 제어할 수 있습니다.
CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인의 BTDF 패키지에 대한 지원은 BizTalk Server 2016 기능 팩에 도입된 이 기능을 포함하는 BizTalk Server 2020에서 사용할 수 있습니다. 이 기능과 Azure DevOps 플랫폼을 사용하여 환경 전반에서 BizTalk Server 솔루션의 자동 배포를 간소화할 수 있습니다.
Azure 통합 서비스
Azure 통합 서비스 구성 요소 또는 솔루션을 Azure에 배포하는 경우 다음 항목을 관리해야 합니다.
배포하려는 솔루션의 컨테이너 또는 인프라 역할을 하는 Azure 리소스(예: API Management 인스턴스, 표준 논리 앱 리소스, Service Bus 네임스페이스 또는 Event Grid 토픽)
API, 워크플로, 큐 및 구독과 같은 각 구성 요소에서 구현하는 실제 논리
각 구성 요소와 연결된 환경별 구성(예: 권한, 비밀, 경고 등)
인프라 정의를 코드와 별도로 유지하면 인프라 정의를 버전을 지정하고, 소스 제어 리포지토리에 안전하게 저장하고, 정의가 변경될 때 배포를 트리거할 수 있는 또 다른 코드 조각으로 처리할 수 있습니다. 일반적으로 IaC(Infrastructure as Code)라고 하는 이 사례는 각 환경에 대한 버전을 만들고 변경 내용을 소스 제어로 다시 추적할 수 있으므로 환경 품질을 향상시킵니다.
Azure 통합 서비스는 Azure Resource Management 템플릿을 사용하여 인프라 리소스를 만드는 기능을 제공하여 IaC를 지원합니다. ARM 템플릿은 통합 솔루션으로 이해하고 구현하는 것이 복잡해 보일 수 있지만, 인프라 정의를 만들기 위한 코드와 유사한 환경을 제공하는 Bicep, Terraform 또는 Pulumi와 같은 추상화 도구를 사용할 수 있습니다. 이러한 도구는 ARM 템플릿을 통해 추상화 계층을 제공하지만, 도구는 궁극적으로 ARM 템플릿을 생성하고 이러한 템플릿을 배포할 수 있습니다.
인프라를 사용하면 엔드투엔드 워크플로를 구현하는 논리를 배포할 수 있습니다. Azure 통합 서비스는 통합 워크플로를 구현하기 위한 도구 컬렉션을 제공하므로 각 구성 요소를 배포해야 합니다. Azure 통합 서비스를 사용하여 빌드된 솔루션의 경우 CI/CD 파이프라인은 일반적으로 구성 요소의 오케스트레이션 배포를 기반으로 합니다. DevOps 엔지니어는 배포 작업을 추상화하는 기본 제공 작업을 사용하거나 CLI 명령 또는 PowerShell 및 Bash와 같은 자동화 스크립트를 실행하는 일반 작업을 사용할 수 있습니다. 대부분의 경우 엔지니어는 애플리케이션의 요구 사항에 따라 파이프라인을 사용자 지정하고, 공식 설명서의 지침을 검토하고, 샘플 리포지토리를 시작점으로 사용합니다.
배포를 위해 각 구성 요소를 준비하는 프로세스는 일반적으로 고려 중인 다음 단계를 수행합니다.
연속 통합 단계
소스 코드의 최신 버전을 가져옵니다.
환경별 구성으로 코드를 준비합니다.
이 단계의 세부 정보는 환경 변수의 외부 주입에 대한 각 기술의 지원에 따라 달라집니다. 기본 전제는 연결 문자열 및 외부 리소스에 대한 참조와 같은 환경 기반 구성 정보가 애플리케이션 설정 리포지토리를 참조하도록 추상화된다는 것입니다. 따라서 이 시나리오에서는 애플리케이션 설정 리포지토리에 직접 명확한 텍스트로 존재할 수 있는 참조를 저장하지만 비밀과 같은 중요한 값을 Azure 키 자격 증명 모음과 같은 비밀 저장소의 항목에 대한 참조 포인터로 저장합니다.
Azure Logic Apps를 사용하면 애플리케이션 설정 리포지토리에 대한 참조를 지원하여 표준 논리 앱 리소스에 대해 이 방법을 사용할 수 있습니다. 그러면 이름-값 쌍을 키 자격 증명 모음의 항목에 매핑할 수 있습니다.
Azure API Management의 경우 Azure Key Vault도 지원하는 이름-값 구성을 사용하여 비슷한 결과를 얻을 수 있습니다.
다양한 환경에 배포할 코드를 패키지합니다.
지속적인 배포 단계
대상 환경에 패키지된 코드를 배포합니다.
키 자격 증명 모음의 항목에 대한 명확한 텍스트 또는 참조로 애플리케이션 설정 리포지토리를 올바른 환경 값으로 업데이트합니다.
코드에 따라 필요한 권한을 업데이트합니다.
필요한 경우 애플리케이션 실행을 준비합니다.
기능 매치업
다음 표와 다이어그램은 Azure 통합 서비스와 비교하여 BizTalk Server 간에 리소스, 아티팩트, 기능 및 기능이 일치하는지 방식을 대략적으로 보여 주지만, 매치업은 일대일이 아닙니다. Azure 통합 서비스는 통합 워크로드의 핵심 플랫폼이지만 사용 가능한 모든 Azure 기능을 전체적으로 고려해야 합니다.
| 기능 | BizTalk Server | Azure |
|---|---|---|
| 오케스트레이션 | - BizTalk Server 오케스트레이션 - C# 코드(도우미 클래스 또는 웹 서비스) |
- Azure Logic Apps 워크플로 - Azure Functions 함수 앱 - Azure API 앱 |
| 파이프라인 | - BizTalk Server 파이프라인 - 파이프라인 구성 요소 |
- Azure Logic Apps 워크플로(파이프라인으로) - Azure API Management(파이프라인으로) - Azure Functions 또는 Azure API 앱 |
| 메시지 라우팅 | - MessageBox - 속성 프로모션 - 필터 |
- Azure Service Bus 큐 및 토픽(메시지 헤더, 메시지 속성 및 구독) - Azure Event Grid 또는 Azure API Management - SQL Server 또는 Azure Cache for Redis |
| 애플리케이션 연결 | - BizTalk Server 기본 제공 및 사용자 지정 어댑터 - IIS(인터넷 정보 서비스) 및 Azure API Management(하이브리드 기능) |
- Azure Logic Apps 커넥터 - Azure API Management(커넥터로) - Azure Functions 또는 Azure API 앱 |
| 상호 참조 | xref_ * BizTalk Management 데이터베이스의 테이블(BizTalkMgmtDb) | - Azure Functions - SQL Server - 사용자 지정 |
| 스키마(XSD) | - BizTalk Server 스키마 - XML, JSON 및 플랫 파일 스키마 |
- Azure Logic Apps(사용량) 및 Azure 통합 계정 - Azure Functions 및 Azure Storage 계정 - Azure Logic Apps 및 Azure API 앱 - Azure Logic Apps(표준) |
| 지도 | - BizTalk 맵 편집기 - XSLT 맵 - Azure API Management(하이브리드 기능) |
- Azure Logic Apps(사용량) 및 Azure 통합 계정(XSLT 맵, Liquid) - Azure Functions 및 Azure Storage 계정 - Azure Logic Apps 및 Azure API 앱 - Azure Logic Apps(표준) |
| 비즈니스 규칙 | BizTalk Server 비즈니스 규칙 엔진 | - Azure Functions - SQL Server - 사용자 지정 데이터베이스 |
| 비즈니스 활동 모니터링 | BizTalk Server 비즈니스 활동 모니터링 | - SQL Server - Azure Monitor(Application Insights) - Power BI |
| EDI | - BizTalk Server 기본 제공 기능 - 당사자, 파트너, 계약, AS2, X12, EDIFACT |
Azure Logic Apps 및 Azure 통합 계정(파트너, 계약, AS2, X12, EDIFACT) |
| HL7, RosettaNet 및 SWIFT | HL7, RosettaNet 및 SWIFT용 BizTalk Server 가속기 | - Azure Logic Apps, RosettaNet 및 SWIFT 커넥터 및 Azure 통합 계정 - Azure API Management for FHIR(HL7) - Azure Blueprint: Azure에서 SWIFT CSP 규정 준수를 사용하도록 설정 |
| 비밀 | Enterprise SSO(Single Sign-On) | - Azure Key Vault - SQL Server - 애플리케이션 구성 |
| 보안 및 거버넌스 | - Enterprise SSO(Single Sign-On) - SSO 관련 애플리케이션 - Active Directory - 서명 인증서 - IIS 보안 인증 - 네트워크 보안 |
- Microsoft Entra ID - Azure 네트워크 보안 - Azure RBAC(Azure 역할 기반 액세스 제어) - 클레임, 토큰 - 공유 액세스 정책 |
| 데이터 구성 | - 구성 파일 - Enterprise SSO 애플리케이션 구성 - 사용자 지정 캐시 구성 요소 - 사용자 지정 데이터베이스 - 비즈니스 규칙 엔진 - Windows 레지스트리 |
- Azure Key Vault - Azure App Configuration - Azure Cosmos DB - Azure Table Storage - Azure Logic Apps(표준) 구성 - Azure Functions 구성 - Azure API Management 명명된 값 및 백 엔드 - SQL Server - 사용자 지정 캐싱 - 사용자 지정 데이터베이스 |
| 배포 | - BizTalk Server 바인딩 파일 | - Azure Pipelines - Bicep 스크립트 - Terraform |
| 추적 | - BizTalk Server 추적 기능(수신 포트, 송신 포트, 파이프라인, 오케스트레이션) - IIS 추적 - Azure API Management 기본 제공 분석(하이브리드 기능) |
- Azure Logic Apps 실행 기록 및 추적된 속성 - Azure Storage 계정 - Azure Monitor(Application Insights) - Azure API Management 기본 제공 분석 - 사용자 지정 솔루션(예: Azure Event Hubs+ 및 Azure Functions+ SQL Server+ 및 Azure Data Explorer) |
| 모니터링 | - BizTalk 관리 콘솔 - BizTalk 상태 모니터 |
Azure Monitor(Application Insights, Log Analytics) |
| 작업 | - BizTalk Server 관리 콘솔 - Azure Pipelines - MSI, PowerShell - BizTalk 배포 프레임워크 |
- Azure Portal - Azure Monitor - Azure Resource Manager 템플릿 - Azure Pipelines - PowerShell, CLI, Bicep |
로드맵
워크로드 및 인터페이스를 Azure 통합 서비스로 마이그레이션하는 BizTalk 고객의 요구 사항을 해결하기 위해 Microsoft는 현재 다음 투자의 우선 순위를 지정합니다.
| 시간 프레임 | 기능 투자 |
|---|---|
| 단기 | - XSLT + .NET Framework 지원(공개 미리 보기) - SWIFT MT 인코더 및 디코더(공개 미리 보기) - Azure Logic Apps(표준)에서 사용자 지정 .NET Framework 코드 호출 |
| 중기 | - EDI 및 통합 계정 향상 - 네이티브 XML 지원 - WCF 및 SOAP 지원 - 비즈니스 규칙 엔진 지원 |
| 장기간 | 비즈니스 이벤트 추적 |
최신 투자에 대한 최신 정보를 얻으려면 Azure Blog - Tech Community 통합을 구독하세요.
다음 단계
Azure 통합 서비스를 BizTalk Server와 비교하는 방법에 대해 자세히 알아보았습니다. 다음으로, 시나리오에 가장 적합한 Azure 기능을 선택하는 방법을 알아봅니다. 또는 미리 건너뛰어 제안된 접근 방식과 리소스, 계획 고려 사항 및 마이그레이션에 대한 모범 사례를 검토합니다.