데이터베이스의 커넥션과 세션
데이터베이스(DB) 환경에서 커넥션(Connection)과 세션(Session)은 서로 밀접하게 연관된 개념이지만, 엄밀하게는 다른 의미를 가짐.
커넥션은 보통 클라이언트(애플리케이션)와 DB 서버 간의 물리적 혹은 논리적 연결을 말함.
세션은 DBMS 내부에서 특정 사용자(또는 프로세스)가 DB에 접속해 있는 상태를 식별하기 위한 논리적 컨텍스트를 의미함.
커넥션 : 정의 및 특징
1. 물리적(또는 논리적) 연결
클라이언트 애플리케이션이 DB 서버로 연결할 때, TCP 소켓 등의 네트워크 레벨 통신이 성립됨.
일반적으로 3306 포트(MySQL), 5432 포트(PostgreSQL), 1521(Oracle), 1433(MSSQL) 등.
애플리케이션과 DB 서버 사이에 “통신할 채널”이 열리는 것을 커넥션이라 부릅니다.
2. 자원 소비
커넥션은 DB 서버 자원(메모리, CPU, 스레드 등)을 점유함.
많은 커넥션이 동시에 생성되면 서버는 각각을 처리하기 위한 스레드(또는 프로세스) 풀을 유지해야 하므로 부하가 늘어남.
특히 Oracle, PostgreSQL 등 Process 기반 서버는 프로세스 수가 커지는 문제도 있음.
3. 수명
커넥션은 애플리케이션 측에서 종료(close)하거나, 서버 측에서 타임아웃(Idle Timeout) 등이 발생하면 종료될 수 있음.
“짧은 생명(cycle)”의 커넥션을 빈번히 생성·종료하는 것은 오버헤드가 큼.
커넥션 : 커넥션 풀
1. 커넥션 재사용
많은 서비스에서 Connection Pool을 사용해 미리 일정 개수의 DB 커넥션을 열어두고, 필요할 때만 가져다 쓰고 반환함.
매 요청마다 새 커넥션을 만드는 대신, 이미 열린 커넥션을 재사용하면 커넥션 생성/해제 오버헤드가 크게 감소함.
2. 최대 풀 크기(Max Pool Size)
풀 크기를 너무 작게 잡으면 애플리케이션이 대기 시간이 길어질 수 있고, 너무 크게 잡으면 DB 서버가 커넥션을 너무 많이 처리해야 해 병목이 발생할 수 있음.
적절한 풀 크기 설정은 DB 서버 성능, 애플리케이션 트래픽 패턴 등에 따라 결정해야 함.
세션 : 정의 및 역할
1. 논리적 DB 사용자 맥락
세션은 DBMS 내부에서 사용자 인증 정보(UID), 트랜잭션 상태, 세션 변수, 임시 테이블, 커서(Cursor) 정보 등 “세션 전용 상태”를 보관하기 위한 구조임.
예를 들어, SELECT USER()를 실행하면 해당 세션의 사용자가 누구인지 확인 가능.
2. 트랜잭션 관리 단위
세션은 보통 트랜잭션의 범위를 결정하는 단위이기도 함.
BEGIN/COMMIT/ROLLBACK 명령은 세션 단위로 적용됨.
3. DBMS별 세션 개념
Oracle: 세션과 프로세스가 1:1 매핑되는 구조(SERVER PROCESS)와 SGA/UGA 개념이 존재.
PostgreSQL: 클라이언트 1개마다 프로세스 1개가 뜨는 구조이므로, “프로세스=세션”이라 볼 수 있음.
MySQL: 한 커넥션당 한 세션이 기본이지만, 커넥션 풀 레벨에서 논리 세션을 분리할 수 있는 기능이 등장하기도 함(MySQL 8.x 일부 기능).
세션 : 세션과 커넥션의 관계
1. 일반적 상황: 1 커넥션 : 1 세션
대부분의 DBMS에서, “커넥션이 생성되면 동시에 세션도 생성”되어 동일한 수명을 갖음.
커넥션이 끊어지면 세션도 종료됨.
2. 멀티플렉싱(multiplexing) or ‘Session Pool’
일부 미들웨어 또는 드라이버에서 한 물리 커넥션 위에 다중 논리 세션을 맺는 기술이 있을 수 있음
예를 들어, Oracle MTS(Multi-Threaded Server), multiplexing middleware 등.
대규모 다중 접속 환경에서 “커넥션 수는 제한”하고, 세션은 논리적으로 분할해 관리할 수도 있음.
3. Connection Pool vs. Session
Connection Pool은 물리 커넥션을 재사용하는 개념,
세션은 DB 쿼리 실행 상태나 트랜잭션 맥락을 유지하는 논리적 컨텍스트이므로,
일반적으로 Pool에서 한 커넥션을 빌려오면, 해당 커넥션과 연결된 “세션 컨텍스트”도 함께 사용하게 됨.
트랜잭션, 세션, 커넥션의 상호작용
1. 트랜잭션은 세션 단위
세션이 시작되면(=커넥션 성립), 기본적으로 “오토커밋(autocommit)”이 ON인 상태일 수 있고,
세션 단위로 명시적인 트랜잭션을 시작(BEGIN)하고, 커밋(COMMIT) 또는 롤백(ROLLBACK)을 할 수 있음.
한 세션 내에서 여러 트랜잭션이 연속해서 일어날 수 있고, 트랜잭션 중에도 SQL을 여러 개 실행할 수 있음.
2. 커넥션 종료 시 트랜잭션 처리
커넥션이 정상적으로 종료될 때, 보통 DBMS는 해당 세션의 모든 트랜잭션을 자동으로 롤백하거나 자동 커밋 등의 규칙으로 정리함(DBMS마다 차이).
강제 종료(네트워크 끊김 등) 시에는 DBMS가 인지하는 순간 해당 세션은 롤백되어 일관성 유지를 함.
3. Isolation Level, Session 변수
세션마다 격리 수준(Isolation Level) 설정이나 SET session_var = ... 같은 세션 전용 변수를 설정해둘 수 있음.
커넥션 풀에서 재사용되는 커넥션이라면, 이전 사용자의 세션 설정이 남지 않도록 RESET 등을 수행하여 세션 상태를 초기화해야 함.
운영 및 설계 시 고려 사항
1. 커넥션 수 관리
DB 서버의 커넥션 제한(max_connections 등)을 초과하지 않도록 하고, 필요한 만큼만 커넥션 풀을 설정해야 함.
너무 많은 커넥션이 동시에 살아 있으면 OS 차원 프로세스/스레드가 과도하게 늘어나고, 컨텍스트 스위치 비용 등이 증가함.
2. Idle 세션 모니터링
연결된 뒤 실제로 쿼리를 거의 보내지 않는 유휴(Idle) 세션이 많아지면 리소스 낭비가 심해짐.
DBA는 주기적으로 모니터링하여 불필요한 세션을 강제로 종료하거나, 애플리케이션 측에서 세션 관리를 개선하도록 권고할 수 있음.
3. Connection Pool 최적화
풀 크기, 연결 유지 시간, Idle Timeout, Validate Query 등의 파라미터를 통해 오랜 시간 쓰이지 않는 커넥션이나 깨진 커넥션을 효율적으로 정리해야 함.
4. Stateless / Stateful 디자인
웹 애플리케이션에서는 보통 “Stateless” 방식으로 각 요청마다 DB 커넥션을 짧게 열고 닫거나 Pool에서 빌려 쓰는 패턴이 일반적임.
세션에 많은 상태 정보를 저장해야 하는 경우(특수 환경)엔 별도의 “세션 저장소”나 전용 DB 세션 모드를 고려할 수 있음.
데이터베이스별 예시
1. Oracle
프로세스 기반 아키텍처(DEDICATED SERVER)에서, 클라이언트 커넥션 1개당 서버 프로세스 1개가 대응되고, 그 내부에서 세션이 유지됨.
MTS(Multi-Threaded Server)나 Connection Pool 기능으로 프로세스 수를 제어해 다중 사용자를 처리할 수도 있음.
2. PostgreSQL
기본적으로 1 커넥션당 1 OS 프로세스(postgres) 방식.
세션 = 프로세스 로직이지만, pgBouncer 같은 외부 커넥션 풀러를 통해 프로세스 수를 줄이거나 세션 멀티플렉싱 가능.
3. MySQL(InnoDB)
1 커넥션당 1 스레드(스레드 풀 옵션 사용 시 스레드가 다를 수도 있음).
세션은 커넥션을 통해 생성·유지되며, 연결 종료 시 세션도 종료.
MySQL 8.0에서 “Thread Pool” 기능을 사용할 수 있고, 대부분 JDBC/HikariCP 등 애플리케이션 쪽에서 커넥션 풀링을 함.
4. SQL Server
기본적으로 스레드 기반 구조로, 1 커넥션당 1 스레드(쿼리 실행 시), 하지만 내부적으로 스레드 풀 관리(Worker Thread)로 최적화함.
“세션”은 SPID(Session Process ID)로 식별되며, DMVs를 통해 세션 상태를 모니터링할 수 있음.
요약
1. 커넥션(Connection)
클라이언트-DB 서버 간의 물리적/논리적 통신 채널.
생성/해제 시 시스템 자원(스레드, 프로세스, 메모리) 소모가 크므로, 커넥션 풀로 재사용하는 것이 일반적.
2. 세션(Session)
DBMS 내부에서 특정 사용자/프로세스의 실행 상태(트랜잭션 상태, 세션 변수, 임시 오브젝트 등)를 유지하는 논리적 컨텍스트.
주로 1 커넥션당 1 세션이 대응되지만, 일부 환경에서는 하나의 물리 커넥션 위에 여러 세션을 멀티플렉싱할 수도 있음.
운영 측면에서는 너무 많은 커넥션(=세션)으로 인한 리소스 소비, Idle 세션 증가, 트랜잭션이 종료되지 않아 락 점유 등의 문제가 발생하지 않도록 정기 모니터링과 풀 전략을 적절히 세우는 것이 핵심임.
결론적으로, 커넥션과 세션을 혼동하지 않고 각자의 역할과 자원 소모를 이해함으로써, 안정적인 DB 운영, 효율적 동시성 처리, 적절한 풀링 전략을 구축하는 것이 데이터베이스 성능과 안정성을 높이는 핵심 전략임.
'Database > SQL' 카테고리의 다른 글
[SQL] A/B 테스트 (0) | 2025.01.22 |
---|---|
[SQL] 데이터베이스의 커넥션 풀 (0) | 2025.01.21 |
[SQL] 쿼리 캐시 (0) | 2025.01.20 |
[SQL] 스토리지 엔진 (0) | 2025.01.20 |
[SQL] MySQL 옵티마이저 (0) | 2025.01.20 |