Home Assistant는 언제 별도의 데이터베이스나 스토리지 호스트를 사용해야 할까요?

Home Assistant에서 별도의 데이터베이스 또는 스토리지 호스트는 측정된 용량, 보존 기간, 백업 또는 장애 도메인 문제를 해결하는 경우에만 사용해야 합니다. 컨트롤러에서 상태를 옮기는 것이 자동으로 업그레이드가 되는 것은 아닙니다.

많은 가정에서는 안정적인 SSD 스토리지에 로컬 SQLite Recorder 데이터베이스를 두는 것이 가장 간단합니다. 네트워크, 인증, DNS, 데이터베이스 서버 시작에 대한 의존성을 없앨 수 있기 때문입니다. 호스트를 하나 더 만들기 전에 실제 문제가 Recorder의 과도한 쓰기, 긴 보존 기간, 느린 기록 쿼리, 제한된 로컬 용량, 또는 서비스 하나를 독립적으로 복구해야 할 필요 중 무엇인지 먼저 파악하세요.

데이터베이스 서버를 추가하기 전에 Recorder를 튜닝하세요

Recorder의 증가량은 저장되는 엔터티와 이벤트, 변경 빈도, 기록 보존 기간에 따라 달라집니다. 쓰기의 대부분을 노이즈가 많은 센서나 불필요한 도메인이 차지한다면, 같은 워크로드를 더 큰 데이터베이스 서버로 옮겨도 문제를 해결하는 대신 위치만 바꾸게 됩니다.

최신 Recorder 튜닝 워크플로에서는 데이터베이스 이전을 고려하기 전에 보존 기간, 포함/제외 규칙, 커밋 동작이 쓰기 워크로드에 어떤 영향을 미치는지 확인할 수 있습니다. 튜닝 후 데이터베이스 크기, 기록 쿼리 시간, 스토리지 지연 시간, 쓰기 활동을 측정하세요.

조정된 워크로드에서 응답성이 유지되고, 백업이 유지보수 시간 내에 완료되며, 사용 가능한 SSD 용량에 여유가 있다면 데이터베이스를 로컬에 두세요. 분리는 클라이언트-서버 데이터베이스가 언제나 더 빠르다는 막연한 생각이 아니라, 충족되지 않는 요구 사항에 따라 결정해야 합니다.

운영상의 이점이 분명할 때 외부 데이터베이스 사용

Home Assistant가 이미 안정적으로 운영 중인 데이터베이스 플랫폼을 함께 사용하거나, 보존 기간이 길어 지속적인 쿼리 부하가 발생하거나, 컨트롤러 호스트를 가볍게 유지하거나 교체할 수 있어야 하거나, 데이터베이스 백업과 모니터링을 독립적인 수명 주기로 관리해야 하는 경우에는 별도의 MariaDB, MySQL 또는 PostgreSQL 호스트를 사용하는 것이 합리적일 수 있습니다.

SQLite에서 MariaDB로 마이그레이션하는 예시에서는 이 방식을 선택할 때 추가되는 요소를 설명합니다. 데이터베이스 서비스, 인증 정보, 네트워크 주소, 스키마 초기화, 마이그레이션 절차, 검증, 롤백이 이에 해당합니다. 실제로 진행된 더 대규모의 Home Assistant 데이터베이스 마이그레이션 사례는 오랜 기간의 기록과 대용량 데이터 세트가 추가적인 관리 작업을 감수할 만한 이유를 보여줍니다.

The ZimaSpace article on external database upgrade reliability provides the corresponding maintenance boundary: the database must be backed up, upgraded, and restored as its own service rather than treated as invisible infrastructure.

기본적으로 활성 SQLite 데이터베이스를 네트워크 공유 폴더에 두지 마세요

원격 데이터베이스 서버와 SMB 또는 NFS에 저장된 데이터베이스 파일은 서로 다른 아키텍처입니다. 클라이언트-서버 데이터베이스는 데이터베이스 서비스 내부에서 잠금과 트랜잭션을 처리하고 네트워크를 통해 요청을 주고받습니다. SQLite는 파일 시스템을 통해 데이터베이스 파일의 잠금을 처리하므로 네트워크 파일 시스템의 동작 방식, 마운트 가용성, 지연 시간, 잠금 동작이 모든 트랜잭션에 영향을 줍니다.

더 자세한 SQLite 잠금 분석에서는 네트워크 파일 시스템의 잠금 동작이 로컬 디스크와 다를 수 있는 이유를 설명합니다. Home Assistant 네트워크 공유 폴더 장애 사례는 활성 Recorder 데이터베이스가 원격 마운트에 의존할 때 발생할 수 있는 실제 위험을 보여줍니다.

백업 사본, 내보낸 파일, 미디어 및 네트워크 저장용으로 설계된 기타 데이터를 저장할 때는 NAS를 자유롭게 사용하세요. 활성 Recorder 상태 데이터를 다른 시스템에 저장해야 한다면 SQLite 파일을 공유 폴더로 옮기기보다는 지원되는 클라이언트-서버 데이터베이스를 사용하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

대용량 저장소와 활성 Home Assistant 상태 데이터 분리

늘어나는 Home Assistant 디렉터리가 모두 같은 스토리지 계층에 속하는 것은 아닙니다. 설정, 통합 상태, 활성 Recorder 데이터베이스, 미디어, 카메라 클립, 내보내기 파일, 백업은 지연 시간과 복구 요구 사항이 서로 다릅니다. 별도의 서비스가 의도적으로 관리하지 않는 한, 작고 자주 업데이트되는 상태 데이터는 지연 시간이 짧은 로컬 스토리지에 보관하세요.

대용량 미디어나 백업 세대는 안정적인 마운트 지점 뒤에 있는 NAS 용량으로 옮기세요. 해당 마운트가 없어도 Home Assistant를 부팅할 수 있는지 문서화하세요. 사진 아카이브가 없어도 조명 자동화는 시작되어야 합니다. 반면 활성 데이터베이스가 없으면 아무도 알아채지 못하는 조용한 대체 동작 대신 명시적인 성능 저하 상태가 되어야 합니다.

분리를 영구 적용하기 전에 시작, 장애, 복원을 검증하세요

기존 복구 경로를 삭제하지 않은 채 새 데이터베이스 또는 스토리지 역할을 준비하세요. Home Assistant보다 데이터베이스 호스트를 먼저 재부팅하고, 데이터베이스가 준비되기 전에 Home Assistant를 재부팅하고, 네트워크를 끊고, 인증 정보를 교체하고, 대상 파일 시스템을 여유 공간 임계치에 가깝게 채우고, 새 인스턴스에 데이터베이스를 복원하세요.

p95 기록 조회 시간, Recorder 활동이 많은 동안의 자동화 지연 시간, 재시작 시간, 백업 소요 시간, 데이터베이스 호스트 장애 후 복구 시간을 측정하세요. 분리로 지표 하나가 개선되더라도 컨트롤러 재시작이 30초에서 여러 서비스의 복구 절차로 바뀐다면, 그 운영 비용을 결정에 반영하세요.

로컬 저장소가 이미 목표를 충족한다면 그대로 사용하세요. 클라이언트-서버 데이터베이스 작업과 독립적인 복구가 실제 이점이 될 때는 별도의 데이터베이스 호스트를 사용하세요. 대용량 데이터와 백업에는 별도의 스토리지 호스트를 사용하되, 검증된 이유 없이 중요한 로컬 제어가 원격 파일 시스템에 의존하게 만들지 마세요.