단위

개략적 규모 추정은 설계가 현실적인지 빠르게 판단하려고 쓰는 계산법이다.

기본 순서는 가정, 공식, 계산, 설계 의미로 잡으면 된다. 먼저 사용자 수, 요청 빈도, 데이터 크기, 보관 기간 같은 입력값을 명확히 가정한다. 그다음 QPS, 저장소 용량, 네트워크 대역폭처럼 구하려는 값을 공식으로 정리하고, 숫자를 대입해 대략 계산한다. 마지막으로 그 결과가 서버 수, 캐시 필요성, 데이터베이스 선택, 샤딩 여부 같은 설계 판단에 어떤 의미가 있는지 연결한다.

정확한 수치를 맞히는 것보다 사용량, 저장소, 네트워크, 지연시간의 크기를 말이 되게 잡는 게 핵심이다. 면접에서는 결과보다 가정과 계산 과정을 또렷하게 보여주는 게 더 중요하다.

예를 들어 하루 사용자 100만 명이 있고, 사용자 1명이 하루 평균 20번 요청한다고 가정해 보자. 하루 요청 수는 2,000만 건이고, 이를 86,400초로 나누면 평균 QPS는 약 232다. 피크 시간이 평균의 10배라면 피크 QPS는 약 2,300으로 잡을 수 있다. 이 숫자를 보면 단일 서버로 버틸 수 있는지, 읽기 캐시가 필요한지, 로드밸런서 뒤에 서버를 몇 대 둘지 같은 설계 판단을 더 현실적으로 할 수 있다.

핵심은 2의 제곱수를 10진 근사치로 바꿔 기억하는 것이다.

2^10 ≈ 1KB, 2^20 ≈ 1MB, 2^30 ≈ 1GB, 2^40 ≈ 1TB, 2^50 ≈ 1PB처럼 잡으면 대규모 저장소 계산이 빨라진다. 실제 값은 1024 기준이지만, 개략 추정에서는 1000 기준으로 섞어 써도 보통 결론이 크게 달라지지 않는다. 다만 메모리 크기처럼 2의 제곱 단위가 중요한 영역은 1024 기준 감각을 유지하고, 트래픽·스토리지 과금·대략 용량 산정은 1000 기준으로 빠르게 계산해도 충분하다.

단위 감각으로는 짧은 텍스트 몇 줄은 수백 바이트에서 1KB 안팎, 작은 이미지나 긴 JSON 응답은 수십~수백 KB, 사진 한 장은 보통 몇 MB, 로그나 이벤트가 많이 쌓인 하루 데이터는 GB나 TB 단위로 커질 수 있다. 실제 값은 조금 다르지만 규모 추정에서는 이 정도 근사가 실용적이다.

핵심은 메모리는 빠르고 디스크와 먼 네트워크는 느리다는 감각이다.

L1 캐시나 메모리 접근은 나노초 단위에 가깝고, SSD는 보통 마이크로초에서 짧은 밀리초 단위, HDD는 탐색 때문에 밀리초 단위로 느려진다. 같은 데이터라도 캐시에 있느냐, 메모리에 있느냐, 디스크에 있느냐에 따라 처리량과 지연시간이 크게 달라진다. 여기에 같은 리전 내부 네트워크 왕복은 비교적 짧지만, 대륙 간 왕복은 수십~수백 밀리초까지 커질 수 있다.

이 차이를 알면 설계 선택이 달라진다. 자주 읽는 데이터는 캐시나 메모리에 두고, 디스크 접근은 배치·순차 읽기·인덱스로 줄이며, 원격 호출은 병렬화하거나 호출 횟수를 줄인다. 사용자와 먼 서버를 매번 왕복해야 한다면 CDN, 리전 배치, 비동기 처리 같은 전략을 고려해야 한다.

9의 개수는 서비스가 멈추지 않는 비율을 직관적으로 나타낸다.

99%는 연간 약 3.65일 장애를 허용하지만, 99.99%는 연간 약 52.6분 수준으로 줄어든다. 9가 하나 늘 때마다 허용 장애 시간이 급격히 줄어들기 때문에 운영 난이도와 비용도 크게 올라간다.

높은 가용성은 서버를 몇 대 더 추가하는 것만으로 달성하기 어렵다. 무중단 배포, 롤백, 헬스 체크, 자동 복구, 장애 격리, 모니터링과 알림, 장애 대응 절차까지 함께 갖춰야 한다. 그래서 9의 개수는 인프라 규모뿐 아니라 운영 체계의 성숙도를 함께 요구하는 목표다.

SLI는 실제로 재는 값이고, SLO는 그 지표의 목표치다. SLA는 고객에게 공개되는 약속이라 보통 SLO보다 느슨하게 잡는다.

공개 약속인 SLA만 맞추면 된다고 보면 운영 여유가 사라진다. 내부 목표인 SLO를 더 엄격하게 잡아야 장애가 커지기 전에 알림을 받고 대응할 수 있다. 예를 들어 SLA가 99.9%라면 내부 SLO는 그보다 높은 수준으로 두고, 에러 예산을 통해 배포 속도와 안정성 사이의 균형을 잡는다.

월간 사용자를 일간 사용자로 바꾸고, 하루 트윗 수를 초당 요청 수로 나누면 된다.

예를 들어 MAU 3억 명, 50%가 매일 사용, 사용자당 하루 2건 작성이면 하루 트윗은 3억 건이다. 하루를 대략 86,400초로 나누면 평균 QPS는 약 3500이고, 피크 QPS는 보통 2배로 잡아 약 7000으로 본다.

이 숫자는 쓰기 경로의 기본 처리량을 잡는 출발점이다. 트윗 작성, 타임라인 반영, 알림, 검색 색인처럼 쓰기 뒤에 이어지는 작업량을 추정할 수 있다. 다만 트위터류 서비스는 읽기가 쓰기보다 훨씬 많으므로, 평균·피크 쓰기 QPS를 구한 뒤에는 타임라인 조회, 캐시, 팬아웃, 읽기 복제 같은 읽기 경로 설계로 이어서 생각해야 한다.