대규모 시스템 설계시 참고해야할 것들 1

'가상 면접 사례로 배우는 대규모 시스템 설계 기초'를 읽고 중요해 보이는 부분만 아주 간략히 요약해보았습니다. 

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고 (kyobobook.co.kr)

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

시스템을 확장하기 위해 알아야 하는 기본 지식

수직적 규모 확장

- 서버에 고사양 자원을 추가하는 행위

수평적 규모 확장

- 더 많은 서버를 추가하여 성능을 개선하는 행위

=> 한 대의 서버에 CPU나 메모리를 무한대로 증설할 수 없기에 수직적 규모 확장에는 한계가 있음. 따라서 수평적 규모 확장을 하는 것이 일반적이라고 함. 

로드밸런서

- 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 함. 

데이터베이스 다중화

- DB 서버를 여러개 두어, 주 디비서버에는 WRITE 권한을 포함하여 주고, 부 디비서버에는 READ권한만을 주는 것. 부 디비서버에 사본을 전달하여, 안정성을 높이고 데이터를 여러 지역에 복제해둠으로써 특정 디비서버에 문제가 생기더라도 금방 대체할 수 있게끔 가용성을 높인다.

캐시

- 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 빨리 처리될 수 있게끔 하는 것. 서버와 디비 사이에 붙여, 디비 호출을 줄여서 애플리케이션의 성능을 높이는 역할을 함.

=> 캐시 사용시 유의할 점. 

1. 빈번하게  참조되는 데이터에 붙일 것

2. 영속적으로 보관할 데이터는 대상에 두지 말 것

3. 캐시 서버도 분산 시켜야 SPOF (단일장애지점)을 막을 수 있다.

4. 캐시메모리를 과할당하여 캐시 성능을 높여야 함

CDN

- 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크

- 이미지, 비디오, CSS, JS파일을 캐시 가능

무상태 웹 계층

- 웹 계층을 수평적으로 확장하기 위해서는, 사용자 세션 데이터를 웹 계층에서 제거해야함. ex ) sticky session... 

상태 정보 의존적인 아키텍처는 로드밸런싱하기 어려워짐.

따라서 상태정보를 웹서버가 아닌 통일된 공유 보관소에 따로 저장하여 해결한 아키텍처가 무상태 웹 계층 아키텍처임

 

메세지 큐

- 메세지의 무손실을 보장하는, 비동기 통신을 지원하는 컴포넌트. 메세지 큐를 사용하면 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적인 애플리케이션을 구성하기 좋음. 상대 서버가 상태 이상이어도, 메세지를 자유롭게 꺼내서 쓸 수 있다. 

 

처리율 제한 장치   

- 클라이언트 또는 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치로, 요청 횟수를 제한한다.

=> 마이크로 서비스인 경우, 보통 게이트웨이에 포함시킨다고 함

=> 우리 회사는 적용되어있ㄴ ㅏ...??????

 

처리율 제한 알고리즘

토큰 버킷 알고리즘 

- API 엔드포인트마다 버킷을 두고, 고정된 개수의 토큰을 할당하여 토큰을 소진하는 방식. 

누출 버킷 알고리즘

- 고정된 크기의 FIFO 형식의 큐를 사용하여, 큐가 가득차 있는지 확인 후 빈자리가 있으면 큐에 요청을 추가하여 처리하는 알고리즘.

고정 윈도 카운터 알고리즘

- 타임라인을 고정된 간격의 윈도우로 나누고, 각 윈도우마다 카운터를 붙이는 것.

- 요청이 접수될 때마다 카운터 + 1 되고, 임계치를 넘으면 새 요청은 윈도우가 새로 열릴때까지 버려진다. 

- 특정 시간대에 트래픽이 몰릴시, 예상했던 한도보다 많은 양의 요청을 처리할 수도 있음.

처리율 한도 트래픽 처리의 일반적인 설계

1. 클라이언트가 서버쪽에 요청은 처리율 제한 미들웨어에 도달

2. 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져옴

3-1. 제한이 걸리지 않으면 API 서버로 요청 보냄 

3-2. 제한에 걸리면 429 too many request 에러 보냄 ( 클라측 송신할때 보통 헤더에 실어서 보낸 다고함 )