[면접공부] - db (feat.gpt) (1)

klom 2025. 4. 15. 23:52

db같은 경우는 내 멘토님이 요런거를 공부하라고 하셔서 몇가지만 다시 적어보려구 한다.
1. CAP & PACELC 이론
2. 클러스터링
3. 리플리케이션 (아직)
4. 파티셔닝 (아직)
5. 샤딩 (아직)

더 많지만.. 다시 정리하는 차원에서 하는거니까..
일단 요정도만 하장
db는 그래도 내가 열심히 조사했으니 괜찮겠지..
첫번째 cap&pacle이건 분산시스템에서 만족할 수 없는 원칙이라고 한다. 둘중 CAP이 만족할 수 없는 원칙이다.PACLE은 다른거이므로
조금있다 작성예정이다. CAP은 약자로 일관성,가용성,네트워크 분할 하용이 존재하고 이들중 두개만 만족을 시킬 수 있다고 한다.
더욱이 MSA환경에서는 네트워크 분할은 무조건 가져가야 하므로 일관성과 가용성중 하나를 포기를 해야 할듯싶다.
근데 뭐가 더 중요할까?
상황에 따라 다르겠지만 CP는 시스템은 금융 시스템처럼 데이터 정합성이 중요한 경우 사용되어지고
AP 시스템은 SNS나 캐시 시스템처럼 빠른 응답이 중요한 경우 사용되어진다. 그러니까 내가 개발하고 있는것이 정합성이 중요한지 속도가 중요한지 생각을 해봐야 한다. 내가 개발하고 있는건 소모임이랑 세션쪽이다 이둘의 공통점은 맴버가 존재한다는거구 나는 이 맴버를 따로 서버로 뺄 생각이다. 그렇다면 통신을 데이터큐 또는 web통신으로 해야 된다는 말인데 그러다보면 데이터의 유실가능성이 발생한다. 그럼 내가 신경을 써야 하는 부분은 AP보다는 CP를 신경써야 한다. 왜냐하면 도메인 특성상 속도보다는 데이터의 정합성이 더 중요하다고 생각한다. 왜냐하면 가입을 했는데... 조회를 했는데... 안나오면 안되기 때문에 CP가 더 중요하다. 그렇담 PACLE은 멀까 사실 CAP은 장애에 대한 성능을 고려한건데 장애가 발생하지 않았을때의 성능은 고려되지 않았다. 그렇게 나원 원칙이 PACLE이다. P 파티션 발생시
AP vs CP를 고려해야 하고 E또는 레이턴시와 일관성에 대해 설명을 해야 한다고 한다. 여기서 레이턴시는 데이터가 요청된 순간부터 응답을 받을 때까지 걸리는 시간(지연 시간)을 의미합니다.
즉, 사용자가 요청을 보내고 결과를 받을 때까지의 딜레이(Delay)입니다.
그러니까 일관성 또는 레이턴시를 신경을 써야 한다는거다. 근데 이게 레이턴시가 그렇게 중요하지 않는 이유가
시점 자체가 생성이랑 조회가 다르기때문에 레이턴시는 중요하지 않을거 같다. 그러면 일관성인데 생각해보니 메시지 유실은 네트워크 실패는 아니니.. 위에서 말한건 CAP에 해당되지 않는 말인듯하다. 암튼.. 레이턴시와 일관성중 고르자면 일관성이다. 데이터를 정확하게 입력을 해야 되는느낌근데.. 내가 생각했을때 C-> 일관성, A -> 레이턴시로 중요하지 않지 않을까 싶다. 요건 GPT가 어케 반응하는지 보자
CAP 이론은 분산 시스템에서 네트워크 분할 상황이 발생했을 때,
Consistency와 Availability 중 하나를 선택해야 한다는 이론입니다.
하지만 현실에서는 Partition이 없을 때도 성능과 일관성 사이의 trade-off가 존재해서,
이를 설명하는 PACELC 이론이 더 실무에 가깝다고 생각합니다.
예를 들어 Cassandra는 PA/EL 구조로, Partition 상황에서도 가용성을 우선하고,
그렇지 않을 때도 빠른 응답을 위해 Latency를 줄이는 쪽을 택합니다.
라고 한다. 그러면 얘네를 신경써야 하는 DB는 어떤게 있나 생각해보자.

기왕한김에 NoSQL도 검색해봤다.

📄 문서 지향형	JSON/BSON 같은 문서 형태로 저장	MongoDB	CP 또는 PA/EL (버전에 따라 다름)	Consistency 또는 Latency 선택 가능
🔑 키-값 저장소	Key 하나로 Value를 빠르게 조회	Redis, DynamoDB	Redis: CA (단일 노드) / DynamoDB: AP	DynamoDB: PA/EL
📊 컬럼 지향형	열 중심으로 데이터를 저장 (대량 조회 최적)	Cassandra, HBase	Cassandra: AP, HBase: CP	Cassandra: PA/EL, HBase: PC/EC
🌐 그래프형	노드와 관계로 데이터 표현	Neo4j	보통 CP	주로 일관성 우선

라고 하는데 뭔가 와닿지 않는다. 그래서...

📌 Cassandra

컬럼 기반 NoSQL, 대규모 데이터 쓰기/읽기에 적합
AP 시스템 → Partition 발생 시 가용성 우선, 일관성은 나중에 보장 (Eventual Consistency)
PACELC: PA/EL → 평소에도 낮은 지연 시간 우선

👉 대규모 추천 시스템, 로그 수집 등에 적합

📌 MongoDB

문서 지향형 DB, JSON 형태로 직관적이고 유연함
기본은 CP 지향, 하지만 복제 설정에 따라 AP처럼 동작 가능
PACELC 관점에서는 선택 가능 → 지연 시간과 일관성 중 선택 가능

👉 게시판, 블로그, 사용자 프로필 저장 등에 적합

📌 Redis

인메모리 키-값 저장소, 매우 빠름
단일 노드에선 CA, 분산 구성에서는 가용성 우선
일관성보다 속도를 중요시함

👉 캐싱, 세션 저장, 랭킹 시스템 등

📌 HBase

Hadoop 위에 구축된 컬럼 기반 DB
CP 지향 → 항상 일관성 우선
PACELC: PC/EC

👉 금융 거래 기록, 로그 분석 등에서 정확한 데이터가 중요할 때

그러면 내가 맡은 부분은 어디서 좋은지 생각을 해봐야 하는데...

🎟️ 티켓팅 시스템의 핵심 요소

1. ✅ 정확한 수량 관리 (일관성 Consistency)

남은 자리 수는 정확해야 해요.
두 명이 동시에 신청했는데 자리가 1개면, 한 명만 받아야 하죠.
초과 참여를 막기 위한 동시성 제어가 필요해요.

📌 관련 기술:

Redis의 분산 락 (RedLock) 또는
데이터베이스의 낙관적/비관적 락
또는 Kafka로 선착순 큐를 만들고 소비하는 방식도 있음

2. ⚡ 빠른 응답과 고가용성 (Availability & Latency)

많은 요청이 짧은 시간에 몰릴 수 있어서, 빠른 처리와 응답이 중요해요.
이를 위해 Redis나 Kafka 같은 메모리 기반 시스템 활용이 좋아요.

📌 예:

Redis에 자리 수를 저장하고 decr() 로 원자적으로 감소시킴
실패한 사용자는 바로 실패 처리 (응답 빠름)

3. 🔐 중복 방지 및 중복 신청 처리

한 사용자가 여러 창을 열고 계속 참여를 시도할 수 있어요.
사용자별 티켓 상태를 기억해야 해요 → Redis Set, Bloom Filter 등이 유용할 수 있음

4. 🧾 기록의 신뢰성과 저장 (Persistence)

최종적으로 누가 성공했는지는 영속 저장이 필요해요 (ex. PostgreSQL 등)

📌 전략:

Redis → 캐시 or 중간 처리
최종 결과는 DB에 저장해서 추후 복구나 통계, UI 표시 등에 사용

[Client 요청]
     │
     ▼
[API Gateway or Controller]
     │
     ▼
[Redis]
  - key: session:{id}:slots
  - key: session:{id}:users
     │
     ├── 자리 수 감소 (DECR)
     ├── 사용자 중복 확인 (SISMEMBER)
     ├── 분산 락 (선택)
     ▼
[자리 있음 & 중복 아님]
     │
     ▼
[RDB 저장]
  - session_participants 테이블 INSERT
     │
     ▼
[응답: 참여 성공]

구조도는 요렇게 그려질거 같다.
더 자세하게 물어보고는 싶지만.. 요건 면접 공부니까...

다음꺼를 공부 해보자.
클러스터링 요건 여러 개의 DB를 수평적인 구조로 구축하는 방식이라고 한다. 잘 모르겠다. 이런건 그려봐야 알거 같은데
수평적으로 나눈다고 했는데 샤딩이랑 뭐가 다른거지??

그림 요렇다는데.. 그러니까 하나의 DB를 여러개로 쪼개서 관리한다는건데 왜 이렇게 관리를 하는거지?
아 gpt끝나버렸네..
DB 클러스터링을 하는 주요 이유는 다음과 같습니다:

고가용성(High Availability): 한 서버가 다운되어도 다른 서버가 작업을 계속할 수 있어 서비스 중단을 방지합니다.
부하 분산(Load Balancing): 여러 서버에 부하를 나누어 처리 속도를 향상시킵니다.
확장성(Scalability): 필요에 따라 쉽게 서버를 추가할 수 있습니다.
데이터 안전성: 데이터가 여러 노드에 복제되어 데이터 손실 위험을 줄입니다.

개발자가 직접 DB를 다르게 가져가는 것(샤딩 등)과 클러스터링의 차이점:

관리 측면:
- 클러스터링은 DB 시스템이 자동으로 관리하는 반면
- 개발자 직접 구현은 애플리케이션 코드 레벨에서 관리해야 합니다
데이터 일관성:
- 클러스터링은 시스템 레벨에서 데이터 일관성을 보장합니다
- 개발자 구현은 일관성 관리를 위한 추가 로직이 필요합니다
복잡성:
- 클러스터링은 DB 자체에서 처리하므로 구현이 상대적으로 간단합니다
- 개발자 구현은 더 복잡한 코드와 로직이 필요합니다
유연성:
- 개발자 구현은 특정 요구사항에 맞게 커스터마이징할 수 있습니다
- 클러스터링은 DB 시스템이 제공하는 기능으로 제한됩니다

클러스터링은 DB 시스템이 제공하는 내장 기능으로, 개발자가 별도로 구현하지 않아도 시스템 레벨에서 가용성과 성능을 향상시킬 수 있는 장점이 있습니다.

MySQL의 NDB Cluster나 Group Replication요런게 있다고 한다.
와닿지는 않네... 그냥 클러스터링은 DB를 수평적으로 나누는작업으로 알고 있어야 곘다.

DB 클러스터링은 여러 서버에 데이터베이스를 분산 배치하여 고가용성, 부하 분산, 확장성을 확보하는 기술입니다. 주요 목적은 장애 발생 시에도 서비스가 중단되지 않도록 하고, 대규모 트래픽을 효과적으로 처리하는 것입니다.
클러스터링은 데이터베이스 시스템 자체에서 제공하는 기능으로, 개발자가 직접 구현하는 샤딩과는 차이가 있습니다. 클러스터링은 시스템 레벨에서 데이터 일관성과 동기화를 자동으로 관리하지만, 개발자 구현은 애플리케이션 코드에서 관리해야 하는 더 복잡한 과정입니다.
클러스터링은 초기 설정과 운영에 전문 지식이 필요하지만, 일단 구성이 완료되면 데이터베이스 시스템이 노드 간 복제, 장애 감지 및 복구, 부하 분산 등을 자동으로 처리합니다.
대규모 서비스에서는 안정성과 성능을 위해 클러스터링이 필수적이며, 최근에는 클라우드 서비스(AWS RDS, Azure Database 등)를 활용하면 복잡한 설정 없이도 클러스터링의 이점을 쉽게 활용할 수 있습니다.

나머지는 이따 계속 이어서 해야겠다..