Spanner 큐 개요

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

Spanner 대기열과 변경 내역 중에서 선택

다음 비교에서는 데이터 전파 및 비동기 처리에 적합한 메커니즘을 선택하는 방법을 안내합니다.

Spanner 큐

권장

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

주요 특징

  • 작은 사용자 정의 메시지 페이로드
  • 메시지 소비를 위한 풀 모델
  • Spanner 인스턴스 컴퓨팅으로 확장

Spanner 변경 내역

권장

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

주요 특징

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

주요 이점

Spanner 대기열은 다음과 같은 여러 이점을 제공합니다.

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

사용 사례

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

  • 컴퓨팅 집약적인 작업 연기: 사진 공유 웹사이트는 새 사진이 업로드될 때 집약적인 이미지 처리를 실행해야 할 수 있습니다. 새 사진 메타데이터를 쓰는 트랜잭션은 동시에 대기열 메시지를 쓸 수 있습니다. 나중에 큐 수신기가 메시지를 가져와서 처리를 실행하고 메타데이터를 트랜잭션 방식으로 업데이트합니다.
  • 대규모 트랜잭션 업데이트 지연: 캘린더 앱에서 단일 트랜잭션으로 대규모 그룹을 회의에 초대하면 잠금 충돌과 테일 지연 시간이 발생할 수 있습니다. 대신 캘린더 항목을 만드는 트랜잭션에서 각 초대 대상자의 대기열 항목을 추가하여 수신자가 초대를 개별적으로 보낼 수 있습니다.
  • 향후 작업 예약: 30일 무료 체험을 제공하는 서비스형 소프트웨어 (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회 전송을 보장합니다. 임대 기간을 연장하면 재전송을 완화할 수 있습니다.
  • 최대 한 번 확인: 메시지 확인은 트랜잭션을 통해 이루어지므로 Spanner ACID 시맨틱스는 메시지가 한 번만 확인되도록 보장합니다. 정확히 한 번 처리 및 최대 한 번 확인 페이지의 메서드에 따라 최대 한 번 확인을 올바르게 구현합니다.

제한사항

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

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

다음 단계