[TIL] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 1 ~ 4장 배운 내용 정리

FE 개발자이기 이전에, 개발자이기 때문에 프론트 기술이나 프론트 관련 지식이 아니라도 개발 전반에 대한 이해도를 높이기 위해서 네트워크에 대해 잘 알고 있는 것은 중요하다고 생각한다.

그리고 실무를 하다보면 프론트 개발자가 최소한의 네트워크 지식을 몰라서는 안되기도 하다. (내가 만드는 서비스가 어떻게 서빙되는지 알아야 하기 때문에...)

실무를 하기 전까지 배포나 서비스 서빙에 대한 지식이 전무한 무지랭이🪱였던 나는 업무를 하면서 어렴풋이 들었던 네트워크 지식들이 실무에서 이렇게 쓰이는구나 정도로 지식을 쌓아갔고 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 책이 나같은 무지랭이들도 이해하기 쉽고 정말 기본서라고 해서 미루고 미루다 들춰보았는데 정말 내용이 괜찮아서 추천하고 싶은 마음에 글을 작성하게 되었다. (왜 이제서야 읽은 거야..?) (대규모 시스템 설계 기초 2권도 있는데, 개인적으로 2권은 1권에 비해서 꽤나 심화 내용으로 올라가서 서버 무지랭이가 단번에 이해하기에는 약간의 무리가 있었다. 이해가 잘 안되니 흥미가 급속도로 식어버리던... 다음에 다시 도전해보도록 하겠다.)

대충 이런 책이고, 홍보 아니고 진짜 내용이 너무 알차서 추천합니다..!(이런 고전서를 누가 홍보하겠어요 이미 읽을 사람들은 다 읽은 걸...)

개인적으로 실무에서 배웠지만 조각 조각 떨어져 있던 지식들의 전체적인 짜임새가 이 책을 읽으면서 간극이 채워지는 느낌을 받았다. 3, 4년차 프론트 개발자라면 정말 이해가 쏙쏙 잘 될 것이고 신입이라면 실무를 시작하기에 앞서 전반적인 그림을 싹 훑고 가는 느낌이기 때문에 누가 읽든 정말 도움이 되리라 생각한다.

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

1장에서는 단일 서버와 클라이언트의 통신에서 트래픽이 증가함에 따라 수직적 확장을 할 것인지, 수평적 확장을 할 것인지에 대한 내용이 중심이다.

웹 계층, 데이터 계층(데이터베이스와 증설, 주-부 데이터베이스, 데이터베이스 관리 시 부하 분산을 위한 로드밸런서 등의 개략적인 설명이 이어진다.)

캐시 계층과 CDN(Content Delivery Nextwork), 캐시 메모리 관리 전략 등에서도 설명한다. 여기서 우리가 운영체제 시간에 한 번쯤 들어봤을 LRU, LFU 등 데이터 방출 알고리즘도 간단하게 소개된다.

2장. 개략적인 규모 추정

서버에서 어떤 일을 수행할 때 걸리는 시간(연산 시 응답지연 값)에 대한 개략적인 설명과 함께 가용성이라는 개념에 대해 설명한다.

고가용성(high availability)은 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어다. 고가용성을 표현하는 값은 퍼센트(percent)로 표현하는데, 100%는 단 한 번도 중단된 적이 없었음을 의미한다. 대부분의 서비스는 99%에서 100% 사이의 값을 갖는다.

특정 서비스를 만든다고 가정할 때 대략적으로 어느 정도의 DAU가 있고, 어떤 요청을 초당 몇 회를 요청하며, 어떤 데이터를 저장한다고 했을 때 대략적으로 QPS(Query Per Second)나 저장소 요구량을 산정하는 예시를 설명한다.

3장. 시스템 설계 면접 공략법

3장에서는 시스템 설계 면접을 본다고 가정하고 면접관에게 어떤 식으로 문제 해결을 위해 질문을 하고 접근해야 할 지 시뮬레이션을 하면서 면접 팁을 준다.

프론트엔드 개발자가 시스템 설계 면접을 볼 일은 드물겠지만, 전반적으로 어떤 서비스를 만든다고 할 때 면접관에게 물어봐야 할 필수 요구사항을 정리하고 면접관을 팀원이라고 가정하고 적절한 질문과 협업을 하며 소통하는 모습을 보여줘야 한다는 점에서는 충분히 배울만한 내용이 많이 있었다.

💡 팁 면접관에게 설계 내용, 혹은 나의 업무 경험을 설명할 때 특정 부분에 꽂혀서 너무 상세한 내용을 전달하려고 하지 말고 큰 관점에서 기승전결로 문제(이유), 해결 과정, 기대효과, 결론 등으로 마무리 지으면 깔끔하고 그 과정에서 몇 차례 더 핑퐁이 있다면 그 때 상세한 내용을 전달해도 늦지 않다. 상세한 내용을 전달하다 보면 정작 내가 하고 싶었던 얘기는 다 못 할 가능성이 크고, 예상치 못한 꼬리 질문으로 스텝이 꼬일 수 있다. 😥

면접은 질문의 연속인데, 가끔 면접관이 던져주는 질문은 개괄적이거나 추상적이거나 명료하지 않을 때가 종종 있어서 어떤 대답을 해야 할 지 갈피를 잡을 수 없을 때가 있다. 그럴 때는 주저하지 말고 질문을 해서 면접관이 듣고 싶은 목적이 무엇인지 뾰족하게 만들어야 한다. 그래야 명료한 답변과 함께 나의 지식과 능력을 보여줄 수 있다.

4장. 처리율 제한 장치의 설계

개인적으로 4장은 생소한 내용도 많고 처리율을 어떤 식으로 제한할 것인가에 대해 실무에서 크게 고민해 본 적이 없는데 백엔드 개발자들은 이런 것도 많이 고려하겠구나 싶어서 새롭게 배우게 된 것들이 많았다.

처리율 제한이라는 것은, 무분별한 서버 자원 요청을 막기 위해서 특정 endpoint의 특정 시간 내 특정 횟수 요청 제한을 하거나 IP별로 최대 요청 횟수를 제한한다거나 하는 식으로 할 수 있고 보통은 클라에서 제한하는 일은 없고 서버에서 처리하거나 아예 서버에 요청 조차 오지 않도록 API 게이트웨이에서 처리하는 것이 통상적인 시스템 설계인 것 같다.

처리율 제한을 위해서 고려해 볼 수 있는 알고리즘은 다음과 같다.

1. 토큰 버킷 알고리즘 (token bucket algorithm)

• 간단하고 널리 사용되는 알고리즘.
• 하나의 bucket이 수용할 수 있는 token의 개수를 정하고 요청이 들어와서 처리할 때마다 token을 사용.
• token은 일정 주기마다 새롭게 채워지고 토큰이 없는 경우에는 요청을 거부함.

1. 누출 버킷 알고리즘 (leaky bucket algorithm)

• 우리가 잘 알고 있는 선입 선출 큐(FIFO Queue) 자료구조를 활용.
• 요청이 들어올 때마다 특정 사이즈의 Queue에 요청을 추가. Queue가 다 찼을 경우 새로운 요청은 거부.
• 단시간에 요청이 몰려 처리가 지연되는 경우 오래된 요청이 제때 처리되지 않으면 새로운 요청들은 거부될 수 있음(단점)

1. 고정 윈도 카운터 알고리즘(fixed window counter)

• 타임라인을 고정된 간격의 윈도로 나누고, 각 윈도마다 카운터를 붙인다.
• 예를 들어 1분간 5개의 요청을 처리한다고 가정하면, 각 1분이라는 타임라인 내 5개 초과의 요청이 들어온 경우 그 요청들은 무시된다.
• 하지만, 타임라인의 경계에 요청이 몰릴 경우, 경계 부근의 1분이라는 타임라인 내에는 5개가 넘어가는 요청이 처리될 수 있음.(고정적으로 잘라둔 타임라인 내에는 한도 내에 처리된 것으로 볼 수 있으나, 1분이라는 시간으로 윈도우의 시작점을 이동한다고 가정했을 때 특정 구간에 트래픽이 몰리면 한도 이상으로 처리될 수 있음)

1. 이동 윈도 로깅 알고리즘(sliding window log)

• 요청의 타임스탬프를 추적하여, 새로운 요청이 들어왔을 때부터 직전 타임라인을 계산해서 해당 타임라인 내 한도를 넘어가지 않을 때만 새로운 요청을 처리한다.
• 타임라인 외의 만료된 타임스탬프는 제거한다. (현재 윈도의 시작 시점보다 오래된 타임스탬프)
• 하지만 거부된 요청의 타임스탬프도 보관하기 때문에 메모리가 많이 든다.(단점)

1. 이동 윈도 카운터 알고리즘(sliding window counter)

• 고정 윈도 카운터 알고리즘과 이동 윈도 로깅 알고리즘을 합친 개념이라고 볼 수 있다.
• 현재 윈도우를 기준으로, 직전 특정 시간대와 현재 특정 시간대의 교집합 비율을 계산해서 현재 윈도우의 요청 수를 계산하고 아직 한도가 차지 않았다면 요청을 처리하는 식으로 계산

to be continue... 🙌