데이터 스트림 운영 및 모니터링

GoldenGate측 모니터링

• 데이터 스트림 리소스가 있고 배포 서비스에서 사용할 수 있는지 확인합니다.

• 전송된 레코드 및 바이트, 작업 수, DDL 수, 테이블 작업 및 UI 또는 서비스 측정항목에 의해 노출되는 네트워크 통계를 모니터합니다.

• 인증, 추적 조회, 포지션 조회, 스키마 생성, 크기 자르기 및 WebSocket 연결 해제 오류에 대한 분배 서비스 로그를 검토하십시오.

• 소스 추출 및 추적 생성을 독립적으로 모니터링합니다. 정상 WebSocket는 추적에 도달하지 않는 데이터를 전달할 수 없습니다.

소비자 측정항목

척도	중요한 이유
접속 상태 및 재접속 수	네트워크, 인증, 프록시 및 서비스 불안정을 감지합니다.
마지막 수신 및 마지막 커밋 pos	데이터 도착을 지속성 있는 처리에서 분리합니다. 위치가 민감한 것으로 간주되는 경우 해시 또는 보호된 값을 기록합니다.
유형/테이블별 레코드 및 바이트	예상치 않은 볼륨, 필터링 오류 및 비대칭을 식별합니다.
처리 대기 시간	op_ts에서 내구성 다운스트림 커밋까지의 시간입니다. 출처 및 소비자 시계 차이를 고려합니다.
내부 대기열 깊이 및 가장 오래된 대기열에 있는 기간	메모리 소진 전에 역압을 감지합니다.
스키마/메타데이터 버전 변경	DDL 및 계약 변경을 감지합니다.
중복 및 idempotency 충돌 수	전달 및 체크포인트 동작을 검증합니다.
데드레터 및 검증 실패	수동 또는 자동 수정이 필요한 레코드를 표시합니다.

버퍼 및 용량 계획

bufferSize는 서비스가 인메모리 메시지 대기열을 클라이언트로 비우는 바이트 임계값을 제어합니다. 값이 클수록 일괄 처리 효율성이 향상되지만 메시지당 메모리 사용 및 대기 시간이 증가할 수 있습니다. 값이 작을수록 대기 시간이 줄어들지만 메시지 오버헤드가 증가합니다. 내구성이 뛰어난 대기열이 아니며 추적 보존을 대체하지 않으며 소비자 역압 제어의 필요성을 제거하지 않습니다.

• 대표적인 트랜잭션 크기, LOB, DDL, 테이블 개수 및 최대 처리 능력을 테스트합니다.

• WebSocket 및 프록시 최대 메시지 크기를 가장 큰 예상 일괄 처리를 초과하도록 설정합니다.

• 제한되지 않은 메모리 증가를 허용하지 않고 제한된 큐를 사용하고 빠르게 실패합니다.

• 각 단계를 측정할 수 있도록 별도의 네트워크 수신, 검증, 다운스트림 I/O 및 체크포인트 커밋이 수행됩니다.

재연결 전략

• 마지막으로 수신한 레코드가 아니라 마지막 영구 체크포인트에서 다시 연결합니다.

• 최대 지연 및 지터와 함께 지수 백오프를 사용합니다.

• 안정적인 연결 후 지연을 재설정합니다.

• 부적합한 자격 증명 또는 사용할 수 없는 저장된 위치와 같은 재시도할 수 없는 실패를 분류하고 영원히 재시도하지 않고 운영자 경보를 발생시킵니다.

• 복구 중에 동일한 출력 계약을 유지합니다. 스트림 구성이 변경된 경우 재개하기 전에 호환성 검증을 완료하십시오.

여러 소비자

데이터 스트림은 Kafka 스타일의 소비자 그룹이나 서버 관리 소비자별 오프셋을 제공하지 않습니다. 각 독립 클라이언트는 자체 체크포인트를 유지 관리하고 해당 연결 및 begin 값에 따라 레코드를 수신해야 합니다. 외부 조정자가 단일 소유권 및 주문된 체크포인트 갱신을 보장하지 않는 한 동시에 활성 상태인 소비자 간에 하나의 체크포인트를 공유하지 마십시오.

변경 사항 관리

• 데이터 스트림 구성의 버전을 지정하고 소비자 릴리스와 함께 AsyncAPI YAML을 생성했습니다.

• 생성, 연결, 안정된 상태 처리, 연결 해제, 재시작, 위치 유지 실패, DDL, 대용량 레코드 및 인증서 교체를 테스트합니다.

• 새 페이로드 필드 또는 스키마 변경을 사용으로 설정하기 전에 호환되는 소비자 코드를 배치하십시오.

• 마지막으로 알려진 정상 작동이 확인된 체크포인트 및 구성을 보존하는 롤백 계획을 유지합니다.