안녕하세요, 백엔드 개발자 제리입니다. 이번 글에서는 저희 B2B 인플루언서 분석 서비스의 데이터 관리 방식과 이를 개선하기 위해 준비 중인 기술 스택 전환 과정에 대해 공유드리려고 합니다. 현재 저희는 Django와 PostgreSQL, ElasticSearch를 조합해 데이터를 관리하고 있으며, 최근 AWS DocumentDB와 같은 NoSQL 솔루션을 도입하는 방안을 검토 중입니다. 그 과정을 통해 얻은 인사이트와 고민을 공유하려고 합니다.
현재 구조: Django, PostgreSQL, ElasticSearch
저희 서비스는 다양한 인플루언서 데이터를 수집하고 이를 고객사에게 제공합니다. 이를 위해 백엔드에서는 Django를 기반으로, 주요 데이터는 PostgreSQL에 저장하고, ElasticSearch를 통해 빠르고 검색을 지원하도록 구현되어있습니다.
주요 역할 분담
-
ElasticSearch
엔진팀에서 수집/분석한 데이터를 적재합니다. 이 데이터를 활용해 “인플루언서 찾기”와 같은 기능을 제공하며, 다양한 필터 조건에 따라 실시간으로 데이터를 검색합니다.
-
PostgreSQL
ElasticSearch에서 받아온 데이터를 관계형 데이터베이스(PostgreSQL)에 캐싱합니다. 이를 통해 인플루언서와 관련된 상세 정보와 상태를 관리합니다.
현재 데이터 구조 (Django ORM)
인플루언서 데이터를 EAV(Entity-Attribute-Value) 형태로 정규화하여 관리하고 있습니다.
예를 들어, 인플루언서의 플랫폼별 정보를 다음과 같이 저장합니다:
class InfluencerPlatform(models.Model):
platform_type = models.CharField(...)
platform_pk = models.CharField(...)
class InfluencerPlatformAttribute(models.Model):
platform_type = models.CharField(...)
name = models.CharField(...)
code = models.SlugField(...)
type = models.CharField(...)
class InfluencerPlatformAttributeValue(models.Model):
attribute = models.ForeignKey(InfluencerPlatformAttribute, ...)
influencer_platform = models.ForeignKey(InfluencerPlatform, ...)
value_text = models.TextField(...)
value_integer = models.BigIntegerField(...)
value_boolean = models.BooleanField(...)
value_float = models.FloatField(...)
이를 통해 다양한 데이터를 유연하게 저장하고 관리할 수 있습니다. 인플루언서와 워크스페이스의 연관 데이터 등은 아래와 같이 별도 테이블로 관리합니다:
class WorkspaceInfluencer(models.Model):
influencer_platform = models.ForeignKey(InfluencerPlatform, ...)
workspace = models.ForeignKey(Workspace, ...)
기존 구조의 문제
현재 시스템은 ElasticSearch(ES)와 PostgreSQL을 조합해 인플루언서 데이터를 관리하고 있습니다. 하지만, 특정 상황에서는 데이터 처리와 관리에서 다음과 같은 문제가 발생하고 있습니다.
-
ElasticSearch → DB 싱크의 비효율성
고객이 인플루언서 조회 기능을 실행할 때, 필터 조건에 맞는 데이터를 ElasticSearch에서 가져와 PostgreSQL에 캐싱하는 구조를 사용하고 있습니다.
-
이 과정에서 SQL 쿼리가 복잡해지고, 대규모 데이터 처리 시 성능 저하가 발생합니다.
-
실시간 요청에서 캐싱 데이터를 적재하는 방식은 서비스 응답 속도에 직접적인 영향을 미칩니다.
-
데이터 관리의 어려움
PostgreSQL의 데이터 모델이 정규화되어 있어, 인플루언서 데이터를 필터링하거나 정렬할 때 SQL 쿼리가 복잡하고 유지보수가 어렵습니다.
-
특히 다중 필터(예: 팔로워 수, 참여율, 인증 여부 등)를 포함한 정렬 쿼리는 인플루언서 데이터가 많아질 수록 성능 저하가 발생합니다.
|
기술 스택 |
주요 역할 |
장점 |
단점 |
|---|---|---|---|
|
ElasticSearch |
실시간 데이터 검색 및 필터링 |
빠른 검색 성능, 다양한 필터 조건 지원 |
검색 결과가 PostgreSQL에 캐싱되어 비효율적 |
|
PostgreSQL |
관계형 데이터 저장 및 관리 |
ACID 트랜잭션 지원, 관계형 데이터 처리 |
복잡한 SQL 쿼리, 대규모 데이터 처리 성능 저하 |
|
ElasticSearch + PostgreSQL |
데이터의 검색 및 캐싱 처리 |
데이터 분산 처리, 빠른 조회 기능 |
싱크 문제로 인한 데이터 복잡성 증가, 관리 어려움 |
변경 구조: Django, PostgreSQL,Document DB, OpenSearch
AWS DocumentDB를 활용한 개선 설계
AWS DocumentDB는 JSON 기반의 NoSQL 문서 데이터베이스로, MongoDB와 호환되도록 설계된 AWS의 ‘완전 관리형’ 서비스입니다. MongoDB 3.6, 4.0 및 5.0과 호환됩니다.
AWS DocumentDB를 선택한 이유
-
정규화된 데이터의 복잡성 해소
-
기존 관계형 데이터베이스(PostgreSQL)에서 다루기 어려운 데이터를 간단히 관리할 수 있습니다.
-
JSON 기반의 스키마리스 데이터 모델로 복잡한 EAV(Entity-Attribute-Value) 패턴을 대체하고 심플하게 데이터를 관리/조회할 수 있습니다.
-
MongoDB와 호환되면서 안정적
-
MongoDB 오픈소스와 호환되면서도 AWS에서 관리형으로 제공되어 유지보수 부담을 줄입니다.
-
백엔드에서는 Django, Python 기반으로 코드가 작성되어 있어서, PyMongo를 활용하여 자연스러운 통합이 가능합니다.
-
고성능
-
대규모 읽기 작업에 최적화된 구조로 설계되어, 많은 동시 요청이 들어와도 안정적으로 처리 가능합니다.
-
데이터를 실시간으로 업데이트하고, 복잡한 필터링/정렬 조건도 빠르게 처리됩니다.
-
AWS와의 통합
-
기존 인프라가 AWS 기반이기 때문에 VPC, IAM, CloudWatch, Lambda 등과의 통합으로 운영 효율성을 극대화할 수 있습니다.
OpenSearch와 DocumentDB 통합 및 인플루언서 관리 데이터 조회 방안
현재 ElasticSearch에서 OpenSearch로 전환을 계획하고 있으며, AWS DocumentDB와 OpenSearch 간 Zero-ETL 통합을 활용해 데이터 관리와 검색 효율성을 높일 수 있습니다. 이를 기반으로 기존 DB(PostgreSQL)와 DocumentDB를 병행 사용하며 인플루언서 관리 데이터를 효과적으로 조회하는 방법을 계획하고 있습니다.
OpenSearch와 DocumentDB 통합 활용
AWS DocumentDB와 OpenSearch는 Zero-ETL 통합 기능을 제공해, DocumentDB에 저장된 데이터를 OpenSearch에 자동으로 동기화할 수 있습니다. 이 통합을 활용하면 데이터 복잡성을 줄이고 실시간으로 검색 가능한 데이터베이스 환경을 구축할 수 있습니다.
Zero-ETL 통합의 이점
-
자동 동기화
-
DocumentDB에 데이터가 저장되거나 업데이트되면, OpenSearch에 자동으로 반영됩니다.
-
별도의 데이터 파이프라인 구축이나 스케줄링 작업 없이 실시간 데이터 동기화 가능합니다.
-
복잡한 검색 쿼리 처리
-
OpenSearch는 고급 검색 및 분석(예: 다중 필터, 동적 정렬)에 최적화되어 있습니다.
-
예: 인플루언서 리스트에서 특정 태그, 팔로워 수, 참여율 등의 복합 조건으로 필터링됩니다.
-
확장성과 안정성
-
DocumentDB는 데이터를 관리하고 OpenSearch는 검색과 분석에 집중하여, 각 서비스의 장점을 최대한 활용할 수 있습니다.
OpenSearch와 DocumentDB를 ZeroETL로 통합하며 고려한 잠재적 이슈
OpenSearch와 AWS DocumentDB를 ZeroETL로 통합하면서 가장 큰 고려 사항은 데이터 동기화 타이밍으로 인한 정합성 문제였습니다. ZeroETL 통합은 DocumentDB에서 MongoDB의 Change Streams를 활용해 데이터 변경 사항을 실시간으로 OpenSearch에 전달하는 방식으로 작동합니다.
이 방식은 실시간에 가까운 동기화를 제공하지만, 수 밀리초에서 수 초 정도의 지연시간이 발생할 수 있습니다. 이러한 지연은 대부분의 서비스에서 큰 문제가 되지 않지만, 대량의 데이터가 한 번에 삽입되는 경우에는 일부 데이터가 지연되거나 동기화가 제대로 이루어지지 않을 가능성도 있습니다.
-
배치 작업과 수동 업데이트 기능
대량 데이터 삽입 시 발생할 수 있는 부하를 줄이기 위해, 동기화를 배치 작업으로 처리하거나 특정 이벤트에 따라 수동으로 업데이트를 트리거할 수 있는 기능을 추가로 구현할 예정입니다.
-
정기적인 정합성 검증 프로세스
동기화 과정에서 누락되거나 실패한 이벤트로 인해 데이터 불일치가 발생할 가능성에 대비해, 정기적으로 DocumentDB와 OpenSearch 간의 데이터 정합성을 확인하는 백그라운드 프로세스를 설계할 계획입니다. 이를 통해 문제가 발생한 데이터를 다시 처리하고 동기화 상태를 유지할 수 있습니다.
|
기술 스택 |
주요 역할 |
장점 |
단점 |
|---|---|---|---|
|
PostgreSQL |
인플루언서의 influencer_id만 저장, 관련 데이터는 DocumentDB에서 조회 |
간단한 인덱싱 및 키 관리, 데이터 중복 최소화 |
데이터 조회 시 DocumentDB에 의존, 실시간 성능 요구 |
|
AWS DocumentDB |
NoSQL 데이터 저장 및 관리, JSON 기반의 스키마리스 데이터 관리 |
데이터 모델 복잡성 해소, MongoDB와 호환 |
NoSQL 구조에 적합한 데이터만 효율적 관리 가능 |
|
PostgreSQL + AWS DocumentDB 통합 |
인플루언서 관련 정보는 PostgreSQL에서 ID만 저장하고, 실제 데이터는 DocumentDB에서 쿼리하여 가져옴 |
복잡한 데이터 모델을 간단하게 처리, 데이터 중복 최소화, 성능 최적화 |
추가적인 데이터 조회 로직이 필요하다. |
|
OpenSearch |
고급 검색 및 분석, 다중 필터, 동적 정렬 처리 |
실시간 검색, 복합 조건 필터링 지원, 고급 검색 |
초기 설정 및 관리 필요 |
|
AWS DocumentDB + OpenSearch |
실시간 데이터 동기화 및 검색 최적화 |
Zero-ETL 통합으로 데이터 동기화 자동화, 확장성 및 안정성 제공 |
동기화 지연 및 대량 데이터 처리 시 부하 가능성 |
마무리
이번 기술 스택 전환은 기존의 Django, PostgreSQL, ElasticSearch 조합에서 발생하던 데이터 처리 및 관리의 비효율성을 해결하고, 더 나은 확장성과 성능을 제공하기 위한 방향으로 진행되고 있습니다.
AWS DocumentDB와 OpenSearch를 도입하여 데이터 관리와 검색 환경을 개선하고, Zero-ETL 통합을 통해 동기화 복잡성을 줄이는 것이 핵심 목표입니다. 이로 인해 인플루언서 데이터를 다룰 때 유연성과 성능을 모두 확보할 수 있을 것으로 기대됩니다.
이 과정에서 고려해야 할 몇 가지 중요한 요소들, 특히 동기화 타이밍 이슈와 대량 데이터 처리와 관련된 잠재적 문제를 해결하기 위한 방안도 마련하고 있습니다. 이러한 변화는 현재의 데이터 구조와 운영 방식을 넘어, 더 나은 사용자 경험을 제공할 기반이 될 것입니다.
앞으로도 시스템의 효율성을 높이고, 새로운 기술 도입의 효과를 극대화하기 위해 꾸준히 개선을 이어가겠습니다. 이번 글을 통해 얻은 인사이트가 유사한 문제를 겪는 분들에게 유용한 참고가 되기를 바랍니다. 감사합니다!
