세 가지 사용량부터 더한다
둘 다 AMD EPYC 7543P, 32코어 / 64스레드, 2.8–3.7 GHz입니다. 128GB는 월 $449, 256GB는 월 $599입니다. 메모리는 둘 다 DDR4-3200 ECC RDIMM입니다. 주문할 때 정하며, 나중에 모듈을 추가할 수 없습니다. 운영 DB와 캐시를 한 대에 둘지는 결제 전에 계산합니다. 이후에 올라갈 세 번째 용량은 없습니다.
한 대에서 메모리는 적어도 세 갈래로 나뉩니다. 첫째는 운영체제, 페이지 캐시, 연결 자체이고, SSH로 들어온 뒤의 관리 프로세스도 포함합니다.
둘째는 데이터베이스가 상주시킬 핫 데이터입니다. MySQL에서는 주로 InnoDB 버퍼 풀이고, PostgreSQL에서는 shared_buffers에 OS가 남겨 두는 페이지 캐시가 더해집니다.
셋째는 Redis나 다른 캐시의 maxmemory입니다. 애플리케이션도 이 서버에서 돌리면 그 상주 메모리를 또 뺍니다.
셋을 더하고 여유를 남긴 뒤에 128과 256을 비교합니다. 디스크에 있는 데이터베이스 용량을 메모리 요구로 그대로 쓰지 않습니다. 데이터 디렉터리가 400GB여도 실제로 자주 읽는 핫 데이터는 수십 GB일 수 있습니다. 반대로 디렉터리는 작은데 캐시가 객체 대부분을 메모리에 올려야 하면 128GB가 먼저 부족합니다. 보는 것은 핫 셋과 캐시 목표이지, 디렉터리 총량이 아닙니다.
ECC와 코어 수는 두 구성이 같습니다. 월 $150의 차이는 메모리만 삽니다. 256GB를 골라도 코어는 늘지 않고, 128GB를 골라도 CPU가 싸지지는 않습니다.
이 글은 Linux의 MySQL, PostgreSQL, Redis를 기준으로 합니다. Windows Server를 고르면 SQL Server 메모리 상한은 따로 계산합니다. 아래 버퍼 풀 비율을 Windows에 그대로 옮기지 않습니다. Linux에서는 SSH로 들어가 설정을 바꿉니다. 접속 방식은 메모리가 커도 달라지지 않습니다.
128GB로 충분한 경우
128GB로 충분한 것은 아래가 함께 성립할 때입니다. 핫 데이터가 버퍼 풀에 들어가고 히트율이 이미 안정적입니다. Redis는 세션, 핫 키, 또는 크기가 정해진 객체 캐시만 두며 목표는 대략 8GB에서 24GB이고, 제거는 받아들일 수 있는 범위입니다. OS, 연결, 같은 서버의 앱을 더해도 약 16GB에서 24GB가 남습니다. 앞으로 반년 동안 핫 데이터가 두 배가 되지 않고, 또 다른 큰 메모리 서비스를 올리지 않습니다.
이것은 대략적인 계산이지 이 서버의 용량 약속이 아닙니다. 128GB에서는 먼저 약 20GB를 OS와 연결에 남깁니다. Redis를 16GB로 잡으면 데이터베이스에는 약 90GB가 남습니다. MySQL 버퍼 풀은 64GB에서 80GB에서 시작하고, 페이지 캐시와 임시 정렬의 틈을 남깁니다. Redis가 수 GB이면 풀을 80GB 가까이 둬도 됩니다. Redis가 이미 24GB라면 풀을 80GB 위로 밀지 않습니다.
PostgreSQL은 shared_buffers를 MySQL 버퍼 풀보다 낮게 두는 경우가 많습니다. 흔한 시작점은 물리 메모리의 약 4분의 1이고, 나머지는 OS 페이지 캐시에 맡깁니다.
같은 핫 데이터라면 128GB에 남을 수 있습니다. 조건은 동시 정렬과 해시 집계가 work_mem을 큰 피크로 만들지 않는 것입니다.
쿼리 하나에 정렬 노드가 여러 개일 수 있고, 동시에 도는 쿼리 수를 곱합니다. 64MB에 수십 개의 동시 작업은 대개 여유 안에 있습니다. work_mem을 수백 MB로 열고 백 개가 넘는 동시 작업을 겹치면 128GB의 빈자리가 사라집니다.
256GB를 고르는 경우
아래 중 하나라도 해당하면 256GB를 봅니다. 버퍼 풀만 80GB 안팎이 필요한데 Redis도 수십 GB가 필요합니다.
지금 서버에서 데이터베이스 프로세스와 캐시 프로세스의 상주 메모리가 이미 90GB에 가깝거나 넘습니다.
PostgreSQL에서 동시 정렬이 많고, work_mem에 동시성을 곱하면 여유가 찹니다.
운영 DB와 Redis 외에 검색 엔진이나 힙을 크게 쓰는 서비스를 같은 서버에 둡니다. 앱을 분리하지 않았고 앱만 십수 GB가 필요합니다.
256GB 계산도 먼저 24GB에서 32GB를 OS와 연결에 남깁니다. Redis가 32GB에서 48GB이면 버퍼 풀은 120GB에서 160GB에 둘 수 있습니다. 이것은 시작점입니다. 오픈 뒤 히트율, 임시 파일, Redis 제거 횟수를 보고 상한을 되돌립니다. 물리 메모리의 약 90퍼센트를 버퍼 풀에 주고 같은 서버에서 큰 Redis를 돌리지 않습니다. 둘이 함께 커지면 스왑이 시작되고, 디스크 미스보다 원인을 보기 어렵습니다.
월 요금 차이는 $150입니다. 분기는 $1,347 대 $1,797, 반년은 $2,694 대 $3,594, 연간은 $5,388 대 $7,188입니다. 기간은 월 요금에 개월 수를 곱할 뿐입니다. 256GB를 골라도 할인은 붙지 않습니다. 메모리가 부족해 데이터베이스를 옮기는 비용은 대개 이 $150보다 큽니다. 현재 사용량이 128GB 수위에 가깝다면 주문할 때 256GB를 고릅니다. 핫 데이터가 모여 있고 히트율이 높으며 캐시가 아직 8–24GB이면 128GB에 남깁니다.
지금 숫자로 맞춰 본다
운영 중이거나 이전 서버에서 잰 숫자를 표에 넣습니다. 오른쪽 열에 하나라도 맞으면 256GB로 준비합니다. 다섯 줄이 모두 왼쪽이면 이번 주문은 128GB로 충분합니다.
| 지금 잴 수 있는 것 | 128GB에 가깝다 | 256GB에 가깝다 |
|---|---|---|
| 핫 데이터 | 버퍼 풀이 감당하고 히트율이 안정적이다 | 핫 데이터 자체가 100GB에 가깝거나 넘는다 |
| Redis / 캐시 | 핫 키나 세션이 8–24GB | 수십 GB가 더 필요하고 버퍼 풀도 크다 |
| 연결과 정렬 | 연결 수를 통제할 수 있고 정렬이 디스크로 잘 안 넘친다 | work_mem × 동시성이 여유를 채운다 |
| 같은 서버의 다른 프로세스 | 주로 운영 DB와 이 캐시 | 앱, 검색, 또는 두 번째 메모리 서비스도 있다 |
| 앞으로 반년 | 핫 데이터가 두 배가 되지 않는다 | 현재 사용량이 이미 90GB에 가깝다 |
히트율이 높고 제거를 받아들일 수 있으며 핫 데이터가 모여 있으면 128GB에 남깁니다. 디스크로 메모리를 대신하고 있거나, Redis가 아직 필요한 키를 버리고 있으면 256GB를 고릅니다. 숫자가 애매하면 이전 서버의 상주 메모리에 1.3을 곱해 성장 여유를 본 뒤 128과 256을 비교합니다. 약 100GB 아래이면 이번은 128GB입니다. 100GB를 넘으면 256GB입니다.
설치 뒤에 상한을 고정한다
용량을 정한 뒤에도 데이터베이스와 캐시의 상한을 설정에 적습니다. 상한이 없으면 InnoDB와 Redis가 각자 기본값으로 같은 물리 메모리를 차지합니다.
-
1
숫자 세 개를 적는다
데이터베이스 상주 메모리, Redis
used_memory, OS가 아직 쓸 수 있는 메모리. MySQL은 버퍼 풀 읽기 히트, Redis는used_memory와evicted_keys, PostgreSQL은 캐시 히트와 임시 파일을 봅니다. -
2
풀과 maxmemory를 따로 막는다
한 서버에서는 Redis가 작지 않다면 InnoDB 버퍼 풀을 물리 메모리의 약 60–70% 안에 둡니다. Redis에는
maxmemory와 제거 정책을 넣습니다. 두 상한이 동시에 있어야 합니다. -
3
페이지 캐시 틈을 남긴다
버퍼 풀과 Redis 상한의 합은 물리 메모리에서 OS와 연결을 뺀 값보다 낮아야 합니다. 128GB에서는 합을 약 100GB 이하로 시험합니다. 256GB에서는 약 210GB 이하로 시험합니다.
-
4
오픈 일주일 뒤에 다시 본다
스왑이 계속 오르면 상한이 큰 것입니다. 버퍼 풀이나 Redis를 먼저 줄이고 히트율을 봅니다. 디스크 읽기가 보인다고 메모리 선택이 틀렸다고 단정하지 않습니다.
버퍼 풀을 물리 메모리의 약 80%보다 높게 두고 큰 Redis를 같이 돌리면 스왑이 시작됩니다. 두 상한을 더한 뒤 물리 메모리를 넘지 않는지 확인하고 서비스를 다시 시작합니다.
디스크를 더해도 메모리는 늘지 않는다
기본 디스크는 2 × 1TB NVMe이고 하드웨어 RAID는 없습니다. 두 장은 각각 직결이며 쓸 수 있는 용량은 2TB입니다. 핫 데이터가 메모리에 들어가지 않는 읽기는 이 디스크로 내려갑니다. NVMe는 미스를 받아 줍니다. 지연은 메모리 히트보다 높습니다. 추가 2TB는 장당 월 $79, 최대 두 장, 역시 직결입니다. 늘어나는 것은 용량이지 메모리 모듈이 아닙니다. 데이터 파일과 백업을 어떻게 나눌지는 디스크 계획입니다. 메모리를 고를 때 「디스크를 한 장 더」로 256GB를 대신하지 않습니다.
대역도 버퍼 풀을 채우지 않습니다. 기본은 250M, 트래픽 무제한입니다. 1G는 +$250, 2G는 +$750이며 바뀌는 것은 출구 속도입니다. 운영 DB와 로컬 Redis 사이 통신은 루프백이라 이 대역을 쓰지 않습니다. 메모리와 대역은 별도 항목입니다. 백업을 서버 밖으로 보내야 하면 그 전송으로 250M이 충분한지 봅니다. 그것은 다른 선택입니다.
메모리를 정한 뒤 직결 디스크 두 장에 데이터를 어떻게 둘지 봅니다. 하드웨어 RAID가 아닙니다. 나누는 방법은 디스크 직결 글에 있습니다.
두 구성 중 어디에 해당하는가
핫 데이터, 캐시, 여유를 더한 뒤 주문 화면에는 이 두 구성이 있습니다. 128GB는 월 $449, 256GB는 월 $599입니다.
CPU는 둘 다 EPYC 7543P, 32코어 / 64스레드, 2.8–3.7 GHz입니다. 메모리는 둘 다 DDR4-3200 ECC RDIMM이며 주문 때 정하고 나중에 모듈을 추가하지 않습니다.
서버는 일본 도쿄에 있습니다. Linux는 SSH로 들어가 버퍼 풀과 maxmemory를 바꿉니다. 설치비는 없습니다.
낼 금액은 월 요금에 개월 수를 곱한 값입니다. 월, 분기, 반년, 연간에 추가 할인은 없습니다. 이 서버의 디스크 추가와 대역도 같은 기간으로 선납합니다.
합이 256GB로 여유 있게 담기는 범위를 이미 넘었다면, 큰 버퍼 풀, 큰 캐시, 검색 힙, 애플리케이션을 한 대에 억지로 넣지 않습니다. 캐시나 검색을 두 번째 서버로 나눕니다. 모든 상한을 천장까지 쓰는 것보다 분명합니다. 이 글은 주문할 수 있는 두 용량 중에서 이번 선택을 돕는 글입니다.