로그는 서버가 동작할 때 서버의 상태와 동작 정보를 시간 경과에 따라 기록된 결과다. 로그는 시스템의 오류와 문제들을 쉽게 찾아낼 수 있도록 도와준다. 반면, 메트릭은 시스템의 성능과 상태에 대한 통계적인 정보를 의미한다. 메트릭을 잘 수집하면 시스템의 현재 상태를 손쉽게 파악할 수 있고, 사업 현황에 관한 유용한 정보를 얻을 수 있다. 메트릭에는 DAU, Retension, CPU 사용량, 메모리 사용량 등이 있다.
로그와 메트릭 수집 경험
docker compose 로 Kafka + ELK stack 사용 - 해당 글에서 자세한 과정을 볼 수 있다.
서비스의 로그를 효율적으로 수집하고 모니터링하기 위한 ELK 스택 및 Kafka를 활용한 경험
로그 수집 아키텍처
시스템 구성
- Spring Boot 애플리케이션에서 로그 생성
- Filebeat로 로그 파일 수집
- Kafka를 통한 로그 데이터 버퍼링
- Logstash에서 로그 처리 및 필터링
- Elasticsearch에 저장
- Kibana를 통한 시각화
주요 모니터링 지표
- 애플리케이션 로그 수집 및 분석
- 에러 레벨 로그 실시간 모니터링
- Slack을 통한 에러 알림 자동화
로깅은 SLF4J를 이용했다.
기술적 구현
logging:
file:
name: /app/logs/application.log
pattern:
console: "%d{yyyy-MM-dd HH:mm:ss} - %msg%n"
file: "%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n"
level:
org.hibernate.SQL: debug
com.ssafy.omg: debug
로그 처리 파이프라인
- Filebeat가 로그 파일을 읽어 Kafka로 전송
- Logstash가 Kafka에서 데이터를 가져와 처리
- Elasticsearch에 저장 후 Kibana로 시각화
- 에러 발생 시 Slack 웹훅을 통한 실시간 알림
해당 로그 수집 구성을 선택한 이유?
시스템 아키텍처 관점
-
안정성 및 확장성을 확보
- Kafka를 메시지 큐로 활용하여 대규모 트래픽에도 로그 유실 없이 처리 가능.
- 마이크로서비스로 확장시에도 서비스간 느슨한 결합(Loose Coupling)을 구현.
- 각 컴포넌트의 독립적인 스케일링 가능.
-
고가용성
- Filebeat는 로그 수집 실패 시 자동 재시도 메커니즘 제공.
- Kafka의 파티셔닝을 통해 부하 분산 및 데이터 복제가 가능.
- Elasticsearch 클러스터링으로 데이터 안정성 확보.
- 효율적인 운영: 중앙 집중화된 로그 관리로 문제 상황을 신속하게 파악하고 대응할 수 있습니다.
서비스 운영 효율성
- 중앙화된 로그 관리
- 분산된 마이크로서비스의 로그를 단일 시스템에서 통합 관리.
- 상관관계 분석을 통한 문제 발생 지점 신속 파악.
- 로그 보관 기간 및 정책의 중앙 관리 - 로그 보관 기간은 1주일로 설정하였다.
- 실시간 모니터링 및 알림
- Kibana 대시보드를 통한 시스템 상태 실시간 모니터링.
- 에러 발생 시 Slack 웹훅을 통한 즉각적인 알림.
- 커스텀 대시보드로 주요 비즈니스 메트릭 추적.
System.out.print 을 사용하면 로깅 프레임워크는 사용하지 않아도 될까?
로그를 출력하는 경우 대기시간이 발생한다. 그리고, 로그 또한 데이터이기 때문에 저장공간을 요구한다. 따라서 정말 필요한 경우에만 로깅을 수행하는 것이 효율적이다. 하지만, System.out.println은 로그 레벨 설정과 환경 별 필터링을 적용하기 까다롭다. 반면, 로깅 프레임워크는 로그 레벨 설정, 필터링 등 로그의 양 조절을 하기 위한 기능을 제공하기 때문에 이를 사용하는 것이 서비스 운영에 유리하다.
예상 기술 면접 질문과 답변
Q: ELK 스택에서 Kafka를 도입한 이유는 무엇인가요?
A: Kafka는 로그 수집 파이프라인에서 버퍼 역할을 수행합니다. 대량의 로그 데이터가 발생할 때 Elasticsearch에 직접 부하가 가는 것을 방지하고, 시스템 장애 시에도 데이터 유실을 방지할 수 있었습니다. 또한 로그 처리 파이프라인의 확장성과 유연성을 높일 수 있습니다.
Q: Elasticsearch의 인덱스 전략은 어떻게 설계했나요?
A: 로그 데이터의 특성을 고려하여 일자별 인덱스 (omg-game-log-%{+YYYY.MM.dd})를 생성했습니다. 또한 에러 로그의 경우 인덱스 index => "omg-game-error-log-%{+YYYY.MM.dd}" 를 생성했습니다. 이를 통해 오래된 로그의 효율적인 관리가 가능하며, 특정 기간의 로그 검색 및 로그 추적을 용이하게 하여 성능을 최적화할 수 있었습니다.
Q: 로그 시스템의 장애 대응 전략은 무엇인가요?
A: 여러 단계의 안전장치를 구현했습니다. Filebeat의 자동 재시도 메커니즘, Kafka의 데이터 영속성, Logstash의 필터링과 재시도 로직을 통해 데이터 유실을 방지했습니다. 또한 Slack 알림을 통해 즉각적인 대응이 가능하도록 구성했습니다.
References
