[대규모 시스템 설계 기초] 1장, 2장

스터디에 참여하게 되었다...! 어렵다...! 하지만 해야지 뭐 어케

1장. 사용자 수에 따른 규모 확장성

---

로드 밸런서(Load Balancer)

https://www.appviewx.com/education-center/load-balancer-and-types/

1. 동작 원리 및 구현

로드 밸런서는 여러 서버에 들어오는 네트워크 트래픽을 분산시켜 서버 과부하를 방지한다.

• 요청 분배: 클라이언트 요청을 받아 백엔드 서버 중 하나로 전달한다.
• 방식:
  • 라운드 로빈: 순서대로 서버에 요청을 분배.
  • 가중치 기반: 성능이 높은 서버에 더 많은 요청 할당.
  • 최소 연결: 현재 연결 수가 가장 적은 서버에 요청 전달.

2. 장단점 사용 이유

• 장점:
  • 시스템 가용성 및 확장성 향상.
  • 특정 서버 과부하 방지.
  • 장애 서버 자동 감지 및 제외.
• 단점:
  • 초기 설정 및 유지보수 필요.
  • 로드 밸런서 자체가 장애 지점이 될 수 있음.
• 사용 이유: 많은 사용자가 동시에 접속하는 서비스에서 성능을 유지하기 위해 사용한다.

⚠️로드 밸런서 자체가 장애 지점(Single Point of Failure, SPOF)이 되는 문제를 해결하기 위한 방안.
1. 문제 원인
🛑하드웨어 문제: 전원 장애, 네트워크 인터페이스 장애, 스토리지 장애
🛑소프트웨어 문제: 로드밸런서 소프트웨어 버그, 메모리 누수, CPU 과부하
🛑네트워크 문제: 네트워크 장애, DNS 문제, 라우틴 오류
🛑트래픽 초과: DDoS 공격, 용량 한계 초과
🛑구성 및 관리 문제: 잘못된 설정, 업데이트 실패, 인증서 문제
🛑로드 밸런서 자체가 SPOF로 설계된 경우: 이중화(HA)가 없을때
🛑물리적 재해

2. 해결 방법
✅로드 밸런서 이중화
방법: 두 개 이상의 로드 밸런서를 설정하여 하나가 장애가 발생한다면 다른 하나가 트래픽을 처리하도록 만든다.
- 액티브-액티브(Active-Active): 두 로드 밸런서가 동시에 작동하여 트래픽을 분산 처리.
- 액티브-패시브(Active-Passive): 한 로드 밸런서가 주로 작동하고, 다른 하나는 대기 상태에서 장애시 동작.
구현 기술
- Keepalived: 가상 IP (VIP)를 사용해 액티브-패시브 구성을 지원.
- Pacemaker: 클러스터 관리 및 장애 복구를 자동화.
✅DNS 기반 로드 밸런싱
방법: DNS 레코드에 여러 로드 밸런서의 IP를 등록하여 장애가 발생한 로드 밸런서를 자동으로 제외.
- Round-Robin DNS: 순차적으로 여러 IP를 반환.
- Health Check와 결합: DNS 서비스가 로드 밸런서의 상태를 주기적으로 체크하여 가용한 IP만 반환
✅실시간 모니터링와 알림 시스템
방법: 로드 밸런서를 실시간으로 모니터링하여 장애를 조기에 감지하고 대응.
- 도구: Prometheus + Grafana, CloudWatch, Datado 등.

등이 있다!

데이터베이스 다중화(Database Replication/Clustering)

https://www.linkedin.com/pulse/database-scaling-methods-clustering-replication-whataplabs/

1. 동작 원리 및 구현

• 복제(Replication): 데이터를 여러 데이터베이스에 복사하여 데이터 읽기 작업 부하를 분산한다.
  • 마스터-슬레이브: 마스터 DB에 쓰기, 슬레이브 DB에서 읽기.
  • 마스터-마스터: 두 마스터 DB에서 쓰기와 읽기 모두 가능.
• 클러스터링(Clustering): 여러 데이터베이스가 하나의 시스템 처럼 동작.

⚠️데이터베이스 다중화에서 마스터와 슬레이브의 역할 및 동작 원리
1. 마스터와 슬레이브의 역할
마스터 데이터베이스:
- 모든 쓰기 작업(INSERT, UPDATE, DELETE 등)을 처리한다.
- 데이터가 업데이트 되면, 해당 변경 사항을 슬레이브 데이터베디으세 복제(replication) 한다.
슬레이브 데이터베이스
- 마스터로부터 복제된 데이터를 유지하며, 읽기 작업(SELECT)을 처리한다.
- 다수의 슬레이브를 두어 읽기 부하를 분산할 수 있다.

2. 동작 원리(Replication)
1️⃣마스터 데이터베이스의 변경 감지:
- 마스터에서 데이터 변경(쓰기 작업)이 발생하면, 변경 사항을 변경 로드(Write-Ahead Log, WAL) 또는 바이너리 로그(Binary Log)로 기록한다.
2️⃣슬레이브 복제 전송
- 슬레이브는 마스터의 로그를 읽어들여 해당 변경 사항을 적용한다.
3️⃣ 슬레이브의 데이터 갱신
- 슬레이브는 마스터와 동일한 데이터 상태를 유지하도록 갱신을 완료한다.
4️⃣ 읽기 작업 분산
- 애플리케이션에서 슬레이브로 읽기 요청을 보내고, 쓰기 작업은 마스터로 보낸다.

3. 장점과 주의사항
장점
- 읽기 성능 향상: 읽기 작업을 슬레이브에 분산
- 장애 복구: 마스터가 다운되면 스렐이브를 승격(promote)하여 대체 가능
주의 사항
- 복제 지연 문제: 마스터에서 변경된 데이터가 슬레이브에 즉시 반영되지 않을 수 있음.
- 일관성 문제: 데이터 읽기 시 슬레이브의 데이터가 최신이 아닐 수 있음.

2. 장단점 사용이유

• 장점:
  • 읽기 작업 성능 향상.
  • 장애 복구가 가능하여 높은 가용성 제공.
• 단점:
  • 복제 지연 문제.
  • 복잡한 설정.
• 사용 이유: 트래픽이 많은 애플리케이션에서 데이터 읽기 성능과 시스템 안정성을 높이기 위해 사용한다.

CDN(Content Delivery Network) 

1. 동작 원리 및 구현

CDN은 사용자와 가까운 서버에 콘텐츠를 캐싱하여 빠르게 제공한다.

• 요청 처리: 사용자의 요청이 CDN서버(엣지 서버)로 전송되고, 캐싱된 콘텐츠가 반환된다.
• 구성 요서:
  • 오리진 서버: 원본 콘텐츠가 저장된 서버.
  • 엣지 서버: 사용자와 가까운 캐시 서버.

2. 장단점 사용이유

• 장점:
  • 빠른 콘텐츠 전달로 사용자 경험 개선
  • 오리진 서버의 트래픽 감소.
  • DDoS 공격 완화.
• 단점:
  • 캐시 갱신 지연 가능.
  • 서비스 비용 추가.
• 사용 이유: 전 세계 사용자에게 콘텐츠를 신속히 제공하고, 트래픽을 분산하기 위해.

2장. 개략적인 규모 추정

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는데 필요한 기본기에 능숙해야 한다.

2제곱수

2의 x 제곱	근사치	이름	축약형
10	1천(thousand)	1킬로바이트(Kilobyte)	1KB
20	1백만(million)	1메가바이트(Megabyte)	1MB
30	10억(billion)	1기가바이트(Gigabyte)	1GB
40	1조(trillion)	1테라바이트(Terabyte)	1TB
50	1000조(quadrillion)	1페타바이트(Petabyte)	1PB

---

생각해보기

서버를 확장하는 방법에는 무엇이 있을까? 각 방법의 장단점에 대해서 설명해보자?

1. 스케일 업(Scale Up)
   • 개념: 기존의 서버를 더 강력한 하드웨어로 업그레이드 하거나 추가적인 자원을 제공하여 성능을 높이는 방식.
   • 장점:
     • 구조적으로 간단하며 변경 작업이 적음.
     • 응용 프로그램이나 데이터베이스 수정이 필요 없음.
     • 초기 비용이 적게 듬
   • 단점:
     • 업그레이드의 한계가 존재(CPU 코어, 메모리 용량 등 물리적 한계).
     • 단일 장애 지점(Single Point of Failure, SPOF) 문제 해결 불가.
     • 고성능 하드웨어 비용이 매우 높아질 수 있음.
2. 스케일 아웃(Scale Out)
   • 개념: 여러 대의 서버를 추가하여 작업을 분산 처리하는 방식.
   • 장점:
     • 수평적 확장이 가능하며, 이론적으로 무한 확장이 가능.
     • 특정 서버에 장애가 발생해도 전체 서비스 중단을 막을 수 있음.
     • 개별 서버는 저비용 하드웨어로 구성 가능.
   • 단점:
     • 인프라 관리 복잡도 증가.
     • 데이터 동기화 및 분산처리 로직 필요.
     • 초기에는 설정이 더 복잡할 수 있음(로드 밸런서, 클러스터링 등).

수직, 수평 확장.. 그럼 언제해?

• 작은 서비스: 스케일 업이 단순하고 비용 효율적.
• 성장 중인 서비스: 스케일 아웃으로 확장성 확보.
• 대규모 서비스: 스케일 아웃을 기본으로 하고, 필요에 따라 CDN, 데이터베이스 샤딩 등을 추가 설계.

NoSQL은 왜 빠를까?

1. 스키마리스 (Schema-less)
   • 데이터베이스 설계에서 고정된 스키마가 필요 없으므로 데이터 삽입 및 읽기가 빠름.
2. 수평 확장에 최적화
   • NoSQL은 설계 단계부터 분산 환경을 염두에 둔 아키텍처를 사용.
   • 수많은 노드에 데이터를 분산 저장하며, 병렬 처리를 통해 속도를 높임.
3. 단순 데이터 모델
   • 관계형 데이터베이스(RDBMS)는 JOIN이나 복잡한 쿼리를 사용하지만, NoSQL은 키-값 조회, 문서 겁색 등 단순 작업으로 처리.
4. 인덱스 최적화
   • NoSQL 데이터베이스(예: MongoDB)는 읽기 작업을 위한 효율적인 인덱스 구조를 제공.
5. CAP 이론에서의 선택
   • NoSQL은 일관성(Consistency)보다 가용성(Availability)과 분산 처리(Partition Tolerance)를 우선.
   • 즉시 일관성을 포기하고 속도를 높이는 경우가 많음.

---

 

 

조아써 오늘도 지식이 늘었다! 구조파악하고 이해하고! 공부하고!! 신난다!

 

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

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

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

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