AWS Unicorn Day 세션 정리 - Amazon Redshift를 활용한 데이터 파이프라인 구축

AWS Unicorn Day를 다녀와서 인상깊게 보았던 세션 중 하나를 팀원들에게 공유하기 위해 정리해보았습니다. 데이터 분석 요구사항이 급증하는 상황에서 어떻게 확장 가능한 분석 인프라를 구축했는지에 대한 실제 사례입니다.

1. 배경: 데이터 분석 요구 증가

1.1 비즈니스 환경 변화

비즈니스 성장과 함께 데이터 기반 의사결정의 필요성이 급격히 증가했습니다. 기존의 직관 중심 의사결정에서 데이터 기반 전환이 필수가 되었고, 다음과 같은 분석 수요가 폭증했습니다:

• KPI 모니터링 및 성과 측정
• 사용자 행동 분석 및 패턴 파악
• 비즈니스 트렌드 분석 및 예측

왜 문제가 되었는가? 데이터 수요 증가에 비해 기존 인프라는 확장성과 성능 면에서 한계가 명확했고, 이로 인해 의사결정 속도가 저하되었습니다.

2. 기존 데이터 처리의 한계점

2.1 개발자 의존도 문제

기존 시스템의 가장 큰 문제는 모든 데이터 요청이 개발자를 거쳐야 한다는 점이었습니다:

• "데이터 좀 뽑아주세요"라는 비정형/일회성 요청 반복
• 수작업 + 엑셀 기반 협업으로 자동화 부족
• 개발자 리소스 지속적 소모

이 방식의 문제점: 데이터 분석의 속도와 자율성이 현저히 떨어지며, 개발팀의 핵심 업무에 집중할 수 없게 됩니다.

3. 1차 시도: Reader DB + Redash

3.1 초기 접근법

간단한 시각화와 쿼리 요구사항을 해결하기 위해 Read Replica와 Redash를 도입했습니다.

3.2 한계점 발견

• 성능 저하: 복잡한 쿼리 실행 시 운영 DB Read Replica에 부하 발생
• 확장성 부족: 분석 요구사항이 복잡해질수록 성능 문제 심화
• 리소스 소모 지속: 여전히 개발자 개입이 필요한 상황 발생

왜 이 방법이 한계였는가? OLTP 최적화된 구조에서 OLAP 성격의 분석 쿼리를 실행하는 것은 근본적으로 비효율적이었습니다.

4. 2차 시도: 분석용 독립 DB + FDW

4.1 FDW(Foreign Data Wrapper) 도입

PostgreSQL의 FDW 기능을 활용하여 외부 데이터베이스를 로컬 데이터베이스처럼 접근할 수 있게 구성했습니다.

FDW의 장점: 서로 다른 데이터베이스 간의 크로스 쿼리가 가능해져 데이터 통합 분석이 용이해졌습니다.

4.2 새로운 문제점들

• pg_dump + restore 방식의 위험성: 데이터베이스 전체 덤프 과정에서 실패 위험과 운영 영향 발생
• 실시간성 부족: 스냅샷 기반 방식으로 실시간 분석 수요를 충족하지 못함
• 성능 한계 지속: 여전히 대용량 데이터 처리에는 한계

근본적 문제: OLTP 구조 기반의 접근법으로는 분석 워크로드를 효율적으로 처리할 수 없다는 것을 확인했습니다.

5. 최종 해결책: Amazon Redshift 도입

5.1 Redshift 선택 이유

여러 클라우드 데이터 웨어하우스 중 Amazon Redshift를 선택한 이유는 다음과 같습니다:

• 빠른 연동: 기존 AWS 인프라와의 seamless한 통합
• 비용 효율성: BigQuery, Snowflake 대비 우수한 가격 경쟁력
• 완전관리형: 인프라 운영 부담을 AWS가 담당

왜 이 선택이 효과적인가? OLAP 전용 데이터 웨어하우스로 대용량 데이터 분석에 최적화되어 있으며, 병렬 처리 기반으로 성능을 보장합니다.

5.2 Amazon Redshift 특징

• 완전관리형 OLAP 데이터 웨어하우스: 복잡한 쿼리와 다차원 분석에 최적화
• PostgreSQL 기반 SQL 지원: 기존 SQL 스킬을 그대로 활용 가능
• 병렬 처리: 대용량 데이터 분석을 위한 분산 아키텍처
• 유연한 요금제: 서버리스 또는 클러스터 기반 선택 가능

6. 아키텍처 구성 및 워크플로우

6.1 전체 파이프라인 구조

자동화된 데이터 파이프라인을 다음과 같이 구성했습니다:

1단계: 이벤트 트리거 (Amazon EventBridge)

• 정해진 주기로 이벤트 자동 발생
• AWS Step Functions 워크플로우를 트리거

효과: 수동 개입 없이 정기적인 데이터 업데이트가 보장됩니다.

2단계: 스냅샷 생성 및 업로드 (Lambda)

• RDS에서 최신 snapshot 확인
• Snapshot을 .parquet 포맷으로 변환
• Amazon S3에 업로드

왜 Parquet 포맷인가? 컬럼형 저장 방식으로 압축률이 높고 분석 쿼리 성능이 우수합니다.

3단계: 데이터 처리 (AWS Batch + ECS)

• Lambda가 AWS Batch에 작업 제출
• ECS Cluster에서 Docker 컨테이너 실행:
• RDS 스키마 추출
• S3의 parquet 파일을 Redshift로 COPY
• 데이터 정합성 검증

Batch 사용 이유: Lambda의 15분 시간 제한을 우회하고, 대용량 데이터 처리에 최적화된 환경을 제공합니다.

4단계: Amazon Redshift 적재

• COPY 명령어로 S3 데이터를 Redshift에 적재
• 예약어 처리, 타입 매핑, 오류 로깅 자동화
• 데이터 무결성 검증 포함

5단계: 시각화 (Redash)

• 최종 분석 테이블을 Redash와 연결
• 비개발자도 셀프 서비스 분석 가능

6.2 구현 시 고려사항

자동화된 파이프라인 구성:

• Python 스크립트 포함 Docker 이미지 제작
• AWS Batch가 ECR 이미지 기반으로 컨테이너 실행

데이터 적재 시 해결해야 할 이슈들:

• Redshift 비호환 타입 처리
• 컬럼 최대 길이 제약 해결
• PostgreSQL 예약어와 Redshift 예약어 차이 처리
• 스키마 유추 과정에서 발생하는 타입 불일치 오류

7. 도입 효과

7.1 성능 개선

7.2 운영 효율성

• 개발자 리소스: 분석 요청마다 개발 개입 → Redash 셀프 서비스로 전환
• 비용 최적화: 사용량 기반 요금제로 효율적 비용 관리
• 확장성: 실시간 분석 확장 가능성 확보

왜 이런 개선이 가능했는가? OLAP 전용 아키텍처와 완전 자동화된 파이프라인으로 인해 성능과 운영 효율성을 동시에 확보할 수 있었습니다.

8. 향후 개선 계획

8.1 증분 적재 처리

현재 방식의 한계: 전체 삭제 후 재적재 방식으로 비효율적

개선 방안: 타임스탬프 기반 증분 처리로 전환하여 처리 시간 단축 및 리소스 절약

8.2 Aurora Zero-ETL 검토

도입 목적: 실시간 데이터 분석 수요에 대응

효과: ETL 과정 없이 Aurora에서 Redshift로 자동 연동하여 실시간성 확보

8.3 Amazon QuickSight 도입 검토

목표: 개발자뿐만 아니라 비즈니스 사용자를 위한 셀프 BI 환경 제공

기대 효과: 데이터 민주화를 통한 조직 전체의 데이터 활용도 향상

9. 핵심 학습 사항

9.1 아키텍처 선택의 중요성

OLTP와 OLAP 워크로드의 차이를 명확히 이해하고, 목적에 맞는 아키텍처를 선택하는 것이 성공의 핵심이었습니다.

9.2 자동화의 가치

수동 프로세스를 완전 자동화함으로써 운영 부담을 제거하고 데이터 신뢰성을 확보할 수 있었습니다.

9.3 점진적 개선 접근법

한 번에 완벽한 솔루션을 구축하기보다는 문제점을 파악하고 점진적으로 개선해나가는 접근이 효과적이었습니다.

참고자료

• AWS Unicorn Day 2025 세션 영상

요약

• 비즈니스 성장으로 인한 데이터 분석 수요 급증에 대응하기 위해 기존 OLTP 기반 분석에서 OLAP 전용 데이터 웨어하우스로 전환했습니다.
• Amazon Redshift와 완전 자동화된 파이프라인 구축을 통해 쿼리 성능을 40배 개선(4분→6초)하고 개발자 의존도를 제거했습니다.
• EventBridge-Lambda-Batch-ECS 기반의 서버리스 아키텍처로 운영 부담 없는 안정적인 데이터 파이프라인을 확보했습니다.
• Aurora Zero-ETL과 QuickSight 도입을 통해 실시간 분석과 셀프 BI 환경으로 확장할 계획입니다.