설정 적용은 파일 몇 개를 바꾸는 일이 아니라 검증된 desired bundle → 게시된 version → 각 프로세스의 applied version을 이동시키는 제어 흐름입니다. 이 세 상태를 분리하면 저장 성공을 서비스 적용 완료로 오해하지 않고, 총량 예산과 재시작 overlap까지 같은 변경 단위에서 판단할 수 있습니다.
인스턴스별 상한과 전체 resource budget
10개 instance의 pool 상한을 20→100으로 바꾸면 잠재 연결은 200→1000입니다. 즉시 모두 연결된다는 뜻은 아니지만 burst·scale-out·rolling overlap 때 도달할 상한이 달라집니다. DB 최대에서 관리·migration·다른 service·여유를 뺀 예산으로 검증합니다.
pool 대기가 줄어도 DB CPU·lock·query p99가 악화되면 성공이 아닙니다. worker·retry·fan-out·memory·deadline의 조합을 함께 검토합니다. 500의 시간 단위와 0의 비활성/무제한 의미, unknown key 정책도 schema에 포함합니다.
예산 계산은 정상 평균이 아니라 scale-out과 rolling overlap의 순간 상한으로 시작합니다. 10개 instance가 동시에 20개 연결을 만들 수 있는지, 새·옛 process가 겹칠 때 20개씩 두 세대가 필요한지, retry와 migration이 추가 연결을 만드는지를 같은 표에 놓아야 DB의 여유를 과대평가하지 않습니다.
개별 값·설정 묶음의 불변식
| 검사 | 예 |
|---|---|
| 타입·범위 | 음수 pool·누락 secret 거절 |
| 단위·특수값 | timeout ms·0의 의미 |
| 조합 | retry 총 대기가 요청 deadline 초과 |
| 전체 총량 | instance×pool+기타 연결 ≤ DB 예산 |
| 적용 가능성 | hot reload 또는 restart 필요 |
| 보안 | 검증 로그에 secret 원문 없음 |
프로세스가 시작할 때 필수 설정이 없거나 잘못되면 위험한 default(기본값)로 계속 실행하지 말고 시작을 실패시킬 수 있습니다. 이미 실행 중인 프로세스의 동적 갱신이 실패하면 마지막 정상값을 유지하면서 갱신 실패와 현재 적용 version(설정 묶음 버전)을 함께 노출합니다. 설정 저장소 장애와 기존 프로세스가 정상 설정으로 계속 동작하지 못하는 것은 다른 상태이므로 구분해 기록합니다.
검증 실패는 어떤 필드가 잘못됐는지와 어떤 조합 규칙이 깨졌는지를 구분해 반환해야 운영자가 secret 원문 없이 수정할 수 있습니다. 예를 들어 timeout 단위 오류는 타입 검증, retry 총 대기 초과는 조합 검증, 전체 연결 초과는 budget 검증입니다. 서로 다른 오류를 모두 “invalid config”로 뭉개면 안전한 수정 방향을 찾기 어렵습니다.
Bundle 완성과 Root 전환 순서
관련 timeout·retry·pool을 각각 즉시 읽게 두면 신timeout+구retry처럼 서로 다른 version의 값이 한 요청에 섞일 수 있습니다. 그래서 새 version의 immutable bundle(게시 후 내용을 바꾸지 않는 설정 묶음)을 모두 준비하고 전체 예산·조합을 확인한 다음, 읽는 쪽(reader)이 따라갈 root pointer를 한 번에 새 version으로 전환합니다.
저장소가 bundle 자체의 원자 갱신을 지원하지 않으면 version namespace에 완성본을 먼저 만든 뒤 작은 manifest만 바꾸어 reader가 완성된 묶음으로 이동하게 할 수 있습니다.
그림을 글로 읽기
- 새 설정 bundle·version 준비
- 타입·조합·전체 예산 검증
- root 게시·canary 적용
- instance별 실제 적용 version
- 사용자·DB 지표 확인 후 확대
- 새 설정 bundle·version 준비 → 타입·조합·전체 예산 검증: 완성된 값
- 타입·조합·전체 예산 검증 → root 게시·canary 적용: 유효 bundle만
- root 게시·canary 적용 → instance별 실제 적용 version: 전파 지연 있음
- instance별 실제 적용 version → 사용자·DB 지표 확인 후 확대: 효과 검증
요청 시작 시 root를 한 번 읽고 그 version의 bundle을 끝까지 사용하면 timeout·retry·pool이 서로 다른 시점의 값으로 섞이지 않습니다. 다만 보안 차단처럼 즉시 철회해야 하는 동작은 긴 request snapshot만 따라가게 두면 계속 허용될 수 있으므로, 별도 current policy(현재 정책) 검사를 요청 처리 경로에 둡니다. 아직 준비 중인 bundle은 일부 파일만 읽히지 않도록 완성 표시 전에는 reader가 접근하지 못하게 합니다.
v17을 읽는 요청이 시작된 뒤 root가 v18로 바뀌어도 그 요청은 v17의 timeout·retry·pool을 함께 사용하고, 다음 요청부터 v18 snapshot을 얻습니다. 다만 즉시 차단해야 하는 정책은 이 snapshot을 우회하는 current policy 검사가 필요합니다. 이 추적을 로그의 request ID와 config version으로 남기면 혼합 version 여부를 실제로 판별할 수 있습니다.
Restart 필요 설정과 프로세스 수명
새 process가 검증된 version으로 준비됐는지 확인한 다음 옛 process의 신규 요청 수락을 막고, 이미 받은 요청이 끝날 때까지 drain합니다. 이때 새·옛 process가 함께 살아 있는 동안의 총 resource와 protocol/data 호환을 계산해 두 version이 동시에 필요한 예산을 넘지 않는지 봅니다. pool limit을 낮췄다고 이미 빌린 연결이 강제로 반환된 것은 아니므로, 신규 대여부터 줄이고 각 작업이 실제로 끝난 뒤 연결을 회수합니다.
rollback 때 새 데이터가 옛 코드로 읽히는지도 확인해야 합니다. 단순 설정 값 원복이 포화·남은 연결·늦은 retry를 즉시 없애지는 않습니다. 작성자·version·적용 시점·실패 instance·마지막 정상값을 secret 없이 기록합니다.
restart 장애를 진단할 때는 새 process 준비, 신규 요청 수락 여부, 옛 process의 drain 완료, 두 세대의 총 자원, rollback 호환성 순서로 확인합니다. pool 상한을 낮춘 뒤에도 이미 대여한 연결은 남을 수 있으므로 “설정값이 낮아졌다”와 “현재 사용량이 내려갔다”를 같은 지표로 처리하지 않습니다.
Canary와 앱·하위 시스템 지표
유효하지만 위험한 조합·전파 지연·store 장애·restart overlap·limit 감소·잘못된 bundle을 시험합니다. connection wait·DB CPU/lock·사용자 오류·p99·복귀 시간을 봅니다. 이 노트는 설정 적용 설계이며 운영 DB pool 변경을 실행한 결과는 아닙니다.
canary의 성공 조건은 설정 저장 성공이 아니라 connection wait, DB lock, 오류율, p99가 기준선 안에 있고 적용 version이 의도한 값인 것입니다. 완화가 필요한 경우에는 확대를 멈추고 마지막 정상 version으로 되돌린 뒤, 남은 연결과 retry가 가라앉는 시간까지 확인해야 rollback 완료라고 부를 수 있습니다.