신중한 고려 끝에 Amazon Kinesis Data Analytics for SQL 애플리케이션을 중단하기로 결정했습니다.
1. **2025년 9월 1**일부터 Amazon Kinesis Data Analytics for SQL 애플리케이션에 대한 버그 수정은 제공되지 않습니다. 곧 중단될 예정이므로 지원이 제한될 예정이기 때문입니다.
2. **2025년 10월 15**일부터 새 Kinesis Data Analytics for SQL 애플리케이션을 생성할 수 없습니다.
3. **2026년 1월 27**일부터 애플리케이션이 삭제됩니다. Amazon Kinesis Data Analytics for SQL 애플리케이션을 시작하거나 작동할 수 없게 됩니다. 그 시점부터 Amazon Kinesis Data Analytics for SQL에 대한 지원을 더 이상 이용할 수 없습니다. 자세한 내용은 [Amazon Kinesis Data Analytics for SQL 애플리케이션 단종](discontinuation.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 모범 사례
이 섹션에서는 Amazon Kinesis Data Analytics 애플리케이션 작업의 모범 사례를 설명합니다.
**Topics**
+ [애플리케이션 관리](#bp-manage-apps)
+ [Scaling 애플리케이션](#bp-scale-apps)
+ [애플리케이션 모니터링](#bp-monitor-apps)
+ [입력 스키마 정의](#bp-define-inputschema)
+ [출력 연결](#bp-connect-to-outputs)
+ [애플리케이션 코드 작성](#bp-authoring-sqlcode)
+ [애플리케이션 테스트](#bp-testing)
## 애플리케이션 관리
Amazon Kinesis Data Analytics 애플리케이션을 관리할 때 다음 모범 사례를 따르십시오:
+ Amazon CloudWatch 경보 설정 – Kinesis Data Analytics에서 제공하는 CloudWatch 지표를 사용하여 다음을 모니터링할 수 있습니다:
+ 입력 바이트 및 입력 레코드(애플리케이션으로 들어오는 바이트 및 레코드의 수)
+ 입력 바이트 및 출력 레코드
+ `MillisBehindLatest` (애플리케이션이 스트리밍 소스에서 읽어오는 시간이 뒤처진 정도를 나타냅니다)
프로덕션 내 애플리케이션 용 지표에 대해 둘 이상의 경보를 설정하는 것이 좋습니다:
+ `MillisBehindLatest` – 대부분의 경우, 애플리케이션이 최신 데이터보다 한 시간 뒤쳐진 경우 평균 1분 간격으로 경보가 발동되도록 설정하는 것이 좋습니다. 종단 간 처리 필요성이 낮은 애플리케이션의 경우, 허용치를 더 적게 조정할 수 있습니다. 이 경보는 애플리케이션이 최신 데이터를 읽고 있는지 확인하는 데 도움이 됩니다.
+ `ReadProvisionedThroughputException` 예외를 피하기 위해 동일한 Kinesis 데이터 스트림을 읽는 프로덕션 애플리케이션의 수를 2개로 제한하십시오.
**참고**
이 경우, *애플리케이션*은 스트리밍 소스로부터 읽을 수 있는 모든 애플리케이션을 가리킵니다. Kinesis Data Firehose 전송 스트림은 Firehose 전송 스트림에서 읽을 수 있습니다. 그러나 Kinesis Data Analytics 애플리케이션 또는 같은 Kinesis 데이터 스트림에서 많은 애플리케이션을 읽을 수 있습니다 AWS Lambda. 권장 애플리케이션 한도는 스트리밍 소스로부터 읽도록 구성하는 모든 애플리케이션을 참고합니다.
Amazon Kinesis Data Analytics가 스트리밍 소스로부터 읽는 속도는 애플리케이션당 약 1회/초입니다. 그러나 뒤쳐진 애플리케이션의 경우 따라잡기 위해 더 빨리 읽을 수 있습니다. 애플리케이션이 따라잡을 수 있는 적절한 처리량을 허용하기 위해 동일한 데이터 소스를 읽는 애플리케이션 수를 제한하십시오.
+ 동일한 Firehose 전송 스트림으로부터 읽는 프로덕션 애플리케이션의 수를 하나로 제한하세요.
Firehose 전송 스트림은 Amazon S3 및 Amazon Redshift와 같은 대상에 작성할 수 있습니다. 또한 Kinesis Data Analytics 애플리케이션의 스트리밍 소스가 될 수 있습니다. 따라서 Firehose 전송 스트림당 Kinesis Data Analytics 애플리케이션 수를 하나 이하로 구성할 것을 권장합니다. 이렇게 하면 전송 스트림을 다른 대상으로도 전송할 수 있습니다.
## Scaling 애플리케이션
입력 애플리케이션 내 스트림 수를 사전에 기본값(1)에서 증가시켜 향후 조정 니즈에 맞게 애플리케이션을 설정하십시오. 애플리케이션의 처리량에 따라 다음의 언어 선택을 권장합니다:
+ 애플리케이션이 100MB/초 이상으로 조정해야 할 경우 복수의 스트림과 SQL 애플리케이션용 Kinesis Data Analytics를 사용하십시오.
+ 단일 스트림과 애플리케이션을 사용하려는 경우 [Managed Service for Apache Flink Applications](https://docs.aws.amazon.com/managed-flink/latest/java/what-is.html)를 사용하십시오.
**참고**
애플리케이션의 예상 입력 처리량이 100MB/초를 초과하는 경우 여러 SQL 애플리케이션을 사용할 계획을 미리 계획하거나 Managed-flink/latest/java/로 마이그레이션할 수 있도록 애플리케이션의 `InputProcessing.OkBytes` 메트릭을 정기적으로 검토하는 것이 좋습니다.
## 애플리케이션 모니터링
애플리케이션이 입력 처리량 `InputProcessing.OkBytes` 한도에 가까워지면 알림을 받을 수 있도록 CloudWatch 경보를 생성하는 것이 좋습니다. 이는 애플리케이션 쿼리를 업데이트하여 처리량을 늘려주므로 분석의 역압과 지연을 방지할 수 있으므로 유용할 수 있습니다. 자세한 설명은 [문제 해결](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/troubleshooting.html)을 참조하십시오. 업스트림에서 처리량을 줄이는 메커니즘이 있는 경우에도 유용할 수 있습니다.
+ 단일 애플리케이션 내 스트림에 권장되는 최대 처리량은 애플리케이션 쿼리의 복잡성에 따라 2\$120MB/초입니다.
+ 단일 Kinesis Data Analytics for SQL 애플리케이션으로 처리할 수 있는 최대 스트리밍 처리량은 약 100MB/초입니다. 이는 애플리케이션 내 스트림 수를 최대값인 64개로 늘리고 KPU 한도를 8개 이상으로 늘렸다고 가정합니다. 자세한 설명은 [한도](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/limits.html)를 참조하십시오.
**참고**
애플리케이션의 예상 입력 처리량이 100MB/초를 초과하는 경우 여러 SQL 애플리케이션을 사용할 계획을 미리 계획하거나 Managed-flink/latest/java/로 마이그레이션할 수 있도록 애플리케이션의 `InputProcessing.OkBytes` 메트릭을 정기적으로 검토하는 것이 좋습니다.
## 입력 스키마 정의
콘솔에서 애플리케이션 입력을 구성할 때 먼저 스트리밍 소스를 지정합니다. 그런 다음 콘솔이 검색 API([DiscoverInputSchema](API_DiscoverInputSchema.md) 참조)를 통해 스트리밍 소스에서 레코드를 샘플링하여 스키마를 유추합니다. 특히 스키마는 산출된 애플리케이션 내 스트림에 있는 열의 데이터 유형을 정의합니다. 콘솔이 스키마를 표시합니다. 유추된 스키마로 다음 작업을 수행하는 것이 좋습니다.
+ 유추된 스키마를 적절히 테스트합니다. 검색 프로세스는 스트리밍 소스의 레코드 샘플만 사용하여 스키마를 유추합니다. 스트리밍 소스의 [레코드 유형이 다수](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/app-tworecordtypes.html)인 경우, 검색 API가 하나 이상의 레코드 유형의 샘플링을 놓칠 가능성이 있습니다. 이러한 상황은 스키마가 스트리밍 소스상 데이터를 정확히 반영하지 못하는 결과를 초래할 수 있습니다.
애플리케이션이 시작될 때 이러한 레코드 유형이 누락되면 구문 분석 오류가 발생할 수 있습니다. Amazon Kinesis Data Analytics는 이러한 레코드를 애플리케이션 내 오류 스트림으로 보냅니다. 이러한 파싱 오류를 줄이기 위해 유추된 스키마를 콘솔에서 양방향으로 테스트하고 누락된 레코드에 대해 애플리케이션 내 스트림을 모니터링할 것을 권장합니다.
+ Kinesis Data Analytics API는 입력 구성에서 열에 대한 `NOT NULL` 제약 지정을 지원하지 않습니다. 애플리케이션 내 스트림에서 열에 대한 `NOT NULL` 제약을 원하는 경우 애플리케이션 코드를 사용하여 이를 애플리케이션 내 스트림에 생성해야 합니다. 그런 다음 하나의 애플리케이션 내 스트림에서 다른 애플리케이션 내 스트림으로 데이터를 복사하면 제약이 적용됩니다.
값이 필요할 때 `NULL` 값이 있는 행을 삽입하려고 하면 오류가 발생합니다. Kinesis Data Analytics는 이러한 오류를 애플리케이션 내 오류 스트림으로 보냅니다.
+ 검색 프로세스에 의해 유추된 데이터 유형을 완화합니다. 검색 프로세스는 스트리밍 소스에서의 무작위 레코드 샘플링을 바탕으로 열 및 데이터 유형을 추천합니다. 이를 신중히 검토하여 입력에 있는 레코드의 가능한 모든 경우를 망라할 수 있도록 이들 데이터 유형의 완화를 고려할 것을 권장합니다. 이렇게 하면 애플리케이션 전반에 걸쳐 실행 중에 파싱 오류의 발생을 줄일 수 있습니다. 예를 들어, 유추된 스키마의 열 유형이 `SMALLINT` 인 경우 `INTEGER`로 변경하는 것을 고려할 수 있습니다.
+ 애플리케이션 코드에서 SQL 함수를 사용하여 구성되지 않은 임의의 데이터 도는 열을 처리합니다. 입력에 로그 데이터와 같이 구성되지 않은 데이터 또는 열이 있을 수 있습니다. 예를 보려면 [예: DateTime 값 변환](app-string-datetime-manipulation.md) 섹션을 참조하십시오. 이러한 유형의 데이터를 처리하는 접근 방식 중 하나는 `VARCHAR(N)` 한 가지 유형의 열로만 스키마를 정의하는 것입니다. 여기에서 `N`는 스트림에서 나타날 것으로 예상되는 행 중 가장 큰 것입니다. 그런 다음 애플리케이션 코드에서 수신 레코드를 읽습니다. `String` 그리고 `Date Time` 함수를 사용하여 원시 데이터를 구문 분석하고 스키마로 변환합니다.
+ 두 개 수준을 초과하는 중첩을 포함하는 스트리밍 소스 데이터를 완전히 처리하고 있는지 확인합니다. 소스 데이터가 JSON인 경우 중첩을 가질 수 있습니다. 검색 API가 하나의 수준 중첩을 평면화하는 스키마를 유추합니다. 두 개 수준의 중첩의 경우에도 검색 API가 평면화를 시도합니다. 두 개 수준을 초과하는 중첩의 경우 평면화 지원에 제한이 있습니다. 중첩을 온전히 처리하기 위해서는 유추된 스키마를 필요에 맞게 직접 수정해야 합니다. 다음 전략 중 하나를 사용하여 이를 수행하면 됩니다.
+ JSON 행 경로를 사용하여 애플리케이션에 요구되는 키 값만 선택적으로 가져옵니다. A JSON 행 경로는 애플리케이션으로 가져오고자 하는 특정 키 값 페어에 대한 포인터를 제공합니다. 모든 수준의 중첩에 대해 이를 수행할 수 있습니다.
+ JSON 행 경로를 사용하여 복잡한 JSON 객체를 선택적으로 가져온 다음 애플리케이션 코드에서 문자열 조작 함수를 사용하여 필요로 하는 특정 데이터를 가져옵니다.
## 출력 연결
모든 애플리케이션이 둘 이상의 출력을 가지는 것이 좋습니다:
+ 첫 번째 대상을 사용하여 SQL 쿼리의 결과를 삽입합니다.
+ 두 번째 대상을 사용하여 전체 오류 스트림을 삽입하고 Firehose 전송 스트림을 통해 S3 버킷으로 전송합니다.
## 애플리케이션 코드 작성
다음과 같이 하는 것이 좋습니다:
+ SQL 문에서 시간 기반 창을 1시간 이상으로 지정하지 마십시오. 그 이유는 다음과 같습니다.
+ 때때로 애플리케이션 업데이트 또는 Kinesis Data Analytics 내부 이유로 애플리케이션을 다시 시작해야 합니다. 애플리케이션을 다시 시작하는 경우 해당 창에 포함된 모든 데이터를 스트리밍 데이터 소스로부터 다시 읽어야 합니다. 이 때문에 Kinesis Data Analytics가 해당 창에 출력하는 데 시간이 소요됩니다.
+ Kinesis Data Analytics는 해당 기간 동안의 애플리케이션 상태에 관한 모든 요소(관련 데이터 포함)를 유지해야 합니다. 이 경우 상당한 Kinesis Data Analytics 처리 단위가 소모됩니다.
+ 개발 시에 결과를 보다 빨리 확인할 수 있도록 SQL 문에서 창 크기를 작게 유지하십시오. 애플리케이션을 프로덕션 환경에 배포할 때 창 크기를 적절히 설정할 수 있습니다.
+ 복잡한 단일 SQL 문을 복수의 문으로 나누고 각 단계에서 결과를 중간 애플리케이션 내 스트림에 저장하는 것을 고려할 수 있습니다. 이렇게 하면 디버깅을 신속하게 수행할 수 있습니다.
+ [텀블링 창을](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/tumbling-window-concepts.html) 사용할 때 두 개의 창을 사용할 것을 권장합니다. 하나는 처리 시간, 다른 하나는 논리 시간 (수집 시간 또는 이벤트 시간) 창입니다. 자세한 설명은 [타임스탬프와 ROWTIME 열](timestamps-rowtime-concepts.md) 섹션을 참조하십시오.
## 애플리케이션 테스트
Kinesis Data Analytics 애플리케이션의 스키마 또는 애플리케이션 코드를 변경할 경우, 변경 사항을 프로덕션에 배포하기 전에 테스트 애플리케이션을 사용하여 변경 사항을 확인하는 것이 좋습니다.
### 테스트 애플리케이션 설정
콘솔을 통해 또는 CloudFormation 템플릿을 사용하여 테스트 애플리케이션을 설정할 수 있습니다. CloudFormation 템플릿을 사용하면 테스트 애플리케이션과 라이브 애플리케이션에 대한 코드 변경 사항을 일관되게 유지할 수 있습니다.
테스트 애플리케이션을 설정할 때 애플리케이션을 라이브 데이터에 연결하거나 테스트 대상이 될 모의 데이터로 스트림을 채울 수 있습니다. 다음 두 가지 방법으로 모의 데이터로 스트림을 채울 수 있습니다.
+ [Kinesis 데이터 제너레이터(KDG)](https://aws.amazon.com/blogs/big-data/test-your-streaming-data-solution-with-the-new-amazon-kinesis-data-generator/)를 사용합니다. KDG는 데이터 템플릿을 사용하여 임의 데이터를 Kinesis 스트림에 보냅니다. KDG는 사용이 간편하지만, 데이터 핫스팟이나 이상을 탐지하는 애플리케이션의 경우와 같이 데이터 항목 사이의 복잡한 관계를 테스트하는 데 적합하지 않습니다.
+ 맞춤 Python 애플리케이션을 사용하여 더 복잡한 데이터를 데이터 스트림으로 보냅니다. Python 애플리케이션은 핫스팟이나 이상과 같은 데이터 항목들 사이의 복잡한 관계를 생성할 수 있습니다. 클러스터링된 데이터를 데이터 핫스팟으로 보내는 Python 애플리케이션의 예는 [예: 스트림에서 핫스팟 감지(HOTSPOTS 함수)](app-hotspots-detection.md)를 참조하십시오.
테스트 애플리케이션을 실행할 때 콘솔의 애플리케이션 내 스트림을 확인하는 대신 대상(Amazon Redshift 데이터베이스로 향하는 Firehose 전송 스트림)을 사용하여 결과를 모니터링합니다. 콘솔에 표시되는 데이터는 스트림의 샘플링이며 레코드를 모두 포함하지는 않습니다.
### 스키마 변경 사항 테스트
애플리케이션의 입력 스트림 스키마를 변경할 때 테스트 애플리케이션을 사용하여 다음 사항이 사실인지 확인합니다.
+ 스트림의 데이터가 올바른 데이터 유형으로 강제 변환되고 있습니다. 예를 들어, 날짜/시간 데이터가 문자열로 애플리케이션에 수집되지 않도록 해야 합니다.
+ 데이터는 원하는 데이터 유형으로 구문 분석 및 수집되고 있습니다. 분석 또는 강제 변환 오류가 발생할 경우, 콘솔에서 이러한 오류를 확인하거나 대상을 오류 스트림에 할당하고 대상 스토어의 오류를 확인할 수 있습니다.
+ 문자 데이터의 데이터 필드는 길이가 충분하며, 애플리케이션은 문자 데이터를 잘라내지 않습니다. 대상 스토어의 데이터 레코드를 점검하여 애플리케이션 데이터가 잘리지 않음을 점검할 수 있습니다.
### 코드 변경 사항 테스트
SQL 코드의 변경 사항 테스트에는 애플리케이션의 도메인 지식이 필요합니다. 어떤 출력을 테스트해야 하는지와 어떤 것이 올바른 출력인지 판단할 수 있어야 합니다. 애플리케이션의 SQL 코드 수정 시 확인해야 할 문제 가능성이 있는 영역에 대해서는 [Amazon Kinesis Data Analytics for SQL 애플리케이션 문제 해결](troubleshooting.md)를 참조하십시오.