24장 최종 실전: 금요일 WAR와 인증서를 함께 교체한다
운영 변경 하나에 애플리케이션 1.0.0과 만료 18일 남은 인증서 교체가 함께 들어왔다. 가능하면 두 변경을 분리하는 것이 원인 격리에 유리하다. 불가피하게 같은 window에서 한다면 단계 사이 관찰점을 둔다.
변경 전
- 현재 WAR digest, Git commit, context, JVM과 Tomcat 버전을 기록한다.
- 현재 외부 인증서 serial, SAN, notAfter와 TLS 종료 지점을 기록한다.
- 0.9.0 rollback과 이전 인증서의 사용 가능성을 검증한다.
- DB migration이 양방향 호환인지 확인한다.
- 담당자, 승인자, rollback 결정 시각과 소통 채널을 정한다.
애플리케이션 배포
WAR checksum과 구조를 검증하고 green slot에 배포한다. 내부 health와 smoke 뒤 소량 traffic을 보내 오류율과 p95를 본다. 기준을 넘으면 인증서 작업을 시작하지 않고 앱부터 rollback한다.
인증서 교체
새 certificate의 SAN·기간·key·chain을 검증한다. Nginx라면 nginx -t, Tomcat이라면 keystore alias와 TLS 설정을 확인한다. reload 후 외부 SNI handshake에서 새 serial을 확인한다. 모든 DNS 대상 IP와 주요 클라이언트 경로를 확인한다.
완료
변경 ticket에 WAR digest, 새 certificate serial/notAfter, smoke 결과, 지표 dashboard, rollback 만료시각을 남긴다. 구버전 WAR와 인증서는 보존 정책이 끝날 때 안전하게 폐기한다. private key 백업을 일반 artifact 보관함에 두지 않는다.
졸업 기준
- 빌드한 WAR와 서버의 WAR가 같음을 digest로 증명할 수 있다.
javax/jakarta, 빌드 JDK/서버 JVM 경계를 설명할 수 있다.- health와 smoke, 외부 경로 검사의 차이를 말할 수 있다.
- TLS 종료 지점과 실제 교체 대상을 찾을 수 있다.
- 인증서의 SAN·기간·키·체인을 교체 전에 검증할 수 있다.
- reload 뒤 외부에서 serial을 확인하고 이전 상태로 rollback할 수 있다.