연결 풀
이 주제에서는 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와 지연 시간을 기준으로 가이드라인에 따라 풀 수를 구성해야 합니다.