이 주제에서는 Bigtable에서 연결 풀이 작동하는 방식, 연결 풀 크기가 Bigtable을 사용하는 애플리케이션에 미치는 영향, 그리고 기본 연결 풀 설정을 변경해야 하는 경우를 설명합니다.
이 페이지를 읽은 후 연결 풀 크기를 변경해야 할 경우 연결 풀 구성을 참조하여 최적의 크기를 결정하는 방법과 변경하는 방법을 알아보세요. Cloud Bigtable에 Go, C++, 자바 클라이언트 라이브러리를 사용하는 경우에만 코드에서 각 풀의 연결 수를 구성할 수 있습니다.
연결 풀 작동 방식
채널 풀이라고도 하는 연결 풀은 연결 지연 시간과 성능이 개선되도록 공유하고 재사용하는 데이터베이스 연결의 캐시입니다. 연결은 라운드 로빈 시스템에서 사용됩니다.
Bigtable을 사용하는 경우 애플리케이션 프로세스별로 단일 데이터 클라이언트를 만듭니다. 클라이언트마다 연결 풀이 하나씩 있습니다. 각 연결 풀에는 일정한 수의 gRPC 연결이 있으며, 각 연결은 최대 100개의 동시 스트림을 처리할 수 있습니다. 이러한 연결을 통해 전송된 요청은 Google 미들웨어를 통과한 후 테이블에 라우팅됩니다. 미들웨어 레이어는 여러 부하 분산 인스턴스로 구성되어 있으며 각 요청은 가용성이 가장 높은 미들웨어 인스턴스를 통해 라우팅됩니다.
연결(또는 채널)은 최대 100개의 차선이 있는 고속도로와 같으며, 각 차선(스트림)에는 지정한 기간에 한 대의 차량(요청)만 있을 수 있습니다. gRPC 연결당 동시 스트림 한도는 100개로 Google의 미들웨어 레이어에 적용되며 이 수를 다시 구성할 수 없습니다.
1시간 간격으로 자동으로 연결이 새로고침됩니다. 또한 5분 동안 연결이 요청에 표시되지 않으면 미들웨어는 연결을 자동으로 삭제하고 추가 연결이 필요할 때까지 연결을 다시 만들지 않습니다.
각 채널마다 하나의 하위 채널이 있습니다. 각 하위 채널에는 TCP를 사용하여 요청을 바이트로 변환하고 미들웨어를 통해 테이블로 전송하는 HTTP2 연결이 있습니다. 이 프로세스는 Bigtable 서비스에 의해 원활하게 처리되므로 이를 위해 별도로 구성할 것이 없습니다.
연결 풀이 성능에 미치는 영향
버퍼링 없이 요청을 처리하려면 gRPC 연결이 충분해야 합니다. 하지만 사용 부족으로 인해 자주 끊어지는 연결은 너무 많지 않아야 합니다.
연결이 충분하지 않음
연결 풀이 트래픽을 처리할 만큼 연결이 충분하지 않으면 미들웨어는 요청을 버퍼링하고 큐에 추가하기 시작합니다. 버퍼링으로 인해 트래픽 처리 속도가 느려지므로 초당 요청 수가 감소하고 요청이 백업될 때 지연 시간을 늘어납니다.
연결이 너무 많음
풀에 연결이 너무 많아서 일부 연결이 유휴 상태가 되는 경우 미들웨어는 유휴 연결의 해제합니다. 그런 다음 이러한 연결을 필요로 하는 새 요청이 들어오면 해당 연결이 다시 설정됩니다. 즉, 트래픽이 증가하면 요청에 서버 측 캐시 부적중이 발생하여 추가 작업 및 지연 시간이 발생할 수 있습니다. 트래픽 수준 변화로 인해 이 문제가 자주 발생하면 이 활동으로 인해 클라이언트 측에서 꼬리 지연 시간이 급격하게 증가할 수 있습니다.
기본 설정을 변경해야 하는 경우
기본 연결 풀 크기는 대부분의 애플리케이션에 적합하며 대부분의 경우 변경할 필요가 없습니다. 애플리케이션에서 사용하는 클라이언트 라이브러리에 따라 연결 풀 크기를 변경하지 못할 수도 있습니다. Cloud Bigtable에 Go, C++ 또는 자바 클라이언트 라이브러리를 사용하는 경우에만 코드에서 각 풀의 연결 수를 구성할 수 있습니다.
일반적으로 이상적인 연결 풀은 포화도를 극대화하는 데 필요한 연결 수의 최소 두 배 이상입니다. 따라서 트래픽 변동에 대한 여지가 남게 됩니다. 예를 들어 연결이 4개 있고 각각 최대 요청 수(100개)를 처리하는 경우 연결당 요청 수를 10~50개로 줄이고 싶으므로 이상적인 연결 풀 크기는 최소 두 배 이상이거나 최소 연결 8개입니다.
풀의 연결 수 변경을 고려해야 하는 신호는 다음과 같습니다.
낮은 처리량과 클라이언트 측 꼬리 지연 시간 급증
일반적인 처리량이 매우 낮고(예: 연결당 초당 요청 1개 미만) 애플리케이션의 꼬리 지연 시간이 주기적으로 높게 관찰되는 경우 연결을 유지하는 데 충분한 트래픽이 전송되지 않을 수 있습니다. 이 경우 풀의 연결 수를 줄여야 할 수 있습니다. 올바른 수를 결정하는 방법은 연결 풀 구성을 참조하세요.
버퍼링된 요청 수
요청이 클라이언트 측에 계속 쌓이는 경우 연결 풀이 처리할 수 있는 것보다 많은 동시 요청을 전송한다는 의미일 수 있습니다. 최적의 수를 계산한 다음, 필요한 경우 코드를 변경합니다.
요청이 계속 쌓이고 있는지 확인하려면 OpenCensus를 사용하여 grpc.io/client/started_rpcs 측정항목과 grpc.io/client/completed_rpcs 측정항목의 차이를 확인할 수 있습니다.
가상 환경
드문 경우지만 Bigtable 클라이언트는 애플리케이션이 실행 중인 CPU 수를 알 수 없으며 CPU가 한 개만 사용되는 것처럼 연결을 할당합니다. 예를 들어 Kubernetes 또는 Docker에서 가상 CPU 인스턴스를 사용할 때 이 문제가 발생할 수 있습니다. 이 문제가 분명한 경우 애플리케이션의 QPS와 지연 시간을 기준으로 가이드라인에 따라 풀 수를 구성해야 합니다.
[[["이해하기 쉬움","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-09-04(UTC)"],[[["\u003cp\u003eConnection pools are caches of database connections that enhance performance by sharing and reusing connections, using a round-robin system.\u003c/p\u003e\n"],["\u003cp\u003eEach Bigtable client has a connection pool, containing gRPC connections that can each handle up to 100 concurrent streams, managed by Google's middleware.\u003c/p\u003e\n"],["\u003cp\u003eHaving too few connections leads to buffering and increased latency, while too many idle connections result in frequent disconnections and potential server-side cache misses, spiking tail latency.\u003c/p\u003e\n"],["\u003cp\u003eThe default connection pool size is usually sufficient, but adjustments might be needed when experiencing low throughput with high latency, buffered requests, or when using virtual environments where CPU count detection is inaccurate.\u003c/p\u003e\n"],["\u003cp\u003eOnly the Go, C++ and Java client libraries allow the number of connections in each pool to be configurable.\u003c/p\u003e\n"]]],[],null,["# Connection pools\n================\n\nThis topic describes how connection pools work in Bigtable, the impacts\nthat connection pool size can have on an application that uses\nBigtable, and when you might want to change the default connection\npool settings.\n\nAfter you read this page, if you determine that you should change your\nconnection pool size, see [Configuring connection pools](/bigtable/docs/configure-connection-pools) to\nlearn how to determine the optimal size and how to change it. The number of\nconnections in each pool is configurable in your code only when you use the Go,\nC++, or Java client libraries for Cloud Bigtable.\n\nHow connection pools work\n-------------------------\n\nA *connection pool* , also known as a *channel pool*, is a cache of database\nconnections that are shared and reused to improve connection latency and\nperformance. Connections are used in a round robin system.\n\nWhen you use Bigtable, you create a single data client per\napplication process. Each client has one connection pool. Each connection pool\ncontains some number of gRPC connections, which can each handle up to 100\nconcurrent streams. Requests sent through these connections pass through Google\nmiddleware, which then routes them to your table. The middleware layer is made\nup of many load-balanced instances, and each request is routed through the\nmiddleware instance that has the most availability.\n\nYou can think of a *connection* (or channel) like a highway that has up to 100\nlanes, and each lane (stream) can only contain one car (request) at any given\ntime. The limit of 100 concurrent streams per gRPC connection is enforced in\nGoogle's middleware layer, and you are not able to reconfigure this number.\n\nA connection automatically refreshes itself once every hour. Additionally, if a\nconnection has not seen a request in five minutes, the middleware automatically\ndeletes the connection and doesn't recreate it until an additional connection is\nneeded.\n\nBehind the scenes, each channel has a single subchannel. Each subchannel has an\nHTTP2 connection that uses TCP to convert requests to bytes and send them\nthrough the middleware and then to your table. This process is handled\nseamlessly by the Bigtable service, and you don't need to configure\nanything to make it happen.\n\nHow connection pools affect performance\n---------------------------------------\n\nIdeally, you should have enough gRPC connections to handle your requests\nwithout any buffering. However, you should not have so many connections that\nthey are frequently dropped because of lack of use.\n\n### Not enough connections\n\nIf a connection pool does not have enough connections to handle your traffic,\nthe middleware starts to buffer and queue requests. This buffering slows down\nthe traffic, reducing the number of requests per second and increasing latency\nas the requests back up.\n\n### Too many connections\n\nIf a pool has too many connections, meaning some of the connections are idle,\nthe middleware disconnects the idle connections. Then when new requests come\nthrough that require them, these connections are reestablished. This means that\nwhen traffic increases, requests can encounter a server-side cache miss, causing\nextra work and latency. If this happens frequently because of varying traffic\nlevels, this activity can manifest as a perceived spike in tail latency on the\nclient side.\n| **Note:** In most cases, you cannot control the refresh cadence. However, If this tail latency is a concern and you need predictable latency at a low rate of queries per second (QPS), and you are using the [Cloud Bigtable client library for Java](https://cloud.google.com/java/docs/reference/google-cloud-bigtable/latest/overview), you are able to configure the refresh settings using the `BigtableDataSettings.Builder` class. If you are using the [Cloud Bigtable client library for Go](https://godoc.org/cloud.google.com/go/bigtable), see the [Connection Refresh Example](https://github.com/GoogleCloudPlatform/cloud-bigtable-examples/tree/master/go/connection-refresh) on GitHub.\n\nWhen to change the default settings\n-----------------------------------\n\n**The default connection pool size is right for most applications, and in most\ncases there's no need to change it.** Depending on the client library you use in\nyour application, you might not be able to change your connection pool size. The\nnumber of connections in each pool is configurable in your code **only when you\nuse the Go, C++, or Java client libraries for Cloud Bigtable**.\n\nAs a general rule, an ideal connection pool has at least twice the number of\nconnections that it takes for maximum saturation. This leaves room for traffic\nfluctuations. For example, if you have 4 connections and they are each handling\nthe maximum number of requests possible (100), you want to bring the number of\nrequests per connection down to a number between 10 and 50, so the ideal\nconnection pool size is at least double that, or a minimum of 8 connections.\n\nSignals that you should consider changing the number of connections in the pool\ninclude the following:\n\n### Low throughput combined with spikes in client-side tail latency\n\nIf your typical throughput is fairly low, such as less than one request per\nsecond per connection, and you observe periodically high tail latency for your\napplication, you might not be sending enough traffic to keep the connections\nalive. In this case, you might need to lower the number of connections in the\npool. See [Configuring connection pools](/bigtable/docs/configure-connection-pools) to learn how to\ndetermine the right number.\n\n### Buffered requests\n\nIf you observe that requests are stacking up on the client side, this might\nindicate that you are sending more concurrent requests than the connection pool\ncan handle. [Calculate the optimal number](/bigtable/docs/configure-connection-pools), then change\nyour code if you need to.\n\nTo determine whether requests are stacking up, you can use\n[OpenCensus](https://opencensus.io/guides/grpc/java/#examining-metrics) to look at the difference between the\n`grpc.io/client/started_rpcs` and `grpc.io/client/completed_rpcs` metrics.\n\n### Virtual environment\n\nIn some rare cases, the Bigtable client is not able to tell the\nnumber of CPUs that the application is running on and allocates connections as\nif only one CPU is in use. For example, this can happen when you use virtual\nCPU instances in Kubernetes or Docker. If this is evident, you should configure\nthe number of pools [according to the guidelines](/bigtable/docs/configure-connection-pools) based on\nyour application's QPS and latency.\n\nWhat's Next\n-----------\n\n- Learn how to [configure connection pools](/bigtable/docs/configure-connection-pools).\n- Read more about [performance](/bigtable/docs/performance)."]]
