Hyperdrive 연결 한도 1,500개로 확대: DB 풀을 늘리기 전 볼 세 가지

Hyperdrive의 새 연결 상한을 활용하려면 먼저 원본 데이터베이스의 남은 연결 용량, 연결을 붙잡는 트랜잭션, 실제 풀 대기를 함께 보세요. Cloudflare는 2026년 11월 11일 Workers Paid 플랜의 Hyperdrive 구성을 계정당 최대 25개에서 100개로, 구성별 원본 연결 설정 상한을 100개에서 1,500개로 확대했다고 발표했습니다. 선택할 수 있는 범위가 넓어진 만큼, 내 데이터베이스에 맞는 값을 정하는 과정이 중요해졌어요.

이 글은 Hyperdrive로 PostgreSQL이나 MySQL 계열 원본에 연결하는 운영자를 위한 검토 안내입니다. 2026년 11월 12일 공식 변경 공지와 풀·지표 문서를 확인했습니다. 실제 계정의 연결 수를 바꾸거나 성능 시험을 한 것은 아니며, 아래 계산과 상황은 판단을 돕기 위해 만든 예시예요.

구성 개수와 연결 수를 각각 읽어 보세요

먼저 계정당 구성 상한은 Hyperdrive 연결 설정을 몇 개 만들 수 있는지에 관한 값입니다. 구성에는 접속할 데이터베이스와 연결 정보가 들어가므로 서로 다른 작업이나 데이터베이스를 연결할 때 관련됩니다. 구성별 원본 연결 상한은 한 구성이 원본 데이터베이스에 연결할 수 있는 풀의 크기와 관계가 있어요. 구성 100개와 원본 연결 1,500개는 적용되는 단위가 다릅니다.

이번 공지의 대상은 Workers Paid 플랜입니다. Free 플랜에도 같은 새 상한이 적용됐다고 일반화하면 안 돼요. 또한 상한 확대만으로 현재 구성의 선택값이나 원본 데이터베이스의 최대 연결 설정이 바뀌었다고 판단할 수는 없습니다. 지금 사용하는 플랜과 구성의 설정값, 원본의 제한을 각각 읽어야 실제 검토를 시작할 수 있어요.

자료 사이의 기준일도 확인할 필요가 있습니다. 작성 때 열어 본 Limits 안내 표에는 유료 구성 25개와 원본 연결 약 100개라는 이전 수치가 남아 있었어요. 이 글의 새 상한은 11월 11일 변경 공지를 기준으로 적었습니다. 실제 적용을 검토할 때는 최신 공지와 계정의 설정 화면을 함께 확인하고, 표시가 다르면 해당 플랜과 구성 정보를 갖고 공급자에게 확인하세요.

첫째, DB 전체 연결 예산을 적어 보세요

Cloudflare는 Hyperdrive의 원본 연결 설정을 원본 데이터베이스의 연결 한도보다 낮게 두도록 안내합니다. 원본에는 Hyperdrive 이외의 접속도 들어올 수 있어요. 배치 작업, 관리 도구, 다른 서비스가 같은 데이터베이스를 사용하는지부터 확인해 보세요. 새 상한에 맞춰 한 구성의 숫자만 크게 바꾸면 다른 사용처가 쓸 여유를 놓칠 수 있습니다.

예를 들어 어떤 데이터베이스의 허용 연결이 200개라고 가정해 볼게요. 다른 서비스가 사용할 예산을 80개, 관리·장애 대응을 위한 여유를 20개로 잡았다면 이번 검토에서 Hyperdrive에 배분할 범위는 100개입니다. 이 숫자는 권장 비율이나 실제 측정치가 아닌 가상 계산이에요. 각 항목에 얼마가 필요한지는 해당 서비스의 관측과 운영 조건으로 정해야 합니다.

같은 원본을 가리키는 Hyperdrive 구성이 여러 개라면 각 구성에 적힌 값을 따로 보지 말고 합쳐서 검토해 보세요. 개발과 운영이 같은 원본을 공유하는지, 별도 계정이나 외부 애플리케이션에서 연결하는 경로가 있는지도 적을 수 있습니다. 구성 이름만으로 데이터베이스가 완전히 분리됐다고 가정하지 않는 것이 좋겠어요.

Cloudflare 문서는 분산된 풀의 특성상 새 풀이 만들어지면서 안내된 연결 수를 일시적으로 넘을 수 있는 상황도 설명합니다. 따라서 화면의 설정값을 원본 전체에 적용되는 절대적인 차단선으로 사용하기는 어렵습니다. 원본 자체의 연결 제한과 실제 사용량도 함께 확인할 이유예요. 공급자가 적용하는 DB 제한을 바꾸려면 별도의 용량과 운영 검토가 필요합니다.

둘째, 연결이 오래 점유되는 이유를 살펴봐요

Hyperdrive는 트랜잭션 단위의 연결 풀을 사용합니다. 트랜잭션이 끝나면 연결을 풀로 돌려주어 다른 요청이 사용할 수 있게 하는 구조예요. 그래서 요청 수가 늘어난 상황과, 적은 요청이 연결을 오래 붙잡고 있는 상황은 조사할 지점이 달라집니다. 풀 크기를 보기 전에 오래 실행되는 쿼리나 트랜잭션이 있는지 확인해 보세요.

공식 Limits 문서는 풀에서 연결을 얻지 못하는 오류의 원인으로 긴 쿼리나 트랜잭션에 의한 점유를 듭니다. 반면 연결 거부 오류에는 방화벽이나 원본 공급자의 연결 한도 초과가 관련될 수 있다고 설명해요. 두 증상을 모두 ‘연결이 부족하다’로 적으면 풀 크기 조정, 쿼리 조사, 네트워크 확인 가운데 무엇을 할지 정하기 어려워집니다.

가상의 사례로, 정산 배치가 시작된 시간에만 사용자 요청이 기다린다고 생각해 볼게요. 먼저 배치가 시작된 시각, 대기가 생긴 구간, 쿼리와 트랜잭션의 지속 시간을 나란히 기록할 수 있습니다. 이후 배치와 사용자 요청이 같은 원본 자원을 쓰는지 확인하면 됩니다. 이 관측 없이 숫자부터 늘리면 대기 원인을 설명하지 못한 상태로 원본 부담만 바꿀 수 있어요.

또 다른 예로, 짧은 요청이 한꺼번에 늘어난 시간대에는 남은 연결 슬롯과 대기 고객 수를 확인해 볼 수 있습니다. 원본에 여유가 있고 연결 대기가 함께 늘었다면 풀 크기를 검토할 근거가 생겨요. 반대로 원본 쿼리 시간이 길어졌는데 연결 대기는 뚜렷하지 않다면, 다음 조사의 질문은 달라질 수 있습니다. 어떤 변경이 맞는지는 실제 지표로 정해야 해요.

세션 상태에 의존하는 코드도 점검 대상입니다. 공식 풀 문서는 트랜잭션이 끝난 뒤 연결이 반환될 때 상태가 초기화되는 동작을 설명합니다. 상태를 유지하려고 여러 작업을 긴 트랜잭션에 묶는 설계는 연결 재사용에 영향을 줄 수 있어요. 이 글에서 코드를 고치거나 실행하지는 않았으므로, 해당 동작에 의존하는 부분이 있다면 개발자와 함께 원래 의도를 검토하세요.

셋째, 같은 구간의 지표로 변경 필요성을 확인해요

Hyperdrive의 Metrics and analytics 문서에는 열린 연결, 사용 가능한 슬롯, 연결을 기다리는 고객 수와 풀 설정 최대값이 나옵니다. 쿼리 관련 지표에는 연결을 맺는 시간과 쿼리 결과를 받는 시간, 캐시 상태도 설명돼 있어요. 이 항목을 같은 구성과 같은 시간 구간으로 맞춰 보면 질문을 더 구체적으로 만들 수 있습니다.

예를 들어 ‘최대값에 가까워졌다’는 관찰 옆에 대기 고객이 실제로 있었는지 적어 보세요. 이어서 그 시간의 원본 연결 사용량과 쿼리 시간을 확인할 수 있습니다. 풀의 연결이 많이 열렸다는 사실만으로 사용자에게 영향이 있었다고 단정하지 말고, 실제 요청 오류나 지연과 시간대가 맞는지 살펴보면 좋겠어요.

평균값과 최고값의 용도도 구분하세요. 하루 평균에선 여유가 보이더라도 특정 배치 시간에 대기가 몰릴 수 있습니다. 반대로 일시적인 최고값 한 번을 하루 종일 유지된 상태처럼 표현하면 검토가 과해질 수 있어요. 어떤 집계값을 읽었고 어느 구간에 해당하는지 기록해야 다음 사람이 같은 관측을 재현할 수 있습니다.

캐시 상태는 원본에 도착하는 작업을 이해할 때 도움이 됩니다. 요청이 늘어도 캐시로 처리되는 비중이 다르면 원본에 필요한 연결의 양을 같은 방식으로 볼 수 없어요. 다만 캐시 적중률 하나로 필요한 풀 크기를 계산하는 공식을 이 글에서 제시하지는 않습니다. 실제 작업의 쿼리 수와 트랜잭션 점유를 함께 볼 항목으로 남겨 두세요.

설정값을 검토할 때 남길 작은 변경 메모

실제 값을 바꾸려면 현재 플랜, 구성 식별 정보, 원본 데이터베이스, 기존 설정값을 먼저 남기세요. 변경 이유에는 ‘1,500개까지 지원해서’보다 실제 관찰을 적는 편이 좋습니다. 예를 들면 ‘업무 시작 구간에 이 구성의 대기 고객과 원본 여유를 확인했고, 현재 설정이 작업량과 맞는지 검토한다’처럼 쓸 수 있어요.

그다음 어떤 지표로 결과를 읽을지 정해 보세요. 변경 전후에 같은 구성과 비슷한 작업 구간을 비교하고, 원본 연결 사용량과 오류·쿼리 시간도 함께 보겠다는 식입니다. 이용량이나 배포가 함께 변했다면 그 사실을 비교 기록에 적으세요. 동시 변경이 많은 상황에서 풀 설정의 효과만 분리해 확정하기는 어렵습니다.

복원할 값과 담당자도 변경 전에 정하세요. 원본이 연결을 거부하거나 작업 지연이 커지면 어떤 승인 절차로 기존 설정을 돌려놓을지 논의할 수 있습니다. 운영 구성 삭제나 풀 강제 재시작을 숫자 확인의 기본 단계로 삼을 필요는 없어요. 특히 공식 풀 문서는 수동 재시작이 활성 연결을 끊고 진행 중인 쿼리에 오류를 줄 수 있다고 안내합니다.

대시보드에서 값을 조정하는 절차 자체는 Tune connection pooling 문서에 나와 있습니다. 이 글은 운영 계정의 값을 대신 선택하는 지침이 아니므로, 변경 권한과 실제 대상이 확인된 환경에서 담당 절차를 따라 주세요. 직접 시험하지 않은 환경의 적정 연결 수나 처리량을 특정 숫자로 제시할 수는 없습니다.

자주 묻는 질문과 적용 범위

Workers의 동시 접속 수도 1,500개라는 뜻인가요? 공식 문서는 Workers에서 Hyperdrive로 들어오는 고객 연결과 Hyperdrive에서 원본으로 나가는 연결을 구분합니다. 이번 공지의 1,500개는 구성별 원본 연결 설정 상한입니다. 이 숫자를 사용자 수나 초당 요청 수로 바꾸어 읽지 마세요.

여러 구성을 만들면 같은 DB의 연결 한도를 넓힐 수 있나요? 계정의 구성 상한과 원본 DB의 허용 연결은 각각 적용됩니다. 구성을 나누더라도 원본의 제한과 다른 작업의 예산을 함께 계산해야 해요. 구성 개수를 늘리는 결정을 원본 자원 검토와 연결해서 보세요.

지금 오류가 없는데 상한에 맞춰 바꿔 둘까요? 먼저 앞으로 필요한 작업량과 현재 관측을 적어 보세요. 조정 근거가 없다면 기존 동작을 기록해 두고 필요한 시점에 검토할 수 있습니다. 새 상한은 더 큰 값을 선택할 가능성을 제공하며, 모든 환경에 같은 선택값이 필요하다는 결과를 뜻하지는 않아요.

공식 자료 확인일은 2026년 11월 12일입니다. 새 상한과 적용 플랜은 11월 11일 공지, 풀의 동작과 지표 해석은 아래 문서를 기준으로 정리했어요. 개별 계정의 적용 상태·과금·데이터베이스 성능은 직접 확인하지 않았습니다.

• Hyperdrive 한도 확대 공지
• Hyperdrive 제한과 오류 원인 안내
• 연결 풀 크기 설정 문서
• 트랜잭션 풀 동작 설명
• Hyperdrive 지표와 분석 안내

데이터베이스 운영 변경의 범위와 전환 조건을 함께 살펴보고 싶다면 Cloud SQL MySQL blue-green 업그레이드 전 확인할 조건도 참고해 보세요.

앱의 접속 수와 원본 데이터베이스가 받아들이는 연결 수를 나눠 생각하는 개념 이미지입니다.