Pub/Sub 측정항목을 파이프라인 자동 확장 신호로 사용하는 경우의 권장사항은 다음과 같습니다.
신호를 2개 이상 사용하여 파이프라인 자동 확장
Pub/Sub 측정항목만 사용하여 파이프라인을 자동 확장하지 마세요. 자동 확장 결정을 위한 단일 장애점이 있는 시나리오가 발생할 수 있습니다. 대신 신호를 조합하여 자동 확장을 트리거합니다. 추가 신호의 예시로는 클라이언트의 CPU 사용률 수준이 있습니다. 이 신호는 클라이언트 태스크가 태스크를 처리하고 있는지, 확장 시 클라이언트 태스크가 더 많은 태스크를 처리할 수 있는지 여부를 나타낼 수 있습니다.
파이프라인에 사용할 수 있는 다른 Cloud 제품의 신호 예시는 다음과 같습니다.
Compute Engine(GCE)은 CPU 사용률 및 Monitoring 측정항목과 같은 신호에 따른 자동 확장을 지원합니다.
또한 Compute Engine은 신뢰성 향상을 위해 여러 측정항목과 여러 신호를 지원합니다.
Google Kubernetes Engine(GKE) 수평형 포드 자동 확장(HPA)은 CPU 및 메모리 사용량과 같은 리소스 사용량, 커스텀 Kubernetes 측정항목, Pub/Sub의 Monitoring 측정항목과 같은 외부 측정항목을 기준으로 자동 확장을 지원합니다.
또한 여러 신호를 지원합니다.
측정항목이 없다고 해서 처리할 메시지가 없다고 가정하지 마세요. 예를 들어 누락된 측정항목에 대한 응답으로 처리 태스크를 0으로 축소하면 이미 백로그에 있는 메시지나 이 시간 동안 게시된 메시지가 소비되지 않습니다. 이렇게 되면 엔드 투 엔드 지연 시간이 늘어납니다.
지연 시간을 최소화하려면 최신 Pub/Sub 측정항목이 빈 큐를 표시하더라도 항상 게시된 메시지를 처리할 준비가 될 수 있도록 최소 태스크 수를 0보다 크게 설정합니다.
GCE 자동 확장 처리와 GKE HPA 모두 측정항목을 사용할 수 없을 때 현재 복제본 수를 유지하도록 설계되었습니다. 이렇게 하면 사용 가능한 측정항목이 없을 때 안전망 역할을 합니다.
또한 Pub/Sub 흐름 제어 메커니즘을 구현하여 누락된 측정항목으로 인해 의도치 않게 축소된 태스크가 과부하되지 않도록 방지할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-01-09(UTC)"],[],[],null,["# Best practices for using Pub/Sub metrics as a scaling signal\n\nIf you use Pub/Sub metrics as a signal to autoscale your pipeline, here\nare some recommendations.\n\nUse more than one signal to autoscale your pipeline\n---------------------------------------------------\n\nDon't use only Pub/Sub metrics to autoscale your pipeline. It\nmight lead to scenarios where you have a single point of failure for your\nautoscaling decisions. Instead, use a combination of signals to trigger\nautoscaling. An example of an additional signal is the client's CPU\nutilization level. This signal can indicate whether the client tasks are\nhandling work and if scaling up can let the client tasks handle more work.\nSome examples of signals from other\nCloud products that you can use for your pipeline are as follows:\n\n- Compute Engine supports autoscaling based on signals such as\n CPU utilization and Monitoring metrics.\n Compute Engine also supports multiple metrics and multiple signals\n for better reliability.\n\n For more information about scaling with Monitoring metrics, see\n [Scale based on Monitoring metrics](/compute/docs/autoscaler/scaling-cloud-monitoring-metrics).\n For more information about scaling with CPU utilization, see [Scale based on CPU utilization](/compute/docs/autoscaler/scaling-cpu).\n- Google Kubernetes Engine Horizontal Pod autoscaling (HPA) supports\n autoscaling based on resource usage such as CPU and memory usage,\n custom Kubernetes metrics, and external metrics such as\n Monitoring metrics for Pub/Sub.\n It also supports multiple signals.\n\n For more information, see [Horizontal Pod autoscaling](/kubernetes-engine/docs/concepts/horizontalpodautoscaler).\n\nUse the regional version of the metrics instead of global versions\n------------------------------------------------------------------\n\nPub/Sub offers two versions of each metric typically used with\nautoscaling. Make sure you use the versions with the `by_region` suffix:\n\n- [`subscription/num_unacked_messages_by_region`](/monitoring/api/metrics_gcp_p_z#pubsub/subscription/num_unacked_messages_by_region)\n- [`subscription/oldest_unacked_message_age_by_region`](/monitoring/api/metrics_gcp_p_z#pubsub/subscription/oldest_unacked_message_age_by_region)\n\nDon't use the global versions of these metrics if you want your autoscaling to\nbe resilient to single-region outages. The global version of these metrics\nrequire the calculation of the backlog across all regions known to have\nmessages, which means unavailability in a single region region results in a data\ngap. In contrast, the `by_region` versions of the metrics calculate and report\nthe backlog on a per-region basis. If the backlog cannot be computed for a\nsingle region, the metric still reports values for the other regions.\n\nAvoid using subscriber-side throughput metrics to autoscale subscribers\n-----------------------------------------------------------------------\n\nAvoid using subscriber-side throughput metrics like\n`subscription/ack_message_count` to autoscale subscriber clients. Instead,\nconsider using metrics that directly reflect the backlog of messages waiting\nto be processed, such as the previously mentioned\n`subscription/num_unacked_messages` or\n`subscription/oldest_unacked_message_age`.\n\n**Issues with using subscriber-side throughput metrics for autoscaling**\n\nUsing these metrics can cause problems because they represent the amount\nof traffic between Pub/Sub and subscribers. Scaling based on such\nmetric can create a self-referential loop where a decrease in delivered or\nacknowledged messages leads to scaling down of clients. For example, this\nmight occur if there is a temporary dip in traffic or there is an issue with\none of your subscribers.\n\nIf your clients scale down to zero or near-zero, all on-going subscribe traffic\ncan stop, and subscribers may not be able to process messages, even if new\nmessages arrive. This can result in significant ingestion lag and lead to an\nunrecoverable state for your subscriber clients.\n\nDeal with metrics gaps when they occur\n--------------------------------------\n\nDon't assume that the absence of metrics means that there are no messages to\nprocess. For example, if in response to missing metrics, you scale down\nprocessing tasks to zero, messages already in the backlog or that get published\nduring this time might not be consumed. This increases the end-to-end latency.\nTo minimize latency, set a minimum task count greater than zero so that you\nare always prepared to handle published messages,\neven if recent Pub/Sub metrics indicate an empty queue.\n\nBoth Compute Engine autoscalers and Google Kubernetes Engine HPAs are designed to\nmaintain the current replica count when metrics are unavailable. This provides a\nsafety net if no metrics are available.\n\nYou can also implement\n[Pub/Sub flow control](/pubsub/docs/flow-control) mechanisms\nto help prevent tasks from being overwhelmed if they are unintentionally\ndownscaled due to missing metrics."]]
