관제 영역을 제어 영역과 나눈 이유
관제 화면이 관리 VPC의 EKS와 Argo CD를 직접 부르면 네트워크와 API 호출은 단순합니다. 하지만 화면이 제어 기능에 닿을 수 있고 장애 범위도 겹칩니다. 그래서 두 영역을 네트워크로 잇지 않고 DynamoDB와 S3에 저장된 결과만 조회하게 했습니다. 대신 제어 영역을 바로 조회하는 편의는 포기했고, 화면에 필요한 값은 팀원과 정한 형식으로 먼저 저장돼야 합니다.
설계와 검증 근거 보기 ↗문제 해결 과정
504를 막은 임시 조치가 위험 신호를 가렸습니다
응답만 돌아오게 만든 조치가 관제 화면의 목적을 해치고 있었고, 조회 구조를 다시 나눠 해결했습니다.
-
1문제
24시간 이력 조회에서 504 연쇄 발생
3개 공장의 24시간 이력을 함께 열면, 3초마다 쌓이는 이력을 한꺼번에 읽느라 백엔드의 동시 조회 한도가 가득 차 504가 연달아 났습니다.
-
2임시 조치
최신 500건만 읽도록 제한
제가 한 번에 읽는 양을 최신 500건으로 줄이자 504 없이 응답이 돌아왔습니다.
-
3새 문제
지나간 위험 신호가 사라짐
500건은 1시간 이력도 다 담지 못했습니다. 앞서 점수가 급락했다가 회복된 구간이 차트에서 빠져, 지나간 위험을 확인하는 이력 화면의 목적을 채우지 못했습니다.
-
4해결
조회 기간별로 읽는 방식을 나눔
팀원과 방식을 정해 1시간은 원본(최대 2,000건, 새 데이터만 이어 받기), 6, 12, 24시간은 팀원이 만든 5분 집계를 읽게 했습니다. 평균과 최솟값을 함께 표시해 급락이 평균에 묻히지 않게 했고, 회귀 테스트로 확인했습니다.
