パフォーマンスのトラブルシューティング - Managed Service for Apache Flink

Amazon Managed Service for Apache Flink は、以前は Amazon Kinesis Data Analytics for Apache Flink と呼ばれていました。

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

パフォーマンスのトラブルシューティング

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

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

データパス

アプリケーションのパフォーマンス上の問題を調査するときは、データがたどる経路全体を考慮してください。以下のアプリケーションコンポーネントは、適切に設計またはプロビジョニングされていないと、パフォーマンスのボトルネックとなり、バックプレッシャーとなる可能性があります。

  • データソースとデスティネーション:」アプリケーションがやり取りする外部リソースが、アプリケーションのスループットに合わせて適切にプロビジョニングされていることを確認してください。

  • 状態データ:」アプリケーションがステート・ストアとあまり頻繁にやり取りしないようにしてください。

    アプリケーションが使用しているシリアライザーを最適化できます。デフォルトの Kryo シリアライザーはシリアライズ可能なすべての型を処理できますが、アプリケーションが POJO タイプにしかデータを保存しない場合には、より高性能なシリアライザーを使用できます。Apache Flink シリアライザーについて詳しくは、Apache Flink ドキュメントの「データ型とシリアル化」を参照してください。

  • オペレータ:」オペレータが実装するビジネスロジックが複雑すぎないことや、処理されるレコードごとにリソースを作成したり使用したりしていないことを確認してください。また、アプリケーションがスライディングウィンドウやタンブリングウィンドウをあまり頻繁に作成していないようにしてください。

パフォーマンストラブルシューティングソリューション

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

CloudWatch 監視レベル

CloudWatch 監視レベルがあまりにも冗長な設定になっていないか確認してください。

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

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

詳細については、「アプリケーションモニタリングレベル」を参照してください。

アプリケーション CPU メトリック

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

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

注記

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

アプリケーション並列処理

アプリケーションの並列度を増やす。アクションのパラメータを使用してアプリケーションの並列処理を更新します。ParallelismConfigurationUpdate UpdateApplication

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

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

アプリケーションログ

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

オペレータ並列処理

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

アプリケーションのオペレータのワークロードのチューニングについては、 オペレータースケーリング を参照してください。

アプリケーションロジック

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

アプリケーションが外部依存関係を使用して受信データを強化したり処理したりする場合は、代わりに非同期 IO の使用を検討してください。詳細については、「Apache Flink ドキュメント」の「非同期 IO」を参照してください。

アプリケーションメモリ

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