2장 개략적인 규모 측정

이번 장은 개략적인 규모 측정에 관련한 간단한 팁입니다. 킬로바이트 부터, 기가바이트 테라바이트, 페타바이트는 종종 나올 수 있다고 생가합니다. 일상 생활에서는 테라바이트 까지만 해도 충분하지만, 실무에 데이터를 다루는 데에 있어서 페타바이트 까지 도달하는 경우가 있는 경우를 들었습니다. 각 데이터는 2^10 을 기준으로 대략 1,000이므로(~1024) 1천씩 증가한다고 보면 됩니다.

그리고 응답 지연 값입니다. L1 캐시가 대략 L2캐시 보다 빠르다고 알지만 정확히 몇배가 빠른지는 잘 모릅니다. 2010 자료에 의하면 14배 정도 빠르네요. 그리고 뮤텍스락/언락은 100ns에 이루어집니다. 가장 느린 것은 패킷 왕복지연 시간으로 150ms 입니다. 데이터를 전송하기 위해선 먼저 압축을 하는게 필수적일 것입니다.

그 다음은 가용률입니다. SLA서비스 사업자가 보편적으로 사용하는 용어입니다. 아마존 , 구글, 마이크로소프트와 같은 사업자는 99%이상의 SLA를 제공합니다. 관습적으로 9로 표현하는데, 아래 표는 9의 개수와 시스템 다운 타임 사이의 관계입니다.

다음은, 트위터 QPS와 요구량 추정치입니다. mau가 3억일 경우, 그리고 50% 사용자가 매일 사용 하는 경우, dau는 3억에서 30을 나눈 것이 아닌 3억 *0.5 입니다. 그래서 dau는 1.5억이고, 해당 사용자들이 매일 2건을 올린다면 총 3억 건이 될 것입니다. 여기서(3억 나누기 2400 나누기 3600) 를 한다면 3500입니다. 그래서 query per second는 3500입니다. peek qps는 해당 값에 2를 곱한 것인데 왜 2를 곱한 건진 확실친 않으나, 아마 dau가 맥시멈인 경우 3억명이므로 해당 값에 2를 곱한 듯 합니다.

그리고 미디어 추정량입니다. 미디어가 1MB입니다. dau 1.5억명이며, 2번 트윗을 올리므로, 최대 3억번 트윗을 올립니다. 그중 *10% * 1MB = 즉 30TB/일 입니다. 5년간 미디어를 보관하기 위한 저장소 요구량은 30TB * 365 * 5 =약 55PB 입니다.

 

마지막으로 팁이니다. 근사치를 활용하고, 가정은 적어둬야합니다. 단위를 확실히 붙여두고, QPS, Peek QPS, 저장소 요구량, 캐시 요구량, 서버 수등을 추정하는 것을 연습하는게 중요합니다.