이 문서에서는 사용자가 Pub/Sub 주제를 구독하고 구독자 클라이언트에서 메시지를 수신하는 프로세스에 이미 익숙하다고 가정합니다.
Pub/Sub를 처음 사용하는 경우 빠른 시작 가이드 중 하나를 참조하고 콘솔, Google Cloud CLI, 클라이언트 라이브러리를 사용하여 Pub/Sub를 실행하는 방법을 알아보세요.
올바른 구독 선택
Pub/Sub는 push 및 pull 구독과 같은 표준 구독을 제공합니다. 표준 구독 외에도 Pub/Sub는 Dataflow를 중개자로 사용하지 않고도 메시지를Trusted Cloud by S3NS 리소스에 직접 저장할 수 있는 내보내기 구독도 제공합니다. 예를 들어 BigQuery 구독은 BigQuery 테이블에 메시지를 저장합니다.
push 구독은 다음과 같은 시나리오에서 권장됩니다.
클라이언트 라이브러리를 종속 항목으로 가져오는 코드를 구독자 애플리케이션에 포함할 수 없습니다.
구독자 클라이언트는 아웃바운드 요청을 할 수 없습니다.
구독자 클라이언트가 구독 목록을 모르는 상황에서 동일한 인스턴스를 사용하여 서로 다른 주제 및 구독의 메시지를 처리하려고 합니다.
일반적인 경우 상위 수준 클라이언트 라이브러리를 사용하는 것이 좋습니다. 단항 가져오기를 대신 사용하는 경우 returnImmediately을 true로 설정하지 마세요. true로 설정하면 풀 성능에 부정적인 영향을 미칩니다.
returnImmediately 필드가 이제 지원 중단됩니다.
모든 구독 유형을 비교하고 비즈니스 요구사항에 가장 적합한 유형을 선택하려면 Pub/Sub 구독 비교 표를 참고하세요.
내보내기 구독의 이점을 알아보려면 내보내기 구독을 사용해야 하는 경우를 참고하세요.
메시지를 확인하기 전에 처리
기본적으로 Pub/Sub는 메시지가 확인된 후 구독에서 메시지를 삭제합니다. 확인을 전송하기 전에 메시지를 처리하지 않고 처리가 실패하면 서비스에서 메시지를 다시 전송하지 않습니다. 단, 확인된 메시지 보관 또는 주제 보관을 구성한 후 탐색 작업을 실행하는 경우는 예외입니다.
지연 시간이 긴 구독자가 있는 경우 흐름 제어 및 임대 관리에 맞춤 값을 설정해야 할 수 있습니다.
일시적인 트래픽 급증에 대한 구독자 흐름 제어 구성
구독자 측의 흐름 제어를 사용하면 트래픽 급증으로 인해 구독자가 과부하되는 것을 방지할 수 있습니다. 자동 확장 메커니즘이 증가된 부하에 대응할 시간을 허용하거나 더 긴 기간에 걸쳐 부하 처리를 분산할 수 있습니다. 전자의 경우 지연 시간이 절약되고 후자의 경우 비용이 절약됩니다.
흐름 제어를 구성하려면 maximum outstanding messages 및 total outstanding message bytes에 적절한 값을 설정해야 합니다. 이러한 흐름 제어 변수의 기본값과 변수 이름은 클라이언트 라이브러리마다 다를 수 있습니다.
최대 미해결 메시지 수는 Pub/Sub에서 확인이나 부정 확인을 수신하지 못한 경우 클라이언트에 전송된 최대 메시지 수를 정의합니다.
총 미해결 메시지 바이트는 Pub/Sub에서 확인이나 부정 확인을 수신하지 못한 경우 클라이언트에 전송된 메시지의 최대 총 크기를 정의합니다.
이러한 옵션 중 하나의 한도가 초과되면 구독자 클라이언트에서 더 이상 메시지를 가져오지 않습니다. 이 동작은 이미 가져온 메시지가 확인되거나 부정적으로 확인될 때까지 계속됩니다. 이렇게 하면 처리량과 더 많은 구독자를 실행하는 데 관련된 비용 사이에 균형을 맞출 수 있습니다.
중복 전송 처리
기본적으로 Pub/Sub는 구독자에게 최소 1회 메시지 전송을 제공합니다. 즉, 확인된 메시지라도 여러 번 전송될 수 있습니다. 다음 섹션에서는 일반적인 재전송 시나리오를 해결하는 방법을 설명합니다.
많은 메시지의 일관된 재전송
항상 많은 메시지가 다시 전송되는 경우 구독자가 과부하 상태이거나 기한이 만료되기 전에 메시지를 확인하지 않는 것입니다.
풀 구독을 사용하는 경우 흐름 제어 값에 맞춤 값을 설정하거나 임대 관리를 사용하여 임대 연장 기간을 늘려야 할 수 있습니다.
푸시 구독을 사용하는 경우 확인 기한 설정을 늘려야 할 수 있습니다. 정상 구독을 유지하는 방법에 관한 권장사항을 따를 수도 있습니다.
메시지가 가끔 다시 전송됨
확인 기한이 지나기 전에 또는 메시지가 확인된 후 몇 초 이내에 메시지가 다시 전송되는 경우 Pub/Sub가 예상대로 작동하는 것입니다. 재전송 스파이크는 자주 발생하지 않지만 재전송이 발생하면 여러 메시지에서 동시에 발생할 가능성이 높습니다. 시스템은 이러한 가끔 발생하는 중복을 허용하도록 빌드되어야 합니다.
일부 메시지의 반복적인 재전송
메일이 여러 번 전송되는 경우가 소수라면 먼저 메일을 확인하고 있는지 확인하세요. 그렇지 않다면 구독자가 메시지를 제대로 처리하지 않는 이유를 파악하세요. 추가 재전송을 방지하기 위해 데드 레터 주제를 구성하는 것이 좋습니다. 메시지를 확인하는 경우 Pub/Sub가 여전히 예상대로 작동할 수 있습니다. 매우 드물지만 내부 네트워크 또는 하드웨어 중단이 있는 경우 소수의 메시지가 여러 번 전송될 수 있습니다. 이러한 경우 서비스에서 자체 복구를 시도하지만 해결 방법이 활성화되는 데 몇 분 정도 걸릴 수 있습니다.
시스템은 재전송을 허용해야 합니다. 메시지를 최대한 빨리 처리하고 확인하면 이러한 가능성을 줄일 수 있습니다.
애플리케이션에서 중복을 허용할 수 없는 경우 1회만 전송을 사용 설정하면 됩니다. 이 기능은 가져오기 구독에만 사용할 수 있으며 게시-구독 지연 시간이 길어집니다. 이 기능을 사용 설정하기 전에 지연 시간 증가라는 절충안이 사용 사례에 적합한지 평가하세요.
구독의 순서가 지정된 메시징 권장사항
메시지 순서를 사용하는 경우 다음 사항을 확인합니다.
StreamingPull 또는 Pull 구독을 선택합니다. push 구독의 경우 Pub/Sub는 각 순서 키에 대해 한 번에 하나의 미해결 메시지만 지원합니다. 이러한 시나리오에서 동시 push 요청을 보내는 것은 동일한 순서 키에 대해 여러 개의 메시지 배치를 동시에 보내 구독자를 동시에 가져오는 것과 유사합니다. 따라서 push 구독은 같은 순서 키로 여러 메시지가 자주 게시되거나 지연 시간이 매우 중요한 주제에는 권장되지 않습니다.
구독에서 메시지 순서를 사용 설정합니다. 게시자 측에서 순서 키를 사용하여 동일한 리전에서 메시지를 전송하는 경우 이러한 메시지를 순서대로 수신하도록 구독자를 구성할 수 있습니다. 구독자 측에서는 순서가 지정된 메시지를 수신하려는 구독에 대해서만 메시지 순서 속성을 사용 설정합니다. 속성 상태에 따라 주제에 연결된 각 구독은 서로 영향을 주지 않고 순서가 지정된 전송이 필요한지 확인할 수 있습니다.
메시지를 순서대로 확인합니다. 순서가 지정된 전송을 사용하는 경우 순서 키별로 이전 메시지에 대한 확인이 처리될 때까지 이후 메시지 확인이 처리되지 않습니다. 예를 들어 순서 키가 동일한 메시지 1, 2, 3이 있는데 메시지를 모두 수신하고 메시지 3만 확인한다면 이 서비스는 메시지 2, 3이 확인될 때까지 메시지 3을 확인한 것으로 간주하지 않습니다. 메시지 1과 2의 확인을 수신하지 않으면 메시지 1, 2, 3이 모두 다시 전송됩니다.
권장사항 요약
다음 표에서는 이 문서에 설명된 권장사항을 요약해서 보여줍니다.
| 주제 | 태스크 |
|---|---|
| 구독 유형 선택 | 비즈니스 요구사항에 맞는 구독 유형을 선택합니다. 구독에서 지원하는 경우 상위 수준 클라이언트 라이브러리도 사용합니다. |
| 확인된 메시지 재생 | 메시지를 확인하기 전에 처리합니다. 또는 확인된 메시지가 손실되지 않도록 탐색 작업을 위해 구성합니다. |
| 흐름 제어 | 자동 확장 기능이 시작되거나 시간이 지날 때까지 구독자가 과부하되지 않도록 구독자 설정에서 흐름 제어를 구성합니다. |
| 메시지 순서 지정 | 순서가 지정된 메시지를 사용할 때는 StreamingPull 또는 Pull을 선택하고, 구독에서 메시지 순서를 사용 설정하고, 메시지를 순서대로 확인합니다. |