[독서] 가상 면접 사례로 배우는 대규모 시스템 설계 1

가상 면접 사례로 배우는 대규모 시스템 설계 기초

 

이 책의 목차를 열었을때, 개발자라면 흥미로운 단어들이 많이 눈에 띌 것입니다.

웹크롤러, 분산시스템, 피드 시스템, 검색어 자동 완성, 유투브 설계 등

챕터 별로 다양한 종류의 시스템을 어떻게 설계하고 개발 할 것인가에 대한 내용이 포함되어 있습니다.

몇몇 기억에 남는 내용을 포스팅 해봅니다.

 

서버 확장

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

실제 현업에서 많이 고민하게 되는 서버의 확장성에 대해서 이야기 하고 있습니다.

비관계형 데이터 저장소(NoSQL)을 고려해봄직 할 케이스를 기술 한 것이 기억에 남네요.

• 낮은 응답 지연(Latency)
• 비정형 데이터
• 데이터를 직렬화, 역직렬화
• 대규모 데이터 저장

위 같은 요구가 있다면 고려해봄직 하다고 합니다.

 

그리고 웹 계층의 무상태, 데이터 베이스의 수평 확장, 샤딩 등

서버 확장에 있어 고려해야할 것과 단일 서버부터 점진적으로 확장해 나가는 내용이

현업자에게 많은 도움이 될 것 같았습니다.

 

한편으로는 신규 프로젝트 시작 시, 어떻게 사용자 규모를 예측 할 수 있을지 고민이 되기도 합니다.

 

시스템 설계 면접

3장에서는 시스템 설계 면접 공략법에 대한 내용이었습니다.

시스템 설계 시에는 반드시 트레이드오프를 고려하고

이를 도외시하면 과도한 엔지니어링이 될 수 있다고 말합니다.

 

과도한 엔지니어링은 언제나 함께 해왔던것 같습니다.

트레이드오프와 같은 문제를 정의하고 커뮤니케이션 하는 것이 가끔은 힘들기도 했던 것 같네요.

 

트레이드오프와 연관된 시스템 설계 전략 중 하나로는

입력과 조회의 분리. CQRS(Command and Query Responsibility Segregation)가 나왔습니다.

많은 요구사항을 충족 시킬 수 있고, 시스템 안정성 측면에서도 장점이 부각되는 전략인 것 같습니다.

• (단점)복잡도는 증가할 수 있다.
• (장점)대부분의 시스템은 READ가 80-90% 해당 할 것이다. 캐싱 처리 간편하다.

 

처리율 제한 장치

4장에서 처리율 제한 장치의 설계에 대해서 이야기 합니다.

보통 미들웨어 형태로 구현되며, API Gateway가 이러한 처리율 제한 장치의 기능을 가질 수 있습니다.

단, 이는 도전적인 시스템 설계 일 수 있습니다. 차라리 상용 API Gateway가 좋을 수도 있다고 하네요.

 

아직까지 이러한 처리율 제한 장치를 개발 및 적용 해본적은 없었네요.

기회가 된다면, 애플리케이션 계층의 처리율을 제한이 필요한 프로젝트를 맞아보고 싶네요.

 

처리율 제한에는 토큰 버킷, 큐 등의 알고리즘이 사용될 수 있다고 합니다.

Redis 오픈소스를 사용하여 여러 요구 사항을 충족 시킬 수 있다고 합니다.

 

Redis는 아래와 같은 처리율 제한 장치에 필요할 법한 기능을 제공합니다.

• 카운터 저장
• 만료시간 설정
• SortedSet(ZSET)

 

웹 크롤러

9장에서는 웹 크롤러에 대해서 이야기합니다.

웹 크롤러는 용도에 따라 초대형 프로젝트가 될 수 있습니다.

 

구글 검색 엔진을 예로 들수 있겠네요.

웹 콘텐츠들을 크롤러(또는 봇)를 통해 수집, 인덱싱, 광고 플랫폼 연동 등.

 

웹 크롤러에서 반드시 고려해야 할 것은

웹 콘텐츠의 중복 제거라고 합니다.

이는 해시 기술이 사용 될 수 있습니다.

 

 

알림 시스템

10장에서는 알림 시스템의 설계에 대해 이야기 합니다.

알림 시스템은 연성 실시간 시스템(Soft Real Time System)에 해당하며

실시간이 필수적이지만, 부하 시에는 어느정도 지연을 허용하는 것이 특징입니다.

 

알림시스템은 클라이언트에 맞게끔 Payload를 구성할 수 있어야 한다고 말합니다.

또한 단일 실패 지점이 될 수 있기 때문에 메시지 큐를 활용하는 것이 좋다고 하네요.

 

실제 회사에서 알림 시스템을 구축 하고 있는데

해당 내용이 많은 도움이 되었네요.

 

 

채팅 시스템

12장에서는 채팅 시스템을 다룹니다.

과거에는 Long polling으로 채팅 시스템을 개발하기도 했다고 합니다.

현재는 대부분 웹소켓 기술을 이용한다고 하네요.

웹소켓의 첫 연결은 Http지만 이후 Http Upgrade 방식으로 바뀐다.

 

채팅 시스템은 연결 상태를 서버에서 다뤄야 하기 때문에

Application의 무상태성을 위해 고려해야하는 바가 많을 수 있습니다.

요구 기능에 따라 규모도 천차 만별로 다를 수 있는 것이 채팅 시스템이라고 말합니다.

 

 

유투브

14장에서 유투브와 같은 시스템의 설계를 다룹니다.

흥미로운 내용이 많았는데요.

대용량의 파일을 다루고, 실시간 서비스로서의 기능(낮은 응답지연), 대규모 사용자 등

개발 난이도 끝판왕이 아닐까 생각 되기도 하네요.

 

이러한 대규모 시스템에서는 시스템 오류는 불가피 한 것으로 보고

Retry 패턴 등으로 처리하는 것도 방법이 될 수 있다는 내용이 기억에 남네요.

 

---

제목에 "가상 면접 사례"로 유추 할 수 있듯이

내용을 읽다보면 시스템 설계 면접을 보는 듯한 느낌을 줍니다.

이 때 다양한 역질문을 통해, 규모를 가정하고 요구사항을 명세하는 과정들이 인상 깊었습니다.

IT회사에서 개발자로 일하게 되면 시스템 설계 시, 기획자나 상위 직급자에게 질문과 제안을 반복하게 됩니다.

마치 이러한 과정의 축소판이라고 보여집니다.

 

마지막의 유투브 설계 관련 내용이 저에게는 가장 흥미로웠습니다.

실제 비슷한 프로젝트를 경험해 봤는데(비디오 스트리밍 제외)

실행 파일을 다루고, 실시간 분석, 검색 엔진, 집계 등의 요구가 포함된 일종의 분석 서비스 였습니다.

MSA, 메타 데이터, 원본 데이터, 메시지 큐, 지연 허용 등... 

해당 시스템 개발 했던 시절이 기억 나네요.