Atlas Stream Processing Operations

피어링 및 라우팅 테이블

Atlas Stream Processing 과 자체 관리형 Apache Kafka 클러스터 또는 비공개 API와 같은 비공개 외부 시스템 간의 보안 통신을 보장하려면 VPC 또는 VNet 피어링 연결을 사용하세요. 이러한 연결은 데이터가 공용 인터넷에 노출되지 않도록 보호합니다. 피어링 연결을 설정하는 것 외에도, 트래픽을 Atlas VPC CIDR 차단 으로 전달하도록 애플리케이션의 VPC 에 대한 라우팅 테이블을 명시적으로 구성해야 합니다. 라우팅 테이블을 구성하는 방법에 대해 자세히 학습 외부 제공자 의 VPC 설명서를 참조하세요.

Atlas 프로젝트 간 연결

동일한 조직 내의 서로 다른 Atlas 프로젝트 간에 스트리밍 데이터를 라우팅하기 위해 Atlas Stream Processing 교차 프로젝트 연결을 지원합니다. 교차 프로젝트 연결은 클러스터를 비공개 인터넷에 노출하지 않고 데이터를 전송하므로 VPC 피어링을 수동으로 구성할 필요 없이 개인정보를 보호할 수 있습니다.

비밀번호 없는 AWS 인증

Atlas Stream Processing 다음과 같은 AWS 통합을 지원합니다.

• S3

• Kinesis Data Streams

• Lambda ($externalFunction)

이러한 각 통합은 통합 AWS 액세스와 호환됩니다. 통합 액세스를 구성하면 정적 액세스 ID 또는 Secret 자격 증명 MongoDB 에 저장 필요가 없으며, 이는 모든 AWS 통합에 권장되는 인증 모델입니다.

Kafka OIDC

Atlas Stream Processing JSON Web Token과 함께 OIDC를 사용하여 Apache Kafka 브로커에 대한 인증을 지원합니다. 그러나 이 기능 현재 공용 네트워크를 통해 액세스할 수 있는 ID 제공자만 지원합니다. 이 기능 고객의 VPC 내의 ID 제공자에 대해 지원되지 않습니다.

데드 레터 대기열

처리되지 않은 데이터를 데드 레터 큐 (DLQ)로 라우팅하도록 Atlas Stream Processing 구성할 수 있습니다. 그런 다음 DLQ에서 처리되지 않은 레코드를 확인하여 처리 실패를 해결할 수 있습니다.

DLQ를 검사할 때 다음과 같은 일반적인 처리 오류를 찾으세요.

• 페이로드 구문 분석

  수신 기록 형식이 잘못되어 구문 분석에 실패했습니다. 이는 잘못된 JSON 으로 인해 발생하는 경우가 많습니다.

• 표현식 평가

  처리 파이프라인 의 표현식 제대로 평가되지 않습니다.

  예시

  파이프라인 Kafka 레코드를 삭제 위한 $emit.config.tombstoneWhen 구성 필드 포함되어 있으며, 특정 문서 평가할 필드 누락되었습니다.

• 크기 제한

  발신 기록 대상 싱크의 크기 제한을 초과했습니다(예:AWS Kinesis 의 1 MB ).

• 키 생성

  싱크의 파티션 키 생성하는 동안 프로세서에서 오류가 발생합니다.

• 지연 데이터

  프로세서는 window를 사용하며 구성된 지연 허용 기간이 만료된 후에 지정된 문서 도착합니다.

처리 실패의 원인을 분석 후 업스트림 데이터 소스를 수정하여 데이터가 Atlas Stream Processing 파이프라인 에 들어가기 전에 수정하거나, 파이프라인 수정하여 엣지 케이스를 처리하다 .

DLQ의 레코드를 사용하여 Atlas Stream Processing 구성을 가이드 한 후 해당 레코드에 대한 다음 수정 옵션을 고려하세요.

• 폐기

  시간에 매우 민감한 시스템에서 데이터가 매우 늦은 경우와 같이 기록 매우 잘못되었거나 관련이 없는 경우 컬렉션 에서 삭제 .

• 수동 수정

  사소한 JSON 오류가 있거나 미션 크리티컬한 기록 의 경우 필드를 수동으로 조정하여 대상 싱크에 직접 삽입합니다.

• 자동 재처리:

  복구 가능한 관련 데이터가 많은 경우, DLQ에서 읽고 정리된 데이터를 대상 싱크로 라우팅하기 전에 알려진 장애 조건에 대해 변환을 적용하는 세컨더리 스크립트 또는 추가 스트림 프로세서를 만듭니다.

페일오버 구성 원칙

다음 원칙은 Atlas Stream Processing 워크로드를 보호하기 위한 강력한 페일오버 구성을 정의합니다.

• 여러 리전에 Atlas 클러스터를 배포하세요.

  리전 페일오버 이벤트 에서 스트림 프로세서가 계속 작동하려면 스트림 프로세서가 연결되는 모든 Atlas cluster 멀티 리전 클러스터 여야 합니다. 이 원칙은 프라이머리 리전 다운될 때 소스 또는 싱크 연결이 활성 상태로 유지되도록 합니다.

• 각 리전 에 대한 Atlas Stream Processing 작업 공간을 만듭니다.

  멀티 리전 클러스터를 배포한 후 각 리전 에 대한 작업 공간을 만듭니다. 이 원칙은 스트림 프로세서와 지원하는 Atlas 데이터베이스 간의 연결 지연 시간 최소화합니다.

• 백업 연결로 연결 레지스트리를 채웁니다.

  각 리전의 작업 공간에서 각 소스 및 싱크에 대한 연결을 구성합니다.기본 연결뿐만 아니라 VPC 및 비공개 엔드포인트 연결에 대해서도 연결을 구성해야 합니다.

• 연결별 재해 복구 구성

  스트림 프로세서에 대한 서비스 연속성을 보장하려면 스트림 프로세서가 의존하는 모든 외부 제공자도 페일오버 활성화해야 합니다. 각 외부 제공자 소스 또는 싱크가 설명서에 따라 올바르게 구성되어 있는지 확인합니다.

  예시

  스트림 프로세서가 Kafka 클러스터 소스 또는 싱크로 사용하는 경우, 소비자 오프셋 보존을 위해 클러스터 구성하여 Atlas Stream Processing 소비자 그룹 오프셋에서 처리 재개할 수 활성화 .

• 일상적인 드라이 런을 수행합니다.

  주기적으로 페일오버 드라이런을 수행하여 페일오버 구성을 확인합니다. 이러한 드라이런은 구성이 네트워크에 연결되고 체크포인트를 올바르게 로드하는지 확인하고, 필요할 때 더 쉽게 수행할 수 있도록 페일오버 워크플로를 교육하는 데 제공 . 페일오버 오버 드라이런의 주기를 정기적으로 설정하고 페일오버 구성을 변경할 때마다 드라 실행 수행하는 것이 좋습니다.

스트림 프로세서 페일오버 설정

권장사항 적용되었는지 확인한후 스트림 프로세서를 생성하고 페일오버 구성을 확인합니다.

Atlas Stream Processing 다음 구성의 프로세서에 대해서만 자동 리전 페일오버 지원합니다.

• Atlas 소스 및 싱크

• Atlas 소스 및 Apache Kafka 싱크

자동 페일오버 에 대한 자세한 내용은 페일오버 프로세서를 참조하세요.

그러나 소스 및 싱크 연결의 모든 조합에 대해 수동 페일오버 지원하는 Atlas Stream Processing 아키텍처를 구성할 수 있습니다.

강제 페일오버 시작

작업 공간 또는 스트림 프로세서 수준에서 강제 페일오버 시작할 수 있습니다.

스트림 처리 공간 페일오버 시작하려면 트리거 스트림 처리 작업 공간 페일오버에설명된 절차를 따르세요.

개별 스트림 프로세서 페일오버 시작하려면 1개 스트림 프로세서에 대한 페일오버 시작에 설명된 절차를 따르세요.

페일오버 이벤트에 응답

리전별 서비스 중단 이벤트 발생한 경우:

페일오버 동작

리전 페일오버 또는 수동 페일 페일오버 위해 시스템을 구성할 때는 다음 사항을 고려하세요.

• 리전 페일오버 발생하면 Atlas Stream Processing 페일오버 리전 의 비활성 페일오버 프로세서를 활성 프로세서로 승격합니다. 이러한 프로세서는 사용 가능한 마지막 체크포인트 부터 스트림 처리 재개합니다.

• Atlas Stream Processing 체크포인트는 10분 이상 경과되지 않도록 보장됩니다. 그러나 페일오버 프로세서는 시작 시 마지막 체크포인트 이후 프라이머리 프로세서가 처리한 모든 데이터를 다시 처리합니다. 페일오버는 최소 한 번 처리 시맨틱을 보장 .

• 리전 페일오버 이벤트 중에 페일오버 프로세서가 시작에 실패하더라도 여전히 액티브 프로세서의 역할 맡습니다. 그런 다음 기본 원인을 해결하고 페일오버 리전 에서 정상적으로 프로세서를 다시 시작할 수 있습니다.