DB 연결 풀을 인스턴스마다 20개에서 100개로 늘리려 합니다. 값 자체는 유효한데 어떤 장애가 생길 수 있고 어떻게 안전하게 적용하나요?

설정도 실행 동작을 바꾸므로 코드와 비슷한 검증과 추적이 필요합니다. 형식이 맞는 것과 운영상 안전한 것은 다릅니다. 예를 들어 연결 풀 크기가 숫자로 유효해도 전체 인스턴스 합계가 DB 한도를 넘으면 장애가 날 수 있습니다.

예를 들어 인스턴스당 풀 상한을 20에서 100으로 늘리고 인스턴스가 10개면 설정상 최대 연결은 200개에서 1,000개로 바뀝니다. 이것은 실제로 즉시 1,000개를 연다는 뜻은 아니지만, 부하가 늘 때 DB가 감당해야 할 상한이 달라진다는 뜻입니다. 다른 서비스가 쓰는 연결을 제외한 예산보다 크다면 설정을 거절하거나 전체 동시성을 제한하겠습니다.

저는 설정 스키마로 타입·범위·필수값을 확인하고, 서로 의존하는 값은 함께 검증하겠습니다. 요청 타임아웃보다 내부 재시도 시간이 길거나 캐시 한도가 메모리 예산을 넘는 조합도 거절해야 합니다. 시작 시 잘못된 설정이면 조용히 기본값으로 실행하기보다 명확히 실패하는 편이 안전한 경우가 많습니다. 동적 설정은 마지막 정상 버전 유지와 변경 실패 알림을 둘 수 있습니다.

변경은 작성자·버전·적용 시점을 남기고 일부 인스턴스에서 먼저 확인하겠습니다. 모든 인스턴스가 같은 순간에 바뀐다고 가정하지 않아야 합니다. 설정 저장소 장애 때 새 값을 못 받는 것과 기존 정상 동작을 계속할 수 없는 것은 구분하겠습니다. 테스트에서는 잘못된 단일 값뿐 아니라 유효하지만 위험한 조합과 전파 지연을 재현합니다. 비밀값은 검증 로그에도 원문을 남기지 않겠습니다.

전체 연결 예산을 계산합니다

인스턴스가 10개일 때 풀 상한은 20개에서 100개로 바뀌며 잠재적 연결 수는 200개에서 1,000개가 됩니다. 자동 확장으로 인스턴스가 늘면 이 상한은 더 커집니다. DB 최대 연결 수에서 관리용·마이그레이션·다른 서비스 몫과 여유를 빼고도 새 상한이 들어오는지 계산해야 합니다. 연결을 많이 열어 풀 대기는 줄었지만 DB CPU, 락 대기, 쿼리 지연, 애플리케이션 스레드가 악화되면 풀 확대는 실패입니다.

조합과 적용 단계를 검증합니다

풀 크기, 워커 수, 재시도 횟수, 요청 timeout은 각각 유효해도 곱해진 동시성이 DB와 하위 API 한도를 넘을 수 있습니다. 시작 시 필수 연결·비밀값이 틀리면 위험한 기본값으로 실행하지 않고 실패시키며, 동적 설정은 버전·마지막 정상값·적용 인스턴스를 기록합니다. 여러 설정을 원자적으로 바꿀 수 없다면 먼저 구버전이 새 값을 읽을 수 있게 하고 중간 조합도 안전하게 만듭니다. canary에서 연결 대기·DB 포화·오류율을 본 뒤 확대하고, 원복할 때 기존 연결 drain과 포화 회복 시간까지 확인하겠습니다.

구체적인 경계 사례

관련 설정을 요청 도중 여러 번 읽으면 timeout은 새 값이고 retry 횟수는 옛 값인 혼합 조합을 볼 수 있습니다. 검증된 설정 묶음을 불변 스냅샷으로 게시하고 요청 시작에 버전 하나를 잡아 끝까지 쓰게 할 수 있습니다. 보안상 즉시 회수해야 하는 권한·차단 정책은 긴 요청 스냅샷과 다른 갱신 계약을 둡니다.

시간 단위도 스키마에 포함합니다. 500이 밀리초인지 초인지, 0이 비활성인지 무제한인지가 라이브러리마다 다르기 때문입니다. 알 수 없는 키는 오타로 보아 거절할지 호환을 위해 경고할지 정하고, 실행 중 변경 가능한 값과 재시작이 필요한 값을 구분합니다. 실제 적용된 설정 버전을 비밀값 없이 상태 화면에 노출하면 저장소 값과 프로세스 값의 차이를 확인할 수 있습니다.