아키텍처 - Amazon Timestream

Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. 여기에서 자세히 알아보세요.

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

아키텍처

Amazon Timestream for Live Analytics는 대규모 시계열 데이터를 수집, 저장 및 처리하도록 처음부터 설계되었습니다. Amazon Timestream for Live Analytics의 서버리스 아키텍처는 독립적으로 규모를 조정할 수 있는 완전히 분리된 데이터 수집, 스토리지 및 쿼리 처리 시스템을 지원합니다. 이 설계는 각 하위 시스템을 단순화하여 굳건한 신뢰성을 형성하고, 확장성 병목 현상을 없애고, 상호 연관된 시스템 장애 발생 가능성을 줄이는 데 도움이 됩니다. 이러한 각 요소는 시스템이 규모가 조정됨에 따라 더 중요해집니다.

Timestream architecture diagram showing ingestion, storage, and query layers with AWS SDK interactions.

쓰기 아키텍처

시계열 데이터를 작성할 때 Amazon Timestream for Live Analytics는 높은 처리량의 데이터 쓰기를 처리하는 내결함성이 있는 메모리 스토어 인스턴스로 테이블과 파티션에 대한 쓰기 작업을 라우팅합니다. 그러면 메모리 스토어는 3개의 가용 영역(AZ)에 걸쳐 데이터를 복제하는 별도의 스토리지 시스템을 통해 내구성을 확보합니다. 복제는 쿼럼 기반으로 하므로 노드 손실이나 전체 AZ 손실이 발생하더라도 쓰기 가용성이 중단되지 않습니다. 쿼리를 처리하기 위해 다른 인 메모리 스토리지 노드는 거의 실시간으로 데이터와 동기화됩니다. 읽기 가용성을 높이기 위해 리더 복제 노드도 여러 AZ에 걸쳐 분산됩니다.

Timestream for Live Analytics는 처리량이 낮은 지연 도착 데이터를 생성하는 애플리케이션을 위해 데이터를 마그네틱 스토어에 직접 쓰는 기능을 지원합니다. 지연 도착 데이터는 현재 시간보다 이전 타임스탬프를 가진 데이터입니다. 메모리 스토어의 높은 처리량 쓰기와 마찬가지로 마그네틱 스토어에 작성되는 데이터는 3개의 AZ에 걸쳐 복제는 쿼럼을 기반으로 합니다.

데이터를 메모리 스토어에 쓰든 마그네틱 스토어에 쓰든 Timestream for Live Analytics는 데이터를 스토리지에 쓰기 전에 자동으로 인덱싱하고 파티셔닝합니다. Timestream for Live Analytics 테이블 하나에 수백, 수천 또는 수백만 개의 파티션이 있을 수 있습니다. 개별 파티션은 서로 직접 통신하지 않으며 어떠한 데이터도 공유하지 않습니다(아무 것도 공유하지 않는 아키텍처). 대신 테이블의 파티셔닝은 가용성이 높은 파티션 추적 및 인덱싱 서비스를 통해 추적됩니다. 이는 시스템 내 장애의 영향을 최소화하고 관련된 장애 발생 가능성을 크게 낮추기 위해 특별히 설계된 또 다른 관심사 분리를 제공합니다.

스토리지 아키텍처

Timestream for Live Analytics에 데이터가 저장될 때 데이터는 시간 순서대로 구성될 뿐만 아니라 데이터와 함께 작성된 컨텍스트 속성에 따라 시간별로 구성됩니다. 시계열 시스템을 대규모로 조정하려면 시간 외에도 ‘스페이스’를 나누는 파티셔닝 체계를 갖추는 것이 중요합니다. 이는 대부분의 시계열 데이터가 현재 시간 또는 그 전후로 작성되기 때문이다. 결과적으로 시간만으로 파티셔닝하는 것은 쓰기 트래픽을 효과적으로 분산시키거나 쿼리 시점에 데이터를 효율적으로 정리하는 데 적합하지 않습니다. 이는 초대형 시계열 처리에 중요하며, 이를 통해 Timestream for Live Analytics가 서버리스 방식으로 현재 시중 나와 있는 다른 주요 시스템보다 훨씬 더 높은 수준으로 규모를 조정할 수 있게 되었습니다. 결과 파티션은 2차원 스페이스(유사한 크기로 설계됨)의 분할을 나타내기 때문에 ‘타일’이라고 합니다. Timestream for Live Analytics 테이블은 단일 파티션(타일)으로 시작한 다음 처리량에 따라 공간 차원으로 파티셔닝됩니다. 타일이 특정 크기에 도달하면 데이터 크기가 증가함에 따라 더 나은 읽기 병렬 처리를 달성하기 위해 시간 차원으로 분할됩니다.

Timestream for Live Analytics는 시계열 데이터의 수명 주기를 자동으로 관리하도록 설계되었습니다. Timestream for Live Analytics는 인 메모리 스토어와 비용 효과적인 마그네틱 스토어라는 2개의 데이터 스토어를 제공합니다. 또한 스토어 간에 데이터를 자동으로 전송하도록 테이블 수준 정책 구성을 지원합니다. 수신되는 높은 처리량의 데이터 쓰기는 메모리 스토어에 저장되며, 여기서 데이터는 쓰기 작업뿐만 아니라 대시보드 구동 및 알림 유형 쿼리를 위한 현재 시간 전후의 읽기 작업에 최적화됩니다. 쓰기, 알림 및 대시보드 작업 요구 사항에 대한 기본 기간이 지나면 메모리 스토어에서 마그네틱 스토어로 데이터가 자동으로 이동하여 비용을 최적화할 수 있습니다. Timestream for Live Analytics를 사용하면 이러한 목적으로 메모리 스토어에 데이터 보존 정책을 설정할 수 있습니다. 지연 도착 데이터에 대한 데이터 쓰기는 마그네틱 스토어에 직접 작성됩니다.

마그네틱 스토어에서 데이터를 사용할 수 있게 되면(메모리 스토어 보존 기간 만료 또는 마그네틱 스토어에 직접 쓰기 작업으로 인해) 대용량 데이터 읽기에 매우 최적화된 형식으로 데이터가 재구성됩니다. 마그네틱 스토어에는 데이터가 유용성을 능가하는 시간 임곗값이 있는 경우 구성할 수 있는 데이터 보존 정책도 있습니다. 마그네틱 스토어 보존 정책에 대해 정의된 시간 범위를 초과하는 데이터는 자동으로 제거됩니다. 따라서 Timestream for Live Analytics를 사용하면 일부 구성만 거치면 데이터 수명 주기 관리가 백그라운드에서 원활하게 이루어집니다.

쿼리 아키텍처

Timestream for Live Analytics 쿼리는 시계열별 지원(시계열별 데이터 유형 및 함수)을 위한 확장이 포함된 SQL 문법으로 표현되므로, SQL에 이미 익숙한 개발자라면 쉽게 배울 수 있습니다. 그런 다음 쿼리는 타일 추적 및 인덱싱 서비스의 메타데이터를 사용하여 쿼리 실행 시점에 데이터 스토어 전반의 데이터에 원활하게 액세스하고 결합하는 적응형 분산 쿼리 엔진에 의해 처리됩니다. 이러한 방식은 간단한 작업을 불필요할 정도로 복잡하게 수행하는 많은 과정을 단순하고 친숙한 데이터베이스 추상화로 축소하여 고객에게 직관적인 경험을 제공합니다.

쿼리는 특정 쿼리를 실행하도록 등록된 워커 수가 쿼리 복잡성과 데이터 크기에 따라 결정되는 전용 워커 플릿에 의해 실행됩니다. 대규모 데이터세트에 대한 복잡한 쿼리의 성능은 쿼리 런타임 플릿과 시스템의 스토리지 플릿 모두에서 대규모 병렬 처리를 통해 달성됩니다. 대량의 데이터를 빠르고 효율적으로 분석하는 기능은 Timestream for Live Analytics의 가장 큰 장점 중 하나입니다. 수 테라바이트 또는 페타바이트에 달하는 데이터를 처리하는 단일 쿼리에는 수천 대의 컴퓨터가 동시에 동원될 수 있습니다.

셀룰러 아키텍처

Timestream for Live Analytics는 애플리케이션에 사실상 무한한 확장성을 제공하는 동시에 99.99%의 가용성을 보장하기 위해 셀룰러 아키텍처를 사용하여 설계되었습니다. 시스템 규모를 전체적으로 조정하는 대신 Timestream for Live Analytics는 이라는 여러 개의 더 작은 복제본으로 분할됩니다. 이렇게 하면 셀을 전체 규모로 테스트할 수 있으며 한 셀의 시스템 문제가 특정 리전의 다른 셀 활동에 영향을 미치지 않습니다. Timestream for Live Analytics는 리전당 여러 셀을 지원하도록 설계되었지만 한 리전에 2개의 셀이 있는 다음과 같은 가상 시나리오를 고려해 보세요.

Timestream architecture diagram showing ingestion, storage, and query layers for two cellular endpoints.

위의 시나리오에서 데이터 수집 요청과 쿼리 요청은 각각 데이터 수집과 쿼리를 위해 검색 엔드포인트에서 먼저 처리됩니다. 그런 다음 검색 엔드포인트는 고객 데이터가 포함된 셀을 식별하고 요청을 해당 셀에 대한 적절한 수집 또는 쿼리 엔드포인트로 보냅니다. SDK를 사용하면 이러한 엔드포인트 관리 태스크가 투명하게 처리됩니다.

참고

Timestream for LiveAnalytics와 함께 VPC 엔드포인트를 사용하거나 Timestream for LiveAnalytics의 REST API 작업에 직접 액세스하는 경우 셀룰러 엔드포인트와 직접 상호 작용해야 합니다. 이를 수행하는 방법에 대한 안내는 VPC 엔드포인트 설정 방법에 대한 지침은 VPC 엔드포인트를 참조하고, REST API 작업의 직접 호출 방법에 대한 지침은 엔드포인트 검색 패턴을 참조하세요.