이 문서에서는 고가용성 및 재해 복구 요구 사항을 충족하기 위해 CloudHub 2.0에 응용 프로그램을 배포하기 위한 현재 옵션을 간략하게 설명합니다. 예를 들어 미국 지역을 사용하며 다른 지역에 적용할 수 있습니다.

CloudHub 2.0은 클라우드에서 MuleSoft API 및 통합의 배포, 확장 및 관리를 자동화하여 인프라 오버헤드를 없애는 완전히 관리되는 클라우드 네이티브 통합 플랫폼입니다. 이는 Amazon AWS 인프라에서 실행되는 MuleSoft의 최신 클라우드 배포 플랫폼입니다.

대부분의 경우 CloudHub 2.0에서 제공하는 기본 HA(고가용성) 및 DR(재해 복구)가 충분합니다. CloudHub 2.0은 지역 수준에서 HA 및 DR를 제공합니다(자세한 내용은 CloudHub 2.0 초과 시나리오를 참조하십시오). CloudHub 2.0 지원 HA 및 DR에 대한 자세한 내용은 CloudHub 2.0 주요 고려 사항 섹션을 참조하십시오.

CloudHub 2.0의 기본 가용성 이외의 설계를 요구하는 조건에는 다음이 포함됩니다.

• 응용 프로그램이 재해 시나리오(예: Amazon의 하락 지역)에서 데이터 손실을 방지해야 합니다.
• 응용 프로그램은 개체 저장소에 따라 다르며 배포 영역이 하락하는 경우 연속성을 보장해야 합니다.

• 백엔드 시스템은 동등한 가용성으로 구성됩니다. CloudHub 2.0은 대기열 또는 유사한 메커니즘을 통해 신뢰성을 제공할 수 있지만, 통합이 실시간이든 비동기식이든 상관없이 백엔드 시스템은 유사한 수준의 HA 및 DR를 지원해야 합니다.
• AWS 지역 수준 중단이 백엔드 시스템에 영향을 미치는 경우 복구가 CloudHub 2.0 복구와 동시에 실행되는 것으로 간주됩니다.
• 여러 지역에서 비공개 공간 설정이 완료되었습니다.

이 가이드의 설계 옵션은 전체 AWS 가용성 영역 또는 지역을 사용할 수 없는 경우 CloudHub 2.0에서 응용 프로그램 가용성에 대한 솔루션에 중점을 둡니다.

이 가이드는 이러한 복구 시나리오에 대해 다루는 것은 아니지만 관련된 경우 다음과 같은 영향을 주지 않습니다.

• 온 프레미스 또는 클라우드에서 Anypoint CloudHub 외부에서 관리 및 프로비저닝되는 백엔드 시스템, 응용 프로그램, 데이터베이스, 네트워크 구성 요소, 데이터 센터의 복구
• CloudHub 2.0과 고객의 비공개 데이터 센터(예: IPsec 터널 및 VPN 게이트웨이) 간 VPN 링크 복구 이 가이드의 일부 DR 옵션은 해당 시나리오를 부분적으로 해결할 수 있습니다.
• 통합에 IP 허용 목록이 사용되는 경우 재해 복구 동안 MuleSoft에 대한 변경 사항이 IP를 추출합니다. 이 가이드의 일부 DR 옵션은 해당 시나리오를 부분적으로 해결할 수 있습니다.
• MuleSoft(예: Anypoint MQ) 또는 기타 공급업체(예: AWS MSK 또는 Heroku Kafka)가 제공하는 고객 솔루션에 사용되는 외부 Messaging 시스템입니다.

CloudHub 2.0을 재해 복구 요구 사항에 맞춰 평가할 때 다음의 주요 고려 사항을 고려하십시오.

CloudHub 2.0은 AWS 지역 가용성에 의존합니다.

• CloudHub 2.0은 AWS에서 실행되며, 가용성은 AWS 지역에 연결됩니다.
• 배포 및 응용 프로그램 가용성은 지역별로 정리됩니다. 이러한 지역은 AWS 지역에 해당합니다.

전체 AWS 지역이 실패하면 해당 지역의 응용 프로그램을 사용할 수 없으며 다른 위치에서 자동으로 복제되지 않습니다.

응용 프로그램 고가용성(HA) 및 복제본 관리

• 하드웨어가 실패하면 CloudHub 2.0이 동일한 영역 내에서 응용 프로그램을 자동으로 재배포하지만, 단일 복제본이 있는 응용 프로그램은 가동 중지 시간이 발생할 수 있습니다.
• 복제본이 여러 개인 응용 프로그램은 기본적으로 별도의 가용성 영역에 배포되어 영역 전체에서 HA를 제공합니다.
• 단일 복제 응용 프로그램에 대한 가용성 영역이 실패하면 응용 프로그램이 동일한 영역 내의 다른 가용성 영역에서 자동으로 표시됩니다.

미국 동부 지역 특정 영향

• 미국 동부 지역에 중단되는 경우:
  • CloudHub 2.0 관리 UI 및 배포 REST 서비스를 사용할 수 없으며 새 응용 프로그램을 배포할 수 없습니다.
  • 대부분의 실패 시나리오에서 다른 지역의 응용 프로그램은 영향을 받지 않습니다. 이러한 응용 프로그램은 계속해서 정상적으로 작동하지만, 중단 중에 제어 플레인을 통한 모니터링 및 관리 기능을 사용할 수 없습니다.
  • Core CloudHub 2.0 모듈(응용 프로그램 설정 등)은 미국 동부에서 유지되므로 중단 중에는 설정을 편집할 수 없습니다.

모니터링 및 경고

• status.mulesoft.com을 통해 가용성 영역 또는 지역 수준 오류에 대한 경고를 구성합니다.
• 복제가 실패하거나 응용 프로그램이 응답을 중지할 경우 팀에 알림이 전송되도록 CloudHub 2.0 외부에서 별도의 상태 확인 및 경고 메커니즘을 사용합니다.

데이터 지속성(개체 저장소 V2)

• 객체 저장소 V2는 응용 프로그램이 첫 번째로 배포된 영역에 연결됩니다.
• 응용 프로그램을 다른 영역으로 이동하는 경우 개체 저장소 V2는 데이터 손실을 방지하기 위해 원래 영역에 유지됩니다.
• 개체 저장소 V2가 배포된 영역에 실패할 경우 개체 저장소를 사용할 수 없습니다.

입력 컨트롤러 및 개인 공간

• CloudHub 2.0의 입력 컨트롤러는 지역 수준에서 쉽게 사용할 수 있습니다.
• 공유 공간에서 하나의 영역이 실패하면 다른 영역의 입력 컨트롤러를 계속 사용할 수 있지만 해당 영역에 배포된 응용 프로그램만 제공할 수 있습니다.
• 비공개 공간에서 하나의 영역이 실패하면 사전에 설정하지 않으면 다른 영역의 입력 컨트롤러를 사용할 수 없습니다.
• 비공개 공간 설정은 지역이며, 지역이 실패하면 다른 지역이 설정되지 않는 한 비공개 공간을 사용할 수 없습니다.

개요 플랫폼 서비스 다운 시나리오 – 객체 저장소

고가용성(HA)은 시스템 구성 요소 장애 발생 시 시스템의 액세스 가능성을 측정합니다. 일반적으로 HA는 다중 수준의 오류 허용 및/또는 로드 밸런싱 기능을 시스템에 구축하여 구현됩니다. 일반적으로 활성-활성 구성이며 비즈니스 서비스에 제한되거나 영향을 미치지 않습니다.

재해 복구 (DR)는 재해 시나리오 후 시스템이 자연(예: 홍수, 토네이도, 지진 또는 화재) 또는 인공(예: 전원 중단, 서버 장애 또는 잘못된 구성)으로 이전에 허용되는 상태로 복원되는 프로세스입니다. DR는 일반적으로 활성-패시브 구성이며 비즈니스 서비스에 약간의 영향을 미칩니다.

AWS 지역 장애 발생 시 비즈니스 영향을 줄이기 위해 지역 지역 고가용성 또는 지역 재해 복구를 원할 경우 MuleSoft CloudHub 2.0에서 솔루션을 설계할 때 다음 사항을 고려하십시오.

• CloudHub 2.0 복제본 및 관련 기능(비공개 공간, 입력 컨트롤러, Anypoint MQ 대상)은 지역에 따라 다릅니다.
• 전체 AWS 지역이 실패하면 해당 지역의 모든 복제본 및 연결된 서비스를 사용할 수 없습니다.
• 영역이 복구되면 구성이 복원됩니다. 응용 프로그램을 다시 시작해야 합니다.
• 미국 동부 지역에서 실패하면 Anypoint Platform 서비스(예: 액세스 관리 및 런타임 관리자)도 사용할 수 없습니다.
• MuleSoft는 지역 내의 활성-활성 구성에서 CloudHub 2.0 복제본을 포함하여 플랫폼 서비스에 99.95% 가용성 SLA를 제공합니다. 자세한 내용은 최신 MuleSoft Cloud에서 제공하는 SLA를 참조하십시오.
• CloudHub 2.0은 다중 지역 HA 또는 DR를 기본 지원하지 않으며, 가용성은 단일 지역 내에서만 제공됩니다.

선택한 설정에 관계없이 해당 설계 지침이 적용됩니다.

다중 지역 개인 공간 설정

다음 섹션에 설명된 모든 옵션은 응용 프로그램을 별도의 지역에 배포해야 합니다. 이는 사전 재해 전에 비공개 공간 설정을 완료한 경우에만 가능합니다. 비공개 공간 설정은 지역적이므로, DR 전략을 수행하려면 지역당 하나씩 2개의 비공개 공간과 적절한 VPN 끝점으로 트래픽을 전환하는 메커니즘이 필요합니다.

지역 내에서 고가용성 개인 공간 설정

CloudHub 2.0은 지역 내의 비공개 공간이 실패할 경우 자동 페일오버를 제공하지 않습니다. 해결 방법은 다음이 필요한 여러 환경 전반에 걸친 활성-패시브 설정입니다.

• 비공개 공간에서 여러 VPN 게이트웨이를 구성합니다.
• CloudHub 2.0 지역에 각각 자체 비공개 공간이 있는 별도의 환경을 설정합니다.
• 이러한 환경 중 하나를 패시브로 지정합니다(응용 프로그램이 처음에 배포되지 않지만 기본 비공개 공간이 실패할 경우 가져옵니다).

VPN 게이트웨이가 단일 시점으로 실패하지 않는 고가용성 설정을 하려면 두 지역에 배포하는 것이 가장 적합합니다. 이 시나리오의 VPN 게이트웨이 실패는 영향을 받는 영역을 비공개 공간이 이미 구성된 대체 영역으로 전환하여 해결할 수 있습니다.

제로 메시지 손실

전체 영역이 실패할 때 메시지 손실을 없애려면 응용 프로그램에서 데이터 손실을 방지하고 다음 사항을 해결해야 합니다.

• 외부 Messaging을 사용하여 메시지 신뢰성을 달성합니다.
• 개체 저장소가 특성에 따라 트랜잭션인 비행 중 트랜잭션 데이터에 사용되지 않는지 확인합니다. MuleSoft 응용 프로그램이 처음 배포된 배포 영역이 다운되면 개체 저장소를 사용할 수 없습니다.
• 개체 저장소 읽기 또는 쓰기 작업이 실패할 경우 예외 처리 및 동작 모두에 대해 계속 작동하는 별도의 플로 또는 섹션에 모든 개체 저장소 액세스를 래핑합니다.

참고해 대부분의 경우 DR 요구 사항은 재해 발생 시 메시지 손실을 0으로 보장하지 않아도 되고 데이터 손실이 지정된 기간의 데이터 가치(예: 1시간)보다 작은지 확인해야 합니다.

국가 없는 통합 유지

일반적인 설계 원칙으로 통합의 특성을 유지하는 것이 항상 중요합니다. 즉, 예약된 서비스의 경우 다양한 클라이언트 호출 또는 실행 간에 트랜잭션 정보가 공유되지 않습니다. 시스템 제한으로 인해 일부 데이터가 미들웨어에서 유지해야 하는 경우 MuleSoft 인프라 또는 메모리가 아닌 데이터베이스 또는 Messaging 대기열과 같은 외부 저장소에 유지해야 합니다. 특히 클라우드에서 확장할 때 각 복제본이 사용하는 시/도 및 리소스는 다른 복제본과 독립되어야 한다는 점에 유의해야 합니다. 이 모델은 향상된 성능, 확장성, 신뢰성을 보장합니다.

네트워크 및 트래픽 관리

• 지역 가용성에 필요한 배너리 도메인은 지역 전체의 모든 입력 컨트롤러에 대해 전역 DNS로 작동합니다.
• 글로벌 로드 밸런서는 기본 및 DR 지역 개인 공간 간의 교통을 라우팅합니다. 고객이 이 구성 요소를 제공합니다. 라우팅 정책과 함께 AWS Route 53 또는 전역 CDN을 사용하여 지역 전체에서 트래픽을 라우팅합니다.
• 사용자 정의 Vanity 도메인을 사용하여 기본 및 DR 영역 모두에서 접속 컨트롤러를 구성합니다.
• 기본 및 DR 영역 비공개 공간 모두에서 온 프레미스 응용 프로그램에 액세스할 수 있도록 방화벽 규칙 및 VPN 터널링을 계획하고 유지합니다.
• 원활한 복구를 위해 TLS 인증서 유지 보수는 기본 및 DR 지역의 개인 공간을 모두 포함해야 합니다.

응용 프로그램 배포 및 구성

• 응용 프로그램 이름은 지역 간에 고유해야 합니다. 예를 들어 CI/CD 파이프라인은 배포 전에 응용 프로그램 이름에 지역 이름(또는 지역 코드)을 추가하여 기본 및 DR 지역 전체에서 고유성을 유지할 수 있습니다.
• CI/CD 파이프라인을 구성하여 두 지역 모두에서 모든 응용 프로그램을 사용할 수 있도록 기본 및 DR 영역 모두에 응용 프로그램을 배포합니다.

인프라 및 수용력
모든 인프라의 기본 및 DR 영역 용량이 동일한 경우 성능이 가장 우수합니다. 이러한 인프라 측면이 동일하지 않을 경우 성능이 저하됩니다.

데이터 지속성 및 저장

• 두 영역 간에 주기적으로 동기화해야 하는 지속 스토리지입니다. 고객은 저장소 복제를 책임지고 MuleSoft는 이를 제공하지 않습니다. 기본 및 DR 영역의 VPC 간에 단일 공유 저장소를 사용할 수 있지만 공유 저장소는 고가용성이 있어야 합니다. 그렇지 않으면 두 영역 모두에 단일 장애가 발생합니다.
• Object Store V2는 지역적이며 Mule 애플리케이션이 처음 배포된 지역에서만 사용할 수 있습니다. 응용 프로그램이 다른 영역으로 이동하는 경우 데이터 손실을 방지하기 위해 개체 저장소 V2가 원래 영역에 남아 있게 됩니다. 다중 지역 DR 전략에 다른 영구 저장소를 사용합니다.

시험 및 운영 절차

공식적인 DR 테스트 전략을 채택하고 정기적인 DR 드릴을 실행합니다. 활성 활성 DR의 경우 Canary 배포 전략을 사용하여 두 지역을 모두 확인합니다.

성능 및 서비스 수준 계약(SLA)

DR 영역이 기본 영역보다 최종 사용자 또는 백엔드 시스템에서 멀리 떨어져 있어 일부 성능이 저하될 수 있습니다. DR SLA를 정의하고 이해당사자에게 전달합니다.

복구 모드 동작(상관 사항 참고)

활성 활성 모드에서 기본 영역에서 DR 영역의 비공개 공간으로 페일오버는 빠릅니다. 전역 로드 밸런처가 기본이 건강하지 않음을 감지하고 트래픽을 정상(DR) 영역으로 라우팅합니다. 활성-패시브 모드에서 재해가 발생하면 DR 영역 비공개 공간에 응용 프로그램을 배포해야 합니다.

세 가지 옵션으로 DR 수준 가용성을 높일 수 있습니다.

액티브 구성

활성 활성 설정은 외부 로드 밸런서를 사용하여 두 인스턴스 간의 트래픽을 라우팅하는 지역 전체에 분포된 활성 작업자를 기반으로 합니다.

Warm Standby 구성
활성-패시브 설정은 한 지역의 활성 작업자와 다른 지역의 패시브 작업자를 기반으로 합니다. 필요한 경우 패시브 영역이 시작됩니다.

페일오버를 위해 일부 패시브 영역 요소는 활성 상태를 유지하거나 사전 설정해야 합니다(예: 비공개 공간, VPN 및 전송 게이트웨이 첨부 파일).

Cold Standby 구성

위에서와 같이 복제본 및 수집 컨트롤러는 페일오버 시 완전히 자동화된 DevOps 프로세스를 통해 두 번째 영역에서 프로비저닝됩니다. 비공개 공간, VPN 및 전송 게이트웨이 첨부 파일 등 패시브 영역의 일부 요소는 페일오버를 위해 활성 상태로 유지해야 합니다.

CloudHub 2.0 네트워킹 아키텍처의 기본 구성 요소는 다음과 같습니다.

• HTTP 로드 밸런서
• 복제본 DNS 레코드 모음
• 비공개 공간
• 지역 서비스

자세한 내용은 CloudHub 2.0 네트워킹 아키텍처를 참조하십시오.

Vanity 도메인

비공개 공간이 생성되면 <space-id>.<region>.cloudhub.io 형식의 DNS 대상 이름이 수신됩니다. 해당 비공개 공간에서 test-api라는 앱을 배포하면 끝점이 다음 형식을 따릅니다.

CloudHub 2.0은 TLS 컨텍스트 및 DNS 레코드를 사용하여 비공개 공간 내에서 사용자 정의 또는 비활성 도메인을 구성하여 지원합니다. 비공개 공간의 런타임 관리자에서 TLS 컨텍스트를 만들려면 공개 인증서 및 비공개 키를 업로드한 다음, 응용 프로그램의 설정에 사용자 정의 끝점을 추가하여 해당 도메인을 사용합니다. 비공개 공간의 기본 호스트 이름을 비공개 공간 도메인을 가리키는 DNS 레코드(예: CNAME)를 만듭니다.

예를 들어, 기본 DNS 42y52r.usa-w2.cloudhub.io를 사용하여 us-west-2에 배포된 test-api라는 응용 프로그램의 API 끝점은 다음과 같습니다.

https://test-api-mwsklu-42y52r.usa-w2.cloudhub.io

이 URL은 배너리 또는 사용자 정의 도메인을 사용하지 않습니다. API URL이 https://test-api.acme.com으로 표시되도록 acme.com을 사용하려면 다음 단계를 수행합니다.

1. 공개 및 비공개 키를 사용하여 런타임 관리자에서 TLS 컨텍스트를 만듭니다.
2. 응용 프로그램의 설정에 유휴 도메인을 추가하여 해당 도메인을 사용합니다.
3. AWS 경로 53에서 DNS 레코드를 만들고 간단한 라우팅 정책(예: CNAME)을 구성하여 공백 도메인이 비공개 공간의 기본 호스트 이름으로 확인됩니다.

사용자 정의 도메인의 경우 라우팅 정책과 함께 AWS Route 53 또는 기타 모든 글로벌 CDN 서비스를 사용할 수 있습니다. 아래 다이어그램에서 AWS 경로 53는 "간단한" 라우팅 정책과 함께 사용됩니다. 공개(외부) 네트워크의 소비자가 acme.com을 요청하면 AWS 경로 53가 MuleSoft 비공개 공간 진입 컨트롤러로 요청을 라우팅합니다.

응용 프로그램에 페일오버가 필요한 경우 이 옵션을 사용합니다. 기본 영역(예: us-west-2)에서 하나의 인스턴스와 보조 영역(예: us-east-1)에서 다른 인스턴스를 배포합니다.

가능한 경우 보조 지역의 기존 환경을 사용하십시오. 새 환경을 만들려면 추가 노력이 필요합니다.

다른 지역으로 페일오버된 한 지역(미국 서부 2)에 배포된 앱의 예(미국 동부 1)

이 구성에서 AWS 경로 53는 미국 서부 2 및 미국 동부 1의 비공개 공간에 대한 입력 컨트롤러로 트래픽을 라우팅합니다. 상태 확인을 사용하여 페일오버 라우팅 정책이 구성됩니다.

대기 시간과 고가용성을 줄이려면 다이어그램에 설명된 배포 전략을 사용하십시오. 이 전략을 사용하면 두 지역(이 예에서는 us-west-2 및 us-east-1)에서 앱을 배포할 수 있습니다.

AWS 경로 53의 대기 시간 라우팅 정책을 사용하여 높은 가용성을 유지하면서 가장 낮은 대기 시간을 제공하는 지역으로 요청을 라우팅합니다. AWS 경로 53의 "대기 시간" 라우팅 정책은 여전히 높은 가용성이 있는 낮은 대기 시간에 대한 요청을 라우팅합니다.

애플리케이션 두 지역 모두에 배포(미국 서부 2개 및 미국 동부 1개)로 낮은 지연 시간 및 높은 가용성을 제공합니다.

MuleSoft CloudHub 2.0은 기본적으로 자동 복제 중복 및 지능형 로드 밸런싱을 활용하여 지역 내 복원에 견고한 기반을 제공합니다. 단일 클라우드 지역 내에서 복제본이 여러 개 있는 응용 프로그램을 배포하면 하나의 인스턴스가 실패할 경우 다른 인스턴스가 작업 부하를 즉시 차단할 수 있습니다. 통합 로드 밸런처는 정상적인 복제본 전체에서 수신 트래픽을 효율적으로 배포하여 가동 중지 시간을 최소화하고 정상적인 운영 조건에서 지속적인 서비스 가용성을 보장합니다.

그러나 이 중복성이 높은 단일 영역 아키텍처에만 의존하는 경우에도 광범위하고 재해적인 지역 중단의 상당한 위험이 있습니다. 역사적으로 가장 신뢰할 수 있고 기술적으로 고급 클라우드 공급자도 전체 지리적 지역에 영향을 미칠 수 있는 중단 사고에 취약하다는 사실을 알 수 있습니다. 드물지만 이러한 단일 실패는 다음을 포함한 다양한 이벤트로 인해 발생할 수 있습니다.

• 대규모 인프라 사고
• 주요 전원 장애
• 광범위한 네트워크 중단

따라서 진정한 고가용성(HA) 및 재해 복구(DR)를 달성하려면 단일 지역 모델의 제한 사항을 초과하도록 아키텍처를 설계해야 합니다. 권장하는 전략은 여러 지리적으로 구별되는 지역에 대한 배포입니다. 이 지역 간 복원 기능을 통해 예기치 않은 재해로 인해 전체 클라우드 영역을 사용할 수 없게 되면 별도의 영향을 받지 않는 영역에서 실행되는 응용 프로그램 인스턴스에 대한 트래픽이 원활하게 실패하여 서비스 중단을 최소화하고 가동 시간 목표를 극대화할 수 있습니다.

CloudHub 2.0 Networking Architecture

표준 대기열에 대한 지역 간 장애 복구 구성

개체 저장소 V2 배포 지역

개체 저장소 배포 지역

Gulal Kumar는 데이터 및 통합 아키텍처에 중점을 둔 Salesforce의 소프트웨어 엔지니어링 아키텍처입니다. 통합 및 API, 현대화 프로그램, 보안, AIML 이니셔티브 분야에서 20년 이상의 경험을 보유한 그는 풍부한 전문 지식을 제공합니다. Gulal은 비즈니스 전환 이니셔티브를 발전시키고, 보안 및 복원 능력을 향상하고, 아키텍처 우수성을 촉진하고, 다양한 도메인 전반에 걸쳐 AIML 이니셔티브를 선도하기 위해 노력하고 있습니다.

Ajay Nagaraju는 엔터프라이즈 아키텍처, 시스템 통합, 대규모 디지털 변환 분야에서 28년 이상의 경험을 보유한 MuleSoft의 엔터프라이즈 아키텍처 및 선임 디렉터입니다. 그는 Fortune 100대 기업과 Fortune 500대 기업에서 복잡한 수백만 달러의 프로그램에 대한 아키텍처 및 전달을 이끌었으며 API 기반 연결, SOA, 클라우드 기술, 엔터프라이즈 통합 패턴에 대한 깊은 전문 지식을 보유하고 있습니다. Ajay는 비즈니스 프로세스, 데이터 플랫폼, 통합 생태계를 현대화하기 위해 경영진과 긴밀한 파트너 관계를 맺고 있으며, 기술을 통해 확장 가능한 아키텍처를 구축하고, 팀을 멘토링하고, 측정 가능한 비즈니스 결과를 촉진하는 데 열정적입니다.