GeoServer 장애를 DB Pool과 NFS 관점에서 분리해서 보는 법

GeoServer 운영 중 다음 증상이 비슷한 시점에 나타난다고 하자.

응답 지연
PostgreSQL idle connection 증가
간헐적인 layer load 실패
NFS Stale file handle
일부 요청 timeout

증상이 한꺼번에 보이면 하나의 root cause라고 생각하기 쉽다.

예를 들어:

DB connection이 많아서 GeoServer가 느려졌고, 그것 때문에 NFS 오류도 난 것 아닐까?

하지만 이런 식으로 증상을 연결하면 진단이 오히려 느려질 수 있다.

핵심은 각 증상을 먼저 계층별로 분리하는 것이다.

1. 먼저 요청 경로를 계층으로 나눈다

GeoServer 요청 하나가 지나가는 경로를 단순화하면 다음처럼 볼 수 있다.

Client
↓
Ingress / Web Server
↓
GeoServer
↓
JDBC Pool
↓
PostgreSQL
 
GeoServer
↓
File System / NFS

DB와 NFS는 같은 GeoServer에서 사용되더라도 서로 다른 의존성이다.

따라서 두 오류가 동시에 보였다고 바로 동일 원인이라고 결론내리면 안 된다.

2. PostgreSQL idle connection이 많다고 바로 leak은 아니다

운영 화면에서 idle connection이 수백 개 보이면 문제처럼 느껴진다.

하지만 먼저 이 계산을 해야 한다.

예상 최대 connection
=
application instance 수
×
각 instance pool size

예를 들어 인스턴스가 여러 개라면 idle connection도 자연스럽게 늘어날 수 있다.

따라서 단순 count보다 상태를 봐야 한다.

active
idle
idle in transaction
waiting
long-running query

특히 idle in transaction은 일반 idle과 다르게 봐야 한다.

3. Connection Pool 설정은 역할이 다르다

먼저 어느 풀을 보고 있는지부터 정해야 합니다. GeoServer에서 PostGIS 데이터스토어를 추가하면 GeoServer가 Apache Commons DBCP 기반의 내부 풀을 직접 만듭니다. HikariCP가 아닙니다. 그래서 웹 관리 화면에서 보이는 이름도 다릅니다.

GeoServer 데이터스토어 화면	뜻	HikariCP에서 같은 역할
`max connections`	이 스토어가 가질 수 있는 최대 연결 수	`maximumPoolSize`
`min connections`	유휴 상태로 유지할 최소 연결 수	`minimumIdle`
`Connection timeout`	풀에서 연결을 얻으려 기다리는 최대 시간	`connectionTimeout`
`Max connection idle time`	안 쓰는 연결을 언제 정리할지	`idleTimeout`
`validate connections`	빌려주기 전에 살아 있는지 확인할지	—

HikariCP 이름을 찾고 있다면 그건 JNDI로 데이터소스를 톰캣 쪽으로 뺐을 때입니다. GeoServer 기본 구성에서는 그 이름들이 나오지 않으므로, 설정 파일을 뒤지기 전에 어느 쪽인지부터 확인하세요.

이름이 무엇이든 역할은 넷으로 나뉩니다 — 얼마나 기다릴지, 몇 개까지 가질지, 언제 버릴지, 빌려주기 전에 확인할지. “timeout을 늘리면 되겠지”처럼 한 값만 올리면 증상이 늦게 나타날 뿐 원인은 그대로입니다.

풀 지표만 보면 안 되는 이유

애플리케이션 관점에서:

pool active
pool idle
pool pending
connection acquisition latency

를 보고,

DB 관점에서는:

session count
wait event
query latency
lock
transaction state

를 같이 본다.

두 계층을 함께 보면:

DB가 느려서 pool이 고갈되는지
pool 설정이 작아서 대기하는지
connection이 반환되지 않는지

를 구분할 수 있다.

4. NFS Stale File Handle은 별도 트랙으로 본다

Stale file handle은 일반적으로 파일 시스템 계층 문제다.

예를 들어 다음 상황을 확인한다.

NFS server remount
export 재구성
inode 변경
파일/디렉터리 교체
오래 열린 file descriptor
container/node 재시작

JDBC pool 값을 바꿨다고 NFS stale handle이 해결되는 것은 아니다.

따라서 별도 incident track으로 보는 편이 안전하다.

5. “같은 시간”은 상관관계일 뿐이다

운영 장애에서 흔한 실수다.

10:05 DB connection 증가
10:06 NFS 오류
10:07 API latency 증가

시간이 비슷하다고 원인 관계가 자동으로 생기지는 않는다.

가능한 시나리오는 여러 개다.

A가 B를 유발
B가 A를 유발
공통 원인 C가 둘 다 유발
서로 독립적인 두 장애가 우연히 겹침

그래서 timestamp만으로 root cause를 결정하지 않는다.

6. 계층별 최소 증거를 만든다

각 계층마다 최소한 하나의 독립 지표를 둔다.

HTTP
- latency / error rate
 
GeoServer
- request/thread state
 
Pool
- active / idle / pending
 
PostgreSQL
- sessions / locks / query latency
 
NFS
- mount state / kernel log / file access
 
Node
- CPU / memory / IO

이렇게 보면 한 계층의 이상이 다른 계층으로 어떻게 전파됐는지 추적하기 쉽다.

장애 분석 순서

실무적으로는 다음 순서가 유용하다.

1. 사용자 증상 확인
2. HTTP latency/error 확인
3. GeoServer 내부 상태 확인
4. JDBC pool 상태 확인
5. PostgreSQL session/query 확인
6. NFS 오류 별도 확인
7. 공통 timestamp로 correlation
8. 변경 하나씩 적용
9. 동일 지표로 전후 비교

흔한 오판

idle connection이 많으니 DB leak이다

반드시 그렇지 않다. instance 수와 pool size부터 계산해야 한다.

timeout을 늘리면 해결된다

원인을 늦게 드러나게 만들 뿐일 수 있다.

NFS 오류와 DB 오류가 같은 시간에 났으니 같은 원인이다

증거가 없으면 단순 상관관계다.

계층 분리가 통하지 않는 경우

증상 다섯 개를 한 이야기로 묶지 않는 것이 이 글의 요지지만, 그 대가가 있습니다.

계층마다 지표를 두면 장애 중에 볼 대시보드가 여섯 개가 됩니다. 실제 인시던트에서는 먼저 되돌릴 변경 하나를 찾는 편이 빠를 때가 많습니다
이 분리는 원인이 둘 이상일 때 값이 납니다. 원인이 하나인 흔한 장애에서는 오히려 진단이 느려집니다
GeoServer 기본 구성은 DBCP라 위에 적은 지표 이름이 그대로 나오지 않습니다. 이름을 맞추는 데 시간을 먼저 씁니다
NFS를 쓰지 않는 구성이라면 이 글의 절반은 해당되지 않습니다
GeoServer 사용자 문서 — 데이터스토어별 연결 설정
PostgreSQL 통계 수집기 문서 — pg_stat_activity 의 state 값 해석

정리하면

복합 장애에서 중요한 것은 증상을 빨리 하나의 이야기로 묶는 것이 아니다.

먼저 분리해야 한다.

GeoServer
JDBC Pool
PostgreSQL
NFS
Node

각 계층에서 독립적인 증거를 확보한 뒤 인과관계를 연결해야 한다.

운영 장애는 “그럴듯한 이야기”보다 계층별 측정값이 더 중요하다.

AI 자동화 지식 블로그