데이터 엔지니어링

데이터 엔지니어링 아키텍처 설계와 선택

 

아키텍처 vs 도구

• 아키텍처(전략): 어떤 기술(하이브리드/클라우드/온프레미스)을, 왜(비즈니스 요구, 보안, 성능, 비용), 언제(도입 타이밍, 확장성) 구축해야 할지를 결정한다.
• 도구(전술): 아키텍처 내에서 어떻게 구축할지를 정한다.

 

하이브리드 클라우드를 고려할 시점

• 보안, 규제 요구: 일부 데이터나 애플리케이션이 법적, 보안상 온프레미스에서 유지되어야 할 때
• 기존 인프라 활용: 조직이 이미 운영 중인 온프레미스 자원의 비용 절감이나 최대 활용이 필요한 경우
• 클라우드 특화 기능 활용: 빅데이터 분석, AI 모델 학습, 서버리스 이벤트 처리 등 클라우드 서비스가 더 효율적인 경우
• 성능 요구 분리: 트랜잭션 민감 서비스는 온프레미스, 대용량 배치/분석은 클라우드에서 수행하고자 할 때

egress 비용 최적화 방법

• 이벤트 데이터만 클라우드로 전송: 애플리케이션은 온프레미스에 두고, 대량의 raw 데이터를 클라우드로 보내지 않고, 이벤트나 변환된 데이터만 전송하여 총 트래픽량을 최소화한다.
• 역 ETL: 분석 결과나 인사이트만 다시 온프레미스로 푸시할 때, 대용량 raw 데이터를 온프레미스를 벗어나지 않게 제어한다.
• 필요 데이터만 전송: 필터링, 집계, 요약 등 전처리된 데이터만 클라우드로 보내서 전송량을 줄인다.
• 스케줄링/배치 사용: 데이터 전송을 실시간이 아닌 스케줄링 또는 배치로 이뤄지도록 한다.

하이브리드 클라우드는 온프레미스와 클라우드의 장점을 병행하면서, egress 비용 최적화를 위해 데이터 이동을 최소화하는 전략적 선택이 된다. 이벤트 데이터 위주로 클라우드에 보내면 비용을 줄일 수 있고, 역 ETL로 분석 결과를 온프레미스로 가져와 보안과 규정 요구 사항을 충족할 수 있다.

 

멀티클라우드의 장점

• 공급업체 종속 최소화: 특정 클라우드 벤더에 의존하지 않음 -> 다양한 솔루션을 필요에 따라 선택 가능
• 유연한 워크로드 분배: 각 클라우드의 장점을 활용해 다양한 서비스별로 최적화 가능
• 장애 복구 및 복원력: 한 클라우드 서비스 장애 발생 시 다른 클라우드로 자동 전환이 가능 -> 안정성 향상

멀티클라우드의 단점

• 데이터 egress 비용: 서로 다른 클라우드로 데이터를 보낼 때 발생하는 비용 증가 문제
• 네트워크 병목 및 지연: 클라우드 간 네트워크 전송에서 병목 현상이나 지연 위험
• 복잡성 및 관리 부담

 

모놀리식 vs 모듈식

• 모놀리식: 한곳에서 전체 기능을 집중하는 단순함, 컨텍스트 스위칭 적음. 하지만 시스템 규모가 커지면 변경, 배포가 오래 걸리고 장애 관리가 어렵다. 수평 확장 불가
  • + 멀티 테넌시 문제: 하나의 시스템에 여러 고객(테넌트)을 동시에 수용하면서 데이터 격리와 운영 안정성에 어려움이 생기는 것
• 모듈식/마이크로서비스(MSA): 서비스별 분리로 도메인 집중 개발이 가능하고, 각자 독립적으로 배포·확장할 수 있다. 그러나 서비스 간 통합·API 통신·운영환경 복잡성이 커진다.

 

+ 테넌트?

• 소프트웨어나 데이터베이스 환경에서 독립적인 사용자, 조직, 고객
• ex) SaaS 서비스에서 여러 회사가 같은 애플리케이션을 사용하더라도, 각 회사는 독립적인 데이터와 환경을 가지는데 이 회사들이 바로 각각의 테넌트

 

서버리스

 

서버리스: 개발자가 서버의 운영과 관리를 신경 쓰지 않아도 되고, AWS Lambda, GCP BigQuery 같은 서비스가 대표적이며, 이벤트 기반으로 실행되어 실제 사용한 만큼 비용이 발생한다.

 

서버리스가 적합한 상황

• 트래픽이나 작업 부하가 일정하지 않고 간헐적인 이벤트 기반 작업에 적합하다.
• 빠른 개발과 배포가 필요하고, 서버 관리 부담을 줄이고 싶을 때 이상적이다.
• 스타트업이나 프로토타입, 마이크로서비스 등 작은 단위로 빠르게 확장 가능한 환경에 맞는다.
• 자동 확장과 유휴 리소스 비용 절감이 중요한 경우 사용된다.

 

서버리스 단점 및 주의사항

• 이벤트 기반으로 비용이 발생하므로 사용량이 많아지면 비용이 급증할 수 있다.
• 콜드 스타트 문제로 인해 실행 초기 지연 시간이 발생할 수 있다.
• 실행 시간이나 리소스(메모리, CPU) 제한이 있어 긴 작업에는 부적합하다.

 

컨테이너 특징 및 서버리스와 관계

• 컨테이너는 단일 호스트 OS 커널을 공유하면서 오버헤드를 줄이고, 의존성 관리와 이식성을 제공한다.
• 서버리스 환경은 보통 컨테이너 위에서 실행된다.
• AWS에서 컨테이너 관리를 위한 서비스로는 ECS, EKS, Fargate가 있다.

 

• ECS: AWS가 직접 제공하는 컨테이너 오케스트레이션 서비스로, 클러스터 관리를 간소화하여 진입 장벽이 낮고 운영이 비교적 쉽다. 특히 EC2 기반 혹은 Fargate 서버리스 모드에서 실행할 수 있다.다만, 쿠버네티스에 비해 유연성이 부족하고 멀티 클라우드 환경에는 부적합하다.
• EKS: 완전 관리형 쿠버네티스 서비스로, 오픈소스 쿠버네티스 환경을 AWS에서 제공한다. 이 때문에 멀티 클라우드나 하이브리드 클라우드에 적합하고, 복잡한 마이크로서비스 아키텍처에 높은 유연성과 확장성을 자랑한다. 하지만 클러스터 및 노드 관리를 직접 해야 하고, 운영 복잡성과 관리 부담이 크며 관리 비용도 발생한다.
• Fargate는 서버리스 컨테이너 서비스로, 서버나 노드를 직접 관리할 필요 없이 컨테이너만 배포하면 된다. 자동 확장, 리소스 프로비저닝의 자동화로 운영 부담이 최소화되어 진입이 쉽지만, 비용은 리소스 사용량에 따라 증가할 수 있고, 대용량 메모리 작업에는 한계가 있으며, 네트워크 초기화 지연이나 디버깅 제약도 있다.

 

서버 vs 서버리스 사용 판단 기준

• 서버는 일정 비용이 발생하지만, 장애 관리·수평 확장·IaC 자동화가 가능하다.
• 서버리스는 사용한 만큼 비용을 내고, 단순하고 개별 작업, 이벤트 기반 처리에 적합하다.
• 일반 권장 패턴은 서버리스를 우선 도입하고, 이후 필요에 따라 서버로 이전하는 방식이다.
• 서버는 고성능·지속적 서비스를 위해, 서버리스는 간헐적·빠른 확장성 작업에 적합하다.

 

Airflow

 

Apache Airflow는 복잡한 데이터 파이프라인 자동화와 관리에 최적화된 도구이다.

Airflow는 언제 쓰는것이 좋고, 어떨때는 적합하지 않는가?

 

Airflow가 적합한 상황

• 복잡한 ETL/ELT 데이터 파이프라인을 구성하고 싶을 때
  • 왜 좋은가? Airflow는 DAG를 사용해 복잡한 작업 간 의존성, 순서를 명확히 표현하고 관리할 수 있다. 
• 다양한 데이터 소스 또는 시스템 간에 데이터 이동과 처리를 자동화 및 모니터링해야 할 때
  • 왜 좋은가? Airflow는 다수의 내장 오퍼레이터와 훅으로 여러 DB, 클라우드 서비스, API 등 다양한 시스템과 쉽게 통합되고, UI로 워크플로우 상태, 로그, 실행 이력을 실시간 모니터링할 수 있다.
• 머신러닝 모델 학습/배포 등 복수 작업이 순차적으로 또는 병렬로 연속 실행되어야 할 때
  • 왜 좋은가? Airflow는 병렬 실행과 작업 분기, 조건 수행 등 복잡한 작업 흐름을 지원한다.
• 워크플로우의 재시도, 알림, 실패 시 백업 처리 등 오류 관리 기능이 중요한 경우
  • 왜 좋은가? Airflow는 오류 발생 시 작업 재시도, 실패 알림, 백필(과거 데이터 재처리) 기능이 있다.

 

부적합한 상황

• 초단위로 빈번한 작업 실행이 필요하거나, 수많은 동적 워크플로를 즉각 처리해야 하는 대규모 트랜잭션성 업무
  • 왜 부적합? Airflow는 배치 위주의 스케줄링 도구로 초단위 빈번 실행, 실시간 이벤트 처리, 초고속 대량 동시 워크플로 처리에는 적합하지 않다. 실행 지연(콜드 스타트)과 큰 부하가 운영에 문제를 일으킬 수 있다.
• 워크플로우가 극도로 간단하거나 단일 작업 실행에 그치는 경우
  • 왜 부적합? Airflow가 제공하는 복잡한 DAG 구성과 관리 시스템이 오히려 과도한 비용과 복잡성을 유발하며, 단순 작업은 cron, 스크립트 등 더 경량화된 도구가 적절하다.
• 실시간 데이터 처리 및 이벤트 중심 아키텍처 (Airflow는 배치 지향적)
  • 왜 부적합? Airflow는 기본적으로 예약 기반 배치 처리 도구이므로, 실시간 트리거나 스트리밍 데이터 처리에는 Apache Kafka와 같은 이벤트·스트림 처리 플랫폼이 더 적합하다.

 

---

 

데이터 수집

 

데이터 엔지니어는 원천 시스템에서 데이터를 수집한 뒤, 분석이나 비즈니스 활용에 적합하도록 정제 및 가공하는 역할을 수행한다.

 

CDC(Change Data Capture): 데이터 변경을 실시간으로 추적하기

 

데이터베이스에서 발생하는 각 변경 이벤트(INSERT, UPDATE, DELETE)를 추출하는 방법

• RDBMS에서는 스트림 생성 위해 처리될 수 있는 이벤트 로그 생성해 저장
• NoSQL의 경우 로그, 이벤트 스트림 목표로하는 스토리지 위치로 전송

 

RDBMS와 대비해서 NoSQL의 장점 

• 스키마 유연성
  • NoSQL은 고정된 스키마 없이 구조 변경이나 다양한 데이터 타입이 자유로움
  • 비정형·반정형 데이터 처리에 유리
• 수평 확장성과 분산 처리
  • 설계부터 노드 추가를 통한 수평 확장과 자동 데이터 분산(샤딩, 복제)에 최적화
  • 대규모 트래픽이나 데이터 증가에도 손쉽게 시스템 확장이 가능
• 고가용성 및 실시간 처리
  • 분산 구조를 기본으로 설계되어 여러 노드에 데이터를 복제하여 저장 -> 고가용성 유지
  • 단일 장애점이 없음 ->  실시간 데이터 스트림·이벤트 기반 처리에 강점
  • 다중 지역 또는 분산 환경 -> 데이터 접근 지연(latency)을 줄이고, 특정 지역의 장애 발생 시에도 다른 지역의 데이터로 서비스를 계속 유지할 수 있어 내결함성과 가용성이 개선됨.
    • 네트워크 장애나 분할이 발생해도 시스템 전체가 멈추지 않도록 보장하는 분산 허용성(Partition Tolerance)을 갖추고 있기 때문
• 개발 민첩성 및 비용 효율
  • 데이터 모델 변경, 신규 기능 추가 시 복잡한 스키마 수정 없이 빠르게 개발 작업 진행 가능

 

 

그렇다면 로그에 대해서 자세히 알아보자

로그: 시스템에서 발생하는 이벤트 정보

 

로그의 3요소

• 누구(Who): 이벤트를 발생시킨 사용자/시스템
• 무엇(What): 발생한 이벤트와 메타데이터
• 언제(When): 타임스탬프

 

	장점	단점
바이너리 인코딩	공간 효율적, 빠른 I/O	읽기 어려움
JSON	기계가 읽기 쉬움, 이식성	바이너리보다 크고 느림
비정형	유연함	규격 존재 안함, 일관성 부족

 

JSON이 느린 이유

왜 JSON이 바이너리보다 비효율적인가?

• 텍스트 기반 포맷의 크기 부피: JSON은 구조를 표현하기 위해 키 이름과 구문 요소(중괄호, 콜론, 따옴표 등)를 모두 텍스트로 포함하므로, 동일한 데이터를 저장할 때 바이너리보다 데이터 크기가 훨씬 크다.
• 파싱 비용 증가: JSON은 텍스트 파싱을 위해 반복적인 문자열 처리와 변환 작업이 필요해 CPU 부하가 커지며, 바이너리 포맷은 메모리에서 직접 읽어 들일 수 있어 빠르다.

 

빅데이터의 경우 모든 변경사항을 로그에 기록하면 데이터 양이 지나치게 많아 비효율적이다. 따라서 특정 커밋 이벤트가 발생한 사실만 기록하는 방식을 사용하며, 이때 적용하는 조건은 “로그 레벨”로 관리한다.

• 로그 레벨: 어떤 이벤트를 기록할지 결정 (DEBUG < INFO < WARN < ERROR)
• 로그 해상도: 얼마나 상세히 기록할지

 

Append-Only 패턴(입력 전용 패턴)

 

과거를 지우지 않는 데이터 저장 방식, 테이블의 레코드를 수정(UPDATE)하지 않고, 변경 사항을 새 레코드로 추가(INSERT)하는 방식

 

장점

• 완전한 이력 추적 가능
• 원인 분석, 복원 쉬움
• race condition 감소
  • 업데이트나 삭제 처리 과정에서 발생할 수 있는 동시성 문제를 줄일 수 있다.
  • 단순히 데이터를 추가하기 때문에 복잡한 동시성 제어가 덜 필요하다.

문제점

• 데이터 빈번히 변경 시 테이블이 급격히 커짐
• 최신 레코드 조회 시 오버헤드 발생 (한 ID에 수백 개 레코드 존재 가능)
  • 하나의 ID별로 많은 이력 레코드를 조회해야 하므로, 원하는 현재 상태나 특정 시점 상태를 찾기 위해 복잡한 필터링이나 정렬 작업이 필요하다. 이 과정에서 추가적인 CPU, 메모리 자원이 소모되고 쿼리 시간이 늘어난다.

-> 따라서 많이 변경되는 데이터에서는 입력 전용 이력 패턴이 데이터 용량과 쿼리 성능 측면에서 부담이 될 수 있다. 이럴 때는 아카이빙, 파티셔닝, 인덱싱 최적화 등의 보완책과 설계가 필요하다.

 

 

메시지와 스트림, 메시지 큐의 이해와 비교

 

현대 분산 시스템과 MSA에서 자주 등장하는 개념인 메시지, 메시지 큐, 그리고 이벤트 스트림에 대해 알아보자.

이들은 데이터와 이벤트를 시스템 간에 전달하는 중요한 메커니즘이다.

 

1. 메시지란 무엇인가?

메시지는 시스템 간 전달되는 데이터의 원시 데이터이다. 예를 들어, 주문 정보, 알림, 센서 데이터 등이 모두 메시지가 될 수 있다. 보통 게시자가 메시지를 생성하고, 소비자가 이를 받아 처리한다.

메시지 자체는 데이터이기에 저장이나 전송을 직접 담당하지는 않는다. 메시지는 독립적인 단위이며, 메시지 간의 연속성이나 순서가 보장되지 않는 경우가 많다.

 

2. 메시지 큐란?

메시지 큐는 메시지를 안전하게 저장하고 전달하는 시스템이다. 기본적으로 큐 구조를 띠며, 메시지를 넣은 순서대로 소비자가 하나씩 받아 처리한다. 메시지를 받은 소비자는 처리 완료 후 큐에서 메시지를 삭제한다.

메시지 큐의 주요 특징

• 비동기 전송: 발행자와 소비자가 동시에 동작하지 않아도 메시지 전달이 가능하다.
• 선입선출(FIFO) 처리: 메시지는 들어온 순서대로 처리되어 메시지 순서를 관리할 수 있다.
• 부하 완화 및 버퍼링: 갑작스러운 메시지 증가 시 큐가 메시지를 저장해 소비자가 천천히 처리할 수 있게 한다.
• 확장성: 여러 노드로 분산 복제 가능하며 수평 확장이 가능하다.
  • 분산 환경에서 메시지 큐는 노드 복제를 통해 메시지 내구성을 보장한다.
• 적어도 한 번 전달(at-least-once delivery): 메시지는 최소 한 번 소비자에게 전달된다. 중복 가능성을 대비해 소비자에서 중복 처리 방지가 필요하다.
• AWS SQS 같은 서비스는 표준 큐(FIFO 순서 미보장)와 FIFO 큐(순서 보장)를 제공

 

왜 스택(Stack)이 아니라 큐(Queue)를 사용하는가?

스택은 LIFO구조라 가장 마지막에 들어온 메시지가 먼저 처리된다. 이 경우 메시지 처리 순서가 뒤바뀌어 데이터의 일관성을 해칠 수 있다.

 

3. 스트림이란?

스트림은 이벤트가 발생할 때마다 데이터를 시간 순서대로 누적해서 저장하는 연속적인 데이터 흐름이다. 스트림은 메시지처럼 소멸하지 않고, 나중에 다시 읽거나 재처리할 수 있다.

 

스트림의 핵심 특징

• 지속적 저장과 재생 가능: 이벤트 히스토리가 로그처럼 쌓여 언제든 재생하거나 과거 상태를 재구성할 수 있다.
• 여러 소비자 동시 처리: 각 소비자가 독립적으로 스트림의 이벤트를 읽고 처리할 수 있다.
• 실시간 처리 및 분석에 강점: 지속적인 데이터 흐름을 실시간으로 처리하고 복잡한 이벤트 추적에 유리하다.
• 순서 보장: 이벤트 시간 순서가 보장되어 상태 변화 흐름 추적에 적합하다.

 

스트림이 메시지 단점 보완

• 메시지는 소비 후 삭제되어 과거 데이터 추적이 어렵지만, 스트림은 데이터를 계속 누적해 보존한다.
• 스트림은 이벤트 순서와 논리적 연관성을 유지하면서 여러 소비자가 독립적으로 데이터를 조회할 수 있다.
• 스트림은 실시간 처리뿐 아니라, 과거 이벤트 재생이 가능해 복잡한 이벤트 분석과 상태 추적이 쉽다.

따라서 스트림은 단순한 메시지 전달을 넘어 시간에 따른 이벤트 기록과 지속적 데이터 흐름 관리가 필요한 시스템에서 메시지의 한계를 극복하는 확장된 개념이라 할 수 있다.

 

정리하면

• 메시지는 독립적인 데이터 단위 그 자체이며, 메시지 큐는 이를 저장하고 전달하는 시스템이다.
• 메시지 큐는 주로 작업 처리, 알림, 비동기 호출에 적합하며, 메시지는 소비되면 삭제된다.
• 스트림은 이벤트가 연속적으로 저장되고 재처리 및 실시간 분석이 필요한 경우에 쓰인다.
• 스트림은 메시지의 단점을 보완하며, 특히 시간에 따른 이벤트 이력 관리와 복잡한 상태 추적에 효과적이다.

 

추가로 큐에는 데드레터 큐가 있다.

• 수집할 수 없는 이벤트는 다시 라우팅해서 데드레터 큐라는 별도 큐에 저장한다. 
• 이를 이용하여 에러 발생 이유를 확인하고, 수정 후에 큐를 개선 가능

 

이벤트 스트리밍 플랫폼과 메시지 큐 차이

• 메시지 큐는 특정 메시지를 소비자에게 정확히 전달하는 데 초점을 둔 미들웨어로, 메시지를 소비하면 큐에서 삭제한다.
• 이벤트 스트리밍 플랫폼은 정렬된 레코드 로그 형태로 데이터를 저장하고, 과거 이벤트를 재생할 수 있으며, 여러 소비자가 독립적으로 데이터를 읽을 수 있다.
• 이벤트 스트리밍은 데이터를 잠시 유지하며, 시간 순서대로 이벤트 흐름을 다루므로 복잡한 상태 추적 및 실시간 분석에 적합하다.

 

토픽과 스트림 파티션

• 토픽: 이벤트가 스트리밍되는 데이터 단위. 예를 들어 이상거래탐지 시스템에서 "이상거래" 정보를 담은 토픽이 있다.
• 스트림 파티션: 하나의 토픽 내 데이터가 파티션 키에 따라 여러 파티션으로 나누어짐. 각 파티션은 독립적인 서브 스트림이며, 데이터를 분산 저장한다.
• 파티션을 통해 병렬 처리가 가능하여, 여러 소비자가 동시에 데이터를 빠르게 처리할 수 있다.
• 또한, 파티션 덕분에 확장성이 뛰어나고, 데이터 처리량이 큰 환경에서도 시스템 부하 분산과 안정적 처리가 가능하다.

 

핫스팟 문제와 파티션 키

• 파티션 키가 특정 값에 집중되면 몇몇 파티션에만 메시지가 쏠리면서 데이터 불균형이 발생한다.
• 이런 데이터 불균형이 바로 핫스팟 문제로, 일부 파티션에 과도한 부하가 생겨 처리 지연, 노드 과부하, 자원 낭비 등의 문제를 일으킨다.
• 이를 방지하려면 파티션 키 설계 시 고르게 분산되도록 키를 선택하는 것이 필수적이다.

 

분산형 시스템으로서 이벤트 스트리밍 플랫폼의 장점

• 스트림 데이터가 여러 노드에 분산 저장되어 내결함성(Fault Tolerance)과 복구력(Recovery)이 훌륭하다.
• 노드 장애 발생 시에도 다른 노드에서 스트림 데이터를 복제해 서비스 지속이 가능하다.
• 확장성이 뛰어나 대규모 데이터와 실시간 스트리밍 처리에 적합하다.

 

+ 쿠버네티스에서의 Taint와 Toleration

• Taint: 노드에 설정하는 특성으로, 특정 조건을 만족하지 않는 파드가 해당 노드에 스케줄링되지 않도록 거부하는 역할
• Toleration: 파드에 설정하는 특성으로, 노드의 taint를 허용해 그 노드에 스케줄링될 수 있도록 한다.
• -> 특정 노드를 장애 처리, 리소스 격리 또는 특정 워크로드 전용으로 설정할 수 있다.

 

시간은 한 종류가 아니다. 이벤트 시간, 수집시간, 처리 시간

 

1. 이벤트 시간(Event Time)

• 원천 시스템에서 이벤트가 실제로 발생한 시점
• 예를 들어 사용자가 버튼을 클릭하거나 거래가 발생한 정확한 순간이다.

 

2. 수집 시간(Ingestion Time)

• 이벤트 데이터가 저장소로 수집되어 들어온 시점
• 네트워크 지연, 처리 지연 등으로 인해 이벤트 시간과 수집 시간에는 차이가 있을 수 있다.

 

3. 처리 시간(Processing Time)

• 스트림 처리 엔진이나 데이터 처리 시스템에서 실제 이벤트 데이터를 처리하는 시간
• 시스템 성능과 처리 속도를 평가하거나, 작업 지연 시간을 측정할 때 중요하다.
• 처리 시간은 시스템의 현재 시각과 밀접하며, 이벤트 시간과는 무관할 수 있다.

 

이 세 가지 시간이 중요한 이유

• 데이터 시스템에서는 이벤트 시간이 가장 중요하지만, 네트워크 지연이나 장애로 인해 이벤트가 나중에 수집될 수 있다.
• 이를 고려해 스트림 처리 시스템은 수집 시간과 처리 시간을 함께 관리해야 한다.

 

데이터베이스는 종류가 많다. 이때, 어떤 기준으로 DB를 선택해야 하는가?

 

데이터 유형과 워크로드가 다양해지면서 적합한 데이터베이스를 선택하는 기준이 중요해졌다.

기존 RDBMS에서 NoSQL로의 전환 고민이 많아지는 이유와, NoSQL 데이터베이스의 종류별 특징과 활용 시점을 아래와 같이 정리한다.

 

RDBMS에서 NoSQL로 변경하는 이유

• RDBMS는 정형화된 스키마와 복잡한 조인, ACID 트랜잭션을 지원하지만, 큰 부하, 대용량, 빠른 확장성, 스키마 유연성이 필요한 워크로드에서 한계가 나타난다.
• 이럴 때, NoSQL로 마이그레이션하여 성능, 확장성, 개발 민첩성을 확보하는 전략이 필요하다.

NoSQL로 포기하는 것과 얻는 것

포기하는 것	얻는 것
강한 일관성(ACID)	확장성과 성능 향상
복잡한 JOIN 지원	유연한 스키마
엄격한 스키마 고정	빠른 스키마 변경 가능

 

4가지 NoSQL 종류별로 어떨때 사용을 고민해야 하는지 알아보자.

 

1. Key-Value DB

• 예: Redis
• 특징: 키로 초고속 조회 가능, 인메모리 특성으로 빠른 동시성 처리에 적합
• 단점: 데이터 휘발성, 복구 위해 디스크 저장과 다중 노드 분산 필요
• 사용처: 세션 저장, 캐시, 실시간 데이터 처리 등

2. 도큐먼트 저장소

• 예: MongoDB
• 특징: JSON 형태 문서 저장, 스키마 유연, 컬렉션 단위 관리
• 단점: 조인 미지원 -> 정규화 어려움으로 데이터 중복 및 비일관성 위험, ACID 제한
• 작업 시 풀스캔이 필요할 수 있으며, CDC(변경 데이터 캡처) 전략으로 이벤트 스트림 활용해 데이터 신뢰성 보완
  • 인덱스가 모든 쿼리 조건에 적용되지 않거나, 배열/중첩 구조 등 복잡한 도큐먼트 필드 조건이 많으면 인덱스 사용이 어려워진다.
  • 인덱스가 없는 필드나 복잡한 쿼리는 전체 컬렉션의 모든 도큐먼트를 훑어야 하므로 full scan이 발생한다.
• 활용처: 콘텐츠 관리, 로그 저장, 비정형 데이터 관리
• CDC로 어떻게 보완되나?
  • 이를 통해 변경된 데이터만 추적하여 별도 이벤트 스트림으로 처리하므로, 전체 컬렉션을 반복 조회하는 풀스캔 부담을 줄인다.
  • 즉, 도큐먼트 저장소의 풀스캔 부담을 줄이고, 변경 데이터에 집중한 효율적 처리를 가능하게 한다.
  • CDC 기반 이벤트 스트림은 실시간 분석, 동기화, 데이터 파이프라인 구축에 활용되어 데이터 신뢰성과 효율성을 개선한다.
  • CDC는 데이터 변경 이벤트(생성, 수정, 삭제)를 실시간 스트림 형태로 캡처한다.

3. 와이드 컬럼 DB

• 예: Cassandra
• 특징: 빠른 쓰기 성능과 대규모 분산처리, 1개의 인덱스만 지원
• 단점: 복잡한 쿼리 및 트랜잭션 어려움, 인덱스 외 데이터 액세스 시 풀스캔 또는 CDC를 이용한 이벤트 캡처 필요
• 활용처: 대용량 데이터 저장, 전자상거래, 핀테크 트랜잭션 처리

4. 그래프 DB

• 예: Neo4j
• 특징: 노드와 엣지 구조로 복잡한 관계 탐색에 최적, 특수 쿼리 언어(SPARQL, GRAPHQL, Cypher 등) 지원
• 도큐먼트 저장소의 관계 탐색 한계 보완
  • 도큐먼트 저장소는 각 데이터를 문서 단위로 저장하며, 조인(Join) 기능이 없어 다수의 연관된 데이터를 함께 조회하기 어렵다.
  • 관계 표현이 제한적이고, 실시간으로 복잡한 관계를 탐색하거나 순회하는 데 비효율적이다.
  • 따라서 다중 레벨 연결, 다대다 관계 등 복잡한 네트워크 데이터를 효과적으로 처리하기 어렵다.
  • 그래프 DB가 어떻게 보완하는가?
    • 그래프 DB는 노드와 엣지로 데이터를 표현하여, 복잡한 관계와 연결을 자연스럽게 모델링한다.
    • 그 결과, SNS 친구 관계, 추천 시스템, 사기 탐지 등 관계 기반 쿼리를 효율적이고 빠르게 수행할 수 있다.
    • 도큐먼트 저장소에서 비효율적인 다중 조인, 중첩 문서 탐색 문제를 그래프 DB는 연결 탐색으로 해결한다.
• 활용처: SNS, 추천 시스템, 복잡한 네트워크 분석

 

• 검색 DB: 텍스트 검색, 로그 분석에 최적화. 인덱싱으로 쿼리 성능 향상, Elasticsearch
• 시계열 DB: 주가, 기상 등 시계열 데이터에서 대량의 쓰기 작업과 실시간 분석에 적합. Apache Druid

 

기존 RDBMS와의 차이

• 기존에는 시계열 데이터와 텍스트 로그 등을 RDBMS에 저장해왔지만, 빅데이터 시대가 되면서 특수 목적 DB가 필요해짐
• RDBMS는 정형화된 테이블과 엄격한 스키마를 사용하며, 복잡한 조인과 트랜잭션 관리에 강점
• Elasticsearch와 시계열 DB는 비정형 데이터, 대용량 데이터, 빠른 검색과 분석에 특화되어 있어 빅데이터 환경에 적합

 

API 종류

• REST API: 무상태(stateless)가 특징으로, 각각의 요청이 독립적이고 서버에 상태를 저장하지 않음. HTTP 메서드 기반
  • 즉, 한 번의 요청이 끝나면 서버는 그 요청과 관련된 데이터를 저장하지 않고 모두 버린다.
  • 요청 시 필요한 정보가 요청 메시지 안에 다 들어있고, 서버는 해당 요청만 보고 처리하는 것이다.
  • 서버는 클라이언트 상태를 저장하지 않기 때문에 이전 요청의 영향 없이 각 요청이 독립적으로 처리된다. 
  • 무상태인이유: 클라이언트-서버 간에 상태 정보를 저장하지 않고 각 요청을 독립적으로 처리하게 함 -> 확장성, 성능, 장애 허용성, 단순성 개선
  • 요청을 여러 서버 인스턴스에 자유롭게 분산할 수 있어 쉽게 확장할 수 있다.
  • 각 요청이 요청에 필요한 모든 정보를 포함하고 있어 서버는 세션 상태 관리나 상태 조회 오버헤드 없이 빠르게 요청을 처리할 수 있다.
• GraphQL: 쿼리가 특정 데이터 모델로 제한되는 REST API와 달리, 단일 요청으로 여러 데이터 모델을 검색할 수 있게 한다. 더 유연한 쿼리를 짤 수 있는 것. 
• 웹훅: 이벤트 발생 시 지정된 URL로 자동 호출되는 역방향 API 방식. GitHub 액션에서 사용해봤다.
• RPC, gRPC: 원격 프로시저 호출(remote procedure call) 방식으로, 분산 시스템에서 빠른 통신과 처리를 위해 사용
  • gRPC는 RPC를 HTTP/2와 프로토콜 버퍼라는 이진 직렬화 기술을 활용해 구현한 것
  • 이진 직렬화: JSON 같은 텍스트 형식 대신 프로토콜 버퍼를 사용해 데이터 크기가 작고 직렬화/역직렬화 속도가 빠르다.

 

---

 

데이터 스토리지 시스템과 관리

 

데이터 저장

데이터 저장은 데이터 분석, 변환, 서빙의 핵심 단계이기 때문에 중요하며, 각 단계마다 저장 전략과 시스템을 선택하는 것이 성능과 안정성에 큰 영향을 미친다. 이를 위해 여러 저장 방식과 추상화 계층이 존재한다.

 

스토리지 추상화

• 데이터 레이크: 원시 데이터를 그대로 저장하며, 구조화되지 않은 데이터를 대량으로 저장하는 데 적합
• 데이터 레이크하우스: 데이터 레이크와 데이터 웨어하우스의 장점을 결합한 플랫폼
• 데이터 플랫폼: 다양한 데이터 저장소와 처리 엔진을 포괄하는 통합 환경.
• 클라우드 데이터웨어하우스: 클라우드 기반 데이터 웨어하우스로, 확장성과 유연성을 보장하며 분석과 보고에 적합하다.

https://koreatstm.tistory.com/309#1.%20Data%20Warehouse-1

데이터 엔지니어링

 

 

스토리지 시스템

• 하둡 분산 파일 시스템(HDFS): 대규모 데이터를 분산 저장하는 오픈소스 프레임워크
• 캐시/메모리 기반 스토리지: 빠른 데이터 접근을 위해 RAM을 활용, 예: Redis, Memcached
• RDBMS: 관계형 데이터베이스로 구조화된 데이터를 저장, 트랜잭션 처리에 강함
• 객체 스토리지: 장기 저장, 확장성 좋음, 예: Amazon S3
• 스트리밍 스토리지: 실시간 데이터 흐름을 저장 및 처리, 예: Kafka

 

데이터 직렬화

• 데이터 자체는 네트워크 전송, 디스크 저장 시 바로 사용할 수 없기 때문에 직렬화 과정을 거친다. 
• 텍스트 기반 직렬화 (JSON, XML, CSV)
  • 사람이 읽고 쓰기 쉬움
  • 크기가 상대적으로 크고, 파싱 속도가 느릴 수 있음
• 인메모리 직렬화
  • 빠른 처리와 전달을 위해 메모리 내에서 직렬화하는 방식을 사용해 성능 향상
  • 바이너리 형태로 직렬화되어 속도가 빠름, 크기도 작음
  • Airflow 같은 워크플로우 도구에서 작업 상태나 중간 결과 전달에 활용
  • pickle파일이 여기에 해당

 

 

데이터 스토리지 시스템

 

단일머신 vs 분산 스토리지

• 단일 머신 스토리지: 하나의 서버에 저장하는 방식. 속도는 빠르지만 단일 장애점(Single Point of Failure)이 있어 내결함성이 낮다.
• 분산 스토리지: 여러 서버에 데이터를 분산해서 저장 -> 한 곳에 장애가 생겨도 서비스가 유지되도록 설계. 고가용성과 확장성

 

일관성 모델

• 강력 일관성: 모든 노드에서 동시에 최신 데이터를 볼 수 있도록 보장. 성능이나 가용성 문제 가능
• 최종 일관성: 일정 시간이 지나면 모든 노드의 데이터가 일관되도록 보장하지만, 일시적으로는 데이터가 일치하지 않을 수 있다. 가용성, 확장성 좋다.

 

파일 스토리지 vs 객체 스토리지 vs 블록 스토리지

• 파일 스토리지: 디렉터리와 파일 구조를 갖춘 전통적인 저장 방식. NAS(Network Attached Storage)가 대표적이며 파일 단위 접근을 지원
• 객체 스토리지: 파일, 이미지, 동영상 등 모든 형태와 크기의 데이터를 객체 단위로 저장
  • 각 객체는 고유한 키-값 쌍으로 관리되며, 데이터와 함께 메타데이터를 함께 관리
  • 저장된 객체는 불변(immutable) 데이터로 취급되어 변경 대신 새 객체로 대체하는 방식
  • 확장성이 뛰어나고, AWS S3, 대용량 비정형 데이터 저장에 적합
• 블록 스토리지: 디스크 블록 단위로 데이터를 저장하는 방식으로, SAN(Storage Area Network)이 대표적. 일반적으로 OS가 로컬 디스크처럼 인식하며, 고성능이 요구되는 데이터베이스 등에 사용된다.

 

클라우드 내 블록 스토리지 예: AWS EBS

• EBS (Elastic Block Store): AWS의 가상화된 블록 스토리지 서비스로 EC2 인스턴스와 별도로 저장되지만, 동일 가용 영역(AZ)에 존재해 낮은 지연과 높은 성능을 제공
• EBS 볼륨은 여러 호스트와 디스크에 데이터를 복제해 내구성과 가용성을 높인다.
• 단, 가용 영역(AZ) 전체에 장애가 발생하면 EBS 볼륨 복원은 불가능

EC2 인스턴스 스토어

• EC2 인스턴스 스토어는 EC2 인스턴스 자체에 물리적으로 연결된 로컬 스토리지
• 인스턴스가 종료되거나 재시작되면 인스턴스 스토어의 데이터는 모두 사라진다.
• 빠른 I/O 성능이 필요할 때 사용하지만, 영구 저장용으로는 적합하지 않다.

EC2에는 EBS라는 별도 관리되는 높은 내구성 블록 스토리지가 있고, 인스턴스 스토어는 임시 로컬 스토리지라는 차이가 있다. 

• 인스턴스 스토어는 EC2 인스턴스(컴퓨터)의 내장 디스크로 빠르지만 내구성은 부족한 임시 저장 공간
• EBS는 외부 네트워크로 연결된 영구적이고 독립적인 저장장치로, 데이터 영속성과 복원력을 제공하는 저장공간

 

캐시 시스템

• Memcached와 Redis가 대표적인 메모리 기반 캐시 솔루션
• Memcached는 단순한 키-값 저장에 초점, 빠른 읽기/쓰기에 적합
• Redis는 키-값 저장 외에도 다양한 데이터 구조(리스트, 셋, 정렬된 셋 등)를 지원하며, 지속성 저장과 복제 기능도 제공

 

스트리밍 스토리지

• 스트리밍 데이터는 일반적인 배치 데이터와 달리, 순차적이고 실시간 처리가 핵심
• 핵심 개념 중 하나인 리플레이는 스트리밍 시스템에 저장된 과거 데이터를 특정 범위까지 다시 읽거나 재처리할 수 있는 기능
• 이를 통해 장애 복구, 재처리, 그리고 데이터의 특정 시점 상태 재구성이 가능해진다.

 

쓰기 스키마 (Write Schema)

• OLTP, 전통적인 데이터 웨어하우스에서 주로 사용
• 데이터가 저장될 때 엄격한 표준화와 구조를 미리 정의 (schema-on-write)
• 데이터 삽입 시 스키마 검증과 정형화가 이루어져 데이터 품질과 일관성을 보장
• 하지만 스키마 변경이 어렵고 유연성이 낮음

읽기 스키마 (Read Schema)

• OLAP, 데이터 레이크 등에서 주로 사용
• 저장 시에는 스키마를 엄격히 적용하지 않고, 데이터를 읽거나 분석할 때 스키마를 동적으로 적용 (schema-on-read)
• 읽기 시점에서 필요한 형식으로 데이터를 변환하여 유연한 쿼리와 분석이 가능
• 다양한 비정형 데이터 처리에 유리함

 

왜 컴퓨팅과 스토리지를 분리 해야 하는가?

• 컴퓨팅(처리) 자원과 스토리지(데이터 저장) 자원을 분리하면 자원 활용 효율성이 높아진다.
• 컴퓨팅 용량은 처리량 증가에 맞게 탄력적으로 조절 가능하지만, 스토리지는 대용량 데이터 저장에 특화되어 비용이 절감된다.
• 만약 컴퓨팅과 스토리지가 결합되면 컴퓨팅 자원에 데이터를 함께 저장하므로, 컴퓨팅 확장 시마다 스토리지도 함께 증설되어 비효율적이고 복잡해진다.
• EC2 같은 컴퓨팅 자원은 필요할 때만 늘리고, 데이터는 S3 같은 독립적인 스토리지에 저장되어 비용과 성능을 분리 관리 가능
• 컴퓨팅 장애 시에도 데이터는 안전하게 유지되며, 컴퓨팅과 스토리지를 각각 최적화하고 확장할 수 있어 운영의 유연성과 안정성 증가

 

데이터 분류

 

모든 데이터를 핫 스토리지에 저장하면 최고의 성능을 내지만 비용이 감당하기 어렵고, 반대로 모든 데이터를 콜드 스토리지에 두면 비용을 절감하지만 성능 저하가 크다. -> trade-off를 고려

• 핫 데이터 (Hot Data): 자주 접근되고, 즉시 사용해야 하는 데이터
  • 빠른 접근성과 낮은 지연 시간이 필수
  • 고성능 스토리지(예: SSD, 메모리) 사용하지만 비용이 매우 높음
• 웜 데이터 (Warm Data): 중간 정도 빈도의 접근을 가지는 데이터
  • 비용과 성능의 균형을 맞춘 저장소에 저장
  • 빠른 조회는 아니더라도 적당한 속도가 필요
• 콜드 데이터 (Cold Data): 드물게 접근하는 장기 보관용 데이터
  • 저장 비용이 낮은 장기 보관용 스토리지 사용(예: 테이프, 저가형 HDD, 클라우드 아카이브)
  • 접근 속도는 느리지만 비용 절감에 초점

 

싱글 테넌트 vs 멀티 테넌트 데이터 저장

 

싱글 테넌트 (Single Tenant)

• 각 테넌트가 전용 스토리지와 데이터베이스 환경을 가진다.
• 데이터 스키마, 버킷, 인프라가 독립적이어서 테넌트별 맞춤 설정과 보안이 쉽다.
• 인프라 중복 및 관리 비용 증가, 테넌트 간 데이터 통합 및 분석이 어렵다.

멀티 테넌트 (Multi Tenant)

• 단일 스토리지 또는 데이터베이스 내에 여러 테넌트 데이터가 공존하며, 동일한 인프라와 구조를 공유
• 인프라 비용 절감과 효율적인 리소스 활용이 가능하고 스케일이 쉽다.
• 그러나 각 테넌트 데이터의 분리와 보안, 그리고 스키마 제한 등 관리상의 어려움 존재

-> 보안 요구사항, 비용 효율성, 관리 편의성, 데이터 통합 필요성 등을 고려해 선택

 

예를 들어, 민감한 금융 데이터는 싱글 테넌트를 선호 / SaaS 서비스 대량 고객 대상은 멀티 테넌트가 효율적

싱글 테넌트는 각 테넌트가 전용 스토리지와 독립 스키마로 분리되어 있어 테넌트별 통제가 쉬우나, 인프라 중복과 통합 분석 어려움이 있다.

멀티 테넌트는 단일 데이터베이스 내 여러 테넌트 데이터를 저장해 비용과 운영 효율이 높지만, 데이터 분리, 보안, 스키마 제약 관리가 필요