DynamoDB와의 통합 모범 사례 - Amazon DynamoDB
스냅샷 생성변경 데이터 캡처OpenSearch Service와 제로 ETL 통합

DynamoDB와의 통합 모범 사례

DynamoDB를 다른 서비스와 통합할 때는 항상 각 서비스 사용에 대한 모범 사례를 따라야 합니다. 하지만 통합과 관련하여 고려해야 할 몇 가지 모범 사례가 있습니다.

DynamoDB에서 스냅샷 생성

  • 일반적으로 초기 복제를 위한 스냅샷을 생성할 때는 Amazon S3로 내보내기를 사용하는 것이 좋습니다. 둘 다 비용 효율적이며 처리량 측면에서 애플리케이션 트래픽과 경쟁하지 않습니다. 새 테이블에 백업 및 복원한 다음 스캔 작업을 수행하는 방법도 고려해 볼 수 있습니다. 이렇게 하면 애플리케이션과의 처리량 경쟁을 피할 수 있지만 일반적으로 내보내기보다 훨씬 덜 비용 효과적입니다.

  • 내보내기를 수행할 때는 항상 StartTime을 설정하세요. 이렇게 하면 변경 데이터 캡처(CDC)를 어디서 시작할지 쉽게 결정할 수 있습니다.

  • S3로 내보내기를 사용하는 경우 S3 버킷에 수명 주기 작업을 설정하세요. 일반적으로 만료 작업을 7일로 설정하는 것이 안전하지만 회사에서 지침을 제시한다면 따라야 합니다. 수집 후 명시적으로 항목을 삭제하더라도 이렇게 하면 문제를 포착하여 불필요한 비용을 줄이고 정책 위반을 예방할 수 있습니다.

DynamoDB에서의 변경 데이터 캡처

  • 실시간에 가까운 CDC가 필요한 경우 DynamoDB Streams 또는 Amazon Kinesis Data Streams(KDS)를 사용하세요. 어느 것을 사용할지 결정할 때는 일반적으로 다운스트림 서비스와 함께 사용하기 가장 쉬운 방법을 고려합니다. 파티션 키 수준에서 순서대로 이벤트를 처리해야 하거나 항목이 매우 큰 경우에는 DynamoDB Streams를 사용하세요.

  • 실시간에 가까운 CDC가 필요하지 않은 경우 증분 내보내기와 함께 Amazon S3로 내보내기를 사용하여 두 시점 사이에 발생한 변경 사항만 내보낼 수 있습니다.

    스냅샷을 생성할 때 S3로 내보내기를 사용한 경우 유사한 코드를 사용하여 증분 내보내기를 처리할 수 있으므로 이 방법이 특히 유용할 수 있습니다. 일반적으로 S3로 내보내기가 이전 스트리밍 옵션보다 약간 저렴하지만 보통 비용은 옵션 선택의 주요 요인이 아닙니다.

  • 일반적으로 DynamoDB 스트림의 동시 소비자는 두 명만 있을 수 있습니다. 통합 전략을 계획할 때 이 점을 고려하세요.

  • 스캔을 사용하여 변경 사항을 감지하지 마세요. 규모가 작을 때는 효과가 있을 수 있지만 곧 실용성이 떨어집니다.

OpenSearch Service와 DynamoDB의 제로 ETL 통합

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 함수입니다.