Monitoring

1. 모니터링 대상

• 서버의 리소스를 모니터링한다. cpu, memory, disk, 등 시스템 자원을 관찰하며 정상 범위를 벗어나면 주의 경고를 알린다.
• 서버의 로그를 남긴다. 언제, 어디서, 무엇을 헀는지 등 모든 내용이 담긴 로그를 기록한다. 이때 오래된 로그 파일을 디스크 공간을 다 채우지 않도록 주기적으로 삭제하는 작업이 필요하다. 로그를 남김으로써 추후 장애시 빠르게 원인 파악이 가능하다.
• 사용 중인 애플리케이션에 관한 모니터링을 한다. TPS, GC(메모리를 많이쓰는 앱의 경우 GC가 자주일어나 Stop-the-world가 발생해 잠시 응답이 지연되는 이슈가 발생할 수도 있다.), 서비스 응답시간 (캐시 처리등을 확인해야할 수도 있다.), 에러 갯수 등을 파악한다.

2. MSA 모니터링의 문제점

• 전통적인 비클라우드 환경에서 클라우드 환경으로 옮겨오면서, 어플리케이션은 더 이상 미리 정의한 사양의 특정한 장비에 종속되지 않게 되었다. 즉, 배포에 사용되는 장비는 그때그때 다를 수 있다. 더욱이 도커와 같은 컨테이너는 본질적으로 짧은 수명을 전제로 한다. 이는 결국 로그도 디스크의 저장 상태에 더 이상 의존하지 못한다는 의미다. 디스크에 기록된 로그는 컨테이너가 재시작 됨에 따라 사라질 수 있다.
• 또한 MSA별로 파편화된 앱들의 로그를 처음부터 끝까지 추적하는 것은 불가능하다.
• 즉, 시스템을 더 세분화된 마이크로 서비스로 분해하면 많은 해택을 얻지만, 모니터링 관점에선 복잡성이 증가한다. 장애 발생시 모놀리식 앱은 쉽게 장애 로그를 찾을 수는 있지만, MSA는 작은 서비스들이 합쳐서 기능을 제공하기 때문에 장애 포인트를 찾기 쉽지 않다. 수 많은 로그 파일을 일일이 확인하고, 네트워크 지연 등 사이드 이펙트를 고려해야한다.
• 해결책은 간단하다. 작은것들을 모니터링하고, 전체 상황을 볼 수 있게 취합하자.

3. 중앙 집중형 로깅 및 트레이싱

[1] 중앙 집중형 로깅

• 모든 마이크로서비스의 로그를 취합하여 보여주는 로깅방식이다. 수 많은 로그 메시지를 처리하기 때문에 보통 빅데이터 솔루션에 의해 수행되어진다.
• 특정 장비에 의존하지 않고, 모든 로그 메시지를 수집할 수 있어야한다.
• 트랜잭션의 처음부터 끝까지 연결지으며 추적할 수 있어야한다.
• 로그 정보를 오랜 기간 동안 보관할 수 있어야한다.
• 네트워크 장치, OS, MSA 등 여러 소스에서 오는 로그도 수집할 수 있어야 한다.

[2] 로깅 구조 예시

• Log Stream : MSA가 만들어내는 로그 메시지의 스트림이다. 로그 스트림은 Log4j와 같은 애플리케이션 메시지 스트림일 수도 있고, DB && Network 로그 등 다양하게 생성할 수 있다. ex) log4j, logback etc
• Log Shipper : 각각의 MSA에서 나온 로그를 수집하여, Log Store or Log Stream Processor로 데이터를 전송해준다. ex) filebeat, logstash etc
• Log Stream Processor : 로그를 파이프라인에 따라 저장소 혹은 대시보드로 전송한다. ex) kafka, streamset etc
• Log Store : 모든 로그 메시지를 저장하는 저장소다. ex) ES, MongoDB(NoSQL), Hadoop etc
• Log Dashboard : 로그 분석 결과를 그래프나 차트로 한눈에 파악할 수 있게 해준다. ex) kibana, grafana etc

[2] 트레이싱

• 중앙 집중형 로깅 솔루션을 사용하면 모든 로그를 중앙 저장소에 보관할 수 있다. 그러나 여전히 트랜잭션의 전 구간을 추적하는건 불가능하다. 여러 마이크로 서비스에 걸쳐 있는 트랜잭션의 전 구간을 추적하려면 하나의 연관 ID 있어야한다.
• 시스템 추적 시스템을 사용할 수 있는데, 분산형 추적은 SPAN(구간)과 TRACE(추적)의 개념으로 동작한다. 구간이란 작업의 단위로 볼 수 있는데, 하나의 서비스 호출을 구간, 여러 개의 구간으로 이루어진 한 세트를 추적이라 할 수 있다. 추적 ID를 이용해 서비스의 호출을 처음부터 끝까지 추적할 수 있다.