RDS 블루/그린 배포 feat. 롤백

블루/그린 배포란?

• 상용 서비스는 시중에 나왔다고 끝이 아닙니다
• 지속적으로 버그 픽스, 새로운 기능 개발 등 꾸준한 관리가 필요합니다
• 그러다보면 기존에 돌아가고 있는 서비스를 어떻게 새로운 버전으로 바꿀지(배포)를 고민하게 되는데요
• 이러한 것을 위해 다양한 배포 전략이 있습니다
• 배포 전략에는 크게 4가지로 나누어 볼 수 있습니다
  1. 인플레이스 배포 (In-Place Deployment)
  2. 롤링 배포 (Rolling Update Deployment)
  3. 블루/그린 배포 (Blue/Green Deployment)
  4. 카나리 배포 (Canary Deployment)

인플레이스 배포 (In-Place Deployment)

• 기존 서비스들을 중지하고 새로운 서비스들을 올려서 배포하는 방식으로 가장 간단하고 기본적인 배포 방법입니다
• 직관적이고 서버 증설이 필요 없다는 장점이 있지만, 배포할 동안에는 서비스를 이용할 수 없다는 단점이 있습니다

롤링 배포 (Rolling Update Deployment)

 

 

• 구버전에서 새로운 버전으로 점진적으로 배포하는 방법입니다
• 상황에 따라 다르지만 서버 증설을 안해도 됩니다
• 구버전 서버에 이미 신버전이 배포되었기 때문에 롤백이 어렵습니다
• 새 버전을 배포하면서 구버전의 서버 갯수가 줄어들기 때문에 트래픽이 몰릴 수 있습니다
• 이를 해결하기 위해 온프레미스는 힘들지만 클라우드 환경에서는 추가적으로 vm을 생성해서 전체 용량을 유지하는 방식도 있습니다
• 배포가 진행될 때 구버전과 신버전이 공존하여 호환성 문제가 발생할 수 있습니다

블루/그린 배포 (Blue/Green Deployment)

• 구버전만큼 신버전도 배포를 한 후에 서비스 준비가 되면 구버전에서 신버전으로 라우팅만 바꿔주는 배포 방법입니다
• 한번에 배포하고 라우팅만 바꾸기 때문에 배포 속도가 빠릅니다
• 라우팅만 바꿔주면 되기 때문에 롤백하기도 쉽습니다
• 버전 호환성을 유지하면서 서비스 중단을 최소화한 상태로 배포가 가능합니다
• 구버전 갯수만큼 서버를 증설해야 하기 때문에 추가 비용이 발생할 수 있습니다

카나리 배포 (Canary Deployment)

• 전체에서 특정 비율만 신버전을 배포한 후에 문제가 없는지 검증을 한 후에 점진적으로 배포하는 방법입니다
• A/B 테스트가 가능하고, 신버전을 일부 사용자에게만 제공하기 때문에 문제가 발생해도 전체 시스템에 영향을 주지 않습니다
• 안정성이 검증된 후에 전체 배포가 가능합니다
• 일부 비율에만 배포를 하였고 라우팅만 조절하면 되기 때문에 롤백이 쉬운 편입니다
• 서비스 중단 없이 배포가 가능합니다
• 운영 및 설정이 복잡하고, 트래픽 관리가 필요하기 때문에 추가 솔루션이 필요합니다

RDS 블루/그린 배포

• AWS RDS에는 자체적으로 블루/그린 배포를 지원하고 있습니다
• 그래서 간단하게 버전 업그레이드를 진행할 수 있습니다
• 블루/그린 배포이기 때문에 거의 무중단입니다 (블루에서 그린으로 전환할 때 순단이 발생)
• 추가로 엔드포인트도 바뀌지 않기 때문에 애플리케이션 단에서 코드 수정이 불필요합니다👍

사전 준비

• 여기서 중요한 점이 구 RDS의 DB 파라미터 그룹을 수정했을 경우에 새로 배포할 RDS의 DB 파라미터 그룹도 동일하게 수정을 해주어야 한다는 점입니다
• RDS 블루/그린 배포는 binlog를 통해서 동기화를 진행하기 때문에 충돌을 줄이기 위해서 binlog=ROW로 진행하는 것을 권장합니다
  https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-creating.html https://repost.aws/ko/questions/QUNaoRzPYORK-y43h-IXvW7w/aurora-my-sql-blue-green-%EB%B0%B0%ED%8F%AC-%EC%8B%9C-binlog-format-%EB%AC%B8%EC%9D%98

 

• 블루/그린 전환을 수행하고 난 후, 문제가 생겼을 때 롤백을 제대로 하려면 binlog 파일이 남아있어야 합니다. 그렇기 때문에 binlog 보유 기간을 충분한 기간으로 설정합니다

• # 바이너리 로깅 활성화 확인
  mysql> show variables like 'log_bin';
  +----------------+------------+
  | Variable_name  | Value      |
  +----------------+------------+
  | log_bin        | ON         |
  +----------------+------------+
  
  # SET binlog_format=ROW;
  mysql> show variables like 'binlog_format';
  +----------------+------------+
  | Variable_name  | Value      |
  +----------------+------------+
  | binlog_format  | ROW        |
  +----------------+------------+

• # 바이너리 로깅 보존 기간 설정 (여기선 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)

1. 블루/그린 배포 생성하기

• AWS에서 지원하는 기능이기 때문에 수정 옵션에서 간단하게 확인 가능합니다

• 간단하게 배포 이름을 생성(안 중요함, 원하는 걸로 설정)

• 새로 배포할 RDS에 대한 구성을 설정합니다

2. 영향도 체크 및 검증

• 새로 만들어진 신버전(그린)의 데이터 및 스키마가 잘 복사되었는지 확인합니다

3. 블루/그린 전환

• 상태가 모두 ✔사용 가능 으로 바뀌었다면 전환이 가능합니다
• 전환은 새로 만들어진 블루/그린 배포의 작업 옵션에서 가능합니다

• 또는 aws cli 명령어로도 가능합니다
  https://docs.aws.amazon.com/cli/latest/reference/rds/switchover-blue-green-deployment.html

aws rds switchover-blue-green-deployment --blue-green-deployment-identifier bgd-nhyog5tfmuijg23o

switchover-blue-green-deployment — AWS CLI 1.37.24 Command Reference

 

4. 애플리케이션 테스트

• 전환되고 나서 새로운 RDS가 애플리케이션에서 기능 동작을 하는데 문제가 발생하지 않는지 검증합니다

5. 완료

• 남은 구버전 RDS와 블루/그린 배포를 삭제해주면 완료입니다
• 바로 삭제하지 않고 몇일 정도 서비스를 운영해보고 문제 없다고 판단 시에 삭제하는 것을 권장드립니다

※ 롤백 방법

• 전환하는 도중에 지정한 timeout 시간 내에 성공을 못하거나 문제가 생기면 자동으로 롤백을 해줍니다
• 하지만 전환이 완료되고 난 이후에 다시 롤백을 하려면 수동으로 해야 합니다; ㅡㅡ (어이X)

• 기존에 구버전이 남아있다면 애플리케이션에 엔드포인트만 바꿔주면 됩니다
• 혹시나 삭제를 했다면… binlog를 통해서 복제를 해야합니다

수동 롤백 방법

• A를 전환했는데 문제가 생긴 프로덕션 DB, B를 롤백 DB라고 하겠습니다
• 목표: A->B로 복제하고, 애플리케이션이 B를 바라보게 만들기

A DB) binlog 확인

• 바이너리 로그 파일 이름과 위치를 확인합니다
• 메모해두세요

mysql> show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000007 |     2638 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.07 sec)

B DB) 읽기 모드 설정

• A에서 B로 복제하려는데, B에 누가 쓰기를 하면 안되니까 읽기 모드로 전환
• 매개변수 그룹의 값을 0에서 1로 read_only변경
• 동적 매개변수이므로 재부팅 없이도 수정 사항이 적용됩니다

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

A DB) 작업용 사용자 생성

• B에서 A로 접근할 때 사용할 사용자를 생성합니다 (여기서는 repl_user로 만듦, 아무거나 하세요)

mysql> CREATE USER 'repl_user'@'<IP_address>' IDENTIFIED BY '<password>';

• 사용자에게 다음 권한이 필요합니다
  • REPLICATION CLIENT : 마스터의 binlog 파일과 현재 복제 상태를 조회할 수 있는 권한 (조회만)
  • REPLICATION SLAVE : 슬레이브 서버에서 마스터 서버의 데이터를 복제할 수 있음 (데이터 가져오기)

mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<IP_address>'; 
mysql> FLUSH PRIVILEGES;

B DB) binlog로 복제하기

1. B DB에서 rds_set_external_master 를 사용하여 수동 MySQL 복제를 구성하는 SQL 명령을 실행합니다
2. 이전에 수집한 MySQL binlog 파일 이름과 위치를 사용합니다

mysql> call mysql.rds_set_external_master ('database-1-instance-1.xxxxxxxxx.xxxx.rds.amazonaws.com', 3306, 'repl_user', '<Password>', '<Binlog file>', '<Binlog position>', 0);

1. rds_start_replication을 사용하여 B DB에서 MySQL 복제 프로세스를 시작합니다

mysql> CALL mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.03 sec)

1. ※ Aurora MySQL 버전 3부터 데이터 제어 언어(DCL)문(ex.CREATE USER,GRANT,REVOKE)은 더 이상 바이너리 로그 복제와 함께 복제되지 않습니다.
   복제가 필요하다면 해당 DCL문을 A, B DB 둘 다에서 실행해야 합니다.
2. B DB에서 show slave status를 사용하여 MySQL 복제 상태를 검증 하고 복제 프로세스가 오류 없이 실행 중인지 확인합니다
   Slave_IO_Running가 Connecting이 아니라 Yes여야 함

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

A DB, B DB) 롤백 단계 (복제 완료 후 전환 단계)

1. A DB에 접속해서 쓰기 작업을 방지하기 위해 DB 매개변수 그룹의 값을 0에서 1로 read_only변경
2. B DB에 접속해서 A DB 복제를 완료했는지 확인합니다
   1. Seconds_Behind_Master = 0 확인
   2. Relay_Master_Log_File 값이 마스터의 mysql-bin-changelog.xxx과 같은지 확인
   3. Exec_Master_Log_Pos 값이 마스터의 Position 값과 동일한지 확인

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:

...

1. B DB에서 다음 명령을 사용하여 복제 프로세스를 중지합니다.

mysql> call mysql.rds_stop_replication;

1. B DB에서 MySQL 복제 구성 정보를 제거하기 위해 rds_reset_external_master를 사용합니다.

mysql> call mysql.rds_reset_external_master;

1. B DB에서 read_only사용자 지정 데이터베이스 매개변수 그룹 설정에서 매개변수를 1에서 0으로 변경하여 읽기 전용 모드를 끕니다
2. 애플리케이션에서 B DB 엔드포인트를 사용하도록 소스 코드를 수정합니다

참고 링크)

https://aws.amazon.com/ko/blogs/database/implement-a-rollback-strategy-after-an-amazon-aurora-mysql-blue-green-deployment-switchover/

Implement a rollback strategy after an Amazon Aurora MySQL blue/green deployment switchover | Amazon Web Services

 

추가 고려 사항

• Route53으로 카나리 배포처럼 일부 트래픽을 제어해서 몇일 동안 검증한 후에 블루/그린 전환하는 방법

• Route53은 가중치 기반 트래픽 제어가 가능합니다 (가중치 이외에도 지역 기반, 사용자 위치 기반 등 트래픽 제어 가능)