AWS Redis 클러스터, DB 인스턴스 가용 영역 변경 작업기 - 가용 영역 통일해서 데이터 통신 비용 절약하자!

안녕하세요. 2024년 9월을 잘 보내고 있으신가요?
저는 잠깐 찾아온 여유가 너무 반갑습니다. 동시에 다시 바빠졌을 때가 두렵긴 하지만 어떻게든 되겠죠? ㅎㅎ

이번에는 AWS DB 인스턴스와 Redis 클러스터의 가용 영역을 변경했던 작업을 기록하고자 합니다.

• 가용 영역을 변경했던 이유는 사용하는 인스턴스들의 가용 영역을 통일해서 데이터 통신 비용을 아끼고자 함이었습니다!

AWS 데이터 통신 비용

• 참고: 자칫하면 줄줄 샐 수 있는 AWS 데이터 통신 비용 살펴보기 - 데이터 통신 비용으로 얼마까지 지출해보셨나요?

간단한 작업이라고 생각했지만 계획했던대로 진행되지 않아서 예상했던 것보다 시간이 오래 걸렸습니다...ㅜㅠ
혹시라도 DB, Redis 인스턴스의 가용 영역을 변경하셔야 한다면 이 글이 도움이 되기를 희망합니다 ㅎㅎ

---

1. Redis 클러스터 가용 영역 변경하기

저는 먼저 Redis 클러스터의 가용 영역부터 변경했습니다.

Redis 클러스터의 가용 영역을 변경하는 것은 크게 2가지 작업이 필요합니다.

1. Redis 클러스터가 사용하고 있는 서브넷 그룹 수정하기
2. Redis 클러스터 내의 인스턴스들 정리하기

1.1. Redis 클러스터가 사용하고 있는 서브넷 그룹 수정하기

Redis 클러스터는 생성할 때 서브넷 그룹을 선택합니다.

읽기 복제본을 추가하거나 노드를 추가하면 서브넷 그룹에 포함된 서브넷에 Redis 인스턴스가 생성되는 것이죠.

 

예를 들어서, 서브넷 그룹에 포함된 서브넷이 subnet1(가용 영역 1), subnet2(가용 영역 2)가 있다면

해당 클러스터의 Redis 인스턴스는 가용 영역 1과 가용 영역 2에 생성될 수 있습니다.

 

언제 노드를 추가해야 할지 모르고 어떤 가용 영역에 노드가 추가될지 모르니 제일 먼저 서브넷 그룹을 수정해야겠죠?

서브넷 그룹을 수정하는 방법은 간단합니다.

 

1. AWS 콘솔에서 Elasticache 서브넷 그룹 페이지에 접속합니다.

 

2. 사용하고 있는 Elasticache 서브넷 그룹을 선택하고 우측 상단의 "수정" 버튼을 클릭합니다.

Elasticache 서브넷 그룹 선택 및 수정

 

3. Elasticache 서브넷 그룹 상세 페이지에 들어왔다면 "관리" 버튼을 클릭합니다.

서브넷 관리 버튼 클릭!

 

4. 원하는 가용 영역에 포함된 서브넷만 남겨두고 "선택" 버튼을 클릭합니다.

사용하고 싶지 않은 서브넷 해제하기!

 

5. 원하는 서브넷만 남은 것을 확인하고 "변경 사항 저장" 버튼을 클릭합니다.

변경 사항 저장 버튼 클릭!

6. 끝!

 

1.2. Redis 클러스터 내의 인스턴스들 정리하기

만약 Redis 클러스터 내에 생성된 인스턴스가 원하는 가용 영역에만 포함되어 있다면 1.1. 만으로 작업이 끝납니다.

하지만 다른 가용 영역에 포함되어 있는 인스턴스가 있다면 이들을 제거해줘야 합니다.

 

1. 제일 먼저 원하는 가용 영역에서 실행되고 있는 Redis 인스턴스가 존재해야 합니다.

원하는 가용 영역에 Redis 인스턴스가 생길 때 까지 노드를 추가합니다.

 

2. 원하는 가용 영역에 Redis 인스턴스가 있다면 해당 인스턴스를 primary 노드로 전환합니다.

 

3. 다른 인스턴스들을 삭제합니다.

 

4. 끝!

 

클러스터 형태로 연결이 관리되고, 프라이머리 노드가 계속 존재하기에 다운 타임 없이 Redis 인스턴스들을 정리할 수 있었습니다!

2. DB 인스턴스 가용 영역 변경하기

DB 인스턴스의 가용 영역을 변경하는데 애를 많이 먹었습니다.

 

처음에는 다음 링크를 따라서 DB 인스턴스의 가용 영역을 변경하려고 했습니다.

• 참고 링크: https://repost.aws/knowledge-center/rds-move-availability-zone

위의 링크에서는 RDS DB 인스턴스를 다중 AZ 배포를 활성화하고

원하는 AZ에 인스턴스가 추가되면 다른 인스턴스는 제거한뒤 다시 다중 AZ 배포를 비활성화 하는 방법입니다.

 

어떻게 보면 1.2. 와 유사한 방식입니다.

 

하지만 서비스 인스턴스들이 DB 인스턴스의 엔드포인트를 사용하고 있었기 때문에

이 방식으로 진행하려면 DB 인스턴스 엔드포인트 설정값을 바꾸기 위해 서비스 인스턴스들의 재배포가 필요했습니다.

 

배포 방식과도 연관되어 있고, 그 때는 '서비스 인스턴스들의 재배포는 안하는 것이 좋지!' 라는 생각이 들어서 다른 방법을 찾았습니다.

 

결과적으로 저는 다음 과정을 통해서 DB 인스턴스의 가용 영역을 변경했습니다.

 

1. 현재 실행 중인 DB 인스턴스의 데이터를 덤프합니다.
- pg_dump 혹은 psql을 사용해서 DB 인스턴스의 데이터를 덤프할 수 있습니다.
- 혹은 dbeaver 같은 GUI 클라이언트를 통해서도 덤프할 수 있으니 편하신 방법을 사용해주세요 ㅎㅎ

2. DB 인스턴스를 삭제합니다.

3. DB 인스턴스를 원하는 가용 영역에 동일한 이름으로 생성합니다.

4. DB 인스턴스의 생성이 완료되면 1에서 덤프한 데이터를 복원합니다.

5. 끝!

---

이번에는 다른 팀의 협조를 구해서 긴 다운타임에도 불구하고 어찌저찌 DB 인스턴스의 가용 영역을 변경할 수 있었습니다.

• 모든 작업을 마치는데 장장 3시간이나 걸렸습니다 ㅜ

하지만 테스트 환경이더라도 이렇게 긴 다운타임이 발생하는 것은 조직 전체적으로 큰 병목을 발생시킵니다.

 

다음에는 이런 문제가 발생하지 않도록 방안을 마련해둬야겠습니다.

 

P.S.

RDS Proxy 기능을 사용했다면 다중 AZ 배포 활성화를 통한 DB 인스턴스의 가용 영역 변경이 가능하지 않았을까 싶습니다.

기회가 된다면 RDS Proxy 기능을 한번 사용해보겠습니다!