2. 개략적인 규모 추정

서평

1장을 보고 2장부터 필기를 하기 시작하였습니다. (1장은 시간되는데로 필기 예정) 많은 사람들이 가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 많이 학습한 것으로 알고 있었습니다. 그래서 2023년도 초에 책을 구매하고 이제서야 산지 1년만에 1장부터 읽어 나가기 시작하였습니다.

오늘 작성한 2장은 이러한 규모를 어떻게 추정할 지에 대한 개략적인 규모 추정에 대한 이야기가 써져 있었습니다. 2장은 데이터엔지니어로 일하고 있는 저에게는 중요한 내용 중 하나입니다. 데이터 저장소가 얼만큼 적재될 지, 파이프라인 동작 시간은 얼마일 지 추정하여 계획을 세우는 작업을 해야 하기 떄문입니다. 특히나 현재 회사에서는 파이프라인을 구성하는데 AWS Lambda를 사용하고 있습니다. AWS Lambda 는 메모리나 타임아웃 시간 등을 직접 정해야 하기 때문에 해당 작업이 얼마만큼의 시간을 갖어야 하는 지에 따라서 최대로 제공되는 15분이 부족할 수 있습니다. (주로 API를 통한 데이터 증분 시 Network Latency 때문에 부족한 경우가 많이 발생 했었습니다. Next Cursor 😭) 시간, 메모리, CPU, GPU 등 이를 발견하고 조치를 해야지 안정적으로 데이터 파이프라인이 유지될 수 있었습니다.

특히 고가용성이나 SLA 같은 내용들이 저에게는 빅테크 기업들에서만 사용되는 것들이라 생각했었습니다. 사실은 현재 운영하고 있는 파이프라인, 서버들에도 충분히 적용할 수 있는 내용이였습니다. 이런 부분을 계산해야겠다라고 생각을 못하고 있었는데 인식을 바꾸어주어 책이 저에게 좋은 영향을 준 것 같습니다:)

---

개략적인 규모 추정(back-of-the-envelope experiments)

• 보편적으로 통용되는 성능 수치 상에서 사고 실험을 행하여 추정치를 계산하는 행위

• 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것

• 효과적으로 해 내려면, _규모 확장성_을 표현하는 데 필요한 기본기에 능숙해야 함

• 특히, 2의 제곱수나 응답 지연(latency) 값, 가용성과 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다.

2의 제곱수

• 분산 시스템에서 다루는 데이터 양은 엄청나게 커질 수 있으나, 그 계산법은 기본을 벗어나지 않음.

• 제대로 된 계산 결과를 얻으려면 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는 지를 알아야 한다.

  • 최소 단위는 1바이트 = 8비트

  • 1KB(210), 1MB(220), 1GB(230), 1TB(240), 1PB(2**50)

응답 지연(Latency) 값

• 개략적으로 응답 지연값을 참조하여 시스템을 설계할 때 소요되는 시간을 산정할 수 있다.

  • ns = nanosecond(나노초) = (1 / 10 ** 9)초

  • us = microsecond(마이크로초) = (1 / 10 ** 6)초

  • ms = milisecond(밀리초) = (1 / 10 ** 3)초

연산명	시간
L1 캐시 참조	0.5ns
분기 예측 오류(branch mispredict)	5ns
L2 캐시 참조	7ns
뮤텍스(mutex) 락/언락	100ns
주 메모리 참조	100ns
Zippy로 1KB 압축	10,000ns = 10us
1Gbps 네트워크로 2KB 전송	20,000ns = 10us
메모리에서 1 MB 순차적으로 read	250,000ns = 250us
같은 데이터 센터 내에서 메시지 왕복 지연시간	500,000ns = 500us
디스크 탐색(seek)	10,000,000ns = 10ms
네트워크에서 1MB 순차적으로 read	10,000,000ns = 10ms
디스크에서 1MB 순차적으로 read	30,000,000ns = 30ms
한 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연 시간	150,000,000ns = 150ms

• 메모리 >> 디스크

  • 디스크 탐색(seek)는 가능한 피해야 한다.

• 단순한 압축 알고리즘은 빠르다.

• 데이터를 인터넷에 전송하기 전에 가능하면 압축하라.

• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다.

가용성에 관계된 수치들

고가용성(high availability)

• 시스템이 오랜 시간 동안 지속적으로 중단없이 운영될 수 있는 능력

• 고가용성은 퍼센트(%)로 표시, 100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미

• 대부분의 서비스는 99~100% 사이의 값을 갖는다.

SLA(Service Level Agreement)

• 서비스 사업자(Service Provider)가 보편적으로 사용하는 용어

• 서비스 사업자와 고객 사이에 맺어진 합의

  • 서비스 사업자가 제공하는 서비스의 가용 시간(Uptime)이 공식적으로 기술되어 있음.

  • 아마존, 구글, 마이크로소프트 같은 사업자들은 99% 이상의 SLA를 제공한다.

• 가용시간은 관습적으로 숫자 9를 사용해 표시함, 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.00밀리초	6.05초	26.30초	5.26분
99.9999%	86.40밀리초	604.80밀리초	2.63초	31.56초

예제: 트위터의 QPS와 저장소 요구량 추정

가정

• 월간 능동 사용자(Monthly Active User, MAU): 3억명

• 50% 사용자가 트위터를 매일 사용한다.

• 평균적으로 각 사용자는 매일 2건의 트윗을 올린다.

• 미디어를 포함하는 트윗은 10% 대

• 데이터는 5년간 보관

추정

• QPS(Query Per Second) 추정치

  • 일간 능동 사용자(Daily Active User, DAU) = 3억 * 50% = 1.5억

  • QPS = DAU * 2 Tweet / 24h / 3,600s = 약 3,500

  • 최대 QPS(Peek QPS) = 2 * QPS = 약 7,000

• 미디어 저장을 위한 저장소 요구량

  • 평균 트윗 크기

    • tweet_id - 64byte

    • text - 140byte

    • media - 1MB

  • 미디어 저장소 요구량

    • 1.5B * 2 * 10% * 1MB = 30TB/day

    • 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB * 1YEAR * 5 = 약 55PB

면접 팁

• 올바른 절차를 밟는 것이 결과를 내는 것보다 중요함. 면접자가 보고 싶어하는 것은 각자의 문제 해결 능력일 것

• 계산 결과의 정확함보다 근사치가 필요한 경우 적절하게 활용하여 시간을 절약

• 가정(Assumption)은 나중에 확인할 수 있도록 필기

• 단위(MB, GB)를 붇쳐 헷갈림과 모호함을 방지

• 많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 것, 면접에 임하기 전에 이런 값들을 계산하는 연습을 미리하자.