아키텍처 기본 사항
Atlas Stream Processing 의 핵심 추상화는 스트림 프로세서입니다. 스트림 프로세서는 지정된 소스의 스트리밍 데이터에서 지속적으로 작동하고 출력을 싱크에 쓰는 MongoDB 집계 파이프라인 입니다. 자세한학습 은 스트림 프로세서의 구조를 참조하세요.
스트림 처리는 스트림 처리 인스턴스에서 발생합니다. 각 스트림 처리 인스턴스는 다음을 연결하는 Atlas 네임스페이스입니다.
스트림 프로세서를 실행하는 데 필요한 RAM과 CPU를 제공하는 하나 이상의 작업자입니다.
클라우드 공급자 및 클라우드 리전.
스트리밍 데이터의 사용 가능한 소스 및 싱크 목록을 저장하는 연결 레지스트리입니다.
사용자 권한 부여를 정의하는 보안 컨텍스트.
Atlas Stream Processing 인스턴스 자체에 대한 연결 string 입니다.
노동자
스트림 프로세서를 정의하면 해당 스트림 프로세서를 정의한 스트림 처리 인스턴스에서만 사용할 수 있게 됩니다. 각 작업자는 실행 중인 스트림 프로세서를 최대 4개까지 호스팅할 수 있으며, 필요에 따라 작업자를 프로비저닝하여 스트림 프로세서를 시작할 때 Atlas Stream Processing 인스턴스가 자동으로 확장됩니다. 작업자의 모든 스트림 프로세서를 중지하여 작업자의 프로비저닝을 해제할 수 있습니다. Atlas Stream Processing은 항상 새 작업자를 프로비저닝하는 것보다 기존 작업자에 스트림 프로세서를 할당하는 것을 선호합니다.
예시
이름이 proc01 ~ proc08 인 8개의 스트림 프로세서를 실행하는 Atlas Stream Processing 인스턴스가 있습니다. proc01 ~ proc04 는 한 작업자에서 실행되고 proc05 ~ proc08 는 두 번째 작업자에서 실행됩니다. proc09 이라는 새 스트림 프로세서를 시작합니다. Atlas Stream Processing은 proc09 을(를) 호스팅할 세 번째 작업자를 프로비저닝합니다.
나중에 첫 번째 작업자에서 proc03을 중지합니다. proc09를 중지하고 다시 시작하면 Atlas Stream Processing은 proc09를 첫 번째 작업자에 재할당하고 세 번째 작업자의 프로비저닝을 해제합니다.
proc09를 중지하고 다시 시작하기 전에 proc10이라는 새로운 스트림 프로세서를 시작하면 Atlas Stream Processing은 proc10을 이전에 proc03에 할당된 슬롯의 첫 번째 작업자에게 할당합니다
확장 시 Atlas Stream Processing은 현재 실행 중인 스트림 프로세서의 수만 고려하며 실행 중이 아닌 정의된 스트림 프로세서는 계산하지 않습니다. 스트림 처리 인스턴스의 계층은 작업자의 RAM 및 CPU 할당을 결정합니다.
연결 레지스트리
연결 레지스트리는 하나 이상의 연결을 저장합니다. 각 연결은 스트림 프로세서가 외부 서비스와 상호 작용할 수 있도록 하는 네트워킹 및 보안 세부 정보의 조합에 이름을 할당합니다. 연결은 다음과 같은 동작을 나타냅니다.
지정된 스트림 처리 인스턴스의 연결 레지스트리에 정의된 연결만 해당 스트림 처리 인스턴스에서 호스팅되는 스트림 프로세서에 서비스를 제공할 수 있습니다.
각 연결은 임의의 수의 스트림 프로세서를 제공할 수 있습니다.
단일 연결만 지정된 스트림 프로세서의 소스 역할을 할 수 있습니다.
단일 연결만 지정된 스트림 프로세서의 싱크 역할을 할 수 있습니다.
연결은 원래 소스또는 싱크로 정의되지 않습니다. 지정된 연결은 스트림 프로세서가 해당 연결을 호출하는 방식에 따라 두 가지 기능을 모두 수행할 수 있습니다.
Atlas Stream Processing 은 멀티 테넌트 인프라의 전용 고객 컨테이너에서 Atlas Stream Processing 작업자를 실행합니다. MongoDB 보안 및 컴플라이언스에 대한 자세한 내용은 MongoDB 보안 센터를 참조하세요.
체크포인트
Atlas Stream Processing 체크포인트를 사용하여 스트림 프로세서의 상태 캡처합니다. 각 체크포인트 에는 고유한 ID 가 있으며 스트림 프로세서 로직의 흐름에 따라 달라집니다. 스트림 프로세서의 모든 연산자가 자신의 상태 체크포인트 에 추가한 후 Atlas Stream Processing 체크포인트 커밋하여 두 가지 유형의 레코드를 생성합니다.
체크포인트 ID 와 체크포인트 ID가 속한 스트림 프로세서의 유효성을 검사하는 단일 커밋 기록
Atlas Stream Processing이 체크포인트를 커밋하는 순간 관련 스트림 프로세서의 각 상태 저장 작업의 상태를 설명하는 레코드 집합입니다.
중단 후 스트림 프로세서를 다시 시작하면 Atlas Stream Processing은 마지막으로 커미트된 체크포인트를 쿼리하고 명시된 상태부터 작업을 재개합니다.
데드 레터 대기열
Atlas Stream Processing은 Atlas 데이터베이스 컬렉션을 데드 레터 큐(DLQ)로 지원합니다. Atlas Stream Processing이 데이터 스트림에서 문서를 처리할 수 없을 때, 문서의 내용을 처리 실패 세부 정보와 함께 DLQ에 기록합니다. 스트림 프로세서 정의에서 컬렉션을 DLQ로 설정할 수 있습니다.
자세한 내용 은 스트림 프로세서 생성을 참조하세요.
Atlas Stream 처리 타이밍
스트리밍 데이터 처리에서는 문서가 두 가지 타이밍 시스템의 영향을 받습니다.
이벤트 시간
처리 시간
Atlas Stream Processing 스트림 프로세서가 이러한 타이밍 시스템과 상호 작용 방식을 제어하기 위해 다양한 매개변수를 제공합니다.
이벤트 시간
이벤트 시간은 소스 스트림 문서 생성하거나 메시징 시스템(예: Apache Kafka) 문서 수신하는 시간입니다. 이는 문서 의 타임스탬프로 확인됩니다.
네트워크 지연 시간, 업스트림 처리 및 기타 요인으로 인해 특정 문서 의 이러한 시간 사이에 불일치가 발생할 수 있을 뿐만 아니라 문서가 이벤트 시간 순서와 다르게 스트림 프로세서에 도착할 수도 있습니다. 두 경우 모두 Windows에서 캡처하려는 문서를 놓칠 수 있습니다. Atlas Stream Processing 이러한 문서가 지연 도착하는 것으로 간주하여 구성한 경우 데드 레터 대기열로 전송합니다.
이벤트 시간은 텀블링 Windows 및 홉핑 Windows 에서 지원되는 boundary 필드 에 대해 구성 가능한 옵션입니다.
처리 시간
처리 시간은 스트림 프로세서가 문서를 소비하는 시간입니다. 이는 스트림 프로세서를 호스팅하는 시스템의 시계에 의해 확인됩니다.
처리 시간은 텀블링 Windows 및 호핑 Windows 에서 지원되는 필드 에 대해 구성 가능한 boundary 옵션입니다. 이를 통해 서버 의 벽시계 시간을 기준으로 데이터를 축적하는 일종의 창 가진 파이프라인 만들 수 있습니다.이벤트 시간 창과 달리 처리 시간 창은 서버 가 스트림 프로세서에 도달할 때 벽시계 시간을 기준으로 각 이벤트 타임스탬프를 할당합니다.
문서 타임스탬프와 창 경계 타임스탬프는 UTC 기준입니다. 창 구성할 때는 idleTimeout 또는 허용된 지연 시간 옵션을 지정할 수 processingTime 없습니다.
예시
5분 이벤트 시간 창으로 파이프라인을 생성합니다. 09:33의 소스 Kafka 클러스터에 이벤트가 추가됩니다. Kafka 클러스터의 일부 지연으로 인해 09:37의 스트림 프로세서에 도착합니다.
파이프라인에 5분 이벤트 시간 창이 있는 경우 이 이벤트는 09:30-09:35 창에 할당됩니다. 파이프라인에 5분 처리 시간 창이 있는 경우 이벤트는 대신 09:35-09:40 창에 할당됩니다.
워터마크
워터마크는 처리 시간 을 대체하며 프로세서가 이전에 소비한 문서보다 이벤트 시간이 더 늦은 문서를 소비하는 경우에만 업데이트됩니다. 모든 스트림 프로세서는 Atlas Stream Processing 에서 워터마크를 적용 .
예시
5분 Windows 로 스트림 프로세서를 구성합니다. 프로세서를 12:00에서 시작하여 처음 두 Windows 의 지속 시간이 12:00-12:05 및 12:05-12:10이 되도록 합니다. 다음 표는 워터마크 유무에 관계없이 다양한 지연이 있는 경우 어떤 Windows 가 어떤 이벤트를 캡처하는지 보여줍니다.
이벤트 시간 | 처리 시간 | 창 시간(워터마크 없음) | 창 시간(워터마크) |
|---|---|---|---|
12:00 | 12:00 | 12:00-12:05 | 12:00-12:05 |
12:01 | 12:03 | 12:00-12:05 | 12:00-12:05 |
12:02 | 12:05 | 12:05-12:10 | 12:00-12:05 |
12:01 | 12:06 | 12:05-12:10 | 12:00-12:05 |
12:06 | 12:07 | 12:05-12:10 | 12:05-12:10 |
워터마크가 없으면 스트림 처리 인스턴스 의 시스템 시계에 따라 12:00-12:05 창 12:05 에 닫히고 12:05-12:10 창 즉시 열립니다. 따라서 소스는 12:00-12:05 간격 동안 문서 4개를 생성했지만 관련 창 문서 2개만 캡처합니다.
워터마크를 사용하면 12:00-12:05 창 해당 점 까지 수집하는 문서 중 가장 최근 이벤트 시간(따라서 워터마크 값)이 12:03이기 때문에 12:05 에 닫히지 않습니다. 12:00-12:05 창 스트림 프로세서가 이벤트 시간이 12:05 인 문서 수집하고 워터마크를 해당 시간으로 진행한 다음 12:05-12:10 창 열 때 시스템 시계의 12:07 때까지 닫히지 않습니다. 각 창 해당 문서를 모두 캡처합니다.
Apache Kafka 에서 읽을 때 Atlas 모든 파티션이 워터마크를 통과할 때까지 기다립니다. 파티션이 유휴 상태이고 워터마크보다 늦은 타임스탬프로 이벤트를 생성하지 못하면 창 닫히거나 결과가 출력되지 않습니다. 이 문제를 주소 하려면 를 설정하다 partitionIdleTimeout 유휴 파티션이 워터마크의 진행을 중단하지 않도록 합니다. 자세한 학습 은 $source 단계(스트림 처리)를 참조하세요.
허용된 지연 시간
이벤트 시간과 처리 시간의 차이가 충분히 차이가 나면 워터마크가 예상 창을 닫을 만큼 진행된 후에 문서가 스트림 프로세서에 도착할 수 있습니다. 이를 완화하기 위해 Atlas Stream Processing은 워터마크를 기준으로 창 닫기를 설정된 간격만큼 지연시키는 설정인 허용 지연 시간을 지원합니다.
워터마크는 스트림 프로세서의 속성이지만, Allowed Lateness(허용 유휴 시간)은 창의 속성이며 창이 닫힐 때만 영향을 줍니다. 스트림 프로세서의 워터마크가 새 창이 열리도록 트리거하는 지점까지 적용되는 경우, Allowed Lateness(허용 유휴 시간)은 이를 막지 않고 이전 창을 열린 상태로 유지합니다.
예시
5분 텀블링 Windows 를 사용하여 스트림 프로세서를 구성합니다. 프로세서를 12:00에서 시작하여 처음 두 Windows 의 지속 시간이 12:00-12:05 및 12:05-12:10이 되도록 합니다. 허용 지연 시간을 2 분으로 설정했습니다.
아래 표는 스트림 프로세서가 설명된 문서를 수집하는 순서를 반영합니다.
이벤트 시간 | 워터마크 | 허용된 지연 시간 | 창 시간 |
|---|---|---|---|
12:00 | 12:00 | 11:58 | 12:00-12:05 |
12:02 | 12:03 | 12:01 | 12:00-12:05 |
12:01 | 12:04 | 12:02 | 12:00-12:05 |
12:05 | 12:05 | 12:03 | 12:00-12:15, 12:05-12:10 |
12:04 | 12:06 | 12:04 | 12:00-12:05, 12:05-12:10 |
12:07 | 12:07 | 12:05 | 12:05-12:10 |
워터마크가 12:05로 이동하면 12:05-12:10 창이 열립니다. 하지만 허용된 지연 간격은 2분이므로 12:00-12:05 창 내에서는 사실상 12:03에 불과합니다. 따라서 열린 상태로 유지됩니다. 워터마크가 12:07로 진행되어야만 조정된 시간이 12:05에 도달합니다. 이 시점에서 12:00-12:05 창이 닫힙니다.
유휴 시간 초과
기본적으로 창 동작을 처리 시간에서 분리하면 대부분의 경우 스트림 처리의 정확성이 향상됩니다. 그러나 스트리밍 데이터 소스는 유휴 기간이 길어질 수 있습니다. 이 시나리오에서 창은 워터마크가 진행되어 닫힐 때까지 기다리는 동안 유휴 기간 이전의 이벤트를 캡처하고 처리된 결과를 반환하지 못할 수 있습니다.
Atlas Stream Processing 사용하면 처리 시간을 사용하여 이러한 시나리오를 완화하기 위해 창에 대한 유휴 시간 제한을 구성할 수 있습니다. 유휴 시간 제한은 처리 시간이 열린 창 간격의 끝을 지나고 스트림 프로세서의 소스가 유휴 상태일 때 시작되는 간격입니다. 소스가 유휴 시간 제한과 동일한 간격 동안 유휴 상태로 유지되면 문서 수집과 관계없이 창 닫히고 워터마크가 진행됩니다.
예시
3분 간격과 1분 유휴 시간 초과로 텀블링 창을 구성합니다. 다음 표는 창 간격 도중과 창 간격 이후의 유휴 시간 초과의 효과를 보여줍니다.
처리 시간 | 이벤트 시간 또는 상태 | 워터마크 | 창 시간 |
|---|---|---|---|
12:00 | 12:00 | 12:00 | 12:00-12:03 |
12:01 | 소스 유휴 상태 | 12:00 | 12:00-12:03 |
12:02 | 소스 유휴 상태 | 12:00 | 12:00-12:03 |
12:03 | 소스 유휴 상태 | 12:00 | 12:00-12:03 |
12:04 | 12:02 | 12:02 | 12:00-12:03 |
12:05 | 12:05 | 12:05 | 12:03-12:06 |
12:06 | 소스 유휴 상태 | 12:05 | 12:03-12:06 |
12:07 | 소스 유휴 상태 | 12:00 | 12:06-12:09 |
12:08 | 소스 유휴 상태 | 12:00 | 12:06-12:09 |
12:09 | 12:09 | 12:09 | 12:09-12:12 |
12:00-12:03 간격 동안 소스는 3분 동안 유휴 상태에 있지만 스트림 프로세서는 창의 간격 끝까지 처리 시간이 지나지 않았기 때문에 창을 닫지 않으며, 창의 간격이 끝난 후 소스가 유휴 상태를 유지하지 않습니다. 워터마크가 12:05로 진행되면 창이 정상적으로 닫히고 12:03-12:06 창이 열립니다.
소스가 12:06 에 유휴 상태가 되면 12:07 까지 유휴 상태로 유지되어 유휴 시간 제한이 트리거되고 워터마크가 12:06 로 진행됩니다.