RDS 보류 유지보수 안전 적용: 11개 작업을 나눈 기준

RDS 콘솔을 열었을 때 유지보수 알림이 하나가 아니었다.

9개 리소스에 11개 액션이 보류된 상태였다.

RDS는 AWS가 관리하는 관계형 데이터베이스 서비스인 Amazon Relational Database Service의 약자다.

운영체제 업데이트처럼 피할 수 없는 작업도 있었고, 재부팅이나 플랫폼 변경처럼 서비스 연결에 영향을 줄 수 있는 항목도 섞여 있었다.

여기서 가장 간단해 보이는 선택은 Apply Immediately였다.

지금 적용하라는 버튼을 누르고 모든 항목이 끝나기를 기다리는 방식이다.

하지만 버튼 하나가 여러 데이터베이스에서 같은 위험을 만든다고 볼 수는 없었다.

어떤 서비스는 Writer와 Reader가 분리된 클러스터였고, 어떤 서비스는 단일 Writer 한 대에 의존했다.

Writer는 데이터를 기록하는 DB 인스턴스이고 Reader는 읽기 요청을 나눠 받는 복제 인스턴스다.

BI 도구가 쓰는 단일 DB에는 pending-reboot 상태와 되돌리기 어려운 플랫폼 변경도 함께 있었다.

나는 11개 작업을 일괄 적용하지 않고, 실패했을 때의 영향과 복구 난이도에 따라 순서를 나눴다.

예를 들어 상품 조회용 Reader가 잠시 재연결되는 상황과 주문을 기록하는 단일 Writer가 멈추는 상황은 같은 “DB 유지보수”라도 사용자 영향이 다르다.

전자는 읽기 요청을 다른 복제본으로 보낼 여지가 있지만, 후자는 새 주문을 받을 경로가 사라질 수 있다.

이 글은 장애를 해결한 회고가 아니다.

기존 운영 환경에 쌓인 유지보수 항목을 발견한 뒤, 실제 실행 전에 중단 조건과 복구 절차를 만든 예방 작업이다.

먼저 확인할 수 있는 사실과 권장안을 나눴다

업무 기록에서 확정할 수 있는 범위는 다음과 같다.

• 조사 대상은 RDS 리소스 9개와 보류 유지보수 액션 11개였다.
• 개발 환경 Canary를 먼저 적용하고 24시간 관찰하도록 설계했다.
• 운영 클러스터와 단일 Writer 서비스를 같은 묶음으로 다루지 않았다.
• 스냅샷, 중단 조건, Smoke test, 적용 후 관찰 항목을 런북에 넣었다.
• 애플리케이션에는 Writer·Reader 엔드포인트 분리와 최대 3회 연결 재시도 설정이 있었다.

Canary는 영향이 작은 대상에 먼저 변경을 적용해 문제를 일찍 발견하는 방식이다.

Smoke test는 서비스가 시작되고 핵심 기능이 동작하는지 짧게 확인하는 최소 검증이다.

반대로 확인되지 않은 내용도 분명하다.

업무 상태는 완료로 남아 있지만, 11개 액션이 운영에 모두 적용됐다는 RDS 이벤트와 변경 기록은 현재 노트에 없다.

그래서 “9개 DB의 유지보수를 무중단으로 끝냈다”고 쓰지 않는다.

내가 완료한 것으로 확인되는 성과는 위험도가 다른 리소스를 분류하고 실행 가능한 런북을 만든 일이다.

먼저 11개 액션을 같은 표에 올렸다

AWS는 보류 유지보수 상태를 required, available, next window, in progress 등으로 구분한다.

required는 무기한 미룰 수 없는 작업이고, available은 사용자가 적용 시점을 선택할 수 있는 항목이다.

이 상태를 보지 않고 알림 개수만 세면 긴급한 작업과 선택 가능한 작업이 섞인다.

지금 같은 조사를 다시 한다면 AWS CLI로 원본 목록부터 저장한다.

AWS CLI는 웹 콘솔 대신 명령으로 AWS 자원을 조회하고 변경하는 도구다.

aws rds describe-pending-maintenance-actions

describe-pending-maintenance-actions는 보류된 액션과 대상 리소스를 조회한다.

이 명령 자체는 유지보수를 적용하지 않는 읽기 작업이다.

출력에는 리소스의 고유 식별자가 포함될 수 있으므로 공개 글이나 공유 문서에서는 실제 값을 가려야 한다.

각 리소스의 현재 구성과 함께 보기 위해 다음 조회도 사용한다.

aws rds describe-db-instances \
  --query "DBInstances[].{
    id:DBInstanceIdentifier,
    multiAZ:MultiAZ,
    engine:Engine,
    pending:PendingModifiedValues,
    window:PreferredMaintenanceWindow
  }"

describe-db-instances는 DB 인스턴스의 구성 정보를 읽는다.

--query는 서버의 값을 바꾸는 옵션이 아니라, 받은 JSON에서 필요한 필드만 골라 출력하는 필터다.

여기서는 Multi-AZ 여부, 엔진, 이미 대기 중인 변경과 유지보수 창을 함께 보려고 사용했다.

Multi-AZ는 서로 다른 가용 영역에 대기 인스턴스를 두어 장애 조치를 지원하는 구성이다.

목록에는 최소한 다음 열이 필요하다.

유지보수 알림의 이름만으로 중단 시간을 단정해서도 안 된다.

같은 엔진 패치라도 배포 방식, 현재 트랜잭션과 함께 대기 중인 설정에 따라 영향이 달라진다.

그래서 각 액션을 다음 세 질문으로 다시 분류했다.

1. 지금 미룰 수 있는가, AWS가 정한 기한 안에 반드시 적용해야 하는가
2. 재부팅·장애 조치·엔진 변경 중 어떤 동작이 예상되는가
3. 실패하면 기존 인스턴스로 돌아갈 수 있는가, 새 인스턴스로 복원해야 하는가

Apply Immediately가 한 항목만 적용하는 버튼은 아니다

RDS 인스턴스를 수정할 때 Apply Immediately를 선택하면 방금 고른 설정만 즉시 바뀐다고 생각하기 쉽다.

AWS 공식 문서에 따르면 큐에 있던 다른 보류 변경도 함께 적용될 수 있다.

그 안에 중단이 필요한 항목이 있으면 기대하지 않았던 시점에 연결이 끊길 수 있다.

이번에 플랫폼 변경과 pending-reboot를 따로 분리한 이유도 여기에 있다.

pending-reboot는 설정 변경이 저장됐지만 DB를 다시 시작해야 실제로 반영된다는 상태다.

버튼을 누르기 전에는 “어떤 변경을 적용할 것인가”만 보지 않고 “이미 무엇이 함께 대기 중인가”를 확인해야 한다.

운영 환경에서는 유지보수 대상과 PendingModifiedValues를 한 장의 실행표에 넣는다.

즉시 적용이 필요한 사유가 없다면 예정된 유지보수 창을 이용하고, 필수 항목이라면 먼저 개발 환경에서 중단 시간을 측정한다.

Multi-AZ여도 연결은 끊길 수 있다

Multi-AZ는 무중단을 보장하는 이름이 아니다.

AWS는 일반적인 장애 조치 시간이 60~120초라고 안내하지만, DB 활동량과 복구해야 할 트랜잭션에 따라 더 길어질 수 있다고 설명한다.

60~120초는 이 작업의 실제 결과나 보장 시간이 아니라 AWS가 제시한 일반 범위다.

장애 조치가 일어나면 애플리케이션은 기존 연결을 정리하고 DNS가 가리키는 새 대상에 연결해야 한다.

DNS는 사람이 읽는 주소를 실제 네트워크 주소로 찾게 해 주는 이름 체계다.

연결 풀은 미리 만든 DB 연결을 보관해 재사용하는 애플리케이션 구성인데, 오래된 연결을 계속 들고 있으면 새 Writer로 전환된 뒤에도 오류가 이어질 수 있다.

당시 애플리케이션 설정에는 연결 오류를 최대 3회 재시도하는 조건이 있었다.

재시도는 새 연결을 만드는 데 도움을 줄 수 있지만, 끊긴 트랜잭션 전체를 자동으로 안전하게 다시 실행하지는 않는다.

예를 들어 외부 결제 요청까지 포함된 작업을 그대로 재시도하면 DB에는 한 번만 저장됐어도 외부 요청이 두 번 갈 수 있다.

따라서 유지보수 전에는 진행 중인 긴 트랜잭션을 줄이고, 재연결과 업무 재처리를 서로 다른 문제로 다룬다.

위험에 따라 적용 순서를 네 단계로 나눴다

리소스 이름은 공개하지 않고 역할만 남기면 순서는 네 단계였다.

서비스 유형으로 보면 다음처럼 읽을 수 있다.

이 표는 구성 이름만 보고 자동으로 등급을 정하는 규칙이 아니다.

업무 중요도, 실제 연결 구조와 허용 가능한 중단 시간을 함께 확인해야 한다.

1. 개발 환경 Canary

개발 DB에서 같은 종류의 유지보수를 먼저 적용한다.

RDS 이벤트, 재부팅 시간, 연결 오류, 애플리케이션 시작 상태를 기록한다.

기록상 다음 단계 전 관찰 시간은 24시간으로 잡았다.

24시간은 AWS의 필수 규칙이 아니라 하루 동안의 배치와 사용 패턴을 한 번은 지나가 보려는 운영 판단이었다.

2. Reader가 있는 운영 클러스터

운영 클러스터에서는 Writer와 Reader의 역할, 장애 조치 방식, 애플리케이션의 읽기·쓰기 엔드포인트를 확인한다.

적용 전 긴 트랜잭션을 줄이고, 연결 오류가 늘어나는 즉시 멈출 기준을 정한다.

Multi-AZ나 Reader가 있다는 이유만으로 사용자 영향이 없다고 가정하지 않는다.

Smoke test도 단순 접속 성공으로 끝내지 않는다.

상품 조회처럼 읽기 경로는 실제 목록 한 건을 조회하고, 주문 서비스처럼 쓰기 경로는 중복 부작용이 없는 테스트 레코드의 생성·조회·삭제를 확인한다.

어떤 테스트 데이터를 써도 되는지는 서비스 소유자와 먼저 합의해야 한다.

3. 단일 Writer 서비스

대체 Writer가 없는 DB는 별도의 중단 창을 잡는다.

현재 요청이 적은 시간, 데이터 변경 작업의 종료 시각, 담당자가 즉시 검증할 수 있는 시간을 함께 맞춘다.

이 그룹은 장애 시 우회할 인스턴스가 없기 때문에 일괄 처리 대상에서 제외했다.

4. 비가역 변경과 여러 액션이 겹친 도구

플랫폼 변경과 재부팅 등 세 가지 액션이 함께 있던 BI 도구는 별도 작업으로 분리했다.

비가역은 같은 버튼으로 이전 상태로 바로 돌아갈 수 없다는 뜻이다.

이 경우에는 복원된 새 인스턴스로 애플리케이션을 바꾸는 시간까지 계산해야 한다.

스냅샷은 되돌리기 버튼이 아니었다

런북에 스냅샷을 넣으면 마음이 놓이지만, 생성 완료만 확인해서는 복구 절차가 되지 않는다.

RDS 스냅샷을 복원하면 기존 인스턴스 위에 과거 상태를 덮는 것이 아니라 새 DB 인스턴스가 만들어진다.

특정 시점 복구도 새로운 대상 식별자와 엔드포인트를 만든다.

따라서 롤백 계획에는 다음 시간이 포함돼야 한다.

1. 복원 요청부터 새 DB가 사용 가능해질 때까지의 시간
2. 파라미터와 보안 설정을 확인하는 시간
3. 새 엔드포인트로 애플리케이션을 전환하는 시간
4. 쓰기 중단 시점 이후 생긴 데이터 차이를 판단하는 시간
5. 사용자 요청을 다시 열기 전 Smoke test 시간

스냅샷은 중요한 안전장치지만 즉시 원상 복구를 뜻하지 않는다.

이를 알면 “스냅샷이 있으니 지금 적용해도 된다”는 판단을 피할 수 있다.

런북에서 가장 중요한 것은 중단 조건이었다

실행 순서를 적는 문서는 많다.

문제가 생겼을 때 언제 멈출지 적힌 문서는 상대적으로 적다.

내가 런북에 포함한 핵심은 다음 단계로 넘어갈 조건과 멈출 조건이었다.

구체적인 임계치는 서비스의 평소 지표를 기준으로 정해야 한다.

현재 기록에는 실제 오류율과 지연 수치가 없으므로 여기서 임의의 숫자를 만들지 않았다.

적용 완료를 확인하려면 남겨야 할 것

이번 작업에서 가장 큰 증거 공백은 실행 런북 뒤의 운영 이벤트다.

같은 일을 다시 진행한다면 리소스마다 아래 자료를 하나의 변경 기록에 붙인다.

• 적용 전 describe-pending-maintenance-actions 결과
• RDS 이벤트의 시작·완료 시각
• 재부팅 또는 장애 조치 동안의 연결 오류
• 핵심 읽기·쓰기 Smoke test 결과
• 적용 후 보류 액션 재조회 결과
• 중단 조건을 넘지 않았다는 지표
• 복구 절차를 사용했다면 새 엔드포인트 전환 기록

이 자료가 있어야 “계획을 만들었다”에서 “11개 액션을 적용하고 검증했다”로 문장을 바꿀 수 있다.

결론

9개 리소스와 11개 유지보수 액션을 발견했을 때 내가 한 일은 버튼을 빨리 누르는 것이 아니었다.

같은 RDS라는 이름 아래 숨어 있던 서로 다른 실패 방식을 분리하는 일이었다.

개발 Canary, 운영 클러스터, 단일 Writer, 비가역 변경 순으로 범위를 나누고 스냅샷·중단 조건·Smoke test·24시간 관찰을 런북에 넣었다.

현재 남은 증거만으로 실제 운영 적용의 성공과 무중단을 주장하지는 않는다.

대신 다음 원칙은 분명하게 남았다.

RDS 유지보수의 안전성은 Apply Immediately를 누르는 속도가 아니라, 함께 적용될 변경을 찾고 실패를 한 리소스 안에 가두는 순서에서 나온다.

운영 환경을 병행 교체하는 다른 사례는 Amazon Linux 지원 종료에 대응한 과정에서 볼 수 있다.

참고한 공식 문서

• Amazon RDS — Maintaining a DB instance
• Amazon RDS — Using the schedule modifications setting
• Amazon RDS — Rebooting a DB instance
• Amazon RDS — Failing over a Multi-AZ DB instance
• Amazon RDS — Restoring from a DB snapshot