Atlas Stream Processing 아키텍처

계층

스트림 프로세서를 정의하면 이를 정의하는 스트림 처리 작업 공간에서만 사용할 수 있게 됩니다. 각 스트림 프로세서는 계층 에 따라 할당된 리소스에서 실행됩니다. Atlas Stream Processing 스트림 프로세서가 실행 동안에만 사용자에게 요금을 청구합니다.

계층 크기를 선언하지 않고 스트림 처리 프로세서를 시작하면 스트림 처리 작업 공간의 계층이 실행됩니다. 스트림 처리 작업 공간의 최대 계층까지 포함하여 모든 계층의 스트림 프로세서를 시작할 수 있습니다.

연결 레지스트리

연결 레지스트리는 하나 이상의 연결을 저장합니다. 각 연결은 스트림 프로세서가 외부 서비스와 상호 작용할 수 있도록 하는 네트워킹 및 보안 세부 정보의 조합에 이름을 할당합니다. 연결은 다음과 같은 동작을 나타냅니다.

• 지정된 스트림 처리 작업 공간의 연결 레지스트리에 정의된 연결만 해당 스트림 처리 적옵 공간에서 호스팅되는 스트림 프로세서에 서비스를 제공할 수 있습니다.

• 각 연결은 임의의 수의 스트림 프로세서를 제공할 수 있습니다.

• 단일 연결만 지정된 스트림 프로세서의 소스 역할을 할 수 있습니다.

• 단일 연결만 지정된 스트림 프로세서의 싱크 역할을 할 수 있습니다.

• 연결은 원래 소스또는 싱크로 정의되지 않습니다. 지정된 연결은 스트림 프로세서가 해당 연결을 호출하는 방식에 따라 두 가지 기능을 모두 수행할 수 있습니다.

Atlas Stream Processing 멀티 테넌트 인프라에서 VM 수준으로 격리 전용 고객 컨테이너 에서 각 스트림 프로세서를 실행합니다. MongoDB 보안 및 컴플라이언스에 대한 자세한 내용은 MongoDB 보안 센터참조하세요.

Kafka 소스 및 소비자 그룹 오프셋

Atlas Stream Processing 체크포인트 커밋한 후 Kafka 의 소비자 그룹 오프셋을 비동기적으로 업데이트합니다. When you use Apache Kafka 를 $source로 사용하는 경우 소비자 그룹은 각 파티션에 대해 Kafka 클러스터에서 이러한 체크포인트를 커밋된 오프셋으로 추적합니다.

이러한 업데이트는 주기적으로 비동기적으로 발생하기 때문에 소비자 그룹의 커밋된 오프셋은 가장 최근의 체크포인트 보다 일시적으로 지연될 수 있습니다. 이로 인해 kafka-consumer-group CLI 도구와 같이 Kafka 에서 커밋된 오프셋을 읽는 도구의 모니터링 및 지연 지표 단기적으로 지연될 수 있습니다. 이러한 도구는 스트림 프로세서의 실제 내부 위치 '배후'에 있는 소비자 그룹 보여줄 수 있습니다.

내부 체크포인트와 커밋된 Kafka 오프셋 간의 지연 정도는 고정되어 있지 않으며 워크로드 및 구성에 따라 달라질 수 있습니다. 일반적인 워크로드에서는 몇 초 정도 소요되지만 엄격한 상한은 없습니다.

페일오버 고려 사항

작업 영역을 처음 만들 때 스트림 처리 작업 영역에 대한 페일오버 리전을 만들거나 페일오버 리전을 사용하도록 기존 스트림 처리 작업 영역을 수정할 수 있습니다.

개별 프로세서, 지정된 작업 공간 내의 모든 프로세서 또는 지정된 리전 에 페일오버 가 구성된 모든 프로세서에 대해 페일오버 트리거하다 할 수 있습니다.

페일오버 프로세서는 최소 한 번 처리 시맨틱을 보장합니다.

페일오버 프로세서의 요구 사항 및 제한 사항에 대해 자세히 학습 보려면 제한 사항을 참조하세요.

페일오버 프로세서 가격에 대한 학습 은 청구 문서를 참조하세요.

오류 분류

Atlas Stream Processing 오류를 두 가지 주요 카테고리로 분류합니다.

사용자 오류

사용자 구성, 데이터 문제 또는 Atlas Stream Processing의 제어를 벗어난 외부 서비스 문제로 인해 발생한 오류입니다. 예는 다음과 같습니다.

• 잘못된 연결 자격 증명

• 외부 서비스에 대한 네트워크 연결 문제

• 처리할 수 없는 잘못된 형식의 데이터

• 외부 리소스에 액세스할 수 있는 권한 문제

내부 오류

Atlas Stream Processing 시스템 자체 내에서 발생하는 오류로, 일반적으로 일시적인 인프라 문제나 서비스 중단으로 인해 발생합니다. 이는 Atlas Stream Processing 서비스에서 해결해야 할 책임으로 간주됩니다.

재시도 동작

재시도 동작은 오류 분류에 따라 달라집니다.

사용자 오류 재시도 정책

• Atlas Stream Processing 5분 동안 제한된 횟수만큼 스트림 프로세서를 다시 시작하려고 시도합니다.

• 이 기간 내에 모든 재시도 시도가 실패하면 스트림 프로세서가 FAILED 상태 로 전환됩니다.

• 일부 사용자 오류는 재시도할 수 없는 오류로 분류되어 즉시 프로세서 장애를 유발합니다. 예는 다음과 같습니다.

  • StreamProcessorWorkerOutOfMemory (418): 파이프라인이 계층 메모리 제한을 초과합니다.

  • StreamProcessorInvalidOptions (420): 잘못된 파이프라인 구문 또는 구성입니다.

• start() 메서드를 호출하여 실패한 스트림 프로세서를 수동으로 다시 시작할 수 있습니다.

내부 오류 재시도 정책

• Atlas Stream Processing 시간 제한 없이 내부 오류를 지속적으로 재시도합니다.

• 내부 오류가 Atlas Stream Processing 엔지니어링 팀 에 경고를 트리거하다 .

• 시스템은 내부 문제가 해결된 후 자동 재시도 메커니즘을 사용하여 프로세서를 복구합니다.

• 스트림 프로세서 재시작 시 마지막 체크포인트 부터 자동으로 재개

복구 프로세스

스트림 프로세서에 오류가 발생하여 다시 시작해야 하는 경우 복구 프로세스 다음 단계를 따릅니다.

이 복구 프로세스 사용하면 일시적인 오류로 인해 데이터가 손실되거나 대부분의 경우 수동 개입이 필요하지 않습니다.

이벤트 시간

이벤트 시간은 소스 스트림 이 문서 생성하거나 메시징 시스템(예: Apache Kafka)가 문서 수신합니다. 이는 문서 의 타임스탬프로 확인됩니다.

네트워크 지연 시간, 업스트림 처리 및 기타 요인으로 인해 특정 문서 의 이러한 시간 사이에 불일치가 발생할 수 있을 뿐만 아니라 문서가 이벤트 시간 순서와 다르게 스트림 프로세서에 도착할 수도 있습니다. 두 경우 모두 Windows에서 캡처하려는 문서를 놓칠 수 있습니다. Atlas Stream Processing 이러한 문서가 지연 도착하는 것으로 간주하여 구성한 경우 데드 레터 대기열 로 전송합니다.

이벤트 시간 은 텀블링 Windows 및 홉핑 Windows에서 지원되는 boundary 필드에 대해 구성 가능한 옵션입니다.

처리 시간

처리 시간은 스트림 프로세서가 문서를 소비하는 시간입니다. 이는 스트림 프로세서를 호스팅하는 시스템의 시계에 의해 확인됩니다.

처리 시간 은 텀블링 Windows 및 호핑 Windows에서 지원되는 boundary 필드에 대해 구성 가능한 옵션입니다. 이를 통해 서버 의 벽시계 시간을 기준으로 데이터를 축적하는 일종의 창 가진 파이프라인 만들 수 있습니다. 이벤트 시간 Windows 와 달리 처리 시간 Windows 서버 스트림 프로세서에 도달할 때 벽시계 시간을 기준으로 각 이벤트 타임스탬프를 할당합니다.

문서 타임스탬프와 창 경계 타임스탬프는 UTC를 기준으로 합니다. 창 구성할 때는 idleTimeout 또는 허용된 지연 시간 옵션을 지정할 수 processingTime 없습니다.