Online DDL을 사용하지 않고 테이블 락 없이 스키마 변경하기

배경

얼마 전 데이터가 약 30만 건인 테이블에 컬럼을 추가하는 작업을 진행했다. 문제는 컬럼 추가에 20분이 넘게 걸렸고, full-text 인덱스가 있어 Online DDL 또한 불가능한 상황이었다.

요약

AWS RDS의 블루/그린 배포 기능을 활용하여 테이블 락으로 인한 서비스 장애 없이 컬럼을 추가하였다.

• 블루/그린 배포는 상용환경(블루)와 동일한 분리된 환경(그린)을 새로 생성하여 변경을 테스트 한 후, 트래픽을 그린환경으로 전환하고 블루환경을 제거함으로써 상용 데이터베이스 배포 시의 예상치 못한 장애를 방지하는 전략이다. 이번 작업에서는 논리적 복제를 사용하였다. 

작업 순서

1. 논리적 복제 설정: RDS 클러스터 파라미터 그룹에 binlog_format=ROW 설정
2. 논리적 복제 적용
   1. reader 인스턴스 1대 증설 (*)
   2. writer로 승격할 reader 를 writer 스펙으로 맞춘뒤 우선순위 tier 0 으로 설정
   3. writer 인스턴스 failover (안전한 재부팅, 5초 이내의 다운타임이 있었다)
   4. reader 인스턴스 failiover 또는 하나씩 재부팅
   5. reader 인스턴스 제거
3. 블루/그린 배포 환경 생성
4. 그린 환경에 접속하여 컬럼 추가 DDL 실행
5. 블루/그린 환경 전환(switch over)
6. (올드)블루 환경 및 블루/그린 환경 제거

기타, 회고

기존의 DB 클러스터의 파라미터 그룹에 논리적 복제(binlog_format: ROW)가 가능하지 않도록 설정되어 있었고, 이 설정은 정적(static) 이었기에 변경 뒤 적용되기 위해서는 인스턴스 재시작이 불가피했다. 그래도 다운타임을 최소화하기 위해 쓰기 인스턴스의 경우 재시작 대신 장애조치(failover)를 사용하였다(이는 Multi-AZ배포만 가능하며, 이 전에 쓰기 인스턴스로 승격될 읽기 인스턴스의 failover priority를 1로 설정하였다). *읽기 인스턴스의 경우 파라미터 그룹 변경 후에 새로 생성하고 기존 인스턴스를 삭제하는 방법을 사용했다(읽기 인스턴스 개수가 감소한 순간 나머지 읽기 인스턴스로 트래픽이 몰리고, session이 쌓여 읽기 인스턴스가 다시 추가된 이후에도 복구되지 않을 수 있다).

주의할 점은 쓰기 인스턴스와 읽기 인스턴스의 타입이 다른 경우 다시 한 번 failover가 필요하다는 점이다. failover 는 본래 장애 발생 시 다른 대기(읽기) 인스턴스를 주(쓰기) 인스턴스로 승격시킴으로써 가용성을 높이는 기능인데, RDS 서비스 중단 없이 구성 변경을 적용하기 위해 사용되기도 한다.

 

참고

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html#blue-green-deployments-major-steps