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

기본적으로 활성 데이터베이스 파일은 컴퓨팅 장치 옆의 지연 시간이 낮은 스토리지에 두고, 스토리지 노드는 백업, 덤프, 복제본 및 아카이브에 사용하세요.

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

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

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

NAS 공유 하나를 마운트한 뒤 그 안에 모든 것을 넣지 마세요. 활성 데이터베이스 볼륨을 백업 대상 및 대용량 애플리케이션 데이터와 분리하세요. 이렇게 하면 모든 영구 데이터가 동일한 매체를 필요로 한다고 가정하지 않고 각 역할을 별도로 조정하고, 모니터링하고, 용량을 관리하고, 스냅샷을 생성하고, 복원하고, 마이그레이션할 수 있습니다.

단기간만 사용하는 브랜치 데이터베이스나 CI 테스트에서는 내구성보다 재생성 시간이 더 중요할 수 있습니다. 이러한 데이터베이스는 빠른 로컬 임시 스토리지에 두고 마이그레이션이나 정제된 시드에서 다시 생성하세요. 개발자가 매일 사용하는 서비스 데이터베이스의 경우 로컬 SSD 장애를 복구 이벤트로 간주하고, 선언한 복구 시점 목표를 충족할 수 있을 만큼 원격 복사본을 최신 상태로 유지하세요.

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

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

공개된 PostgreSQL 비교 테스트에서는 로컬 NVMe가 테스트한 네트워크 연결 클라우드 서비스보다 더 낮고 예측 가능한 지연 시간을 제공했으며, 동시에 네트워크 스토리지의 확장성과 내구성 이점도 언급했습니다. 이러한 로컬 및 네트워크 연결 PostgreSQL 벤치마크가 홈 랩 환경에서 그대로 적용된다는 보장은 없지만, 데이터베이스 배치에는 인터페이스 속도만이 아니라 워크로드 측정이 필요한 이유를 보여줍니다.

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

기본적으로 기본 데이터베이스 파일을 컴퓨팅 장치 가까이에 배치하기

개발자 한 명, 컴퓨팅 노드 하나, 적당한 규모의 데이터베이스를 사용하는 경우 로컬 미러링 SSD나 복구 가능한 로컬 볼륨이 대체로 가장 명확한 관리 경계를 제공합니다. 데이터베이스 프로세스, 데이터 파일 및 미리 쓰기 로그가 함께 장애를 일으키고, 스토리지 노드는 원격에 항상 열려 있는 파일 시스템을 호스팅하는 대신 데이터베이스를 인식하는 프로세스를 통해 백업을 받습니다.

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

복구 경로가 실제로 작동할 때만 로컬 스토리지를 사용하세요. 컴퓨팅 노드를 교체할 때 오래된 복사본을 바탕으로 추측해야 한다면 중앙 집중식 스토리지는 새로운 백업 장애를 만드는 것이 아니라 기존 백업 장애를 드러낼 수 있습니다. 데이터 경로를 최적화하기 전에 백업 및 복원 작업 흐름을 먼저 바로잡으세요.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

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

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

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

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

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

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

더 큰 아키텍처를 선택할 때는 개발 워크로드가 변화하더라도 어떤 역할을 안정적으로 유지해야 하는지 결정하는 데 ZimaSpace의 스토리지 우선 NAS와 컴퓨팅 우선 홈 서버 비교가 도움이 됩니다.

최종 설정 원칙

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