내용으로 건너뛰기

Amazon Managed Service for Apache Flink 애플리케이션이 다시 시작되는 이유는 무엇입니까?

3분 분량
0

Amazon Managed Service for Apache Flink 애플리케이션이 계속 다시 시작됩니다.

해결 방법

작업이 실패하면 Apache Flink 애플리케이션은 실패한 작업과 영향을 받은 다른 작업을 다시 시작하여 작업을 정상 상태로 되돌립니다.

다음은 이 문제의 몇 가지 원인과 문제 해결 단계입니다.

코드 오류

NullPointerExceptionDataCast 유형과 같은 코드 오류는 작업 관리자에서 생성되어 작업 관리자에서 종료됩니다. 그러면 애플리케이션이 최신 체크포인트에서 다시 시작됩니다. 애플리케이션에서 처리되지 않은 예외로 인해 애플리케이션이 다시 시작되는지 감지하려면 가동 중지 시간과 같은 Amazon CloudWatch 지표를 확인하십시오. 이 지표는 재시작 기간 동안 0이 아닌 값을 표시합니다. 이러한 현상이 발생하는 원인을 파악하려면 애플리케이션 로그를 쿼리하여 애플리케이션 상태가 RUNNING에서 FAILED로 변경되었는지 확인합니다. 자세한 내용은 오류 분석: 애플리케이션 작업 관련 장애를 참조하십시오.

메모리 부족 예외

메모리 부족 예외가 발생하면 작업 관리자가 작업 관리자에게 정상적인 하트비트 신호를 보낼 수 없고 애플리케이션이 다시 시작됩니다. 이 경우 TimeoutException, FlinkException 또는 RemoteTransportException과 같은 오류가 애플리케이션 로그에 표시될 수 있습니다.

CPU 또는 메모리 리소스 압력으로 인해 애플리케이션이 과부하되었는지 확인합니다.

  • fullRestarts가동 중지 시간 CloudWatch 지표에 0이 아닌 값이 있는지 확인합니다.
  • cpuUtilizationheapMemoryUtilization 지표에 비정상적인 급증이 있는지 확인합니다.
  • 애플리케이션 코드에서 처리되지 않은 예외가 있는지 검사합니다.
  • 체크포인트 및 세이브포인트 장애를 검사합니다. 급증 및 꾸준한 증가를 확인하기 위해 numOFFailedCheckpoints, lastCheckpointSizelastCheckpointDuration CloudWatch 지표를 모니터링합니다.

급증과 꾸준한 증가를 해결하려면 다음 작업을 완료하십시오.

  • 애플리케이션에 대한 디버그 로그를 활성화한 경우, 애플리케이션 리소스 사용률이 높을 수 있습니다. 로깅 양을 줄이려면 문제를 조사할 때만 디버그 로그를 일시적으로 활성화합니다.
  • Apache Flink 대시보드에서 TaskManager 스레드 덤프를 분석합니다. 예를 들어 스레드 덤프에서 CPU를 많이 사용하는 프로세스를 식별할 수 있습니다.
  • 구성된 플레임 그래프를 검토하려면 스택 추적을 여러 번 샘플링합니다. 차단된 직접 호출을 확인하려면 CPU 외부 플레임 그래프를 사용하십시오. 플레임 그래프에 대한 자세한 내용은 Apache Flink 웹사이트의 플레임 그래프를 참조하십시오.

스로틀링 오류

애플리케이션이 소스 또는 싱크에 대한 프로비저닝이 부족한 경우 Kinesis Data Streams와 같은 스트리밍 서비스를 읽고 쓸 때 애플리케이션에서 스로틀링 오류가 발생할 수 있습니다. 이 문제로 인해 애플리케이션이 충돌할 수 있습니다. 소스 및 싱크의 처리량을 확인하려면 WriteProvisionedThroughputExceededReadProvisionedThroughputExceeded와 같은 CloudWatch 지표를 사용하십시오. 데이터 볼륨을 수용하려면 샤드 수를 늘려 데이터 스트림을 스케일 업합니다.

제한 시간 오류

FlinkKinesisProducer는 Kinesis Producer Library(KPL)를 사용하여 Flink 스트림의 데이터를 Kinesis Data Stream에 넣습니다. 제한 시간 오류로 인해 KPL에서 오류가 발생하여 Flink 애플리케이션이 다시 시작될 수 있습니다. 이 경우 버퍼링 시간과 재시도 횟수가 늘어날 수 있습니다. KPL에 대한 RecordMaxBufferedTime, RecordTtlRequestTimeout 구성을 수정하여 레코드가 만료되지 않도록 할 수 있습니다. 자세한 내용은 GitHub 웹사이트의 default_config.properties를 참조하십시오. 또한 ErrorsByCode, RetriesPerRecord, UserRecordsPending과 같은 중요한 KPL 지표를 모니터링합니다. 이러한 지표를 통해 애플리케이션이 다시 시작된 것으로 나타나면 CloudWatch Logs Insights의 필터를 사용하여 애플리케이션의 재시작을 초래한 장애를 파악합니다.

모든 오류가 애플리케이션을 즉시 다시 시작하게 하는 것은 아닙니다. 예를 들어 애플리케이션 코드의 오류로 인해 DAG(Directed Acyclic Graph, 유향 비순환 그래프) 워크플로 오류가 발생할 수 있습니다. 이 경우 애플리케이션의 DAG가 생성되지 않습니다. 애플리케이션이 종료되고 즉시 다시 시작되지 않습니다. 또한 액세스 거부됨 오류가 발생해도 애플리케이션이 즉시 다시 시작되지 않습니다.

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

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

관련 정보

애플리케이션 재시작 중

AWS 공식업데이트됨 4년 전