개요
최근 RDS for MySQL5.7 메이저 버전이 EOL 되면서 업그레이드 사례가 많아지고 있고 AWS RDS에서는 DB 엔진별로 업그레이드 시 유의해야 될 점이 있다.
따라서 RDS 엔진별로 업그레이드 시 유의점을 정리하기 전에 오늘은 RDS를 업그레이드 할 때 DB엔진과는 별개로 공통사항으로 적용되는 내용들, 유의할 점 등에 대해서 공유하고자 한다.
RDS를 업그레이드 하는 방법은 여러 가지가 있다. 오늘은 그중에서 가장 많이 사용하는 In-Place 방식으로 RDS를 업그레이드할 때를 기준으로 이야기하려 한다.
RDS Upgrade 공통사항
1. DB Downtime 발생
기본적으로 RDS 업그레이드 간에는 DB Downtime이 존재한다.
즉 DB가 업그레이드되는 일정시간동안 Shutdown 되므로 연결되어 있는 서비스 Application, Web server, Was 등 DB 접근이 불가능하다.
따라서 실제 서비스중인 RDS를 업그레이드하기 위해서는 보통 Application 테스트를 포함하여 사전에 많은 테스트를 진행하고, 예측 Downtime을 산정하여 Downtime을 확보하여 진행한다.
Downtime이 확보가 된다면, App/Was 등 유관 서비스들을 중지 후에 RDS Upgrade를 진행하는 것이 안전하며 이는 서비스가 일시적으로 중단되는 것을 의미하기 때문에 반드시 작업 전 DB Downtime이 발생한다라는 것을 인지해두자.
2. 업그레이드 호환성 및 EOS/EOL 파악
👉 RDS for PostgreSQL Upgrade Version Release
👉 RDS Supported Instance Class
RDS는 DB 엔진/버전 별로 업그레이드가 가능한 버전이 별도 존재할 수 있으며 특정 메이저 업그레이드를 하기 위해서는 중간 버전으로 마이너 업그레이드가 필요할 수 있다.
또한 AWS RDS / Aurora의 경우 엔진 버전별로 EOL날짜가 있기 때문에 사전에 이를 파악하여 업그레이드 한다면 좀 더 장기간 버전을 유지할 수 있을 것이다.
그리고, RDS의 엔진/버전 별로 지원 가능한 Instance Class 타입이 따로 존재할 수 있다.
예를 들어 기존 사용 중이던 Instance Class가 낮은 타입으로 사용 중이라 Tobe 버전에서는 지원이 안된다면 Scale up 작업을 선작업으로 필요할 수 있기 때문에 검토가 필요하다.
3. Parameter Group / Option Group
기존 On-Premise 환경에서 DB를 사용할 때 DB 내부 설정값들을 변경/적용할 수 있는 파일을
AWS RDS에서는 Parameter Group과 Option Group으로 관리한다.
Oracle로 치면 spfile이 되고, MySQL은 my.cnf, PostgreSQL은 postgresql.conf 등의 DB 내부 설정값들을 변경할 수 있는 파일 및 기타 DB 설정들을 AWS RDS에서는 Parameter Group과 Option Group으로 관리할 수 있다.
하지만 Paramter Group과 Option Group의 경우 DB 엔진별로, 메이저버전별로 설정이 가능하기 때문에 만약 메이저업그레이드를 생각 중이라면 해당 엔진/메이저버전에 맞는 그룹이 미리 생성되어 있어야 한다.
4. Multi-AZ
RDS에서 고가용성을 보장하는 RDS 기능 중 하나로 Multi-AZ 기능이 있다.
해당 기능을 사용하고 있을 때, RDS 업그레이드를 할 경우 Primary(원본) DB와 Multi-AZ 구성으로 생성된 Standby DB까지 모두 업그레이드되기 때문에 업그레이드 시간이 늘어날 수 있다는 점 참고해 두자.
5. Read Replica
RDS에서는 트래픽 분산 목적으로 Read Replica라는 기능을 제공하고 있다.
업그레이드하고자 하는 RDS에서 Read Replica를 사용 중이라면 DB 엔진별로 업그레이드 작업 절차가 달라진다.
예를 들어 RDS for MySQL의 경우 Read Replica를 사용 중이라면, Writer (Master)를 업그레이드하기 전 사용 중인 모든 Read Replica를 먼저 업그레이드해야 Writer의 업그레이드가 가능하다.
따라서 업그레이드하고자 하는 RDS에서 Read Replica를 사용 중이라면 DB 엔진별로 어떠한 유의사항이 있는지 확인하고 작업계획을 짜보자.
6. Rollback (Autobackup)
RDS는 기본적으로 업그레이드 후 다운그레이드 작업은 불가능하다. 즉 Rollback이 불가능하다.
RDS의 백업 기능으로 Autobackup이 활성화되어 있다면 업그레이드 프로세스의 첫 동작으로 사전 스냅샷이 생성된 뒤 업그레이드 작업이 이어서 진행되고, 업그레이드 완료 후에 다시 한번 스냅샷을 생성한다.
업그레이드 동작 전 자동으로 생성되는 사전 스냅샷은 실질적으로 RDS가 업그레이드 프로세스에 들어가기 전 생성되는 백업본이기 때문에 예기치 못한 상황으로 인한 Rollback 용도로 사용할 수 있다.
작업을 진행하는 작업자 입장에서 Rollback은 반드시 염려해 두고 있어야 한다.
따라서 Autobackup이 활성화되어있지 않다면, 트래픽 차단 (App, Was 서비스 중지) 이후 수동으로 스냅샷을 생성하여 Rollback에 대비할 수 있다.
추가적인 내용으로 업그레이드 작업 시작 전 RDS의 Autobackup 시간대가 겹쳐, RDS가 백업이 진행되고 있는 상태라면 업그레이드 작업이 불가능하기 때문에 Backup Window도 검토해 볼 필요가 있다.
RDS Snapshot의 경우 증분 백업 방식이기 때문에, Autobakcup이 활성화되어 있다고 하더라도 업그레이드 작업 전 수동으로 스냅샷 생성 시 업그레이드 작업으로 동작하는 사전 스냅샷 생성 단계의 시간을 일부 줄일 수 있다.
7. 업그레이드 테스트
업그레이드 대상 RDS의 스냅샷을 생성한 뒤 이를 복원하여 업그레이드 테스트를 진행할 수 있으며 테스트 간 이상현상은 없는지, 예측 작업시간과 Downtime은 어떻게 되는지 산정할 수 있다.
여기서 말하는 테스트는 실제 작업자가 AWS Console 상에서 진행하는 Instance 작업 테스트뿐 아니라 업그레이드 후 Application 혹은 Was에서 이상현상은 없는지, 성능에 이슈는 없는지 등의 기능 및 전수 테스트를 모두 포함한다.
RDS라 할지라도 인스턴스 자체의 업그레이드를 실패하는 사례도 많이 있으며 업그레이드는 성공했어도 예기치 못한 에러가 발생하는 경우는 생각보다 빈번하게 발생된다.
실패를 방지하기 위한 가장 최선책은 일정기간 동안 이러한 테스트를 꼼꼼히 해보는 것이다.
따라서 업그레이드 테스트는 반드시 진행하도록 하자.
끝맺음
RDS를 업그레이드하는 방법은 여러 가지 방식이 있다.
비교적 최근에 AWS에서 새로 출시된 기능인 Blue-Green 배포 방식이라던지, 스냅샷을 이용한 업그레이드, Replication을 이용한 업그레이드 등의 다양한 업그레이드 기술이 있지만 각 방법마다 장단점이 존재하고 상황에 맞춰 적용하는 기술이 필요할 수 있다.
오늘은 가장 많이 사용되는 In-Place 방식의 업그레이드를 기준으로 끄적여봤다.
다른 방법들에 비해 Downtime이 길게 소요된다라는 단점이 있고, 업그레이드 실패에 대한 리스크가 있지만 Downtime이 충분히 확보되고, 충분한 테스트와 사전점검을 통해 사전에 에러를 방지할 수만 있다면 간편하고 비용절감과 더불어 가장 확실하게 하는 방법이 아닐까 생각한다.
