Kubernetes 5일차 개념 정리

 

DB 복제 구조

 

1. M-S (Master - Slave)

• 구조: Master 1개, Slave 1개
• 역할
  • Master: 쓰기 전용
  • Slave: 읽기 전용 (Master 데이터를 복제해서 사용)
• 특징: 구조가 단순하고 명확하지만, 읽기 부하 분산이 어려움

---

2. M-MS (Master - Multi Slave)

• 구조: Master 1개, Slave 여러 개
• 역할
  • Master: 쓰기 전용
  • 여러 Slave: 읽기 전용
• 특징: 읽기 부하 분산이 가능하여, 읽기 요청이 많은 시스템에 적합

---

3. MM-S (Multi Master - Slave)

• 구조: Master 여러 개, 각 Master에 따라 연결된 Slave 존재
• 역할
  • Master: 각각 쓰기 가능
  • Slave: 각자의 Master에서 복제된 데이터 읽기
• 특징: 쓰기 확장성 ↑
  단, 충돌 관리 어려움 (각 Master의 동기화/데이터 충돌 문제)

---

4. MM (Multi Master)

• 구조: Master 여러 개, Slave 없음 또는 Master 자체에서 읽기 수행
• 역할
  • 모든 Master가 읽기/쓰기 가능
  • Master 간 양방향 동기화 필요
• 특징: 고가용성과 데이터 동기화 복잡성↑
  예시: Galera Cluster

 

 

CAP 이론

 

CAP: 분산 시스템에서 동시에 만족할 수 없는 3가지 속성을 정의한 이론

요소	설명
C - Consistency (일관성)	모든 노드에서 같은 데이터를 보장. 하나의 요청 이후 모든 클라이언트가 동일한 값을 봄
A - Availability (가용성)	일부 노드가 다운되어도, 클라이언트 요청에 응답함 (단, 데이터가 최신이 아닐 수도 있음)
P - Partition Tolerance (분할 허용성)	네트워크가 분리되어도 시스템은 동작을 멈추지 않음

 

• 세 가지를 동시에 만족할 수는 없음
• 3개 중 2개만 동시에 보장 가능
  → 네트워크 장애(Partition)가 항상 발생할 수 있으므로, 대부분 P는 기본 전제
  → 따라서 실제 선택지는 C vs A

 

Eventual Consistency (결국엔 일관성)

 

• 일시적으로는 불일치하더라도, 시간이 지나면 결국 일관된 상태로 수렴
• NoSQL에서 자주 사용되는 개념 (예: DynamoDB, Cassandra)
• **BASE 원칙 (Basically Available, Soft state, Eventually consistent)**과 연결됨

 

 

CI / CD 고급

 

JAVA + Kustomize + Kubernetes

 

Kustomize? → 쿠버네티스(Kubernetes)의 리소스 정의 파일들을 환경별로 유연하게 관리할 수 있도록 도와주는 YAML 패치 도구

• 변경되는 환경마다 yml 파일을 패치할 수 있게 해줌
• Kustomize는 환경별 차이를 "패치(Patch)"로 관리
• 특히 GitOps나 ArgoCD 같은 CD 툴과의 연계에 강력

 

 

HPA(Horizontal Pod Auto-scaler)

 

HPA: 쿠버네티스에서 CPU 사용률 등 리소스 사용량에 따라 Pod 개수를 자동으로 조절해주는 기능

 

• 사용자가 갑자기 많아져 CPU 사용률이 급등하면, 기존 Pod들이 과부하 상태에 빠짐
  → 자동으로 Pod를 늘려 부하 분산
• 반대로 유휴 상태면 Pod를 줄여서 리소스 낭비 방지

 

주기적으로 다음과 같은 계산:

현재 전체 Pod의 평균 CPU 사용률 vs Target 사용률
→ 필요한 Pod 수 계산

→ QPS(Query Per Second) 같은 메트릭도 함께 고려

 

• QPS(Query Per Second)
• 위와 같은 상태면 Pod를 4개를 맞추기 위해 1개를 더 늘림