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

# パフォーマンスの問題をトラブルシューティングする
<a name="performance-troubleshooting"></a>

このセクションには、パフォーマンスの問題を診断して修正するために確認できる徴候のリストが含まれています。

データソースが Kinesis ストリームの場合、パフォーマンスの問題は通常、高いまたは増加する `millisbehindLatest` メトリクスとして現れます。他のソースについては、ソースからの読み取りの遅れを表す同様のメトリクスを確認できます。

## データパスを理解する
<a name="performance-troubleshooting-data"></a>

アプリケーションのパフォーマンス上の問題を調査するときは、データがたどる経路全体を考慮してください。以下のアプリケーションコンポーネントは、適切に設計またはプロビジョニングされていないと、パフォーマンスのボトルネックとなり、バックプレッシャーとなる可能性があります。
+ **データソースとデスティネーション:** アプリケーションがやり取りする外部リソースが、想定されるスループットに対応できるように適切にプロビジョニングされていることを確認します。
+ 「**状態データ:**」アプリケーションがステート・ストアとあまり頻繁にやり取りしないようにしてください。

  アプリケーションが使用しているシリアライザーを最適化できます。デフォルトの Kryo シリアライザーはシリアライズ可能なすべての型を処理できますが、アプリケーションが POJO タイプにしかデータを保存しない場合には、より高性能なシリアライザーを使用できます。Apache Flink シリアライザーについて詳しくは、「Apache Flink ドキュメント」の「[Data Types & Serialization](                 https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/serialization/types_serialization/)」を参照してください。
+ 「**オペレータ:**」オペレータが実装するビジネスロジックが複雑すぎないことや、処理されるレコードごとにリソースを作成したり使用したりしていないことを確認してください。また、アプリケーションがスライディングウィンドウやタンブリングウィンドウをあまり頻繁に作成していないようにしてください。

## パフォーマンスのトラブルシューティングソリューション
<a name="performance-troubleshooting-solutions"></a>

このセクションでは、パフォーマンスに関する問題のソリューションを紹介します。

**Topics**
+ [CloudWatch モニタリングレベル](#performance-troubleshooting-solutions-monitoring)
+ [アプリケーション CPU メトリクス](#performance-troubleshooting-solutions-cpu)
+ [アプリケーションの並列度](#performance-troubleshooting-solutions-parallelism)
+ [アプリケーションログ](#performance-troubleshooting-solutions-logging)
+ [オペレーターの並列処理](#performance-troubleshooting-solutions-operators)
+ [アプリケーションロジック](#performance-troubleshooting-solutions-logic)
+ [アプリケーションメモリ](#performance-troubleshooting-solutions-memory)

### CloudWatch モニタリングレベル
<a name="performance-troubleshooting-solutions-monitoring"></a>

CloudWatch モニタリングレベルがあまりにも冗長な設定になっていないことを確認します。

`Debug` モニタリングログレベル設定では大量のトラフィックが生成され、バックプレッシャーが発生する可能性があります。アプリケーションの問題を積極的に調査する場合にのみ使用してください。

アプリケーション `Parallelism` の設定が高い場合、 ` Parallelism` モニタリングメトリクスレベルを使用すると同様に大量のトラフィックが生成され、バックプレッシャーにつながる可能性があります。このメトリクス・レベルは、アプリケーションの `Parallelism` が低い場合、またはアプリケーションの問題を調査している場合にのみ使用します。

詳細については、「[アプリケーションのモニタリングレベルを制御する](cloudwatch-logs.md#cloudwatch_levels)」を参照してください。

### アプリケーション CPU メトリクス
<a name="performance-troubleshooting-solutions-cpu"></a>

アプリケーションの `CPU` メトリクスを確認してください。このメトリックスが 75% を超える場合は、自動スケーリングを有効にすることで、アプリケーションがアプリケーション自体により多くのリソースを割り当てられるようにすることができます。

自動スケーリングが有効になっている場合、CPU 使用率が 15 分間 75% を超えると、アプリケーションはより多くのリソースを割り当てます。スケーリングの詳細については、次の [スケーリングを適切に管理する](performance-improving.md#performance-improving-scaling) セクション、「[アプリケーションスケーリングを実装する](how-scaling.md)」を参照してください。

**注記**  
アプリケーションは CPU 使用率に応じてのみ自動的にスケーリングされます。アプリケーションは、`heapMemoryUtilization` などの他のシステムメトリクスに応じて自動スケーリングすることはありません。アプリケーションで他のメトリクスの使用率が高い場合は、アプリケーションの並列度を手動で増やします。

### アプリケーションの並列度
<a name="performance-troubleshooting-solutions-parallelism"></a>

アプリケーションの並列度を増やす。「[UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)」アクションの `ParallelismConfigurationUpdate` パラメータを使用して、アプリケーションの並列度を更新します。

 アプリケーションの最大 KPU はデフォルトで 64 ですが、制限の引き上げをリクエストすることで増やすことができます。

アプリケーションの並列度だけを増やすのではなく、そのワークロードに基づいて各オペレータに並列度を割り当てることも重要です。以下の [オペレーターの並列処理](#performance-troubleshooting-solutions-operators) を参照してください。

### アプリケーションログ
<a name="performance-troubleshooting-solutions-logging"></a>

処理中のすべてのレコードについて、アプリケーションがエントリを記録しているかどうかを確認してください。アプリケーションのスループットが高いときに各レコードにログエントリを書き込むと、データ処理に重大なボトルネックが生じます。この状態を確認するには、アプリケーションが処理するレコードごとに書き込まれるログエントリをログに問い合わせてください。アプリケーションログの読み取りの詳細については、 [CloudWatch Logs Insights でログを解析する](cloudwatch-logs-reading.md) を参照してください。

### オペレーターの並列処理
<a name="performance-troubleshooting-solutions-operators"></a>

アプリケーションのワークロードがワーカープロセスに均等に分散されていることを確認します。

アプリケーションのオペレータのワークロードのチューニングについては、 [オペレータースケーリング](performance-improving.md#performance-improving-scaling-op) を参照してください。

### アプリケーションロジック
<a name="performance-troubleshooting-solutions-logic"></a>

外部依存関係（データベースやウェブサービスなど）へのアクセス、アプリケーション・ステートへのアクセスなど、非効率的な操作や非実行的な操作がないか、アプリケーションロジックを調べます。外部依存関係は、パフォーマンスが低かったり、確実にアクセスできない場合にもパフォーマンスを低下させる可能性があり、外部依存関係から `HTTP 500` エラーが返される可能性があります。

アプリケーションが外部依存関係を使用して受信データを強化したり処理したりする場合は、代わりに非同期 IO の使用を検討してください。詳細については、「[Apache Flink ドキュメント](https://ci.apache.org/projects/flink/flink-docs-release-1.8/)」の「[非同期 IO](https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/asyncio.html)」を参照してください。

### アプリケーションメモリ
<a name="performance-troubleshooting-solutions-memory"></a>

アプリケーションにリソースリークがないかチェックします。アプリケーションがスレッドやメモリを適切に処理していないと、 `millisbehindLatest`、`CheckpointSize`、`CheckpointDuration` メトリクスが急増したり徐々に増加したりしていることがあります。この状態は、タスクマネージャーやジョブマネージャーの障害の原因にもなります。