Home Assistant 리소스 예약: 인터넷 장애가 로컬 제어 동작을 바꾸는 이유

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Home Assistant Resource Scheduling: Why Internet Outages Change Local-Control Behavior

인터넷이 끊겼다고 해서 Home Assistant의 로컬 자동화가 자동으로 실패하는 것은 아닙니다. WAN이 중단된 동안에도 로컬 Zigbee, Z-Wave, Matter, ESPHome, MQTT 및 LAN 통합은 계속 작동할 수 있습니다. 달라지는 것은 이러한 통합을 둘러싼 작업 부하입니다. 클라우드 요청은 시간 초과되고, 통합은 재시도하며, DNS 조회는 실패하고, 원격 연결은 끊기며, 연결이 복구되면 복구 작업이 한꺼번에 몰릴 수 있습니다.

따라서 로컬 제어 경로가 유지되더라도 장애 중에는 리소스 스케줄링이 중요합니다. 문제는 “Home Assistant에 인터넷이 필요한가?”가 아닙니다. 실패한 원격 작업이 격리되는지, 아니면 이벤트 루프 시간, 실행기 스레드, DNS 처리 용량, 로깅 I/O 또는 통합 다시 로드를 사용하기 시작해 로컬 제어와 겹치는지가 핵심입니다.

실패한 클라우드 요청은 빠른 성공 경로를 시간 초과 경로로 바꿉니다

WAN이 정상일 때는 클라우드 요청이 빠르게 완료될 수 있습니다. 장애 중에는 같은 호출이 시간 초과 기간 동안 작업을 점유하고, 재시도하며, 오류를 기록한 뒤 반환될 수 있습니다. 몇 번의 호출은 문제가 되지 않지만, 여러 통합에서 동시에 이런 일이 발생하면 정상 작동과는 다른 스케줄링 양상이 만들어집니다.

Home Assistant의 구성 항목 수명 주기에는 준비되지 않은 종속성을 위한 명시적인 설정 재시도 상태가 있으며, 자동 시도 사이의 간격은 시간이 지나면서 늘어납니다. 정확한 실패 방식은 여전히 각 통합에 따라 다르지만, 재시도 작업은 예외적인 상황이 아니라 성능 저하 상태에서 정의된 동작의 일부입니다.

중요한 자동화가 로컬 동작을 실행하기 전에 원격 API를 기다리지 않도록 하세요. 원격 결과가 집에서 무엇을 해야 할지 결정하는 데 필요하지 않다면, 실제 동작을 실행한 후 알림, 클라우드 업데이트 또는 외부 웹훅을 전송하세요.

네트워크 시간 초과는 CPU 사용량이 높지 않아도 리소스를 점유할 수 있습니다

멈춘 네트워크 작업은 CPU를 거의 사용하지 않으면서도 작업, 연결, 스레드 또는 시간 초과 예산을 점유할 수 있습니다. 따라서 “CPU 사용률이 10%밖에 안 된다”는 사실만으로 장애에 비용이 없다고 판단할 수는 없습니다.

2026년 Home Assistant 사례에서는 반복되는 통합 시간 초과와 연쇄적인 다시 로드가 연결이 빠르게 실패하지 않고 대기하게 만든 손상된 IPv6 경로로 추적되었습니다. 증상은 원시적인 컴퓨팅 자원 고갈이 아니라 네트워크 호출 주변의 스케줄링 지연이었습니다.

대기 중인 네트워크 작업, 통합 경고, DNS 실패, 트리거부터 로컬 서비스 호출까지 걸리는 시간을 관찰하세요. 클라우드 엔터티를 사용할 수 없게 되어도 로컬 동작이 계속 빠르다면 장애가 올바르게 격리된 것입니다. 실패한 원격 호출과 함께 로컬 지연 시간이 늘어난다면 공유 런타임을 점유하고 있는 통합 또는 사용자 지정 코드를 찾아야 합니다.

비동기 대기보다 차단 작업이 더 위험합니다

Home Assistant의 핵심은 비동기 방식으로 작동하므로, 제대로 설계된 통합은 I/O를 기다리는 동안 실행을 중단하고 다른 작업이 실행되도록 할 수 있습니다. 위험한 경우는 이벤트 루프 자체를 점유하는 차단 작업이나, 잘못된 위치에서 동기식 네트워크 작업을 수행하는 사용자 지정 코드입니다.

Home Assistant 개발자 지침에서는 이벤트 루프에서 차단 작업이 실행되면 해당 작업이 끝날 때까지 다른 작업이 실행되지 않는다고 설명합니다. 인터넷 장애는 평소에는 즉시 반환되던 호출이 갑자기 긴 시간 초과를 기다릴 수 있기 때문에 이러한 취약점을 드러낼 수 있습니다.

이 때문에 사용자 지정 통합은 기본 로컬 통합이 잘 설계되어 있어도 장애가 플랫폼 전체의 속도 저하처럼 느껴지게 만들 수 있습니다. 하드웨어를 탓하기 전에 사용자 지정 구성 요소를 비활성화한 상태와 동작을 비교해 보세요.

-15% OFF

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

Single board computer zimaboard2

복구 과정에서 두 번째 작업 부하 급증이 발생할 수 있습니다

인터넷 연결이 복구되면 여러 통합이 거의 동시에 다시 연결되고, 상태를 새로 고치며, 다시 인증하고, 엔터티를 업데이트하고, 새로운 기록을 기록할 수 있습니다. 따라서 복구 구간은 장애 중간보다 더 바쁠 수 있습니다.

WAN이 복구된 직후 CPU, 네트워크 또는 Recorder 기록이 급증했다고 해서 정상적인 지속 부하를 감당할 용량이 부족하다고 단정하지 마세요. 급증이 얼마나 지속되는지, 이후 로컬 제어 지연 시간이 기준 상태로 돌아오는지를 측정하세요.

ZimaSpace의 재연결 후 보존 메시지, 대기 메시지, 검색 메시지 및 가용성 메시지에 관한 글에서도 같은 복구 원칙을 보여 줍니다. 분산된 구성 요소가 다시 연결되면 연결이 안정적일 때는 존재하지 않았던 상태를 재생하고 작업을 만들어 낼 수 있습니다.

정상 모드뿐 아니라 성능 저하 모드도 고려해 스케줄링하세요

WAN이 끊긴 동안에도 로컬 동작 감지-조명 경로는 원격 조건 없이 계속 실행되어야 합니다. 클라우드 폴링은 제한된 재시도 상태로 전환할 수 있어야 하고, 원격 알림은 실패하거나 대기열에 들어갈 수 있으며, DNS에 의존하는 서비스는 예측 가능한 방식으로 실패해야 합니다. 연결이 복구되면 짧은 새로 고침 급증이 발생할 수 있습니다.

설계 목표는 선택적 성능 저하입니다. 선택적인 원격 작업은 느려지거나 사라지더라도 로컬 제어는 평소의 타이밍 범위 안에 유지되어야 합니다. 가장 효과적인 장애 테스트는 일반적인 가정 내 작업 부하 중 WAN을 끊고, 몇 가지 중요한 로컬 자동화를 측정한 다음, 다시 연결하여 복구 급증과 기준 상태로 돌아가는 데 걸리는 시간을 모두 측정하는 것입니다.