기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 애플리케이션 다시 시작 중
<a name="troubleshooting-rt-restarts"></a>

사용하시는 애플리케이션이 정상이 아닌 경우 Apache Flink 작업이 계속 실패하고 다시 시작됩니다. 이 섹션에서는 이러한 상태에 대한 증상과 문제 해결 조치들을 설명합니다.

## 증상
<a name="troubleshooting-rt-restarts-symptoms"></a>

이 상태는 다음과 같은 증상이 있을 수 있습니다:
+ `FullRestarts` 지표가 0이 아님. 이 지표는 측정 단위는 귀하가 애플리케이션을 시작한 이후 해당 애플리케이션의 작업이 다시 시작된 횟수를 나타냅니다.
+ `Downtime` 지표가 0이 아님. 이 지표는 애플리케이션이 `FAILING` 또는 `RESTARTING` 상태에 있는 밀리초의 수치를 나타냅니다.
+ 애플리케이션 로그는 `RESTARTING` 또는 `FAILED`로의 상태 변경을 포함합니다. 다음과 같은 CloudWatch Logs Insights 쿼리를 사용하여 애플리케이션 로그에서 이러한 상태 변경을 검색할 수 있습니다. [오류 분석: 애플리케이션 작업 관련 실패](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).

## 원인 및 해결 방법
<a name="troubleshooting-rt-restarts-causes"></a>

다음과 같은 상태 하에서 애플리케이션은 불안정해지고 반복적으로 다시 시작될 수 있습니다.
+ **연산자가 예외를 발생시키는 경우:** 귀하의 애플리케이션에서 연산자의 예외가 처리되지 않으면 연산자가 오류를 처리할 수 없다고 해석하여 애플리케이션이 페일오버됩니다. “정확히 한 번” 처리하라는 의미를 유지하기 위해 애플리케이션이 최근의 체크포인트에서 다시 시작됩니다. 따라서 이러한 재시작 기간 동안에는 `Downtime`의 값이 0이 아닙니다. 이러한 일이 발생하지 않도록 하려면 애플리케이션 코드에서 재시도 가능한 예외를 모두 처리하는 것이 좋습니다.

  애플리케이션 로그를 검색하여 애플리케이션 상태를 `RUNNING`에서 `FAILED`로 변경할 것을 요청함으로써 이 상태의 원인을 조사할 수 있습니다. 자세한 내용을 알아보려면 [오류 분석: 애플리케이션 작업 관련 실패](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps) 섹션을 참조하세요.
+ **Kinesis 데이터 스트림이 제대로 프로비저닝되지 않음**: 애플리케이션의 소스 또는 싱크가 Kinesis 데이터 스트림인 경우, 스트림의 [지표](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)에 `ReadProvisionedThroughputExceeded` 또는 `WriteProvisionedThroughputExceeded` 오류가 있는지 확인하세요.

  이러한 오류가 표시되면 스트림의 샤드 수를 늘려 Kinesis 스트림의 가용 처리량을 늘릴 수 있습니다. 자세한 내용을 알아보려면 [Kinesis Data Streams에서 열린 샤드 수를 변경하려면 어떻게 해야 하는가?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)를 참조하십시오.
+ **다른 소스 또는 싱크가 제대로 프로비저닝되거나 사용 가능하지 않음:** 애플리케이션이 소스 및 싱크를 올바르게 프로비저닝하고 있는지 확인하세요. 애플리케이션에 사용되는 소스 또는 싱크(예: 다른 AWS 서비스, 외부 소스 또는 대상)가 잘 프로비저닝되어 있거나, 읽기 또는 쓰기 제한이 없거나, 주기적으로 사용할 수 없는지 확인합니다.

  종속 서비스에서 처리량 관련 문제가 발생하는 경우 해당 서비스에 사용할 수 있는 리소스를 늘리거나 오류 또는 사용 불능의 원인을 조사하십시오.
+ **연산자가 제대로 프로비저닝되지 않은 경우:** 애플리케이션의 연산자 중 하나에 대한 스레드의 워크로드가 제대로 분배되지 않으면 연산자에 과부하가 걸리고 애플리케이션이 와해될 수 있습니다. 연산자 병렬성 조정에 대한 자세한 내용을 알아보려면 [연산자 스케일링을 적절하게 관리](performance-improving.md#performance-improving-scaling-op) 섹션을 참조하십시오.
+ **DaemonException에서의 애플리케이션 실패:** 이 오류는 Apache Flink 1.11 이전 버전을 사용하는 경우 귀하의 애플리케이션 로그에 나타납니다. KPL 0.14 또는 그 이후 버전을 사용하려면 Apache Flink를 이후 버전으로 업그레이드해야 할 수 있습니다.
+ **TimeoutException, FlinkException 또는 RemoteTransportException에서 애플리케이션이 실패함:** 작업 관리자가 충돌하는 경우 이러한 오류가 애플리케이션 로그에 나타날 것입니다. 애플리케이션에 과부하가 걸리면 작업 관리자가 CPU 또는 메모리 리소스 부족을 경험하여 실패가 발생할 수 있습니다.

  이러한 오류는 아마 다음과 같을 것입니다.
  + `java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out`
  + `org.apache.flink.util.FlinkException: The assigned slot xxx was removed`
  + `org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager`

  이 문제를 해결하려면 다음과 같이 하세요.
  + CloudWatch 측정치를 확인하여 CPU 또는 메모리 사용량이 비정상적으로 급증했는지 확인하십시오.
  + 애플리케이션에서 처리량 문제를 확인하십시오. 자세한 내용을 알아보려면 [성능 문제 해결](performance-troubleshooting.md) 섹션을 참조하세요.
  + 애플리케이션 로그에서 애플리케이션 코드에서 발생하는 처리되지 않은 예외가 있는지 확인하십시오.
+ **JaxBannotationModule에서 찾을 수 없음 오류로 인해 애플리케이션 실패. 이 오류는 애플리케이션에서 Apache Beam을 사용하지만 의존성 또는 의존성 버전이 올바르지** 않은 경우 발생합니다. Apache Beam을 사용하는 Managed Service for Apache Flink 애플리케이션은 다음 버전의 의존성을 사용해야 합니다.

  ```
  <jackson.version>2.10.2</jackson.version>
  ...
  <dependency>
      <groupId>com.fasterxml.jackson.module</groupId>
      <artifactId>jackson-module-jaxb-annotations</artifactId>
      <version>2.10.2</version>
  </dependency>
  ```

  정확한 버전의 `jackson-module-jaxb-annotations`를 명시적 의존성으로 제공하지 않으면 애플리케이션이 환경 의존성에서 해당 버전을 로드하고, 버전이 일치하지 않으므로 애플리케이션이 런타임에 충돌합니다.

  Managed Service for Apache Flink와 Apache Beam을 사용하는 방법에 대한 자세한 내용을 알아보려면 [CloudFormation 사용Apache Beam을 사용하여 애플리케이션 생성](examples-beam.md) 섹션을 참조하세요.
+ **Java.io.IOException에서 애플리케이션 실패: 네트워크 버퍼 수 부족.**

  이는 애플리케이션에 네트워크 버퍼에 할당된 메모리가 충분하지 않을 때 발생합니다. 네트워크 버퍼는 하위 작업 간의 통신을 용이하게 합니다. 또한 네트워크를 통해 전송하기 전에 레코드를 저장하고, 수신 데이터를 분해하여 기록하고 이를 하위 작업에 전달하기 전에 저장하는 데 사용됩니다. 필요한 네트워크 버퍼 수는 귀하의 작업 그래프의 병렬성과 복잡성에 따라 조정됩니다. 이 문제를 완화할 수 있는 여러 가지 방법이 있습니다.
  + 귀하는 하위 작업 및 네트워크 버퍼별로 더 많은 메모리가 할당되도록 더 낮은 값의`parallelismPerKpu` 을 구성할 수 있습니다. `parallelismPerKpu`을 낮추면 KPU가 증가하여 비용 또한 증가한다는 점에 유의하세요. 이를 방지하려면 병렬성을 같은 배수로 낮춰 KPU의 양을 동일하게 유지할 수 있습니다.
  + 연산자 수를 줄이거나 서로 연결하여 필요한 버퍼 수를 줄이면 귀하의 작업 그래프를 단순화할 수 있습니다.
  + 또는 https://aws.amazon.com/premiumsupport/ 에 문의하여 고객의 맞춤 네트워크 버퍼 구성에 대해 문의할 수 있습니다.