RDS, Aurora Cluster 의 내부 작업 종류 및 주의 사항

해당 페이지에서는 RDS, Aurora Cluster 에서 내부적으로 발생하는 작업 및 이에 대한 주의사항을 다룬다.

 

해당 내용은 아래의 AWS 공식 문서를 참조하여 기재한다.

 

[1] https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html

 

[2] https://aws.amazon.com/premiumsupport/knowledge-center/rds-mysql-downtime-impact/?nc1=h_ls 

 

[3] https://aws.amazon.com/ko/rds/faqs/

이 글은 아래의 이전 게시글과 연관이 있다.

 

2022.04.26 - [AWS 및 클라우드 지식/AWS RDS, Aurora 및 관련 지식] - AWS RDS 지원 버전 확인 및 관리

 

2022.05.04 - [AWS 및 클라우드 지식/AWS RDS, Aurora 및 관련 지식] - AWS RDS Failover

 

 

2022.05.10 - [AWS 및 클라우드 지식/AWS RDS, Aurora 및 관련 지식] - AWS Aurora Failover

 

개요

 

RDS, Aurora Cluster 를 운영 할 때는 온프레미스 DB 와 다르게 인스턴스 내부적으로 일어나는 패치 및 유지보수 작업에 대해서 인지를 해야 할 필요가 있다. 이는 해당 서비스들이 AWS 측에서 버전 관리 및 유지보수를 담당하는 서비스이기 때문이다.

 

일반적으로 이로 인하여 RDS, Aurora Cluster 를 운영 시, 염두 해야 할 내부작업은 크게 세가지다.

 

- 버전 패치

 

- OS 및 인스턴스 내부 SW 패치

 

- 내부적인 하드웨어 (H/W) 이상에 따른 긴급 유지보수 (H/W Maintenance) 작업.

 

이에 대하여 각 항목들의 세부적인 내용들을 정리하면 아래와 같다.

 

 

버전 패치

 

일반적으로 DB 엔진 버전들은 주기적으로 EOL (End of Life - 제품단종 선언) 되고 이에 따라 지원 종료 및 사용 불가가 되게 되는 과정을 거치는데 AWS 에서도 이에 따라 각 버전들에 대하여 지원 할 수 있는 주기가 정해져 있다.

 

이에 따라 온프레미스때 보다 버전 관리에 대해서 특히나 더 주의해서 관리 해야 할 필요가 있다. 왜냐하면 패치를 수행 하지 않으면 실제로 버전이 종료된 이후에는 불시에 강제로 버전 업그레이드가 이루어지고 이 때, Multi-AZ 든 Aurora Cluster 에 Reader 가 있든 minor, major 버전 유형에 상관 없이 무조건 downtime 이 발생하기 때문이다. 또한 소요 downtime 예측 시간은 직접 테스트를 수행 해 봐야한다.

 

Major 버전은 영향도가 매우 크기에 이에 대해서는 AWS 측에서 PHD 등의 안내문을 보내고 업그레이드 수행을 권장하기에 이에 대해서 준비를 하면 된다. 그러나 minor 버전은 인스턴스 생성 및 수정에서 자동 마이너버전 업그레이드 옵션을 (Enable auto minor version upgrade) 끄지 않으면 인스턴스에 설정된 maintenance window (사용자 측에서 유지 보수 작업이 수행 될 시, 수행 되어도 좋다고 허용하는 설정 시간대) 에 자동으로 업그레이드가 발생할 수 있다.

그렇기에 RDS 및 Aurora Cluster 가 익숙치 않을시에는 인스턴스 생성 및 수정 시 이 옵션을 항시 확인 하는 것을 권장한다.

 

또한 업그레이드가 가능한 버전을 수동으로 선택시에 모든 버전이 나오지 않을 수 있다. 그 때는 그 선택 가능한 버전에서 선택을 해야 한다. 또한, 어떤 버전을 골라야 할 지 어려울 수 있다. 일반적으로 온프레미스에서는 각 DB 의 최신 버전 이전버전을 택하여 아직 bug 사례가 많이 알려지지 않은 최신 버전을 꺼려 하는 경우가 다수이나 RDS, Aurora Cluster 에서는 기능적인 측면이든, EOL 버전의 제한적인 지원기간을 벗어나는 측면에서 최선의 선택 일 수 있다. 

 

간혹, FAQ 에 안내 된 것과 minor 버전은 1년, major 버전은 3년 의 버전 지원 기준과 달리, 내부적으로 이에 대하여 빠른 EOL 을 PHD 로 보낼수도 있다. 그 때는 AWS support 를 통하여 문의 할 것을 권장한다.

 

 

OS 및 인스턴스 내부 SW 패치

 

AWS 에서는 각 AWS 서비스의 내부구조는 기밀사항이라 모두 공유를 하지 않지만, 사용자들은 어림짐작으로 각 서비스의 인스턴스들도 OS 및 기타 AWS 자체의 SW 를 쓰는 것을 추측 할 수 있다. 이에 따라 이러한 내부 요소들도 주기적으로 AWS 에서 유지보수를 해줘야 하며 이러한 작업이 발생전에 PHD 혹은 각 DB 인스턴스의 Maintenance Tap 에서 안내가 되게 된다. 일반적으로 이러한 작업들은 [1]  번 항목을 보면 보류 할 수 있는지, 반드시 수행 되어야 하는지 알 수 있다.

 

만약에 반드시 수행되어야 한다면 downtime 을 고려 해야 하는데 버전 패치와 달리, 이런 유지보수 작업들은 failover 를 적극적으로 활용하기에 실제 발생 downtime 은 1~2분 내외로 예상하면 된다.

 

RDS 에서는 내부적으로 이 작업이 어떻게 이루어지는지를 [2] 번 document  에서 볼 수 있다.

 

 

내부적인 하드웨어 (H/W) 이상에 따른 긴급 유지보수 (H/W Maintenance) 작업

 

AWS 에서 관리하는 장비에 이슈가 생겼을 때, 긴급하게 수행하는 작업이다. 아무래도 H/W 이상은 minor 버전 자동 패치 연기 등과 같이 연기를 할 수 없는 어려움이 있기에 이에 대해서 안내를 받으면 바로 준비를 해야 한다.

 

 

참고로 위의 세작업은 공통적으로 AWS 측에서 긴급도에 따라 선조치, 후보고를 할 수 있다. 그렇기에 운영 중 downtime 이 발생하면서 패치 등이 진행 되었을 때는 (minor 버전은 auto 옵션을 껐는데도 진행 되었을 때만 해당)  AWS Support 등을 통하여 추가 확인을 받는 것이 좋다.