

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

# 성능 문제 해결
<a name="performance-troubleshooting"></a>

이 섹션에는 성능 문제를 진단하고 해결하기 위해 확인할 수 있는 증상 목록이 포함되어 있습니다.

데이터 소스가 Kinesis 스트림인 경우 성능 문제는 일반적으로 `millisbehindLatest` 지표가 높거나 증가하는 것으로 나타납니다. 다른 소스의 경우 소스의 읽기 지연을 나타내는 유사한 지표를 확인할 수 있습니다.

## 데이터 경로 이해
<a name="performance-troubleshooting-data"></a>

애플리케이션의 성능 문제를 조사할 때는 데이터가 취하는 전체 경로를 고려하세요. 다음과 같은 애플리케이션 구성 요소는 제대로 설계되거나 프로비저닝되지 않을 경우 성능 병목 현상이 발생하고 역압을 초래할 수 있습니다.
+ **데이터 소스 및 대상:** 애플리케이션이 상호 작용하는 외부 리소스가 애플리케이션이 경험하게 될 처리량을 지원할 수 있도록 적절히 프로비저닝되어 있는지 확인하세요.
+ **상태 데이터:** 애플리케이션이 상태 저장소와 너무 자주 상호 작용하지 않도록 하세요.

  애플리케이션이 사용하는 시리얼라이저를 최적화할 수 있습니다. 기본 Kryo 시리얼라이저는 모든 직렬화 가능 유형을 처리할 수 있지만 애플리케이션이 데이터를 POJO 유형으로만 저장하는 경우 더 성능이 좋은 시리얼라이저를 사용할 수 있습니다. Apache Flink 시리얼라이저에 관한 자세한 내용은 [Apache Flink 설명서의 데이터 유형 및 직렬화](                 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` Monitoring Metrics Level을 사용하면 마찬가지로 많은 양의 트래픽이 발생하여 역압으로 이어질 수 있습니다. 애플리케이션의 `Parallelism`이(가) 낮거나 애플리케이션 관련 문제를 조사할 때만 이 지표 수준을 사용하세요.

자세한 내용을 알아보려면 [애플리케이션 모니터링 수준 제어](cloudwatch-logs.md#cloudwatch_levels) 섹션을 참조하세요.

### 애플리케이션 CPU 지표
<a name="performance-troubleshooting-solutions-cpu"></a>

애플리케이션의 `CPU` 지표를 확인하세요. 이 지표가 75%를 초과하는 경우 Auto Scaling을 활성화하여 애플리케이션이 자체적으로 더 많은 리소스를 할당하도록 허용할 수 있습니다.

Auto Scaling이 활성화된 경우 15분 동안 CPU 사용량이 75% 를 초과하면 애플리케이션에서 더 많은 리소스를 할당합니다. 스케일링에 대한 자세한 내용은 다음 [적절한 크기 조정](performance-improving.md#performance-improving-scaling) 섹션 및 [애플리케이션 규모 조정 구현](how-scaling.md) 섹션을 참조하세요.

**참고**  
애플리케이션은 CPU 사용량에 따라서만 자동으로 규모가 조정됩니다. 애플리케이션은 `heapMemoryUtilization`와(과) 같은 다른 시스템 지표에 따라 Auto Scaling되지 않습니다. 애플리케이션의 다른 지표 사용량이 높은 경우 애플리케이션의 병렬성을 수동으로 높이세요.

### 애플리케이션 병렬성
<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/)의 [Async I/O](https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/asyncio.html)를 참조하세요.

### 애플리케이션 메모리
<a name="performance-troubleshooting-solutions-memory"></a>

애플리케이션에 리소스 누수가 있는지 확인하세요. 애플리케이션이 스레드나 메모리를 제대로 처리하지 않는 경우 `millisbehindLatest`, `CheckpointSize`, `CheckpointDuration`, 지표가 급증하거나 점차 증가할 수 있습니다. 이 경우 작업 관리자 또는 작업 관리자 오류가 발생할 수도 있습니다.