목차
비녀장머리말
봉투 뒷면 계산이라고도 알려진 봉투 뒷면 계산은 간단한 추정을 사용하여 복잡한 문제의 대략적인 값을 계산하는 방법입니다.여기서도 검토해 보겠습니다. 분산형 시스템은 네트워크를 통해 연결된 컴퓨팅 노드로 구성됩니다. 이러한 노드는 웹 서버, 애플리케이션 서버, 스토리지 서버 등 다양한 유형의 서버일 수 있습니다.
분산형 시스템을 설계할 때 각 노드가 처리할 수 있는 요청 수를 이해하는 것이 중요합니다. 동시에 필요한 노드 수와 트래픽도 결정할 수 있으므로 봉투 뒷면을 사용하여 대략적인 추정치를 계산하고 마지막으로 필요한 시스템을 설계합니다.
봉투 뒷면
실제로 분산 시스템은 네트워크를 통해 연결된 컴퓨팅 노드로 구성됩니다. 시중에 나와 있는 소프트웨어 시스템에도 다양한 컴퓨팅 노드가 있으며 다양한 방식으로 연결됩니다. 봉투 뒷면은 시스템의 세부 사항을 무시하고 이전 기사에서 언급한 추상 개념과 같은 더 중요한 측면에 집중하는 데 도움이 될 수 있습니다.
다음은 봉투 뒷면의 예입니다.
- 서버가 허용할 수 있는 동시 TCP 연결 수입니다.
- 웹 페이지, 데이터베이스 또는 캐시 서버가 처리할 수 있는 초당 요청 수(RPS)입니다.
- 서비스의 저장소 요구 사항입니다.
이러한 경우 무리한 수치가 계산되면 소프트웨어 설계 결함이 발생할 수 있습니다. 따라서 시스템을 설계할 때 기본 개념을 사용하여 대략적인 추정을 한 다음 시스템을 최적화하고 확장해야 합니다.
데이터 센터 서버 유형
데이터 센터에는 한 가지 유형의 서버만 있는 것이 아닙니다. 엔터프라이즈 솔루션은 비용을 절감하고 확장 가능한 시스템을 개발하기 위한 솔루션을 찾기 위해 데이터 센터에서 다양한 워크로드(워크로드) 서버 유형을 처리하는 데 일반적으로 사용됩니다.
웹 서버
확장성을 위해 웹 서버는 애플리케이션 서버와 분리됩니다. 웹 서버는 로드 밸런서(Work Balancer) 다음의 첫 번째 노드입니다. 웹 서버는 클라이언트 측의 API 호출을 처리하는 서버이기도 합니다. 일반적으로 메모리와 스토리지 리소스는 필요에 따라 다릅니다. 물론 일반적으로 메모리와 저장 용량이 클수록 서버가 처리할 수 있는 리소스가 더 좋아집니다. 예: Meta는 많은 계산을 충족하기 위해 32GB RAM 및 500GB 용량을 갖춘 서버를 사용합니다.
애플리케이션 서버
애플리케이션 서버는 애플리케이션 및 비즈니스 로직을 처리하는 데 사용됩니다. 그러나 일반적으로 웹 서버와 응용 프로그램 서버를 구별하기는 어렵습니다. 차이점은 다음과 같습니다. 응용 프로그램 서버는 동적 콘텐츠를 제공하는 반면 웹 서버는 주로 클라이언트 브라우저에 정적 콘텐츠를 제공합니다.
스토리지 서버
인터넷이 점점 발전함에 따라 트래픽과 규모로 인해 모든 네트워크 서비스가 저장해야 하는 데이터의 양도 폭발적으로 증가할 것입니다. 따라서 이를 처리하기 위한 스토리지 서버(전용 데이터베이스 서버로 이해 가능)가 필요합니다. 엄청난 양의 데이터. 또한 다양한 데이터 유형을 기반으로 적절한 데이터베이스를 선택해야 합니다. 예: Youtube는 다음 데이터베이스를 사용합니다.
- Blob Storage를 사용하여 컴파일된 비디오 데이터를 저장합니다.
- 특히 대량의 비디오 썸네일을 저장하려면 Bigtable을 사용하세요.
- RDBMS를 사용하여 댓글 및 좋아요 데이터와 같은 사용자 및 비디오 데이터를 저장합니다.
- SQL 및 NoSQL을 사용하여 데이터 분석을 위한 다양한 유형의 데이터를 저장합니다.
공통표준
시스템 서비스의 설계, 계획, 구현에는 막대한 자금, 시간, 인력 투자가 필요합니다. 기계가 처리할 수 있는 작업 부하 유형을 모르면 추가 설계가 어렵습니다. 지연 시간은 어떤 머신이 어떤 작업 부하에 적합한지 판단할 수 있게 해주는 매우 중요한 것입니다. Github에서 찾은 리소스, 그리고 독자들의 참고를 위해 표로 만들었습니다.
지연
프로젝트 | 시간(나노초) |
---|---|
명령 실행 | 1/1,000,000,000초 = 1나노초 |
L1 캐시에서 가져오기 | 0.5나노초 |
분기 예측 오류 | 5나노초 |
L2 캐시에서 가져오기 | 7나노초 |
뮤텍스 잠금/잠금 해제 | 25나노초 |
주 메모리에서 검색 | 100나노초 |
1Gbps 네트워크를 통해 2K 바이트 전송 | 20,000나노초 |
메모리에서 순차적으로 1MB 읽기 | 250,000나노초 |
새 디스크 위치에서 추출(탐색) | 8,000,000나노초 |
디스크에서 순차적으로 1MB 읽기 | 20,000,000나노초 |
미국과 미국 사이에 데이터 패킷 보내기 | 150밀리초 = 150,000,000나노초 |
QPS
위에 나열된 지연 시간 외에도 데이터베이스 쿼리의 양을 측정하는 QPS(초당 쿼리 수)도 있습니다.
중요한 비율 | 초당 쿼리 수(QPS) |
---|---|
MySQL에서 처리되는 QPS | 1000 |
키-값 데이터베이스 처리 QPS | 10,000 |
캐시로 처리되는 QPS | 100,000 – 100만 |
단위 수량
색인 | 근사 | 이름 | 약어 |
---|---|---|---|
10 | 천 | 킬로바이트 | KB |
20 | 백만 | 메가바이트 | MB |
30 | 10억 | 기가바이트 | GB |
40 | 일조 | 테라바이트 | 결핵 |
요청량 계산
다음으로 설명하자면, 서버가 초당 처리할 수 있는 요청 수, 즉 RPS(Requests Per Second)는 얼마입니까?
서버 내에서는 리소스가 제한되어 있으며 클라이언트 요청 유형에 따라 시스템 병목 현상이 발생할 수 있습니다.
주로 두 가지 유형의 요청으로 나눌 수 있습니다.
- CPU 바인딩된 요청: 이러한 요청을 제한하는 요소는 CPU입니다.
- 메모리 바인딩된 요청: 이러한 요청에는 메모리 제한이 적용됩니다.
CPU 바인딩된 요청
CPU 집약적인 요청에 대한 RPS를 계산하는 일반적인 공식은 다음과 같습니다.
RPS-CPU = Num-CPU x 1 / 작업 시간
그 중 각 변수의 의미는 다음과 같다.
- RPS-CPU: CPU 집약적인 RPS
- Num-CPU: CPU 스레드 수
- 작업 시간: 각 작업을 완료하는 데 필요한 시간
메모리 바인딩된 요청
메모리 집약적인 요청의 경우 다음 공식을 사용합니다.
RPS-메모리 = 작업자 메모리 / RAM 크기 x 1 / 작업 시간
그 중 각 변수의 의미는 다음과 같다.
- RPS-메모리: 메모리 집약적인 RPS
- RAM 크기: RAM 크기
- Worker-Memory: 메모리를 관리하기 위해 메모리에서 사용하는 작업자
서비스는 CPU 집약적 요청과 메모리 집약적 요청을 모두 받습니다. 요청의 절반은 CPU 집약적이고 나머지 절반은 메모리 집약적이라고 가정할 때 처리할 수 있는 총 RPS는 다음과 같습니다.
RPS = (RPS-CPU + RPS-메모리) / 2
위의 계산은 RPS 추정의 근사치를 이해하기 위한 것일 뿐입니다. 실제로는 RPS에 영향을 미치는 다른 많은 요소가 있을 수 있습니다. 예를 들어, RAM에 데이터가 없거나 데이터베이스 서버에 요청이 있는 경우 디스크 탐색(Seek)이 필요하므로 지연이 발생합니다. 기타 요인으로는 장애, 프로그램 코드 오류, 노드 장애, 정전, 네트워크 중단 등이 있으며 이는 모두 불가피한 요인입니다.
시스템 설계 인터뷰의 컴퓨팅 유형
시스템 설계 인터뷰에서는 다음과 같은 유형의 추정을 수행해야 할 수도 있습니다.
- 부하 추정: 시스템이 초당 예상할 수 있는 요청 수, 데이터 볼륨 또는 사용자 트래픽을 예측합니다.
- 스토리지 추정: 시스템에서 생성된 데이터를 처리하는 데 필요한 저장 공간의 양을 추정합니다.
- 대역폭 추정: 데이터 전송에 필요한 예상 트래픽 및 네트워크 대역폭.
- 지연 시간 추정: 응답 시간과 대기 시간을 예측하는 시스템 아키텍처 및 구성 요소입니다.
- 자원 추정: 로드를 처리하는 데 필요한 서버, CPU 또는 메모리 수를 추정합니다.
뒷표지 계산의 실제 예
부하 추정
일일 활성 사용자(DAU)가 1억 명에 달하고 각 사용자가 하루 평균 10개의 게시물을 게시하는 소셜 미디어 플랫폼을 설계한다고 가정해 보겠습니다. 로드를 계산하려면 하루에 생성된 총 게시물 수를 계산해야 합니다.
1억 DAU * 사용자당 게시물 10개 = 게시물 10억 개/일
그런 다음 초당 요청 수를 추정합니다.
게시물 10억 개/일/86,400초/일 = 요청 11,574개/초
스토리지 추정
5억 명의 사용자가 매일 평균 2장의 사진을 업로드하는 사진 공유 앱을 생각해 보세요. 각 사진의 평균 크기는 2MB입니다. 하루 동안의 사진에 필요한 저장 공간을 추정하려면 다음과 같이 계산하세요.
5억 명의 사용자* 사용자당 사진 2장* 사진당 2MB = 2,000,000,000MB/일
대역폭 추정
1080p 비디오를 4Mbps로 스트리밍하는 사용자가 천만 명인 비디오 스트리밍 서비스의 경우 필요한 대역폭은 다음과 같이 계산할 수 있습니다.
사용자 1,000만 명 * 4Mbps = 40,000,000Mbps
지연 시간 추정
여러 소스에서 데이터를 가져오는 API를 설계하려고 하며 각 소스의 평균 대기 시간이 50밀리초, 100밀리초, 200밀리초라는 것을 알고 있다고 가정합니다. 다음과 같이 대기 시간을 계산합니다.
50ms + 100ms + 200ms = 350ms
프로세스가 병렬(Parallel)인 경우 총 지연은 최대 지연이 됩니다.
최대(50ms, 100ms, 200ms) = 200ms
자원 추정
초당 10,000개의 요청을 수신하는 시스템을 설계하려면 각 요청에 10밀리초의 CPU 시간이 필요합니다. 필요한 CPU 코어 수를 계산하려면 초당 총 CPU 시간을 계산하면 됩니다.
10,000개 요청/초 * 10밀리초/요청 = 100,000밀리초/초
이때 각 CPU가 코어당 1,000밀리초를 처리할 수 있다고 가정할 수도 있습니다. 그러면 필요한 코어 수는 다음과 같습니다.
100,000ms/초 / 1,000ms/코어 = 코어 100개
결론
백 오브 엔벨로프(Back-of-the-Envelope)는 시스템 요구 사항을 신속하게 예측하는 방법이며 시스템 설계 초기 단계에서 사용할 수 있습니다. 이러한 접근 방식을 통해 효과적인 설계 결정을 내리고 후속 단계에서 문제를 피할 수 있습니다.
봉투 뒷면을 사용한 시스템 설계에 대한 몇 가지 고려 사항은 다음과 같습니다.
- 봉투 뒷면에서는 대략적인 추정만 제공할 수 있습니다. 시스템을 설계하는 실제 상황이 있는 경우 자세한 분석이 필요합니다.
- 기본 설명을 수행할 때는 하드웨어, 소프트웨어, 네트워킹을 포함하여 시스템의 모든 주요 요소를 고려해야 합니다.