LG전자의 Amazon Aurora 및 RDS 블루/그린 배포를 이용한 데이터베이스 업그레이드 안정성 확보

LG전자는 전자, 가전 분야의 혁신적인 기술로 세계적인 일류기업 자리를 지키고 있으며,  가전제품과 서비스를 아우르는 LG ThinQ 플랫폼을 통해, 앱 하나로 언제 어디서나 가전 제품은 물론, 집안 곳곳을 컨트롤 할 수 있고, 일상을 보다 편리하게 누릴 수 있는 새로운 고객경험을 제공하고 있습니다.

LG전자는 LG ThinQ 플랫폼의 글로벌 서비스를 안정적이고 확장성 있는 서비스로 구축하였으며, AWS IoT와 서버리스 서비스(AWS Lambda, Amazon DynamoDB 등)를 적극 활용하고 있습니다. 특히 데이터베이스는 Amazon Aurora 및 Amazon RDS를 중심으로, 목적에 맞는 데이터베이스 서비스를 적용하여 제조 중심의 가전 회사에서 데이터 중심의 소프트웨어 기업으로 변화해 왔습니다.

이번  게시글에서는 최근 새롭게 출시된 Amazon Aurora 및 RDS의 블루/그린 배포(Blue/Green Deployments) 기능을 LG전자 ThinQ 서비스에 적용하여 고객 서비스의 운영 안정성과 효율성을 어떻게 확보했는지 알아봅니다.

Amazon Aurora/RDS에서의 버전 업그레이드

Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스입니다. Aurora는 완전 관리형 서비스이므로 일반적인 DB 유지보수 작업(패치, 백업 및 복구 등)은 자동화됩니다. 하지만, 버전 업그레이드와 같은 경우에는 업그레이드 계획, 테스트 및 운영 전환과 같은 고도의 작업 계획 수립이 필요합니다.

일반적으로 Aurora 및 RDS의 버전 업그레이드와 같은 경우, 다음과 같은 3가지 방법 중에서 고객의 상황에 적절한 방법을 선택하여 진행하는 것이 일반적입니다.

1. In-place 업그레이드

In-place 업그레이드는 아래 그림과 같이, 현재 서비스에 사용하고 있는 Aurora DB Cluster에서 Modify DB Cluster 기능으로 직접 버전 업그레이드를 진행하는 방법입니다.

In-place 업그레이드는 클릭 몇 번만으로 손쉽게 버전 업그레이드를 진행할 수 있는 방법이지만, 운영 DB Cluster에 직접적인 변경을 진행하므로 DB 엔진 내부의 업그레이드 절차와 데이터 변경량에 따라 장시간이 소요될 수 있습니다. 이는 고객 서비스의 다운타임이 길어진다는 것을 의미합니다. 만약, 업그레이드에 대한 rollback을 결정하게 된다면, 이미 상위 버전으로 업그레이드가 끝난 뒤이므로 현실적으로 rollback을 할 수 없을 수 있습니다.

2. Snapshot restore in-place

In-place 업그레이드의 이러한 문제를 방지하기 위해 많이 사용하는 방법이 운영 DB Cluster의 백업(snapshot)을 이용하여 새로운 DB Cluster로 복구(restore)를 진행 한 후, 신규 DB Cluster에 In-place 업그레이드를 진행하는 방법입니다.

백업의 복구가 완료되어 새로운 DB Cluster 생성이 완료되면, 이 DB Cluster로 In-place 업그레이드를 진행합니다. 단순 In-place 방식에서는 rollback이 불가능하였지만, 기존 운영 DB Cluster는 정상적으로 존재하므로 문제 발생 시, 기존 DB Cluster로의 rollback이 바로 가능합니다.

다만, 이 방법은 복구(restore) 이후 In-place를 진행하게 되므로, 업그레이드 작업이 다른 방식의 작업보다 시간이 더 소요될 수 있으며, 작업 중 운영 DB Cluster에 트랜잭션이 발생하면 동기화를 시켜야 하는 부분이 있으므로, 트랜잭션을 통제해야 하는 문제가 있습니다. 무엇보다 새로운 DB Cluster를 업그레이드하여 서비스에 사용하게 되므로, 서비스에서 사용하는 DB Cluster endpoint(DNS)를 신규 DB Cluster로 변경하여야 하기 때문에 애플리케이션의 변경 및 배포 작업이 필요합니다.

3. Cluster 간 binlog replication (Read Replica) 구성 후, 교체

Aurora/RDS의  버전 업그레이드 관련하여 세번째로 고려할 수 있는 방법은 MySQL에서 제공되는 binlog replication 기능을 사용하여 DB Cluster 간 External replication을 구성하고, 복제 지연이 없을 때 운영 DB Cluster를 신규 DB Cluster로 전환하는 방식입니다.

일반적으로 다음과 같은 3단계로 진행됩니다.

단계 1 : binlog replication 구성

서비스를 하고 있는 Cluster를 Old Cluster 라고 하고, 변경할 버전으로 적용된 Cluster 를 New Cluster 라고 하겠습니다.  단계 1은 Old Cluster 와 New Cluster 사이에 Cluster간 binlog replication을 구성하는 단계입니다. Old Cluster 에서 변경되는 데이터는 binlog replication 기능을 이용하여 자동으로 New Cluster 로 전달됩니다.

단계 2 : Read 트래픽 전환

Read 트래픽을 New Cluster 로 선별적으로 전환하여, 변경된 버전에서의 서비스 정상 유무를 확인해 볼 수 있습니다.

단계 3 : Write 트래픽 전환

Write 트래픽도 New Cluster 로 전환하여, 서비스를 완전히 전환하고, 버전 업그레이드 작업을 마무리 합니다. rollback을 감안하여, New Cluster 에서 Old Cluster 로 반대방향으로 binlog replication 을 구성 할 수도 있습니다. Old Cluster를 서비스 정책에 따라 필요기간 동안 유지할 수 있습니다.

이 방식의 장점은 작업 간 서비스의 중단과 같은 서비스의 영향 범위와 시간을 최소로 할 수 있다는 점입니다. 또한 신규 DB Cluster에서 기존 DB Cluster로 reverse external replication의 구성도 가능합니다.

다만, 이 방식의 경우 숙련된 작업자가 작업을 수행하여야 작업 중 발생할 수 있는 데이터 유실 및 서비스 장애 등의 상황 방지 및 후속대응이 가능합니다. 또한 신규 DB Cluster로 서비스가 변경되므로 애플리케이션에서 Cluster endpoint(DNS)가 변경되는 부분이 발생하여, 작업 단계에서 애플리케이션의 변경 및 배포 작업이 필요합니다.

Aurora/RDS for MySQL 에서 Blue/Green Deployment 기능이 제공되기 전, 일반적으로 버전 업그레이드에 사용할 수 있는 3가지 방식의 장단점은 다음과 같이 정리 할 수 있습니다.

각각의 장단점이 있으므로 고객의 상황에 맞게 선택하여 사용할 것을 권장합니다.

Amazon RDS/Aurora for MySQL Blue/Green Deployment

AWS re:Invent 2022에서 Aurora/RDS for MySQL의 버전 업그레이드를 보다 안정적이고, 다운타임을 최소화하면서 쉽게 할 수 있는 Blue/Green Deployment 기능이 소개되었습니다. 2023년 3월 현재, 서울 리전에서도 사용 가능합니다.

Blue/Green Deployment 기능은 기존 운영 DB cluster인 Blue와 이를 복제한 Green DB cluster 간의 binlog external replication을 자동으로 구성해주며, switch over 시에도 Cluster Endpoint 가 변경되지 않으므로 별도의 애플리케이션 배포가 필요 없다는 장점이 있습니다. 또한 클릭 몇 번 만으로 쉽고 간단하게 구성 할 수 있는 장점도 있습니다.

따라서 앞에서 말씀드린 3가지 버전 업그레이드 방식의 장점을 모두 가지고 있습니다.

Blue/Green Deployment의 진행 단계를 3단계로 간단히 살펴보겠습니다.

단계 1 : 시작 및 준비

서비스를 하고 있는 DB Cluster, Blue가 아래와 같이 Primary 1대와 Read Replica 2대로 구성되어 있다고 가정하겠습니다.

단계 2: Blue/Green Deployment 생성

Blue/Green Deployment 기능을 통해서 새롭게 Green DB Cluster를 구성하겠습니다.

Green DB Cluster는 최초 생성 시에 Blue DB Cluster와 동일한 구조, 동일한 스펙으로 생성됩니다. 따라서 Green DB Cluster도 Blue DB Cluster와 동일하게 Primary 1대에 Read Replica 2대 구성으로 생성되었습니다. 개별 인스턴스의 스펙도 동일하게 생성됩니다.

Blue DB Cluster와 Green DB Cluster사이에는 데이터 동기화 작업이 필요한데, MySQL에서 제공하는 binlog replication 기능을 사용하여 DB Cluster간 복제를 하게 됩니다. 따라서 Blue DB Cluster에는 binlog replication 기능을 활성화한 후, Green DB Cluster를 생성해야 합니다.

단계 3 : Switch-over

서비스에서 필요한 시점에 운영 DB Cluster를 기존 Blue에서 Green으로 변경하는 Switch-over 작업을 진행하면, 이후 서비스 트래픽은 Green DB Cluster로 넘어가게 됩니다. 이 때, 기존 Blue DB Cluster가 사용하고 있던 Cluster endpoint 정보를 Green DB Cluster가 자동적으로 승계 받게 되므로, 애플리케이션 입장에서는 DB Cluster endpoint를 변경하는 배포 작업을 진행할 필요가 없습니다.

Blue/Green Deployment는 클릭 몇 번으로 간단히 버전 업그레이드 작업이 가능하며, binlog replication도 자체 구성이 되므로, 고도의 작업계획 등의 준비도 필요 없습니다.

Blue/Green Deployment를 사용하기 위해 실제 콘솔에서의 작업 단계를 살펴 보겠습니다.

콘솔에서 Create Blue/Green Deployment 를 선택합니다. Green의 버전을 선택하는 화면이 나옵니다. Green의 버전은 현재 Blue의 버전보다 같거나 큰 버전만 선택이 가능합니다.

아래 그림은 Aurora for MySQL 2.10.2 버전에서 Aurora for MySQL 3.02.2 버전으로 Blue/Green Deployment 기능을 통해 업그레이드를 한다고 가정해 보겠습니다.

만약, 현재 운영 DB Cluster인 Blue에서 binlog replication이 비활성화 되어 있다면, 다음과 같은 에러가 발생하게 됩니다. 이러한 에러가 발생할 경우 parameter group에서 binlog_format 의 값을 변경해 주시면 됩니다. (binlog_format 파라미터 설정 변경 시, DB Cluster 의 Writer 인스턴스 재부팅이 필요합니다.)

Blue/Green Deployment가 진행될 경우, 다음과 같은 진행 화면을 콘솔에서 확인 할 수 있습니다. 현재 서비스 중인 DB Cluster인 Blue는 정상 사용 가능합니다.

Green DB Cluster의 생성이 완료되면, 다음과 같이 Blue DB Cluster와 Green DB Cluster가 정상적으로 보입니다.

Blue에서 Green으로 서비스 DB Cluster를 전환하는 Switch-over 작업은 Action에서 선택할 수 있습니다.

Green DB Cluster의 Identifier를 선택하고 Action을 선택한 후, Switch-over를 진행하면 됩니다.

Switch-over 되면, Green DB Cluster는 기존 Blue DB Cluster의 이름으로 자동 변경되고, 기존 Blue DB Cluster는 이름 뒤에 -old1 과 같은 postfix가 붙어서 별도의 DB Cluster로 변경됩니다.

따라서 만약 Blue/Green Deployment 이후에 rollback이 필요한 경우에는 변경된 기존 Blue DB Cluster로 endpoint를 변경하여 사용할 수 있습니다. 그러나, Green DB Cluster에 트랜잭션(데이터 변경)이 발생하기 전, SELECT 와 같은 Read 작업으로 서비스의 정상 유무를 확인하여 rollback을 결정하는 것이 좋습니다.

LG전자의 Amazon Aurora 및 RDS Blue/Green Deployment 사례

이제 Blue/Green Deployment 기능을 이용한, LG전자 ThinQ 플랫폼의 Aurora/RDS for MySQL의 버전 업그레이드 사례를 알아보겠습니다. LG ThinQ 플랫폼은 많은 수의 Aurora/RDS for MySQL을 사용하여 서비스되고 있습니다. LG전자는 AWS re:Invent 2022에서 Blue/Green Deployment 기능이 출시된 후, 해당 기능에 대한 철저한 테스트 및 검증을 실시하여 Aurora/RDS for MySQL의 Major/Minor 버전 업그레이드 작업의 기본 작업 방식으로 채택하여 수행 중입니다.

Blue/Green Deployment 기능을 이용해 데이터베이스를 쉽게 업그레이드할 수 있지만, 업그레이드 당일의 작업 시간을 최소화하고, 서비스 안정성을 확보하는 것이 필요합니다.

LG전자는 Green DB Cluster 구성을 실제 버전 업그레이드 작업일 1주일 전에 시작하여 작업의 안정성을 확보하였습니다. Green DB Cluster 구성 시, DB Storage 최적화(Lazy Loading 최소화)를 위한 시간을 확보하고 DB 캐시에 자주 사용되는 DB 페이지들을 미리 상주시키기 위한 warm-up 작업을 수행하여 업그레이드 후에도 서비스 성능을 확보하였습니다.

Green DB Cluster 구성 시 유의할 점

1. binlog 활성화

Aurora for MySQL은 기본적으로 특별한 용도(ex. 데이터 마이그레이션 시 CDC 툴 이용)가 없는 경우, binlog 를 비활성화하여 사용합니다. 즉, 파라미터 binlog_format=OFF 이고, log_bin=OFF 입니다. 따라서, Blue/Green Deployment 기능을 사용하기 위해서는 서비스 DB Cluster인 Blue의 binlog_format을 다른 값(예: MIXED)으로 변경해서 Green DB Cluster를 생성하여야 하는데, binlog_format 파라미터 변경을 데이터베이스에 적용하기 위해서는 데이터베이스 reboot 이 필요합니다.

그리고 binlog 를 활성화하여 log_bin=ON일 경우, 기존보다는 운영 DB Cluster Blue의 Write 성능이 저하될 수 있습니다. 이 부분을 고려하여 업그레이드 계획 및 모니터링을 진행합니다. (RDS for MySQL은 백업이 켜져 있으면 binlog 를 기본 사용)

2. Aurora for MySQL에서의 event_scheduler

Aurora for MySQL에서 Green DB Cluster 생성 시,  event_scheduler=Off 상태로 생성하여야 합니다. RDS for MySQL에서 Green 생성 시에는 read_only=”true if replica” 수식에 의해 read_only=true 로 Green이 생성됩니다. 이 경우에는 Green의 event_scheduler가 On 이어도 read_only=true 라서 문제가 없습니다. 그러나 Aurora for MySQL에서는 Green DB Cluster의 경우 read_only=true로 생성되지 않습니다(read_only=false임). 따라서 event_scheduler=On 이면 Green에서 스케줄러에 의한 데이터 조작으로 인해 동기화 에러가 발생할 수 있으므로, Aurora for MySQL의 경우 event_scheduler=Off 상태로 Green을 생성해야 합니다. 또한 Aurora 에 추가된 Role 은 자동으로 Green 에 추가되지 않으므로 별도로 추가해야 합니다.

DB Cut-Over(업그레이드 당일)

• LG전자는 실제 업그레이드 작업 당일에는 Blue에서 Green으로 Switch-over작업만 수행하여, 간단하고, 작업 시간을 최소화하여 서비스에 영향 없이 업그레이드하였습니다. Switch-over 시에는 RDS와 Aurora 모두 read_only = true로 자동으로 변경됩니다.
• 서비스 클라이언트는 JDBC 드라이버를 사용하여 접속하는 환경이나, WAS(Web Application Server)의 재시작과 같은 서비스 유입차단에 대한 작업은 별도로 진행하지 않았습니다.
• Blue/Green Deployment의 Switch-over 수행 시, 내부적으로 짧은 순간에 DB 세션이 차단되므로, 실제 write 트래픽을 차단하지 않고 서비스 트래픽이 유입되는 상황에서도 버전 업그레이드를 진행할 수 있었습니다.
• Blue에서 Green으로 switch-over 작업이 수행되기 위해서는 Blue와 Green 간의 동기화 지연시간(Seconds_Behind_Master)이 없어야 하고, 변경량이 많은 오랜 시간이 소요되는 트랜잭션이 없는 것이 좋습니다. 따라서, 배치 형태의 트랜잭션 작업은 버전 업그레이드 작업 전/후에는 수행되지 않도록 하였습니다.
• Blue/Green Deployment 의 Switch-over가 진행되면서 Write 트래픽이 차단되는 시간은 실제로 약 1분 이내로 소요되었습니다.

아래 표는 LG전자에서 실제 업그레이드 작업 시 시간별 작업 내역입니다. 노란색 배경 부분은 WAS가 JDBC 드라이버를 통해서 접속하는 대상이 어디인지를 나타냅니다.

LG ThinQ 플랫폼은 글로벌 서비스 이므로, 작업 시간을 최소화하고, 서비스의 영향을 최소화 할 필요가 있었습니다. 또한, 전 세계에 서비스되고 있는 애플리케이션의 배포 및 재시작에는 현실적으로 문제가 있으므로, DB 버전 업그레이드 작업 시 애플리케이션 배포가 필요없는 Blue/Green Deployment 방식은 최선의 선택이 되었습니다.

결론

LG전자는 새로운 Blue/Green Deployment 기능을 선제적으로 활용하여 DB 업그레이드 작업을 더  안전하고 빠르게 수행하였고, LG ThinQ 플랫폼을 안정적으로 운영하고 있습니다.

데이터베이스 엔진의 버전 업그레이드 작업은 DB엔진의 버그 수정, 보안 강화 및 개선 사항들을 반영하여 보다 안정적인 DB서비스를 운영하기 위하여 지속적으로 수행되어야 하는 필수적인 작업입니다. 특히, 오픈소스 DB 엔진 커뮤니티의 버전 지원 종료와 오픈소스 DB와 호환성을 갖는 Aurora/RDS의 구 버전 수명 종료(EoL: End-of-Life) 전에 DB엔진 버전 업그레이드 작업을 수행하는 것을 권장합니다.

버전 업그레이드 작업 시 Blue/Green Deployment를 사용하면 더 쉽게 작업을 할 수 있으며, LG전자의  사례가 DB 버전 업그레이드 작업 계획 및 진행에 많은 참고가 되기를 기대합니다.

Blue/Green Deployment는 현재 서울 리전을 포함하여 대부분의 AWS 리전에서 사용 가능하며, Aurora for MySQL DB와 RDS for MySQL, RDS for MariaDB에서 사용 가능합니다. 사용할 수 있는 버전 및 지역에 대한 자세한 내용은 블루/그린 배포 사용 설명서를 참고하시기 바랍니다.

Blue/Green Deployment에 대한 자세한 내용은 Aurora용 Amazon RDS 블루/그린 배포 개요  또는  Amazon RDS 블루/그린 배포 개요 사용 설명서를 참고하실 수 있습니다.