翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アプリケーションが再起動している
<a name="troubleshooting-rt-restarts"></a>

アプリケーションが正常でない場合、その Apache Flink ジョブは繰り返し失敗して再起動します。このセクションでは、この状態の症状とトラブルシューティングの手順について説明します。

## 症状
<a name="troubleshooting-rt-restarts-symptoms"></a>

この状態では、次の症状が発生する可能性があります。
+ `FullRestarts` 指標はゼロではない。このメトリクスは、アプリケーションを起動してからアプリケーションのジョブが再開された回数を表します。
+ `Downtime` 指標はゼロではない。このメトリクスは、アプリケーションが `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 Data Streams が適切にプロビジョニングされていない:** アプリケーションのソースまたはシンクが Kinesis データストリームの場合は、ストリームの [メトリクス](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) に `ReadProvisionedThroughputExceeded` または `WriteProvisionedThroughputExceeded` エラーがないか確認してください。

  これらのエラーが表示される場合は、ストリームのシャード数を増やすことで Kinesis ストリームの利用可能なスループットを増やすことができます。詳細については、「[Kinesis データストリームで開いているシャードの数を変更するにはどうすればよいですか](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)」を参照してください。
+ **他のソースまたはシンクが適切にプロビジョニングされていないか、使用できない:** アプリケーションがソースとシンクを正しくプロビジョニングしていることを確認してください。アプリケーションで使用されるソースまたはシンク (他の AWS サービス、外部ソースまたは送信先など) が適切にプロビジョニングされているか、読み取りまたは書き込みスロットリングが発生していないか、または定期的に使用できないことを確認します。

  依存するサービスでスループット関連の問題が発生している場合は、それらのサービスが利用できるリソースを増やすか、エラーや利用不能の原因を調査してください。
+ **オペレータが適切にプロビジョニングされていない:** アプリケーション内のいずれかのオペレータのスレッドのワークロードが正しく分散されていないと、オペレータが過負荷になり、アプリケーションがクラッシュする可能性があります。オペレータの並列処理のチューニングについては、「[オペレータースケーリングの適切な管理](performance-improving.md#performance-improving-scaling-op)」を参照してください。
+ **アプリケーションが DaemonException で失敗する:** 1.11 より前のバージョンの Apache Flink を使用している場合、このエラーはアプリケーションログに表示されます。0.14 以降の KPL バージョンを使用するには、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 Not Found エラーでアプリケーションが失敗する:** このエラーは、アプリケーションが Apache Beam を使用しているが、正しい依存関係または依存バージョンがない場合に発生します。Apache Beam を使用する Apache Flink 用 Managed Serviceアプリケーションでは、以下のバージョンの依存関係を使用する必要があります。

  ```
  <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` の正しいバージョンを明示的な依存関係として指定しないと、アプリケーションはそれを環境の依存関係から読み込み、バージョンが一致しないため、実行時にアプリケーションがクラッシュします。

  Apache Beam 向けの Apache Flink 用 Managed Service の使用に関する詳細については、[CloudFormation を使用するApache Beam を使用してアプリケーションを作成する](examples-beam.md) を参照してください。
+ 「**アプリケーションが java.io.IOException: ネットワークバッファの数が不十分で失敗する**」

  アプリケーションに十分なメモリがネットワークバッファに割り当てられていない場合に発生します。ネットワークバッファはサブタスク間の通信を容易にします。ネットワーク経由で送信する前にレコードを保存したり、受信データをレコードに分解してサブタスクに渡す前に保存したりするために使用されます。必要なネットワークバッファの数は、ジョブグラフの並列処理と複雑さに直接影響します。この問題を軽減する方法はいくつかあります。
  + `parallelismPerKpu` を低く設定することで、サブタスクやネットワーク・バッファごとに割り当てられるメモリーを増やすことができます。`parallelismPerKpu`を下げると KPU が増加し、したがってコストも増加することに注意してください。これを避けるには、並列処理を同じ係数だけ下げることで、同じ量の KPU を維持できます。
  + オペレータの数を減らすか、オペレータをチェーン化して必要なバッファの数を減らすことで、ジョブグラフを簡略化できます。
  + それ以外の場合は、https://aws.amazon.com/premiumsupport/ に連絡して、カスタムネットワークバッファー構成を依頼することもできます。