[대규모 시스템 설계 기초] 3장, 4장

으어 스터디 하다가 아파서 버티다가 마지막에 못듣고 나와버렸다............ ㅠㅠㅠ 일단 스터디한 부분까지 정리!

설계 계산 해보기

TPS는 Transactions Per Second에 줄임말이다. 

초당 처리되는 트랜잭션 수를 의미한다. Read TPS와 Write TPS를 사용하여 유저 수와 기간에 따른 데이터 량을 계산 하는 방법을 알아보쟈~

TPS 관련 글: https://docs.whatap.io/en/best-practice-guides/about-apm-dashboard

❓ 30일동안 얼만큼의 데이터가 쌓일까  ❓
READ TPS: 100
WRITE TPS: 10
유저: 1000명

1초 동안의 총 트랜잭션 수

총 트랜잭션 수는 유저 수에 TPS를 곱한다.

• Read 트랜잭션 수/초 = 100 * 1,000 = 100,000
• Write 트랜잭션 수/초 = 10 * 1,000 = 10,000

1일 동안의 총 트랜잭션 수

1일 = 86,400초(24시간 기준)

• Read 트랜잭션 수/일 = 100,000 * 86,400 = 8,640,000,000
• Write 트랜잭션 수/일 = 10,000 * 86,400 = 864,000,000

7일 동안의 총 트랜잭션 수

7일 = 86,400 * 7 = 604,800초

 

• Read 트랜잭션 수/7일 = 100,000×604,800=60,480,000,00
• Write 트랜잭션 수/7일 = 10,000×604,800=6,048,000,000

30일 동안의 총 트랜잭션 수

30일 = 86,400 * 30 = 2,592,000초

• Read 트랜잭션 수/30일 = 100,000 * 2,592,000 = 259,200,000,000
• Write 트랜잭션 수/30일 = 10,000 * 2,592,000 = 25,920,000,000

데이터 크기 계산

각 트랜잭션당 데이터 크기를 알고 있다면 곱해서 총 데이터량을 구할 수 있다.

Write 1건 = 1KB 

-> 864,000,000 * 1KB = 864GB/일

---

Kafka 에서 폴링을 사용하는 이유

 

• Consumer 제어 및 처리 속도 조절
  • Consumer 가 가져오는 메시지의 수와 속도를 조절할 수 있다.
  • Push 방식은 메시지가 Consumer 의 처리 속도를 초과할 때 과부화를 유발할 수 있다. Polling을 통해 Consumer 는 자신이 처리 가능한 만큼만 데이터를 가져올 수 있다.
• 백프레셔(Backpressure) 관리
  • Consumer 가 처리 속도가 느릴 경우 브로커에 데이터를 과도하게 전달하지 않도록 설계되어있다.
  • Pull 방식은 Consumer 주도로 메시지를 가져오기 때문에 Consumer 의 처리 능력에 따라 유연하게 작동한다.
• 컨슈머 그룹과 리밸런싱 지원
  • Kafka는 컨슈머 그룹을 통해 파티션을 여러 Consumer 에게 분배한다. Polling을 사용하면 리밸런싱 중 Consumer 가 메시지를 요청하지 않아 데이터 손실을 방지할 수 있다.
• 정기적인 하트비트❤️(Heartbeat)
  • Consumer 가 메시지를 Polling할 때 하트비트❤️ 신호가 함께 전송되어 브로커가 Consumer 를 활성 상태로 인식 한다.
  • Consumer 가 일정 시간 동안 Polling하지 않으면 세션 타임아웃이 발생하고 리밸런싱이 진행된다.
• 오프셋(Offset)관리
  • Polling 과정에서 Consumer는 가져온 메시지의 오프셋(읽은 위치)을 기록하거나 커밋한다.
  • 이 매커니즘은 메시지 재처리 또는 중복 방지를 용이하게 한다.

Kafka Polling의 구조적인 동작 원리

1. Consumer Group
   • Consumer는 컨슈머 그룹에 속하며, 각 Consumer는 Kafka의 특정 파티션을 할당 받아 메시지를 처리한다.
   • 한 파티션은 동시에 하나의 Consumer만 처리할 수 있다.
2. Poll 호출
   • Consumer가 poll() 메서드를 호출하면, 브로커에서 메시지를 가져온다.
   • 호출 시 최대 데이터 크기(예: max.poll.records)나 타임아웃 등 설정에 따라 데이터를 가져온다.
3. 메시지 처리
   • 가져온 메시지는 Consumer가 처리한다. 처리 방식은 애플리케이션 요구에 따라 다르다.
   • 메시지 처리 중 오류가 발생할 경우 메시지를 재처리할 수 있도록 오프셋 관리를 수행한다.
4. 오프셋 관리
   • Consumer가 메시지를 처리한 후, 읽은 위치(오프셋)를 Kafka에 커밋한다.
   • 자동 커밋: enable.auto.commit-true로 설정 시 주기적으로 커밋.
   • 수동 커밋: Consumer가 직접 commitSync 또는 commitAsync를 호출하여 커밋.
5. 하트비트❤️ 유지
   1. 폴링 과정에서 Consumer는 브로커와 세션을 유지하기 위해 하트비트❤️를 전송한다.
   2. 일정 시간(session.timeout.ms)동안 폴링이 없으면, 브로커는 Consumer가 비활성화 되었다고 판단하여 리밸런싱을 실행한다.
6. 리밸런싱
   • Consumer 가 그룹에 추가되거나 제거되면, 파티션을 다시 배분한다.
   • 이 과정은 데이터 손실을 방지하고, 처리 효율성을 높이는 데 중요하다.

---

로드밸런싱 확장 방법 (LB의 한계)

LB 확장 방법

1. Scale-Up (Vertical Scaling)
   • 방법: 로드 밸런서 또는 서버의 성능(예: CPU, 메모리)을 업그레이드.
   • 장점:
     • 간단하며 시스템 변경이 적다.
   • 단점:
     • 하드웨어 성능의 물리적 한계에 도달하면 더 이상 확장 불가.
2. Scale-Out (Horizontal Scaling)
   • 방법: 서버나 로드 밸런서를 여러 대 추가하여 트래픽을 분산.
   • 장점:
     • 무한에 가까운 확장 가능.
     • 단일 장애 지점(Single Point of Failure, SPOF)을 줄임.
   • 단점:
     • 관리 복잡도 증가.
     • 클러스터링 또는 트래픽 분산 전략 필요.

로그 밸런싱의 한계

로드 밸런서는 단일 서버 성능에 대한 병목을 해소할 수 있지만, 자체적으로 한계를 가진다.

1. 단일 장애 지점(SPOF)
   • 단일 로드 밸런서가 고장나면 전체 시스템에 영향을 미친다.
     • 해결책: 이중화(Failover) 또는 클러스터링
2. 글로벌 트래픽 관리 부족
   • 단일 로드 밸런서는 단일 지역의 서버 트래픽만 관리
     • 글로벌 사용자 분산은 처리하지 못함.
     • 해결책: GSLB 사용
3. 동적 트래픽 패턴 대응 부족
   • 트래픽 패턴이 실시간으로 변할 경우, 기존 로드 밸런싱 정책으로 최적 분산이 어려움.
4. 지리적 분산의 어려움
   • 데이터 센터가 여러 지역에 분산된 경우, 단일 로드 밸런서로 모든 요청을 처리하기 힘듦.

GSLB (Global Server Load Balancer) 란?

GSLB는 여러 지역에 분산된 데이터 센터 간의 트래픽을 효율적으로 관리하고 분산시키기 위해 사용되는 로드 밸런싱 기술이다.

GSLB의 주요 기능

1. 지역 기반 라우팅
   • 사용자의 위치에 따라 가장 가까운 서버로 트래픽을 전달하여 지연(latency)을 최소화 한다.
   • 예: 아시아 사용자는 아시아 서버로, 유럽 사용자는 유럽 서버로.
2. 장애 복구 (Disaster Recovery)
   • 특정 지역 데이터 센터가 다운되면, 트래픽을 자동으로 다른 지역으로 전환
3. 부하 분산
   • 전 세계적으로 트래픽을 균등하게 분산하여 특정 서버나 지역의 과부화를 방지.
4. DNS 기반 트래픽 분산
   • GSLB는 주로 DNS를 사용하여 클라이언트의 요청을 가장 적합한 서버로 라우팅.
5. 지능형 트래픽 라우팅
   • 서버상태, 네트워크 상태, 트래픽 부하 등을 기준으로 동적으로 라우팅

GSLB의 작동 원리

• 사용자가 도메인 이름을 요청하면 DNS 쿼리가 GSLB로 전달된다.
• GSLB는 사용자의 위치(IP 지리 정보)와 현재 서버 상태를 기반으로 가장 적합한 서버(데이터 센터)를 선택한다.
• 선택된 서버의 IP주소를 사용자에게 반환하여 트래픽을 해당 서버로 전달 한다.

---

GSLB와 일반 로드 밸런서의 차이점

특징	일반 LB	GSLB
관리 범위	단일 데이터 센터 내 서버	여러 데이터 센터 간
라우팅 기준	서버 상태, 트래픽 부하	지역, 서버 상태, 네트워크 상태
장애 복구	단일 데이터 센터 내 장애 연결	글로벌 데이터 센터 복구 지원
사용 기술	L4/L7 (TCP, HTTP 등)	주로 DNS 기반

---

스터디할때 아래와 같은 구조로 설계를 하신 분이 있었다.

좋은 설계라고 하시길래 좀더 알아보았다.

이 설계는 DNS와 Load Balancer(LB)를 활용해 트래픽을 효율적으로 분산시키고, 시스템의 확장성과 가용성을 높이는 구조이다.

구조 살펴보기

1. DNS
   • 사용자의 요청이 처음 들어오면 DNS가 요청을 처리한다.
   • DNS는 사용자의 위치(지리적 정보)나 부하 상태를 기반으로 여러 Load Balancer(LB)중 하나를 선택하여 트래픽을 전달한다.
2. Load Balancer(LB)
   • DNS에서 전달받은 요청을 각각의 LB로 보낸다.
   • 각 LB는 자신의 영역(예: 특정 데이터 센터 또는 서버 그룹) 내에서 트래픽을 서버로 분산시킨다.
3. 웹 서버(WAS/W3)
   • LB에서 받은 요청을 처리한다.
   • 웹 서버는 내부적으로 Pub/Sub 또는 Message Broker와 같은 백엔드 시스템과 연계하여 요청을 처리하거나 메시지를 큐에 넣는다.

이 설계의 장점

1. 확장성과 유연성 확보
   • LB의 수를 증가시키거나 지역별 데이터 센터를 추가하여 시스템을 쉽게 확장할 수 있다.
2. 고가용성
   • DNS와 LB의 이중화로 인해 한 구성 요소가 실패하더라도 서비스가 중단되지 않는다.
3. 지연 시간 최소화
   • DNS를 통해 사용자가 가장 가까운 데이터 센터나 서버로 연결되어 응답 속도를 최적화 한다.
4. 다양한 트래픽 처리 방식
   • Pub/Sub과 Message Broker를 추가로 사용하여 동기와 비동기 작업을 나누고 트래픽 처리 효율성을 높인다.

이 설계의 잠재적 단점

1. DNS 캐싱
   • 사용자 쪽에서 DNS를 캐싱하면 업데이트된 LB정보를 즉시 반영하지 못할 수 있다.
   • 해결책: 짧은 TTL(Time-To-Live) 설정.
2. DNS 장애
   • DNS 자체가 실패하면 모든 트래픽 라우팅에 문제가 생길 수 있다.
   • 해결책: DNS 서비스 이중화(예: 클라우드 기반 DNS 서비스 사용).

---

Redis 펍섭

Pub/Sub의 단점

1. 비영구적
   • 메시지가 발행되었을 때, 구독자가 연결되어 있지 않으면 해당 메시지는 사라진다.
   • 구독자는 메시지를 놓칠 수 있다. 이를 해결하려면 메시지를 저장할 수 있는 Redis Streams나 Message Broker(Kafka) 같은 대안이 필요하다.
2. 스케일링의 한계
   • Redis의 Pub/Sub은 단일 인스턴스에서 동작하기 때문에, 클러스터링된 환경에서는 메시지가 특정 샤드에서만 전달되 수 있다. 따라서 여러 샤드에서 동작하는 분산 시스템에는 적합하지 않을 수 있다.
3. 구독자 관리 부족
   • 특정 구독자의 상태를 Redis에서 관리하지 않는다.
   • 누가 구독 중인지 또는 어떤 채널이 얼마나 구독되고 있는지에 대한 메타데이터를 관리할 수 없다.
4. 대량 메시지 처리
   • 많은 구독자와 고빈도의 메시지가 발생하면 Redis 인스턴스에 부하가 증가한다.
   • 이로인해 다른 Redis 작업(예: 데이터베이스 동작)에 성능 저하가 발생할 수 있다.

---

아~  뭐 많이 공부했는데 좀더 봐야겠다 3장 4장이 좀 어려웠다 생각해본적 없는 시스템 설계여서 받아드리는데 시간이 좀 걸릴 꺼같다.... 어색행

 

** 그냥 하루하루 개인 공부한 것을 끄적 거리는 공간입니다.

이곳 저곳에서 구글링한 것과 강의 들은 내용이 정리가 되었습니다.

그림들은 그림밑에 출처표시를 해놓았습니다.

문제가 될시 말씀해주시면 해당 부분은 삭제 하도록하겠습니다. **