기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Managed Service for Apache Flink 문제 해결 다음 주제는 Amazon Managed Service for Apache Flink와 관련하여 발생할 수 있는 문제를 해결하는 데 도움이 되는 내용입니다. 해결 방법을 검토하려면 적절한 주제를 선택합니다. **Topics** + [개발 문제 해결](troubleshooting-development.md) + [런타임 문제 해결](troubleshooting-runtime.md) # 개발 문제 해결 이 섹션에는 Managed Service for Apache Flink 애플리케이션의 개발 문제를 진단하고 수정하는 방법에 대한 정보가 포함되어 있습니다. **Topics** + [시스템 롤백 모범 사례](troubleshooting-system-rollback.md) + [Hudi 구성 모범 사례](troubleshooting-hudi.md) + [Apache Flink 플레임 그래프](troubleshooting-update-flamegraphs.md) + [EFO 커넥터 1.15.2의 자격 증명 공급자 문제](troubleshooting-credential-provider.md) + [지원되지 않는 Kinesis 커넥터가 있는 애플리케이션](troubleshooting-unsupported-kinesis-connectors.md) + [컴파일 오류: ‘프로젝트의 종속성을 해결할 수 없음’](troubleshooting-compile.md) + [잘못된 선택: ‘kinesisanalyticsv2’](troubleshooting-cli-update.md) + [UpdateApplication 작업에서 애플리케이션 코드가 다시 로드되지 않는 문제](troubleshooting-update.md) + [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md) + [저장점 사용 중지 관련 FlinkKafkaConsumer 문제](troubleshooting-FlinkKafkaConsumer.md) + [Flink 1.15 Async Sink 교착 상태](troubleshooting-async-deadlock.md) + [리샤딩 중 Amazon Kinesis Data Streams 소스 처리 순서가 잘못됨](troubleshooting-kinesis-data-streams-processing-out-of-order.md) + [실시간 벡터 임베딩 블루프린트 FAQ 및 문제 해결](troubleshooting-blueprints.md) # 시스템 롤백 모범 사례 Amazon Managed Service for Apache Flink의 자동 시스템 롤백 및 운영 가시성 기능을 사용하여 애플리케이션의 문제를 식별하고 해결할 수 있습니다. ## 시스템 롤백 코드 버그 또는 권한 문제와 같은 고객 오류로 인해 애플리케이션 업데이트 또는 규모 조정 작업이 실패하는 경우 이 기능을 옵트인하면 Amazon Managed Service for Apache Flink는 자동으로 이전 실행 버전으로 롤백을 시도합니다. 자세한 내용은 [Managed Service for Apache Flink 애플리케이션의 시스템 롤백 활성화](how-system-rollbacks.md) 단원을 참조하십시오. 이 자동 롤백이 실패하거나 옵트인 또는 옵트아웃하지 않은 경우 애플리케이션은 `READY` 상태로 전환됩니다. 애플리케이션을 업데이트하려면 다음 단계를 완료합니다. 작업이 실패한 이유에 대한 오류 설명을 확인하려면 Amazon Managed Service for Apache Flink 콘솔을 확인하거나 `DescribeApplicationOperation` API를 사용합니다. 전체 오류 스택을 확인하려면 [Cloudwatch 로그](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html)를 사용합니다. 일반적인 문제는 권한 부족, 호환되지 않는 코드 변경 또는 인프라 구성 오류입니다. 근본적인 문제를 해결합니다. `UpdateApplicaton` API를 사용하여 새 애플리케이션 버전을 다시 배포합니다. ## 수동 롤백 애플리케이션이 진행되지 않고 일시적인 상태에 오래 머무르거나 `Running` 상태로 정상 전환되었지만 업데이트된 Flink 애플리케이션에서 처리 오류와 같은 다운스트림 문제가 발생하는 경우 `RollbackApplication` API를 사용하여 수동으로 롤백할 수 있습니다. 1. `RollbackApplication` 직접 호출 - 이전 실행 버전으로 되돌리고 이전 상태를 복원합니다. 1. `DescribeApplicationOperation` API를 사용하여 롤백 작업을 모니터링합니다. 1. 롤백에 실패하면 이전 시스템 롤백 단계를 사용합니다. ## 운영 가시성 `ListApplicationOperations` API는 애플리케이션의 모든 고객 기록 및 시스템 작업 기록을 보여줍니다. 1. 목록에서 실패한 작업의 *operationId*를 가져옵니다. 1. `DescribeApplicationOperation`을 직접적으로 호출하여 상태와 *statusDescription*을 확인합니다. 1. 작업이 실패한 경우 설명은 조사해야 할 잠재적 오류를 나타냅니다. **일반적인 오류 코드 버그:** 롤백 기능을 사용하여 마지막 정상 버전으로 되돌립니다. 버그를 해결하고 업데이트를 다시 시도합니다. **권한 문제:** `DescribeApplicationOperation`을 사용하여 필요한 권한을 확인합니다. 애플리케이션 권한을 업데이트한 뒤 다시 시도합니다. **Amazon Managed Service for Apache Flink 서비스 문제:**를 확인하거나 지원 사례를 AWS Health Dashboard 엽니다. # Hudi 구성 모범 사례 Managed Service for Apache Flink에서 Hudi 커넥터를 실행하려면 다음과 같이 구성을 변경할 것을 권장합니다. `hoodie.embed.timeline.server` 비활성화 Flink의 Hudi 커넥터는 작업 병렬 처리가 높을 때 성능을 향상시키기 위해 Flink jobmanager(JM)에 메타데이터를 캐시하는 임베디드 타임라인(TM) 서버를 설정합니다. Managed Service for Apache Flink에서는 JM과 TM 간의 비Flink 통신이 비활성화되어 있으므로 이 임베디드 서버를 비활성화할 것을 권장합니다. 이 서버가 활성화되는 경우 Hudi 쓰기 작업은 먼저 JM의 임베디드 서버에 연결을 시도한 뒤 Amazon S3에서 메타데이터를 읽는 방식으로 돌아갑니다. 이는 연결 시간 초과를 유발하여 Hudi 쓰기 작업이 지연되고 Managed Service for Apache Flink의 성능에 영향을 미칩니다. # Apache Flink 플레임 그래프 플레임 그래프는 플레임 그래프를 지원하는 Managed Service for Apache Flink버전의 애플리케이션에서 기본적으로 활성화됩니다. [Flink 설명서](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/)에 나와 있는 것처럼 그래프를 열어 두면 플레임 그래프가 애플리케이션 성능에 영향을 미칠 수 있습니다. 애플리케이션에 대해 플레임 그래프를 비활성화하려면 애플리케이션 ARN에서 플레임 그래프를 비활성화하도록 요청하는 케이스를 생성하십시오. 자세한 내용을 알아보려면 [AWS 지원 센터](https://console.aws.amazon.com/support/home#/)를 참조하세요. # EFO 커넥터 1.15.2의 자격 증명 공급자 문제 Kinesis 데이터 스트림 EFO 커넥터 버전 최대 1.15.2에는 `FlinkKinesisConsumer`가 `Credential Provider` 구성을 준수하지 않는 [알려진 문제가](https://issues.apache.org/jira/browse/FLINK-29205) 있습니다. 이 문제로 인해 유효한 구성이 무시되고 있으며, 이로 인해 `AUTO` 자격 증명 공급자가 사용됩니다. 이로 인해 EFO 커넥터를 사용하여 Kinesis에 대한 교차 계정 액세스를 사용할 때 문제가 발생할 수 있습니다. 이 오류를 해결하려면 EFO 커넥터 버전 1.15.3 이상을 사용하십시오. # 지원되지 않는 Kinesis 커넥터가 있는 애플리케이션 Managed Service for Apache Flink 버전 1.15 이상은 애플리케이션 JAR 또는 아카이브(ZIP)에 번들로 제공되는 지원되지 않는 Kinesis 커넥터 버전(1.15.2 이전 버전)을 사용하는 경우 [애플리케이션의 시작 또는 업데이트를 자동으로 거부합니다](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html). ## 거부 오류 다음을 통해 애플리케이션 생성/업데이트 호출을 제출할 때 다음 오류가 표시됩니다. ``` An error occurred (InvalidArgumentException) when calling the CreateApplication operation: An unsupported Kinesis connector version has been detected in the application. Please update flink-connector-kinesis to any version equal to or newer than 1.15.2. For more information refer to connector fix: https://issues.apache.org/jira/browse/FLINK-23528 ``` ## 해결 단계 + `flink-connector-kinesis`에 대한 애플리케이션 종속성을 업데이트하십시오. Maven을 프로젝트의 빌드 도구로 사용하고 있다면 [Maven 종속성 업데이트](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency)을 따르세요. Gradle을 사용하고 있다면 [Gradle 종속성 업데이트](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency)을 따르세요. + 애플리케이션을 재패키징합니다. + Amazon S3 버킷에 업로드합니다. + Amazon S3 버킷으로 업로드한 수정된 애플리케이션으로 애플리케이션 생성/업데이트 요청을 다시 제출합니다. + 동일한 오류 메시지가 계속 표시되면 애플리케이션 종속성을 다시 확인하십시오. 문제가 지속되면 지원 티켓을 생성하세요. ### Maven 종속성 업데이트 1. 프로젝트의 `pom.xml`를 엽니다. 1. 프로젝트의 종속성을 찾아보세요. 모양은 다음과 같습니다. ``` ... ... org.apache.flink flink-connector-kinesis ... ... ``` 1. 1.15.2 이상의 버전으로 `flink-connector-kinesis`을 업데이트하세요. 예를 들면 다음과 같습니다. ``` ... ... org.apache.flink flink-connector-kinesis 1.15.2 ... ... ``` ### Gradle 종속성 업데이트 1. 프로젝트 `build.gradle`(또는 Kotlin 애플리케이션의 `build.gradle.kts`)를 엽니다. 1. 프로젝트의 종속성을 찾아보세요. 모양은 다음과 같습니다. ``` ... dependencies { ... implementation("org.apache.flink:flink-connector-kinesis") ... } ... ``` 1. 1.15.2 이상의 버전으로 `flink-connector-kinesis`을 업데이트하세요. 예를 들면 다음과 같습니다. ``` ... dependencies { ... implementation("org.apache.flink:flink-connector-kinesis:1.15.2") ... } ... ``` # 컴파일 오류: ‘프로젝트의 종속성을 해결할 수 없음’ Managed Service for Apache Flink 샘플 애플리케이션을 컴파일하려면 먼저 Apache Flink Kinesis 커넥터를 다운로드하여 컴파일한 다음 로컬 Maven 저장소에 추가해야 합니다. 커넥터가 저장소에 추가되지 않은 경우 다음과 비슷한 컴파일 오류가 나타납니다. ``` Could not resolve dependencies for project your project name: Failure to find org.apache.flink:flink-connector-kinesis_2.11:jar:1.8.2 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced ``` 이 오류를 해결하려면 커넥터용 Apache Flink 소스 코드([https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html)의 버전 1.8.2)를 다운로드해야 합니다. Apache Flink 소스 코드를 다운로드, 컴파일 및 설치하는 방법에 대한 지침은 [Apache Flink Kinesis 스트림 커넥터를 이전 Apache Flink 버전과 함께 사용](earlier.md#how-creating-apps-building-kinesis) 섹션을 참조하십시오. # 잘못된 선택: ‘kinesisanalyticsv2’ Managed Service for Apache FlinkAPI의 v2를 사용하려면 최신 버전 AWS Command Line Interface (AWS CLI)이 필요합니다. 업그레이드에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*[의 설치를 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) AWS CLI참조하세요. # UpdateApplication 작업에서 애플리케이션 코드가 다시 로드되지 않는 문제 지정된 S3 객체 버전이 없는 경우 [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html) 작업은 동일한 파일 명칭을 가진 애플리케이션 코드를 다시 로드하지 않습니다. 애플리케이션 코드를 동일한 파일 명칭으로 다시 로드하려면 S3 버킷의 버전 관리를 활성화하고 `ObjectVersionUpdate` 파라미터를 사용하여 새 객체 버전을 지정하십시오. S3 버킷에서 객체 버전 관리 활성화에 대한 자세한 내용을 알아보려면 [버전 관리 활성화 또는 비활성화](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html)를 참조하세요. # S3 StreamingFileSink FileNotFoundExceptions Managed Service for Apache Flink 애플리케이션은 저장 포인트에서 참조하는 진행 중인 부분 파일이 없는 경우 스냅샷에서 시작할 때 진행 중인 부분 파일 `FileNotFoundException`로 실행될 수 있습니다. 이 오류 모드가 발생하면 Managed Service for Apache Flink 애플리케이션의 연산자 상태는 일반적으로 복구할 수 없으므로 `SKIP_RESTORE_FROM_SNAPSHOT`을 사용하는 스냅샷 없이 다시 시작해야 합니다. 다음 예 스택트레이스를 참조하십시오. ``` java.io.FileNotFoundException: No such file or directory: s3://amzn-s3-demo-bucket/pathj/INSERT/2023/4/19/7/_part-2-1234_tmp_12345678-1234-1234-1234-123456789012 at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:2231) at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2149) at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088) at org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:699) at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:950) at org.apache.flink.fs.s3hadoop.HadoopS3AccessHelper.getObject(HadoopS3AccessHelper.java:98) at org.apache.flink.fs.s3.common.writer.S3RecoverableMultipartUploadFactory.recoverInProgressPart(S3RecoverableMultipartUploadFactory.java:97) ... ``` Flink `StreamingFileSink`는 [파일 시스템](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/)에서 지원하는 파일 시스템에 레코드를 기록합니다. 들어오는 스트림을 제한하지 않을 수 있다는 점을 고려하면 데이터는 데이터가 기록될 때 새 파일이 추가되고 한정된 크기의 부분 파일로 구성됩니다. 부품 라이프사이클 및 롤오버 정책에 따라 부분 파일의 타이밍, 크기 및 명칭이 결정됩니다. 체크포인트 지정 및 저장점 지정(스냅샷) 중에는 보류 중인 모든 파일의 명칭이 바뀌고 구속됩니다. 그러나 진행 중인 부분 파일은 구속되지 않고 명칭이 변경되며 해당 참조는 작업을 복원할 때 사용할 체크포인트 또는 저장점 메타데이터에 보관됩니다. 진행 중인 이러한 부분 파일은 결국 미결로 넘겨지고 후속 체크포인트 또는 저장점에서 명칭을 바꾸고 구속됩니다. 진행 중인 부분 파일이 누락되는 근본 원인과 해결 방법은 다음과 같습니다. + Managed Service for Apache Flink 애플리케이션을 시작하는 데 사용되는 오래된 스냅샷 – 애플리케이션이 중지되거나 업데이트될 때 생성된 최신 시스템 스냅샷만 Amazon S3 StreamingFileSink를 사용하여 Managed Service for Apache Flink 애플리케이션을 시작하는 데 사용할 수 있습니다. 이러한 장애 클래스를 방지하려면 최신 시스템 스냅샷을 사용하십시오. + 예를 들어 중지 또는 업데이트 중에 시스템 트리거 스냅샷 대신 `CreateSnapshot`을 사용하여 만든 스냅샷을 선택할 때 이런 현상이 발생합니다. 이전 스냅샷의 저장점에는 후속 체크포인트 또는 저장점에 의해 명칭이 변경되고 구속된 진행 중인 부분 파일에 대한 오래된 참조가 보관됩니다. + 이는 최신이 아닌 Stop/Update 이벤트에서 시스템이 트리거한 스냅샷을 선택한 경우에도 발생할 수 있습니다. 시스템 스냅샷이 비활성화되었지만 `RESTORE_FROM_LATEST_SNAPSHOT`을 이미 구성한 애플리케이션을 예로 들 수 있습니다. 일반적으로 Amazon S3 StreamingFileSink를 사용하는 Managed Service for Apache Flink에서는 항상 시스템 스냅샷을 활성화하고 `RESTORE_FROM_LATEST_SNAPSHOT`을 구성해야 합니다. + 진행 중인 부분 파일 제거 – 진행 중인 부분 파일은 S3 버킷에 있으므로 해당 버킷에 액세스할 수 있는 다른 구성 요소나 행위자에 의해 제거될 수 있습니다. + 이는 앱을 너무 오랫동안 중지하고 앱의 저장점에서 참조하는 진행 중인 부분 파일이 [S3 버킷 MultiPartupload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html) 라이프사이클 정책에 의해 제거된 경우 발생할 수 있습니다. 이러한 장애 클래스를 방지하려면 S3 Bucket MPU 라이프사이클 정책이 사용 사례에 비해 충분히 긴 기간 동안 적용되는지 확인하십시오. + 이는 진행 중인 부분 파일을 수동으로 제거하거나 시스템의 다른 구성 요소에 의해 제거된 경우에도 발생할 수 있습니다. 이러한 오류 클래스를 방지하려면 진행 중인 부분 파일이 다른 행위자나 구성 요소에 의해 제거되지 않도록 하십시오. + 저장점 이후 자동 체크포인트가 트리거되는 경쟁 조건 – 이는 Managed Service for Apache Flink 버전(최대 1.13 포함)에 영향을 미칩니다. 이 문제는 Managed Service for Apache Flink 버전 1.15에서 수정되었습니다. 재발을 방지하려면 애플리케이션을 최신 버전의 Managed Service for Apache Flink로 마이그레이션하세요. 또한 StreamingFileSink에서 [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink)로 마이그레이션하는 것이 좋습니다. + 애플리케이션이 중지되거나 업데이트되면 Managed Service for Apache Flink는 저장점을 트리거하고 두 단계에 걸쳐 애플리케이션을 중지합니다. 두 단계 사이에 자동 체크포인트가 트리거되면 진행 중인 부분 파일의 명칭이 바뀌고 잠재적으로 구속될 수 있으므로 저장점을 사용할 수 없게 됩니다. # 저장점 사용 중지 관련 FlinkKafkaConsumer 문제 레거시 FlinkKafkaConsumer를 사용할 때 시스템 스냅샷을 활성화한 경우 애플리케이션이 업데이트, 중지 또는 조정에서 멈출 수 있습니다. 이 [문제](https://issues.apache.org/jira/browse/FLINK-28758)에 대한 수정은 게시되지 않았으므로 이 문제를 완화하려면 새 [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source)로 업그레이드하는 것이 좋습니다. 스냅샷이 활성화된 상태로 `FlinkKafkaConsumer`를 사용하는 경우 Flink 작업에서 저장점 API로 중지 요청을 처리할 때 `ClosedException`를 보고하는 런타임 오류가 발생하여 `FlinkKafkaConsumer`이 실패할 수 있습니다. 이러한 상황에서는 Flink 애플리케이션이 중단되고 실패한 체크포인트로 나타납니다. # Flink 1.15 Async Sink 교착 상태 AsyncSink 인터페이스를 구현하는 Apache Flink용 AWS 커넥터에는 [알려진 문제가](https://issues.apache.org/jira/browse/FLINK-32230) 있습니다. 이는 다음 커넥터와 함께 Flink 1.15를 사용하는 애플리케이션에 영향을 줍니다. + Java 애플리케이션의 경우: + KinesisStreamsSink – `org.apache.flink:flink-connector-kinesis` + KinesisStreamsSink – `org.apache.flink:flink-connector-aws-kinesis-streams` + KinesisFirehoseSink – `org.apache.flink:flink-connector-aws-kinesis-firehose` + DynamoDbSink – `org.apache.flink:flink-connector-dynamodb` + Flink SQL/TableAPI/Python 애플리케이션: + kinesis – `org.apache.flink:flink-sql-connector-kinesis` + kinesis – `org.apache.flink:flink-sql-connector-aws-kinesis-streams` + firehose – `org.apache.flink:flink-sql-connector-aws-kinesis-firehose` + dynamodb – `org.apache.flink:flink-sql-connector-dynamodb` 영향을 받는 애플리케이션에서는 다음과 같은 증상이 나타납니다. + Flink 작업이 `RUNNING` 상태이지만 데이터를 처리하지 못하고 있다; + 작업이 다시 시작되지 않는다; + 체크포인트 시간이 초과되었다. 이 문제는 AWS SDK의 [버그](https://github.com/aws/aws-sdk-java-v2/issues/4354)로 인해 비동기 HTTP 클라이언트를 사용할 때 호출자에게 특정 오류가 표시되지 않습니다. 이로 인해 싱크는 체크포인트 플러시 작업 중에 “진행 중인 요청”이 완료될 때까지 무기한 대기하게 됩니다. 이 문제는 버전 **2.20.144**부터 AWS SDK에서 수정되었습니다. 다음은 애플리케이션에서 새 버전의 AWS SDK를 사용하도록 영향을 받는 커넥터를 업데이트하는 방법에 대한 지침입니다. **Topics** + [Java 애플리케이션 업데이트](troubleshooting-async-deadlock-update-java-apps.md) + [Python 애플리케이션 업데이트](troubleshooting-async-deadlock-update-python-apps.md) # Java 애플리케이션 업데이트 아래 절차에 따라 Java 애플리케이션을 업데이트하십시오. ## flink-connector-kinesis 애플리케이션은 `flink-connector-kinesis`을 사용하는 경우: Kinesis 커넥터는 셰이딩을 사용하여 AWS SDK를 비롯한 일부 종속성을 커넥터 jar에 패키징합니다. AWS SDK 버전을 업데이트하려면 다음 절차에 따라 이러한 셰이딩된 클래스를 바꿉니다. ------ #### [ Maven ] 1. Kinesis 커넥터와 필수 AWS SDK 모듈을 프로젝트 종속성으로 추가합니다. 1. 구성 `maven-shade-plugin`: 1. Kinesis 커넥터 jar의 콘텐츠를 복사할 때 음영 처리된 AWS SDK 클래스를 제외하도록 필터를 추가합니다. 1. 재배치 규칙을 추가하여 업데이트된 AWS SDK 클래스를 Kinesis 커넥터에서 예상되는 패키지로 이동합니다. **pom.xml** ``` ... ... org.apache.flink flink-connector-kinesis 1.15.4 software.amazon.awssdk kinesis 2.20.144 software.amazon.awssdk netty-nio-client 2.20.144 software.amazon.awssdk sts 2.20.144 ... ... ... ... org.apache.maven.plugins maven-shade-plugin 3.1.1 package shade ... ... org.apache.flink:flink-connector-kinesis org/apache/flink/kinesis/shaded/software/amazon/awssdk/** org/apache/flink/kinesis/shaded/org/reactivestreams/** org/apache/flink/kinesis/shaded/io/netty/** org/apache/flink/kinesis/shaded/com/typesafe/netty/** ... ... software.amazon.awssdk org.apache.flink.kinesis.shaded.software.amazon.awssdk org.reactivestreams org.apache.flink.kinesis.shaded.org.reactivestreams io.netty org.apache.flink.kinesis.shaded.io.netty com.typesafe.netty org.apache.flink.kinesis.shaded.com.typesafe.netty ... ... ... ... ``` ------ #### [ Gradle ] 1. Kinesis 커넥터와 필수 AWS SDK 모듈을 프로젝트 종속성으로 추가합니다. 1. ShadowJar 구성 조정: 1. Kinesis 커넥터 jar의 콘텐츠를 복사할 때 음영 처리된 AWS SDK 클래스를 제외합니다. 1. 업데이트된 AWS SDK 클래스를 Kinesis 커넥터에서 예상되는 패키지로 재배치합니다. **build.gradle** ``` ... dependencies { ... flinkShadowJar("org.apache.flink:flink-connector-kinesis:1.15.4") flinkShadowJar("software.amazon.awssdk:kinesis:2.20.144") flinkShadowJar("software.amazon.awssdk:sts:2.20.144") flinkShadowJar("software.amazon.awssdk:netty-nio-client:2.20.144") ... } ... shadowJar { configurations = [project.configurations.flinkShadowJar] exclude("software/amazon/kinesis/shaded/software/amazon/awssdk/**/*") exclude("org/apache/flink/kinesis/shaded/org/reactivestreams/**/*.class") exclude("org/apache/flink/kinesis/shaded/io/netty/**/*.class") exclude("org/apache/flink/kinesis/shaded/com/typesafe/netty/**/*.class") relocate("software.amazon.awssdk", "org.apache.flink.kinesis.shaded.software.amazon.awssdk") relocate("org.reactivestreams", "org.apache.flink.kinesis.shaded.org.reactivestreams") relocate("io.netty", "org.apache.flink.kinesis.shaded.io.netty") relocate("com.typesafe.netty", "org.apache.flink.kinesis.shaded.com.typesafe.netty") } ... ``` ------ ## 영향을 받는 기타 커넥터 애플리케이션이 영향을 받는 다른 커넥터를 사용하는 경우. AWS SDK 버전을 업데이트하려면 프로젝트 빌드 구성에서 SDK 버전을 적용해야 합니다. ------ #### [ Maven ] `pom.xml` 파일의 종속성 관리 섹션에 AWS SDK BOM(Bill of Material)을 추가하여 프로젝트에 SDK 버전을 적용합니다. **pom.xml** ``` ... ... software.amazon.awssdk bom 2.20.144 import pom ... ... ``` ------ #### [ Gradle ] AWS SDK 재료표(BOM)에 플랫폼 종속성을 추가하여 프로젝트에 SDK 버전을 적용합니다. 이를 위해서는 Gradle 5.0 이상이 필요합니다. **build.gradle** ``` ... dependencies { ... flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144")) ... } ... ``` ------ # Python 애플리케이션 업데이트 Python 애플리케이션은 커넥터를 두 가지 방식으로 사용할 수 있습니다. 커넥터 및 기타 Java 종속성을 단일 uber-jar의 일부로 패키징하거나 커넥터 jar를 직접 사용하는 것입니다. Async Sink 교착 상태의 영향을 받는 애플리케이션을 수정하려면, + 애플리케이션이 uber jar를 사용하는 경우 [Java 애플리케이션 업데이트](troubleshooting-async-deadlock-update-java-apps.md)의 지침을 따르세요. + 소스에서 커넥터 jar를 다시 빌드하려면 다음 단계를 사용하십시오. **소스에서 커넥터 만들기:** Flink [빌드 요건](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/flinkdev/building/#build-flink)과 유사한 사전 요건: + Java 11 + Maven 3.2.5 ## flink-sql-connector-kinesis 1. Flink 1.15.4의 소스 코드 다운로드: ``` wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz ``` 1. 소스 코드 압축 해제: ``` tar -xvf flink-1.15.4-src.tgz ``` 1. kinesis 커넥터 디렉터리로 이동합니다. ``` cd flink-1.15.4/flink-connectors/flink-connector-kinesis/ ``` 1. 필요한 AWS SDK 버전을 지정하여 커넥터 jar을 컴파일하고 설치합니다. 빌드 속도를 높이려면 테스트 실행을 건너뛰는 `-DskipTests` 방법과 추가 소스 코드 검사를 건너뛰는 `-Dfast` 방법을 사용하십시오. ``` mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144 ``` 1. kinesis 커넥터 디렉터리로 이동합니다. ``` cd ../flink-sql-connector-kinesis ``` 1. sql 커넥터 jar 컴파일 및 설치: ``` mvn clean install -DskipTests -Dfast ``` 1. 결과 jar는 다음에서 확인할 수 있습니다. ``` target/flink-sql-connector-kinesis-1.15.4.jar ``` ## flink-sql-connector-aws-kinesis-streams 1. Flink 1.15.4의 소스 코드 다운로드: ``` wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz ``` 1. 소스 코드 압축 해제: ``` tar -xvf flink-1.15.4-src.tgz ``` 1. kinesis 커넥터 디렉터리로 이동합니다. ``` cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/ ``` 1. 필요한 AWS SDK 버전을 지정하여 커넥터 jar을 컴파일하고 설치합니다. 빌드 속도를 높이려면 테스트 실행을 건너뛰는 `-DskipTests` 방법과 추가 소스 코드 검사를 건너뛰는 `-Dfast` 방법을 사용하십시오. ``` mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144 ``` 1. kinesis 커넥터 디렉터리로 이동합니다. ``` cd ../flink-sql-connector-aws-kinesis-streams ``` 1. sql 커넥터 jar 컴파일 및 설치: ``` mvn clean install -DskipTests -Dfast ``` 1. 결과 jar는 다음에서 확인할 수 있습니다. ``` target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar ``` ## flink-sql-connector-aws-kinesis-firehose 1. Flink 1.15.4의 소스 코드 다운로드: ``` wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz ``` 1. 소스 코드 압축 해제: ``` tar -xvf flink-1.15.4-src.tgz ``` 1. 커넥터 디렉토리로 이동합니다. ``` cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/ ``` 1. 필요한 AWS SDK 버전을 지정하여 커넥터 jar을 컴파일하고 설치합니다. 빌드 속도를 높이려면 테스트 실행을 건너뛰는 `-DskipTests` 방법과 추가 소스 코드 검사를 건너뛰는 `-Dfast` 방법을 사용하십시오. ``` mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144 ``` 1. sql 커넥터 디렉터리로 이동합니다. ``` cd ../flink-sql-connector-aws-kinesis-firehose ``` 1. sql 커넥터 jar 컴파일 및 설치: ``` mvn clean install -DskipTests -Dfast ``` 1. 결과 jar는 다음에서 확인할 수 있습니다. ``` target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar ``` ## flink-sql-connector-dynamodb 1. Flink 1.15.4의 소스 코드 다운로드: ``` wget https://archive.apache.org/dist/flink/flink-connector-aws-3.0.0/flink-connector-aws-3.0.0-src.tgz ``` 1. 소스 코드 압축 해제: ``` tar -xvf flink-connector-aws-3.0.0-src.tgz ``` 1. 커넥터 디렉토리로 이동합니다. ``` cd flink-connector-aws-3.0.0 ``` 1. 필요한 AWS SDK 버전을 지정하여 커넥터 jar을 컴파일하고 설치합니다. 빌드 속도를 높이려면 테스트 실행을 건너뛰는 `-DskipTests` 방법과 추가 소스 코드 검사를 건너뛰는 `-Dfast` 방법을 사용하십시오. ``` mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144 ``` 1. 결과 jar는 다음에서 확인할 수 있습니다. ``` flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar ``` # 리샤딩 중 Amazon Kinesis Data Streams 소스 처리 순서가 잘못됨 현재 FlinkKinesisConsumer 구현은 Kinesis 샤드 간의 강력한 주문 보장을 제공하지 않습니다. 이로 인해 Kinesis Stream을 리샤딩하는 동안 처리 순서가 잘못될 수 있으며, 특히 처리 지연이 발생하는 Flink 애플리케이션의 경우 더욱 그렇습니다. 이벤트 시간을 기반으로 하는 Windows 연산자와 같은 일부 상황에서는 결과적으로 지연이 발생하여 이벤트가 삭제될 수 있습니다. ![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/flink-ts.png) 이는 오픈 소스 Flink의 [알려진 문제](https://issues.apache.org/jira/browse/FLINK-6349)입니다. 커넥터 수정 사항이 제공될 때까지 다시 파티셔닝하는 동안 Flink 애플리케이션이 Kinesis Data Streams에 뒤쳐지지 않도록 합니다. Flink 앱에서 처리 지연을 허용하도록 하여 잘못된 처리 순서로 인한 영향과 데이터 손실 위험을 최소화할 수 있습니다. # 실시간 벡터 임베딩 블루프린트 FAQ 및 문제 해결 실시간 벡터 임베딩 블루프린트 문제를 해결하려면 다음 FAQ 및 문제 해결 섹션을 검토하세요. 실시간 벡터 임베딩 블루프린트에 관한 자세한 내용은 [실시간 벡터 임베딩 블루프린트](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)를 참조하세요. Managed Service for Apache Flink 애플리케이션의 일반적인 문제 해결 방법은 [https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html) 페이지를 참조하세요. **Topics** + [실시간 벡터 임베딩 블루프린트 - FAQ](troubleshooting-blueprints-FAQ.md) + [실시간 벡터 임베딩 블루프린트 - 문제 해결](troubleshooting-blueprints-TS.md) # 실시간 벡터 임베딩 블루프린트 - FAQ 실시간 벡터 임베딩 블루프린트에 관한 FAQ를 검토하세요. 실시간 벡터 임베딩 블루프린트에 관한 자세한 내용은 [실시간 벡터 임베딩 블루프린트](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)를 참조하세요. **Topics** + [이 블루프린트는 어떤 AWS 리소스를 생성하나요?](#troubleshooting-blueprints-1) + [AWS CloudFormation 스택 배포가 완료된 후 내 작업은 무엇입니까?](#troubleshooting-blueprints-2) + [소스 Amazon MSK 주제의 데이터는 어떤 구조로 구성되어 있어야 하나요?](#troubleshooting-blueprints-3) + [메시지의 일부만 임베딩하도록 지정할 수 있나요?](#troubleshooting-blueprints-4) + [여러 Amazon MSK 주제에서 데이터를 읽을 수 있나요?](#troubleshooting-blueprints-5) + [Amazon MSK 주제 이름을 정규식으로 구성할 수 있나요?](#troubleshooting-blueprints-6) + [Amazon MSK 주제에서 읽을 수 있는 메시지의 최대 크기는 얼마인가요?](#troubleshooting-blueprints-7) + [어떤 유형의 OpenSearch가 지원되나요?](#troubleshooting-blueprints-8) + [OpenSearch Serverless 컬렉션에서 벡터 검색 컬렉션, 벡터 인덱스, 벡터 필드를 사용해야 하는 이유는 무엇인가요?](#troubleshooting-blueprints-9) + [벡터 필드의 차원으로 무엇을 설정해야 하나요?](#troubleshooting-blueprints-10) + [구성된 OpenSearch 인덱스에서 출력은 어떻게 보이나요?](#troubleshooting-blueprints-11) + [OpenSearch 인덱스에 저장되는 문서에 추가할 메타데이터 필드를 지정할 수 있나요?](#troubleshooting-blueprints-12) + [OpenSearch 인덱스에서 중복 항목이 발생할 수 있나요?](#troubleshooting-blueprints-13) + [여러 OpenSearch 인덱스로 데이터를 전송할 수 있나요?](#troubleshooting-blueprints-14) + [하나의 AWS 계정계정에 여러 실시간 벡터 임베딩 애플리케이션을 배포할 수 있나요?](#troubleshooting-blueprints-15) + [여러 실시간 벡터 임베딩 애플리케이션이 동일한 데이터 소스 또는 싱크를 사용할 수 있나요?](#troubleshooting-blueprints-16) + [애플리케이션이 교차 계정 연결을 지원하나요?](#troubleshooting-blueprints-17) + [애플리케이션이 교차 리전 연결을 지원하나요?](#troubleshooting-blueprints-18) + [Amazon MSK 클러스터와 OpenSearch 컬렉션이 서로 다른 VPC 또는 서브넷에 있을 수 있나요?](#troubleshooting-blueprints-19) + [애플리케이션에서 지원하는 임베딩 모델은 무엇인가요?](#troubleshooting-blueprints-20) + [워크로드에 따라 애플리케이션의 성능을 미세 조정할 수 있나요?](#troubleshooting-blueprints-21) + [어떤 Amazon MSK 인증 유형이 지원되나요?](#troubleshooting-blueprints-22) + [`sink.os.bulkFlushIntervalMillis`란 무엇이며 어떻게 설정하나요?](#troubleshooting-blueprints-23) + [Managed Service for Apache Flink 애플리케이션을 배포할 때 Amazon MSK 주제의 어느 지점부터 메시지 읽기를 시작하나요?](#troubleshooting-blueprints-24) + [`source.msk.starting.offset`을 어떻게 사용하나요?](#troubleshooting-blueprints-25) + [지원되는 청킹 전략은 무엇인가요?](#troubleshooting-blueprints-26) + [벡터 데이터 저장소에서 레코드를 어떻게 읽나요?](#troubleshooting-blueprints-27) + [소스 코드에 대한 새로운 업데이트는 어디에서 찾을 수 있나요?](#troubleshooting-blueprints-28) + [AWS CloudFormation 템플릿을 변경하고 Managed Service for Apache Flink 애플리케이션을 업데이트할 수 있나요?](#troubleshooting-blueprints-29) + [에서 사용자를 대신하여 애플리케이션을 AWS 모니터링하고 유지 관리하나요?](#troubleshooting-blueprints-30) + [이 애플리케이션이 데이터를 AWS 계정외부로 이동하나요?](#troubleshooting-blueprints-31) ## 이 블루프린트는 어떤 AWS 리소스를 생성하나요? 계정에 배포된 리소스를 찾으려면 AWS CloudFormation 콘솔로 이동하여 Managed Service for Apache Flink 애플리케이션에 제공한 이름으로 시작하는 스택 이름을 식별합니다. **리소스** 탭을 선택하여 스택의 일부로 생성된 리소스를 확인합니다. 스택이 생성하는 주요 리소스는 다음과 같습니다. + 실시간 벡터 임베딩 Managed Service for Apache Flink 애플리케이션 + 실시간 벡터 임베딩 애플리케이션의 소스 코드를 저장하는 Amazon S3 버킷 + 로그를 저장하는 CloudWatch 로그 그룹 및 로그 스트림 + 리소스를 조회하고 생성하는 Lambda 함수 + Lambda, Managed Service for Apache Flink 애플리케이션, Amazon Bedrock, Amazon OpenSearch Service에 액세스하기 위한 IAM 역할 및 정책 + Amazon OpenSearch Service 데이터 액세스 정책 + Amazon Bedrock 및 Amazon OpenSearch Service에 액세스하기 위한 VPC 엔드포인트 ## AWS CloudFormation 스택 배포가 완료된 후 내 작업은 무엇입니까? AWS CloudFormation 스택 배포가 완료되면 Managed Service for Apache Flink 콘솔에 액세스하여 블루프린트 Managed Service for Apache Flink 애플리케이션을 찾습니다. **구성** 탭에서 모든 런타임 속성이 올바르게 설정되어 있는지 확인합니다. 속성이 많으면 다음 페이지로 이어질 수 있습니다. 설정이 정확하다는 확신이 들면 **실행**을 선택합니다. 애플리케이션은 주제에서 메시지를 수집하기 시작합니다. 새 릴리스를 확인하려면 [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases) 페이지를 참조하세요. ## 소스 Amazon MSK 주제의 데이터는 어떤 구조로 구성되어 있어야 하나요? 현재 정형 및 비정형 소스 데이터를 모두 지원합니다. + 비정형 데이터는 `STRING`에서 `source.msk.data.type`으로 표시됩니다. 데이터는 들어오는 메시지 값을 그대로 읽습니다. + 조화된 JSON 데이터도 지원하며, 이는 `source.msk.data.type`에서 `JSON`으로 지정됩니다. 데이터는 반드시 JSON 형식이어야 합니다. 애플리케이션은 잘못된 형식의 JSON을 수신하면 실패합니다. + JSON을 소스 데이터 유형으로 사용할 경우 모든 소스 주제의 메시지가 유효한 JSON인지 반드시 확인해야 합니다. 이 설정에서 JSON 객체가 아닌 데이터를 포함한 주제를 구독하면 애플리케이션은 실패합니다. 한 이상의 주제에 정형 데이터와 비정형 데이터가 혼합된 경우 Managed Service for Apache Flink 애플리케이션에서 소스 데이터를 비정형 데이터로 구성하는 것이 좋습니다. ## 메시지의 일부만 임베딩하도록 지정할 수 있나요? + `source.msk.data.type`이 `STRING`인 비정형 입력 데이터의 경우 애플리케이션은 메시지 전체를 임베딩하며 구성된 OpenSearch 인덱스에 전체 메시지를 저장합니다. + `source.msk.data.type`이 `JSON`인 정형 입력 데이터의 경우, `embed.input.config.json.fieldsToEmbed` 값을 설정해 JSON 객체에서 임베딩할 필드를 지정할 수 있습니다. 이 설정은 최상위 JSON 필드만 지원하며 중첩 JSON이나 JSON 배열이 포함된 메시지에는 사용할 수 없습니다. 전체 JSON을 임베딩하려면 .\$1를 사용하세요. ## 여러 Amazon MSK 주제에서 데이터를 읽을 수 있나요? 네, 이 애플리케이션은 여러 Amazon MSK 주제에서 데이터를 읽을 수 있습니다. 모든 주제의 데이터는 동일한 유형(STRING 또는 JSON)이어야 하며, 그렇지 않으면 애플리케이션이 실패할 수 있습니다. 모든 주제에서 읽은 데이터는 항상 하나의 OpenSearch 인덱스에 저장됩니다. ## Amazon MSK 주제 이름을 정규식으로 구성할 수 있나요? `source.msk.topic.names`는 정규식 목록을 지원하지 않습니다. 쉼표로 구분된 주제 이름 목록 또는 모든 주제를 포함하기 위한 `.*` 정규식을 지원합니다. ## Amazon MSK 주제에서 읽을 수 있는 메시지의 최대 크기는 얼마인가요? 처리할 수 있는 메시지의 최대 크기는 현재 25,000,000으로 설정된 Amazon Bedrock InvokeModel 본문 제한에 의해 결정됩니다. 자세한 내용은 [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody)을 참조하세요. ## 어떤 유형의 OpenSearch가 지원되나요? OpenSearch 도메인과 컬렉션을 모두 지원합니다. OpenSearch 컬렉션을 사용하는 경우 이 애플리케이션에서 사용하기 위해 벡터 컬렉션을 사용하고 벡터 인덱스를 생성해야 합니다. 이렇게 하면 데이터를 쿼리하기 위해 OpenSearch 벡터 데이터베이스 기능을 사용할 수 있습니다. 자세한 내용은 [Amazon OpenSearch Service의 벡터 데이터 베이스 기능 설명](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/)을 참조하세요. ## OpenSearch Serverless 컬렉션에서 벡터 검색 컬렉션, 벡터 인덱스, 벡터 필드를 사용해야 하는 이유는 무엇인가요? OpenSearch Serverless의 *벡터 검색* 컬렉션 유형은 확장 가능하고 성능이 우수한 유사성 검색 기능을 제공합니다. 이는 최신 기계 학습(ML) 기반 증강 검색 환경과 생성형 인공 지능(AI) 애플리케이션을 구축하는 과정을 간소화합니다. 자세한 내용은 [벡터 검색 컬렉션 작업](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped)을 참조하세요. ## 벡터 필드의 차원으로 무엇을 설정해야 하나요? 벡터 필드의 차원은 사용할 임베딩 모델에 따라 설정합니다. 다음 표를 참조하고 해당 설명서에서 이러한 값을 확인합니다. **벡터 필드 차원** | Amazon Bedrock 벡터 임베딩 모델 이름 | 모델이 제공하는 출력 차원 지원 | | --- | --- | | Amazon Titan Text Embeddings V1 | 1,536 | | Amazon Titan Text Embeddings V2 | 1,024(기본값), 384, 256 | | Amazon Titan Multimodal Embeddings G1 | 1,024(기본값), 384, 256 | | Cohere Embed English | 1,024 | | Cohere Embed Multilingual | 1,024 | ## 구성된 OpenSearch 인덱스에서 출력은 어떻게 보이나요? OpenSearch 인덱스의 모든 문서에는 다음 필드가 포함됩니다. + **original\$1data**: 임베딩을 생성하는 데 사용된 데이터입니다. STRING 유형의 경우 전체 메시지입니다. JSON 객체의 경우 임베딩에 사용된 JSON 객체입니다. 이는 메시지의 전체 JSON이 될 수도 있고 JSON 내 지정된 필드가 될 수도 있습니다. 예를 들어, 들어오는 메시지에서 이름 필드가 임베딩 대상으로 선택된 경우 출력은 다음과 같습니다. ``` "original_data": "{\"name\":\"John Doe\"}" ``` + **embedded\$1data**: Amazon Bedrock에서 생성한 임베딩의 벡터 부동 배열입니다. + **날짜**: 문서가 OpenSearch에 저장된 시점의 UTC 타임스탬프입니다. ## OpenSearch 인덱스에 저장되는 문서에 추가할 메타데이터 필드를 지정할 수 있나요? 아니요. 현재 OpenSearch 인덱스에 저장되는 최종 문서에 추가 필드를 포함하는 기능은 지원하지 않습니다. ## OpenSearch 인덱스에서 중복 항목이 발생할 수 있나요? 애플리케이션 구성 방식에 따라 인덱스에 중복 메시지가 나타날 수 있습니다. 일반적인 원인은 애플리케이션 재시작입니다. 애플리케이션은 기본적으로 소스 주제의 가장 이른 메시지부터 읽도록 구성되어 있습니다. 구성을 변경하면 애플리케이션이 재시작되며 주제의 모든 메시지를 다시 처리합니다. 재처리를 방지하려면 source.msk.starting.offset 사용 방법에 대한 설명서를 참조하고 애플리케이션의 시작 오프셋을 올바르게 설정합니다. ## 여러 OpenSearch 인덱스로 데이터를 전송할 수 있나요? 아니요. 애플리케이션은 하나의 OpenSearch 인덱스에만 데이터를 저장하는 것을 지원합니다. 여러 인덱스에 벡터화 출력을 구성하려면 별도의 Managed Service for Apache Flink 애플리케이션을 배포해야 합니다. ## 하나의 AWS 계정계정에 여러 실시간 벡터 임베딩 애플리케이션을 배포할 수 있나요? 예. 각 애플리케이션에 고유한 이름이 있는 경우 하나의 AWS 계정 에 여러 실시간 벡터 임베딩 Managed Service for Apache Flink 애플리케이션을 배포할 수 있습니다. ## 여러 실시간 벡터 임베딩 애플리케이션이 동일한 데이터 소스 또는 싱크를 사용할 수 있나요? 예. 동일한 주제에서 데이터를 읽거나 동일한 인덱스에 데이터를 저장하는 여러 실시간 벡터 임베딩 Managed Service for Apache Flink 애플리케이션을 생성할 수 있습니다. ## 애플리케이션이 교차 계정 연결을 지원하나요? 아니요. 애플리케이션이 성공적으로 실행되려면 Amazon MSK 클러스터와 OpenSearch 컬렉션이 Managed Service for Apache Flink 애플리케이션을 설정하려는 AWS 계정 동일한에 있어야 합니다. ## 애플리케이션이 교차 리전 연결을 지원하나요? 아니요. 애플리케이션은 Amazon MSK 클러스터와 OpenSearch 컬렉션이 Managed Service for Apache Flink 애플리케이션과 동일한 리전에 있는 경우에만 Managed Service for Apache Flink 애플리케이션을 배포할 수 있습니다. ## Amazon MSK 클러스터와 OpenSearch 컬렉션이 서로 다른 VPC 또는 서브넷에 있을 수 있나요? 예. 동일한 AWS 계정에 있는 경우 Amazon MSK 클러스터와 OpenSearch 컬렉션이 서로 다른 VPC 및 서브넷에 있어도 지원합니다. 설정이 올바른지 확인하려면 (일반적인 MSF 문제 해결)을 참조하세요. ## 애플리케이션에서 지원하는 임베딩 모델은 무엇인가요? 현재 해당 애플리케이션은 Bedrock에서 지원하는 모든 모델을 지원합니다. 다음이 포함됩니다. + Amazon Titan Embeddings G1 - Text + Amazon Titan Text Embeddings V2 + Amazon Titan Multimodal Embeddings G1 + Cohere Embed English + Cohere Embed Multilingual ## 워크로드에 따라 애플리케이션의 성능을 미세 조정할 수 있나요? 예. 애플리케이션의 처리량은 여러 요소에 따라 달라지며, 이 모든 요소는 고객이 제어할 수 있습니다. 1. **AWS MSF KPUs** 애플리케이션은 기본 병렬 처리 인자 2와 KPU 1당 병렬 처리로 배포되며 자동 조정이 켜져 있습니다. 그러나 워크로드에 따라 Managed Service for Apache Flink 애플리케이션의 조정을 구성할 것을 권장합니다. 자세한 내용은 [Managed Service for Apache Flink 애플리케이션 리소스 검토](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html)를 참조하세요. 1. **Amazon Bedrock**: 선택한 Amazon Bedrock 온디맨드 모델에 따라 적용되는 할당량이 다를 수 있습니다. 서비스가 처리할 수 있는 워크로드를 확인하려면 Bedrock 서비스 할당량을 검토합니다. 자세한 내용은 [Amazon Bedrock 할당량](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html)을 참조하세요. 1. **Amazon OpenSearch Service**: 경우에 따라 OpenSearch가 파이프라인의 병목 지점이 될 수 있습니다. 크기 조정 정보는 OpenSearch 크기 조정 [Amazon OpenSearch Service 도메인 크기 조절](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html)을 참조하세요. ## 어떤 Amazon MSK 인증 유형이 지원되나요? IAM MSK 인증 유형만 지원합니다. ## `sink.os.bulkFlushIntervalMillis`란 무엇이며 어떻게 설정하나요? Amazon OpenSearch Service로 데이터를 전송할 때 벌크 플러시 간격은 요청 내 작업 수나 요청 크기와 관계없이 벌크 요청이 실행되는 간격입니다. 기본값은 1밀리초입니다. 플러시 간격을 설정하면 데이터가 적시에 인덱싱되도록 하는 데 도움이 되지만, 간격이 너무 짧게 설정된 경우 오버헤드가 증가할 수 있습니다. 플러시 간격을 선택할 때 사용 사례와 적시 인덱싱의 중요성을 고려하여 적절한 값을 선택합니다. ## Managed Service for Apache Flink 애플리케이션을 배포할 때 Amazon MSK 주제의 어느 지점부터 메시지 읽기를 시작하나요? 애플리케이션은 애플리케이션의 런타임 구성에서 설정된 `source.msk.starting.offset` 구성에 지정된 오프셋부터 Amazon MSK 주제의 메시지를 읽기 시작합니다. `source.msk.starting.offset`이 명시적으로 설정되지 않은 경우 애플리케이션은 주제에서 사용 가능한 가장 이른 메시지부터 읽기 시작합니다. ## `source.msk.starting.offset`을 어떻게 사용하나요? 원하는 동작에 따라 `ource.msk.starting.offset`을 다음 값 중 하나로 명시적으로 설정합니다. + EARLIEST: 기본 설정으로, 파티션의 가장 오래된 오프셋부터 읽습니다. 다음과 같은 경우에 적합합니다. + Amazon MSK 주제 및 소비자 애플리케이션을 새로 생성한 경우 + 상태를 빌드하거나 재구성하기 위해 데이터를 재생해야 하는 경우 이는 이벤트 소싱 패턴을 구현하거나 데이터 기록의 전체 보기를 필요로 하는 신규 서비스를 초기화할 때 관련이 있습니다. + LATEST: Managed Service for Apache Flink 애플리케이션이 파티션 끝에서 메시지를 읽습니다. 새로 생성되는 메시지만 필요하고 기존 데이터를 처리할 필요가 없는 경우 권장됩니다. 이 설정에서는 소비자가 기존 메시지를 무시하고 업스트림 프로듀서가 새로 게시하는 메시지만 읽습니다. + COMMITTED: Managed Service for Apache Flink 애플리케이션이 소비 그룹의 커밋된 오프셋부터 메시지 소비를 시작합니다. 커밋된 오프셋이 없는 경우 EARLIEST 재설정 전략이 사용됩니다. ## 지원되는 청킹 전략은 무엇인가요? 입력을 청킹하기 위해 [langchain](https://js.langchain.com/v0.1/docs/get_started/introduction/) 라이브러리를 사용하고 있습니다. 입력 길이가 선택한 `maxSegmentSizeInChars`보다 큰 경우에만 청킹이 적용됩니다. 다음 다섯 가지 청킹 유형을 지원합니다. + `SPLIT_BY_CHARACTER`: 각 청크의 길이가 maxSegmentSizeInChars를 초과하지 않는 범위에서 가능한 많은 문자를 청크에 포함합니다. 공백을 고려하지 않으므로 단어가 잘릴 수 있습니다. + `SPLIT_BY_WORD`: 공백 문자를 기준으로 청킹합니다. 단어가 잘리지 않습니다. + `SPLIT_BY_SENTENCE`: Apache OpenNLP 라이브러리의 영어 문장 모델을 사용하여 문장 경계를 감지합니다. + `SPLIT_BY_LINE`: 줄바꿈 문자를 기준으로 청킹합니다. + `SPLIT_BY_PARAGRAPH`: 연속된 줄바꿈 문자를 기준으로 청킹합니다. 분할 전략은 앞서 제시된 순서에 따라 폴백되며, `SPLIT_BY_PARAGRAPH`와 같은 더 큰 청킹 전략은 `SPLIT_BY_CHARACTER`로 폴백됩니다. 예를 들어 `SPLIT_BY_LINE`을 사용하는 경우 줄이 너무 길면 문장 단위로 다시 청킹되며 각 청크는 가능한 많은 문장을 포함합니다. 문장이 너무 긴 경우 단어 단위로 청킹됩니다. 단어가 너무 긴 경우 문자 단위로 분할됩니다. ## 벡터 데이터 저장소에서 레코드를 어떻게 읽나요? 1. `source.msk.data.type`이 `STRING`인 경우 + **original\$1data**: Amazon MSK 메시지의 전체 원본 문자열입니다. + **embedded\$1data**: `chunk_data`가 비어 있지 않은 경우(청킹 적용됨) 여기에서 생성된 임베딩 벡터이며 청킹이 적용되지 않은 경우 `original_data`에서 생성된 임베딩 벡터입니다. + **chunk\$1data**: 원본 데이터가 청킹된 경우에만 나타납니다. `embedded_data`의 임베딩을 생성하는 데 사용된 원본 메시지의 청크를 포함합니다. 1. `source.msk.data.type`이 `JSON`인 경우 + **original\$1data**: JSON 키 필터링 적용 *후* Amazon MSK 메시지의 전체 원본 JSON입니다. + **embedded\$1data**: `chunk_data`가 비어 있지 않은 경우(청킹 적용됨) 여기에서 생성된 임베딩 벡터이며 청킹이 적용되지 않은 경우 `original_data`에서 생성된 임베딩 벡터입니다. + **chunk\$1key**: 원본 데이터가 청킹된 경우에만 나타납니다. `original_data` 내에 해당 청크가 속한 JSON 키를 포함합니다. 예를 들어, 중첩된 키의 경우 `jsonKey1.nestedJsonKeyA`와 같은 형태가 될 수 있으며, `original_data`의 예시에서는 *metadata*와 같은 키가 될 수 있습니다. + **chunk\$1data**: 원본 데이터가 청킹된 경우에만 나타납니다. `embedded_data`의 임베딩을 생성하는 데 사용된 원본 메시지의 청크를 포함합니다. 네, 이 애플리케이션은 여러 Amazon MSK 주제에서 데이터를 읽을 수 있습니다. 모든 주제의 데이터는 동일한 유형(STRING 또는 JSON)이어야 하며, 그렇지 않으면 애플리케이션이 실패할 수 있습니다. 모든 주제에서 읽은 데이터는 항상 하나의 OpenSearch 인덱스에 저장됩니다. ## 소스 코드에 대한 새로운 업데이트는 어디에서 찾을 수 있나요? 새 릴리스를 확인하려면 [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases) 페이지를 참조하세요. ## AWS CloudFormation 템플릿을 변경하고 Managed Service for Apache Flink 애플리케이션을 업데이트할 수 있나요? 아니요. AWS CloudFormation 템플릿을 변경해도 Managed Service for Apache Flink 애플리케이션은 업데이트되지 않습니다. 의 새로운 변경 사항은 새 스택을 배포해야 AWS CloudFormation 함을 의미합니다. ## 에서 사용자를 대신하여 애플리케이션을 AWS 모니터링하고 유지 관리하나요? 아니요, AWS 는 사용자를 대신하여이 애플리케이션을 모니터링, 확장, 업데이트 또는 패치하지 않습니다. ## 이 애플리케이션이 데이터를 AWS 계정외부로 이동하나요? Managed Service for Apache Flink 애플리케이션에서 읽고 저장한 모든 데이터는 내에서 유지 AWS 계정 되며 계정에서 나가지 않습니다. # 실시간 벡터 임베딩 블루프린트 - 문제 해결 실시간 벡터 임베딩 블루프린트에 대한 다음 문제 해결 주제를 검토합니다. 실시간 벡터 임베딩 블루프린트에 관한 자세한 내용은 [실시간 벡터 임베딩 블루프린트](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)를 참조하세요. **Topics** + [CloudFormation 스택 배포가 실패하거나 롤백되었습니다. 이를 해결하려면 어떻게 해야 하나요?](#troubleshooting-blueprints-deployment) + [애플리케이션이 Amazon MSK 주제의 시작 부분부터 메시지를 읽는 것을 원치 않습니다. 어떻게 해야 합니까?](#troubleshooting-blueprints-beginning) + [Managed Service for Apache Flink 애플리케이션에 문제가 있는지 어떻게 알 수 있으며 디버깅하려면 어떻게 해야 하나요?](#troubleshooting-blueprints-debug) + [Managed Service for Apache Flink 애플리케이션에 대해 모니터링해야 하는 핵심 지표는 무엇인가요?](#troubleshooting-blueprints-metrics) ## CloudFormation 스택 배포가 실패하거나 롤백되었습니다. 이를 해결하려면 어떻게 해야 하나요? + CFN 스택으로 이동하여 스택 실패 원인을 확인합니다. 실패 원인은 권한 누락, AWS 리소스 이름 충돌 등 다양할 수 있습니다. 배포 실패의 근본 원인을 수정합니다. 자세한 내용은 [CloudWatch 문제 해결 안내서](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide)를 참조하세요. + [선택 사항] 하나의 VPC에서는 서비스당 하나의 VPC 엔드포인트만 존재할 수 있습니다. 동일한 VPC에서 Amazon OpenSearch Service 컬렉션으로 데이터를 쓰기 위해 여러 실시간 벡터 임베딩 블루프린트를 배포한 경우 VPC 엔드포인트를 공유하고 있을 수 있습니다. 이러한 엔드포인트는 이미 계정의 해당 VPC에 존재하고 있을 수도 있고, 최초의 실시간 벡터 임베딩 블루프린트 스택이 Amazon Bedrock 및 Amazon OpenSearch Service용 VPC 엔드포인트를 생성하여 계정에 배포된 모든 다른 스택이 이를 사용하고 있을 수도 있습니다. 스택이 실패한 경우 해당 스택이 Amazon Bedrock 및 Amazon OpenSearch Service용 VPC 엔드포인트를 생성했는지 확인하고 계정의 다른 곳에서 사용되지 않는 경우 삭제합니다. VPC 엔드포인트를 삭제하는 단계는 애플리케이션을 안전하게 삭제하는 방법에 대한 설명서를 참조하세요. + 계정의 다른 서비스나 애플리케이션이 해당 VPC 엔드포인트를 사용하고 있을 수 있습니다. 엔드포인트를 삭제하면 다른 서비스에 네트워크 중단이 발생할 수 있습니다. 이러한 엔드포인트를 삭제할 때는 주의해야 합니다. ## 애플리케이션이 Amazon MSK 주제의 시작 부분부터 메시지를 읽는 것을 원치 않습니다. 어떻게 해야 합니까? 원하는 동작에 따라 `source.msk.starting.offset`을 다음 값 중 하나로 명시적으로 설정해야 합니다. + **가장 빠른 오프셋**: 파티션에서 가장 오래된 오프셋입니다. + **최신 오프셋**: 소비자가 파티션의 끝에서 메시지를 읽습니다. + **커밋된 오프셋**: 소비자가 파티션 내에서 마지막으로 처리한 메시지부터 읽습니다. ## Managed Service for Apache Flink 애플리케이션에 문제가 있는지 어떻게 알 수 있으며 디버깅하려면 어떻게 해야 하나요? [Managed Service for Apache Flink troubleshooting guide](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html)를 사용하여 애플리케이션의 Managed Service for Apache Flink 관련 문제를 디버깅합니다. ## Managed Service for Apache Flink 애플리케이션에 대해 모니터링해야 하는 핵심 지표는 무엇인가요? + 일반 Managed Service for Apache Flink 애플리케이션에서 사용할 수 있는 모든 지표는 애플리케이션 모니터링에 도움이 됩니다. 자세한 내용은 [Managed Service for Apache Flink의 지표 및 차원](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html)을 참조하세요. + Amazon Bedrock 지표를 모니터링하려면 [Amazon Bedrock용 Amazon CloudWatch 지표](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics)를 참조하세요. + 임베딩 생성 성능을 모니터링하기 위해 두 가지 새로운 지표를 추가했습니다. CloudWatch의 `EmbeddingGeneration` 작업 이름에서 확인할 수 있습니다. 두 가지 지표는 다음과 같습니다. + **BedrockTitanEmbeddingTokenCount**: Amazon Bedrock으로 전송되는 단일 요청에 포함된 토큰 수입니다. + **BedrockEmbeddingGenerationLatencyMs**: Amazon Bedrock에서 임베딩을 생성하기 위한 응답을 보내고 받는 데 걸린 시간을 밀리초 단위로 보고합니다. + Amazon OpenSearch Service 서버리스 컬렉션의 경우 `IngestionDataRate`, `IngestionDocumentErrors` 등의 지표를 사용할 수 있습니다. 자세한 내용은 [Amazon CloudWatch로 OpenSearch Serverless 모니터링](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html)을 참조하세요. + 프로비저닝된 OpenSearch 지표는 [Amazon CloudWatch로 OpenSearch 클러스터 지표 모니터링](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html)을 참조하세요. # 런타임 문제 해결 이 섹션에는 Managed Service for Apache Flink 애플리케이션의 런타임 문제를 진단하고 수정하는 방법에 대한 정보가 포함되어 있습니다. **Topics** + [문제 해결 도구](#troubleshooting-tools) + [애플리케이션 문제](troubleshooting-symptoms.md) + [애플리케이션 다시 시작 중](troubleshooting-rt-restarts.md) + [처리량이 너무 느림](troubleshooting-rt-throughput.md) + [영구 지속적 성장](troubleshooting-rt-stateleaks.md) + [I/O 바운드 연산자](troubleshooting-io-bound-operators.md) + [Kinesis 데이터 스트림의 업스트림 또는 소스 조절](troubleshooting-source-throttling.md) + [체크포인트](troubleshooting-checkpoints.md) + [체크포인트 시간이 초과되었습니다.](troubleshooting-chk-timeout.md) + [Apache Beam 애플리케이션의 체크포인트 실패](troubleshooting-chk-failure-beam.md) + [역압](troubleshooting-backpressure.md) + [데이터 편중](troubleshooting-data-skew.md) + [상태 편중](troubleshooting-state-skew.md) + [서로 다른 리전의 리소스와 통합](troubleshooting-resources-in-different-regions.md) ## 문제 해결 도구 애플리케이션 문제를 탐지하는 기본 도구는 CloudWatch 경보입니다. CloudWatch 경보를 사용하면 애플리케이션의 오류 또는 병목 상태를 나타내는 CloudWatch 지표에 대한 임계값을 설정할 수 있습니다. CloudWatch 경보에 대한 일반적인 정보는 [Amazon Managed Service for Apache Flink에서 CloudWatch 경보 사용](monitoring-metrics-alarms.md) 섹션을 참조하세요. # 애플리케이션 문제 이 섹션에는 Managed Service for Apache Flink 애플리케이션에서 발생할 수 있는 오류 조건에 대한 솔루션이 포함되어 있습니다. **Topics** + [애플리케이션이 일시적 상태에서 정체](#troubleshooting-rt-stuck) + [스냅샷 생성 실패](#troubleshooting-rt-snapshots) + [VPC에서 리소스에 액세스 불가능](#troubleshooting-rt-vpc) + [Amazon S3 버킷에 작성할 때 데이터의 손실](#troubleshooting-rt-s3) + [애플리케이션이 가동 상태이지만 데이터를 처리하지 않고 있습니다.](#troubleshooting-rt-processing) + [스냅샷, 애플리케이션 업데이트 또는 애플리케이션 중지 오류: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception) + [java.nio.file.NoSuchFileException: /usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf) ## 애플리케이션이 일시적 상태에서 정체 애플리케이션이 일시적 상태 (`STARTING`, `UPDATING``STOPPING`, 또는`AUTOSCALING`)에 정체되어 있는 경우 `Force` 파라미터가 `true`로 설정된 상태에서 [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html) 작업을 사용하여 애플리케이션을 중지할 수 있습니다. `DELETING` 상태에서는 애플리케이션을 강제로 중지할 수 없습니다. 또는 애플리케이션이 `UPDATING` 또는 `AUTOSCALING` 상태인 경우 이전 실행 버전으로 회귀할 수 있습니다. 애플리케이션을 회귀시키면 마지막으로 성공한 스냅샷의 상태 데이터가 로드됩니다. 애플리케이션에 스냅샷이 없는 경우 Managed Service for Apache Flink는 회귀 요청을 거부합니다. 애플리케이션 회귀에 대한 자세한 설명은 [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)을 참조하십시오. **참고** 애플리케이션을 강제로 중지하면 데이터가 손실되거나 중복될 수 있습니다. 애플리케이션 재시작 시 데이터 손실이나 데이터 중복 처리를 방지하려면 애플리케이션의 스냅샷을 자주 생성하는 것이 좋습니다. 애플리케이션이 정체되는 사유에는 다음이 포함됩니다. + **애플리케이션 상태가 너무 큼:** 애플리케이션 상태가 너무 크거나 너무 지속적이면 체크포인트 또는 스냅샷 작업 중에 애플리케이션이 정체될 수 있습니다. 애플리케이션의 지표 `lastCheckpointDuration` 및 `lastCheckpointSize`의 값이 꾸준히 증가하거나 비정상적으로 높은지 확인하십시오. + **애플리케이션 코드가 너무 큼:** 애플리케이션 JAR 파일이 512MB보다 작은지 확인하십시오. 512MB보다 큰 JAR 파일은 지원되지 않습니다. + **애플리케이션 스냅샷 생성 실패:** Managed Service for Apache Flink는 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html) 요청 중에 애플리케이션의 스냅샷을 찍습니다. 그런 다음 이 서비스는 이 스냅샷 상태를 사용하고 업데이트된 애플리케이션 구성을 사용하여 애플리케이션을 복원하여 *정확히 1회에 한하여* 시맨틱의 처리를 제공합니다. 자동 스냅샷 생성이 실패할 경우, 다음의 [스냅샷 생성 실패](#troubleshooting-rt-snapshots)을 참조하십시오. + **스냅샷 실패로부터 복구:** 애플리케이션 업데이트에서 연산자를 제거하거나 변경한 후 스냅샷에서 복구하려고 시도하면 스냅샷에 누락된 연산자에 대한 상태 데이터가 포함되어 있으면 기본적으로 복구가 실패합니다. 또한 이 애플리케이션은 `STOPPED` 또는 `UPDATING` 상태 중 하나로 고정됩니다. [이 동작을 변경하여 복구에 성공하려면 애플리케이션 FlinkRun Configuration의 *AllowNonRestoredState* 파라미터를 `true`으로 변경하십시오.](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html) 이렇게 하면 새 프로그램에 매핑할 수 없는 상태 데이터를 재개 작업에서 건너뛰도록 할 수 있습니다. + **애플리케이션 초기화 시간이 더 오래 걸림:** Managed Service for Apache Flink는 Flink 작업이 시작되기를 기다리는 동안 내부 제한 시간 5분(소프트 설정)을 사용합니다. 이 제한 시간 내에 작업을 시작하지 못하면 다음과 같은 CloudWatch 로그가 표시됩니다. ``` Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s ``` 위와 같은 오류가 발생하면 Flink 작업의 `main` 메서드에 정의된 작업이 5분 이상 걸리고, 이로 인해 Managed Service for Apache Flink 끝에서 Flink 작업 생성 시간이 초과되었음을 의미합니다. Flink **JobManager** 로그와 애플리케이션 코드를 확인하여 `main` 메서드에서 이러한 지연이 예상되는지 확인하는 것이 좋습니다. 그렇지 않은 경우 5분 이내에 완료되도록 문제를 해결하기 위한 조치를 취해야 합니다. [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) 또는 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html) 조치를 사용하여 귀하의 신청 상태를 확인할 수 있습니다. ## 스냅샷 생성 실패 Managed Service for Apache Flink는 다음과 같은 상황에서는 스냅샷을 찍을 수 없습니다: + 애플리케이션이 스냅샷 한도를 초과했습니다. 스냅샷 한도는 1,000입니다. 자세한 내용은 [스냅샷을 사용한 애플리케이션 백업 관리](how-snapshots.md) 단원을 참조하십시오. + 애플리케이션에는 소스 또는 싱크에 액세스할 수 있는 권한이 없습니다. + 애플리케이션 코드가 제대로 작동하지 않습니다. + 애플리케이션에 다른 구성 문제가 발생했습니다. 애플리케이션 업데이트 중에 스냅샷을 찍는 동안 또는 애플리케이션을 중지하는 중에 예외가 발생하는 경우 애플리케이션의 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html)의 `SnapshotsEnabled` 속성을 `false`로 설정하고 요청을 재시도하십시오. 애플리케이션 연산자가 제대로 프로비저닝되지 않은 경우 스냅샷이 실패할 수 있습니다. 연산자 성능 조정에 대한 자세한 설명은 [연산자 스케일링](performance-improving.md#performance-improving-scaling-op)을 참조하십시오. 애플리케이션이 정상 상태로 돌아오면 애플리케이션 `SnapshotsEnabled` 속성을 `true`로 설정하는 것이 좋습니다. ## VPC에서 리소스에 액세스 불가능 애플리케이션이 Amazon VPC에서 실행되는 VPC를 사용하는 경우, 다음을 수행하여 애플리케이션이 해당 리소스에 액세스할 수 있는지 확인하십시오: + CloudWatch 로그에서 다음 오류를 확인하십시오. 이 오류는 귀하의 애플리케이션이 VPC의 리소스에 액세스할 수 없음을 나타냅니다. ``` org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms. ``` 이 오류가 표시되면 경로 표가 올바르게 설정되어 있고 커넥터에 올바른 연결 설정이 있는지 확인하십시오. CloudWatch 로그 설정 및 분석에 대한 자세한 설명은 [Amazon Managed Service for Apache Flink의 로깅 및 모니터링](monitoring-overview.md) 섹션을 참조하십시오. ## Amazon S3 버킷에 작성할 때 데이터의 손실 Apache Flink 버전 1.6.2를 사용하여 Amazon S3 버킷에 출력을 쓸 때 일부 데이터 손실이 발생할 수 있습니다. Amazon S3를 사용하여 직접 출력할 때는 지원되는 최신 버전의 Apache Flink를 사용하는 것이 좋습니다. Apache Flink 1.6.2를 사용하여 Amazon S3 버킷에 쓰려면 Firehose를 사용하는 것이 좋습니다. Managed Service for Apache Flink와 함께 Firehose를 사용하는 방법에 관한 자세한 설명은 [Firehose 싱크](earlier.md#get-started-exercise-fh) 섹션을 참조하세요. ## 애플리케이션이 가동 상태이지만 데이터를 처리하지 않고 있습니다. [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) 또는 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html) 작업을 사용하여 애플리케이션 상태를 확인할 수 있습니다. 애플리케이션이 `RUNNING` 상태에 들어가지만 싱크에 데이터를 쓰지 않는 경우 Amazon CloudWatch 로그 스트림을 애플리케이션에 추가하여 문제를 해결할 수 있습니다. 자세한 설명은 [애플리케이션 CloudWatch 로깅 옵션 작업](cloudwatch-logs.md#adding_cloudwatch) 섹션을 참조하세요. 로그 스트림에는 애플리케이션 문제를 해결하는 데 사용할 수 있는 메시지가 포함됩니다. ## 스냅샷, 애플리케이션 업데이트 또는 애플리케이션 중지 오류: InvalidApplicationConfigurationException 스냅샷 작업 중에 또는 스냅샷을 생성하는 작업 (예: 애플리케이션 업데이트 또는 중지) 중에 다음과 유사한 오류가 발생할 수 있습니다. ``` An error occurred (InvalidApplicationConfigurationException) when calling the UpdateApplication operation: Failed to take snapshot for the application xxxx at this moment. The application is currently experiencing downtime. Please check the application's CloudWatch metrics or CloudWatch logs for any possible errors and retry the request. You can also retry the request after disabling the snapshots in the Managed Service for Apache Flink console or by updating the ApplicationSnapshotConfiguration through the AWS SDK ``` 이 오류는 애플리케이션에서 스냅샷을 생성할 수 없을 때 발생합니다. 스냅샷 작업 또는 스냅샷을 생성하는 작업 중에 이 오류가 발생하는 경우 다음을 수행하십시오. + 애플리케이션의 스냅샷을 비활성화하십시오. Managed Service for Apache Flink 콘솔에서 또는 [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html) 작업의 `SnapshotsEnabledUpdate` 파라미터를 사용하여 이 작업을 수행할 수 있습니다. + 스냅샷을 생성할 수 없는 이유를 조사하세요. 자세한 설명은 [애플리케이션이 일시적 상태에서 정체](#troubleshooting-rt-stuck) 섹션을 참조하세요. + 애플리케이션이 정상 상태로 돌아오면 스냅샷을 다시 활성화하십시오. ## java.nio.file.NoSuchFileException: /usr/local/openjdk-8/lib/security/cacerts SSL 신뢰 저장소의 위치는 이전 배포에서 업데이트되었습니다. `ssl.truststore.location` 파라미터에 대해 다음 값을 대신 사용하세요. ``` /usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts ``` # 애플리케이션 다시 시작 중 사용하시는 애플리케이션이 정상이 아닌 경우 Apache Flink 작업이 계속 실패하고 다시 시작됩니다. 이 섹션에서는 이러한 상태에 대한 증상과 문제 해결 조치들을 설명합니다. ## 증상 이 상태는 다음과 같은 증상이 있을 수 있습니다: + `FullRestarts` 지표가 0이 아님. 이 지표는 측정 단위는 귀하가 애플리케이션을 시작한 이후 해당 애플리케이션의 작업이 다시 시작된 횟수를 나타냅니다. + `Downtime` 지표가 0이 아님. 이 지표는 애플리케이션이 `FAILING` 또는 `RESTARTING` 상태에 있는 밀리초의 수치를 나타냅니다. + 애플리케이션 로그는 `RESTARTING` 또는 `FAILED`로의 상태 변경을 포함합니다. 다음과 같은 CloudWatch Logs Insights 쿼리를 사용하여 애플리케이션 로그에서 이러한 상태 변경을 검색할 수 있습니다. [오류 분석: 애플리케이션 작업 관련 실패](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps). ## 원인 및 해결 방법 다음과 같은 상태 하에서 애플리케이션은 불안정해지고 반복적으로 다시 시작될 수 있습니다. + **연산자가 예외를 발생시키는 경우:** 귀하의 애플리케이션에서 연산자의 예외가 처리되지 않으면 연산자가 오류를 처리할 수 없다고 해석하여 애플리케이션이 페일오버됩니다. “정확히 한 번” 처리하라는 의미를 유지하기 위해 애플리케이션이 최근의 체크포인트에서 다시 시작됩니다. 따라서 이러한 재시작 기간 동안에는 `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 애플리케이션은 다음 버전의 의존성을 사용해야 합니다. ``` 2.10.2 ... com.fasterxml.jackson.module jackson-module-jaxb-annotations 2.10.2 ``` 정확한 버전의 `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/ 에 문의하여 고객의 맞춤 네트워크 버퍼 구성에 대해 문의할 수 있습니다. # 처리량이 너무 느림 애플리케이션이 들어오는 스트리밍 데이터를 충분히 빠르게 처리하지 않으면 성능이 저하되고 불안정해집니다. 이 섹션에서는 이러한 상태에 대한 증상과 문제 해결 조치들을 설명합니다. ## 증상 이 상태는 다음과 같은 증상이 있을 수 있습니다: + 애플리케이션의 데이터 소스가 Kinesis 스트림인 경우 스트림의 `millisbehindLatest` 지표는 계속 증가합니다. + 애플리케이션의 데이터 소스가 Amazon MSK 클러스터인 경우 클러스터의 소비자 지연 지표는 계속 증가합니다. 자세한 설명은 [Amazon MSK 개발자 가이드](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html)의 [소비자 지연 모니터링](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html)을 참조하십시오. + 애플리케이션의 데이터 소스가 다른 서비스 또는 소스인 경우 사용 가능한 소비자 지연 지표 또는 사용 가능한 데이터를 확인하십시오. ## 원인 및 해결 방법 애플리케이션 처리 속도가 느려지는 원인은 여러 가지가 있을 수 있습니다. 애플리케이션이 입력을 따라가지 못하는 경우 다음을 확인하세요: + 처리량 지연이 급증하다가 점점 줄어드는 경우 애플리케이션이 다시 시작되고 있는지 확인하세요. 애플리케이션이 다시 시작되는 동안 입력 처리가 중지되어 지연이 급증합니다. 애플리케이션 보고서에 대한 자세한 설명은 [애플리케이션 다시 시작 중](troubleshooting-rt-restarts.md) 섹션을 참조하세요. + 처리량 지연이 일정하다면 애플리케이션이 성능을 위해 최적화되었는지 확인하세요. 애플리케이션 성능 최적화에 대한 자세한 설명은 [성능 문제 해결](performance-troubleshooting.md)을 참조하십시오. + 처리량 지연이 급증하지 않고 계속 증가하고 있으며 애플리케이션이 성능에 맞게 최적화되어 있다면 애플리케이션 리소스를 늘려야 합니다. 애플리케이션 리소스 증가에 대한 자세한 설명은 [애플리케이션 규모 조정 구현](how-scaling.md)을 참조하십시오. + 애플리케이션이 다른 지역의 Kafka 클러스터에서 읽고, 높은 소비자 지체에도 불구하고 `FlinkKafkaConsumer` 또는 `KafkaSource`가 대부분 유휴 상태(`idleTimeMsPerSecond` 높음 또는 `CPUUtilization` 낮음)인 경우, `receive.buffer.byte`의 값을 높일 수 있습니다(예: 2097152). 자세한 설명은 [맞춤 MSK 구성](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html)에서 높은 잠복 환경 섹션을 참조하십시오. 애플리케이션 소스의 느린 처리량 또는 소비자 지연 증가에 대한 문제 해결 단계는 [성능 문제 해결](performance-troubleshooting.md) 섹션을 참조하십시오. # 영구 지속적 성장 애플리케이션이 이미 지난 정보를 제대로 처리하지 않으면 낡은 정보가 계속 누적되어 애플리케이션 성능이나 안정성 문제가 발생할 수 있습니다. 이 섹션에서는 이러한 상태에 대한 증상과 문제 해결 조치들을 설명합니다. ## 증상 이 상태는 다음과 같은 증상이 있을 수 있습니다: + `lastCheckpointDuration` 지표가 점차 증가하거나 급증함. + `lastCheckpointSize` 지표가 점차 증가하거나 급증함. ## 원인 및 해결 방법 다음과 같은 조건에서는 애플리케이션이 상태 데이터를 축적할 수 있습니다. + 애플리케이션이 상태 데이터를 필요 기간보다 더 오래 보존하고 있음. + 애플리케이션이 윈도우 쿼리를 너무 오랜 시간 동안 사용함. + 상태 데이터에 TTL을 설정하지 않았음. 자세한 내용을 알아보려면 Apache Flink 설명서의 [상태 존속 시간(TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)을 참조하세요. + 귀하는 지금 Apache Beam 버전 2.25.0 이상을 사용하는 애플리케이션을 실행하고 있습니다. 주요 실험 및 값 `use_deprecated_read`로 [BeamApplicationProperties를 확장](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure)함으로써 새 버전의 읽기 변환을 옵트아웃할 수 있습니다. 자세한 내용을 알아보려면 [Apache Beam 설명서](https://beam.apache.org/blog/beam-2.25.0/#highlights)를 참조하세요. 간혹 애플리케이션은 상태 크기가 계속 커지는 상황에 직면하고 있는데, 이는 장기적으로 지속가능하지 않습니다(결국 Flink 애플리케이션은 무한정 실행됩니다). 때로는 데이터를 상태 그대로 저장하고 오래된 정보를 폐기하지 않는 애플리케이션이 원인일 수 있습니다. 하지만 가끔은 Flink가 제공할 수 있는 기능에 대해 지나치게 기대하는 경우가 있습니다. 애플리케이션은 며칠 또는 몇 주에 걸친 긴 단위 시간에 걸쳐 집계를 사용할 수 있습니다. 증분 집계를 허용하는 [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)를 사용하지 않는 한 Flink는 전체 창의 사건들을 상태 내에 유지해야 합니다. 또한 프로세스 함수를 사용하여 맞춤 연산자를 구현하는 경우 애플리케이션은 더 이상 비즈니스 로직에 필요하지 않은 데이터를 상태로부터 제거해야 합니다. 이 경우, [상태 존속 시간](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)을 사용하여 처리 시간에 따라 오래된 데이터를 자동으로 퇴출할 수 있습니다. Managed Service for Apache Flink는 증분 체크포인트를 사용하므로 상태 존속 시간은 [RocksDB 압축](https://github.com/facebook/rocksdb/wiki/Compaction)에 근거합니다. 압축 작업이 수행된 후에야 실제 상태 크기 감소(체크포인트 크기로 표시)를 관찰할 수 있습니다. 특히 체크포인트 크기가 200MB 미만인 경우 상태 만료로 인해 체크포인트 크기가 줄어들 가능성은 거의 없습니다. 하지만 세이브 포인트는 이전 데이터가 포함되지 않은 상태의 깨끗한 사본에 근거하므로 Managed Service for Apache Flink에서 스냅샷을 트리거하여 이미 지난 상태를 강제로 제거할 수 있습니다. 디버깅을 위해서는 증분 체크포인트를 비활성화하여 체크포인트 크기가 실제로 줄어들거나 안정화되는지 더 빨리 확인하고 RockSBS에서 압축으로 인한 영향을 방지하는 것이 좋습니다. 하지만 이를 위해서는 서비스 팀에 대한 티켓이 필요합니다. # I/O 바운드 연산자 데이터 경로에서 외부 시스템에 대한 종속성을 피하는 것이 가장 좋습니다. 개별 이벤트를 보강하기 위해 외부 시스템을 쿼리하는 것보다 참조 데이터 세트를 상태로 유지하는 것이 훨씬 더 효과적인 경우가 많습니다. 그러나 Amazon Sagemaker에서 호스팅되는 기계 학습 모델로 이벤트를 강화하려는 경우처럼의 상태로 쉽게 이동할 수 없는 종속성이 있는 경우가 있습니다. 네트워크를 통해 외부 시스템과 상호 작용하는 연산자는 병목 현상이 발생하여 역압을 유발할 수 있습니다. 개별 호출의 대기 시간을 줄이고 전체 애플리케이션의 속도 저하를 방지하려면 [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/)를 사용하여 기능을 구현하는 것이 좋습니다. 또한 I/O 바운드 연산자가 있는 애플리케이션의 경우 Managed Service for Apache Flink 애플리케이션의 [ParallelismperKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) 설정을 높이는 것도 합리적일 수 있습니다. 이 구성은 애플리케이션이 Kinesis 처리 단위(KPU)에 따라 수행할 수 있는 병렬 하위 작업 수를 설명합니다. 값을 기본값 1에서 4로 늘리면 애플리케이션은 동일한 리소스를 활용하고 비용은 같지만 병렬 처리 수를 4배까지 확장할 수 있습니다. 이는 I/O 바인딩된 애플리케이션에서는 잘 작동하지만 I/O 바인딩되지 않은 애플리케이션에는 추가 오버헤드가 발생합니다. # Kinesis 데이터 스트림의 업스트림 또는 소스 조절 **증상**: 애플리케이션이 업스트림 소스 Kinesis 데이터 스트림에서 `LimitExceededExceptions`을 발견합니다. **잠재적 원인**: Apache Flink 라이브러리 Kinesis 커넥터의 기본 설정이 Kinesis 데이터 스트림 소스에서 읽도록 설정되어 있으며, `GetRecords` 호출당 인출되는 최대 레코드 수에 대해 매우 엄격한 기본 설정이 사용됩니다. 샤드당 레코드 한도는 레코드 1,000개에 불과하지만 Apache Flink는 기본적으로 `GetRecords` 직접 호출당 10,000개의 레코드를 가져오도록 구성되어 있습니다(이 직접 호출은 기본적으로 200ms마다 수행됨). 이 기본 동작으로 인해 Kinesis 데이터 스트림을 사용하려고 할 때 병목 현상이 발생하여 애플리케이션 성능 및 안정성에 영향을 미칠 수 있습니다. CloudWatch `ReadProvisionedThroughputExceeded` 지표를 확인하여 이 지표가 0보다 큰 상태가 장기간 또는 지속적으로 이어지는지 보면 이를 확인할 수 있습니다. Amazon Managed Service for Apache Flink 애플리케이션의 CloudWatch 로그에서 지속적인 `LimitExceededException` 오류가 발생하는지 확인해 이를 파악할 수 있습니다. **해결 방법**: 다음 두 가지 중 하나를 수행하여 이 시나리오를 해결할 수 있습니다. + `GetRecords` 직접 호출당 가져오는 레코드 수의 기본 한도를 낮춥니다. + Amazon Managed Service for Apache Flink 애플리케이션에서 적응형 읽기를 활성화합니다. 적응형 읽기 기능에 대한 자세한 내용을 알아보려면 [SHARD\$1USE\$1ADAPTIVE\$1READS](https://nightlies.apache.org/flink/flink-docs-release-1.10/api/java/org/apache/flink/streaming/connectors/kinesis/config/ConsumerConfigConstants.html#SHARD_USE_ADAPTIVE_READS)를 참조하십시오. # 체크포인트 체크포인트는 애플리케이션의 상태가 내결함성을 갖는지 확인하는 Flink의 메커니즘입니다. 이 메커니즘을 통해 Flink는 작업이 실패할 경우 연산자의 상태를 복구할 수 있으며 애플리케이션에는 오류 없는 실행과 동일한 의미를 부여합니다. Managed Service for Apache Flink를 사용하면 애플리케이션의 상태가 디스크에 작동 상태를 유지하는 내장형 키/값 저장소인 RocksDB에 저장됩니다. 체크포인트를 가져오면 상태가 Amazon S3에도 업로드되므로 디스크가 손실되더라도 체크포인트를 사용하여 애플리케이션 상태를 복원할 수 있습니다. 자세한 설명은 [상태 스냅샷은 어떻게 작동하는가?](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work) 섹션을 참조하세요. ## 체크포인트 단계 Flink의 체크포인트 연산자 하위 태스크에는 5대 단계가 있습니다: + 대기 [**시작 지연**] – Flink는 스트림에 삽입되는 체크포인트 장벽을 사용하므로 이 단계의 시간은 연산자가 체크포인트 장벽에 도달할 때까지 기다리는 시간입니다. + 정렬 **[정렬 지속 시간**] – 이 단계에서 하위 작업은 하나의 장벽에 도달했지만 다른 입력 스트림으로 들어오는 장벽을 기다리고 있습니다. + 동기화 체크포인트 [**동기화 지속 시간**] – 이 단계는 하위 작업이 실제로 연산자의 상태를 스냅샷하고 하위 작업의 다른 모든 활동을 차단하는 단계입니다. + 비동기 체크포인트 [**비동기 지속 시간**] – 이 단계의 대부분은 상태를 Amazon S3에 업로드하는 하위 작업입니다. 이 단계에서는 하위 작업이 더 이상 차단되지 않고 레코드를 처리할 수 있습니다. + 승인 – 일반적으로 짧은 단계이며 단순히 하위 작업이 JobManager에 승인을 보내고 위탁 메시지(예컨대, Kafka 싱크와 함께)를 수행하는 단계입니다. 이러한 각 단계(승인 단계 제외)는 Flink WebUI에서 사용할 수 있는 체크포인트의 기간 지표에 매핑되므로 긴 체크포인트의 원인을 파악하는 데 도움이 될 수 있습니다. 체크포인트에서 사용할 수 있는 각 지표의 정확한 정의를 보려면 [이력 탭](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab)으로 이동하십시오. ## 조사 중 긴 체크포인트 기간을 조사할 때 가장 중요한 것은 체크포인트의 병목 현상, 즉 어떤 연산자와 하위 작업이 체크포인트에 가장 오래 걸리고 해당 하위 작업의 어느 단계에 오랜 시간이 걸리는지입니다. 이는 작업 체크포인트 태스크에서 Flink WebUI를 사용하여 확인할 수 있습니다. Flink의 웹 인터페이스는 체크포인트 문제를 조사하는 데 도움이 되는 데이터와 정보를 제공합니다. 자세한 설명은 [체크포인트 모니터링](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/)을 참조하십시오. 가장 먼저 살펴볼 것은 Job 그래프에서 각 연산자의 **단대단 지속시간**입니다. 이를 통해 어떤 연산자가 체크포인트에 걸리는 시간이 소요되며 추가 조사가 필요한지 확인할 수 있습니다. Flink 설명서에 따르면 지속시간의 정의는 다음과 같습니다: *트리거 타임스탬프부터 가장 최근 승인까지 남은 시간(또는 아직 승인이 수신되지 않은 경우 해당 없음). 전체 체크포인트의 단대단 지속 시간은 체크포인트를 승인하는 마지막 하위 작업에 의해 결정됩니다. 이 시간은 일반적으로 단일 하위 작업에서 상태를 실제로 체크포인팅하는 데 필요한 시간보다 큽니다.* 체크포인트를 위한 다른 지속시간은 또한 그 시간이 어디에 사용되는지에 대한 보다 세밀한 정보를 제공합니다. **동기화 지속 시간**이 길면 스냅샷 중에 문제가 발생한 것입니다. 이 단계에서는 SnapshotState 인터페이스를 구현하는 클래스를 얻기 위해 `snapshotState()`을 호출합니다. 이것은 사용자 코드일 수 있으므로 스레드 덤프가 이 문제를 조사하는 데 유용할 수 있습니다. **비동기 지속 시간**이 길면 상태를 Amazon S3에 업로드하는 데 많은 시간이 소요되고 있음을 알 수 있습니다. 이는 상태가 크거나 업로드되는 상태 파일이 많은 경우 발생할 수 있습니다. 이런 경우에는 애플리케이션이 상태를 어떻게 사용하는지 조사하고 가능한 경우 Flink 네이티브 데이터 구조가 사용되고 있는지 확인하는 것이 좋습니다 ([관건 상태 사용](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Managed Service for Apache Flink는 Amazon S3 호출 횟수를 최소화하는 방식으로 Flink를 구성하여 호출이 너무 오래 걸리지 않도록 합니다. 다음은 연산자의 체크포인트 통계 예입니다. 이전 연산자 체크포인트 통계에 비해 **비동기 지속 시간**이 상대적으로 길다는 것을 알 수 있습니다. ![\[체크포인트 조사\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/checkpoint.png) **개시 지연**이 높으면 대부분의 시간이 체크포인트 장벽이 연산자에게 도달하기를 기다리는 데 소비되고 있다는 것을 알 수 있습니다. 이는 애플리케이션에서 기록을 처리하는 데 시간이 오래 걸리고 있다는 것을 의미하며, 이는 작업 그래프를 통해 장벽이 느리게 흐르고 있음을 의미합니다. 이는 일반적으로 Job이 역압을 받거나 연산자가 계속 바쁠 경우에 해당합니다. 다음은 두 번째 KeyedProcess 연산자가 사용 중인 JobGraph의 예입니다. ![\[체크포인트 조사\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/checkpoint2.png) Flink Graphs 또는 TaskManager 스레드 덤프를 사용하여 무엇이 그렇게 오래 걸리는지 조사할 수 있습니다. 병목 현상이 확인되면 Flame-graph 또는 스레드 덤프를 사용하여 더 자세히 조사할 수 있습니다. ## 스레드 덤프 스레드 덤프는 플레임 그래프보다 약간 낮은 수준에 있는 또 다른 디버깅 도구입니다. 스레드 덤프는 특정 시점의 모든 스레드의 실행 상태를 출력합니다. Flink는 Flink 프로세스 내 모든 스레드의 실행 상태인 JVM 스레드 덤프를 사용합니다. 스레드 상태는 스레드의 스택 트레이스와 몇 가지 추가 정보로 표시됩니다. 실제로 플레임 그래프는 여러 개의 스택 트레이스를 연속으로 빠르게 캡처하여 작성합니다. 그래프는 이러한 트레이스를 바탕으로 만든 가시화이므로 일반적인 코드 경로를 쉽게 식별할 수 있습니다. ``` "KeyedProcess (1/3)#0" prio=5 Id=1423 RUNNABLE at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:154) at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(>19) at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(:14) at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83) at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205) at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134) at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105) at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66) ... ``` 위는 Flink UI에서 단일 스레드에 대해 가져온 스레드 덤프의 스니펫입니다. 첫 번째 줄에는 다음을 포함하여 이 스레드에 대한 몇 가지 일반 정보가 포함되어 있습니다: + 스레드 명칭 *KeyedProcess (*1/3) \$10 + 스레드의 우선순위 *prio=5* + 고유 스레드 ID *ID=1423* + 스레드 상태 *실행 가능* 스레드 명칭은 일반적으로 스레드의 일반적인 용도에 대한 정보를 제공합니다. 연산자 스레드는 연산자와 명칭이 같기 때문에 연산자 스레드는 그 명칭으로 식별할 수 있으며 스레드가 어떤 하위 작업과 관련되어 있는지를 나타냅니다. 예컨대, *KeyedProcess (1/3)\$10* 스레드는 *KeyedProcess* 연산자 출신으로서 (3개 중) 첫 번째 하위 태스크에서 온 것입니다. 스레드는 몇 가지 상태 중 하나일 수 있습니다. + 신규 – 스레드가 생성되었지만 아직 처리되지는 않았음. + 실행 가능 – 스레드가 CPU에서 실행 중임. + 차단됨 – 스레드가 다른 스레드에 의한 잠금 해제를 기다리고 있음. + 대기 – `wait()`, `join()`, 또는 `park()` 메서드를 사용함으로써 스레드가 대기 중임. + TIMED\$1WAITING – 스레드가 sleep, wait, join 또는 park 메서드를 사용하여 대기 중이지만 대기 시간은 최대로 설정되어 있음. **참고** Flink 1.13에서는 스레드 덤프에 있는 단일 스택 트레이스의 최대 깊이가 8로 제한됩니다. **참고** 스레드 덤프는 읽기가 어렵고 여러 샘플을 채취하여 수동으로 분석해야 하므로 Flink 애플리케이션에서 성능 문제를 디버깅할 때 최후의 수단이어야 합니다. 가능하면 플레임 그래프를 사용하는 것이 좋습니다. ### Flink의 스레드 덤프 Flink에서는 Flink UI의 왼쪽 탐색 표시줄에서 **작업 관리자** 옵션을 선택하고 특정 작업 관리자를 선택한 다음 스레드 덤프 탭으로 이동하여 **스레드 덤프**를 가져올 수 있습니다. 스레드 덤프는 다운로드하거나 즐겨 사용하는 텍스트 편집기 (또는 스레드 덤프 분석기) 에 복사하거나 Flink 웹 UI의 텍스트 보기 내에서 직접 분석할 수 있습니다 (하지만 이 마지막 옵션은 약간 복잡할 수 있습니다). 스레드 덤프를 수행할 작업 관리자를 결정하려면 특정 연산자를 선택한 경우 **TaskManager** 탭의 스레드 덤프를 사용할 수 있습니다. 이는 연산자가 연산자의 여러 하위 작업에서 실행되고 있으며 다른 작업 관리자에서 실행될 수 있음을 나타냅니다. ![\[스레드 덤프 사용\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/checkpoint4.png) 덤프는 여러 스택 트레이스로 구성됩니다. 하지만 덤프를 조사할 때는 연산자와 관련된 것이 가장 중요합니다. 연산자 스레드는 연산자와 이름이 같을 뿐만 아니라 해당 스레드가 어떤 하위 작업과 관련되어 있는지 알 수 있기 때문에 쉽게 찾을 수 있습니다. 예를 들어 다음 스택 트레이스는 *KeyedProcess* 연산자에서 가져온 것이며 첫 번째 하위 태스크입니다. ``` "KeyedProcess (1/3)#0" prio=5 Id=595 RUNNABLE at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:155) at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:19) at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:14) at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83) at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205) at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134) at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105) at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66) ... ``` 이름이 같은 연산자가 여러 개 있는 경우 혼란스러울 수 있지만 연산자의 이름을 지정하여 이러한 문제를 피할 수 있습니다. 예제: ``` .... .process(new ExpensiveFunction).name("Expensive function") ``` ## [플레임 그래프](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/) 플레임 그래프는 목적지 코드의 스택 트레이스를 가시화하는 유용한 디버깅 도구로, 이를 통해 가장 빈번한 코드 경로를 식별할 수 있습니다. 스택 트레이스를 여러 번 샘플링하여 생성합니다. 플레임 그래프의 x 축은 다양한 스택 프로필을 보여주고, y 축은 스택 깊이와 스택 트레이스에서의 호출을 보여줍니다. 플레임 그래프에서 단일 직사각형은 스택 프레임을 나타내며, 프레임 너비는 스택에서 해당 사각형이 나타나는 빈도를 나타냅니다. 플레임 그래프 및 사용 방법에 대한 자세한 설명은 [플레임 그래프](https://www.brendangregg.com/flamegraphs.html)를 참조하십시오. Flink에서는 연산자를 선택한 다음 **FlameGraph** 탭을 선택하여 웹 UI를 통해 연산자에 대한 플레임 그래프에 액세스할 수 있습니다. 샘플이 충분히 수집되면 플레임 그래프가 표시됩니다. 다음은 체크포인트에 많은 시간이 걸렸던 ProcessFunction의 플레임 그래프입니다. ![\[플레임 그래프 사용\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/checkpoint3.png) 이것은 매우 간단한 플레임 그래프로, 모든 CPU 시간이 ExpensiveFunction 연산자의 `processElement`내의 foreach 룩에 소비되고 있음을 보여줍니다. 또한 라인 번호도 확인할 수 있어 코드 실행이 이루어지는 위치를 파악하는 데 도움이 됩니다. # 체크포인트 시간이 초과되었습니다. 애플리케이션이 최적화되지 않았거나 제대로 프로비저닝되지 않은 경우 체크포인트가 실패할 수 있습니다. 이 섹션에서는 이러한 상태에 대한 증상과 문제 해결 조치들을 설명합니다. ## 증상 애플리케이션의 체크포인트에 장애가 발생하는 경우 `numberOfFailedCheckpoints` 값은 0보다 커집니다. 애플리케이션 오류와 같은 직접적인 장애나 애플리케이션 리소스 부족과 같은 일시적인 장애로 인해 체크포인트가 실패할 수 있습니다. 애플리케이션 로그와 지표에서 다음과 같은 증상이 있는지 확인하십시오. + 코드에 오류가 있습니다. + 애플리케이션의 종속 서비스에 액세스하는 중 오류가 발생했습니다. + 데이터를 직렬화하는 중 오류가 발생했습니다. 기본 시리얼라이저가 애플리케이션 데이터를 직렬화할 수 없는 경우 애플리케이션이 실패합니다. 애플리케이션에서 사용자 지정 직렬 변환기를 사용하는 방법에 관한 자세한 설명은 Apache Flink 설명서의 [데이터 형식 및 직렬화](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/)를 참조하세요. + 메모리 부족 오류 + 다음 지표의 스큐 또는 꾸준한 증가 + `heapMemoryUtilization` + `oldGenerationGCTime` + `oldGenerationGCCount` + `lastCheckpointSize` + `lastCheckpointDuration` 자세한 내용을 알아보려면 Apache Flink 설명서의 [체크포인트 모니터링](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/)을 참조하세요. ## 원인 및 해결 방법 애플리케이션 로그 오류 메시지에는 직접 실패의 원인이 표시됩니다. 일시적 오류에는 다음과 같은 원인이 있을 수 있습니다: + 애플리케이션에 KPU 프로비저닝이 충분하지 않음. 애플리케이션 프로비저닝 향상에 대한 자세한 설명은 [애플리케이션 규모 조정 구현](how-scaling.md)을 참조하십시오. + 애플리케이션 상태 크기가 너무 큼. `lastCheckpointSize`지표를 사용하여 애플리케이션 상태 크기를 모니터링할 수 있습니다. + 애플리케이션의 상태 데이터는 여러 키 간에 불균등하게 분산됩니다. 애플리케이션에서 `KeyBy` 연산자를 사용하는 경우 들어오는 데이터가 여러 키 간에 균등하게 분배되는지 확인하십시오. 대부분의 데이터가 단일 키에 할당되면 병목 현상이 발생하여 오류가 발생합니다. + 애플리케이션에서 메모리 또는 가비지 컬렉션 역압을 경험하고 있음. 애플리케이션의 값이 급증하거나 꾸준히 증가하는 값이 있는지 애플리케이션의 `heapMemoryUtilization`, `oldGenerationGCTime` 및 `oldGenerationGCCount`을 모니터링하세요. # Apache Beam 애플리케이션의 체크포인트 실패 Beam 애플리케이션이 [shutdownSourcesAfterIdleMs를](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs) 0ms로 설정하도록 구성된 경우 작업이 “완료” 상태이기 때문에 체크포인트가 트리거되지 않을 수 있습니다. 이 섹션에서는 그러한 상황의 증상과 해결 방법을 설명합니다. ## 증상 Managed Service for Apache Flink 애플리케이션 CloudWatch 로그로 이동하여 다음 로그 메시지가 기록되었는지 확인합니다. 다음 로그 메시지는 일부 작업이 완료되어 체크포인트가 트리거되지 않았음을 나타냅니다. ``` { "locationInformation": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator.onTriggerFailure(CheckpointCoordinator.java:888)", "logger": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator", "message": "Failed to trigger checkpoint for job your job ID since some tasks of job your job ID has been finished, abort the checkpoint Failure reason: Not all required tasks are currently running.", "threadName": "Checkpoint Timer", "applicationARN": your application ARN, "applicationVersionId": "5", "messageSchemaVersion": "1", "messageType": "INFO" } ``` 일부 작업이 “완료” 상태로 전환되어 더 이상 체크포인트를 지정할 수 없는 Flink 대시보드에서도 이 문제를 확인할 수 있습니다. ![\[“완료” 상태인 작업은\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/beam_checkpoint_failure.png) ## 원인 ShutdownSourcesAfterIdleMs는 구성된 시간(밀리초) 동안 유휴 상태였던 소스를 종료하는 Beam 구성 변수입니다. 일단 소스가 종료되면 체크포인트를 더 이상 사용할 수 없습니다. 이로 인해 [체크포인트 오류](https://issues.apache.org/jira/browse/FLINK-2491)가 발생할 수 있습니다. 작업이 “완료” 상태로 전환되는 원인 중 하나는 ShutdownSourcesAfterIdleMs가 0ms로 설정된 경우입니다. 즉, 유휴 상태인 작업이 즉시 종료됩니다. ## Solution 작업이 즉시 “완료” 상태로 전환되지 않도록 하려면 shutdownSourcesAfterIdleMs를 Long.MAX\$1VALUE를 설정하십시오. 이것은 두 가지 방법으로 수행될 수 있습니다. + 옵션 1: Managed Service for Apache Flink 애플리케이션 구성 페이지에서 빔 구성을 설정한 경우 다음과 같이 새 키 값 쌍을 추가하여 shutdpwnSourcesAfteridleMs를 설정할 수 있습니다. ![\[shutdpwnSourcesAfteridleMs를 Long.MAX_VALUE로 설정합니다.\]](http://docs.aws.amazon.com/ko_kr/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png) + 옵션 2: JAR 파일에 빔 컨피그레이션이 설정된 경우 다음과 같이 shutdpwnSourcesAfteridleMs를 설정할 수 있습니다: ``` FlinkPipelineOptions options = PipelineOptionsFactory.create().as(FlinkPipelineOptions.class); // Initialize Beam Options object options.setShutdownSourcesAfterIdleMs(Long.MAX_VALUE); // set shutdownSourcesAfterIdleMs to Long.MAX_VALUE options.setRunner(FlinkRunner.class); Pipeline p = Pipeline.create(options); // attach specified options to Beam pipeline ``` # 역압 Flink는 역압을 사용하여 개별 연산자의 처리 속도를 조정합니다. 연산자는 여러 가지 이유로 수신한 메시지 양을 계속 처리하는 데 어려움을 겪을 수 있습니다. 작업에는 연산자가 사용할 수 있는 것보다 많은 CPU 리소스가 필요할 수 있습니다. 연산자는 I/O 작업이 완료될 때까지 기다릴 수 있습니다. 연산자가 이벤트를 충분히 빠르게 처리하지 못하면 업스트림 연산자에 역압이 가중되어 속도가 느린 연산자에게 전달됩니다. 이로 인해 업스트림 연산자의 속도가 느려지고, 이로 인해 역압이 소스로 더 전파되어 소스가 애플리케이션의 전체 처리량에 맞게 조정되어 속도가 느려질 수 있습니다. [Apache Flink™가 역압을 처리하는 방법](https://www.ververica.com/blog/how-flink-handles-backpressure)에서 역압과 그 작동 방식에 대한 자세한 설명을 확인할 수 있습니다. 애플리케이션에서 속도가 느린 연산자를 알면 애플리케이션 성능 문제의 근본 원인을 이해하는 데 중요한 정보를 얻을 수 있습니다. 역압 정보는 [Flink 대시보드를 통해 노출됩니다](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). 속도가 느린 연산자를 식별하려면 싱크에 가장 가까운 높은 역압 값을 가진 연산자를 찾으십시오(다음 예에서는 연산자 B). 그러면 속도 저하를 초래한 연산자가 다운스트림 연산자 중 한 명입니다(해당 예에서는 연산자 C). B는 이벤트를 더 빠르게 처리할 수 있지만 출력을 실제 느린 연산자 C에게 전달할 수 없으므로 역압을 받습니다. ``` A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%) ``` 느린 연산자를 식별한 후에는 속도가 느린 이유를 이해해 보십시오. 이유는 무수히 많을 수 있으며, 무엇이 잘못되었는지 명확하지 않을 수 있으며 문제를 해결하는 데 며칠의 디버깅과 프로필링이 필요할 수 있습니다. 다음은 명확하고 일반적인 몇 가지 이유이며, 그 중 일부는 아래에 자세히 설명되어 있습니다: + 연산자가 느린 I/O(예: 네트워크 호출)를 하고 있습니다(대신 AsyncIO를 사용할 것을 고려하세요). + 데이터에 편중이 있고 Flink 대시보드에서 한 연산자가 다른 연산자보다 더 많은 이벤트를 수신하고 있습니다(개별 하위 작업(예: 동일한 연산자의 인스턴스)에서 들어오고 나가는 메시지 수를 보아서 확인하십시오. + 이는 리소스 집약적인 작업입니다(데이터 왜곡이 없다면 CPU/메모리 바운드 작업을 위해 규모를 확장하거나 I/O 바운드 작업을 위해 `ParallelismPerKPU`을 늘리는 것을 고려해 보세요). + 연산자의 광범위한 로깅(프로덕션 애플리케이션의 경우 로깅을 최소한으로 줄이거나 대신 디버그 출력을 데이터 스트림으로 보내는 방안을 고려해 보세요). ## 폐기 싱크를 사용한 처리량 테스트 [폐기 싱크](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html)는 단순히 애플리케이션을 실행하는 동안 수신되는 모든 이벤트를 무시합니다. 즉, 싱크가 없는 애플리케이션은 실행되지 않습니다. 이는 처리량 테스트, 프로필링, 애플리케이션이 적절하게 확장되고 있는지 확인하는 데 매우 유용합니다. 또한 싱크로 인해 역압이나 애플리케이션이 발생하는지 확인하는 것도 매우 실용적인 온전성 검사입니다(하지만 많은 경우 역압 지표를 확인하는 것만으로도 더 쉽고 간단합니다). 애플리케이션의 모든 싱크를 폐기 싱크로 바꾸고 프로덕션 데이터와 유사한 데이터를 생성하는 모의 소스를 만들면 특정 병렬 처리 설정에서 애플리케이션의 최대 처리량을 측정할 수 있습니다. 그런 다음 병렬 처리를 늘려 애플리케이션이 적절하게 규모 조정되고 처리량이 높아질 때만 발생하는 병목 현상이 없는지 (예: 데이터 편중) 확인할 수도 있습니다. # 데이터 편중 Flink 애플리케이션은 클러스터에서 분산 방식으로 실행됩니다. Flink는 여러 노드로 확장하기 위해 키 스트림이라는 개념을 사용합니다. 즉, 고객 ID와 같은 특정 키에 따라 스트림의 이벤트가 분할되고 Flink는 여러 노드의 여러 파티션을 처리할 수 있습니다. 그런 다음 [키 윈도우](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/), [프로세스 함수](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/), [비동기 I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) 등과 같은 여러 Flink 연산자를 이러한 파티션을 기반으로 평가합니다. 파티션 키 선택은 대개 비즈니스 로직에 따라 달라집니다. 동시에 다음과 같은 [DynamoDB](https://aws.amazon.com/dynamodb/) 및 Spark의 여러 모범 사례가 Flink에도 동일하게 적용됩니다. + 파티션 키의 높은 농도 보장 + 파티션 간 이벤트 볼륨 왜곡 방지 Flink 대시보드에서 하위 작업(예: 동일한 연산자의 인스턴스)의 수신/전송 기록을 비교하여 파티션의 편차를 식별할 수 있습니다. 또한 Managed Service for Apache Flink 모니터링을 `numRecordsIn/Out` 및 `numRecordsInPerSecond/OutPerSecond`의 지표들이 하위 작업 수준에도 노출되도록 구성할 수 있습니다. # 상태 편중 상태 저장 연산자, 즉 창과 같은 비즈니스 로직의 상태를 유지하는 연산자의 경우 데이터 편중은 항상 상태 편중으로 이어집니다. 일부 하위 작업은 데이터의 편중으로 인해 다른 작업보다 더 많은 이벤트를 수신하므로 더 많은 데이터가 상태 그대로 유지됩니다. 그러나 파티션이 균등하게 분산된 애플리케이션의 경우에도 상태에 유지되는 데이터 양에 차이가 있을 수 있습니다. 예를 들어 세션 창의 경우 일부 사용자와 세션은 각각 다른 사용자보다 훨씬 더 길 수 있습니다. 긴 세션이 동일한 파티션에 속하게 되면 동일한 연산자의 여러 하위 태스크가 유지하는 상태 크기가 불균형해질 수 있습니다. 상태 편중은 개별 하위 작업에 필요한 메모리 및 디스크 리소스를 증가시킬 뿐만 아니라 애플리케이션의 전반적인 성능을 저하시킬 수도 있습니다. 애플리케이션이 체크포인트 또는 세이브포인트를 가져오는 경우 연산자 상태가 Amazon S3에 유지되어 노드 또는 클러스터 장애로부터 상태를 보호합니다. 이 프로세스 진행 중에는 (특히 Managed Service for Apache Flink에서 정확히 1회의 시맨틱이 기본으로 활성화되어 있는 경우) 체크포인트/세이브포인트가 완료될 때까지 외부 관점에서 처리가 중단됩니다. 데이터 편중이 있는 경우 특히 많은 양의 상태가 누적된 단일 하위 작업으로 인해 작업을 완료하는 데 걸리는 시간이 제한될 수 있습니다. 극단적인 경우에는 단일 하위 작업이 상태를 유지할 수 없어 체크포인트/세이브포인트 가져오기가 실패할 수 있습니다. 따라서 상태 편중은 데이터 편중과 마찬가지로 애플리케이션 속도를 크게 저하시킬 수 있습니다. 상태 편중을 식별하기 위해 Flink 대시보드를 활용할 수 있습니다. 최근 체크포인트 또는 세이브포인트를 찾아 세부 정보에서 개별 하위 작업에 대해 저장된 데이터의 양을 비교해 보세요. # 서로 다른 리전의 리소스와 통합 Flink 구성에서 지역 간 복제에 필요한 설정을 통해 Managed Service for Apache Flink 애플리케이션과 다른 지역에 있는 Amazon S3 버킷에 쓸 수 있도록 `StreamingFileSink`의 사용을 활성화할 수 있습니다. 이를 위해서는 [AWS Support 센터](https://console.aws.amazon.com/support/home#/)에 지원 티켓을 제출하십시오.