Aurora 메이저 버전 업그레이드는 성공한 다음에 터진다

오픈을 앞두고 Aurora를 세 번 건드렸다. 리더 추가, 메이저 버전 업그레이드, 비밀번호 관리 방식 변경. 셋 다 되돌리기가 어렵거나 불가능한 작업이라 준비에 시간을 많이 썼는데, 그런데도 예상 못 한 게 나왔다. 특히 메이저 업그레이드는 성공한 다음에 터진다. 옵션 그룹이 조용히 바뀌어 있기 때문이다.

리더를 붙였는데 트래픽이 안 갔다

읽기 부하를 나누려고 리더 인스턴스를 추가했다. 코드도 맞고 엔드포인트도 생겼는데 리더로 쿼리가 안 갔다.

원인은 JVM의 DNS 캐시였다.

리더가 생기기 전에 앱이 cluster-ro- 엔드포인트를 한 번이라도 조회했다면, 그 시점엔 그게 writer를 가리킨다. JVM이 그걸 캐시하고 있으면 리더가 생겨도 계속 writer로 간다.

리더를 추가하면 앱을 재기동한다. 이게 절차의 일부다.

EC2와 DB를 한 apply에서 같이 재부팅하지 않는다

이것도 한 번 겪었다. 증상이 특이해서 원인을 찾는 데 시간이 걸렸다.

Tomcat은 살아 있는데 모든 요청이 404.

무슨 일이냐면,

1. apply가 EC2와 RDS를 동시에 건드린다
2. Tomcat이 먼저 올라와 DB를 찾는다
3. 그런데 Aurora는 아직 변경 중이다
4. Spring 컨텍스트가 죽은 채 WAR만 전개된다
5. 서블릿 컨테이너는 정상이라 프로세스는 살아 있고, 매핑이 없으니 전부 404

RDS를 먼저 끝내고 EC2를 나중에. 순서를 나누는 것 말고 방법이 없다.

메이저 업그레이드 — 다운그레이드는 없다

8.0에서 8.4로, 그리고 운영 Aurora도 메이저 버전을 올렸다.

자동 스냅샷을 믿지 않는다

RDS는 업그레이드 직전에 스냅샷을 하나 뜬다. 그런데 그게 automated 타입이라 보존 기간이 지나면 사라진다.

되돌릴 수 없는 작업 앞에서는 manual 스냅샷을 따로 뜬다.

그리고 복원한다고 원래대로 돌아오는 게 아니다. 복원은 새 인스턴스라 엔드포인트가 바뀐다. 앱 설정을 전부 바꿔야 한다는 뜻이다. "스냅샷이 있으니 괜찮다"와 실제 복구 절차 사이의 거리가 꽤 멀다.

업그레이드는 성공한 뒤에 터진다

메이저 업그레이드는 파라미터 그룹만이 아니라 옵션 그룹도 바꾼다. RDS가 default:mysql-8-0 → default:mysql-8-4로 알아서 바꾸는데, 코드는 낡은 채 남는다.

업그레이드 자체는 성공한다. 그리고 다음 apply가 거부된다.

InvalidParameterCombination

시점이 떨어져 있어서 원인이 안 보인다. 업그레이드 후에는 파라미터 그룹·옵션 그룹을 실물과 대조하는 단계가 필요하다.

engine_version을 리터럴로 두면 다운그레이드를 시도한다

버전은 클러스터 속성이고 인스턴스가 따라 올라간다. 그런데 인스턴스 코드에 버전을 리터럴로 적어 뒀으면 코드만 낡는다. 2편에서 ami를 하드코딩했던 것과 같은 함정이다 — 실물이 앞서 가고 코드가 뒤에 남는다.

그래서 업그레이드 직후 plan이 다운그레이드를 들고 온다.

engine_version = aws_rds_cluster.this.engine_version   # 참조로 둔다

비밀번호 관리를 바꾸는 순간 기존 비밀번호가 죽는다

마스터 비밀번호를 Secrets Manager 관리로 켜면, 켜는 순간 기존 비밀번호가 무효가 된다.

켜기 전에 사용처를 전부 확인해야 한다.

• 배포 스크립트
• 앱 설정 파일
• 그리고 현재 붙어 있는 세션(PROCESSLIST)

3번을 빼먹기 쉽다. 지금 안 끊어져도 다음 재연결에서 끊긴다.

백업 보존 기간은 소급되지 않는다

보존 기간을 7일로 늘렸다. 그런데 이건 스냅샷 개수가 아니라 복구 가능 시점(PITR) 창을 정하는 값이고, 소급되지 않는다.

늘려도 EarliestRestorableTime은 그대로다. 거기서부터 앞으로 자란다. "7일로 늘렸으니 일주일 전으로 돌아갈 수 있다"가 아니다.

Terraform 쪽 함정 두 가지

apply_immediately를 되돌릴 때 null은 안 된다

프로바이더 스키마상 computed: true라 null은 "기존 값 유지"로 해석된다. state에 true가 남고 plan은 No changes로 보인다.

false를 명시해야 실제로 꺼진다.

이게 왜 중요하냐면, ApplyImmediately의 기본 원칙은 "나머지 변경은 정비 창까지 대기"이기 때문이다. 즉시 반영되는 건 삭제 방지·마스터 비밀번호 정도다. 켜 둔 걸 모르고 있으면 의도치 않은 시간에 변경이 적용된다.

이미 밀린 변경이 있으면 설정을 바꾸지 말고 CLI로 흘려보낸다.

aws rds modify-db-cluster ... --apply-immediately

설정 변경은 인스턴스를 하나씩 처리하지 않는다

향상된 모니터링과 Performance Insights를 여러 대에 한 번에 켰다. 재기동이 없는 변경이라 동시 modifying이 무해했다(reboot 이벤트 없음).

하지만 인스턴스 클래스처럼 재기동을 부르는 변경이면 전부 한꺼번에 내려간다. 그런 변경은 -target으로 나누거나 순서를 강제해야 한다.

"지난번엔 괜찮았는데"가 통하지 않는 지점이다. 재기동 여부로 갈린다.

정비 창을 어디에 둘 것인가

감이 아니라 실측으로 정했다. 7일치 시간대별 쿼리 처리량 평균인데, 지표를 켜 뒀기 때문에 셀 수 있었던 값이다.

03시  최저
02시  최저의 1.4배
04시  최저의 3.1배   ← 배치가 도는 시간

그래서 04시를 피하고 02:30~03:00으로 잡았다.

요일은 월요일 새벽으로 뒀다. 문제가 생겨도 평일 업무 시작 전에 발견하기 위해서다. 금요일 밤이 조용하다고 거기 두면, 문제가 생겼을 때 아무도 없다.

백업 창과는 2시간 30분 간격을 뒀다. 둘은 겹치면 안 된다.

정리

• 리더를 추가하면 앱을 재기동한다. JVM이 DNS를 캐시한다.
• EC2와 RDS를 한 apply에서 같이 재부팅하지 않는다. Tomcat이 살아 있는 404가 나온다.
• 메이저 업그레이드 전에는 manual 스냅샷. 자동 스냅샷은 사라지고, 복원은 엔드포인트가 바뀐다.
• 업그레이드는 성공한 뒤에 옵션 그룹 불일치로 터진다.
• 비밀번호 관리 전환은 켜는 순간 기존 비밀번호를 죽인다.
• 백업 보존 기간은 소급되지 않는다.
• 정비 창은 감이 아니라 실측 처리량으로 고른다.

다음 편은 IAM이다. 디스크에서 장기 자격증명을 전부 없앴다.