대규모 시스템 설계 기초 스터디 1회차 (챕터 1 ~ 5장)

 

요새 가상 면접 사례로 배우는 대규모 시스템 설계 기초 스터디를 하고 있다

 

배운 점이 많아서 정리를 해보았다!

 

 

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

수평적 확장을 하는 이유는

수직적 확장에는 한계가 있기 때문이다

• 성능 (CPU, Memory)
• 장애시 대응 문제

DB의 수평적 확장은 특별히 샤딩이라 한다

아래와 같은 문제들이 생긴다

• 재샤딩(resharding)
  • DB 추가
  • 불균형으로 샤드 키 재분배가 필요할때
• 유명인사(celebrity) 문제
• 조인
  • 비정규화로 하여 하나의 테이블에서 질의가 수행될 수 있도록 한다

메시지 큐

• 서비스 또는 서버 간 결합이 느슨해짐, 규모 확장성을 보장

2장: 개략적인 규모 추정

Log Scale

 

L1, L2 캐시 접근	1ns
뮤텍스 락 락/언락	100ns
RAM 접근	100ns
in 1Gbps (100MB) 네트워크 상에서 2KB 전송	10us
RAM 1MB 순차 읽기	250us
디스크 탐색 (순차인지 랜덤인지 표기X)	10ms
네트워크에서 1MB 순차 읽기	10ms
디스크에서 1MB 순차 읽기	30ms
캘리포니아와 네덜란드 한 패킷 왕복	150ms

[요약]

CPU 캐시 접근 → RAM 접근 : 100배

RAM 접근 → RAM 1MB 순차 읽기: 2500배

(1MB 순차 읽기) RAM → 디스크 : 100배 (120배)

 

레알 나으 에스큐엘 (Real My SQL)

항목 초당 연산 횟수

CPU	10억
DRAM	1억
SSD	10만
HDD	200

[요약]

DRAM과 SSD는 1000배 정도 차이

SSD와 HDD는 500배 정도 차이

성능 벤치마크

항목 초당 트랜잭션 처리 횟수

SSD	436
HDD	60

** ssd는 랜덤과 순차 I/O가 거의 없을 것으로 생각되지만 실제로는 그렇지 않다

위와 같은 이유로 대부분의 DBMS는 SSD를 영구 저장소로 채택함

그러나 HDD이더라도 데이터 버퍼 설정을 잘하면 차이를 거의 무마시킬 수 있음

 

 

https://d2.naver.com/helloworld/7005

 

플랜에 따른 순차/랜덤 IO

인덱스 레인지 스캔 → 랜덤 IO

풀 테이블 스캔 → 순차 IO

테이블의 어느 정도 이상의 레코드 읽으면 옵티마이저가 풀테이블 스캔으로 유도

장애 시간

가용률 연 장애 시간

99%	3.65일
99.9%	8.8시간
99.99%	53분
99.999%	5.3분
99.9999%	32초

 

3장: 효과적 면접을 위한 4단계 접근법 (생략)

부정적 신호(red flag): 설계의 순수성에 집착한 나머지 타협적 결정을 도외시하고

과도한 엔지니어링을 하고 마는 엔지니어들이 현업에도 많다

1단계: 문제 이해 및 설계 범위 확정

• 모호함을 없앤다

2단계: 개략적인 설계안 제시 및 동의 구하기

3단계: 상세 설계

4단계: 마무리

4장: 처리율 제한 장치의 설계

기본적으로 L7 기준으로 작성돼 있다고 한다

요청이 너무 많이 오면, HTTP 429 - Too Many Requests

처리율 장치의 기준

• 클라: (X) 오답 (쉽게 위변조 가능)
• 서버
• 미들웨어

 

로컬, 분산 캐시

 

	로컬 캐시	분산 캐시
정의	하나의 서버에서 관리되는 캐시	여러 서버에서 사용하는 공용 캐시
장점	네트워크 오버헤드가 없어 상대적으로 빠름 인프라를 고려하지 않아도 되기 때문에 간편함	같은 데이터를 공유할 수 있음 클러스트링되었을 때 fail over (내결함성)이 좋음
단점	데이터 공유 문제 (세션 등의 정보가 공유가 불가하다)	네트워크 오버헤드 생긴다 구현하기 복잡하다
예시	- 자바의 HashMap - ECache - Caffeine	- Redis - Memcached

 

 

캐시는 얼마나 비쌀까?

 

각각 서버용 RAM, M.2 SSD, NAS용 HDD 로 조사했다

 

	HDD	SSD	RAM
원/GB	46	139	2360
비율 (HDD에 대한)	1	3.02	51.3

 

SSD는 하드보다 3배 비싸고,

RAM은 SSD보다 17배 비싸고, HDD보다 51배 비싸다

 

 

HDD 가격

 

 

 

SSD 가격

 

 

 

RAM 가격

 

 

 

 

캐싱 전략

 read-through caching strategy

 

 

Cache-Aside

WAS와 Cache, Database가 모두 1:1 관계이다

1. 캐시에서 먼저 데이터를 찾고
   1. (있으면 반환한다)
2. 캐시에 없다면
   1. 데이터베이스에서 찾는다
   2. 찾고 애플리케이션에 반환 후
   3. 애플리케이션을 거쳐 캐시에 쓰기한다

장점

대규모 읽기에 적합

단점

캐시 DB간 일관성이 없을 수 있음

Read-Through Cache

: 읽기 주도형 캐시 전략

 

책에서 소개한 예시이다 

 

연결 리스트 처럼

Applicatio ↔ Cache ↔ Databse

이런 순서를 가지고 데이터를 처리한다

1. 캐시에 있으면 데이터를 찾고 반환한다
2. 없다면
   1. 캐시가 DB에 요청한다
   2. 캐시에 저장후 반환한다

장점

대규모 읽기에 적합

단점

캐시 DB간 일관성이 없을 수 있음

Write-Through Cache

Read-Through의 Write 버전

애당초 쓸때부터 캐싱한다

1. App 캐시에 쓰기 요청
2. DB에 동시에 같이 쓴다
   1. (동기적인 쓰기)

장점

캐시와 DB가 일관성 유지

TTL (expire) 무효화 작업을 하지 않아도 됨

단점

쓰기 지연 발생

Write-Back | Wrtie-Behind

Write-Through와 다른 것은 지연 쓰기이다. 한 번에 모았다가 배치성으로 쓰기 작업을 한다

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

 

 

용어 정리

failover: 장애 복구

redundancy: 다중화

 

Fault Tolerance 내결함성

장애에 견딜 수 있는 정도

 

Relisiency

장애가 있을 때 회복하는 능력

스스로 회복할 수 있음

아직 일어나지 않은 장애에 대해서도 대응할 수 있어야 함

 

 

키워드

확실히 사람들과 같이하면서 얻어가는 키워드들이 많다!

 

NoSQL

채팅 내역 등은 이걸로 관리하는게 좋다

• 이미지 OX
• 전화번호부 OX
• 로그성 데이터

정형화가 좀 덜 돼 있는것들…

(12장) 읽어보면 된다

이미지, 연락처 등의 정보를 전송할 수있다

 

수직적 확장

배치서버같은 경우 → 수직적먼저 …

• 셰드 락?…
• == 스케줄 락

왜냐하면 동시성 문제가 빈번하게 생길수있다

 

 

DB에 PK가 없을 경우

500만개 + 인덱스가 없는을때 update 쿼리 발생하면

레플리케이션 할때 PK가 없으면 복제가 안넘어가진다

 

PK가 없으면 mysql 엔진이 혼자 생성하고 개발자는 알 수 없다

-> 꼭 걸어야 한다

 

 

레디스 페이지 교체 알고리즘

LRU, LFU 등 보통은 LRU를 사용한다

 

 

CDN 지역 성능

ELK

CDC를 어떻게 하느냐에 따라 ...

 

 

샤딩

조인이 가능하다 → 샤드1이 늦어지면 나머지 샤드들 늦어짐

트랜잭션 문제 → 라운드로빈…

레플리케이션

Aggregation 으로 조회

(아이디값 분산)→ 스노우 플레이크 방식

NginX는 압축을 해서 응답을 할 수 있다 → gzip

 

 

MSA 설계 질문

로컬 트랜잭션 + 보상트랜잭션

순차적 요청/응답 → 사각형 패턴

 

처리 제한 알고리즘 종류들

 

토큰 버킷

단점: 튜닝어렵 → 시나리오 테스트

이 시간안에 동일 요청안에 요청 못옴 → 그 시간안에 토큰 공급

 

누출 버킷

→ 티켓팅

 

고정 윈도

→ 못써

 

이동 윈도

→ 자주써

 

데드레터

(카프카 등) 나중에 재시도할때 사용한다…

 

DLQ

메세징 큐…

프로 → 브로 → 컨슈

아예 전송이안될때… 내부적으로 보관한다

 

안정해시 가상노드

레디스 기준 16천개

재배치.. 문제

 

 

참고

 

https://www.ufried.com/blog/resilience_vs_fault_tolerance/

https://gist.github.com/Nj-kol/d5211ed218557a6e398212838dffa3e9

Difference between Fault tolerance and Resiliency