📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code 멀티 에이전트 — Teams
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🗄️database

커넥션 풀 크기는 얼마나 조정해야할까?

약 2분
2026년 1월 30일
GitHub에서 보기

커넥션 풀 크기는 얼마나 조정해야할까?

예시 : 동시 접속 사용자 10,000명

  • 동시에 1만 명의 사용자가 DB에 요청을 보내는 웹 사이트가 있다고 가정해보자
  • 그럼 초당 약 1만 건의 트랜잭션이 발생한다.
  • 이런 웹 사이트의 커넥션 풀은 얼마나 커야할까?
  • 놀랍게도, 정답은 '얼마나 커야 하는가'가 아니라 '얼마나 작게 만들어야 하는가' 이다

다른 변경사항 없이, 커넥션 풀 크기만 줄였을 뿐인데 애플리케이션의 응답 시간이 약 100ms에서
약 2ms로 단축되어 50배 이상 개선되었음

왜 그럴까?

  • CPU 코어가 하나뿐인 컴퓨터도 수십, 수백 개의 스레드를 "동시에" 처리할 수 있는 것처럼 보인다.
  • 하지만 이는 운영체제가 타임 슬라이싱이라는 기술을 이용해 만들어낸 일종의 속임수이다.
  • 실제로는 단일 코어가 한 번에 하나의 스레드만 실행할 수 있다.
  • 운영체제는 컨텍스트 스위칭을하여 해당 코어가 다른 스레드의 코드를 실행하는 식으로 진행된다.
  • 단일 CPU 자원을 사용할 경우, A와 B를 순차적으로 실행하는 것이 타임 슬라이싱을 통해 "동시에" 실행하는 것보다 항상 빠르다는 것은 컴퓨팅의 기본 법칙이다.
  • 스레드 수가 CPU 코어 수를 초과하면, 스레드를 추가할수록 속도가 오히려 느려지게 된다.

공식

  • 아래 공식은 PostgreSQL 프로젝트에서 시작점으로 제공하는 것이지만, 대부분의 DB에 적용될 것으로 예상된다.
Connection Pool Size = (코어 수 * 2) + I/O를 동시에 처리할 수 있는 디스크 수
  • 하드 디스크가 하나 장착된 4코어 i7 서버에서 다음과 같이 계산된다
    • 9 = 4 * 2 + 1
  • 적어 보이는가? 직접 테스트 해보자.
  • 이 정도 구성이라면, 사용자 3,000명이 간단한 쿼리를 실행해도 초당 TPS 6,000건은 충분히 처리할 수 있을 것이다.

커넥션을 기다리는 스레드로 가득 찬 작은 커넥션 풀이 필요하다.

  • 사용자가 10,000명이라고 커넥션 풀을 10,000개로 설정하는 것은 말도 안된다.
  • 1,000개도 과하고, 100개 조차도 과하다
  • 커넥션 풀은 많아야 수십 개 정도로 작게 유지하고, 나머지 애플리케이션 스레드는 풀에서 연결을 기다리도록 하는 것이 좋다.

공식을 사용하는 것도 좋지만, 실제 부하테스트를 적용해보면서 Sweet Spot은 찾아야 한다!

database 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • 커넥션 풀 크기는 얼마나 조정해야할까?
  • 예시 : 동시 접속 사용자 10,000명
  • 왜 그럴까?
  • 공식
  • 커넥션을 기다리는 스레드로 가득 찬 작은 커넥션 풀이 필요하다.