DMS를 사용한 RDS to OpenSearch CDC 복제 진행하기 (0) - 들어가는 말
작성 일자 : 2024년 03월 18일
들어가는 말
(해당 부분은 필자의 여정이 어떻게 시작되었는지를 담고 있습니다. 중요하지 않은 부분이니 건너뛰어도 좋습니다. 아래의 "시작하기 전에 알아야 할 것들" 파트는 꼭 읽어주시길 바랍니다.)
필자는 현재 DreamVault 라는 프로젝트 명으로 "생성형 AI를 통해 제작한 음악을 공유하는 플랫폼"을 개발하고 있습니다. 음악과 더불어서 음악을 생성할 때 사용한 프롬프트를 사용자들에게 같이 보여주는 것이 저희 서비스의 핵심 기능인데요. 때문에 한 문단 정도되는 프롬프트의 내용과 음악의 제목, 업로더의 명, 장르, 태그들을 통해서 사용자가 원하는 음악을 찾을 수 있도록 검색 기능을 제공하고자 하였습니다.
시나리오
- 사용자가 원하는 음악을 찾기 위해서 검색창에
Happy라는 키워드를 입력합니다. - 검색 결과로
Happy라는 키워드를 포함한 프롬프트의 내용, 음악의 제목, 업로더의 명, 장르, 태그들을 가진 음악들이 나타냅니다. - 사용자가 자신이 생성한 음악을 새로 업로드하였습니다. 이때, 업로드한 음악의 프롬프트 내용이
Adrenaline이라는 키워드를 포함하고 있습니다. - 사용자가
Adrenaline이라는 키워드를 검색창에 입력합니다. - 검색 결과로 방금 사용자가 업로드한 음악이 나타납니다(CDC).
- RDS에 저장되어 있는 음악이 삭제되었을 때, OpenSearch에도 동일하게 삭제되어야 합니다(CDC).
그러면 왜 OpenSearch를 사용하게 되었나요?
저희 팀은 AWS로 배포를 유지하면서, 과금을 피하고자 프리티어 라는 제약 조건을 가지고 있었습니다. 때문에 아래와 같은 선택지들 사이에서 고민을 걸친 결과, OpenSearch + DMS의 조합을 사용하기로 결정하였습니다.
- ELK(Elasticsearch, Logstash, Kibana) 스택을 EC2 인스턴스에 배포
- EC2 프리티어 인스턴스인 t2.micro(1 vCPU / 1GiB RAM)로 배포하였을 때, 메모리 부족으로 인한 성능 저하가 발생할 수 있음
- EC2 프리티어 인스턴스를 React와 Spring Boot를 배포하기 위해 사용 예정
- 장점으로는 Logstash와 JDBC를 이용한 데이터베이스 테이블 역정규화(참고 링크)
- OpenSearch를 이용한 검색엔진 + Logstash를 이용한 CDC
- 위와 마찬가지로 EC2 프리티어 인스턴스에 React, Spring Boot와 함께 배포하였을 때의 성능 문제
- 장점도 위와 동일
- OpenSearch를 이용한 검색엔진 + DMS를 이용한 CDC (A.K.A 험한 길)
- EC2와 비슷하게 OpenSearch도 월 750시간의 t2.small.search 또는 t3.small.search 인스턴스와 10GB의 스토리지를 제공(OpenSearch 프리티어 요금제)
- DMS도 월 750시간의 Single-AZ dms.t2.micro 인스턴스와 50GB의 스토리지를 제공(DMS 프리티어 요금제)
- 다만, 레퍼런스의 부족과 DMS to OpenSearch 마이그레이션 작업에서 지원되는 데이터 타입이 제한적이라는 문제가 있음(LOB 데이터 타입 지원 안함)
- 테이블 조작에는 Transformation rules을 이용할 수 있으나 기능이 빈약함, SCT(AWS Schema Conversion Tool)를 이용하는 방안도 존재
시작하기 전에 알아야 할 것들
많은 레퍼런스와 기능적으로도 잘 갖추어진 EC2와 RDS가 파인다이닝 🍽️ 이라면, OpenSearch와 DMS는 레퍼런스가 부족할 뿐만 아니라 아직 기능적으로도 제약을 가지고 있어, 사용을 해보면서 길거리 노점 🍢 과 같다는 느낌을 많이 받았습니다. 메뉴판이 부실하게 적혀있거나, 종이컵이 다 떨어졌더라도 자신이 핸들링해야 한다랄까요?
여러분이 들르게 되실 그 길거리 노점이 🍢 숨은 맛집이면 더할 나위 없이 좋겠습니다만, 모두에게나 그럴 수는 없겠죠. 시리즈를 읽으시는 분의 걸음이 헛되지 않도록, 지루해보이더라도 아래의 내용들을 꼭 읽고 진행하시길 강력히 추천드립니다.
DMS가 지원하는 OpenSearch 스칼라 데이터 타입 (DMS -> OpenSearch 마이그레이션)
- Boolean
- Date
- Float
- Int
- String
DMS는 LOB 데이터 타입의 마이그레이션을 지원하지 않습니다(AWS DMS doesn't support migration of LOB data types).
Reference: AWS - Migrating from a relational database table to an OpenSearch Service index
OpenSearch를 DMS의 마이그레션 대상으로 사용할 때의 제한 사항
- 데이터 복제를 위해 CDC와 함께 OpenSearch를 사용할 때는 기본 키(Primary Key)의 속성(Attribute)를 업데이트 할 수 없습니다.
- DMS에서 마이그레이션할 수 없는 항목이 발견되면 AWS CloudWatch 로그에 오류 메세지를 기록합니다.
- DMS는 마스터 사용자 및 암호를 사용하여 세분화된 엑세스 제어(Fine-grained access control)가 활성화된 OpenSearch 클러스터에 대한 연결을 지원하지 않습니다.
- DMS는 OpenSearch 서버리스를 지원하지 않습니다.
- OpenSearch는 기존 인덱스에 데이터를 쓰는 것을 지원하지 않습니다.
- 위의 문장이 CDC의 미지원을 뜻하는 것은 아닙니다. DMS와 OpenSearch의 첫 마이그레이션 과정에서 기존 OpenSearch의 인덱스를 삭제하고 새 인덱스를 생성해 데이터를 추가한 이후로는 CDC가 정상적으로 이루어집니다.
아래의 레퍼런스에는 위의 명시된 항목 이외의 다른 항목들이 추가로 명시되어 있습니다.
Reference: AWS - Limitations when using Amazon OpenSearch Service as a target for AWS Database Migration Service
- 필자의 경험으로는 마이그레이션 할 수 없는 JSON 타입 데이터 필드를 OpenSearch에 저장하려고 했을 때, 해당 필드를 무시하고 나머지 필드만을 저장하는 것으로 보입니다.
- OpenSearch 도메인 생성 시, Public access 대신에 VPC access 네트워크 구성을 해야하며, Fine-grained access control을 체크하지 말아야 합니다 - 시리즈 (2)에서 설명 예정
- Target table preparation mode의 종류(DMS - Create database migration task - Task settings 과정에서 확인 가능)
- Do nothing mode - DMS가 쓰려는 테이블이 OpenSearch에 이미 존재하는 인덱스인 경우 데이터를 쓰지 않습니다. 존재하지 않는 경우에 DMS가 새로운 인덱스를 생성하고 데이터를 쓰게 됩니다.
- Drop tables on target mode - DMS가 이미 존재하는 인덱스를 삭제하고 새로운 인덱스를 생성하고 데이터를 쓰게 됩니다.
MySQL 데이터베이스를 마이그레이션 소스로 사용할 때의 제한 사항
Reference: AWS - Limitations on using a MySQL database as a source for AWS DMS
다음 글: DMS를 사용한 RDS to OpenSearch CDC 복제 진행하기 (1) - RDS 인스턴스 생성과 EC2 연동
