Amazon Kinesis Data Analytics 애플리케이션이 다시 시작되는 이유는 무엇입니까?

최종 업데이트 날짜: 2022년 3월 2일

Amazon Kinesis Data Analytics for Apache Flink 애플리케이션이 다시 시작되고 있습니다.

해결 방법

작업이 실패하면 Apache Flink 애플리케이션이 실패한 작업 및 영향을 받는 다른 작업을 다시 시작하여 작업을 정상 상태로 만듭니다.

다음은 이 조건에 대한 몇 가지 원인 및 각 문제의 해결 단계입니다.

  • NullPointer Exception 및 DataCast 유형 등의 코드 오류는 일반적으로 업무 관리자에서 발생하며, 작업 관리자로 이동합니다. 그런 다음 애플리케이션이 최신 체크포인트에서 다시 시작됩니다. 애플리케이션에서 처리되지 않은 예외로 인한 애플리케이션 재시작을 감지하려면 대기 시간 등의 Amazon CloudWatch 지표를 확인하십시오. 이 지표는 재시작 기간 동안 0이 아닌 값을 표시합니다. 이 조건의 원인을 식별하려면 애플리케이션 상태의 변화에 대한 애플리케이션 로그를 RUNNING에서 FAILED로 쿼리하십시오. 자세한 내용은 오류 분석: 애플리케이션 작업 관련 오류를 참조하세요.
  • 메모리 부족 예외가 발생하면 작업 관리자는 정상 하트비트 신호를 작업 관리자에게 전송할 수 없으므로 애플리케이션이 다시 시작됩니다. 이러한 경우 애플리케이션 로그에서 TimeoutException, FlinkException 또는 RemoteTransportException 등의 오류를 확인할 수 있습니다. CPU 또는 메모리 리소스 압력으로 인해 애플리케이션이 오버로드되었는지 확인합니다.
    • CloudWatch 지표 fullRestartsdowntime가 0이 아닌 값인지 확인하십시오.
    • 지표 cpuUtilizationheapMemoryUtilization에서 비정상적인 스파이크가 발생했는지 확인합니다.
    • 애플리케이션 코드에서 처리되지 않은 예외가 있는지 확인합니다.
    • 체크포인트 및 저장점 실패를 확인합니다. CloudWatch 지표 numOFFailedCheckpoints, lastCheckpointSizelastCheckpointDuration에 스파이크 또는 지속적인 증가가 발생했는지 모니터링합니다.
      이 문제를 해결하려면 다음을 시도합니다.
    • 애플리케이션에 대한 디버그 로그를 활성화한 경우, 애플리케이션 리소스 사용량이 많을 수 있습니다. 문제를 조사할 때에 한하여 디버그 로그를 임시로 활성화해 로깅 양을 줄이십시오.
    • Apache Flink 대시보드에서 TaskManager 스레드 덤프를 분석합니다. 예를 들어 스레드 덤프에서 CPU를 많이 사용하는 프로세스를 식별할 수 있습니다.
    • 스택 추적을 여러 번 샘플링하여 구축한 Flame 그래프를 검토합니다. Flame 그래프를 사용하여 전반적인 애플리케이션 상태 시각화, 가장 CPU 리소스를 많이 사용하는 방식 식별, 그리고 스택에서 특정 방식의 실행을 유도하는 일련의 호출 식별 등을 수행할 수 있습니다. 차단된 호출 중 CPU를 사용하지 않는 Flame 그래프를 사용하는 경우가 있는지 확인합니다.
  • 애플리케이션이 소스 또는 싱크를 과소 프로비저닝하는 경우, Kinesis 데이터 스트림 등의 스트리밍 서비스를 읽고 쓸 때 애플리케이션에서 제한 오류가 발생할 수 있습니다. 이 조건은 결국 애플리케이션 충돌로 이어질 수 있습니다. WriteProvisionedThroughputExceededReadProvisionedThroughputExceeded 등의 CloudWatch 지표를 사용하는 소스 및 싱크의 처리량을 확인합니다. 샤드 수를 늘려서 데이터 볼륨을 수용하도록 데이터 스트림을 확장하는 방안을 고려해 보십시오.
  • FlinkKinesisProducer는 Kinesis Producer Library(KPL)를 사용하여 Flink 스트림에서 Kinesis 데이터 스트림으로 데이터를 보냅니다. 시간 초과 등의 오류로 인해 KPL에 오류가 발생하여, 결국 Flink 애플리케이션이 다시 시작될 수 있습니다. 이러한 경우에는 버퍼링 시간 및 재시도 횟수가 증가할 수 있습니다. 레코드가 만료되지 않도록 KPL에 대한 다음 구성을 조정할 수 있습니다 (RecordMaxBufferedTime, RecordTtlRequestTimeout). 또한 ErrorsByCode, RetriesPerRecordUserRecordsPending 등의 중요 KPL 지표를 모니터링합니다. 이러한 지표에 애플리케이션이 다시 시작 중이라고 표시되면, CloudWatch 로그 인사이트 내 필터를 사용하여 재시작을 유도한 오류의 정확한 원인을 파악할 수 있습니다.
  • 모든 오류로 애플리케이션이 즉시 다시 시작되지는 않습니다. 예를 들면 애플리케이션 코드 오류로 인해 DAG 워크플로 오류가 발생할 수 있습니다. 이 경우 애플리케이션의 유방향 비순환 그래프(DAG)가 생성되지 않습니다. 애플리케이션은 종료되고 즉시 다시 시작되지 않습니다. 또한 "액세스 거부" 오류가 발생하면 애플리케이션이 즉시 다시 시작되지 않습니다.

그래도 문제가 지속되면 AWS Support에 문의하여 다음 정보를 제공하십시오.

  • 애플리케이션 ARN
  • 애플리케이션의 소스 및 싱크에 대한 정보
  • 애플리케이션에 대한 CloudWatch 로그
  • 발행 시간(UTC)
  • Flink 대시보드의 관련 스레드 덤프

이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요하세요?