분산 키(Dist Key)를 이용한 Redshift 성능 최적화
OLTP(Online Transaction Processing)와 OLAP(Online Analytical Processing)은 데이터베이스 관리의 두 주요 방식으로, 각기 다른 유형의 데이터 작업을 처리하기 위해 설계되고 최적화되어 있습니다. OLTP 시스템은 주로 행 기반의 데이터베이스를 사용하여 일상적인 트랜잭션 처리를 신속하게 수행하도록 설계되어 있는 반면, OLAP 시스템은 복잡한 분석과 데이터 집계를 위해 열 기반 데이터베이스 구조를 활용하여 특정 열 집합에 대한 효율적인 처리를 가능하게 합니다. Amazon Redshift와 같은 OLAP 시스템은 데이터를 열로 저장하여, 최적의 메모리 사용과 디스크 입출력을 위해 다양한 데이터 압축 인코딩을 사용하여 대용량 데이터셋에 대한 분석 처리 과정을 효율적으로 만듭니다. 이러한 구조적 차이는 OLTP가 요구되는 전체 행을 읽는 트랜잭션 처리에는 효율적이지만, OLAP에서 요구되는 분석 작업에서는 비효율적이라는 점을 의미합니다.
저희 회사는 운영 데이터베이스로 MongoDB를, 분석용 데이터베이스로 AWS Redshift를 활용하고 있습니다. MongoDB는 고객 정보와 같은 주요 트랜잭션 데이터를 처리하는데 사용하고 있고, AWS Redshift에 적재된 데이터는 데이터 분석, 주요 지표 대시보드 구성, CRM 발송 등 회사의 핵심적인 분석 업무에 사용됩니다.
기존에는 외부 SaaS 솔루션을 통해 두 데이터베이스 간의 데이터 이전 작업이 진행되었으나, 오류 발생 시 문제를 제보하고 해결을 기다리는 과정에서 전사적으로 큰 영향을 미치는 상황이 종종 발생했습니다. 이러한 상황을 개선하고 데이터 처리 과정에 더 많은 유연성과 통제력을 갖기 위해, 저희는 회사 데이터에 맞춤화된 내부 ETL 파이프라인 구축을 결정했습니다.
데이터 이전 과정에서 NoSQL 데이터베이스인 MongoDB에서 SQL 기반의 데이터베이스인 Redshift로의 전환은 이기종 시스템 간의 데이터 마이그레이션에 해당합니다. 이 과정의 주요 어려움은 MongoDB의 유동적인 스키마를 Redshift의 고정된 테이블 스키마로 변환하는 것입니다. MongoDB에서는 데이터 구조가 도큐먼트 단위로 유연하게 변경될 수 있지만, PostgreSQL 기반의 SQL 데이터베이스인 Redshift는 고정된 테이블 구조를 요구하기 때문에, 이 두 시스템 간의 구조적 차이는 데이터 마이그레이션 과정에서 중대한 도전 과제로 다가옵니다.
또한, 500개가 넘는 테이블을 처리해야 하는 환경에서는 ETL(Extract, Transform, Load) 프로세스의 범용성과 코드의 확장성도 중요합니다. 이를 위해서는 각 테이블의 스키마를 유연하게 처리하고 데이터의 일관성과 정확성을 보장할 수 있는 ETL 시스템과, 효율적으로 데이터를 변환하고 로드할 수 있는 파이프라인이 필요합니다.
저희는 MongoDB에서 발생하는 데이터 변화를 실시간으로 추적하기 위해 Mongo Change Streams를 활용하여 데이터의 변경사항을 읽어옵니다. 여기서 발생하는 대량의 데이터는 Amazon Kinesis Data Streams를 통해 수집됩니다. AWS Kinesis는 모든 규모의 데이터 레코드를 실시간으로 수집하고 처리할 수 있는 확장 가능하고 내구력있는 서버리스 데이터 스트리밍 서비스로, 저희의 요구 사항에 적합합니다.
이러한 데이터 흐름은 AWS MSK와 Debezium Mongo connector를 사용하여 구현할 수도 있습니다. 그러나 저희는 인프라의 간소화, 관리의 용이성 및 스케일링의 편리함을 고려하여 Kinesis를 선택했습니다. 저희 데이터 엔지니어가 단독으로 근무하며 Kafka에 대한 경험이 없는 상황에서, 기술적 복잡성을 최소화하고 운영 효율성을 높일 수 있는 Kinesis가 더 적합한 데이터 스트리밍 서비스로 판단되었습니다.
Redshift의 스트리밍 수집 기능을 사용해 손쉽게 Kinesis에 스트리밍되는 데이터를 구체화된 뷰로 변환할 수 있습니다. 그러나 NoSQL 데이터의 비정형 스키마를 정형화하고 필요한 데이터 변환 작업을 수행하기 위해서는 데이트 스트리밍 서비스와 데이터 웨어하우스 사이에 중간 단계의 처리 레이어를 두어야 했습니다. 이 중간 레이어에서는 Kinesis로부터 수집된 데이터를 임시로 Amazon S3에 저장하고, 이후 필요한 데이터 변환과 정리를 AWS Glue를 통해 진행합니다. Redshift의 S3 copy 명령을 직접 사용하지 않는 이유와도 동일합니다.