이 가이드에서는 Pub/Sub 안정성 기능을 이해하고 전체적으로 파악할 수 있습니다. 이 문서에서 다루는 주제는 다음과 같습니다.
- Pub/Sub를 사용해야 하는 이유
- 장애 조치
- 게시자 미세 조정
- 구독자 미세 조정
- 안전한 배포를 위한 스냅샷 및 탐색 사용
Pub/Sub를 사용해야 하는 이유
메시지 패러다임인 게시-구독은 메시지 제작자와 메시지 소비자를 분리하도록 설계되었습니다. 제작자가 데이터와 함께 요청을 직접 소비자에게 전송하는 대신 Pub/Sub와 같은 Pub/Sub 서비스에 데이터를 게시합니다. 이 서비스는 구독했고 관심을 보인 소비자에게 비동기식으로 메시지를 전달합니다.
서비스가 데이터에 관심이 있는 소비자를 찾는 모든 복잡한 과정을 처리해 줍니다. 이 서비스는 또한 용량에 따라 소비자가 데이터를 수신하는 속도를 관리합니다. 분리 덕분에 데이터 제작자가 소비자의 동작과 관계없이 짧은 지연 시간으로 메시지를 대규모로 작성할 수 있습니다.
Pub/Sub는 확장성과 안정성이 뛰어난 메시지 전송을 제공합니다. 이 서비스는 대부분의 과정을 자동으로 처리해 주지만 사용자가 가용성과 성능에 영향을 줄 수 있는 게시자와 구독자의 여러 측면을 제어할 수 있습니다. 이 가이드의 나머지 부분에서는 이러한 측면에 대해 자세히 설명합니다.
장애 조치
Pub/Sub는 전역 서비스입니다. 주제 및 구독이 기본적으로 특정 리전에 연결되지 않으며, 필요에 따라 리전 간 Pub/Sub 서비스 내에서 메시지를 전달합니다. 전역 엔드포인트인 pubsub.googleapis.com을 사용하면 Pub/Sub가 실행되는 네트워크에서 가장 가까운 리전에 게시자와 구독자가 연결됩니다. us-central1-pubsub.googleapis.com과 같은 위치별 엔드포인트를 사용하면 게시자와 구독자가 지정된 리전의 Pub/Sub에 연결합니다. Google Cloud 외부에서 게시자 또는 구독자를 실행할 때는 예상되는 리전 간에 메시지가 일관적으로 전달되도록 위치별 엔드포인트를 사용하는 것이 가장 좋습니다. 이 섹션의 나머지 부분에서는 주제와 구독을 만드는 방법에 대해 다룹니다. 또한 다양한 종류의 장애 조치와 데이터 중복을 지원하기 위해 게시자와 구독자를 배치하는 방법도 설명합니다.
기본 장애 조치 시맨틱스
단일 주제와 구독이 있는 사례를 가정해 보겠습니다. 게시자는 미국 및 오스트레일리아에 위치하고 구독자는 유럽 및 오스트레일리아의 Google Cloud 리전에 위치합니다. 모든 구독자에게 메시지를 수신하기에 충분한 용량이 있는 경우 메시지 흐름은 다음과 같습니다.
P는 게시자, S는 구독자를 나타냅니다. 파란색 육각형은 Pub/Sub 서비스를 나타냅니다. 원통은 메시지가 저장되는 위치를 나타냅니다(메시지는 항상 게시된 리전의 여러 영역에 유지됨). Pub/Sub는 구독자를 사용할 수 있을 때 메시지가 게시된 리전과 동일한 리전 내에서 메시지를 전송하는 것을 선호합니다. 그렇지 않은 경우 용량이 있는 구독자와 가장 가까운 네트워크 리전으로 메시지를 전송합니다. 따라서 이전 이미지에 표시된 것처럼 미국에 게시된 메시지는 유럽의 구독자에게 전달되고 오스트레일리아 내에 게시된 메시지는 오스트레일리아에 유지됩니다.
다음 섹션에서는 다양한 장애 시나리오에서 발생하는 상황을 설명합니다.
유럽의 구독자를 사용할 수 없음
유럽의 구독자가 중단되거나 비정상 종료가 자주 발생하여 Pub/Sub 연결을 유지할 수 없다고 가정해 보겠습니다. 이러한 경우 서비스가 오스트레일리아의 구독자에게 메시지를 전달하기 시작합니다.
유럽 및 오스트레일리아의 구독자를 사용할 수 없음
모든 구독자를 사용할 수 없는 경우 Pub/Sub는 구성된 메시지 보관 기간까지 메시지를 저장합니다.
구독자가 다시 연결되면 서비스 중단이 구성된 메시지 보관 기간보다 오래 지속되지 않는 한 메시지가 전송됩니다. 기본적으로 구독 메시지 보관은 7일로 설정됩니다. 최대 31일 동안 주제의 메시지 보관을 구성할 수도 있습니다. 예상되거나 허용할 최대 중단 시간보다 짧은 메시지 보관 기간을 선택하지 마세요.
유럽에서 Pub/Sub를 사용할 수 없음
드물긴 하지만 Pub/Sub 자체를 사용할 수 없는 사례를 처리해야 할 수 있습니다. Pub/Sub를 사용할 수 없으면 게시 또는 구독 요청에서 예상치 못한 오류가 장시간 발생하거나 게시된 메시지를 구독자에게 전달할 수 없습니다. 예를 들어 Pub/Sub가 유럽 리전 내에서 중지된 경우의 시나리오는 구독자가 중지되었을 때와 거의 유사합니다.
이 경우 유럽의 구독자가 전역 엔드포인트를 사용하더라도 다른 리전으로 장애 조치되지 않습니다. 의도적으로 Pub/Sub에서 장애 조치를 자동으로 수행하지 않습니다. 구독자로 인해 Pub/Sub에서 예기치 않은 문제가 발생하여 서비스를 사용할 수 없게 되었다고 가정해 보겠습니다. 이러한 문제는 심각한 서비스 중단으로 취급됩니다. 그러나 서비스 중단이 영향을 미치는 범위가 구독자가 연결된 리전에 포함될 수 있습니다. 서비스가 다른 리전으로 장애 조치하도록 허용하더라도 구독자로 인해 서비스를 사용할 수 없게 되어 서비스에서 연쇄 장애가 발생할 수 있습니다.
오스트레일리아의 게시자를 사용할 수 없음
한 리전의 게시자를 사용할 수 없게 되더라도 이미 게시된 메시지가 가장 가까운 구독자에게 계속 전송됩니다.
결국 모든 메시지가 소비되고 구독자에 의해 확인됩니다. 메시지를 전송할 때 Pub/Sub는 네트워크 거리를 최소화하려고 시도합니다. 따라서 유럽의 구독자에게 미국에 게시된 모든 메시지를 처리하기에 충분한 용량이 있으면 오스트레일리아의 리전 구독자가 메시지 수신을 중지할 수 있습니다.
미국에서 Pub/Sub를 사용할 수 없음
Pub/Sub는 한 리전의 여러 영역에 메시지를 동기식으로 작성합니다. 따라서 영역 서비스 중단만으로는 메시지 전송이 중단되지 않습니다. 전체 리전을 사용할 수 없어야 전송되지 않습니다. 게시자가 메시지를 전송하는 리전에서 Cloud Pub/Sub를 사용할 수 없게 되면 서비스가 완전히 복원될 때까지 해당 리전의 메시지가 전송되지 않을 수 있습니다.
메시지 보관 기간이 지나지 않았다고 가정할 경우 서비스 중단 기간만큼 지연되지만 결과적으로 메시지가 계속 전송됩니다. 구독자와 마찬가지로 미국 내 게시자도 서비스가 실패할 때 다른 리전으로 장애 조치하지 않습니다. 이 동작은 게시자 또는 구독자의 오류로 인해 리전에서 연쇄 장애가 발생할 가능성을 막는 데 도움이 됩니다.
격리
기본 장애 조치 시맨틱스는 데이터 격리와 게시자, 구독자 또는 Pub/Sub를 사용할 수 없을 때의 메시지 전달에 영향을 미칩니다. 사용 사례에 따라 다른 격리 수준을 요구할 수 있습니다. 예를 들어 모든 메시지의 리전 내 전송이 필요할 수 있습니다.
격리를 원하지 않으면 기본 장애 조치 시맨틱스로 충분합니다. 단일 주제 및 단일 구독을 만들고 선택한 모든 리전에 게시자 및 구독자를 배치해야 합니다. 구독자가 사용할 수 없게 되거나 연결된 리전에서 Pub/Sub가 중지되면 다른 리전의 구독자로 전송이 장애 조치됩니다.
데이터가 리전을 벗어나지 않도록 보장하는 리전 격리의 경우 각 리전에서 메시지를 처리할 주제 및 구독을 만듭니다. 각 리전에서 게시자와 구독자를 찾아 해당하는 리전별 주제 및 구독을 각각 게시하고 구독하도록 합니다. 또한 리전 엔드포인트를 사용해 리전 내에서만 데이터가 이동하게 해야 합니다. 단일 리전에서 게시자, 구독자, Pub/Sub 오류가 발생할 경우 해당 리전에서 메시지 전송이 중지됩니다. 다른 리전의 주제 및 구독에 대한 메시지 전송은 영향을 받지 않습니다.
마지막으로 데이터가 단일 영역 내에 유지되도록 보장하는 영역 격리는 Pub/Sub에서 사용할 수 없습니다. 개별 영역이 독립적이어야 한다면 Pub/Sub 라이트를 사용합니다.
고객 제어형 장애 조치 및 중복
Pub/Sub의 기본 장애 조치 시맨틱스는 게시자와 구독자 사이의 어느 지점에서든 서비스 중단이 발생할 경우 메시지가 항상 게시자에서 구독자로 전송되도록 완전히 보장하지는 못합니다. 서비스 중단은 클라이언트를 포함한 여러 위치, 게시자 또는 구독자가 실행되는 서비스, 네트워크 또는 Pub/Sub 자체에서도 발생할 수 있습니다. 이러한 서비스 중단에 대한 서비스 복원력이 우수해야 하는 경우 자체 중복을 구현해야 합니다. 중복을 위해서는 일반적으로 각각 서로 다른 위치별 엔드포인트를 사용하는 게시자 및 구독자 클라이언트의 여러 인스턴스가 사용됩니다.
서로 다른 두 영향 범위(영역 또는 리전)에 복원력이 필요할 수 있습니다. 각 항목의 설정 옵션은 다음과 같습니다.
영역 복원력
Pub/Sub는 교차 영역 복제를 기본 제공합니다. 서비스 자체에 영향을 미치는 단일 영역 서비스 중단을 처리하기 위해 특별히 조치를 취할 필요가 없습니다. 하지만 클라이언트 또는 네트워크의 서비스 중단에 대한 복원력을 확보하려면 리전 내 여러 영역에서 충분한 용량을 가진 게시자와 구독자를 실행하는 것이 가장 좋습니다. 단일 영역이 중지되면 다른 영역의 클라이언트에서 트래픽을 선택하여 메시지를 처리할 수 있습니다. 버그가 발생할 경우 영향을 받지 않는 다른 영역에서 메시지를 계속 처리할 수 있도록 해당 클라이언트에 변경사항을 동시에 게시하지 않는 것이 좋습니다.
리전 복원력
리전 장애에 대해 복원력이 우수하려면 게시자와 구독자에 추가 중복을 설정합니다. 여러 리전에서 게시자와 구독자를 실행하면 해당 클라이언트 또는 네트워킹에서 발생 가능한 서비스 중단을 해결할 수 있습니다.
한 리전에서 잠재적인 Pub/Sub 장애에 대해 복원력이 우수하려면 이러한 서비스 중단을 처리할 수 있는 장애 조치 메커니즘이 있어야 합니다. 가능한 접근 방식은 엔드 투 엔드 메시지 전송 지연 시간과 비용을 절충하는 것입니다.
비용이 중요하지 않은 경우 지연 시간을 최소화하려면 항상 다른 리전에서 동시에 게시하고 구독하는 것이 가장 좋습니다. 먼저 중복을 원하는 리전의 수를 선택합니다. 꼭 필요한 것은 아니지만 리전마다 주제와 구독을 설정할 수 있습니다.
각 게시자는 리전 수만큼 게시자 클라이언트(리전당 하나씩)를 만들고 다른 위치별 엔드포인트를 사용하여 메시지가 다른 리전으로 전달되도록 합니다. 별도의 주제를 사용하는 경우 각 게시자 클라이언트가 해당 리전별 주제에 게시해야 합니다. 모든 메시지에 대해 게시자는 각 클라이언트에 게시를 호출합니다. 중복 게시를 사용하면 게시 중 하나가 실패해도 게시를 재시도할 필요가 없습니다.
마찬가지로 각 구독자는 리전당 하나씩 여러 구독자 클라이언트를 만들고 위치별 엔드포인트를 사용하여 다른 리전에 연결합니다. 리전마다 다른 구독을 사용하는 경우 각 구독자 클라이언트가 해당하는 구독을 사용해야 합니다. 게시자 및 구독자에 사용되는 리전이 반드시 동일할 필요는 없습니다. 구독자는 3개의 구독에서 메시지를 수신하고 처리합니다.
이 설정에는 몇 가지 주요 기능과 요구사항이 있습니다.
- 단일 리전 서비스 중단은 이미 게시된 메시지 또는 서비스 중단 중에 게시된 메시지에 영향을 주지 않습니다. 메시지가 여러 리전에 게시되었으므로 리전 하나가 중지되어도 다른 리전에서 메시지를 계속 사용할 수 있습니다. 서비스 중단 중에 영향을 받은 리전에서 게시 호출이 실패하지만 나머지 리전에서는 호출에 성공합니다.
- 메시지가 전달되는 리전을 사용할 수 있는 한 메시지 처리 지연 시간이 영향을 받지 않습니다.
- 메시지 처리는 멱등적이어야 합니다. 모든 메시지가 여러 번 전송되므로 메시지 처리에 중복에 대한 복원력이 우수해야 합니다. 리전 서비스 중단이 발생하면 이러한 중복 중 일부가 메시지가 처음 전송된 시점보다 훨씬 늦게 발생할 수 있습니다. 이러한 중복은 서비스 중단이 발생하지 않은 다른 리전에서 발생할 가능성이 높습니다.
이러한 유형의 중복으로 실행하면 모든 유형의 서비스 중단에 가장 높은 복원력이 제공됩니다. Pub/Sub를 사용하고 가장 높은 가용성이 필요한 내부 Google 서비스의 경우 이 설정을 사용하는 것이 좋습니다. 하지만 이 설정은 메시지 전송 비용과 사용된 리전 수를 곱하여 요금을 구하기 때문에 비용이 크다는 단점이 있습니다. 리전 간에 이동해야 하는 메시지에는 리전 간 네트워크 사용량이란 추가 비용도 발생합니다.
또 다른 중복 방법은 요청이 실패하거나 메시지가 게시자에서 예상대로 구독자로 전달되지 않는 경우에만 장애 조치를 수행하는 것입니다. 이 시나리오에는 위치별 엔드포인트를 통해 게시자와 구독자를 연결하는 기본 리전이 있습니다. 이전과 마찬가지로 동일 리전일 필요는 없습니다. 또한 기본 리전을 사용할 수 없을 때 사용되는 게시자 및 구독자의 대체 리전이 있습니다.
게시자는 요청이 성공적으로 전송된 경우 위치별 엔드포인트를 통해 기본 리전에만 게시합니다. 리전이 중지된 것으로 확인될 때마다 게시자가 대신 대체 리전에 게시하기 시작합니다. 두 가지 방법으로 리전 중지를 확인하고 장애 조치를 수행할 수 있습니다. 이 작업은 수동 프로세스 및 게시자에서 동적으로 업데이트되는 구성을 통해 수행할 수 있습니다. 또한 게시 요청의 오류율이 충분히 높으면 게시자가 구성을 직접 업데이트할 수 있습니다.
구독자는 항상 위치별 엔드포인트를 통해 기본 리전에 연결해야 합니다. 다음 트리거 중 하나 이상을 사용하여 구독자가 대체 리전을 사용할 수 있도록 결정할 수 있습니다.
- 항상 대체 리전을 구독합니다. 이 경우 구독자는 항상 기본 리전과 대체 리전 모두에 대한 연결을 유지합니다. 동일한 리전을 게시자 및 구독자 모두의 기본 및 대체 리전으로 사용할 수 있습니다. 이 경우 게시자가 장애 조치한 경우에만 구독자가 백업 리전을 통해 메시지를 수신해야 합니다.
- 구성을 통해 구독자를 수동으로 감지하고 대체 리전으로 전환합니다. 서비스 중단이 감지되면 대체 리전으로 장애 조치한 후 서비스 중단이 완화되었을 때 기본 리전으로 다시 전환할 수 있습니다.
- 구독자 오류를 장애 조치합니다. 구독자 요청이 오류를 반환하는 경우 대체 리전으로 장애 조치해야 한다는 의미로 이를 사용할 수 있습니다. Pub/Sub 클라이언트 라이브러리는 일시적인 오류에 대해 내부적으로 스트리밍 pull 요청을 재시도하므로 장시간 지속되는 예기치 않은 오류를 감지하지 못할 수 있습니다. 또한 정상 작동 중에도 스트리밍 가져오기 오류율이 100%로 예상됩니다.
- 구독자가 메시지를 수신하지 않은 채 예기치 않게 오랜 시간이 지난 경우 장애 조치합니다. 메시지 게시가 일관적이라고 가정할 경우 구독자는 항상 메시지를 수신할 수 있습니다. 메시지를 수신하지 않은 채 오랜 시간이 지나면 기본 리전의 Pub/Sub에 구독 측 문제가 발생한 것일 수 있습니다. 이 문제는 대체 리전으로 장애 조치하면 해결됩니다.
네 가지 옵션 중에서 첫 번째 옵션이 이상적입니다. 메시지가 전달되지 않으면 구독자 연결에서 비용이 발생하지 않습니다. 구독자 클라이언트 라이브러리의 추가 인스턴스를 사용할 때 발생하는 소액의 요금이 전부입니다. 또한 리전별 열려 있는 스트리밍 가져오기 연결 수 할당량에 유의해야 합니다.
두 번째 모델의 이점은 메시지가 한 번만 게시되므로 Pub/Sub 비용을 구할 때 배수가 적용되지 않는다는 것입니다. 하지만 특정 유형의 서비스 중단 시 서비스 중단이 시작되기 전에 게시된 메시지가 서비스 중단이 해결된 이후까지 제공되지 않을 수 있다는 단점이 있습니다. 사용할 수 없는 리전에 저장된 메시지가 연결된 위치에 관계없이 구독자에게 전송되지 못할 수 있습니다. 서비스 중단 중에 대체 리전에 게시된 메시지는 사용할 수 있습니다. 또한 게시자 또는 구독자의 오류율이 증가하여 사용할 수 없는 기간이 있을 수 있습니다. 이는 서비스 중단을 감지하는 데 사용되는 방법과 대체 리전으로 장애 조치하는 시간에 따라 달라집니다.
어떤 옵션을 선택하든 Pub/Sub 기능과 상호작용하는 방식을 알고 있어야 합니다. 정렬된 전송과 1회만 전송 모두 리전 내에서 보장됩니다. 예를 들어 장애 조치 중복 기법을 사용하면 동일한 리전에 게시된 메시지의 경우에만 메시지 전송이 보장됩니다. 메시지가 기본 리전에 먼저 게시되었더라도 구독자가 기본 리전에 게시된 메시지보다 대체 리전에 게시된 메시지를 먼저 수신할 수 있습니다.
게시자 미세 조정
선택한 장애 조치 옵션에 관계없이 게시자에서 수행할 수 있는 몇 가지 추가 미세 조정 단계가 있습니다. 게시자 동작을 미세 조정하면 고부하 시 최적의 성능이 보장됩니다. 메시지 일괄 처리는 비용 절감을 위해 지연 시간을 절충하는 방법이지만 안정성과는 크게 관련이 없으므로 여기에서 다루지 않습니다. 대신 재시도 설정 및 흐름 제어 설정을 비롯하여 안정성을 미세 조정하는 데 유용한 다른 매개변수에 중점을 둡니다.
네트워크를 사용할 수 없는 등의 일시적인 오류나 권한 변경과 같이 사용자 개입이 필요한 상황을 포함한 여러 가지 이유로 게시에 실패할 수 있습니다. Pub/Sub 클라이언트 라이브러리는 재시도 설정에 지정된 매개변수를 사용하여 일시적인 오류를 재시도합니다. 이러한 설정은 일시적인 이유로 실패하는 게시 RPC를 재시도할 때 지수 백오프 동작을 제어합니다. 일반적으로 대부분의 시나리오에는 기본 설정이 효과적이지만 이러한 값을 미세 조정해야 하는 경우가 있습니다.
미세 조정할 가능성이 가장 높은 두 가지 속성은 초기 RPC 제한 시간과 총 제한 시간입니다. 초기 RPC 제한 시간은 첫 번째 게시 RPC가 완료되도록 제공되는 시간입니다. RPC가 실패하거나 시간이 초과되면 총 요청 수 또는 총 제한 시간을 초과할 때까지 더 긴 제한 시간으로 다른 RPC가 시도됩니다.
게시자에 네트워크 제약이 있거나 Pub/Sub를 실행하는 가장 가까운 Google Cloud 데이터 센터에서 게시자가 먼 경우에 초기 제한 시간을 미세 조정할 수 있습니다. 네트워크 제약은 게시자가 실행 중인 머신의 처리량에 제한이 있거나 네트워크를 많이 사용하는 동일한 머신에서 실행되는 다른 서비스 때문일 수 있습니다. 제한 시간을 너무 짧게 설정하면 초기 RPC가 반복적으로 실패하므로 성공적으로 게시하려면 (더 긴 제한 시간의) 더 많은 시도가 필요할 수 있습니다. 재시도를 반복하면 게시 지연 시간이 늘어납니다. 이 경우 초기 제한 시간을 늘리면 게시 속도가 빨라질 수 있습니다.
네트워크 연결이 불안정한 경우 총 제한 시간과 초기 제한 시간을 늘리면 도움이 될 수 있습니다. 총 제한 시간이 늘어나면 게시 RPC가 성공적으로 완료되는 데 더 많은 시간을 할애할 수 있습니다. 게시 RPC가 기한 초과 오류와 함께 지속적으로 실패하는 경우 이러한 값을 미세 조정하는 것이 좋습니다.
게시에 대한 지속적인 기한 초과 오류는 게시자 흐름 제어를 미세 조정해야 한다는 의미일 수도 있습니다. 이러한 설정을 사용하면 수신 트래픽이 급증하여 Pub/Sub로 전송할 메시지가 더 많이 생성된 경우에 게시자의 복원력을 높일 수 있습니다. 발신 요청이 크게 증가하면 게시자의 CPU, 메모리 또는 네트워크 용량에 과부하를 초래할 수 있습니다. 게시에 과부하가 발생하면 제한 시간 전에 게시 요청 또는 응답을 처리할 수 없습니다. 따라서 더 많은 게시 요청이 발생하고 결국 총 제한 시간에 도달합니다. 게시자 흐름 제어는 게시 요청의 응답 없이 미해결될 수 있는 메시지 또는 바이트 수를 제한합니다. 이러한 방식으로 요청 수를 제한하면 사용량이 급증해도 리소스 사용률을 관리 가능한 수준으로 유지할 수 있습니다. 게시자의 작동 방식에 따라 게시가 추가 요청을 차단하도록 허용하여 후속 게시 RPC에서 용량을 기다리도록 만들 수 있습니다. 또는 용량에 도달하면 흐름 제어에 오류가 반환되도록 설정하여 서비스 호출자에게 푸시백할 수도 있습니다. 게시자 클라이언트 라이브러리가 한도 초과 동작으로 응답하는 방법을 구성합니다.
구독자 미세 조정
안정적인 작동을 위해 구독자 미세 조정이 필요할 수도 있습니다. 게시자와 마찬가지로 과부하가 발생하지 않도록 구독자의 흐름 제어 설정을 미세 조정할 수 있습니다. 구독자 클라이언트 라이브러리는 스트리밍 가져오기를 사용합니다. 그러면 클라이언트가 서버에 대한 영구 스트림을 열고 메시지를 사용할 수 있게 되면 서버에서 메시지를 전송합니다. 게시된 메시지가 크게 증가하면 구독자가 처리할 수 있는 것보다 더 많은 메시지를 수신할 수 있습니다. 흐름 제어를 적용하면 한 번에 클라이언트에 대해 확인되지 않은 미해결 메시지 수가 제한됩니다. 그러면 동시에 처리되는 메시지 수가 줄고 처리 시간이 길어집니다. 부하가 분산되면 구독자가 메시지 처리에 영향을 미치는 리소스 제한을 초과하지 않도록 할 수 있습니다. 리소스 제한을 초과할 경우 메시지를 처리할 수 없게 되는 연쇄 효과가 발생할 수 있습니다.
처리할 데이터 양의 급증했다가 결국에는 줄어들 것으로 예상된다면 흐름 제어로 충분합니다. 시간이 지나면서 사용량이 늘어서 일반적으로 트래픽이 증가하는 경우 흐름 제어가 구독자를 보호합니다. 하지만 계속 백로그가 누적되고 메시지 보관 기간이 경과하기 전에 메시지가 전송되지 않을 수 있습니다. 이러한 경우 자동 확장을 설정하면 확인되지 않은 메시지의 증가에 대응하여 더 많은 구독자를 확보할 수 있습니다. 설정 방법은 구독자를 위해 사용하는 컴퓨팅 플랫폼에 따라 다릅니다. 예를 들어 Compute Engine의 자동 확장 처리를 사용하면 전송되지 않은 메시지 수와 같은 측정항목을 기준으로 확장할 수 있습니다. 자동 확장 및 흐름 제어를 모두 사용하면 구독자가 단기간에 급증한 메시지 처리량은 물론 더 많은 컴퓨팅 성능이 요구되는 장기적인 증가에 대해서도 우수한 복원력이 보일 수 있습니다.
안전한 배포를 위한 스냅샷 및 탐색 사용
메시지 손실은 일반적으로 치명적인 이벤트입니다. Pub/Sub는 게시된 모든 메시지에 대해 최소 1회 전송을 제공합니다. 그러나 이러한 메시지가 올바르게 처리되는지 여부는 구독자의 동작에 좌우됩니다. 메시지가 성공적으로 확인되면 Pub/Sub가 메시지를 다시 전송하지 않습니다. 따라서 사용자가 배포한 새 구독자 코드에 메시지를 올바르게 처리하지 않고 확인하는 버그로 발생하면 구독자에 의한 메시지 손실이 발생할 수 있습니다. Pub/Sub는 구독자 버그가 발생하더라도 모든 메시지를 올바르게 처리하는 데 도움이 되는 스냅샷 및 탐색 기능을 제공합니다.
모든 구독자 배포의 패턴은 다음과 같아야 합니다.
새 구독자가 작동하는지 확인하기 전에 기다리는 시간은 사용 사례에 따라 다를 수 있습니다. 단계 흐름을 종료하는 유일한 방법은 구독자가 작동하는 것으로 간주될 때로서 이때 스냅샷을 삭제할 수 있습니다.
스냅샷 및 탐색 사용은 비프로덕션 환경에서 처음 실행되는 소프트웨어 및 프로덕션으로의 점진적 배포에 관한 권장사항을 대체하기 위한 것이 아닙니다. 데이터의 안정적인 처리를 보장하는 추가 보호 수준을 제공합니다. 스냅샷을 탐색하면 구독자가 성공적으로 처리한 메시지의 중복 전송이 발생할 수 있다는 단점이 있습니다. 그러나 Pub/Sub에는 기본적으로 최소 1회 전송 시맨틱스가 있으므로 이미 메시지 재전송에 대한 구독자의 복원력이 우수합니다.