신중한 고려 끝에 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) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 입력 스트림 병렬화를 통한 처리량 증대
**참고**
2023년 9월 12일 이후에는 Kinesis Data Analytics for SQL의 기존 사용자가 아닌 경우, Kinesis Data Firehose를 소스로 사용하여 새 애플리케이션을 생성할 수 없습니다. 자세한 설명은 [한도](https://docs.aws.amazon.com//kinesisanalytics/latest/dev/limits.html)를 참조하십시오.
Amazon Kinesis Data Analytics 애플리케이션은 복수의 애플리케이션 내 입력 스트림을 지원하여 애플리케이션의 용량을 단일 애플리케이션 내 입력 스트림의 처리량 이상으로 확장할 수 있습니다. 애플리케이션 내 입력 스트림에 대한 자세한 설명은 [Amazon Kinesis Data Analytics for SQL 애플리케이션: 작동 방식](how-it-works.md) 섹션을 참조하십시오.
대부분의 경우 Amazon Kinesis Data Analytics는 애플리케이션에 피드되는 Kinesis 스트림 또는 Firehose 소스 스트림의 용량을 처리하도록 애플리케이션의 규모를 조정합니다. 그러나 소스 스트림의 처리량이 단일 애플리케이션 내 입력 스트림의 처리량을 초과하는 경우 애플리케이션이 사용하는 애플리케이션 내 입력 스트림의 수를 명시적으로 늘릴 수 있습니다. `InputParallelism` 파라미터를 사용하여 그렇게 합니다.
`InputParallelism` 파라미터가 1보다 클 경우 Amazon Kinesis Data Analytics는 소스 스트림의 파티션을 애플리케이션 내 스트림 간에 균등하게 분할합니다. 예를 들어, 소스 스트림의 샤드 수가 50개이고 `InputParallelism`을 `2`로 설정한 경우, 각각의 애플리케이션 내 입력 스트림은 25개의 소스 스트림 샤드로부터 입력을 수신합니다.
애플리케이션 내 수를 늘릴 경우 애플리케이션이 각 스트림에서 데이터에 명시적으로 액세스해야 합니다. 코드에서 복수의 애플리케이션 내 스트림에 액세스하는 것에 대한 정보는 [Amazon Kinesis Data Analytics 애플리케이션에서 별도의 애플리케이션 내 스트림에 액세스하는 방법](#input-parallelism-code-example) 을 참조하십시오.
Kinesis 데이터 스트림과 Firehose 샤드가 둘 다 동일한 방식으로 애플리케이션 내 스트림 간에 분할되지만, 애플리케이션에 표시되는 방식은 다릅니다.
+ Kinesis 데이터 스트림의 레코드에는 레코드의 소스 샤드를 식별하는 데 사용 가능한 `shard_id` 필드가 포함됩니다.
+ Firehose 전송 스트림의 레코드는 레코드의 소스 샤드 또는 파티션을 식별하는 필드를 포함하지 않습니다. Firehose가 이 정보를 애플리케이션에서 추상화하기 때문입니다.
## 애플리케이션 내 입력 스트림 수를 증대해야 할지 여부에 대한 평가
대부분의 경우 단일 애플리케이션 내 입력 스트림은 입력 스트림의 복잡성 및 데이터 크기에 따라 단일 소스 스트림의 처리량을 처리할 수 있습니다. Amazon CloudWatch에서 `InputBytes` 및 `MillisBehindLatest`의 지표를 모니터링하여 애플리케이션 내 입력 스트림의 증가 여부를 판단할 수 있습니다.
`InputBytes` 지표가 100MB/초보다 큰 경우 (또는 커질 것으로 예상하는 경우) `MillisBehindLatest`가 증가하고 애플리케이션 문제의 영향이 증가할 수 있습니다. 이를 해결하기 위해 애플리케이션에 대한 다음의 언어 선택을 권장합니다.
+ 100MB/초 이상으로 애플리케이션 규모 조정이 필요한 경우 복수의 스트림과 Kinesis Data Analytics for SQL 애플리케이션를 사용하십시오.
+ 단일 스트림과 애플리케이션을 사용하려는 경우 [Java 애플리케이션용 Kinesis Data Analytics](/managed-flink/latest/java/what-is.html)를 사용하십시오.
`MillisBehindLatest` 지표가 다음 특성 중 하나라도 가지고 있을 경우 애플리케이션의 `InputParallelism` 설정을 늘려야 합니다.
+ `MillisBehindLatest` 지표가 점진적으로 증가하여 애플리케이션이 스트림에서의 최신 데이터보다 뒤쳐지고 있음을 나타냅니다.
+ `MillisBehindLatest` 지표가 지속적으로 1000(1초)을 초과합니다.
다음에 해당하는 경우 애플리케이션의 `InputParallelism` 설정을 늘릴 필요가 없습니다.
+ `MillisBehindLatest` 지표가 점진적으로 감소하여 애플리케이션이 스트림에서의 최신 데이터를 따라잡고 있음을 나타냅니다.
+ `MillisBehindLatest` 지표가 1000(1초) 아래입니다.
CloudWatch에 대한 자세한 정보는 [Amazon CloudWatch 사용자 가이드](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)를 참조하십시오.
## 복수의 애플리케이션 내 입력 스트림 구현
애플리케이션을 생성할 때 [CreateApplication](API_CreateApplication.md)을 사용하여 애플리케이션 내 입력 스트림의 수를 설정할 수 있습니다. 애플리케이션을 생성한 후에 [UpdateApplication](API_UpdateApplication.md)을 사용하여 이 수를 설정합니다.
**참고**
Amazon Kinesis Data Analytics API 또는 AWS CLI를 사용해서만 `InputParallelism` 설정값을 설정할 수 있습니다. 를 사용하여이 설정을 설정할 수 없습니다 AWS Management Console. 설정에 대한 자세한 내용은 단원을 AWS CLI참조하십시오[2단계: AWS Command Line Interface (AWS CLI) 설정](setup-awscli.md).
### 새 애플리케이션의 입력 스트림 수 설정
다음 예는 `CreateApplication` API 작업을 사용하여 새 애플리케이션의 입력 스트림 수를 2로 설정하는 방법을 보여줍니다.
`CreateApplication`에 대한 자세한 정보는 [CreateApplication](API_CreateApplication.md) 섹션을 참조하세요.
```
{
"ApplicationCode": "",
"ApplicationDescription": "",
"ApplicationName": "",
"Inputs": [
{
"InputId": "ID for the new input stream",
"InputParallelism": {
"Count": 2
}],
"Outputs": [ ... ],
}]
}
```
### 기존 애플리케이션의 입력 스트림 수 설정
다음 예는 `UpdateApplication` API 작업을 사용하여 기존 애플리케이션의 입력 스트림 수를 2로 설정하는 방법을 보여 줍니다.
`Update_Application`에 대한 자세한 정보는 [UpdateApplication](API_UpdateApplication.md) 섹션을 참조하세요.
```
{
"InputUpdates": [
{
"InputId": "yourInputId",
"InputParallelismUpdate": {
"CountUpdate": 2
}
}
],
}
```
## Amazon Kinesis Data Analytics 애플리케이션에서 별도의 애플리케이션 내 스트림에 액세스하는 방법
애플리케이션에서 복수의 애플리케이션 내 입력 스트림을 사용하려면 각기 다른 스트림에서 명시적으로 선택해야 합니다. 다음의 코드 예는 시작하기 자습서에서 생성한 애플리케이션에서 복수의 입력 스트림을 쿼리하는 방법을 보여 줍니다.
다음 예에서는 각 소스 스트림은 [수](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-count.html)를 사용하여 우선 집계된 후 `in_application_stream001`라는 단일 애플리케이션 내 스트림으로 결합됩니다. 소스 스트림을 미리 집계하면 결합된 애플리케이션 내 스트림이 과부하 없이 복수의 스트림에서 발생하는 트래픽을 처리하는 데 도움이 됩니다.
**참고**
이 예를 실행하여 두 애플리케이션 내 입력 스트림으로부터 결과를 얻으려면 소스 스트림에 있는 샤드의 수와 애플리케이션의 `InputParallelism` 파라미터를 둘 다 업데이트합니다.
```
CREATE OR REPLACE STREAM in_application_stream_001 (
ticker VARCHAR(64),
ticker_count INTEGER
);
CREATE OR REPLACE PUMP pump001 AS
INSERT INTO in_application_stream_001
SELECT STREAM ticker_symbol, COUNT(ticker_symbol)
FROM source_sql_stream_001
GROUP BY STEP(source_sql_stream_001.rowtime BY INTERVAL '60' SECOND),
ticker_symbol;
CREATE OR REPLACE PUMP pump002 AS
INSERT INTO in_application_stream_001
SELECT STREAM ticker_symbol, COUNT(ticker_symbol)
FROM source_sql_stream_002
GROUP BY STEP(source_sql_stream_002.rowtime BY INTERVAL '60' SECOND),
ticker_symbol;
```
위의 코드 예는 다음과 비슷한 결과를 `in_application_stream001`에 출력합니다:
![\[Table showing ROWTIME, TICKER, and TICKER_COUNT columns with sample data entries.\]](http://docs.aws.amazon.com/ko_kr/kinesisanalytics/latest/dev/images/input-parallelism-results.png)
## 추가 고려 사항
복수의 입력 스트림을 사용하는 경우 다음에 유의해야 합니다.
+ 애플리케이션 내 입력 스트림의 최대 수는 64입니다.
+ 애플리케이션 내 입력 스트림은 애플리케이션 입력 스트림의 샤드 간에 균등하게 분배됩니다.
+ 애플리케이션 내 스트림 추가에 따른 성능상 이득은 선형적으로 증가하지 않습니다. 즉, 애플리케이션 내 스트림을 두 배로 늘린다고 처리량이 두 배가 되지는 않습니다. 행 크기가 일반적인 경우, 각 애플리케이션 내 스트림은 초당 약 5,000\$115,000개의 행을 처리할 수 있습니다. 애플리케이션 내 스트림 수를 10으로 늘리면 초당 20,000\$130,000 정도의 처리량을 확보할 수 있습니다. 처리 속도는 입력 스트림 필드의 수, 데이터 유형 및 데이터 크기에 좌우됩니다.
+ 일부 집계 함수(예: [AVG](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-avg.html))는 여러 샤드에 분할된 입력 스트림에 적용할 경우 예상치 못한 결과를 산출할 수 있습니다. 샤드를 집계 스트림에 결합하기 전에 개별 샤드에 대한 집계 작업을 실행해야 하기 때문에 결과를 레코드가 더 많이 포함된 것에 대해 가감해야 할 수 있습니다.
+ 입력 스트림 수를 늘린 후에도 계속해서 성능 저하가 일어나면 (`MillisBehindLatest`의 지표가 높게) Kinesis 처리 단위(KPU)의 한도에 이른 것일 수도 있습니다. 자세한 설명은 [처리량 증가를 위해 애플리케이션 용량을 자동으로 확장 또는 축소](how-it-works-autoscaling.md) 섹션을 참조하십시오.