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

# Amazon OpenSearch Ingestion의 모범 사례
<a name="osis-best-practices"></a>

이 주제는 Amazon OpenSearch Ingestion 파이프라인 생성 및 관리에 대한 모범 사례를 제공하며, 많은 사용 사례에 적용되는 일반 지침을 포함하고 있습니다. 각 워크로드는 고유한 특성을 가지고 있으므로 모든 사용 사례에 적합한 일반적인 권장 사항은 없습니다.

**Topics**
+ [일반 모범 사례](#osis-best-practices-general)
+ [권장되는 CloudWatch 경보](#osis-cloudwatch-alarms)

## 일반 모범 사례
<a name="osis-best-practices-general"></a>

파이프라인 생성 및 관리에는 다음과 같은 일반적인 모범 사례가 적용됩니다.
+ 고가용성을 보장하려면 2개 또는 3개의 서브넷으로 VPC 파이프라인을 구성합니다. 하나의 서브넷에만 파이프라인을 배포하고 가용 영역이 다운되면 데이터를 수집할 수 없습니다.
+ 각 파이프라인 내에서 하위 파이프라인 수를 5개 이하로 제한하는 것이 좋습니다.
+ S3 소스 플러그인을 사용하는 경우 최적의 성능을 위해 균일한 크기의 S3 파일을 사용하세요.
+ S3 소스 플러그인을 사용하는 경우 최적의 성능을 위해 S3 버킷에서 파일 크기 0.25GB마다 가시성 제한 시간을 30초씩 추가하세요.
+ 실패한 이벤트를 오프로드하고 분석에 액세스할 수 있도록 파이프라인 구성에 [DLQ(Dead Letter Queue)](https://opensearch.org/docs/latest/data-prepper/pipelines/dlq/)를 포함시키세요. 잘못된 매핑이나 기타 문제로 인해 싱크에서 데이터가 거부되는 경우 문제를 해결하고 수정하기 위해 데이터를 DLQ로 라우팅할 수 있습니다.
+ 파이프라인에서 집계 프로세서를 사용하는 경우 파이프라인의 성능을 최적화하려면 `“local_mode: true”` 플래그를 사용하는 것이 좋습니다.

## 권장되는 CloudWatch 경보
<a name="osis-cloudwatch-alarms"></a>

CloudWatch 경보는 CloudWatch 지표가 일정 시간 동안 지정된 값을 초과하면 조치를 수행합니다. 예를 들어 클러스터 상태가 AWS 1분 이상 `red` 지속되면 이메일을 보낼 수 있습니다. 이 단원에는 Amazon OpenSearch Ingestion에 권장되는 몇 가지 경보와 이에 대응하는 방법이 포함되어 있습니다.

경보 구성에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.


| 경보 | 문제 | 
| --- | --- | 
| `computeUnits` 최대값은 15분, 연속 횟수 3번 동안 구성된 `maxUnits` 값임 | 파이프라인이 최대 용량에 도달했으며 maxUnits 업데이트가 필요할 수 있습니다. 파이프라인의 최대 용량을 늘리세요. | 
| `opensearch.documentErrors.count` 합계는 1분, 연속 횟수 1번 동안 = `{{{sub_pipeline_name}}}.opensearch.recordsIn.count`임 | 파이프라인이 OpenSearch 싱크에 쓸 수 없습니다. 파이프라인 권한을 확인하고 도메인이나 컬렉션이 정상인지 확인하세요. DLQ(Dead Letter Queue)에 실패한 이벤트가 있는지 확인할 수도 있습니다 (구성된 경우). | 
| `bulkRequestLatency.max` 최대값은 1분, 연속 횟수 1번 동안 >= *x*임 | 파이프라인이 OpenSearch 싱크로 데이터를 전송하는 데 지연이 많이 발생합니다. 이는 싱크 크기가 너무 작거나 샤딩 전략이 잘못되어 싱크가 뒤처지고 있기 때문일 수 있습니다. 지연 시간이 오래 지속되면 파이프라인 성능에 영향을 줄 수 있으며 클라이언트의 역압으로 이어질 수 있습니다. | 
| `httpAuthFailure.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | 수집 요청은 인증되지 않습니다. 모든 클라이언트에 서명 버전 4 인증이 올바르게 활성화되어 있는지 확인하세요. | 
| `system.cpu.usage.value` 평균값은 15분, 연속 횟수 3번 동안 >= 80%임 | 지속적으로 CPU 사용률이 높아지면 문제가 될 수 있습니다. 파이프라인의 최대 용량을 늘리는 것이 좋습니다. | 
| `bufferUsage.value` 평균값은 15분, 연속 횟수 3번 동안 >= 80%임 | 지속적으로 높은 버퍼 사용량은 문제가 될 수 있습니다. 파이프라인의 최대 용량을 늘리는 것이 좋습니다. | 

### 고려할 만한 기타 경보
<a name="osis-cw-alarms-additional"></a>

정기적으로 사용하는 Amazon OpenSearch Ingestion 기능에 따라 다음 경보 구성을 고려하세요.


| 경보 | 문제 | 
| --- | --- | 
| `dynamodb.exportJobFailure.count` 합계가 1 | Amazon S3로 내보내기를 트리거하는 시도가 실패했습니다. | 
| `opensearch.EndtoEndLatency.avg` 평균값은 15분, 연속 횟수 4번 동안 > X임 | EndtoEndLatency는 DynamoDB 스트림에서 읽을 때 필요한 값보다 높습니다. 이는 OpenSearch 클러스터의 규모가 작거나 최대 파이프라인 OCU 용량이 DynamoDB 테이블의 WCU 처리량에 비해 너무 낮기 때문일 수 있습니다. EndtoEndLatency는 내보내기 후에는 더 높지만 시간이 지나면 최근 DynamoDB 스트림을 따라잡기 때문에 감소할 것입니다. | 
| `dynamodb.changeEventsProcessed.count` 합계는 X분 동안 == 0임 | DynamoDB 스트림에서 수집되는 레코드가 없습니다. 테이블에 활동이 없거나 DynamoDB 스트림 액세스에 문제가 있을 수 있습니다. | 
| `opensearch.s3.dlqS3RecordsSuccess.count` 합계는 1분, 연속 횟수 1번 동안 >= `opensearch.documentSuccess.count`합계임 | OpenSearch 싱크보다 많은 수의 레코드가 DLQ로 전송되고 있습니다. OpenSearch 싱크 플러그인 지표를 검토하여 근본 원인을 조사하고 결정하세요. | 
| `grok.grokProcessingTimeouts.count` 합계는 = 1분, 연속 횟수 5번 동안 recordsIn.count 합계임 | Grok 프로세서가 패턴 매칭을 시도하는 동안 모든 데이터의 타임아웃이 발생했습니다. 이로 인해 성능이 저하되고 파이프라인 속도가 느려질 수 있습니다. 패턴을 조정하여 타임아웃을 줄이는 것을 고려해 보세요. | 
| `grok.grokProcessingErrors.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | Grok 프로세서가 파이프라인의 데이터와 패턴을 일치시키지 못해 오류가 발생했습니다. 데이터와 Grok 플러그인 구성을 검토하여 패턴 매칭이 예상되는지 확인하세요. | 
| `grok.grokProcessingMismatch.count` 합계는 = 1분, 연속 횟수 5번 동안 recordsIn.count 합계임 | Grok 프로세서가 파이프라인의 데이터와 패턴을 일치시키지 못했습니다. 데이터와 Grok 플러그인 구성을 검토하여 패턴 매칭이 예상되는지 확인하세요. | 
| `date.dateProcessingMatchFailure.count` 합계는 = 1분, 연속 횟수 5번 동안 recordsIn.count 합계임 | 날짜 프로세서가 파이프라인의 데이터에 어떤 패턴도 일치시킬 수 없습니다. 데이터와 날짜 플러그인 구성을 검토하여 패턴 매칭이 예상되는지 확인하세요. | 
| `s3.s3ObjectsFailed.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | 이 문제는 S3 객체가 없거나 파이프라인에 충분한 권한이 없기 때문에 발생합니다. s3ObjectsNotFound.count 및 s3ObjectsAccessDenied.count 지표를 검토하여 근본 원인을 파악하세요. S3 객체가 존재하는지 확인하거나 권한을 업데이트하세요. | 
| `s3.sqsMessagesFailed.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | S3 플러그인이 Amazon SQS 메시지를 처리하지 못했습니다. SQS 대기열에서 DLQ를 활성화한 경우 실패한 메시지를 검토하세요. 파이프라인이 처리하려는 잘못된 데이터를 대기열에 수신하고 있을 수 있습니다. | 
| `http.badRequests.count` 합계는 1분, 연속 횟수 3번 동안 >= 1임 | 클라이언트가 잘못된 요청을 보내고 있습니다. 모든 클라이언트가 적절한 페이로드를 보내고 있는지 확인하세요. | 
| `http.requestsTooLarge.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | HTTP 소스 플러그인의 요청에 너무 많은 데이터가 포함되어 있어 버퍼 용량을 초과합니다. 클라이언트의 배치 크기를 조정하세요. | 
| `http.internalServerError.count` 합계는 1분, 연속 횟수 1번 동안 >= 0임 | HTTP 소스 플러그인이 이벤트를 수신하는 데 문제가 있습니다. | 
| `http.requestTimeouts.count` 합계는 1분, 연속 횟수 1번 동안 >= 0임 | 소스 타임아웃은 파이프라인이 제대로 프로비저닝되지 않았기 때문일 수 있습니다. 추가 워크로드를 처리하기 위해 파이프라인 maxUnits(을)를 늘리는 것을 고려해 보세요. | 
| `otel_trace.badRequests.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | 클라이언트가 잘못된 요청을 보내고 있습니다. 모든 클라이언트가 적절한 페이로드를 보내고 있는지 확인하세요. | 
| `otel_trace.requestsTooLarge.count` 합계는 1분, 연속 횟수 1번 동안 >= 1임 | Otel Trace 소스 플러그인의 요청에 너무 많은 데이터가 포함되어 있어 버퍼 용량을 초과합니다. 클라이언트의 배치 크기를 조정하세요. | 
| `otel_trace.internalServerError.count` 합계는 1분, 연속 횟수 1번 동안 >= 0임 | Otel Trace 소스 플러그인이 이벤트를 수신하는 데 문제가 있습니다. | 
| `otel_trace.requestTimeouts.count` 합계는 1분, 연속 횟수 1번 동안 >= 0임 | 소스 타임아웃은 파이프라인이 제대로 프로비저닝되지 않았기 때문일 수 있습니다. 추가 워크로드를 처리하기 위해 파이프라인 maxUnits(을)를 늘리는 것을 고려해 보세요. | 
| `otel_metrics.requestTimeouts.count` 합계는 1분, 연속 횟수 1번 동안 >= 0임 | 소스 타임아웃은 파이프라인이 제대로 프로비저닝되지 않았기 때문일 수 있습니다. 추가 워크로드를 처리하기 위해 파이프라인 maxUnits(을)를 늘리는 것을 고려해 보세요. |