TL;DR
S3 버킷당 Event Notification 100개 제한에 부딪혀 Managed File Events(MFE)로 전환했습니다. 공식 문서는 간단해 보이지만, CDC 환경에서는 자칫 잘못하면 데이터 유실이 발상할 수 있습니다. 이 글에서는 CDC 파이프라인에서 MFE로 안전하게 전환하는 방법과, 놓치기 쉬운 내용들을 다룹니다.
문제 상황: S3 Event Notification 한계에 부딪히다
Aurora MySQL에서 DMS를 통해 S3로 CDC 데이터를 적재하고, Databricks Delta Live Tables(DLT)로 ETL 파이프라인을 운영하고 있었습니다. 초기에는 Auto Loader의 Legacy File Notification 모드를 사용했는데, 파이프라인이 늘어나면서 한계에 도달했습니다.
S3 버킷당 Event Notification 설정은 최대 100개로 제한됩니다.(Hard Limit) Legacy File Notification 모드에서는 파이프라인마다 개별 SNS/SQS를 생성하기 때문에, 테이블 수가 늘어날수록 이 한계에 빠르게 도달합니다. 새로운 테이블을 추가하려면 기존 파이프라인을 통합하거나 버킷을 분리해야 하는 상황이 왔습니다.
해결책: Managed File Events(MFE)
Databricks의 Managed File Events는 이 문제를 해결해 줍니다. MFE는 Databricks가 관리하는 단일 SNS/SQS 인프라를 모든 파이프라인이 공유하는 방식입니다. 버킷당 1개의 Event Notification만 사용하므로 사실상 파이프라인 확장에 제한이 없어집니다.
MFE의 Trade-off
물론 MFE도 만능은 아닙니다. 공유 인프라를 사용하기 때문에 처리량 제한이 있습니다. AWS 환경에서는 초당 약 2,000건의 파일 이벤트 처리가 한계입니다. 대규모 배치성 파일 적재가 빈번한 환경이라면 이 제한을 고려해야 합니다. 다만 현재 저희 환경에서는 충분히 감당 가능한 수준이었습니다.
왜 주의해야 하는가 : CDC 환경의 함정
공식 문서의 마이그레이션 절차는 다음을 안내합니다:
- tearDownNotificationResources API로 기존 SNS/SQS 제거
- External Location에 File Events 활성화
- cloudFiles.useManagedFileEvents를 true로 설정
- 기존 cloud-specific 옵션 제거
- 스트림 재시작 (첫 실행 시 directory listing으로 동기화)
이 절차는 소스 데이터 유입을 중단할 수 있는 환경에서는 동작합니다. 예를 들어 배치성 파일 적재라면, 적재를 잠시 멈추고 SQS의 모든 메시지를 처리한 뒤 전환하면 됩니다.
하지만 CDC 환경에서는 이야기가 다릅니다.
DMS는 계속 돌아가고 있고, S3에는 끊임없이 새 파일이 생성됩니다. 이 상태에서 tearDownNotificationResources를 호출하면 어떻게 될까요?
- SQS에 아직 처리되지 않은 메시지가 남아있는 상태에서 큐가 삭제됩니다
- 해당 메시지에 해당하는 파일들은 Auto Loader가 인식하지 못합니다
- 데이터 유실 발생
물론 DMS를 중단하고, SQS 메시지를 모두 소진한 뒤, MFE로 전환하고, 다시 DMS를 시작하는 방법도 있습니다. 하지만 이 방식은 다운타임이 길어지고, "메시지를 충분히 다 받았다"는 것을 확인하기도 쉽지 않습니다.
결국 CDC 환경에서 안전하게 전환하려면 Full Refresh가 필수입니다. 전환 과정에서 일부 데이터 유실이 발생할 수 있음을 인정하고, Full Refresh로 소스 데이터와 정합성을 다시 맞추는 것이 현실적인 방법이었습니다.
문서에서 살펴보기 어려웠던 것들
CDC 환경의 문제 외에도, 실제 적용 과정에서 문서에서 놓치기 쉬운 함정들을 만났습니다.
1. 숨겨진 File Events 활성화 버튼
MFE를 사용하려면 External Location에서 File Events를 활성화해야 합니다. 문제는 이 설정 버튼이 UI에서 바로 보이지 않는다는 것입니다.
2. Unity Catalog 권한 설정의 함정
DLT 파이프라인이 Unity Catalog를 사용한다면, 파이프라인 Runner(Service Principal 또는 User)에게 적절한 권한이 부여되어야 합니다. 문서에는 이 부분이 명확하게 설명되어 있지 않았습니다.
3. S3 경로 표기법: s3a:// → s3:// (중요)
이건 정말 예상하지 못한 부분이었습니다. 기존 Legacy File Notification 모드에서는 s3a://bucket-name/path 형식을 사용했습니다. MFE로 전환 후 동일한 경로를 사용했더니 파일을 인식하지 못했습니다.
이 부분을 수정하지 않으면, 파이프라인은 정상적으로 돌지만 실제로 데이터를 가져오지 못하는 이슈가 발생합니다.
(참고) s3a:// 형식으로 기술했던 것은 Hadoop/Spark 오픈소스 생태계의 S3 접근 프로토콜. MFE 모드에서 스킴을 s3a로 해도 에러는 발생하지 않으나 실제로 동작하지 않음
# 기존 Legacy File Notification 모드
# path = "s3a://my-bucket/cdc-data/"
# MFE 모드에서는 이렇게 변경해야 합니다
path = "s3://my-bucket/cdc-data/"
4. 제거해야 하는 기존 옵션들
문서에서는 cloudFiles.queueUrl 같은 cloud-specific 옵션을 제거하라고 안내하고 있습니다. 하지만 실제로는 문서에 언급되지 않은 옵션들도 제거해야 했습니다.
cloudFiles.queueName
cloudFiles.subscription
databricks.serviceCredential
cloudFiles.privateKey
cloudFiles.clientSecret
실제 마이그레이션 과정
CDC 환경에서 데이터 유실 없이 MFE로 전환한 실제 과정입니다.
Step 1. 모든 관련 파이프라인 중지
전환 대상 DLT 파이프라인들을 모두 중지합니다. 이 시점부터 DMS가 S3에 적재하는 파일들은 처리되지 않습니다.
Step 2. 기존 Notification 리소스 제거
tearDownNotificationResources API를 사용하여 기존 SNS/SQS 리소스를 제거합니다. 이때 SQS에 남아있던 미처리 메시지는 유실됩니다.
Step 3. MFE 설정 적용
- External Location에서 File Events 활성화
- 노트북 코드에서 S3 경로를 s3:// 형식으로 변경
- cloudFiles.useManagedFileEvents = true 설정
- 기존 cloud-specific 옵션 및 불필요한 옵션 제거
Step 4. 파이프라인 재시작 및 Full Refresh 실행
파이프라인을 재시작하고, 해당 파이프라인에 참조되는 모든 테이블에 대해 Full Refresh를 실행합니다. 이 과정에서 소스 데이터와 정합성이 다시 맞춰집니다.
Step 5. 검증
External Location의 Test Connection 기능으로 File Events가 정상 동작하는지 확인하고, 데이터 정합성을 검증합니다.
덤으로 얻은 것: 파이프라인 분리와 고가용성
이번 작업을 계기로 기존에 단일 스키마로 운영하던 구조를 소스 DB 스키마 기준으로 분리했습니다. 이전에는 하나의 거대한 파이프라인이 모든 테이블을 처리했다면, 이제는 스키마별로 독립된 파이프라인이 동작합니다.
이 구조 변경으로 얻은 이점:
- 장애 격리: 특정 스키마에 문제가 생겨도 다른 스키마의 데이터 처리에 영향을 주지 않습니다
- 운영 유연성: 스키마 단위로 Full Refresh나 장애 대응이 가능해져 운영 부담이 줄었습니다
- 데이터 일관성: 각 파이프라인의 데이터 일관성 경계가 명확해졌습니다
마이그레이션 체크리스트
비슷한 전환을 계획하고 계신 분들을 위해 체크리스트를 정리했습니다.
사전 준비
- Databricks Runtime 14.3 LTS 이상 사용 여부 확인
- Unity Catalog 활성화 여부 확인
- 필요한 권한 확보 (CREATE STORAGE CREDENTIAL, CREATE EXTERNAL LOCATION 등)
- Full Refresh 소요 시간 산정 및 다운타임 확보
마이그레이션 실행
- 모든 관련 DLT 파이프라인 중지
- tearDownNotificationResources API로 기존 리소스 제거
- External Location에 File Events 활성화
- 노트북 코드에서 S3 경로를 s3:// 형식으로 변경
- cloudFiles.useManagedFileEvents = true 설정
- 기존 cloud-specific 옵션 및 불필요한 옵션 제거
- 파이프라인 재시작 및 Full Refresh 실행
검증
- External Location의 Test Connection으로 File Events 정상 동작 확인
- 데이터 정합성 검증
마치며
MFE 전환 자체는 올바른 선택이었습니다. S3 Event Notification 제한에서 벗어나 파이프라인 확장성을 확보했고, 부수적으로 아키텍처도 개선할 수 있었습니다.
다만 CDC 환경에서는 주의하지 않으면 데이터가 유실됩니다. 문서는 소스 데이터 유입을 중단할 수 있는 환경을 전제로 작성되어 있기 때문입니다. CDC 파이프라인을 운영하고 계신다면, Full Refresh를 위한 충분한 다운타임을 확보하시길 권합니다.