책 리뷰/가상 면접 사례로 배우는 대규모 시스템 설계 기초
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 2~3장
eess
2024. 8. 19. 13:55
🔖 2~3장 : 개략적인 규모 추정 ~ 시스템 설계 면접 공략법
읽은 날짜 : 2024.08.19
지은이 : 알렉스 쉬
출판사 : 인사이트
기억하고 싶은 내용
개략적인 규모 추정(back-of-the-envelope estimatation)
- 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위
- 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것
- 2의 제곱수, 응답지연 값, 가용성과 관련된 수치를 이해해야 한다.
2의 제곱수
- 최소 단위는 1바이트(=8비트). ASCII 문자 하나가 1바이트.
- 1 byte(바이트) - 1KB(킬로바이트) - 1MB(메가바이트) - 1GB(기가바이트) - 1TB(테라바이트) - 1PB(페타바이트)
- 단위가 바뀔 때마다 2의 10제곱씩 곱해진다.
응답지연 값
- 메모리는 빠르지만 디스크는 느리다.
- 디스크 탐색은 가능한 한 피하라.
- 단순한 압축 알고리즘은 빠르다.
- 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.
- 데이터 센터는 보통 여러 지역(region)에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다.
가용성에 관계된 수치들
- 고가용성 : 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력.
- 퍼센트로 표현한다. 100%면 한 번도 시스템이 중단된 적 없다는 뜻.
- 대부분의 서비스는 99~100% 사이의 값을 가진다.
- 관습적으로 9를 이용해 표기하고, 9가 많을수록 좋다는 뜻이다. (e.g. 99.999%)
팁
- 근사치를 활용한 계산 : 99987 => 100,000
- 단위를 붙이는 습관
- QPS(Query Per Second), 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등 추정하는 연습
시스템 설계 면접에서 알고 싶은 것들
- 설계 과정에서 내린 결정들에 대한 방어 능력
- 면접관의 피드백을 건설적인 방식으로 처리할 수 있는 자질이 있는지
- 협력에 적합한 사람인지
- 압박이 심한 상황도 잘 헤쳐 나갈 자질이 있는지
- 모호한 문제를 건설적으로 해결할 능력이 있는지
- 좋은 질문을 던질 능력이 있는지
- 설계의 순수성에 집착해서 타협적 결정(tradeoff)을 도외시하고 오버엔지니어링을 하지 않는지
효과적 면접을 위한 4단계 접근법
1단계 : 문제 이해 및 설계 범위 확정 (3~10분)
- 구체적으로 어떤 기능들을 만들어야 하나?
- 제품 사용자 수는 얼마나 되나?
- 회사의 규모는 얼마나 빨리 커지리라 예상하나?
- 회사가 주로 사용하는 기술 스택은 무엇인가? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?
2단계 : 개략적인 설계안 제시 및 동의 구하기(10~15분)
- 설계안에 대한 최초 청사진을 제시하고 의견 구하기.
- 핵심 컴포넌트를 포함하는 다이어그램을 그려보기.
- 클라이언트(모바일/웹), API, 웹 서버, 데이터 저장소, 캐시, CDN, 메시지 큐 등등
- 최초 설계안이 시스템 규모와 관계된 제약사항들을 만족하는지를 개략적으로 계산해보기.
3단계 : 상세 설계(10~25분)
- 특정 컴포넌트들의 세부사항을 깊이 있게 설명하기
- 우선 순위를 정하여 가장 중요한 컴포넌트부터 진행하기
4단계 : 마무리(3~5분)
- 시스템의 병목구간, 좀 더 개선 가능한 지점
- 오류가 발생하면 무슨 일이 생기는지
- 로그나 메트릭은 어떻게 수집하고 모니터링할 것인지
- 시스템은 어떻게 배포해 나갈 것인지
- 미래에 닥칠 규모 확장 요구에 어떻게 대처할 것인지 (더 많은 사용자를 감당하려면 어떻게 해야 하는지)
해야할 것
- 스스로 내린 가정이 옳다 생각하지 말고, 질문을 통해 확인하기
- 문제의 요구사항 이해하기
- 정답이나 최선의 답안 같은 것은 없다
- 면접관과 소통하며 나의 사고 흐름을 이해할 수 있도록 하기
- 가능하다면 여러 해법을 함께 제시하기
하지 말아야 할 것
- 전형적인 면접 문제들에도 대비하지 않은 상태에서 면접장에 가지 말 것
- 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말 것
- 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 말 것 : 개략적 설계 -> 세부사항
- 하다가 막히면 힌트를 요청하는 것을 주저하지 말 것
- 소통을 주저하지 말고, 침묵 속에 설계를 진행하지 말 것
오늘 읽은 소감
꼭 시스템 설계 면접이 아니더라도 기술면접 준비에 필요한 내용들인 것 같습니다.
정답이 있다 생각하고 그걸 맞추려고만 하다보면 오히려 설명과 답변이 더 꼬이는 것 같습니다.
면접관과 소통하면서, 필요하다면 적극적으로 힌트도 구하고 개략적인 내용에서 세부적인 내용 순으로 설명하는 것이 중요한 것 같습니다.
궁금한 내용 & 잘 이해되지 않는 내용
QPS
- 시스템(검색엔진, 데이터베이스, API 등)에서 초당 처리할 수 있는 쿼리 또는 요청의 수를 의미합니다.
- 트래픽 측정 단위 중 하나로, 시스템의 성능과 효율성을 측정하는 지표입니다.