Azure Cosmos DB에서 변경 피드 디자인 패턴
적용 대상: 
NoSQL
Azure Cosmos DB 변경 피드를 사용하면 쓰기량이 많은 큰 데이터 세트를 효율적으로 처리할 수 있습니다. 변경 피드는 또한 변경된 내용을 식별하기 위해 전체 데이터 세트를 쿼리하는 대안을 제공합니다. 이 문서에서는 일반적인 변경 피드 디자인 패턴, 디자인 장단점 및 변경 피드 제한 사항에 중점을 둡니다.
Azure Cosmos DB는 IoT, 게임, 소매 및 운영 로깅 애플리케이션에 적합합니다. 이러한 애플리케이션의 일반적인 디자인 패턴은 데이터 변경 내용을 사용하여 다른 작업을 트리거하는 것입니다. 이러한 작업의 예는 다음과 같습니다.
- 항목이 삽입되거나 업데이트되거나 삭제될 때 알림 또는 API 호출을 트리거합니다.
- IoT에 대한 실시간 스트림 처리 또는 운영 데이터에 대한 실시간 분석 처리
- 데이터 이동(예: 캐시, 검색 엔진, 데이터 웨어하우스 또는 콜드 스토리지와 동기화)
Azure Cosmos DB의 변경 피드를 사용하면 다음 그림과 같이 이러한 패턴 각각에 대해 효율적이고 확장 가능한 솔루션을 구축할 수 있습니다.
이벤트 컴퓨팅 및 알림
Azure Cosmos DB 변경 피드는 알림을 트리거하거나 특정 이벤트를 기반으로 API에 대한 호출을 전송해야 하는 시나리오를 간소화할 수 있습니다. 변경 피드 프로세스 라이브러리를 사용하여 변경 내용을 컨테이너에 자동으로 폴링한 다음, 쓰기, 업데이트 또는 삭제가 있을 때마다 외부 API를 호출할 수 있습니다.
특정 조건에 따라 알림을 선택적으로 트리거하거나 API에 대한 호출을 보낼 수도 있습니다. 예를 들어 Azure Functions를 사용하여 변경 피드에서 읽는 경우 조건이 충족되는 경우에만 알림을 보내는 논리를 함수에 넣을 수 있습니다. Azure Function 코드는 각 변경 내용에 대해 실행되지만 조건이 충족되는 경우에만 알림을 보냅니다.
실시간 스트림 처리
Azure Cosmos DB 변경 피드는 IoT에 대한 실시간 스트림 처리 또는 운영 데이터에 대한 실시간 분석 처리에 사용할 수 있습니다. 예를 들어 디바이스, 센서, 인프라 및 애플리케이션에서 이벤트 데이터를 받고 저장한 다음, Spark를 사용하여 이러한 이벤트를 실시간으로 처리할 수 있습니다. 다름 이미지에서는 Azure Cosmos DB 변경 피드를 사용하여 람다 아키텍처를 구현하는 방법을 보여줍니다.
스트림 처리 구현에서 먼저 많은 양의 들어오는 데이터를 Azure Event Hubs 또는 Apache Kafka와 같은 임시 메시지 큐로 받는 경우가 많습니다. 변경 피드는 Azure Cosmos DB의 기능으로 인해 짧은 읽기 및 쓰기 대기 시간을 보장하여 지속적인 높은 비율의 데이터 수집을 지원하는 좋은 대안입니다. 메시지 큐에 대한 Azure Cosmos DB 변경 피드의 이점은 다음과 같습니다.
데이터 지속성
Azure Cosmos DB에 기록된 데이터는 변경 피드에 표시됩니다. 최신 버전 모드를 사용하여 읽는 경우 데이터는 삭제될 때까지 변경 피드에 유지됩니다. 일반적으로 메시지 큐에는 최대 보존 기간이 있습니다. 예를 들어 Azure Event Hubs는 최대 90일간 데이터를 보존합니다.
쿼리 기능
Azure Cosmos DB 컨테이너의 변경 피드에서 읽는 것 외에도 Azure Cosmos DB에 저장된 데이터에 대해 SQL 쿼리를 실행할 수 있습니다. 변경 피드는 이미 컨테이너에 있는 데이터의 중복이 아니라 데이터를 읽는 다른 메커니즘일 뿐입니다. 따라서 변경 피드에서 데이터를 읽는 경우 데이터는 항상 동일한 Azure Cosmos DB 컨테이너의 쿼리와 일치합니다.
고가용성
Azure Cosmos DB는 최대 99.999% 읽기 및 쓰기 가용성을 제공합니다. 많은 메시지 큐와 달리 Azure Cosmos DB 데이터는 쉽게 전역적으로 배포하고 RTO(복구 시간 목표)를 0으로 구성할 수 있습니다.
변경 피드의 항목을 처리한 후에는 구체화된 뷰를 작성하고 집계된 값을 Azure Cosmos DB에 다시 유지할 수 있습니다. 예를 들어 Azure Cosmos DB를 사용하여 게임을 빌드하는 경우 변경 피드를 사용하여 완료된 게임의 점수에 따라 실시간 순위표를 구현할 수 있습니다.
데이터 이동
실시간 데이터 이동에 대한 변경 피드를 읽을 수도 있습니다.
예를 들어 변경 피드를 사용하여 다음 작업을 효율적으로 수행할 수 있습니다.
캐시, 검색 인덱스 또는 데이터 웨어하우스를 Azure Cosmos DB에 저장된 데이터로 업데이트합니다.
가동 중지 시간이 없는 마이그레이션을 다른 Azure Cosmos DB 계정 또는 다른 논리 파티션 키가 있는 다른 Azure Cosmos DB 컨테이너로 수행합니다.
애플리케이션 수준 데이터 계층화 및 보관을 구현합니다. 예를 들어 Azure Cosmos DB에 "핫 데이터"를 저장하고 만료된 "콜드 데이터"를 다른 스토리지 시스템(예: Azure Blob Storage)으로 내보낼 수 있습니다.
파티션 및 컨테이너 간에 데이터를 비정규화해야 하는 경우 이 데이터 복제의 원본으로 컨테이너의 변경 피드를 읽을 수 있습니다. 변경 피드를 사용하는 실시간 데이터 복제는 최종 일관성만 보장할 수 있습니다. Azure Cosmos DB 컨테이너의 변경 내용을 처리할 때 변경 피드 프로세서의 지연 정도를 모니터링할 수 있습니다.
이벤트 소싱
이벤트 소싱 패턴에는 추가 전용 저장소를 사용하여 해당 데이터에 대한 전체 작업을 기록하는 작업이 포함됩니다. Azure Cosmos DB 변경 피드는 모든 데이터 수집이 쓰기(업데이트 또는 삭제 없음)로 모델링되는 이벤트 소싱 아키텍처의 중앙 데이터 저장소로 선택하는 것이 좋습니다. 이 경우 Azure Cosmos DB에 대한 각 쓰기는 "이벤트"이므로 변경 피드의 과거 이벤트에 대한 전체 레코드가 있습니다. 중앙 이벤트 저장소에서 게시한 이벤트는 일반적으로 구체화된 뷰를 유지하거나 외부 시스템과 통합하는 데 사용됩니다. 변경 피드 최신 버전 모드에서는 보존 시간 제한이 없으므로 Azure Cosmos DB 컨테이너의 변경 피드 시작 부분부터 읽어 모든 과거 이벤트를 재생할 수 있습니다. 여러 변경 피드 소비자가 동일한 컨테이너의 변경 피드를 구독하도록 할 수도 있습니다.
Azure Cosmos DB는 가로 확장성 및 고가용성의 장점 때문에 이벤트 소싱 패턴에서 뛰어난 중앙의 추가 전용 영구 데이터 저장소입니다. 또한 변경 피드 프로세서는 "한 번 이상" 보증을 제공하여 이벤트 처리를 놓치지 않도록 합니다.
현재 제한 사항
변경 피드에는 각각 이해해야 하는 중요한 제한 사항이 있는 여러 모드가 있습니다. 최신 버전 모드 또는 모든 버전 및 삭제 모드에서 변경 피드를 사용하는 애플리케이션을 디자인하는 경우 고려해야 하는 몇 가지 영역이 있습니다.
중간 업데이트
최신 버전 모드에서는 특정 항목에 대한 가장 최근의 변경 내용만 변경 피드에 포함됩니다. 변경 내용을 처리하는 경우 사용 가능한 최신 항목 버전을 참조합니다. 동일한 항목에 대한 여러 업데이트가 짧은 기간 내에 있는 경우 중간 업데이트 처리를 놓칠 수 있습니다. 항목에 대한 과거 개별 업데이트를 재생하려면 이러한 업데이트를 일련의 쓰기로 대신 모델링하거나 모든 버전 및 삭제 모드를 사용할 수 있습니다.
삭제
변경 피드 최신 버전 모드는 삭제를 캡처하지 않습니다. 컨테이너에서 항목을 삭제하면 변경 피드에서도 제거됩니다. 삭제를 처리하는 가장 일반적인 방법은 소프트 마커를 삭제되는 항목에 추가하는 것입니다. deleted이라는 속성을 추가하고 삭제 시 true로 설정할 수 있습니다. 이 문서 업데이트는 변경 피드에 표시됩니다. 나중에 자동으로 삭제할 수 있도록 TTL(Time to Live)을 이 항목에 설정할 수 있습니다.
유지
최신 버전 모드의 변경 피드에는 무제한 보존이 있습니다. 항목이 컨테이너에 있는 한 변경 피드에서 사용할 수 있습니다.
보장된 순서
모든 변경 피드 모드에서 순서는 파티션 키 값 내에서 보장되지만, 파티션 키 값 전체에서는 순서가 보장되지 않습니다. 의미 있는 순서를 보장하는 파티션 키를 선택해야 합니다.
예를 들어 이벤트 소싱 디자인 패턴을 사용하는 소매 애플리케이션을 생각해 보세요. 이 애플리케이션에서 다양한 사용자 작업은 Azure Cosmos DB에 대한 쓰기로 모델링되는 각 "이벤트"입니다. 몇 가지 이벤트 예가 다음 순서로 발생했다고 생각해 보세요.
- 고객이 항목 A를 쇼핑 카트에 추가합니다.
- 고객이 항목 B를 쇼핑 카트에 추가합니다.
- 고객이 쇼핑 카트에서 항목 A를 제거합니다.
- 고객이 체크 아웃하고 쇼핑 카트 콘텐츠가 배송됩니다.
현재 쇼핑 카트 콘텐츠의 구체화된 뷰는 각 고객에 대해 유지 관리됩니다. 이 애플리케이션은 이러한 이벤트를 발생 순서대로 처리해야 합니다. 예를 들어 항목 A가 제거되기 전에 카트 체크 아웃을 처리해야 한다면 항목 A가 고객에게 배송되고 고객이 원한 항목 대신 항목 B가 배송되었을 가능성이 높습니다. 이러한 4개의 이벤트가 발생 순서대로 처리되도록 보장하려면 동일한 파티션 키 값 내에 속해야 합니다. username(각 고객에게 고유한 사용자 이름이 있음)을 파티션 키로 선택하면 이러한 이벤트가 Azure Cosmos DB에 기록된 것과 동일한 순서로 변경 피드에 표시되도록 보장할 수 있습니다.
예제
제공되는 샘플의 범위를 넘어 확장되는 최신 버전 모드에 대한 실제 변경 피드 코드의 몇 가지 예제는 다음과 같습니다.