DynamoDB는 Amazon OpenSearch Service와 DynamoDB의 제로 ETL 통합을 제공합니다. 자세한 내용은 DynamoDB plugin for OpenSearch Ingestion과 Amazon OpenSearch Service의 구체적인 모범 사례를 참조하세요.
구성
-
검색을 수행해야 하는 데이터만 인덱싱하세요. 이를 구현하려면 항상 매핑 템플릿(
template_type: index_template및template_content)과include_keys를 사용하세요. -
로그를 모니터링하여 유형 충돌과 관련된 오류가 있는지 확인하세요. OpenSearch Service에서는 지정된 키의 모든 값이 같은 유형이어야 합니다. 불일치가 있는 경우 예외가 발생합니다. 이러한 오류 중 하나가 발생하는 경우 프로세서를 추가하여 지정된 키가 항상 같은 값인지 확인할 수 있습니다.
-
일반적으로
document_id값에는primary_key메타데이터 값을 사용하세요. OpenSearch Service에서 문서 ID는 DynamoDB의 프라이머리 키와 동일합니다. 프라이머리 키를 사용하면 문서를 쉽게 찾고 업데이트가 충돌 없이 일관되게 문서에 복제될 수 있습니다.도우미 함수
getMetadata를 사용하여 프라이머리 키(예:document_id: "${getMetadata('primary_key')}")를 가져올 수 있습니다. 복합 기본 키를 사용하는 경우 도우미 함수가 두 키를 자동으로 연결합니다. -
일반적으로
action설정에는opensearch_action메타데이터 값을 사용하세요. 이렇게 하면 OpenSearch Service의 데이터가 DynamoDB의 최신 상태와 일치하도록 업데이트가 복제됩니다.도우미 함수
getMetadata를 사용하여 프라이머리 키(예:action: "${getMetadata('opensearch_action')}")를 가져올 수 있습니다. 필터링과 같은 사용 사례에dynamodb_event_name을 통해 스트림 이벤트 유형을 가져올 수도 있습니다. 하지만 일반적으로action설정에는 사용하지 않는 것이 좋습니다.
관찰성
-
삭제된 이벤트를 처리하려면 OpenSearch 싱크에 항상 DLQ(Dead Letter Queue)를 사용하세요. DynamoDB는 일반적으로 OpenSearch Service보다 덜 구조화되어 있으며 예상치 못한 일이 발생할 가능성이 항상 있습니다. DLQ(Dead Letter Queue)를 사용하여 개별 이벤트를 복구하고 복구 프로세스를 자동화할 수 있습니다. 이렇게 하면 전체 인덱스를 다시 빌드할 필요가 없어집니다.
-
복제 지연이 예상한 시간을 초과하지 않도록 항상 알림을 설정하세요. 일반적으로 1분이 지나면 알림이 매우 시끄러워집니다. 이는 쓰기 트래픽이 얼마나 급증하는지와 파이프라인의 OpenSearch Compute Unit(OCU) 설정에 따라 달라질 수 있습니다.
복제 지연이 24시간을 초과하면 스트림에서 이벤트가 삭제되기 시작하고 인덱스를 처음부터 완전히 다시 빌드하지 않는 한 정확성 문제가 발생합니다.
스케일링
-
파이프라인에 Auto Scaling을 사용하면 워크로드에 가장 적합하도록 OCU를 스케일 업 또는 스케일 다운할 수 있습니다.
-
Auto Scaling을 사용하지 않는 프로비저닝된 처리량 테이블의 경우 쓰기 용량 단위(WCU)를 1,000으로 나눈 값을 기준으로 OCU를 설정하는 것이 좋습니다. 최소 OCU를 그 값보다 1개 적게 설정하고(최소 1개), 최대 OCU는 그 값보다 최소 1개 더 많게 설정합니다.
-
공식:
OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1) OCU_maximum = (table_WCU / 1000) + 1 -
예: 테이블에 2만 5,000개의 WCU가 프로비저닝되어 있습니다. 파이프라인의 OCU의 최솟값은 24(25,000/1,000 - 1), 최댓값은 최소 26(2,5000/1,000 + 1)으로 설정해야 합니다.
-
-
Auto Scaling을 사용하는 프로비저닝된 처리량 테이블의 경우 최소 및 최대 WCU를 1,000으로 나눈 값을 기준으로 OCU를 설정하는 것이 좋습니다. 최소 OCU를 DynamoDB의 최솟값보다 1개 적게 설정하고, 최대 OCU를 DynamoDB의 최댓값보다 최소 1개 더 많게 설정합니다.
-
공식:
OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1) OCU_maximum = (table_maximum_WCU / 1000) + 1 -
예: 테이블에 최소 8,000에서 최대 1만 4,000이라는 Auto Scaling 정책이 있습니다. 파이프라인의 OCU의 최솟값은 7(8,000/1,000 - 1), 최댓값은 최소 15(14,000/1,000 + 1)로 설정해야 합니다.
-
-
온디맨드 처리량 테이블의 경우 초당 쓰기 요청 유닛의 일반적인 급증 및 급락을 기준으로 OCU를 설정하는 것이 좋습니다. 사용 가능한 집계에 따라 더 긴 기간의 평균을 구해야 할 수도 있습니다. 최소 OCU를 DynamoDB의 최솟값보다 1개 적게 설정하고, 최대 OCU를 DynamoDB의 최댓값보다 최소 1개 더 많게 설정합니다.
-
공식:
# Assuming we have writes aggregated at the minute level OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1) OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1 -
예: 테이블의 평균 급락은 초당 쓰기 요청 유닛 300개, 평균 급증은 4,300입니다. 파이프라인의 OCU의 최솟값은 1(300/1,000 - 1, 그러나 최소 1개), 최댓값은 5(4,300/1,000 + 1)로 설정해야 합니다.
-
-
대상 OpenSearch Service 인덱스를 확장하는 모범 사례를 따르세요. 인덱스의 규모가 필요한 것보다 작으면 DynamoDB에서의 수집 속도가 느려지고 지연이 발생할 수 있습니다.
참고
GREATEST는 인수 집합이 주어지면 값이 가장 큰 인수를 반환하는 SQL 함수입니다.
