컨테이너가 실행 중이지만, 실제로 제 기능을 하는지 어떻게 알 수 있을까요?

최근 인보이스(invoice)가 고객에게 전달되지 않는 문제에 대한 논의를 들으면서, 우리가 '셀프 호스팅 서비스가 건강하다'고 말할 때 정확히 무엇을 의미하는지에 대해 생각하게 되었습니다. 컨테이너는 실행 중일 수 있습니다. 로그인 페이지도 로드될 수 있고, HTTP 모니터는 계속 성공을 보고할 수 있습니다. 하지만 애플리케이션을 설치한 원래의 작업은 작동을 멈췄을 수도 있습니다. 이 간극은 특히 백그라운드에서 조용히 작동하는 서비스들—사진 업로드, 문서 처리, 파일 동기화, 예약 백업, 그리고 발신 이메일—에 있어 매우 중요해 보입니다. 아무도 애플리케이션을 정기적으로 열어보지 않으면, 실패는 누군가 결과를 필요로 할 때까지 눈에 띄지 않은 채 남아 있을 수 있습니다.

저는 사람들이 집에서 구축한 환경을 또 다른 대규모 인프라 프로젝트로 만들지 않으면서 이 간극을 어떻게 모니터링하는지에 관심이 있습니다. 녹색 상태 표시등 뒤에는 여러 가지 다른 질문들이 숨어 있다고 생각합니다. 첫째, 프로세스가 살아 있습니까? 컨테이너 상태와 리소스 메트릭(resource metrics)이 이를 돕습니다. 둘째, 클라이언트가 서비스에 접근할 수 있습니까? DNS, TLS, HTTP 체크, 응답 시간이 도움이 됩니다. 셋째, 애플리케이션이 유용한 작업을 수행할 수 있습니까? 마지막으로, 예상했던 결과가 실제로 필요한 곳에 나타났습니까? 이 점검들은 서로 다른 증거를 제공합니다.

Docker의 건강 검사(health check)는 그 뒤에 있는 명령어만큼이나 유용할 수 있지만, 그 의미는 그 명령어가 무엇을 테스트하는지에 따라 달라집니다. 페이지를 확인하는 것과 워커가 큐잉된 문서를 성공적으로 처리했는지 확인하는 것은 전혀 다른 것을 말합니다.

작은 환경의 경우, 제가 제안하는 시작점은 서비스별로 한 가지 중요한 워크플로우(workflow)를 선택하고 그 성공 조건을 명시적으로 정의하는 것입니다. 문서 애플리케이션의 경우, 무해한 샘플 문서를 가져와서 텍스트가 검색 가능하게 되는지 확인하는 것이 될 수 있습니다. 파일 동기화의 경우, 작은 테스트 파일이 합리적인 시간 내에 목적지에 손상 없이 도달하는지 검증할 수 있습니다. 사진 서비스의 경우, 테스트 업로드가 실제로 사용되는 클라이언트를 통해 보이는지 확인하는 것일 수 있습니다. 이메일은 조금 더 주의가 필요합니다.

애플리케이션이 '전송됨'을 보고하거나 SMTP 서버가 메시지를 수락하는 것이 사람이 받은 편지함에서 그것을 찾았다는 것을 증명하지는 않습니다. 전용 테스트 메일박스는 해당 메시지가 특정 목적지에 도달했다는 증거를 제공할 수는 있지만, 여전히 모든 클라이언트나 모든 제공업체에 전달되었음을 증명하지는 못합니다. 핵심은 각 검사가 무엇을 확립하는지 결정하는 것이지, 모든 단계에 똑같이 안심시키는 라벨을 붙이는 것이 아닙니다. 예약된 작업의 경우, 마지막 시도와 마지막 성공 완료를 구분하고 싶습니다. 작업이 예정대로 실행되더라도 매번 실패할 수 있습니다. 유용한 신호에는 마지막 성공 시간 스탬프, 가장 오래된 대기 항목의 나이, 또는 테스트 항목이 워크플로우를 통과하는 데 걸리는 시간이 포함될 수 있습니다. 하지만 조용한 서비스(quiet services)에는 복잡성이 따릅니다. 활동이 없다는 것이 반드시 실패를 의미하지는 않습니다. 만약 이번 주에 아무도 사진을 업로드하지 않았다면, 오래된 처리 시간 스탬프가 완벽하게 정상일 수 있습니다. 바로 이런 곳에서 작은 합성 테스트(synthetic test)가 도움이 될 수 있지만, 그것 자체로 유지보수 또한 만들어냅니다. 테스트 데이터는 실제 데이터와 분리되어야 합니다. 검사는 실제 고객에게 메시지를 보내거나, 진정한 인보이스를 생성하거나, 가족 구성원의 라이브러리를 반복적으로 변경하는 것을 피해야 합니다. 제한된 권한과 명확한 정리 정책을 가진 전용 계정이나 테스트 목적지가 더 바람직해 보입니다. 또한 빈번한 검사는 가볍게 유지해야 합니다. 작은 작업을 정기적으로 테스트하고 업그레이드 후에 더 긴 워크플로우를 실행하는 것이 매분 전체 브라우저 여정을 실행하는 것보다 나은 타협일 수 있습니다. 백업도 별도의 구분이 필요합니다. 성공적인 백업 작업은 유용한 증거이지만, 데이터를 복원할 수 있는 것은 별개의 문제입니다. 모니터링 시스템 또한 실패할 수 있습니다. 애플리케이션과 유일한 모니터가 같은 호스트에서 실행된다면, 그 호스트를 잃는 것이 둘 다 침묵하게 만들 수 있습니다. 중요한 무언가를 위해, 모니터링되는 대상이 사용 불가능할 때 알림 경로가 여전히 작동할 수 있는지 고려해 볼 것입니다. 모든 취미 애플리케이션에 이 모든 것이 필요하다고 생각하지 않습니다.

만약 상태 확인(check)을 유지하는 데 드는 시간이 간헐적인 실패가 초래할 비용보다 더 크다면, 수동 점검이 완전히 합리적일 수 있습니다. 하지만 사람들이 의존하는 서비스의 경우, 단순히 연결 가능성만을 확립하는 지표들로 가득 찬 페이지보다는 의미 있는 결과 확인(outcome check)이 더 가치 있어 보입니다. 저는 이 접근 방식들을 비교 테스트한 적은 없지만, 생각할 방식을 제안하고 실제 어떤 것이 효과적이었는지 듣고 싶습니다. 실제 기능은 고장 났는데도 건강해 보였던 서비스는 무엇인가요? 결국 어떤 확인 절차가 이를 포착했나요? 업그레이드 후에는 테스트 트랜잭션(test transactions), 애플리케이션 메트릭(application metrics) 중 어느 것을 사용하시나요? 합법적인 비활동 기간은 어떻게 처리하시나요? 심층 모니터링이 그만한 가치가 없었던 경우는 언제였나요? submitted by /u/Zestyclose-Coach2335 [link] [comments]