AWS 기술 블로그

Amazon Aurora MySQL 블루/그린 배포 전환 후 롤백 전략 구현

이 글은 AWS Database 블로그에 게시된 Implement a rollback strategy after an Amazon Aurora MySQL blue/green deployment switchover by Daxeshkumar Patel, Bhavesh Rathod, and Kamal Singh 을 한국어 번역 및 편집하였습니다.

Amazon Web Services(AWS)에서 제공하는 고성능, 완전 관리형 관계형 데이터베이스 서비스인 Amazon Aurora는 사용자에게 데이터베이스 업데이트를 보다 안전하고 간단하며 빠르게 수행할 수 있는 블루/그린 배포 기능을 제공합니다. 블루/그린 배포는 논리적 복제를 사용하여 완전 관리형 스테이징 환경을 생성합니다. 이를 통해 프로덕션 변경 사항을 배포 및 테스트하고 현재 프로덕션 데이터베이스를 더욱 안전하게 유지할 수 있습니다. 블루 환경은 현재 프로덕션 워크로드를 관리하는 데이터베이스를 나타내고, 그린 환경은 필요한 업데이트나 변경 사항을 적용하여 작동합니다. 블루/그린 배포는 주요 또는 마이너 엔진 버전 업그레이드 및 시스템 업데이트와 같은 데이터베이스 업데이트 또는 변경과 관련된 위험을 최소화하고 가동 중지 시간을 줄입니다. 이를 통해 애플리케이션 엔드포인트를 변경하지 않고도 스테이징 환경을 효율적으로 전환하여 새로운 프로덕션 환경으로 만들 수 있습니다.

그린 환경에서 신중한 계획과 엄격한 테스트에도 불구하고 블루/그린 배포 전환 후에 예상치 못한 문제가 발생할 수 있습니다. 예를 들어, 새로운 프로덕션 환경과 애플리케이션의 호환성 문제가 발생할 수 있으며, 이는 테스트 단계에서 발견되지 않았을 수 있습니다. 또한 새로운 프로덕션 환경에서 워크로드나 리소스 수요가 증가하여 애플리케이션 성능 저하가 발생할 수 있으며, 이는 테스트 중에 정확하게 시뮬레이션되지 않았을 수 있습니다. 이러한 경우를 대비하여 롤백 계획을 세우는 것이 중요합니다.

이 게시물에서는 블루/그린 배포 전환을 수행하는 단계와 Amazon Aurora MySQL 호환 에디션에 대한 전환 후 롤백 전략을 설정하고 수행하는 방법에 대해 설명합니다.

솔루션 개요

성공적인 Aurora MySQL 블루/그린 배포 생성 및 전환에 따라 그린 환경은 새로운 프로덕션 환경이 됩니다. 현재 프로덕션 환경의 이름과 엔드포인트는 애플리케이션을 변경할 필요 없도록 새로 승격된 프로덕션 환경에 할당됩니다. 전환 후 이전 프로덕션 환경은 더 이상 새로 승격된 프로덕션 환경과 동기화되지 않습니다. 이전 프로덕션 환경의 DB 클러스터 및 DB 인스턴스는 현재 이름에 -oldn을 추가하여 이름이 변경됩니다. 여기서 n은 숫자이며 이 이전 환경을 롤백 전략으로 사용할 수 있습니다. 이 접근 방식에서는 예상치 못한 문제가 발생할 경우 롤백 계획을 달성하기 위해 전환 후 새 프로덕션 환경에서 이전 환경으로의 논리적 복제를 수동으로 설정합니다.

다음 다이어그램은 Aurora MySQL 블루/그린 배포 전환 후 롤백 전략을 보여줍니다.


이 솔루션을 구현하기 위한 대략적인 단계는 다음과 같습니다.

  1. 롤백을 위해 그린 환경(스테이징)을 준비합니다.
  2. Aurora MySQL 블루/그린 배포 전환을 수행합니다.
  3. Aurora MySQL 블루/그린 배포를 삭제합니다. 이 단계에서는 블루/그린 배포를 삭제해도 데이터베이스 환경에 영향을 주지 않습니다.
  4. 프로덕션 환경에서 롤백 환경으로 논리적 복제를 구성합니다.
  5. 프로덕션 환경에 문제가 있는 경우 롤백 환경으로 전환하세요.

이 게시물에서는 Aurora MySQL 호환 에디션 버전 2(MySQL 5.7)를 블루 환경으로 사용하고 Aurora MySQL 호환 에디션 버전 3(MySQL 8.0)을 그린 환경으로 사용합니다.

전제조건

이 솔루션을 구현하려면 다음 구성 요소가 필요합니다.

  • Aurora MySQL 블루/그린 배포. 설정 지침은 블루/그린 배포 생성을 참조하세요.
  • Aurora MySQL 그린 클러스터는 사용자 지정 데이터베이스(DB) 클러스터 파라미터 그룹과 연결되어야 합니다. Aurora DB 클러스터 파라미터 그룹에 대한 자세한 내용은 DB 클러스터 파라미터 그룹 작업을 참조하십시오.

제한사항

이 솔루션과 관련된 제한 사항은 다음과 같습니다.

  • MySQL은 더 높은 메이저 버전을 실행하는 소스 데이터베이스 인스턴스에서 더 낮은 메이저 버전을 실행하는 대상 데이터베이스 인스턴스로의 복제를 공식적으로 지원하지 않습니다. 따라서 복제에 문제가 발생할 수 있습니다(자세한 내용은 MySQL 버전 간 복제 호환성 참조). 새로운 환경에 적응하는 동안 짧은 시간 동안만 롤백 전략을 유지하게 되는데, 이 기간 동안에는 새 데이터베이스 버전에서만 사용할 수 있는 새로운 데이터베이스 기능을 사용하지 않도록 주의하세요. 이로 인해 MySQL 복제 오류가 발생하고 이전 버전으로 롤백할 가능성이 막힐 수 있습니다.
  • MySQL 복제 환경에서 스키마 변경을 관리하려면 신중한 계획이 필요합니다. ALTER TABLE, CREATE TABLE 또는 DROP TABLE 문과 같은 일부 스키마 변경 사항은 이 롤백 솔루션에서 작동하지 않을 수 있습니다.

롤백을 위한 그린 클러스터 환경 준비하기

블루/그린 배포 전환 전에 롤백을 위한 그린 환경을 구성합니다.

Aurora MySQL 바이너리 로깅 구성하기

Aurora MySQL 블루/그린 배포 전환 전에 바이너리 로깅이 활성화되어 있고 그린 환경에서 바이너리 로그를 캡처하는지 확인하십시오. 이러한 바이너리 로그는 지속적인 복제에 중요합니다. 기본적으로 바이너리 로그는 Aurora MySQL에서 비활성화되어 있으며 데이터가 Aurora 클러스터 외부로 복제되지 않는 한 활성화할 필요가 없습니다. 바이너리 로그를 활성화하려면 원본 DB 클러스터에 연결된 사용자 지정 DB 클러스터 파라미터 그룹에서 binlog_format 파라미터를 ROW 또는 MIXED로 설정합니다. binlog_format은 정적 파라미터이므로 변경 사항을 적용하려면 클러스터의 라이터 DB 인스턴스를 재부팅해야 합니다. 따라서 전환 후 재부팅이나 중단을 방지하려면 블루/그린 배포 전환 전에 그린 환경에서 binlog_format 매개변수를 활성화하는 것이 좋습니다. MySQL 바이너리 로깅에 대한 자세한 내용은 Aurora MySQL 바이너리 로깅 구성을 참조하십시오.

그린 Aurora DB 클러스터에서 바이너리 로깅이 활성화되어 있는지 확인하려면 인스턴스에 연결하고 다음 명령을 실행하십시오.

mysql> show variables like 'log_bin';
+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| log_bin        | ON         |
+----------------+------------+

이 게시물에서는 binlog_format 매개변수를 ROW로 설정했습니다.

mysql> show variables like 'binlog_format';
+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| binlog_format  | ROW        |
+----------------+------------+

Aurora MySQL 바이너리 로그 보존 기간 구성하기

롤백 접근 방식으로 논리적 복제를 사용하는 경우 그린 환경의 바이너리 로그가 충분한 기간 동안 유지되는지 확인하는 것이 중요합니다. 바이너리 로그 보존 시간을 설정하려면 mysql.rds_set_configuration 프로시저를 사용하고 구성 매개변수 binlog retention hours와 DB 클러스터에 바이너리 로그를 보존할 시간값을 지정합니다. Aurora MySQL 3.x 및 Aurora MySQL 버전 2.11 이상의 최대값은 90일이며, binlog retention hours의 기본값은 NULL입니다. 이는 바이너리 로그가 보존되지 않음을 의미합니다. 바이너리 로그 보존 기간은 프로덕션 환경과 롤백 환경 간의 최대 복제 지연을 처리하기에 충분해야 합니다. 이제 블루/그린 전환을 완료하고 롤백 환경에서 복제를 구성할 때입니다. Aurora MySQL 바이너리 로그 보존에 대한 자세한 내용은 바이너리 로그 보존 구성을 참조하십시오.

이 게시물에서는 그린 환경에서 바이너리 로그 보존 시간을 24시간으로 설정했습니다. 이는 블루/그린 전환을 수행하고 롤백 환경으로 다시 복제를 구성하는 데 충분한 시간을 제공할 것입니다.

mysql> CALL mysql.rds_set_configuration('binlog retention hours', 24);

        Query OK, 0 rows affected (0.01 sec)

변경 후 바이너리 로그 보존 기간을 확인합니다.

mysql> CALL mysql.rds_show_configuration\G
*************************** 1. row ***************************
       name: binlog retention hours
      value: 24
description: binlog retention hours specifies the duration in hours before binary logs are automatically delete
1 row in set (0.00 sec)

Aurora MySQL 블루/그린 배포 전환을 수행하기

전환에는 DB 클러스터 및 관련 DB 인스턴스를 그린 환경에서 새로운 프로덕션 DB 클러스터로 승격시키는 작업이 포함됩니다. 전환 전에 프로덕션 트래픽은 블루(현재 프로덕션) 환경의 클러스터로 전달됩니다. 전환이 성공적으로 완료되면 프로덕션 트래픽은 이전에 그린(스테이징) 환경이었던 새로 승격된 DB 클러스터로 라우팅됩니다.

  1. Aurora MySQL 블루/그린 배포 전환을 수행합니다. 단계에 대한 자세한 내용은 블루/그린 배포 전환을 참조하고 전환 모범 사례는 전환 모범 사례를 참조하세요.전환이 완료되면 Aurora용 AWS Management Console의 데이터베이스 옆에 ‘Old Blue’와 ‘New Blue’가 표시됩니다. 새로운 블루 환경은 새로 승격된 프로덕션 환경입니다.전환 후 이전 블루 DB 클러스터는 재부팅할 때까지 읽기 작업만 허용합니다.

    전환 후에는 이전 프로덕션 환경의 Aurora MySQL DB 클러스터와 DB 인스턴스가 유지됩니다. 이러한 리소스에는 표준 비용이 적용됩니다.
  2. 전환 후 새 블루 환경에서 바이너리 로그 파일 이름과 위치를 가져옵니다. 자세한 내용은 바이너리 로그 좌표 가져오기를 참조하십시오. 다음 AWS 명령줄 인터페이스(AWS CLI) 명령을 사용하여 현재 바이너리 로그 파일 이름과 위치를 찾을 수 있습니다. 
    aws rds describe-events --output json --source-type db-instance --source-identifier database-1-instance-1

{
    "Events": [
...
        {
            "SourceIdentifier": "database-1-instance-1",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000007 and position 2638",
            "EventCategories": [],
            "Date": "2024-03-10T01:33:41.911Z",
...
       }
    ]
}
  3. 블루/그린 배포를 삭제합니다.
    참고: 블루/그린 배포를 전환하기 전에 삭제하면 Amazon RDS는 선택적으로 그린 환경에서 DB 클러스터를 삭제합니다. 블루/그린 배포를 삭제해도 블루 환경에는 영향을 미치지 않습니다. 자세한 내용은 블루/그린 배포 삭제를 참조하세요.

    블루/그린 배포를 삭제하면 다음 이미지에 표시된 것처럼 신규 및 기존 프로덕션 DB 클러스터가 사용 가능한 상태가 됩니다.

  4. 새 프로덕션 환경에서 이전 환경으로의 복제에 문제를 일으킬 수 있는 쓰기 작업을 방지하려면 이전 프로덕션 DB 클러스터를 읽기 전용 모드로 설정하세요. DB 클러스터에 대한 쓰기 작업을 방지하려면 DB 클러스터 파라미터 그룹의 read_only 값을 0에서 1로 변경하여 읽기 전용 데이터베이스 모드를 활성화하십시오.
    이는 동적 매개변수이므로 재부팅할 필요 없이 수정 사항이 적용됩니다.

  5. 이전 프로덕션 DB 클러스터에 연결하고 변경 사항이 적용된 후 DB 인스턴스 모드를 검증합니다. 
    mysql> show global variables like 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON    |
+---------------+-------+

참고: Aurora 블루/그린 배포를 삭제한 후에는 ‘블루’ 또는 ‘그린’이라는 용어는 더 이상 관련이 없습니다. 이 게시물에서는 ‘새 프로덕션’ 또는 ‘새 블루’ 환경을 프로덕션 환경으로, ‘이전 프로덕션’ 또는 ‘이전 블루’ 환경을 롤백 환경으로 지칭합니다.

프로덕션 DB 클러스터에서 복제 사용자 구성하기

  1. 프로덕션 데이터베이스에서 복제 데이터베이스 사용자를 생성합니다. 이 게시물에서는 repl_user라는 사용자를 만듭니다. 
    mysql> CREATE USER 'repl_user'@'<IP_address>' IDENTIFIED BY '<password>';
  2. 이 사용자에게는 REPLICATION CLIENT 및 REPLICATION SLAVE 권한이 필요합니다. 사용자에게 이 권한들을 부여합니다. 
    mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<IP_address>';

프로덕션에서 롤백 DB 클러스터로 바이너리 로그 복제 구성하기

  1. 롤백 환경 DB 클러스터 엔드포인트에 연결하고 SQL 명령을 실행하여 rds_set_external_master를 사용하여 수동 MySQL 복제를 구성합니다. 이전에 수집한 MySQL 바이너리 파일 이름과 위치를 사용합니다. 
    mysql> call mysql.rds_set_external_master ('database-1-instance-1.xxxxxxx.xxxx.rds.amazonaws.com', 3306, 'repl_user', '<Password>', '<Binlog file>', '<Binlog position>', 0);
  2. rds_start_replication을 사용하여 롤백 환경에서 MySQL 복제 프로세스를 시작합니다. 
    mysql> CALL mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.03 sec)

    Aurora MySQL 버전 3부터 CREATE USER, GRANT 및 REVOKE와 같은 데이터 제어 언어 (Data Control Language, DCL) 문은 더 이상 바이너리 로그 복제를 통해 복제되지 않습니다. 복제가 진행되는 동안 DCL 문을 실행하려는 경우 소스 및 대상 데이터베이스 모두에서 DCL 문을 실행해야 합니다.

  3. 롤백 환경에서 show slave status를 사용하여 MySQL 복제 상태를 확인하고 복제 프로세스가 오류 없이 실행되고 있는지 확인합니다. 
    mysql> pager egrep "Slave_IO_Running|Slave_SQL_Running|Error"
PAGER set to 'egrep "Slave_IO_Running|Slave_SQL_Running|Error"'

mysql> show slave status\G
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                   Last_Error: 
                Last_IO_Error: 
               Last_SQL_Error: 
      Slave_SQL_Running_State: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 

mysql> nopager
PAGER set to stdout

롤백 단계

프로덕션 환경에서 롤백 환경으로의 롤백 시나리오가 발생하는 경우 다음 단계를 따르세요.

  1. 복제 지연을 모니터링하여 롤백 환경이 심각한 지연 없이 프로덕션 환경을 따라갈 수 있는지 확인하세요. 상태를 확인하려면 롤백 DB 클러스터에서 다음 명령을 사용하십시오. 
    mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************

              Master_Log_File: mysql-bin-changelog.000010
          Read_Master_Log_Pos: 2836
               Relay_Log_File: relay-bin.000123
                Relay_Log_Pos: 1569
        Relay_Master_Log_File: mysql-bin-changelog.000010
...
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 5
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:

...
  2. 심각한 복제 지연이 없는 것으로 확인한 후 프로덕션 DB에서 모든 애플리케이션 연결을 중지합니다.
  3. 프로덕션 DB 클러스터에서 쓰기 작업을 방지하려면 DB 클러스터 파라미터 그룹의 read_only 값을 0에서 1로 변경하여 읽기 전용 데이터베이스 모드를 활성화할 수 있습니다.
  4. 읽기 전용 데이터베이스 모드를 활성화한 후 프로덕션 환경에서 SHOW MASTER STATUS\G를 실행하여 바이너리 로그 위치가 변경되지 않은 상태로 유지되는지 확인하세요. 이는 데이터베이스에서 추가 데이터 변경이 발생하지 않음을 확인합니다.
  5. 모든 바이너리 로그 파일과 이벤트가 프로덕션에서 롤백 DB 클러스터로 복제되었는지 확인합니다. 상태를 확인하려면 롤백 DB 클러스터에서 다음 명령을 사용하십시오. 
    mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************
...

        Relay_Master_Log_File: mysql-bin-changelog.000010
...

          Exec_Master_Log_Pos: 2836
...

        Seconds_Behind_Master: 0
...

    위 출력에서 Seconds_Behind_Master값을 확인합니다. 이 값은 0이어야 합니다. 자세한 내용은 Second_Behind_Master를 참조하세요. 또한 프로덕션 DB 클러스터에서 show master status 명령을 사용하여 프로덕션 및 롤백 DB 클러스터가 동기화되었는지 확인하세요.

    mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin-changelog.000010
        Position: 2836
...
1 row in set (0.00 sec)

    롤백 환경의 Relay_Master_Log_File 및 Exec_Master_Log_Pos를 프로덕션 환경의 File 및 Position과 비교합니다. 복제 프로세스를 중지하기 전에 이러한 값들은 일치해야 합니다.

  6. 복제 프로세스를 중지하기 위해 롤백 DB 클러스터에서 다음 명령을 사용하십시오. 
    mysql> call mysql.rds_stop_replication;
  7. MySQL 복제 구성 정보를 제거하기 위해 롤백 DB 클러스터에서 rds_reset_external_master를 사용하십시오. 
    mysql> call mysql.rds_reset_external_master;
  8. 사용자 지정 데이터베이스 파라미터 그룹 설정에서 read_only 파라미터를 1에서 0으로 변경하여 롤백 DB 클러스터에 대한 읽기 전용 데이터베이스 모드를 해제합니다.
  9. 롤백 DB 클러스터 엔드포인트를 사용하도록 애플리케이션 구성을 업데이트하고 애플리케이션을 시작하십시오. 원한다면 프로덕션 클러스터의 모든 연결을 종료하여 롤백 클러스터에 다시 연결되도록 합니다. 이제 롤백 DB 클러스터 환경이 프로덕션 환경이 됩니다.

정리

향후 요금이 발생하지 않도록 하려면 더 이상 사용하지 않거나 향후 사용하지 않을 Aurora MySQL DB 클러스터 리소스를 삭제하는 것이 좋습니다.

요약

이 게시물에서는 Aurora MySQL 블루/그린 배포에서 전환 후 롤백 전략을 구현하기 위한 단계별 절차를 제공했습니다. MySQL 복제의 복잡성을 고려하면 이 솔루션을 프로덕션 환경에 배포하기 전에 비프로덕션 환경에서 철저한 테스트를 수행하는 것이 좋습니다. 이 솔루션은 블루/그린 배포 전환 후 프로덕션 환경에서 문제가 발생할 경우 롤백 계획을 제공합니다.

Yujin Cho

Yujin Cho

조유진 테크니컬 어카운트 매니저는 다양한 데이터베이스의 운영과 데이터 분석 경험을 바탕으로 고객이 데이터 기반의 비즈니스 목표를 달성할 수 있도록 고객과 함께 효율적인 아키텍처와 안정적인 운영 환경을 구성하기 위해 노력하고 있습니다.