규모 추정은 시스템 디자인의 일부분이라고 볼 수 있다. 이 시스템 디자인은 소프트웨어 시스템의 구조를 계획하고 설계하는 과정이다. 이 과정은 시스템의 요구사항을 분석하고 최적의 솔루션을 설계하여 시스템이 효울적이고 확장 가능하며 유지관리가 용이하게 만드는 것을 목표로 한다.
시스템 디자인의 첫 단계 중 하나로 시스템이 실제 환경에서 어떻게 작동할지를 예측하는데 매우 중요하다. 이를 통해서 시스템의 시스템의 성능, 비용, 확장성을 고려할 수 있다.
정확한 규모 추정을 통해 우리는 필요한 자원을 적절히 계획하고 예상치 못한 문제를 미리 방지할 수 있다.
규모 추정은 여러가지 요소를 고려해서 시스템의 요구자원을 예측하는 과정이다. 여기에는 사용자의 수 혹은 요청의 수 그리고 데이터의 양 등등이 포함된다. 이러한 요소들을 통해서 시스템이 처리해야 할 트래픽, 데이터 저장소의 크기, 네트워크 대역폭 등을 추정할 수 있다. 규모 추정에 대한 주요한 지표로는 다음과 같은 것들이 있다.
- MAU: Monthly Active Users라고 월간 활성 사용자 수를 나타낸다.
- DAU: Daily Active Users로 일간 활성 사용자 수를 나타낸다.
그리고 QPS와 TPS가 있습니다. 이 두 가지는 서로 혼용되어 사용이 되기도 한다.
- QPS: Queries Per Second로 초당 처리되는 쿼리의 수를 나타낸다. 즉 시스템의 요청 처리 능력을 보여주는 지표다.
- TPS: Transactions Per Second라고 초당 처리되는 트랜잭션의 수이다. 주로 데이터베이스의 처리 능력을 나타낸다.
구분을 해서 사용한다면 편의상 QPS는 읽기 작업, 그리고 TPS는 쓰기 작업으로 구분할 수 있다.
- Peek Users: 특정 시간대에 동시에 접속하는 최대 사용자 수를 나타낸다.
- Data Storage: 시스템이 처리해야 할 데이터의 총량을 예측할 때 사용된다.
- Bandwidth: 시스템이 초당 사용하는 네트워크 대역폭을 나타낸다.
- Latency: 지연 시간으로 요청을 처리하는데 걸리는 평균 시간을 나타낸다.
- Throughput: 단위 시간당 처리되는 작업의 양을 나타낸다.
만약 시스템에서 MAU 1000만 정도로 가정을 하고 아래 3가지 그룹에 대한 데이터를 추정을 해보도록 하겠다.
- DAU
- QPS, TPS
- Volume
먼저 DAU를 보겠다. DAU는 MAU의 10% 정도로 추정을 하려고 한다. 이는 일반적으로 간주되는 방식이고 이것은 서비스 성격에 따라 다를 수 있기 때문에 꼭 무조건 10%로 가정하는 것이 정확한 방법은 아니다. 10%보다 낮거나 높은 경우에 대비해서 시나리오별로 설계를 고려할 수 있지만 여기서는 10%로 가정을 하겠다.
즉, 1000만의 10%라고 하면 하루에 100만명의 활성 사용자가 있다고 볼 수 있다. 이어서 QPS와 TPS를 보겠다. 이 두 가지를 계산하기 전에 QPD라는 것을 먼저 확인해보겠다. QPD는 Queries Per Day로 하루에 요청되는 쿼리의 수를 나타낸다. 즉, DAU의 세션당 쿼리 수를 곱하면 이 QPD를 계산할 수 있다. 세션당 쿼리 수라는 것은 한 사용자가 로그인을 하고 이 시스템과 상호작용하는 쿼리의 수를 나타낸다. 도서관리 시스템를 예로 들면 도서를 검색했을 떄 사용자가 어떤 도서를 검색 했는지에 대한 저장도 같이 일어나게 된다. 그렇기 때문에 한 세션에서 한 번 요청을 보냈을 때는 저장 1회와 조회 1회 이렇게 일어나게 된다. 즉 세션당 쿼리수는 2번이라고 볼 수 있다. 물론 한 사용자가 딱 저만큼의 요청만 보낼 리는 없다. 말 그대로 추정치다. 편의상 두 번의 요청을 보내고 이 사람의 하루 일은 끝난다고 가정을 하겠다. 그렇게 되면 QPD는 200만(DAU * 2)이 된다.
그리고 QPS와 TPS를 구분해서 나타내기로 했기 때문에 1대1의 비율로 본다면 QPS는 100만, TPS도 100만으로 나타낼 수 있다. 물론 일반적인 웹 어플리케이션에서는 읽기와 쓰기 작업의 비율이 일반적으로 8대2 정도로 보통 읽기 작업이 훨씬 많게 된다. 하지만 저희 시스템에서는 이런식으로 가정을 하고 진행을 하겠다. 그리고 이 100만이라는 수치는 하루 동안에 일어나는 숫자이기 때문에 이것을 초당으로 계산해야 한다. 하루를 초로 변환하면 86,400초이다. 그래서 100만을 86,400으로 나누면 QPS와 TPS를 대략적으로 초당 11.57으로 추정할 수 있다. 여기서 조금 더 나아가서 Peek-QPS를 추정을 해 볼 수가 있다. 사실 TPS가 11.57이 나왔다고 해서 0시부터 23시 59분까지 일정한 트래픽으로 사용자의 요청이 들어오지는 않을 것이다. 서비스 특성에 따라서 피크 시간이라는 게 존재를 하게 되고 아마 이런 식의 그래프가 조금 더 현실적인 그래 일 것이다.
그렇기 떄문에 이 피크 시간대에 얼마나 들어오는지를 합리적으로 추정하는게 중요하다. 대략적으로 추정을 했을 때는 QPS에다가 1.2의 값을 곱해서 추정을 하는 것도 방법이다. 이것도 말 그대로 추정치이기 때문에 합리적으로 생각을 잘 해야 된다. 그래서 피크 시간대에 굉장히 많이 몰리는 그런 서비스라면 이 값을 1.2배 정도가 아니라 2배 혹은 3배까지 늘려서 계산을 해야 된다.
마지막으로 볼륨에 대해서 살펴보겠다. 한 사용자가 요청을 보냈을 때 쌓이는 데이터의 크기를 먼저 정의해보겠다. 저장되는 데이터의 항목을 먼저 살펴보면 사용자의 아이디, 검색어 정보 그리고 검색 시간(이벤트 타임)과 기타 메타데이터가 있을 수 있다. 아이디는 ASCII 문자 하나가 차지하는 메모리가 1바이트이므로, 8바이트면 핸들링이 가능하다고 가정하겠다. 그리고 검색어는 검색어 길이에 따라 다르겠지만 평균 50바이트 정도로 하도록 하겠다. 이 검색 시간은 타임스탬프 형태로 저장이 될 것이기 때문에 8바이트 정도로 핸들이 가능하기에 8바이트로 가정하겠다. 그리고 기타 메타성 정보들은 어떤게 들어갈지 디테일하게 정의를 해 볼 수도 있겠지만 대략적으로 64바이트 정도로 추정을 해보도록 하겠다. 이 4가지의 값을 모두 더했을 때는 130 바이트 정도가 된다. 그래서 한 사용자가 하루에 130바이트를 저장을 한다라고 가정을 보면 되겠다.
그리고 TPS(100만)에다가 130바이트를 곱하면 하루 동안 활성 사용자 수에 의해서 저장되는 데이터의 양을 계산해 볼 수 있다. 즉, 100만 TPS에 130바이트를 곱하면 하루 동안 저장되는 데이터의 양이 대략 130MB(130,000,000바이트) 정도가 된다. 즉 하루에 우리 시스템은 130MB 정보가 쌓인다고 볼 수 있다.
느낀 점
공부를 하면서 시스템 규모를 추정하는 것은 시스템 디자인의 중요한 부분이라는 것을 알게 되었다. 정확한 규모 추정을 통해서 시스템의 성능, 비용, 확장성 등을 고려할 수 있고, 필요한 자원을 적절히 계획하고 예상치 못한 문제를 미리 방지할 수 있다는 것을 알게 되었다.