Azure Logic Apps의 안정성
이 문서에서는 가용성 영역 및 다중 지역 배포를 통한 지역 내 복원력을 다루는 Azure Logic Apps의 안정성 지원에 대해 설명합니다.
복원력은 사용자와 Microsoft 간의 공동 책임이므로 이 문서에서는 요구 사항을 충족하는 복원력 있는 솔루션을 만드는 방법도 다룹니다.
논리 앱 워크플로를 사용하면 작성해야 하는 코드 범위를 줄여 앱, 클라우드 서비스, 온-프레미스 시스템 간에 데이터를 보다 쉽게 통합하고 오케스트레이션할 수 있습니다. 복원력을 계획할 때 논리 앱뿐만 아니라 논리 앱과 함께 사용하는 이러한 Azure 리소스도 고려해야 합니다.
연결 - 논리 앱 워크플로에서 다른 앱, 서비스, 시스템으로의 연결을 만듭니다. 자세한 내용은 이 항목의 뒷부분에 나오는 리소스에 대한 연결을 참조하세요.
온-프레미스 데이터 게이트웨이- 온-프레미스 시스템의 데이터에 액세스하기 위해 논리 앱에서 만들고 사용하는 Azure 리소스입니다. 각 게이트웨이 리소스는 로컬 컴퓨터에 있는 별도의 데이터 게이트웨이 설치를 나타냅니다. 여러 컴퓨터를 사용하여 고가용성을 위해 온-프레미스 데이터 게이트웨이를 구성할 수 있습니다. 자세한 내용은 고가용성 지원을 참조하세요.
논리 앱 워크플로가 B2B(Business-to-Business) 엔터프라이즈 통합 시나리오에 사용하는 아티팩트 정의 및 저장을 위한 통합 계정입니다. 예를 들어 통합 계정에 대해 지역 간 재해 복구를 설정할 수 있습니다.
다중 테넌트 Azure Logic Apps는 소비 워크플로에 대한 컴퓨팅 인프라 및 리소스를 자동으로 관리합니다. VM(가상 머신)을 구성하거나 관리할 필요가 없습니다. 소비 워크플로는 많은 고객 간에 컴퓨팅 인프라를 공유합니다.
단일 테넌트 Azure Logic Apps는 전용 컴퓨팅 리소스에서 표준 워크플로를 실행합니다. 이 워크플로는 전용이며 계획이라고 합니다. 각 계획에는 여러 인스턴스가 있을 수 있으며, 이러한 인스턴스는 필요에 따라 여러 가용성 영역에 분산될 수 있습니다. 워크플로는 계획의 인스턴스에서 실행됩니다.
프로덕션 배포 권장 사항
격리 또는 네트워크 보안 요구 사항이 있는 엔터프라이즈 및 보안 워크플로의 경우 다중 테넌트 Azure Logic Apps의 소비 워크플로 대신 단일 테넌트 Azure Logic Apps에서 표준 워크플로를 만들고 실행하는 것이 좋습니다. 자세한 내용은 만들기 및 다른 환경에 배포를 참조 하세요.
단일 테넌트 Azure Logic Apps를 사용하는 프로덕션 배포의 경우 영역 중복을 사용하도록 설정하여 논리 앱 리소스를 여러 가용성 영역에 분산해야 합니다.
일시적인 오류
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 그들은 짧은 기간 후에 자신을 수정합니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리하는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure의 일시적인 오류 처리 지침을 따라야 합니다. 일시적인 오류 처리에 대한 자세한 내용은 일시적인 오류를 전달하기 위한 권장 사항을 참조 하세요.
Azure Logic Apps에서 많은 트리거 및 작업은 일시적 오류로 인해 실패한 요청을 자동으로 다시 시도하는 재시도 정책을 자동으로 지원합니다. 논리 앱에 대한 재시도 정책을 변경하거나 사용하지 않도록 설정하는 방법을 알아보려면 Azure Logic Apps의 오류 및 예외 처리를 참조하세요.
작업이 실패하면 후속 작업의 동작을 사용자 지정할 수 있습니다. 함께 실패하거나 성공할 수 있는 관련 작업을 그룹화하기 위한 범위를 만들 수도 있습니다.
Azure Logic Apps의 오류 처리에 대한 자세한 내용은 Azure Logic Apps의 오류 및 예외 처리를 참조 하세요.
가용성 영역 지원
가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.
Azure의 가용성 영역에 대한 자세한 내용은 가용성 영역이란?을 참조하세요.
Azure Logic Apps는 여러 가용성 영역에 컴퓨팅 리소스를 분산하는 영역 중복성을 지원합니다. 가용성 영역에 논리 앱 워크로드 리소스를 배포하면 프로덕션 논리 앱 워크로드의 복원력과 안정성이 향상됩니다.
다중 테넌트 Azure Logic Apps의 신규 및 기존 소비 논리 앱 워크플로는 자동으로 영역 중복을 사용하도록 설정됩니다.
단일 테넌트 Azure Logic Apps에서 워크플로 서비스 계획 호스팅 옵션을 사용하는 표준 워크플로의 경우 선택적으로 영역 중복을 사용하도록 설정할 수 있습니다.
App Service Environment v3 호스팅 옵션을 사용하는 표준 워크플로의 경우 선택적으로 영역 중복을 사용하도록 설정할 수 있습니다. App Service Environments v3에서 가용성 영역을 지원하는 방법에 대한 자세한 내용은 App Service의 안정성을 참조하세요.
지원되는 지역
가용성 영역을 지원하는 모든 지역에 배포되는 소비 논리 앱은 자동으로 영역 중복됩니다. 일본 서부는 일부 종속성 서비스가 아직 영역 중복을 지원하지 않기 때문에 현재 영역 중복 논리 앱을 지원하지 않는 예외입니다.
Azure 앱 Service에 대한 가용성 영역을 지원하는 모든 지역에서 워크플로 서비스 계획을 사용하여 영역 중복 표준 논리 앱을 배포할 수 있습니다. 일본 서부는 현재 영역 중복 논리 앱을 지원하지 않는 예외입니다. 자세한 내용은 Azure 앱 Service의 안정성을 참조하세요.
App Service Environment v3의 가용성 영역을 지원하는 지역을 보려면 지역을 참조하세요.
요구 사항
워크플로 서비스 계획의 인스턴스를 세 개 이상 배포해야 합니다. 각 인스턴스는 대략 하나의 VM에 해당합니다. 이러한 인스턴스(VM)를 가용성 영역에 분산하려면 최소 3개의 인스턴스가 있어야 합니다.
고려 사항
- 스토리지: 상태 저장 표준 워크플로에 대한 외부 스토리지를 구성할 때 영역 중복성을 위해 스토리지 계정을 구성해야 합니다. 자세한 내용은 Azure Functions의 스토리지 고려 사항을 참조하세요.
커넥터: 논리 앱이 영역 중복일 때 기본 제공 커넥터는 자동으로 영역 중복됩니다.
통합 계정: 프리미엄 SKU 통합 계정은 기본적으로 영역 중복입니다.
비용
다중 테넌트 Azure Logic Apps의 신규 및 기존 소비 워크플로에 대해 자동으로 사용하도록 설정되는 영역 중복을 사용하는 데 추가 비용은 적용되지 않습니다.
단일 테넌트 Azure Logic Apps에서 워크플로 서비스 계획을 사용하는 표준 워크플로가 있는 경우 계획의 인스턴스가 3개 이상 있는 한 가용성 영역을 사용하도록 설정하는 데 추가 비용이 적용되지 않습니다. 자동 크기 조정 기준에 따라 플랜 SKU, 지정된 용량 및 스케일 업 또는 스케일 다운된 모든 인스턴스에 따라 요금이 청구됩니다. 가용성 영역을 사용하도록 설정하지만 3개 미만의 인스턴스 용량을 지정하는 경우 플랫폼은 최소 3개의 인스턴스를 적용하고 이러한 세 인스턴스에 대해 요금을 청구합니다.
App Service Environment v3에는 영역 중복에 대한 특정 가격 책정 모델이 있습니다. App Service Environment v3에 대한 가격 책정 정보는 가격 책정을 참조하세요.
가용성 영역 지원 구성
소비 논리 앱 워크플로는 영역 중복을 자동으로 지원하므로 구성이 필요하지 않습니다.
영역 중복을 사용하여 새 워크플로를 만듭니다.
표준 논리 앱 워크플로에 영역 중복을 사용하도록 설정하려면 논리 앱에 대한 영역 중복 사용 설정을 참조하세요.
마이그레이션
서비스 계획을 만든 후에는 영역 중복을 사용하도록 설정할 수 없습니다. 대신 영역 중복을 사용하도록 설정된 새 계획을 만들고 이전 계획을 삭제해야 합니다.
영역 중복을 사용하지 않도록 설정합니다.
워크플로 서비스 계획을 만든 후에는 영역 중복을 사용하지 않도록 설정할 수 없습니다. 대신 영역 중복이 비활성화된 새 계획을 만들고 이전 계획을 삭제해야 합니다.
용량 계획 및 관리
가용성 영역 오류 에 대비하려면 서비스의 용량을 과도하게 프로비전하는 것이 좋습니다. 오버 프로비저닝을 사용하면 솔루션이 어느 정도의 용량 손실을 허용하고 성능 저하 없이 계속 작동할 수 있습니다.
오버 프로비전할 인스턴스 수를 확인하려면 플랫폼이 여러 영역에 걸쳐 인스턴스를 분산한다는 것을 알아야 합니다. 하나 이상의 영역 실패를 고려해야 합니다.
다음 단계에 따라 프로비전해야 하는 총 인스턴스 수를 확인합니다.
- 최대 워크로드에 필요한 인스턴스 수를 결정합니다. 이 예제에서는 두 가지 시나리오를 사용합니다. 하나는 인스턴스가 3개이고 하나는 4개입니다.
- 최대 워크로드 인스턴스 수를 [(zones/(zones-1)] 요소에 곱하여 오버 프로비전 인스턴스 수를 검색합니다.
참고 항목
다음 표에서는 세 가지 가용성 영역을 사용한다고 가정합니다. 다른 수의 가용성 영역을 사용하는 경우 그에 따라 수식을 조정합니다.
최대 워크로드 인스턴스 수 | [(zones/(zones-1)] 요소 | 수식 | 프로비전할 인스턴스(반올림됨) |
---|---|---|---|
3 | 3/2 또는 1.5 | (3 x 1.5 = 4.5) | 인스턴스 5개 |
4 | 3/2 또는 1.5 | (4 x 1.5 = 4.5) | 인스턴스 6개 |
영역 간 트래픽 라우팅
정상적인 작업 중에 워크플로 호출은 지역 내의 가용성 영역에서 컴퓨팅 리소스를 사용할 수 있습니다.
정상적인 작업 중에 워크플로 호출은 사용 가능한 모든 계획 인스턴스 간에 모든 가용성 영역에 분산됩니다.
영역 다운 환경
검색 및 응답: Azure Logic Apps 플랫폼은 가용성 영역에서 오류를 감지하는 역할을 담당합니다. 영역 장애 조치(failover)를 시작하기 위해 아무 작업도 수행할 필요가 없습니다.
활성 요청: 가용성 영역을 사용할 수 없게 되면 잘못된 가용성 영역의 VM에서 실행되는 진행 중인 워크플로 실행이 종료됩니다. Azure Logic Apps 플랫폼은 다른 가용성 영역의 다른 VM에서 워크플로를 자동으로 다시 시작합니다. 이 동작으로 인해 새 VM이 나머지 가용성 영역에 추가됨에 따라 활성 워크플로에 일시적인 오류 또는 더 높은 대기 시간이 발생할 수 있습니다.
장애 복구(Failback)
가용성 영역이 복구되면 Azure Logic Apps는 가용성 영역의 인스턴스를 자동으로 복원하고, 다른 가용성 영역에서 만든 임시 인스턴스를 제거하고, 인스턴스 간의 트래픽을 정상적으로 다시 라우팅합니다.
영역 오류 테스트
Azure Logic Apps 플랫폼은 영역 중복 논리 앱 리소스에 대한 트래픽 라우팅, 장애 조치(failover) 및 장애 복구(failback)를 관리합니다. 아무것도 시작할 필요가 없습니다. 이 기능은 완전히 관리되므로 가용성 영역 오류 프로세스의 유효성을 검사할 필요가 없습니다.
다중 지역 지원
각 논리 앱은 단일 Azure 지역에 배포됩니다. 지역을 사용할 수 없게 되면 논리 앱도 사용할 수 없습니다.
대체 다중 지역 접근 방식
복원력을 높이기 위해 보조 지역에 대기 또는 백업 논리 앱을 배포하고 주 지역을 사용할 수 없는 경우 다른 지역으로 장애 조치(failover)할 수 있습니다. 이 기능을 사용하도록 설정하려면 다음 작업을 완료합니다.
- 주 지역과 보조 지역 모두에 논리 앱을 배포합니다.
- 필요에 따라 리소스에 대한 연결을 다시 구성합니다.
- 부하 분산 및 장애 조치(failover) 정책을 구성합니다.
- 기본 인스턴스 상태를 모니터링하고 장애 조치(failover)를 시작하도록 계획합니다.
논리 앱 워크플로에 대한 다중 지역 배포에 대한 자세한 내용은 다음 설명서를 참조하세요.
- Azure Logic Apps의 다중 지역 배포
- Azure Logic Apps에서 통합 계정에 대한 지역 간 재해 복구 설정
- Azure Logic Apps를 사용하여 Azure 리소스에 대한 복제 작업 만들기
서비스 수준 약정
Azure Logic Apps에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성을 설명합니다. 이 계약은 또한 이러한 기대를 달성하기 위해 충족할 조건에 대해서도 설명합니다. 이러한 조건을 이해하려면 온라인 서비스에 대한 SLA(서비스 수준 계약)를 검토 해야 합니다.