https://product.kyobobook.co.kr/detail/S000001033116

 

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

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | “페이스북의 뉴스 피드나 메신저,유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?” IT 경력자라도 느닷없이 대규모 시스템

product.kyobobook.co.kr

1장 사용자 수에 따른 규모 확장성 : https://inhyeok-blog.tistory.com/40
2장 개략적인규모추정 : https://inhyeok-blog.tistory.com/41
3장 시스템 설계 면접 공략법 : https://inhyeok-blog.tistory.com/42
4장 처리율제한장치의설계 : https://inhyeok-blog.tistory.com/43
5장 안정해시설계 : https://inhyeok-blog.tistory.com/44
6장 키-값저장소설계 : https://inhyeok-blog.tistory.com/45
7장 분산시스템을위한유일 ID 생성기설계 : https://inhyeok-blog.tistory.com/46
8장 URL 단축기설계 : https://inhyeok-blog.tistory.com/47
9장 웹크롤러설계 : https://inhyeok-blog.tistory.com/48
10장알림시스템설계 : https://inhyeok-blog.tistory.com/49
11장뉴스피드시스템설계 : https://inhyeok-blog.tistory.com/50
12장채팅시스템설계 : https://inhyeok-blog.tistory.com/51
13장검색어자동완성시스템 : https://inhyeok-blog.tistory.com/52
14장유튜브설계 : https://inhyeok-blog.tistory.com/53
15장구글드라이브설계 : https://inhyeok-blog.tistory.com/54

 

이 책은 대규모 시스템을 설계하기 위해서 해야할 접근방식과, 모범답안을 알려준다. 이 문제들과 답안을 통해서 대규모시스템의 문제를 도출해 낼 수 있는 힘과 이를 해결하기 위한 사고방식을 배울 수 있었다. 평소에 시스템 설계를 고민하면서 헤메이던 기억이 많은데, 가려운 곳을 시원하게 긁어주는 책이었다. 개인적으로 이 책은 가볍게 읽어도 좋을 것 같다. 각각의 컴포넌트가 아닌 시스템 전체를 설명하고 있어서 생각보다 어렵지 않고, 심지어 작가가 나열하는 문제를 어떻게 해결해 나가는지가 기대되기도 한다.

 

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

1장에서는 단일 서버에서부터 대규모 시스템을 설계하기 까지의 Step을 하나하나 알려준다. 각 Step이 어떤 문제에서 시작해서 어떤 형태로 변화하는지 아주 설득력 있게 다룬다

 

단일서버

단일서버는 웹서버 한대만으로 사용자 단말의 요청을 처리하는 구조다. 여기엔 DB도 없고, 캐시도 없으며, 정말 단일 웹서버만으로 요청을 처리한다. 아마도 데이터를 저장하는 위치는 해당 웹서버의 파일 시스템일 것으로 보인다.

 

데이터베이스

작가는 첫번째로 서버에서 데이터베이스를 분리한다. 단일 서버는 사용자가 증가하면 트레픽을 버틸만한 컴퓨팅 파워가 부족하기 때문이다. (자세한 언급은 없었지만, 당연하게도 단일버서는 조금만 트레픽이 증가해도 버틸 수 없다.) 데이터 베이스는 RDB와 NoSQL을 간단하게 비교해서 설명해준다. 그리고 각각의 DB를 선택해야하는 기준도 간단하게 언급한다.

 

수직적 규모 확장 vs 수평적 규모확장

수직적 규모 확장(이하 Scale up)은 사용하고 서버에 고사양 자원을 추가하는 방식을 의미하고, 수평적 규모 확장(이하 Scale out)은 서버를 추가해 주는 방식이다. 작가는 Scale up의 단점을 언급하면서 Scale out을 추천하고, 이를 위한 로드 벨런서까지 자연스럽게 이어지게 한다. 작가는 scale up의 단점을 확장에 한계가 있다는 점과, 자동복구나 다중화 방안을 제시하지 않는다는 것을 언급한다. 하지만 서버에 유입되는 트래픽의 양이 적을 경우에는 scale up도 좋은 선택이며, 단순한 솔루션이기 때문에 상황에 따라 선택할 수 있다고도 잠깐 언급한다.

 

로드밸런서

scale out을 하기 위해서는 하나의 엔포인트로 오는 사용자 단말의 요청을 여러개의 서버로 분산해 줘야한다. 그 역할을 하는 것이 로드 밸런서이다. 또한 로드 밸런서는 장애를 자동으로 복구할 수 있으며, 가용성(웹서버 하나가 죽더라도 다른 하나가 사용 가능한 것)이 향상된다. 로드 밸런러는 외부로 공개 IP를 Open해두고, 사설 IP 주소를 가지고 서버들에게 요청을 분산해 주는 방식을 택하고있다. 이제 웹 계층에 대해서 살펴봤으니 데이터 계층에 대해서 살펴본다.

 

데이터베이스 다중화

데이터베이스 다중화는 데이터베이스 서버를 여러개 만들어서 master 또는 slave의 역할을 수행하도록 한다. 이때 쓰기 연산은 master에서만 지원하고, slave는 master에서 그 사본을 전달받아서 읽기 전산을 지원한다. 일반적인 어플리케이션은 쓰기보다 읽기연산이 많으므로, slave 서버가 더 많다. 이렇게 데이터베이스 다중화를 수행하므로서 병렬 읽기로 인한 더 나은 성능과 서버가 분산되므로 인한 안정성(데이터 다중화로 인한 자연 재해로 인한 데이터 손실 최소화), 그리고 가용성(하나의 서버에 장애가 발생해도 다른 서버에서 서비스 가능)을 보장받는다. 

 

캐시

이제 웹 계층과 데이터 계층에 대해 논의했으니, 응답시간을 개선하기 위한 캐시에 대해서 말해보자. 캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고 뒤이은 요청이 보다 빨리 처리 되도록 하는 저장소이다. 캐시 계층은 메모리를 활용하므로 DB에 비해 조회 속도가 빠르고, DB에 요청을 적게 주므로서 부하를 줄일 수 있다. 또한 캐시를 확장시키는 것도 가능하다.

작가는 캐시를 사용하기전에 해야할 질문을 친절하게도 대신 하고, 답변해주고 있다. 캐시가 바람직한 상황, 캐싱할 데이터의 종류, 캐시 만료 전략, 일관성 유지방법, 장애 대응, 캐시 메모리 크기, 데이터 방출 정책에 대한 언급을 하고 있다.(해당 내용은 필요하다면 책을 확인해보자)

 

CDN

CDN은 정적 콘텐츠 전송을 위한 지리적으로 분산된 서버의 네트워크이다. CDN을 통해서 정적파일을 캐싱해두면 지리적 이점을 바탕으로 성능을 향상시킬 수 있다. 하지만 비용, 만료 시한 설정, 장애 대응, 콘텐츠 무효과 방법 등을 고려해서 CDN을 도입해야 한다. 

 

무상태 웹계층

웹 계층을 수평적으로 확장하려면 웹 계층은  무상태를 유지해야 한다. 이는 각각의 요청이 같은 서버로 들어올 것이라는 보장이 없기 때문에(이를 실현할 수 있지만 로드 밸런서에게 큰 부하를 준다) 사용자 단말의 상태를 유지해둬도 재조회가 불가능 하기 때문이다. 이를 위해서 상태는 NoSql과 같은 지속성 저장소에 보관하고, 필요할 때 가져와야 한다.

 

데이터 센터

데이터 센터를 다중화 하므로서 지리적 라우팅을 통한 성능 향상, 그리고 가용성 향상, 안정성 향상을 꾀할 수 있다. 하지만 데이터 센터 다중화는 몇가지 기술적 난제를 해결해야 한다. 이는 트레픽 우회(지리적 라우팅)과 데이터 동기화, 테스트와 배포이다. 

 

메시지큐

메시지 큐는 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트이다. 메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모의 확장성이 보장되어야 하는 안정적인 어플리케이션을 구성하기 좋다. 예컨데 서버와 서버간의 통신의 결합을 느슨하게 해서 두 서버중 누군가 시간이 성능이 부족해져도 독립적으로 확장할 수 있는 것이다. 

 

로그, 메트릭 그리고 자동화

웹사이트와 함계 사업 규모가 커지고 나면 위의 도구는 필수적이다.

 

데이터베이스의 규모확장

DB는 scale up과 scale out이 모두 가능하다. 하지만 앞서 언급한바와 같이 scale up은 한계가 존재하며, SPOF(Single Point Of Failure)의 위한이 크다. 또한 비용도 많이 든다. 반면 수평적 확장은 DB 샤딩을 통해서 가능하다. 샤딩은 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 말한다. 이는 간단하게 (user_id%4)번 DB에 데이터를 저장하는 방식이 있다. DB 샤딩은 데이터가 너무 많아지면 재샤딩 하기도 하고, celebrity문제를 해결해야 하며(이후 안정해시를 이야기하며 힌트를 얻을 수 있다), 조인이 불가능해지기 때문에 비정규화를 통해 하나의 샤드에서 질의가 수행하도록 해야한다. 

+ Recent posts