Last Updated on 10월 4, 2023 by Jade(정현호)
안녕하세요
해당 포스팅은 아래 이전 포스팅에서 이어지는 연재 포스팅으로 Amazon RDS의 Multi-AZ Instance와 RDS 업그레이드에 대한 내용을 담고 있습니다.
Contents
1. Amazon RDS를 위한 고가용성(다중 AZ)
Amazon RDS는 다중 AZ(Multi-AZ Instance) 배포를 사용해 DB 인스턴스에 고가용성과 장애 조치 기능을 지원합니다. Amazon RDS는 다양한 기술을 이용해 장애 조치 지원을 제공합니다. MariaDB, MySQL, Oracle 및 PostgreSQL DB 인스턴스용 다중 AZ 배포는 Amazon의 장애 조치 기술을 사용합니다
Multi-AZ는 Instance 와 DB Cluster 두가지로 종류로 나눌 수 있습니다. 포스팅에서는 Multi-AZ Instance(다중 AZ 인스턴스)에 대해서 설명하고 있습니다. 그래서 이번 글에서 표현하는 다중 AZ 또는 Multi-AZ는 Instance 입니다.
다중 AZ 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 예비 복제본을 프로비저닝하고 유지합니다. 기본 DB 인스턴스는 가용 영역에서 예비 복제본으로는 동기식으로 복제가 되어 데이터 이중화를 제공하고 I/O 중지를 제거하며 시스템 백업 시 Primary 인스턴스가 아닌 예비 복제본(Standby Replica)에서 수행함으로 Primary DB 인스턴스의 지연 시간 스파이크를 최소화합니다
DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 향상시킬 수 있습니다.
Multi-AZ 의 장점은 Mater 인스턴스의 장애에 대한 대비를 할 수 있는 부분 이외에 RDS의 maintenance 작업 시 대기 인스턴스의 부터 작업 후 스위칭 하는 형태로 진행됩니다.
이러한 maintenance 작업은 여러가지가 있으며 보통의 경우 Multi-AZ 를 활용한 적은 다운타임을 사용할 수 있는 경우는 OS 버전 업그레이드, hardware-maintenance 등의 작업이 있습니다(DB Upgrade시에는 불가함)
이런 유형의 작업들에 대해서 Multi-AZ 를 사용할 경우 인스턴스 교체(Take-Over) 되는 기간 동안 다운타임이 발생함으로 Single-AZ 에 비해 다운 타임이 짧아진다는 장점이 있습니다.
단일 인스턴스에 비해서 Multi-AZ 의 단점은 크게 두가지로 비용적인 측면과 상대적으로 I/O 성능저하 라고 볼 수 있을 것 같습니다.
- 단일 인스턴스에 비해 다른 가용 영역에 2개의 Standby Replica DB 인스턴스가 있는 만큼 더 많은 비용이 발생합니다.
- Multi-AZ Instance의 복제 방식은 raid 1(Mirroring) 와 유사한 스토리지(디스크) 복제 기능인 DRBD를 사용하며 동기식(Synchronous) 복제를 수행합니다. 그렇기 때문에 단일 인스턴스에 비해 상대적으로 쓰기 I/O 속도의 지연이나 성능적 저하가 발생합니다.
이와 같이 Multi-AZ Instance는 동기식 데이터 복제(Synchronous Replication)로 수행되며, Active-Standby 형태로 이루어지게 됩니다.
[참고] Multi-AZ DB Cluster에 대해서는 다음 포스팅을 참조하시면 됩니다.
2. 다중 AZ(Multi AZ) 구성
포스팅에서 다중 AZ 를 구성은 아래 이미지와 같이 Master / Read Replica 로 구성된 인스턴스를 사용할 예정입니다.
다중 AZ 를 생성하는 방법은 2가지로 먼저 RDS 인스턴스 생성시 다중 AZ 를 지정하여 생성할 수 있습니다.
참고로 프리티어 사용 및 프리티어 등급 선택시 다중 AZ 옵션 선택이 비활성화 되게 됩니다.
즉, 프리티어 등급으로는 Multi-AZ 사용이 불가합니다.
그 다음으로 생성된 RDS 인스턴스를 수정하여 다중 AZ 를 구성할 수 있습니다.
2-1 인스턴스 수정
다중 AZ 를 구성할 인스턴스 선택 -> 구성 을 선택합니다.
2-2 멀티 AZ 옵션 선택
다중 AZ 배포 를 선택 후 하단의 계속 을 선택합니다.
2-3 변경 사항 확인 및 수정
아래와 같이 변경되는 사항을 확인 후 하단의 "DB 인스턴스 수정" 을 선택하여 구성 변경을 진행합니다. 포스팅에서 수정 시점은 즉시 적용 을 선택하였습니다.
상태 컬럼 에서는 수정 중으로 변경되고 수분이 지난 후 사용가능 으로 상태가 변경되고 나서 확인해보면 다중 AZ 에 "예" 로 변경된 것을 확인할 수 있습니다.
실제 사용 중인 데이터베이스에 대해서 진행 시에는 쿼리 처리량이나 응답 속도가 떨어질 수 있습니다.
실제 RDS에 작업 시 가급적 부하가 적은 시간대에 진행을 해야 할 것으로 생각됩니다.
2-4 읽기 복제본 변경
읽기 복제본에서도 다중 AZ 설정이 가능 하고 위의 순서와 동일 합니다.
3. 장애조치
다중 AZ 가 설정된 상태에서 RDS 인스턴스가 계획되지 않는 중단이 발생하게 되면 RDS는 자동으로 다른 가용 영역에 있는 예비 복제본으로 전환됩니다.
장애 완료되는 소요 시간은 DB 인스턴스의 규모나 트랜잭션이나 여러 조건에 의해서 달라집니다. 대략 소요 시간은 일반적으로 60-120초 입니다.
진행된 트랜잭션에 따라서 복구 프로세스가 더 길어져서 장애 조치에 소요되는 시간이 증가할 수는 있습니다.
장애 유형에 따른 조치의 상세 내용은 아래 링크의 "Amazon RDS 장애 조치 프로세스" 를 참조하시면 됩니다
테스트를 위해서 강제로 장애 조치를 해볼 수 있으며 재부팅 기능을 통해서 장애 조치를 실행할 수 있습니다.
3-1 재부팅 실행
장애 조치 테스트를 위해서 재부팅을 실행하기 위해서는 인스턴스 선택 -> 작업 -> 재부팅 을 선택합니다.
3-2 장애 조치 선택
다중 AZ 가 활성화된 상태에서 재부팅을 실행하면 아래와 같이 장애 조치로 재부팅 할 것인지를 물어보게 됩니다. 장애 조치 재부팅으로 실행하려면 체크하고 하단의 확인을 선택합니다.
실행하게 되면 아래와 같이 상태가 "재부팅 중" 으로 변경되게 됩니다.
변경이 완료되면 아래와 같이 리전 및 AZ 가 다른 가용 영역으로 변경된 것을 확인할 수 있습니다.
장애조치 재부팅시에는 위에서 설명된 것 처럼 인스턴스를 재부팅하기 때문에 60~120초 또는 그 이상의 접속 불가(복구 프로세스 진행) 가 되게 됩니다.
4. 업그레이드
Amazon RDS 의 특징 중 하나가 아주 다양한 버전(버전 이미지 보유) 을 제공하고 있으며, 그에 따라 사용자는 온프레미스 환경에서 사용중인 동일(또는 유사) 버전을 사용할 수 있습니다 다양한 버전을 제공하는 만큼 버전 업그레이드 기능도 제공하고 있습니다.
업그레이드하는 방법으로는 먼저 인스턴스 정보에서 구성 항목 -> 권장 사항 을 보면 아래와 같이 권장되는 버전이 제시되고 해당 메뉴를 통해 업그레이드 진행이 가능 합니다.
또 다른 다른 방법으로는 인스턴스 수정 메뉴를 통해서 원하는 버전으로 업그레이드를 진행할 수 있습니다.
4-1 인스턴스 수정
업그레이드하려는 RDS 인스턴스 선택 후 "수정" 을 선택합니다.
4-2 DB 엔진 버전 선택
업그레이드하려는 DB의 버전을 선택합니다. 포스팅 작성시 기준으로 아래와 같은 버전을 선택할 수 있습니다.
버전을 선택 후 하단의 "계속" 을 선택합니다. 포스팅에서는 기존 버전은 5.7.22 이었고 신규로 업그레이드를 선택한 버전은 5.7.26 입니다 버전에 대한 선택은 예시입니다.
4-3 업그레이드 진행
업그레이드 적용 시점은 선택 후 하단의 DB 인스턴스 "수정" 을 선택합니다 포스팅에서는 즉시 적용을 선택해서 진행하였습니다.
4-4 인스턴스 상태
업그레이드가 시작되면 아래와 같이 상태가 "업그레이드 중" 으로 변경됩니다.
다음 단계로 진행되면 아래와 같이 상태가 "Configuring-enhanced-monitoring" 으로 확인됩니다. 진행 상태에 따라서 해당 상태에서는 RDS의 접속이 가능 합니다.
진행이 모두 완료되었다면 아래와 같이 상태가 사용 가능 상태로 확인됩니다.
Note
RDS 버전(마이너) 업그레이드 이후에 RDS maintenance 항목에 OS 업그레이드가 필요하다는 메세지를 확인될 수도 있습니다.
DB 버전(마이너 버전 포함)에 따라서 OS도 업그레이드를 해야 할 경우가 많이 있습니다. 그렇기 때문에 실 작업전에 테스트로 RDS 버전 업그레이드를 진행하여 maintenance 필요가 발생하는지 확인이 필요합니다
4-5 버전 확인
업그레이드 완료 후 인스턴스 정보 -> 구성 항목에서 업그레이드된 엔진 버전을 확인할 수 있습니다. 
실제 접속 후 확인하였을 때도 버전 변경이 확인됩니다.
이와 같은 절차로 Master(Primary) 도 업그레이드 진행을 완료하면 됩니다.
Master - Replica 구조로 되어 있지만 Aurora Cluster 와 달리 인스턴스간의 롤 변경(Master <-> Replica) 는 불가 함으로 Master 업그레이드하는 동안 비지니스 다운타임은 발생할 수 있습니다.
(DB 버전(마이너) 업그레이드시에는 Multi-AZ에 의한 인스턴스 take-over가 불가능 합니다.)
모든 Replica(읽기 복제본) 이 업그레이드가 완료되었다면 마지막으로 Master 인스턴스의 업그레이드를 진행하면 됩니다 아래의 안내문과 같이 읽기 복제본의 스토리지가 동일한지 또는 그 이상인지에 대한 내용을 확인할 수 있습니다. 절차는 위의 Replica 에서 진행한 것과 동일 합니다.
참고로 백업이 활성화되어 있는 상태로 RDS 버전 업그레이드를 진행하게 되면 아래와 같이 시작 전, 업그레이드 이후 한번 해서, 업그레이드하는 과정에서 총 2번의 백업이 수행되게 됩니다.
May 01, 2021, 7:38:00 AM UTC Backing up DB instance <----!!!! May 01, 2021, 7:40:05 AM UTC Finished DB Instance backup <----!!!! May 01, 2021, 7:47:40 AM UTC DB instance shutdown May 01, 2021, 7:52:44 AM UTC DB instance restarted May 01, 2021, 7:55:46 AM UTC Database instance patched May 01, 2021, 7:56:06 AM UTC Backing up DB instance <----!!!! May 01, 2021, 7:58:09 AM UTC Finished DB Instance backup <----!!!! May 01, 2021, 7:59:30 AM UTC Monitoring Interval changed to 60 May 01, 2021, 8:00:43 AM UTC Finished updating DB parameter group May 01, 2021, 8:04:43 AM UTC Finished updating DB parameter group
그래서 RDS 용량이 크고 백업 수행시간에 오래 걸린다면 작업 시간 산정 시 이런 부분도 유념해야 할 부분입니다.
5. OS Upgrade 과 하드웨어 작업
OS 자체의 버전 업그레이드의 필요성에 의해서 또는 RDS 마이너 버전 업그레이드에 의해서 OS 업그레이드를 실행해야 할 수 있습니다.
업그레이드하기 전 RDS 와 업그레이드 후 RDS 버전에 따라서 OS 업그레이드 필요성 여부는 달라 지게 됩니다.
또한 hardware-maintenance 는 RDS가 위치한 서버에 따라서 maintenance 필요성 여부가 달라지게 됩니다.
Multi-AZ 여부에 따라서 가용영역의 Failover가 수행됨에 따라서 다운 타임의 시간이 차이가 나게 됩니다.
OS 업그레이드 작업 및 hardware-maintenance 이 필요하다면 "유지관리 및 백업 탭" 에서 해당 내역을 확인할 수 있습니다
(스크린샷을 생성하는 시점에는 유지관리 대상이 없었음)
Multi-AZ 가 활성화된 상태에서 OS 업그레이드나 hardware-maintenance 를 수행하게 되면 AZ 간의 Failover(switch) 가 수행되면서 Multi-AZ 비활성 보다는 다운타임이 짧아지게 됩니다.
-- RDS OS 업그레이드 로그 February 08, 2022, 8:07:14 AM UTC Applying off-line patches to DB instance February 08, 2022, 8:12:18 AM UTC DB instance shutdown February 08, 2022, 8:13:00 AM UTC Multi-AZ instance failover started. February 08, 2022, 8:13:14 AM UTC DB instance restarted February 08, 2022, 8:13:35 AM UTC The operating system underlying the RDS database instance is being patched in an offline operation. February 08, 2022, 8:13:35 AM UTC Multi-AZ instance failover completed February 08, 2022, 8:22:43 AM UTC Finished applying off-line patches to DB instance February 08, 2022, 8:24:10 AM UTC Monitoring Interval changed to 60 February 08, 2022, 8:25:24 AM UTC Finished updating DB parameter group
시간은 상황에 따라서 달라질 수 있겠으나 AWS 에서는 아래와 같이 Multi-AZ 에 따른 다운타임을 예상하고 있습니다.
Single-AZ의 경우 : 호스트의 멈춤 후 호스트 교체가 진행되며, 이는 통상적으로 수분의 시간이 걸림 (2~3분)
Multi-AZ의 경우 : 호스트 교체를 위하여 Failover 진행 후, stand-by 인스턴스로 변경된 인스턴스에 대해 호스트 교체가 진행됨
통상적인 Failover의 downtime과 비슷하며, 1분 이내에 다시 인스턴스에 접속 가능할 것으로 예상
이번 포스팅은 여기에서 마무리하도록 하겠습니다.
이어지는 다음 글
6. Reference
Reference link
cloudbasic.net/synchronous-vs-asynchronous [L]
aws/AmazonRDS/UserGuide/USER_RebootInstance [L]
aws/AmazonRDS/UserGuide/Concepts.MultiAZ [L]
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
