1. 배경 지식

Hourly주기로 DataLake에 적재할 필요가 없는 DB Table은 Daily 주기로 복제한다.

DB는 AWS의 Aurora RDS를 사용하기 때문에 Daily 주기로 Cluster와 Instance를 Clone하여 복제한다. backup 성격의 복제 작업이 실 서비스에 영향을 끼치면 안되는 이유와 0시를 기준으로 복제를 하여 멱등성을 보장하기 위해서 Clone을 활용하기로 하였다. (Aurora DB는 최대 35일 전 데이터까지 백업해준다.)

수백개의 Table을 1개의 DAG에서 복제하기보다 DAG마다 비슷한 성격의 테이블들을 모아서 관리하였다. DB Cluster와 Table이 여러개라서 1개의 DAG에서 관리하면 DAG가 너무 커지고 관리하기 어렵다는 문제가 있기 때문이다.

A. 문제 상황

여러개의 DAG에서 DB → DL 복제를 진행할 때 Clone을 진행한다. 그래서 DAG 수만큼 Clone Cluster 및 Instance가 생성되게 된다.

이런 상황은 3가지 문제를 발생시켰다.

1. 불필요하게 많은 수의 Clone Cluster 및 Instance가 생성되었다.
2. 수 많은 Clone이 생성되어서 타이밍 이슈 등으로 정확히 0시를 기준으로 Clone이 되지 않았다.
3. 복제를 위해 사용되는 batch 계정의 Credential은 Secret Manager로 관리하였는데, 이 또한 타이밍 이슈로 일부는 복제에 성공하고 일부는 실패하는 문제가 생겼다.

2. 요구사항

• 비슷한 성격의 테이블들끼리 모아둔 DAG들은 그대로 유지해야 한다.
• Aurora DB Clone은 매 0시를 기준으로 각 Cluster마다 1개만 생성하고 삭제한다.
• Secret Manager로 인해 발생하는 문제도 해결한다.

3. 해결 과정

A. Aurora DB Clone과 관련된 문제

[Aurora DB Clone 문제 개선 도식도]

위 도식도와 같이 Clone DB 생성 작업을 RDS → DL 복제 작업에서 떼어냈다.