개발자는 데이터베이스를 컴퓨팅 노드에 둘까요, 스토리지 노드에 둘까요?

기본적으로 활성 데이터베이스 파일은 컴퓨팅 리소스 가까이에 있는 저지연 스토리지에 두고, 스토리지 노드는 백업, 덤프, 복제본 및 아카이브에 활용하세요.

스토리지 노드가 의도적으로 설계된 블록 스토리지 경로, 측정된 지연 시간, 올바른 내구성 보장, 그리고 추가 종속성을 감수할 만한 복구상의 이점을 제공한다면 기본 방침은 달라집니다. 결정은 단순히 로컬 용량과 네트워크 용량 중 하나를 고르는 문제가 아닙니다. 트랜잭션 로그, 데이터 파일, 백업, 애플리케이션 업로드 파일, 폐기해도 되는 테스트 데이터베이스는 각각 쓰기 패턴과 장애 발생 시 결과가 다릅니다.

데이터베이스 상태와 덤프 및 백업 분리하기

노드를 선택하기 전에 데이터베이스 관련 경로를 모두 파악하세요. 기본 데이터 디렉터리와 트랜잭션 로그는 활성 상태 데이터이므로 일관된 쓰기 순서와 예측 가능한 지연 시간이 필요합니다. 논리 덤프, 기본 백업, 보관된 로그, 내보낸 데이터, 애플리케이션에 업로드된 파일은 액세스 패턴이 다르므로 네트워크를 통해 전송해도 안전한 경우가 많습니다.

NAS 공유 폴더 하나를 마운트해 모든 데이터를 그 안에 넣지 마세요. 활성 데이터베이스 볼륨을 백업 대상 및 대량 애플리케이션 데이터와 분리하세요. 그러면 모든 영구 데이터를 같은 미디어에 저장해야 하는 것처럼 취급하지 않고도 각 역할에 맞게 설정, 모니터링, 용량 관리, 스냅샷 생성, 복원 및 마이그레이션을 할 수 있습니다.

수명이 짧은 브랜치 데이터베이스나 CI 테스트에서는 내구성보다 재구축 시간이 더 중요할 수 있습니다. 이런 데이터베이스는 빠른 로컬 스크래치 스토리지에 두고 마이그레이션이나 익명화된 시드 데이터로 다시 만드세요. 개발자가 매일 사용하는 서비스 데이터베이스라면 로컬 SSD 장애를 복구 상황으로 간주하고, 선언한 복구 시점 목표를 충족할 만큼 원격 사본을 최신 상태로 유지하세요.

노드를 선택하기 전에 쓰기 경로 측정하기

데이터베이스 성능은 순차 처리량만으로 결정되지 않습니다. 동기 커밋 지연 시간, 무작위 읽기 및 쓰기, 백업 트래픽이 있을 때의 큐 깊이, 네트워크 경로가 멈출 때의 동작을 측정하세요. 10GbE 링크는 대용량 파일을 빠르게 전송할 수 있지만, 모든 트랜잭션에 지연 시간과 또 다른 장애 지점을 추가할 수도 있습니다.

공개된 PostgreSQL 비교 결과에 따르면, 로컬 NVMe는 테스트한 네트워크 연결 클라우드 서비스보다 지연 시간이 낮고 예측 가능성이 높았습니다. 다만 네트워크 스토리지의 탄력성과 내구성 이점도 언급했습니다. 이러한 로컬 및 네트워크 연결 PostgreSQL 벤치마크가 홈랩에서도 동일한 결과를 보장하는 것은 아니지만, 데이터베이스 배치는 인터페이스 속도만이 아니라 실제 워크로드 측정값을 바탕으로 결정해야 하는 이유를 보여줍니다.

서비스에 사용할 계획과 동일한 파일시스템, 동기화 설정, 데이터베이스 버전, 데이터 세트 및 동시성 조건으로 대표 테스트를 실행하세요. 테스트 중에는 스토리지 네트워크에서 대용량 백업이나 미디어 전송을 시작하세요. 꼬리 지연 시간이나 커밋 시간이 불규칙해진다면, 중앙 스토리지가 공유 경로의 문제를 보완하지 못하고 있는 것입니다.

기본 데이터베이스 파일은 기본적으로 컴퓨팅 노드 가까이에 배치하세요

개발자 한 명, 컴퓨팅 노드 한 대, 중간 규모 데이터베이스를 사용하는 경우, 로컬 미러링 SSD 또는 복구 가능한 로컬 볼륨을 사용하면 소유 및 관리 범위가 가장 명확해집니다. 데이터베이스 프로세스와 데이터 파일, 쓰기 선행 로그가 함께 중단되고, 스토리지 노드는 원격에서 항상 열려 있는 파일시스템을 호스팅하는 대신 데이터베이스 인식 프로세스를 통해 백업을 받습니다.

로컬에 배치한다고 해서 보호되지 않는 부팅 드라이브 하나만 사용하라는 뜻은 아닙니다. 가능하면 데이터베이스 볼륨을 OS와 분리하고, 여유 공간과 드라이브 상태를 모니터링하며, 유지 관리 작업을 위한 용량을 확보하고, 업그레이드 전에 백업을 내보내세요. 스케줄러가 상태 데이터 없이 다른 노드에서 데이터베이스를 시작하지 않도록 컨테이너 또는 VM 배치를 고정하세요.

실제 복구 경로가 있을 때만 로컬 스토리지를 사용하세요. 컴퓨팅 노드를 교체할 때 오래된 복사본을 두고 추측해야 한다면, 중앙 스토리지가 기존 백업 실패를 야기하는 것이 아니라 드러내는 것일 수 있습니다. 데이터 경로를 최적화하기 전에 백업 및 복원 절차를 바로잡으세요.

Featured

ZimaBoard 2 - 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

백업, 복제본 및 아카이브에는 스토리지 노드를 사용하세요

스토리지 노드는 애플리케이션 일관성이 유지된 덤프, 기본 백업, 보관된 트랜잭션 로그, 변경 불가능한 스냅샷 또는 자체 복구 목적이 있는 데이터베이스 복제본을 저장할 때 유용합니다. 지연 시간에 민감한 데이터베이스 카탈로그와 로그는 로컬에 유지하면서 대용량 첨부 파일이나 분석용 내보내기 파일을 저장할 수도 있습니다.

스토리지 서버에서 NFS를 통한 PostgreSQL을 테스트한 커뮤니티에서는 보편적인 해답 대신 직관에 어긋나는 결과와 설정 관련 의문이 나왔습니다. 따라서 원격 기본 저장소는 설계된 예외로 취급해야 합니다. 정확한 스택에서 동기화 동작, 장애 처리, 마운트 옵션, 캐시 의미 및 복구를 검증하세요.

장애 복구 및 마이그레이션 기준 검증

다음 네 가지 상황을 테스트하세요. 데이터베이스를 정상적으로 재시작하고, 쓰기 도중 컴퓨팅 노드를 강제 종료하고, 백업 중 스토리지 링크를 끊고, 빈 호스트에 복원하세요. 복구 시점, 복구 시간, 데이터베이스 무결성 검사 및 애플리케이션 재연결 동작을 확인하세요. 정상 상태에서 벤치마크가 빠르다고 해서 쓰기 중단 경로가 안전하다는 뜻은 아닙니다.

활성 데이터의 지연 시간이 예측 가능하고, 백업이 기본 저장소를 덮어쓰거나 교착 상태에 빠뜨릴 수 없으며, 문서화되지 않은 스토리지 전제 없이 교체 컴퓨팅 노드에서 복원할 수 있으면 설정을 통과한 것입니다. 측정된 복구 또는 이동성 이점이 네트워크 의존성보다 클 때만 기본 파일을 설계된 스토리지 서비스로 옮기세요. 테일 지연 시간이나 링크 중단이 주요 장애 원인이 되면 다시 로컬로 옮기세요.

더 큰 아키텍처를 선택할 때는 스토리지 우선 NAS와 컴퓨팅 우선 홈 서버에 대한 ZimaSpace 비교를 참고해 개발자 워크로드가 바뀌어도 어떤 역할을 안정적으로 유지할지 결정하세요.

최종 설정 규칙

활성 데이터베이스 파일은 보호된 로컬 SSD 저장소를 기본으로 사용하고, 스토리지 노드는 검증된 백업, 아카이브 및 엄선된 복제본에 사용하세요. 원격 기본 저장소는 쓰기 동작, 테일 지연 시간, 중단 시 동작 및 복구 이점을 측정한 후에만 선택하세요.