빌드업웍스
로그를 메모장으로 뒤지던 일을 끝냈습니다
장비 로그가 매달 쌓이는데 조회 수단은 파일을 내려받아 메모장으로 여는 것뿐이었습니다. 남은 디스크는 한 달치보다 적었습니다. 백업부터 웹 조회 화면까지 만들었습니다.
실측 · 설계 기록읽기 전용 실측(디스크·샘플) 기준 · 월 생성량은 고객 확인값 · 제공 범위는 대표 확인
추측으로 설계하지 않았습니다. 로그 서버를 읽기 전용으로 열어 용량·증가율·포맷을 먼저 재고, 그 위에 설계했습니다.
- 01 추측 없이 실측부터 로그 서버를 읽기 전용으로 열어 용량·증가율·포맷을 먼저 쟀습니다.
- 02 지우기 전에 지킵니다 압축·업로드·검증을 끝낸 파일만 삭제 대상이 됩니다.
- 03 메모장을 걷어냈습니다 기간·장비·레벨·키워드로 화면에서 찾습니다.
어떤 상황이었나
남은 디스크가 92GB인데 로그는 매달 210GB씩 쌓였습니다. 남은 공간이 한 달치보다 적으니 결국 사람이 손으로 지우게 되고, 실제로 긴급 삭제가 있었습니다. 그런데 지워버리면 정작 장애가 났을 때 볼 기록이 없습니다.
장애·문의가 들어오면 파일을 통째로 내려받아 열었습니다. 공간이 차면 손으로 지웠고, 지운 기록은 돌아오지 않습니다.
기간·장비·레벨·키워드로 찾습니다. 원본은 압축해 보관하고, 검증을 통과한 것만 서버에서 비웁니다.
무엇을 했나
- 1 읽기 전용으로 실측했습니다
여유 92GB, 월 생성 210GB. 남은 공간이 한 달치보다 적다는 걸 숫자로 확인했습니다.
- 2 백업을 먼저 세웠습니다
완료된 파일만 압축·업로드하고, 업로드 검증을 통과한 것만 삭제 대상이 됩니다.
- 3 조회를 화면으로 옮겼습니다
기간·장비 ID·레벨·키워드로 찾습니다. 파일을 내려받을 일이 없어졌습니다.
완료된 로그만 골라 압축해 오브젝트 스토리지에 올리고, 업로드가 검증된 파일만 서버에서 비웁니다. 서버에는 스토리지 삭제 권한을 주지 않았습니다 — 잘못 지우는 경로 자체를 만들지 않았습니다. 올라간 로그는 조회용 구조로 변환해 두고, 담당자는 기간·장비·레벨·키워드를 골라 화면에서 찾습니다.
조회 화면은 이렇게 생겼습니다
표시된 장비 ID·시각·IP·메시지는 전부 가상입니다. 실제 고객 데이터가 아니며, 화면 구성을 보여주기 위한 재현입니다.
완료 파일만 선별 → 압축 → 오브젝트 스토리지 업로드 → 업로드 검증 → 검증분 중 보존기간 초과분만 삭제. 최초 회차는 실제 삭제 없이 시험 실행
원본 아카이브와 별도로 조회용 구조(컬럼형)로 변환. 날짜·서비스 단위로 나눠 두어 조건 조회 시 전체를 훑지 않습니다
서버에는 스토리지 삭제 권한 미부여 · 사용 중이거나 잠긴 파일은 대상에서 제외
우리 회사도 해당될까요?
해당되는 항목을 눌러보세요. 많이 켜질수록 이 사례와 비슷한 상황입니다.
0/3 항목을 눌러 확인해 보세요.
맞지 않는 경우도 있습니다 — 먼저 말씀드립니다
효과가 제한적인 경우
- 로그를 오래 보관하는 것 자체가 목적이라면 조회 화면까지는 필요 없습니다 — 아카이브만으로 충분합니다
- 로그가 이미 정형 데이터로 적재되고 있다면 이 설계는 과합니다
이런 경우엔 권하지 않습니다
- 조회 속도가 얼마나 빨라졌는지는 측정하지 않았습니다 — 저희가 실증할 수 있는 것은 실측한 현황과 만든 것까지입니다.
- 보관 비용은 로그량·보존기간에 따라 달라집니다. 이 사례의 수치를 그대로 적용하지 마세요.
- 범위
- 읽기 전용 실측 후 신규 구축. 원본 삭제는 업로드 검증 통과분에 한정.
- 되돌리기
- 서버에 스토리지 삭제 권한을 부여하지 않았습니다 — 잘못 지우는 경로 자체가 없습니다.
- 고객사 공수
- 보존기간·삭제 정책 확정은 고객이, 구현은 저희가 맡았습니다.
이 사례가 실증하는 약속 — 투명한 리포팅
게시 · 검토 · 전 사례 익명(계약 조건) · 고객사와의 계약에 따라 업종·시스템은 밝히지 않습니다. 제공 범위는 대표 확인 기준이며, 조회 성능 개선 폭은 측정하지 않았습니다. 참고 화면의 데이터는 전부 가상입니다.
같은 성격의 일을 데모로 확인하세요
설명보다 작동이 빠릅니다. 모든 데모는 가상 데이터로 동작합니다.