비용 최적화를 위한 내부 로깅 시스템 설계와 시행착오 – Azure 로그 비용 80% 절감한 경험

배경

스타트업 환경에서 인프라 비용은 곧 생존과 직결됩니다.
당시 회사에서는 AWS와 Azure 크레딧을 제공받아 멀티 클라우드 환경으로 인프라를 운영하고 있었습니다.

초기에는 AWS 크레딧을 중심으로 전체 인프라를 구성했지만, 크레딧 소진 이후 데이터베이스를 포함한 일부 워크로드를 Azure로 이전하게 되었습니다. 이 과정에서 클라우드 로그 비용이 급격히 증가하는 문제를 마주하게 되었습니다.

 

🌠 목차
✅ 문제상황
✅ 1차 접근: 로그를 저렴하게 저장하고, 필요할 때 분석하자
✅ 2차 접근:  비용과 실시간성의 균형을 다시 설계하자
✅ 결과 및 성과
✅ 기술 회고 

문제상황

---

Azure로 일부 인프라를 이전한 뒤 비용을 모니터링하던 중,

Azure 로그 저장 비용이 전체 인프라 비용의 약 30%를 차지하고 있다는 점을 발견했습니다.

원인을 분석해보니 다음과 같은 문제가 있었습니다.

• Azure Log Analytics는 최소 30일 보관 정책을 강제
• 개발 단계에서 info/debug 레벨의 상세 로그를 대량 수집
• 로그 볼륨 증가 → 보관 기간 × 저장 비용이 누적

AWS CloudWatch Logs와 달리 Azure에서는 짧은 보관 기간으로 로그를 운영하기 어려웠고, 이 차이가 예상보다 큰 비용 문제로 이어졌습니다.

 

 

1차 접근: 로그를 저렴하게 저장하고, 필요할 때 분석하자

---

아키텍처

접근 전략

• Winston
  • 로그 레벨 분리
  • JSON 기반 구조화 로그 설계
• 로그 포맷 개선
  • NestJS Middleware에서 JWT 디코딩
  • 사용자 식별 정보(email)를 로그에 포함
• S3 기반 로그 저장
  • 애플리케이션 로그를 1분 단위 파일로 변환
  • Parquet 포맷으로 적재하여 저장 비용 최소화
• 분석 환경 구축
  • AWS Glue Crawler를 통해 스키마 자동 추론
  • Data Lake에서 누락 없이 로그 분석 가능

성과

• Azure 로그 저장 비용 약 70% 절감

문제점

• Glue Crawler 실행이 배치 기반
• 스키마 반영 및 적재까지 5~10분 지연
• 실시간 디버깅, 장애 대응에는 치명적인 사용성 문제

기술적으로는 비용 최적화에 성공했지만,
운영 관점에서는 “로그는 즉시 조회할 수 있어야 한다”는 기본 요구사항을 충족하지 못했습니다.

 

2차 접근:  비용과 실시간성의 균형을 다시 설계하자

---

 

아키텍처

 

개선 전략

1차 접근에서 추가 개선을 진행했습니다.

• 선별적 로그 보관
  • error / warning 로그만 Azure Monitor에 저장
  • info / debug 로그는 별도 저장소로 분리
• 실시간 분석 중심 설계
  • KQL 기반 실시간 쿼리 가능
  • 장애 발생 시 즉각적인 원인 파악
• Azure RBAC 적용
  • 팀원 역할에 따른 로그 접근 제어
• 모니터링 대시보드 구축
  • API 호출량
  • 응답 시간
  • 에러율 등 핵심 지표를 실시간 시각화

 

결과 및 성과

---

2차 접근을 통해 다음과 같은 결과를 얻었습니다.

• 비용 절감
  • Azure 로그 관련 비용 월 기준 약 80% 절감
• 운영 효율성 개선
  • 실시간 로그 조회 가능
  • 장애 대응 시간 대폭 단축
• 크레딧 활용 최적화
  • 절감된 비용을 핵심 인프라에 재투자 가능

기술 회고 

---

1차 접근에서는 AWS Glue, Data Lake 등 기술적으로 흥미로운 요소에 집중한 나머지,
실제 사용하는 팀원의 경험을 충분히 고려하지 못했습니다.

돌이켜보면 처음부터 Azure Log Analytics와 Data Explorer의 보관 정책, 쿼리 성능, 비용 옵션을 더 깊이 검토했다면 2차 접근으로 바로 갈 수 있었을 것입니다.

이 경험을 통해 다음을 명확히 깨달았습니다.

• 비용 절감만을 목표로 하면 개발 생산성이 오히려 떨어질 수 있다
• 인프라 설계에서는 기술적 설계보다 실용성과 지속가능성이 중요하다
• “운영자가 매일 쓰는 도구”라는 관점이 "반드시" 필요하다

이후로는 인프라를 설계할 때
비용, 사용성, 운영 부담의 균형을 가장 먼저 고려하게 되었습니다.

 

 

글 잼나게 보셨으면 좋아요 눌러주고 가세요

관심받는 거 좋아합니다