전자해도 서비스 운영 스택·관리 대시보드
전자해도 이미지 서비스를 컨테이너 묶음으로 나눠 정리하고, 상태를 한 화면에서 보는 관리 대시보드와 자동 복구·모니터링을 붙여 운영하고 있습니다.
- 기간
- 2025.08 ~ 현재
- 분류
- 사내
- 역할
- 운영 스택·대시보드
- 문제
- 서비스가 늘면서 무엇이 어디서 도는지, 왜 멈췄는지를 서버에 들어가 봐야만 알 수 있었습니다. 요청이 응답 상태와 무관하게 돌아가며 배정되고, 프로세스가 멈춰도 알아채지 못하며, 컨테이너를 통째로 저장하는 방식이라 빌드가 실패하고 용량이 늘었습니다.
- 담당
- 컴포즈 스택 구성과 관리 대시보드 개발, 모니터링·자동 복구, 배포 절차 정리를 맡았습니다.
- 설계 판단
- 관리·데이터베이스·서비스·개발 네 묶음으로 나누고 한 줄 명령으로 올리고 내리는 래퍼를 두었습니다.
- 검증 기준
- 재배포 뒤 실제 도메인으로 전 페이지·API 응답과 지표를 다시 확인하는 절차로 마무리합니다.
- 결과 범위
- 운영 중인 서비스의 스택·대시보드·감시 구성을 맡아 유지하고 있습니다.
전자해도 이미지 서비스와 그 주변 도구가 늘면서, 무엇이 어디서 도는지 서버에 들어가 봐야만 알 수 있는 상태가 되었습니다. 컴포즈 파일을 관리·데이터베이스·서비스·개발 네 묶음으로 나누고 한 줄 명령으로 올리고 내리는 래퍼를 두어, 묶음 단위로 손댈 수 있게 정리했습니다.
관리 대시보드
관리 대시보드는 컨테이너 상태와 자원 사용량, API 응답을 한 화면에 모읍니다.
화면이 커지면서 페이지마다 흩어져 있던 인증 검사를 의존성 두 개로 합쳤습니다.
한 파일에 몰려 있던 라우트를 기능별 모듈로 나눴습니다.
바깥 CDN 을 걷어내고 의존성 버전을 실제 운영 컨테이너 기준으로 고정해, 다시 빌드해도 같은 것이 올라가게 했습니다.
스택 구성
GPU 메모리 증가 문제
GPU 메모리가 계속 늘어 서비스가 멈추는 문제가 반복됐습니다.
요청 파라미터를 하나씩 빼고 넣어 가며 좁힌 결과, 특정 값이 바뀔 때만 메모리가 늘고 반환되지 않는다는 것을 확인했습니다.
근거를 정리해 해당 구성요소의 개발 담당에게 넘겼습니다.
그 사이에는 임계치를 넘으면 컨테이너를 다시 띄우는 감시 장치를 붙여 서비스가 서지 않게 했습니다.
원인 추적과 임시 대응
상태 점검과 운영
컨테이너 상태 점검과 자동 재시작을 붙이고, 포트와 API 문서를 실제 구현 기준으로 다시 맞췄습니다.
운영 서버는 손으로 고친 부분이 남아 있어, 배포는 파일 단위로 확인하고 반영하는 절차로 고정했습니다.
2026년 10월에는 프로세스가 살아 있는지만 보던 점검이 한 인스턴스의 장시간 정지를 놓친 일이 있었습니다.
점검을 응답 기반으로 바꾸고 비정상 인스턴스를 자동으로 다시 띄우되, 비정상이 절반을 넘으면 재시작을 보류해 연쇄 재시작을 막았습니다.
GPU 메모리 과점유 때의 순차 재시작과 하드 메모리 한도 백스톱도 더했습니다.
응답 기반 점검과 재시작