Back-of-the-envelope Estimation
시스템 디자인 인터뷰에서는 back-of-the-envelope estimation을 사용해 시스템의 용량이나 성능 요구사항을 추정하도록 요청받는 경우가 있다. Google Senior Fellow인 Jeff Dean에 따르면, “back-of-the-envelope 계산이란 사고 실험과 일반적인 성능 수치를 조합하여 어떤 설계가 요구사항을 충족하는지 감을 잡기 위해 만드는 추정치"이다.
이를 효과적으로 수행하려면 확장성(scalability)의 기초에 대한 감각이 있어야 한다. 다음 세 가지 개념을 잘 이해해야 한다: 2의 거듭제곱(power of two), 프로그래머가 알아야 할 지연 시간 수치(latency numbers), 가용성 수치(availability numbers).
2의 거듭제곱 (Power of Two)
분산 시스템을 다룰 때 데이터 규모는 거대해질 수 있지만, 계산은 결국 기본으로 귀결된다. 정확한 계산을 위해서는 2의 거듭제곱 단위로 표현되는 데이터 볼륨 단위를 알아야 한다. 1 byte는 8개의 bit로 구성되며, ASCII 문자 하나는 1 byte(8 bits)의 메모리를 사용한다.
| 거듭제곱 | 근사값 | 전체 명칭 | 약칭 |
|---|---|---|---|
| 10 | 1 Thousand (천) | 1 Kilobyte | 1 KB |
| 20 | 1 Million (백만) | 1 Megabyte | 1 MB |
| 30 | 1 Billion (10억) | 1 Gigabyte | 1 GB |
| 40 | 1 Trillion (1조) | 1 Terabyte | 1 TB |
| 50 | 1 Quadrillion (1000조) | 1 Petabyte | 1 PB |
프로그래머가 알아야 할 지연 시간 수치
Google의 Dr. Dean은 2010년을 기준으로 대표적인 컴퓨터 연산의 소요 시간을 공개하였다. 컴퓨터가 점점 빠르고 강력해지면서 일부 수치는 오래된 것이 되었지만, 다양한 연산의 상대적인 빠르고 느림을 파악하는 데에는 여전히 유효하다.
| 연산 | 소요 시간 |
|---|---|
| L1 cache 참조 | 0.5 ns |
| 분기 예측 실패 (branch mispredict) | 5 ns |
| L2 cache 참조 | 7 ns |
| Mutex lock/unlock | 100 ns |
| 주 메모리 참조 | 100 ns |
| Zippy로 1K bytes 압축 | 10,000 ns = 10 µs |
| 1 Gbps 네트워크로 2K bytes 전송 | 20,000 ns = 20 µs |
| 메모리에서 1 MB 순차 읽기 | 250,000 ns = 250 µs |
| 같은 데이터센터 내 왕복 (round trip) | 500,000 ns = 500 µs |
| 디스크 탐색 (disk seek) | 10,000,000 ns = 10 ms |
| 네트워크에서 1 MB 순차 읽기 | 10,000,000 ns = 10 ms |
| 디스크에서 1 MB 순차 읽기 | 30,000,000 ns = 30 ms |
| 패킷 왕복 CA → 네덜란드 → CA | 150,000,000 ns = 150 ms |
위 수치를 분석하면 다음과 같은 결론을 얻을 수 있다.
- 메모리는 빠르지만 디스크는 느리다.
- disk seek은 가능한 한 피한다.
- 단순한 압축 알고리즘은 빠르다.
- 인터넷을 통해 데이터를 전송하기 전에 압축한다.
- 데이터센터는 보통 서로 다른 지역(region)에 위치하며, 데이터를 전송하는 데 시간이 걸린다.
가용성 수치 (Availability Numbers)
고가용성(high availability)이란 시스템이 원하는 기간 동안 지속적으로 운영될 수 있는 능력이다. 백분율로 측정되며, 100%는 다운타임(downtime)이 전혀 없는 서비스를 의미한다. 대부분의 서비스는 99%에서 100% 사이에 위치한다.
SLA(service level agreement)는 서비스 제공자 사이에서 일반적으로 사용되는 용어로, 서비스 제공자와 고객 간의 합의이다. 이 합의는 제공할 서비스의 uptime 수준을 공식적으로 정의한다. Amazon, Google, Microsoft와 같은 클라우드 제공업체들은 SLA를 99.9% 이상으로 설정하고 있다. uptime은 전통적으로 9의 개수(nines)로 측정되며, 9가 많을수록 더 높은 가용성을 의미한다.
| 가용성 % | 일일 다운타임 | 주간 다운타임 | 월간 다운타임 | 연간 다운타임 |
|---|---|---|---|---|
| 99% | 14.40분 | 1.68시간 | 7.31시간 | 3.65일 |
| 99.9% | 1.44분 | 10.08분 | 43.83분 | 8.77시간 |
| 99.99% | 8.64초 | 1.01분 | 4.38분 | 52.60분 |
| 99.999% | 864 ms | 6.05초 | 26.30초 | 5.26분 |
| 99.9999% | 86.4 ms | 604.8 ms | 2.63초 | 31.56초 |
예시: Twitter QPS 및 저장 용량 추정
가정
- 월간 활성 사용자(MAU): 3억 명
- 사용자의 50%가 매일 Twitter를 사용한다.
- 사용자는 하루 평균 2개의 tweet을 작성한다.
- tweet의 10%에는 미디어(media)가 포함된다.
- 데이터는 5년간 저장된다.
추정
QPS(초당 쿼리 수) 추정
일간 활성 사용자 (DAU) = 3억 * 50% = 1억 5천만
Tweets QPS = 1억 5천만 * 2 / 24시간 / 3600초 = ~3500
최대 QPS (Peak QPS) = 2 * QPS = ~7000미디어 저장 용량 추정
평균 tweet 크기:
tweet_id 64 bytes
텍스트 140 bytes
미디어 1 MB
일일 미디어 저장량: 1억 5천만 * 2 * 10% * 1 MB = 하루 30 TB
5년 미디어 저장량: 30 TB * 365 * 5 = ~55 PB팁
back-of-the-envelope estimation에서 중요한 것은 결과가 아니라 과정이다. 인터뷰어는 문제 해결 능력을 평가한다.
반올림과 근사치 활용: 인터뷰 중 복잡한 계산을 수행하기는 어렵다. 예를 들어
99987 / 9.1은100,000 / 10으로 단순화할 수 있다. 정밀도보다 빠른 근사 계산이 중요하다.가정 사항 기록: 계산에 사용한 가정을 반드시 적어두고, 나중에 참조할 수 있도록 한다.
단위 명시:
5라고만 쓰면 5 KB인지 5 MB인지 모호해진다.5 MB처럼 단위를 함께 적어 혼란을 없앤다.자주 등장하는 추정 항목: QPS, 최대 QPS(peak QPS), 저장 용량(storage), cache, 서버 수(number of servers) 등이 자주 출제된다. 준비 단계에서 반복 연습이 필요하다.
System Design Interview란
System design interview는 두 명의 동료가 모호한 문제를 함께 풀고, 목표에 맞는 해결책을 도출해 나가는 실제 문제 해결 과정을 시뮬레이션한다. 문제는 open-ended이고 완벽한 정답은 없다. 최종 설계 결과보다 설계 과정에서 기울인 노력이 더 중요하다.
면접관은 기술적 설계 능력만 보는 것이 아니다. 협업 능력, 압박 상황에서의 대처 능력, 모호함을 건설적으로 해소하는 능력, 그리고 좋은 질문을 던지는 능력까지 종합적으로 평가한다.
4단계 프로세스
Step 1 - 문제를 이해하고 설계 범위를 확립하라
요구사항을 제대로 이해하지 않고 답변하는 것은 큰 Red Flagover-engineering은 많은 엔지니어들이 앓는 고질병이다. 설계의 순수성을 추구하느라 trade-off를 무시하는 경향, 협소한 시각, 고집 등이 red flag에 해당한다.다. 바로 해결책으로 달려들지 말고, 천천히 생각하며 요구사항과 가정을 명확히 하기 위한 질문을 던져야 한다.
질문을 던지면 면접관은 직접 답변하거나 가정을 스스로 세우도록 요청한다. 후자의 경우라면 화이트보드나 종이에 그 가정을 적어두어야 한다. 시작점이 될 만한 질문들은 다음과 같다.
- 어떤 기능들을 구체적으로 만들어야 하는가?
- 제품의 사용자 수는 얼마나 되는가?
- 회사는 어느 정도의 속도로 scale up할 것으로 예상하는가? 3개월, 6개월, 1년 후의 예상 규모는?
- 회사의 technology stack은 무엇인가? 설계를 단순화하기 위해 활용할 수 있는 기존 서비스는 무엇인가?
Step 2 - High-level design을 제안하고 동의를 얻어라
이 단계에서는 high-level design을 개발하고 면접관과 설계에 대한 합의를 도출하는 것을 목표로 한다.
- 설계의 초기 blueprint를 제시하고 피드백을 요청한다. 면접관을 팀원처럼 대하고 함께 작업한다.
- 화이트보드나 종이에 핵심 컴포넌트를 담은 박스 다이어그램을 그린다. clients (mobile/web), API, web server, data store, cache, CDN, message queue 등이 포함될 수 있다.
- Back-of-the-envelope 계산을 통해 blueprint가 규모 제약을 충족하는지 평가한다. 생각하는 과정을 소리 내어 말하고, 계산이 필요한지 먼저 면접관과 소통한다. API endpoint와 database schema를 포함할지는 문제에 따라 다르다. 대규모 설계 문제에서는 너무 low-level이고, 소규모 문제에서는 적절할 수 있다. 면접관과 소통하여 결정한다.
Step 3 - Deep dive 설계
이 단계에서는 면접관과 함께 아키텍처에서 우선순위를 두어야 할 컴포넌트를 파악하고 집중한다. 모든 면접은 다르기 때문에 면접관이 주는 신호를 잘 읽어야 한다.
- 면접관이 high-level design에 집중하고 싶다는 신호를 줄 수도 있다.
- 시니어 후보자 면접에서는 bottleneck과 resource 추정에 초점을 맞춘 시스템 성능 특성 논의가 이루어질 수 있다.
- 일부 시스템 컴포넌트의 세부 사항을 파고들기를 원하는 경우도 있다. 시간 관리는 필수적이다. 능력을 보여주지 못하는 세부 사항에 빠져드는 것을 경계해야 한다. 불필요한 세부 사항은 피하고, 면접관에게 명확한 신호를 보여주는 데 집중한다.
Step 4 - Wrap up
마지막 단계에서 면접관은 후속 질문을 하거나 추가적인 사항을 자유롭게 논의할 기회를 준다.
- 시스템의 bottleneck을 파악하고 잠재적인 개선 사항을 논의한다. 설계가 완벽하다고 말하지 마라. 항상 개선할 여지는 있다.
- 면접관에게 설계를 다시 정리해서 설명하는 것이 유용하다. 특히 여러 해결책을 제시했을 경우 더욱 그렇다.
- Error case (서버 장애, 네트워크 단절 등), 운영 이슈 (metric 모니터링, error log, roll out 방식)도 언급할 가치가 있다.
- 다음 scale 곡선에 어떻게 대응할 것인가도 흥미로운 주제다.
Dos and Don’ts
Dos
- 항상 명확화를 요청하라. 자신의 가정이 옳다고 전제하지 마라.
- 문제의 요구사항을 이해하라.
- 면접관에게 생각하고 있는 것을 알려라. 면접관과 소통하라.
- 가능하다면 여러 접근 방식을 제안하라.
- Blueprint에 합의했다면, 가장 중요한 컴포넌트를 먼저 설계하라.
- 면접관과 아이디어를 주고받아라. 좋은 면접관은 팀원처럼 함께한다.
- 절대 포기하지 마라.
Don’ts
- 일반적인 면접 질문에 준비되지 않은 채로 임하지 마라.
- 요구사항과 가정을 명확히 하지 않고 해결책으로 달려들지 마라.
- 초반부터 단일 컴포넌트의 세부 사항으로 지나치게 깊이 들어가지 마라.
- 막혔다면 힌트를 요청하는 것을 주저하지 마라.
- 침묵 속에서 혼자 생각하지 마라.
- 설계를 제시했다고 해서 면접이 끝났다고 생각하지 마라. 면접관이 끝났다고 말할 때까지 끝나지 않은 것이다.
시간 배분
System design interview 질문은 대체로 광범위하며, 45분 또는 1시간으로는 전체 설계를 다루기에 충분하지 않다. 아래는 45분 면접 세션에서의 rough estimate이다. 실제 시간 배분은 문제의 범위와 면접관의 요구에 따라 달라진다.
Step 1 - 문제 이해 및 설계 범위 확립: 3 ~ 10분
Step 2 - High-level design 제안 및 동의: 10 ~ 15분
Step 3 - Deep dive 설계: 10 ~ 25분
Step 4 - Wrap up: 3 ~ 5분핵심
Framework는 알고 있는 것을 잘 전달하기 위한 도구다. 도메인 지식 없이는 한계가 있으며, 이 책의 나머지 챕터들이 각 도메인의 표준 레퍼토리를 다루는 이유가 여기에 있다.
이 챕터에서 얻어가야 할 것
두 가지 감각을 익히는 챕터다.
첫 번째는 숫자 감각이다. 규모 추정 질문이 나왔을 때 막히지 않으려면 수치를 외우는 것이 아니라 어림잡는 습관이 필요하다. 2의 거듭제곱, latency 수치, 가용성 표는 그 감각을 기르기 위한 도구다. “DAU 1억이면 QPS가 얼마지?“를 즉각적으로 계산할 수 있는 상태가 목표다.
두 번째는 면접을 대화로 풀어나가는 태도다. 4단계 framework는 면접을 잘 보기 위한 틀이지만, 더 본질적인 메시지는 면접관이 정답을 원하는 것이 아니라 사고하는 과정을 보고 싶어 한다는 것이다. 질문하고, 가정을 세우고, 소통하면서 설계를 발전시켜 나가는 과정 자체가 평가 대상이다. 침묵하거나 혼자 달려가는 순간 면접관은 신호를 잃는다.