연결 이벤트로 계산하는 주간 화면 가동률

드문드문 기록된 연결 및 연결 해제 이벤트로 모든 화면의 주간 연결 점수를 재구성하는 Go Cloud Function입니다.

내 역할: 단독 개발. 18개 커밋 중 17개를 제가 작성했고, 일주일도 안 되어 운영 배포 준비를 마쳤습니다.

2025년 9월

• Go
• GCP Cloud Functions
• PostgreSQL

가동 시간을 재구성하기

운영팀에는 연결이 불안정한 기기를 찾기 위해 화면별 주간 점수가 필요했습니다. 고객이 문제를 신고하기 전에 상태가 가장 나쁜 화면을 확인할 수 있게 해 줍니다.

플랫폼은 가동 시간을 직접 기록하지 않습니다. 타임스탬프가 붙은 연결 및 연결 해제 이벤트만 저장하므로, 상태 변화를 따라 한 주 전체를 재구성해야 합니다. 일주일 내내 연결돼 있던 화면은 이벤트가 하나도 없을 수 있어 여기서 많은 예외 상황이 생깁니다.

제가 만든 것

두 PostgreSQL 데이터베이스에서 화면 목록과 이벤트 이력을 읽고, 모든 화면의 주간 점수를 계산한 다음, 유지보수 대시보드가 사용하는 결과를 기록하는 Go Cloud Function을 작성했습니다.

두 가지 규칙으로 어려운 경우 대부분을 처리합니다.

주가 시작되기 전 상태는 주 안의 첫 이벤트와 반대입니다. 첫 이벤트가 연결 해제라면 그 순간까지 화면은 온라인이었습니다. 연결 이벤트라면 그 전에는 오프라인이었습니다. 이를 통해 월요일 아침부터 첫 상태 변경까지의 상태를 알 수 있습니다.

이벤트가 없다고 데이터가 없는 것은 아닙니다. 한 주 동안 화면의 상태가 바뀌지 않으면 마지막으로 알려진 상태가 그 기간 내내 이어집니다. 이 처리가 없다면 계속 온라인이었던 화면과 계속 오프라인이었던 화면이 모두 빈 데이터처럼 보입니다.

쿼리 구조 수정하기

첫 버전은 화면마다 데이터베이스에 한 번씩 쿼리했습니다. 로컬 테스트에서는 동작했지만, 화면이 수천 대인 환경에서는 실행 시간에 따라 비용이 청구되는 함수 안에서 수천 번 왕복해야 했습니다.

이를 pq.Array를 사용하는 두 개의 배치 쿼리와 결과용 배치 UPDATE 하나로 바꿨습니다. 화면 수가 늘어나도 데이터베이스 요청 수는 고정돼 있으며, 점수 슬라이스는 4,096개 화면을 기준으로 미리 할당합니다.

예약 함수 디버깅하기

예약된 클라우드 함수에서는 실행 전에 기록하기로 정한 로그만 확인할 수 있습니다. 그래서 과정 전반에 구조화된 로그를 추가했습니다. 계산을 손으로 검증할 수 있도록 소수의 화면만 처리하는 DEBUG 모드와 생성된 히스토그램의 500행 제한도 넣었습니다.

수치로 보면

18개 커밋 중 17개를 제가 작성했고, 일주일도 안 되어 운영 배포 준비를 마쳤습니다. 수천 대의 화면을 처리할 때도 실행마다 두 개의 배치 쿼리와 하나의 배치 UPDATE를 두 데이터베이스에 사용합니다.