Spanner 큐 개요

Spanner 큐는 비동기 작업을 관리하는 데 도움이 되는 트랜잭션 메시징을 제공합니다. 이 기능은 이 기능을 Spanner의 확장성 및 안정성과 결합하여 이벤트 기반 애플리케이션을 빌드할 수 있게 해줍니다. Spanner 큐는 메시지 소비를 위해 가져오기 모델을 사용하여 수신자가 메시지를 요청하고 수신할 수 있는 SQL 인터페이스를 노출합니다.

Spanner 큐와 변경 내역 중에서 선택

다음 비교는 데이터 전파 및 비동기 처리에 적합한 메커니즘을 선택하는 데 도움이 됩니다.

Spanner 큐

권장

  • 거래 이벤트 알림
  • 향후 예약된 작업 실행
  • 메시지별 확인 로직

주요 특징

  • 사용자 정의 소형 메시지 페이로드
  • 메시지 소비를 위한 pull 모델
  • Spanner 인스턴스 컴퓨팅에 따라 확장

Spanner 변경 내역

권장

  • 높은 처리량의 데이터 복제
  • 다운스트림 캐시 또는 색인 동기화
  • 모든 데이터베이스 변경사항의 감사 로깅

주요 특징

  • 모든 레코드 프래그먼트 캡처 (최대 10MB)
  • 파티션 토큰을 사용한 가져오기 기반 스트리밍
  • 하트비트 및 체크포인트 포함

주요 이점

Spanner 큐는 다음과 같은 여러 이점을 제공합니다.

  • 통합: 메시징이 데이터베이스에 통합됩니다. 따라서 별도의 메시징 인프라를 프로비저닝, 관리, 데이터 무단 반출할 필요가 없으므로 애플리케이션 아키텍처가 간소화되고 전체 비용이 절감됩니다.
  • 트랜잭션: 다른 데이터베이스 쓰기와 함께 Spanner 트랜잭션 내에서 원자적으로 메시지를 전송하고 확인할 수 있습니다. 트랜잭션이 실패하면 큐에 추가된 메시지가 롤백되고 전송할 수 없습니다.
  • 지속성: 전송할 수 없는 메시지는 데이터베이스에 저장됩니다. Spanner는 메시지가 명시적으로 확인되거나 삭제될 때까지 백오프를 사용하여 전송을 계속 시도합니다.
  • 쿼리 가능: 메시지는 Spanner 테이블과 동일한 프리미티브를 기반으로 빌드되며 행으로 저장됩니다. 표준 테이블처럼 쿼리, 조인 또는 필터링할 수 있습니다.
  • 확장성: Spanner 테이블과 동일한 확장성으로 빌드되어 메시지 처리가 데이터베이스의 나머지 부분과 함께 확장됩니다.
  • 안정성: Spanner 큐는 Spanner의 모든 고가용성 프리미티브를 상속하므로 메시지 전송 및 처리가 내결함성을 갖추고 영역 또는 리전 장애에 대한 복원력이 우수합니다.
  • 예약 가능: 메시지를 나중에 전송하도록 예약할 수 있으므로 태스크 실행을 미래의 특정 타임스탬프로 연기할 수 있습니다.
  • 원자성: 메시지 전송 (INSERT 또는 변형 API) 및 확인(DELETE 또는 변형 API)은 트랜잭션 내에서 원자적으로 실행되어 데이터베이스 상태와의 일관성을 보장합니다.
  • 확장 가능: 메시지 임대는 향후 전송 및 수동 임대 메커니즘을 결합하여 매우 긴 처리 시간을 지원하도록 확장할 수 있습니다.

사용 사례

Spanner 큐는 트랜잭션 내에서 지연된 작업을 조정하는 데 유용합니다. 일반적인 예시는 다음과 같습니다.

  • 컴퓨팅 집약적인 작업 지연: 사진 공유 웹사이트에서 새 사진이 업로드될 때 집중적인 이미지 처리를 수행해야 할 수 있습니다. 새 사진 메타데이터를 쓰는 트랜잭션은 큐 메시지를 동시에 쓸 수 있습니다. 나중에 큐 수신자가 메시지를 선택하고 처리를 수행하며 트랜잭션 방식으로 메타데이터를 업데이트합니다.
  • 대규모 트랜잭션 업데이트 지연: 캘린더 앱에서 단일 트랜잭션으로 대규모 그룹을 회의에 초대하면 잠금 충돌 및 꼬리 지연 시간이 발생할 수 있습니다. 대신 캘린더 항목을 만드는 트랜잭션에서 각 초대 대상자에 대한 큐 항목을 추가하여 수신자가 초대를 개별적으로 전송할 수 있습니다.
  • 향후 태스크 예약: 30일 무료 체험판을 제공하는 Software as a Service (SaaS) 회사는 사용자의 리소스를 프로비저닝하고 동시에 30일 후에 전송되도록 예약된 메시지를 큐에 추가할 수 있습니다. 그러면 작업자가 메시지를 수신하고 무료 체험판 만료 로직을 실행합니다.
  • 외부 시스템으로 작업 지연: 사용자가 등록한 후 데이터베이스 등록이 성공한 경우에만 애플리케이션에서 환영 이메일을 보내야 할 수 있습니다. 등록 트랜잭션은 큐에 항목을 추가하여 작업자가 나중에 외부 이메일 API를 호출할 수 있도록 합니다.
  • 다단계 파이프라인 조정: 주문 관리 시스템에서 주문을 처리하려면 독립적으로 실패할 수 있는 여러 단계가 필요합니다. 각 단계를 큐 메시지로 표현하면 시스템에서 파이프라인 상태를 체크포인트로 지정하고 실패 지점부터 계속할 수 있습니다.

워크플로

Spanner 큐의 일반적인 워크플로는 다음 단계를 따릅니다.

  • 큐 만들기: 테이블과 유사하게 DDL을 사용하여 큐를 정의합니다. Payload 열 (PostgreSQL의 payload)과 기본 키를 포함해야 합니다.
  • 메시지 전송: 표준 DML (INSERT) 또는 변형 API를 사용하여 다른 데이터베이스 작업과 트랜잭션 방식으로 메시지를 큐에 추가합니다.
  • 메시지 수신: ExecuteStreamingSQL API를 사용하여 RECEIVE_QUEUE_NAME()라는 테이블 값 함수 (TVF)를 호출합니다. 이 함수는 메시지를 장기 실행 쿼리로 클라이언트에 스트리밍합니다.
  • 메시지 처리: 애플리케이션 로직을 사용하여 TVF에서 수신한 메시지를 사용합니다.
  • 메시지 확인: DML(DELETE) 또는 변형 API (예: ack)를 사용하여 큐에서 메시지를 삭제합니다. 일반적으로 처리가 완료된 후 트랜잭션 내에서 수행됩니다.
  • 리스 관리: 메시지 리스를 관리하여 Spanner 큐가 리스 제한 시간에 메시지를 다시 전송하지 않도록 합니다. 가장 일반적인 방법은 RENEWLEASE_QUEUE_NAME() TVF를 사용하는 것입니다.

또한 Spanner 큐의 다음과 같은 핵심 동작에 유의하세요.

  • 최소 1회 전송: 대부분의 클라우드 기반 큐 시스템과 마찬가지로 Spanner는 최소 1회 전송을 보장합니다. 임대를 연장하면 재전송을 완화할 수 있습니다.
  • 최대 1회 확인: 메시지 확인은 트랜잭션에서 발생하므로 Spanner ACID 시맨틱스는 메시지가 한 번만 확인되도록 보장합니다. 정확히 한 번 처리 및 최대 한 번 확인 페이지의 메서드에 따라 최대 한 번 확인을 올바르게 구현합니다.

제한사항

Spanner 큐에는 다음과 같은 제한사항이 있습니다.

  • 최대 수신자: 큐당 동일한 인수를 사용하는 활성 수신 쿼리는 1,000개로 제한됩니다.
  • 동시 수신 TVF 할당량 한도: 리전별 프로젝트당 동시 수신 TVF 2,000개의 할당량 한도가 있습니다. 할당량 한도를 늘리려면 Cloud Spanner 프로젝트의 할당량 상향 요청 양식을 작성하세요.
  • 수동 분할: AddSplits API는 큐에 지원되지 않습니다. 워크로드 분산은 전적으로 부하 기반 분할에 의존합니다. 사용자가 테이블에 분할 지점을 추가할 수 있도록 테이블에서 큐를 인터리브 처리하는 것이 좋습니다.
  • 지역 파티셔닝 규정 준수: 지역 파티셔닝된 큐는 DROP PARTITION 작업을 실행한 후 데이터 상주 규정을 준수하지 않습니다.
  • 큐 수 한도: 인스턴스는 노드가 1개 이상인 인스턴스의 경우 큐 100개로 제한됩니다. 한도는 세분화된 인스턴스에 비례하여 축소됩니다 (예: 처리 단위가 200개인 인스턴스는 큐 20개로 제한됨).
  • PostgreSQL 열 이름 지정: Spanner는 메시지 배송 기간에 대해 deliver_time 및 DeliverTime 열을 모두 노출합니다. 표준 PostgreSQL 명명 규칙에 맞추기 위해 deliver_time 열을 사용하는 것이 좋습니다. DeliverTime 열은 향후 출시 버전의 정보 스키마에서 숨겨집니다.
  • 이름이 지정된 스키마: 이름이 지정된 스키마에서는 큐를 만들 수 없습니다.

다음 단계