[시스템디자인&인터뷰] 1.확장 가능한 시스템 설계

시스템 디자인 및 디자인 

목적 : 기업의 비즈니스 모델에 효율적인 아키텍처를 고안하기 위한 능력 배양 

 

목차

1. 확장 가능한 시스템 설계

2. 알고리즘과 데이터 구조 

3. 빅데이터를 활용한 작업

4. 설계 인터뷰 전략 

5. 모의 설계 인터뷰 

7. 일반적인 기술 인터뷰 팁 

 

ref) 

http://media.sundog-soft.com/SystemDesign/SystemDesign.pdf 

 

1. 확장 가능한 시스템 설계

- 확장성 : 기발한 알고리즘으로 성능 vs 수평적 스케일링으로 페타바이트 단위 데이터 처리 

 

1.1 수평적 스케일링 vs 수직 스케일링 

 

1. 싱글 서버 디자인

- 비상용 용도의 취미 개발 서버로 장애시간이 길어도 크게 문제없는 경우 하나의 컴퓨터에 HTTP서버, DB를 같이 구동  

- 단점 : 서버가 단일 장애점 

- 장애 극복을 위해서는, DNS 엔트리를 바꾸고 백업된 데이터를 복구한 새로운 싱글 서버를 바라보도록 해야 한다. 

 

2. 싱글 서버 디자인 > DB를 분리

여전히 단일 고장점이지만, 리소스 분산의 시작으로 본다. 

 

3. Vertical Scaling

- CPU, RAM 등의 하드웨어 성능을 올린다.

- 장점 : 관리하는 게 리소스양 조절이 다이며, 유지보수 간편하다.  ( 여전히 취미용 서버에서 헤비 한 작업할 때 리소스를 늘려보는 정도 )

- 단점 : 성능 업그레이드에 한계가 언젠가 반드시 온다.  

 

4. Horizontal Scaling

LB : 공편하게 각 서버로 부하를 분산 ( 전략 : 라운드 로빈, 파티셔닝, 서버의 idle 리소스에 따른 분배 )

HTTP Server : stateless 유지 

DB : 아직 스케일링을 하지 않았지만, 서버의 상태를 한 곳에 저장한다. 

 

2. DB 장애 극복 전략 

 

서버의 위치는 중요하지 않다, 애초에 다운되는 경우를 고려해서 아키텍처를 설계한다. 

- 가용영역 : 대륙 안에 어쨌든 서버가 위치하도록 보장 

- 서버리스 : 가용영역조차도 중요하지 않다, 서버가 구동되기만 하면 된다. 

 

1. DB 장애극복 - Cold Standby

주기적으로 백업(S3 등)을 수행한다. 장애가 발생했을 때 복구 절차에 들어간다. 

 

단점 :

- 다운시간이 증가한다. ( 새 서버 생성 > 백업을 복원 , 데이터량에 비례 > 서비스 이동 ) 며칠 소모 될 수 있음.

- 일부 데이터 손실이 존재

 

장점 :

- 저렴

 

2. DB 장애극복 -Warm Standby

주기적 백업 대신, 복사본( Replication ) 을 만든다. 

 

단점 :

- 여전히 수직 스케일링을 수행한 것이다. 

- 예열된 복사본을 만들어야 하므로, 복제 DB에서 리소스 소모가 발생 

 

장점 :

- 작은 시간동안 데이터 손실이 일어날 순 있다.

- 일시적으로 다운되고, 빠르게 복구가 가능하다. 

 

2. DB 장애극복 - Hot Standby

애초에 두개의 데이터 베이스에 듀얼라이트를 수행. 수평적 스케일링에 가까워졌다. 

 

단점 :

- 복제 DB에서 리소스 소모가 발생

 

장점 :

- 2개의 DB에 동시에 쓰기, 읽기 수행이 가능. 그래서 하나의 DB가 장애가 나도 다운타임이 발생하지 않는다. 

 

 

 

3. 샤딩 데이터 베이스 / NoSQL 

DB 수평 스케일일 -  샤딩

라우터 : 클라이언트의 요청을 분산 

샤드(Shard) : 데이터 베이스의 수평 분할

샤드 백업 : 호스트 샤드의 다운에 대비 

예) MongoDB -  샤딩

App Server Process: 서버 프로세스는 Server Fleet에서 실행된다. 

mongos : 몽고스 프로세스는 트래픽 분산, 파티셔닝 스키마 관리

ConfigServer : 3대로 구성, 재시작한 Primary 서버에 파티셔닝 데이터를 제공

PRIMARY : 주 서버 , 샤드 안에서 라우터 역할

SECONDARY : 보조 노드, 주 서버를 선택하며 데이터 백업을 진행. 주 서버 다운 시 주 서버를 다시 선택

 

단점 

- 관리해야할 서버가 많다. 비용 및 유지보수 비용 높음

예) Cassandra -  샤딩

카산드라는 데이터를 다른 노드에 분할한다. 여기서 노드는 샤드라고 생각하면 된다. 

- 일부 노드는 다른 노드의 데이터의 복제본을 가져, 모든 노드가 기본 API 포인트이며 모두 최신 상태를 유지하도록 해야 한다.

- 데이터의 전파에 지연이 발생하여, 일관성을 포기한다. 

- 가용성 높으며, 단일 장애점을 해결한다. 

 

그래서, 데이터를 바로 쓰고 읽는 데까지 발생하는 지연이 괜찮은 경우에만 사용한다. 

NoSQL 샤딩 문제

리샤딩 문제 : 샤드를 다시 나눌 때 데이터의 재분배가 필요.

Hotspots 문제 : 특정 샤드에만 트래픽이 몰리는 경우 리샤드를 해야 한다. 

정규화 vs 비정규화

정규화

- 데이터의 중복을 최소화한다. 업데이트를 효과적으로 수행 

- 대신, 데이터의 조회를 여러번 후 합치는 과정에서 고객 경험이 저하될 수 있다. 

 

비정규화

- 데이터의 트래픽을 줄인다, 테이블 조회를 1번만 하도록 

- 대신, 데이터의 업데이트가 어려워 진다. 

 

정규화와 비정규화는 서비스에 따라 다르게 선택해야 한다. 

 

4. 데이터 레이크

데이터 레이크 : CSV, JSON 등 미가공상태의 대량의 데이터를 S3와 같은 버킷에 담아두는 것 

AWS Glue : 데이터 레이크에서 스키마를 만들어 준다.

AWS Athena : 데이터 레이크를 SQL 쿼리 할 수 있도록 도와줌

AWS Redshift : 분산 데이터 웨어하우스에 가까우며, Athena의 상위 역할 수행.

 

데이터를 일딴 넣고, 나중에 스키마와 쿼리를 찾는 방식의 접근법 

 

5. ACID 준수, CAP 정리

ACID

 

A 원자성 : 전체 트랜젝션이 성공하거나 실패 (롤백) 해야 한다. 

C 일관성 : 특정 필드는 음수가 절대 될 수 없음 등의 일관성, 그런 값이 들어간다면 롤백되어야 함

- CAP의 일관성과 다름을 체크 

I 격리성 : 진행 중인 트랜젝션은 다른 트랜젝션의 영향을 받지 않는다. 

D 지속성 : 한번 저장되면 변하지 않는다. 어떻게는 분산된 디스크에 저장해서 상태를 유지해야 함

 

CAP

C 일관성 : 방금 쓴 데이터를, 바로 읽을 수 있는가

A 가용성 : 단일 장애점이 있는지 여부 

P 분할-허용성  : 수평 스케일링을 쉽게 할 수 있는지 여부 

 

가용성과 일관성이 중요한 곳 : 소형 은행은 MySQL, Oracle 선택

일관성을 포기, 확장성과 가용성을 택한다면 : 카산드라 

 

현대 DB 에서는 가용성을 포기한다. 그 포기하는 것이 몇 초 정도의 다운타임을 가질 수 있는 단일 고장점이다. 

서버가 죽는 즉시, 시스템이 다시 만들어지는 수초 정도이다. 일관성과 확장성을 

 

6.  CAP 활용한 DB 선택

MongoDB 가용성 포기

- 주 서버 PRIMARY가 죽으면, 수 초 이내 서버가 다시 만들어져 그 자리를 차지하게 된다. 

카산드라 - 일관성 포기

 

7. 캐싱 기술

디스크를 직접 히트하는 것은 비싼 작업이다. 

캐시 레이어를 두고, 디스크 히트를 줄이도록 한다. 

쓰기보다 읽기가 많은 애플리케이션에 적합하다.

- 적절한 해시 함수를 통해 캐시서버를 히트하도록 웹서버에서 구현한다. 

- 쓰기가 일어나면, 캐시 무효화를 진행한다. 

 

캐시 만료 정책 : 너무 캐시가 오래남지 않도록 적절하게 유지하는 것이 중요. 

 

핫스폿 문제 : 더욱 지능적인 캐시 설루션은, 핫스폿 문제도 해결해줘야 한다. 

- 유명인 전용 서버를 두거나, 유명인은 모든 캐시서버에 분산 저장 한다.

 

콜드 스타트 문제 : 처음에 캐시가 없을 때, 수많은 디스크 히트가 발생하여 DB가 다운될 수 있다.

- 시스템을 베포하기 전에, 임의적인 트래픽으로 캐시층에 데이터가 쌓이도록 warmup 한다.

- 백로그 트래픽을 인위적으로 요청하여 캐시층을 쌓는다. 

 

8. 캐싱 사용을 위한 Eviction Policy

LRU 캐시 설계 : 최근에 사용된 것을 캐시 한다. 히트가 안된 캐시는 리스트의 끝으로 이동하며, 캐시 공간이 차면 끝에서부터 제거한다. 

- 위 그림에서 해시맵은 데이터의 위치를 가르키고, 히트가 된다면 캐시의 Head 쪽으로 이동하게 된다.

- 캐시가 충분히 큰 경우, 대규모 환경에서도 잘 작동된다. 

 

LFU 캐시 설계: 최소사용빈도 알고리즘

- 캐시가 작은 경우 특정 타임윈도우 동안 자주 사용되는 캐시를 남기는 게 좋은 전략이다. 

 

FIFO : 선입 선출, 단순하게 가장 먼저 들어간것이 공간을 먼저 내준다.  

 

최근에는 레디스가 자주 사용. 맴캐시드는 단순한 key-value 저장소이다. 

 

9. 콘텐츠 분산 네트워크 CDN

글로벌 서비스를 지원해야한다면, CDN은 필수이다. 

전 세계의 에지 로케이션의 서버로 정적파일들을 베포 한다. 

- 단점은, 가격이 비싸다. 

10. 복원력 설계

시스템이 정지되었을때 큰 비용이 발생한다. 복원력이 있는 시스템을 설계하는 것이 필요하다. 

- 자연재해 ( 허리케인, 정전 )에 의한 복구 필요 

- CPU, RAM 등 물리적 장비의 노화 

- 해저 네트워크의 장애 등등

위치기반 라우팅 ( Geo-Routing )

NA 전체가 장애가 발생하더라도, EU 의 서비스 플릿으로 라우팅 하여 서비스를 제공

- 다른 지역이 완전한 장애가 발생함을 가정해서, 한 지역에서 트래픽을 감당할 수 있도록 리소스를 준비해야 한다.

- 오버 프로비저닝 비용을 감당할 만큼의 서비스인지 확인하자. 

11. 분산 스토리지 솔루션

대규모 시스템 설계에는, 대규모 데이터 저장도 수반된다. 

- 비정형데이터 CSV, JSON, 정적리소스의 빅데이터 저장

- 확장성, 가용성, 보안, 데이터 검색에 대한 서비스가 제공되어야 한다. 

- 높은 내구성도 중요하다. S3는 99.999..% 의 내구성을 제공해 준다. 

 

서비스 수준 협약 ( SLA )

내구성에 대한 약속과 속도에 대한 약속을 SLA에 명세한다.

- 만약 이 확률을 어기게 된다면 모니터링 얼럿이 발생한다. 

- 레이턴시가 100ms 이내에 99.9% 제공을 못하게 되는 상황이 온다는 등. 

 

99(2개)와 999999(6개)의 큰 차이 

- 99% 가용성이라면, 1년에 3.65일 동안은 다운되는 것이다.

- 99.9999% 라면, 다운타임이 30초라는 계산이 되고 이는 허용 가능하다. 

 

- cloud : S3, Google Cloud Storage, Azue,

- on-premise : Hadoop HDFS ( 셀프 호스팅 가능 ) 

- 소비자 중심의 저장 설루션 : GoogleDrive, OneDrive 등은 시스템 디자인에 적합하지 않다. 

12. 하둡 분산 파일 시스템 

HDFS 예시

 

HDFS : 하둡 분산 파일 시스템 

클라이언트 : 데이터를 요청하는 노드 

네임 노드 : 마스터 노드의 역할, 어떤 파일이 어디에 저장되어 있는지 알도록 해준다.

메타데이터 : 데이터의 이름, 위치 등을 저장

- 단일 고장점 제거를 위해, 두 개 이상의 마스더 및 메타데이터 노드를 대기시킨다.  

랙과 데이터 노드 : 랙과 랙은 서로 다른 물리적 위치에 존재하며, Rask2는 데이터를 백업해야 한다.