1. NoSQL (Not Only SQL)
SQL만을 사용하지 않는 여러 유형의 DB를 통칭한다.
기존 RDBMS의 문제점
- 스키마 규칙이 너무 강함 → 유연하지 못함
- 트랜잭션 원자성 보장은 되지만, 동시 처리량이 낮음
- 디스크 기반의 수직 확장에 의존
| 이유 | 핵심 |
|---|---|
| 데이터 다양성 | 구조적/반구조적/비구조적 데이터 모두 처리, 고정 스키마 불필요 |
| 대규모 데이터 처리 | 분산 저장으로 병렬 처리, 빠른 읽기/쓰기 |
| 수평적 확장성 | 서버를 추가해서 확장, RDBMS의 수직 확장보다 비용 효율 높음 |
| 유연한 설계 | 초기 설계 단순, 변경 사항에 빠르게 적응 |
비관계형 DB는 기본적으로 트리 구조 데이터 구성을 가진다.
1-1. Key-Value Store
단순한 key-value 한 쌍으로 데이터를 저장하는 구조다.
Key: User_12345
Value: {"name": "Alice", "age": 25}In-Memory DB 구조
- CPU는 연산을 위해 데이터를 RAM에서 가져옴
- 디스크는 매우 느리므로 중간에 Memory(RAM)을 사용
- 특징: 휘발성, 속도 빠름, 용량 적음, 가성비 안 좋음
장점
- Hash Table 기반 → 매우 빠른 읽기/쓰기
- 구조 단순 → 수평 확장 용이
단점
- 복잡한 쿼리나 검색 어려움
- value(보통 JSON) 내부 구조를 DB가 이해하지 못함
주요 사용처
- 세션, 캐시, 토큰, 사용자 설정 → 많이 쓰고 많이 읽어야 하는 곳
- 대표 DB: Redis
저장장치 속도 비교
RAM (In-Memory) > SSD > HDD속도는 높이고 싶지만 데이터 용량이 비교적 클 때 → SSD 기반 DB 사용
- Aerospike: SSD에 저장, 실시간성 + 데이터 영속성 + 큰 용량이 필요할 때
실시간 채팅에서의 활용
- 채팅 메시지를 key-value store에 먼저 저장 → 빠른 응답성 제공
- 주기적으로 Document Store나 RDB에 이관하여 영속성 보장
1-2. Document Store
문서(JSON) 단위로 데이터를 저장하는 구조다.
{
"user_id": "12345",
"name": "Alice",
"email": "alice@example.com"
}장점
- 구조 자유로움
- 문서 단위 조회, 수정
단점
- JOIN 어려움
- 데이터 중복 허용
대표 DB: MongoDB, Couchbase
1-3. Column-Oriented Store
데이터를 행(row) 단위가 아닌 열(column) 단위로 저장하는 구조다.
row-oriented는 대용량 데이터에서 I/O가 많아 성능이 떨어질 수 있다. column-oriented는 특정 컬럼만 읽으면 되므로 집계 쿼리에 유리하다.
장점
- 대용량 데이터, 빅데이터 처리에 적합
- 집계 쿼리(SUM, AVG 등) 빠름
단점
- 설계 복잡
- 단순 조회/저장 외 복잡한 쿼리 어려움
SELECT *매우 느림
대표 DB: Cassandra, HBase
1-4. Graph Store
노드(개체)와 엣지(관계)로 데이터를 저장하는 구조다.
장점
- 관계 기반 조회 최적화
- 소셜 네트워크, 추천 시스템에 효율적
단점
- 트랜잭션/대용량 처리 어려움
- 수평 확장 어려움
주요 사용처: 추천 시스템, 소셜 그래프 분석
CAP 이론
분산 시스템에서 일관성(Consistency), 가용성(Availability), 네트워크 분할 허용(Partition Tolerance) 중 두 가지만 동시에 만족할 수 있다는 이론이다.
| 항목 | 의미 |
|---|---|
| Consistency (일관성) | 모든 사용자가 최신 상태를 동일하게 봄 |
| Availability (가용성) | 일부 고장에도 서비스 유지 |
| Partition Tolerance (파티션 허용) | 네트워크 오류에도 작동 |
대부분의 NoSQL은 A(가용성), P(파티션 허용)를 보장하고, 일관성은 애플리케이션 내부에서 직접 관리한다.
2. DB 확장 전략
데이터베이스를 물리적 또는 논리적으로 분산시키는 기술이다.
2-1. Partitioning
기존 테이블을 파트로 나누는 방식이다.
Vertical Partitioning (수직 파티셔닝)
하나의 테이블에서 컬럼을 나누는 방식이다. 자주 조회되는 컬럼과 아닌 컬럼을 분리한다.
users 테이블 → users_basic (id, name, email)
+ users_detail (id, bio, profile_image, created_at)장점
- 자주 조회되는 데이터에 대한 I/O 감소
- 테이블 잠금 및 캐싱 효율 증가
단점
- JOIN 필요도 증가
- 이관 검증 필수 (파티셔닝 후 원본 데이터와 타겟 데이터 간의 누락, 변형, 관계 훼손 여부 확인)
Horizontal Partitioning / Sharding (수평 파티셔닝)
하나의 스키마를 여러 테이블로 나누는 방식이다. 테이블 스키마는 같지만 범위에 따라 저장한다.
| 방식 | 기준 | 예시 |
|---|---|---|
| Range-based | ID 범위, 날짜 범위 | user_id 0~999 → shard1 |
| Hash-based | 해시 함수 결과 | hash(user_id) % 2 → shard 선택 |
| Composite | 위 두 가지 혼합 | — |
단점
- 인덱스 관리 어려움
- 여러 shard에 걸친 쿼리 복잡
2-2. Replication
똑같은 데이터를 복제하는 방식이다.
| 노드 | 역할 | 처리 작업 |
|---|---|---|
| Master (Primary) | 쓰기 담당 | INSERT, UPDATE, DELETE |
| Slave (Replica) | 읽기 담당 | SELECT |
동작 방식
- Master: 데이터 write 전용, binary log 생성
- Slave: binary log를 읽어서 동기화, read 전용
핵심 주의사항
- Replication lag: 복제 지연이 발생할 수 있음 → 핵심 작업은 Master에서 처리, 지연이 허용되는 부분만 Slave로
- Failover: Master 장애 시 Slave를 새 Master로 승격
- 성능 병목: 과도한 Slave 수는 오히려 병목이 될 수 있음
3. Server Cache
반복되는 요청을 매번 다시 처리하는 것은 비효율적이다. 처리한 결과를 저장하고, 동일한 요청이 오면 저장한 결과를 반환하는 전략이다.
서버가 여러 대(scale out)로 늘어날수록 DB 부하가 커진다. 캐시로 DB 조회 자체를 줄이는 전략이 필요하다.
3-1. Local Cache
각 서버 인스턴스 내부 메모리에 위치하는 캐시다.
- 위치: 각 애플리케이션 서버의 메모리 내부
- 접근 속도: 가장 빠름 (네트워크 없이 메모리 직접 접근)
- 동작 원칙: DB 조회 전에 항상 Local Cache를 먼저 확인
- 대표 구현: JVM Heap (Caffeine 등)
- 적합한 데이터: 인기글, 공통 설정 등 자주 읽히고 잘 바뀌지 않는 데이터
문제점: 서버가 여러 대(scale out)일 경우 각 서버의 캐시가 서로 달라질 수 있음 → 동기화 문제 발생 가능
3-2. Global Cache
모든 서버가 공유하는 별도의 독립 인스턴스 캐시다.
[서버 A] ↘
→ [Redis 등 별도 인스턴스] → DB
[서버 B] ↗- 위치: 별도의 독립 인스턴스 (ex. Redis)
- 접근 속도: Local보다 느림 (네트워크 경유)
- 장점: 어느 서버에서 요청이 와도 동일한 데이터를 봄
- 대표 구현: Redis, Memcached
- 적합한 데이터: 인증 정보, 세션, 토큰 등 모든 서버가 동일하게 봐야 하는 데이터
| 항목 | Local Cache | Global Cache |
|---|---|---|
| 저장 위치 | 서버 내부 메모리 | 별도 독립 인스턴스 |
| 접근 속도 | 매우 빠름 | 상대적으로 느림 |
| 데이터 일관성 | 서버마다 다를 수 있음 | 모든 서버가 동일하게 공유 |
| 적합한 데이터 | 인기글, 공통 설정 | 인증 정보, 세션 |
| 대표 구현 | JVM Heap (Caffeine 등) | Redis, Memcached |
⚠️ 캐시는 예민한 문제다. 현업에서 캐시 문제를 인지하는 시점이 너무 늦는 경우가 많다.
3-3. Cache 사용 위치
캐시는 서버 코드 안에만 있는 것이 아니라 인프라 전체에 걸쳐 존재한다.
DB 엔진 메모리
DB 자체도 내부적으로 캐시를 갖는다. MySQL InnoDB의 Buffer Pool이 대표적이다.
CDN (Content Delivery Network)
전 세계 여러 지리적 위치에 분산된 서버 네트워크로, 이미지/동영상/정적 파일을 사용자에게 가까운 서버에서 캐싱하여 전송한다.
브라우저 로컬 캐시
브라우저가 이전에 받은 리소스를 로컬에 저장해두고 재사용한다.
Proxy
서버와 클라이언트 사이 중간 계층에서 HTTP 응답을 캐싱한다.
사용자 → [브라우저 캐시] → [CDN] → [Proxy] → [서버 Local/Global Cache] → DB"인프라 엔지니어는 가성비를 따져서 인프라를 설계할 줄 알아야 한다" → FinOps
