Atlas Stream Processing 계층 선택 가이드

병렬 처리를 지원하는 단계

다음 단계에서는 parallelism 값을 허용합니다. 각각 기본값은 1입니다.

누적 병렬 처리

각 스트림 프로세서에는 해당 계층 에 따라 결정되는 최대 누적 병렬 처리 수 값이 있습니다. 스트림 프로세서의 누적 병렬 처리 수는 다음과 같이 계산됩니다.

parallelism total - parallelized stages

여기서 parallelism total 은(는) $source, $lookup, $merge, $emit 및 $externalFunction 단계에서 1 보다 큰 모든 parallelism 값의 합계이며, parallelized stages 는 parallelism 값이 1보다 큰 이러한 단계의 수입니다.

예시 를 들어 $source 단계에서 parallelism 값을 4로 설정하고, $lookup 단계에서 parallelism 값을 설정하지 않으며(따라서 기본값은 1), $merge 단계는 parallelism 값이 2인 경우 두 개의 parallelized stages이(가) 있고 스트림 프로세서의 누적 병렬 처리 수는 (4 + 2) - 2(으)로 계산됩니다.

스트림 프로세서가 해당 계층 의 최대 누적 병렬 처리 수를 초과하는 경우 Atlas Stream Processing 오류가 발생하고 의도한 병렬 처리 수준에 필요한 최소 프로세서 계층 알려줍니다. 오류를 해결하려면 프로세서를 더 높은 계층 으로 확장하다 하거나 단계의 병렬 처리 값을 줄여야 합니다. 자세한 학습은 Stream Processing을 참조하세요.

Kafka 소스 파티션

Apache Kafka 에서 읽는 프로세서도 해당 계층 의 소스 파티션 제한에 의해 제한됩니다. SP2 계층 프로세서를 32 소스 파티션으로 제한하고 SP5 계층 프로세서를 64로 제한합니다. SP10 계층 이상에는 파티션 제한이 없습니다.

해당 계층 의 파티션 제한을 초과하는 프로세서에는 장애가 발생하며, 추가 파티션을 지원 하도록 해당 프로세서를 확장하다 해야 합니다. 프로세서가 실행되는 동안 주제 파티션이 발생할 수 있으므로 예상하는 파티션 증가에 대한 헤드룸이 있는 계층 선택하세요. Kafka 소스 동작에 대해 자세히 학습 제한 사항을 참조하세요.

구성된 병렬 처리 모니터링

구성한 병렬 처리와 프로세서 계층 에서 사용할 수 있는 병렬 처리를 비교하려면 프로세서 통계가 반환하는 stats.addedParallelism 필드 사용합니다. Atlas Stream Processing 하나 이상의 단계에서 parallelism 값을 1보다 크게 설정한 경우에만 이 필드 반환합니다.

초기화 급증

스트림 프로세서는 일반 작업보다 초기 실행 중에 더 많은 리소스가 필요할 수 있습니다. 예시 를 들어, 대규모 Atlas 컬렉션 에 대해 initialSync를 수행하는 프로세서는 동기화 기간 동안 많은 I/O 및 계산을 지원 해야 합니다.

이러한 증가된 수요를 흡수하려면 일시적으로 상위 계층 선택하고 동기화가 완료되고 프로세서가 새로운 변경 스트림 이벤트만 사용하도록 전환되면 프로세서를 축소 확장하다 .

파이프라인 로직

집계 파이프라인 로직은 CPU 및 RAM 소비의 프라이머리 드라이버 입니다.

• Windows: 오래 지속되는 창은 이동 중에 보관하기 위해 더 많은 RAM 사용합니다.

  문서입니다.

• 사용자 지정 로직: Javascript $function 단계 또는 복잡한 그룹화

  로직은 각 메시지의 계산 요구 사항을 증가시킵니다.

• 복합 복잡성: 상태 저장 또는 계산적으로 복잡한 추가 단계

  리소스 수요에 더 많은 잠재적 변동이 발생합니다. 잉여 용량 유지하면 사용량이 급증하는 동안에도 일관적인 처리량 보장됩니다.

인프라

각 네트워크 또는 저장 문의 점 스트림 프로세서의 오버헤드 증가시킵니다.

• 소스 또는 싱크 밀도: 병렬화된 읽기 또는 쓰기

  소스 또는 싱크(예: Apache Kafka 주제)는 I/O 요구 사항을 증가시킵니다.

• 데이터 강화: $lookup 및 $https 단계, 및 작업

  스트림 의 데이터를 보강하기 위해 Atlas 컬렉션을 사용하려면 네트워크 대역폭과 연결 풀링 필요합니다.

• 조정: 많은 소스를 조정하는 복잡한 배포에서

  스트림 프로세서는 이러한 각 노드 간에 데이터 흐름을 라우팅하는 허브 제공 을 할 수 있습니다. 이러한 프로세서는 SP30 및 SP50 계층의 더 높은 처리량 의 이점을 누릴 수 있습니다.

반대로 처리량이 많은 Stream Processing 워크로드는 연결된 리소스에 대한 수요를 증가시킬 수 있습니다.

• Atlas 에 미치는 영향: 스트림 의 대용량 병렬 I/O

  프로세서는 소스 또는 싱크 Atlas 클러스터의 읽기 또는 쓰기 (write) 용량 초과할 수 있습니다. 이는 프로세서의 지연 시간 증가시킬 뿐만 아니라 해당 클러스터에 의존하는 다른 워크로드에 병목 현상을 일으킬 수 있습니다.

  시스템 전체의 성능을 보장하려면 상호 작용 하는 프로세서에 비례하여 Atlas cluster를 확장하다 .

성능 및 지연 시간

처리 로직이 최소화된 경우에도 성능 목표를 달성하려면 더 높은 계층의 프로세서가 필요할 수 있습니다.

• 높은 처리량: 상위 계층 프로세서가 스트림을 더 잘 지원

  빠른 속도로 이벤트를 생성합니다.

• 짧은 지연 시간 SLA: 상위 계층 프로세서가 제공하는 높은 병렬 처리는 속도가 중요할 때 이벤트가 대기열에 누적되지 않도록 하는 데 도움이 됩니다. 특히 SP50 프로세서는 SP30 프로세서보다 4배 더 많은 스레드를 제공합니다.

• 데이터 인리치먼트 및 캐싱: $cachedLookup 을(를) 사용하여 인리치먼트하는 경우

  정적 또는 느리게 변화하는 참조 데이터가 많은 스트림은 캐싱에 필요한 RAM 제공하기 위해 상위 계층 프로세서를 선호합니다.

• 복합 싱크: 특정 싱크는 더 비쌉니다.

  변환, 트랜잭션 및 파일 관리 오버헤드. 이러한 싱크와 상호 작용 프로세서의 경우 계층이 높을수록 일관적인 성능과 지연 시간 보장하는 데 도움이 됩니다.