-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
이슈 배경
- 프로젝트 운영 단계에서 애플리케이션 로그를 중앙집중 수집·검색·시각화·알람까지 일관되게 처리할 필요가 있음
- AWS 중심 인프라와 컨테이너(또는 EC2) 환경을 고려해, 많이 쓰이는 로그 수집/분석 서비스를 비교/선정
작업 내용
| 항목 | CloudWatch Logs | ELK Stack | EFK Stack | Loki(+Grafana) |
|---|---|---|---|---|
| 성격 | AWS 매니지드 | Logstash 기반 스택 | Fluentd 기반 스택 | 경량 로그 집계 |
| 장점 | AWS 통합, 설정 간단 | 강력한 파싱/변환 | 가볍고 성능 좋음 | 경량, 저비용 |
| 단점 | 비쌈, AWS 종속 | 무겁고 리소스 많이 사용 | 구축/운영 복잡 | 기능 제한적 |
| 비용 | 높음(종량제) | 중간(인프라) | 중간(인프라) | 낮음 |
| 적합환경 | AWS 단일 환경 | 복잡한 로그 변환 필요시 | 대용량 로그 처리 | K8s/마이크로서비스 |
현재 상황
- LLM/스케줄링 서비스는 별도 레포에서 각자 로깅하고, 나는 Spring Boot 서버(단일 레포) 파트만 담당하므로 서버 로그 분석 서비스만 선택하면 됨
선정 기준 및 추천안
1. CloudWatch Logs (1순위)
- 현재 AWS 인프라와 완벽 호환
- Spring Boot 단일 서비스 환경에 최적화
- 개발 초기 단계의 로그 볼륨 대비 합리적 비용 구조
2. Loki + Grafana
- 장기적 비용 효율성 우수
- 컨테이너 기반 환경에서의 확장성 제공
- 초기 구축 비용 대비 운영 효율성 높음
3. ELK/EFK Stack (not recommend)
- 단일 서비스 규모 대비 과도한 인프라 복잡성
- 높은 운영 부담 및 리소스 요구사항
- 현 프로젝트 규모에 부적합한 고급 기능들
🙋🏻 참고 자료
CloudWatch / ELK / EFK / Loki
Reactions are currently unavailable