Azure의 중요 업무용 워크로드를 위한 데이터 플랫폼

중요 업무용 아키텍처에서는 모든 상태를 가능한 한 컴퓨팅 외부에 저장해야 합니다. 기술의 선택은 다음과 같은 주요 아키텍처 특성을 기반으로 합니다.

이 아키텍처에는 두 개의 데이터 저장소가 있습니다.

• Database

  워크로드와 관련된 저장소입니다. 모든 상태는 지역 스탬프와 분리된 데이터베이스에 전역적으로 저장되는 것이 좋습니다. 여러 지역에 데이터베이스를 배포하여 중복성을 구축합니다. 중요 업무용 워크로드의 경우 지역 간 데이터 동기화가 주요 관심사여야 합니다. 또한 실패가 발생한 경우에도 데이터베이스에 대한 쓰기 요청이 계속 작동해야 합니다.

  활성-활성 구성의 데이터 복제를 사용하는 것이 좋습니다. 애플리케이션은 다른 지역과 즉시 연결할 수 있어야 합니다. 모든 인스턴스는 읽기와 쓰기 요청을 처리할 수 있어야 합니다.

• 메시지 브로커

  지역 스탬프의 유일한 상태 저장 서비스는 짧은 기간 동안 요청을 저장하는 메시지 브로커입니다. 브로커는 버퍼링과 신뢰할 수 있는 메시징에 대한 요구를 충족합니다. 처리된 요청은 글로벌 데이터베이스에 유지됩니다.

기타 데이터 고려 사항은 잘 설계된 프레임워크의 중요 업무용 지침: 데이터 플랫폼 고려 사항을 참조하세요.

데이터베이스

이 아키텍처는 Azure Cosmos DB for NoSQL을 사용합니다. 이 옵션은 이 설계에 필요한 대부분의 기능을 제공하므로 선택됩니다.

• 다중 지역 쓰기

  스탬프가 배포된 모든 지역에 배포된 복제본으로 다중 지역 쓰기를 사용하도록 설정됩니다. 각 스탬프는 로컬로 작성할 수 있으며 Azure Cosmos DB는 스탬프 간의 데이터 복제와 동기화를 처리합니다. 이 기능은 애플리케이션의 지리적으로 분산된 최종 사용자의 대기 시간을 크게 줄입니다. Azure 중요 업무용 참조 구현은 다중 마스터 기술을 사용하여 최대 복원력과 가용성을 제공합니다.

  복제된 각 지역 내에서도 영역 중복을 사용하도록 설정됩니다.

  다중 지역 쓰기에 대한 자세한 내용은 Azure Cosmos DB를 사용하는 애플리케이션에서 다중 지역 쓰기 구성을 참조하세요.

• 충돌 관리

  여러 지역에서 쓰기를 수행하는 기능을 사용하면 동시 쓰기가 레코드 충돌을 일으킬 수 있으므로 충돌 관리 모델을 채택해야 합니다. Last Writer Wins는 기본 모델이며 중요 업무 설계에 사용됩니다. 레코드의 연결된 타임스탬프로 정의된 마지막 기록기가 충돌에서 승리합니다. Azure Cosmos DB for NoSQL을 사용하면 사용자 지정 속성을 정의할 수도 있습니다.

• 쿼리 최적화

  많은 수의 파티션이 있는 읽기 집약적인 컨테이너에 대한 일반적인 쿼리 효율성 권장 사항은 식별된 itemID로 같음 필터를 추가하는 것입니다. 쿼리 최적화 권장 사항에 대한 심층 검토는 Azure Cosmos DB를 사용할 때 쿼리 문제 해결에서 찾을 수 있습니다.

• 백업 기능

  데이터 보호를 위해 Azure Cosmos DB의 네이티브 백업 기능을 사용하는 것이 좋습니다. Azure Cosmos DB 백업 기능은 온라인 백업과 주문형 데이터 복원을 지원합니다.

워크로드에 대한 데이터 모델

기존 관계형 데이터베이스에서 제공하는 기능이 필요하지 않도록 데이터 모델을 설계해야 합니다. 예를 들어 외래 키, 엄격한 행/열 스키마, 보기 등이 있습니다.

워크로드에는 다음과 같은 데이터 액세스 특성이 있습니다.

• 읽기 패턴:
  • 포인트 읽기 - 단일 레코드를 가져옵니다. 항목 ID와 파티션 키는 최대 최적화(요청당 1RU)에 직접 사용됩니다.
  • 목록 읽기 - 목록에 표시할 카탈로그 항목을 가져옵니다. 결과 수에 제한이 있는 FeedIterator가 사용됩니다.
• 쓰기 패턴:
  • 작은 쓰기 - 요청은 일반적으로 트랜잭션에 단일 또는 적은 수의 레코드를 삽입합니다.
• 수백만 명의 사용자 순서대로 트래픽 수요를 처리하도록 스케일링할 수 있는 기능을 사용하여 최종 사용자의 높은 트래픽을 처리하도록 설계되었습니다.
• 작은 페이로드 또는 데이터 세트 크기 - 일반적으로 KB 순서입니다.
• 낮은 응답 시간(밀리초 순서).
• 짧은 대기 시간(밀리초 순서).

구성

Azure Cosmos DB는 다음과 같이 구성됩니다.

• 일관성 수준은 단일 지역과 전역적으로 분산된 애플리케이션에 가장 널리 사용되는 수준이므로 기본 세션 일관성으로 설정됩니다. 쓰기 처리의 비동기 특성으로 인해 처리량이 더 높은 약한 일관성은 필요하지 않으며 데이터베이스 쓰기에 대한 짧은 대기 시간이 필요하지 않습니다.

  참고

  세션 일관성 수준은 이 특정 애플리케이션에 대한 대기 시간, 가용성, 일관성 보장에 대한 적절한 절충을 제공합니다. 다중 마스터 쓰기 데이터베이스에는 강력한 일관성 수준을 사용할 수 없다는 점을 이해하는 것이 중요합니다.

• 파티션 키는 모든 컬렉션에 대해 /id로 설정됩니다. 이 결정은 주로 “GUID를 ID로 사용하여 새 문서 작성”과 “ID로 광범위한 문서 읽기”인 사용 패턴을 기반으로 합니다. 애플리케이션 코드가 ID 고유성을 유지하면 Azure Cosmos DB를 통해 새 데이터가 파티션에 고르게 분산되어 무한 스케일링이 가능합니다.

• 인덱싱 정책은 쿼리를 최적화하기 위해 컬렉션에 구성됩니다. RU 비용과 성능을 최적화하기 위해 사용자 지정 인덱싱 정책이 사용됩니다. 이 정책은 쿼리 조건자에 사용되는 속성만 인덱싱합니다. 예를 들어 애플리케이션은 주석 텍스트 필드를 쿼리의 필터로 사용하지 않습니다. 이는 사용자 지정 인덱싱 정책에서 제외되었습니다.

다음은 Terraform을 사용하여 인덱싱 정책 설정을 보여 주는 구현의 예제입니다.

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

이 아키텍처의 애플리케이션에서 Azure Cosmos DB로의 연결에 대한 자세한 내용은 중요 업무용 워크로드에 대한 애플리케이션 플랫폼 고려 사항을 참조하세요.

메시징 서비스

중요 업무용 시스템은 메시지 또는 이벤트 처리를 위해 메시징 서비스를 활용하는 경우가 많습니다. 이러한 서비스는 느슨한 결합을 촉진하고 예기치 않은 수요 급증으로부터 시스템을 보호하는 버퍼 역할을 합니다.

• Azure Service Bus는 높은 가치가 있는 메시지를 처리할 때 메시지 기반 워크로드에 권장됩니다.
• Azure Event Hubs는 많은 이벤트 또는 원격 분석을 처리하는 이벤트 기반 시스템에 권장됩니다.

다음은 중요 업무용 아키텍처에서 Azure Service Bus 프리미엄 및 Azure Event Hubs에 대한 설계 고려 사항과 권장 사항입니다.

부하 처리

메시징 시스템은 필요한 처리량(예: 초당 MB)을 처리할 수 있어야 합니다. 다음을 살펴보세요.

• 시스템의 NFR(비기능 요구 사항)은 평균 메시지 크기와 각 스탬프가 지원해야 하는 초당 최대 메시지 수를 지정해야 합니다. 이 정보는 스탬프당 필요한 최대 MB/초를 계산하는 데 사용할 수 있습니다.
• 스탬프당 필요한 최대 MB/초를 계산할 때 장애 조치(failover)의 영향을 고려해야 합니다.
• Azure Service Bus의 경우 NFR은 세션 및 중복 제거 메시지와 같은 고급 Service Bus 기능을 지정해야 합니다. 이러한 기능은 Service Bus의 처리량에 영향을 미칩니다.
• 필요한 기능이 있는 Service Bus의 처리량은 테스트를 통해 MU(메시징 단위)당 MB/초로 계산해야 합니다. 이 항목에 대한 자세한 내용은 Service Bus 프리미엄 및 표준 메시징 계층을 참조하세요.
• Azure Event Hubs 처리량은 표준 계층의 경우 TU(처리량 단위)당 MB/초, 프리미엄 계층의 경우 PU(처리 단위)로 테스트를 통해 계산해야 합니다. 이 항목에 대한 자세한 내용은 Event Hubs를 사용하여 스케일링을 참조하세요.
• 위의 계산을 사용하여 메시징 서비스가 스탬프당 필요한 부하와 해당 부하를 충족하는 데 필요한 배율 단위 수를 처리할 수 있는지 확인할 수 있습니다.
• 작업 섹션에서는 자동 스케일링에 대해 설명합니다.

모든 메시지를 처리해야 함

Azure Service Bus 프리미엄 계층은 처리가 보장되어야 하는 가치가 높은 메시지에 권장되는 솔루션입니다. 다음은 Azure Service Bus 프리미엄을 사용할 때 이 요구 사항에 대한 세부 정보입니다.

• 메시지가 브로커에 의해 올바르게 전송되고 수락되도록 하려면 메시지 생산자는 지원되는 Service Bus API 클라이언트 중 하나를 사용해야 합니다. 지원되는 API는 메시지가 큐/토픽에 지속된 경우에만 보내기 작업에서 성공적으로 반환됩니다.

• 버스의 메시지가 처리되도록 하려면 PeekLock 수신 모드를 사용해야 합니다. 이 모드를 사용하면 한 번 이상 처리할 수 있습니다. 다음은 프로세스를 간략하게 설명합니다.

  • 메시지 소비자는 처리할 메시지를 수신합니다.
  • 소비자에게 지정된 기간 동안 메시지에 대한 배타적 잠금이 제공됩니다.
  • 소비자가 메시지를 성공적으로 처리하면 브로커에게 승인을 다시 보내고 메시지는 큐에서 제거됩니다.
  • 할당된 기간 동안 브로커가 승인을 받지 못하거나 처리기가 메시지를 명시적으로 중단하면 배타적 잠금이 해제됩니다. 그런 다음 다른 소비자가 메시지를 처리할 수 있도록 메시지를 사용할 수 있습니다.
  • 메시지가 구성 가능한 횟수만큼 성공적으로 처리되지 않거나 처리기가 메시지를 배달 못 한 편지 큐로 전달하는 경우.
    • 배달 못 한 편지 큐로 전송된 메시지가 처리되도록 하려면 배달 못 한 편지 큐를 모니터링하고 경고를 설정해야 합니다.
    • 시스템에는 운영자가 메시지를 검사, 수정하고 다시 제출할 수 있는 도구가 있어야 합니다.

• 메시지가 여러 번 처리될 수 있으므로 메시지 처리기는 idempotent로 만들어야 합니다.

Idempotent 메시지 처리

RFC 7231에서 HTTP(Hypertext Transfer Protocol)은 “해당 메서드를 사용하는 여러 동일한 요청이 서버에 미치는 의도된 효과가 이러한 단일 요청에 미치는 효과와 동일한 경우 ... 메서드는 idempotent라고 간주합니다.”라고 명시합니다.

메시지 처리를 idempotent로 만드는 일반적인 기술 중 하나는 메시지가 이미 처리된 경우 데이터베이스와 같은 영구 저장소를 확인하는 것입니다. 처리된 경우 논리를 실행하여 다시 처리하지 않습니다.

• 메시지 처리에 데이터베이스 작업, 특히 데이터베이스 생성 식별자가 있는 새 레코드 삽입이 포함되는 상황이 있을 수 있습니다. 해당 식별자를 포함하는 새 메시지를 브로커로 내보낼 수 있습니다. 데이터베이스와 메시지 브로커를 모두 포함하는 분산 트랜잭션이 없으므로 코드를 실행하는 프로세스가 실패하는 경우 여러 가지 복잡한 상황이 발생할 수 있습니다. 다음 예제 상황을 참조하세요.
  • 메시지를 내보내는 코드는 작업 단위 패턴을 사용하여 작업하는 개발자 수인 데이터베이스 트랜잭션이 커밋되기 전에 실행될 수 있습니다. 이러한 메시지는 브로커 호출과 데이터베이스 트랜잭션 커밋 요청 사이에 실패가 발생하면 이스케이프될 수 있습니다. 트랜잭션이 롤백되면 데이터베이스에서 생성된 ID도 실행 취소되어 동시에 실행될 수 있는 다른 코드에서 사용할 수 있습니다. 이로 인해 이스케이프된 메시지의 수신자가 잘못된 데이터베이스 항목을 처리하게 되어 시스템의 전반적인 일관성과 정확성이 저하될 수 있습니다.
  • 개발자가 데이터베이스 트랜잭션이 완료된 후에 메시지를 내보내는 코드를 배치하는 경우 이러한 작업(커밋된 트랜잭션 - 보낸 메시지) 간에 프로세스가 여전히 실패할 수 있습니다. 이 경우 메시지는 다시 처리되지만 이번에는 idempotence 보호 절에서 데이터베이스에 저장된 데이터를 기반으로 메시지가 이미 처리되었음을 확인합니다. 절은 모든 것이 지난 번에 성공적으로 수행되었다고 믿고 코드를 내보내는 메시지를 건너뜁니다. 완료된 프로세스에 대한 알림을 받을 것으로 예상했던 다운스트림 시스템은 아무 것도 수신하지 않습니다. 이 경우 다시 전반적인 불일치 상태가 발생합니다.
• 위의 문제에 대한 해결책은 트랜잭션 아웃박스 패턴을 사용하는 것과 관련이 있습니다. 여기서 보내는 메시지는 비즈니스 데이터와 동일한 트랜잭션 저장소에 별도로 저장됩니다. 초기 메시지가 성공적으로 처리되면 메시지가 메시지 브로커로 전송됩니다.
• 많은 개발자가 이러한 문제 또는 솔루션에 익숙하지 않으므로 이러한 기술이 중요 업무용 시스템에 일관되게 적용되도록 하려면 받은 편지함의 기능과 메시지 브로커와의 상호 작용이 일종의 라이브러리에 래핑되어 있는 것이 좋습니다. 모든 코드 처리와 트랜잭션에서 중요한 메시지를 보내는 것은 메시지 브로커와 직접 상호 작용하는 대신 해당 라이브러리를 사용해야 합니다.
  • .NET에서 이 기능을 구현하는 라이브러리에는 NServiceBus와 MassTransit가 포함됩니다.

고가용성 및 재해 복구

생산자는 메시지를 보내고 소비자는 메시지를 받을 수 있도록 메시지 브로커를 사용할 수 있어야 합니다. 다음은 이 요구 사항에 대한 세부 정보입니다.

• Service Bus에서 가장 높은 가용성을 보장하려면 지원 지역의 가용성 영역을 지원하는 프리미엄 계층을 사용합니다. 가용성 영역을 사용하면 메시지와 메타데이터가 동일한 지역에 있는 세 개의 서로 다른 데이터 센터에 복제됩니다.
• 지원되는 Service Bus 또는 Event Hubs SDK를 사용하여 읽기 또는 쓰기 실패를 자동으로 다시 시도합니다.
• 지역 재해로부터 보호하려면 활성-활성 복제 또는 활성-수동 복제 패턴을 고려합니다.

모니터링

메시징 시스템은 메시지 생산자와 소비자 간 버퍼 역할을 합니다. 아래에 설명된 중요한 인사이트를 제공하는 중요 업무용 시스템에서 모니터링해야 하는 주요 지표 유형이 있습니다.

• 제한 - 제한은 시스템에 요청을 처리하는 데 필요한 리소스가 없음을 나타냅니다. Service Bus와 Event Hubs는 모두 제한된 요청 모니터링을 지원합니다. 이 지표에 대해 경고해야 합니다.
• 큐 깊이 - 증가하는 큐 깊이는 메시지 프로세서가 작동하지 않거나 현재 로드를 처리할 프로세서가 충분하지 않음을 나타낼 수 있습니다. 큐 깊이는 처리기의 자동 스케일링 논리를 알리는 데 사용할 수 있습니다.
  • Service Bus의 경우 큐 깊이가 메시지 수로 노출됩니다.
  • Event Hubs의 경우 소비자는 파티션당 큐 깊이를 계산하고 모니터링 소프트웨어에 메트릭을 푸시해야 합니다. 각 읽기에 대해 소비자는 현재 이벤트의 시퀀스 번호와 마지막으로 큐에 추가된 이벤트의 이벤트 속성을 가져옵니다. 소비자는 오프셋을 계산할 수 있습니다.
• 배달 못 한 편지 큐 - 배달 못 한 편지 큐의 메시지는 처리할 수 없는 메시지를 나타냅니다. 이러한 메시지에는 일반적으로 수동 개입이 필요합니다. 배달 못 한 편지 큐에 경고를 설정해야 합니다.
  • Service Bus에는 배달 못 한 편지 큐와 DeadLetteredMessages 메트릭이 있습니다.
  • Event Hubs의 경우 이 기능은 소비자에 기본 제공되는 사용자 지정 논리여야 합니다.
• CPU/메모리 사용량 - 메시징 시스템에 현재 부하를 처리하기에 충분한 리소스가 있는지 확인하기 위해 CPU와 메모리를 모니터링해야 합니다. Service Bus 프리미엄과 Event Hubs 프리미엄 모두 CPU와 메모리 사용량을 노출합니다.
  • MU(메시징 단위)는 Service Bus에서 네임스페이스의 CPU와 메모리와 같은 리소스를 격리하기 위해 사용됩니다. CPU와 메모리가 임계값 이상으로 상승하면 구성된 MU가 충분하지 않음을 나타낼 수 있는 반면, 다른 임계값 아래로 떨어지면 구성된 MU가 너무 많다는 것을 나타낼 수 있습니다. 이러한 지표는 MU를 자동 스케일링하는 데 사용할 수 있습니다.
  • Event Hubs 프리미엄 계층은 PU(처리 단위)를 사용하여 리소스를 격리하고 표준 계층은 TU(처리량 단위)를 사용합니다. 이러한 계층은 PU 또는 TU를 자동으로 팽창시키는 데 CPU/메모리와의 상호 작용이 필요하지 않습니다.

상태 확인

중요 업무용 애플리케이션의 상태 검사에서 메시징 시스템의 상태를 고려해야 합니다. 다음 사항을 고려합니다.

• 메시징 시스템은 메시지 생산자와 소비자 간 버퍼 역할을 합니다. 생산자가 브로커에 메시지를 성공적으로 보낼 수 있고 소비자가 브로커의 메시지를 성공적으로 처리할 수 있는 경우 스탬프를 정상으로 볼 수 있습니다.
• 상태 검사에서는 메시지를 메시지 시스템으로 보낼 수 있는지 확인해야 합니다.

다음 단계

참조 구현을 배포하여 이 아키텍처에 사용되는 리소스와 해당 구성을 완전히 이해하세요.