안녕하세요. 오늘부터는 새로운 주제로 찾아뵙게 되었습니다. 바로 MSA입니다. 저희 회사에서 저는 요즘 프로젝트를 MSA의 기술들을 적용해가며 진행하고 있습니다. 오늘은 MSA의 기술 중 로그관리와 트레이싱에 대해서 한번 알아보도록 하겠습니다.
MSA의 개념에 대한 설명은 추후에 따로 준비하도록 하겠습니다. ^^
문제 제기
MSA(Micro Service Architecture)는 분산 환경에서 운영된다는 특징 때문에 각각의 서비스에 대한 로깅과 모니터링은 큰 고민거리로 남겨지게 됩니다. 서로 다른 개별 마이크로서비스(서버)에서 발생하는 로그를 연결지어 트랜잭션의 처음부터 끝까지 추적을 해내어야 하는데 이것은 쉽지않은 일입니다.
아래는 스프링 5.0 마이크로서비스 2/e
에서 발췌한 내용입니다.
전통적인 비클라우드 환경에서 클라우드 환경으로 옮겨오면서 어플리케이션은 더 이상 미리 정의한 사양의 특정한 장비에 종속되지 않게 되었습니다. 배포에 사용되는 장비는 그때그때 다를 수 있습니다. 그리고 도커와 같은 컨테이너는 본질적으로 짧은 수명을 전제로 합니다. 이는 결국 로그도 디스크의 저장 상태에 더 이상 의존하지 못한다는 의미 입니다. 디스크에 기록된 로그는 컨테어너가 재시작 됨에 따라 사라질 수 도 있습니다.
아래는 마이크로서비스에서의 로그의 파편화에 대한 부분입니다.
마이크로서비스는 독립적인 물릭적 장비 혹은 가상머신에서 운영되므로, 외부화하지 않은 로그 파일은 결국 각 마이크로서비스별로 파편화됩니다. 이렇게 되면 여러 마이크로서비스에 걸쳐서 발생하는 트랜잭션을 처음부터 끝까지 추적하는 것은 불가능해집니다.
위의 이미지를 보면 마이크로서비스 1과 3에서 동시에 reqest를 받았고 마이크로서비스에 전달하여 일을 처리한다고 가정했을때 마이크로서비스 2에서는 log의 순서를 보장 할 수 없으며, 로그의 주인의 파악하기 힘듭니다.
이러한 2가지 이유가 원인으로하여 로그의 외부화
가 필요합니다.
중앙 집중형 로깅
위와 같은 문제를 해결하기 위해 새로운 로깅방식을 적용해야합니다. 바로 중앙 집중형 로깅입니다. 이는 간단히 말해서 모든 마이크로서비스의 log를 취합하여 보여주는 로깅형식입니다. 이러한 중앙 집중형 로깅은 5가지 특징을 가집니다.
- 모든 로그 메시지를 수집할 수 있어야하며, 분석할 수 있어야한다.
- 트랜잭션의 처음부터 끝까지 연결지어가며 추적할 수 있어야한다.
- 로그 정보를 오랜 기간 동안 보관할 수 있어야한다.
- 로컬 디스크 시스템에 의존해서는 안된다.
- 네트워크 장치, 운영체제, 마이크로서비스 등 여러 소스에서 오는 로그도 수집할 수 있어야 한다.
중앙 집중형 로깅 방식은 엄청나게 많은 수의 로그 메시지를 처리해야하기 때문에 보통 빅데이터 솔루션에 의해 수행되어집니다. 아키텍처는 아래와 같습니다.
각 컴포넌트(Component)에 대해서 설명하면 아래와 같습니다.
-
로그 스트림(Log Stream) : 마이크로서비스가 만들어내는 로그 메시지의 스트림을 말합니다. 로그 스트림은 Log4j와 같은 메시지 스트리밍일 수도 있고 DB, Network 로그 등 다양하게 있을 수 있습니다.
-
로그 적재기(log shipper) : 로그 적재기는 서로 다른 로그 생산자나 end-point에서 나오는 로그 메시지의 수집을 담당하는 역할을 합니다. 이는 메시지를 다른 곳으로 모을 때 사용할 수 있습니다. 대표적으로는 fileBeat, Logstash 등이 있습니다.
-
로그 저장소(log store) : 로그 저장소는 실시간 분석, 트렌드 분석을 등을 위해 모든 로그 메시지를 저장하는 컴포넌트입니다. 일반적으로 ElasticSearch, mongodb와 같은 NoSql을 사용합니다.
-
로그 스트림 처리기 : 로그 스트림 처리기는 실시간 로그 이벤트를 분석할 수 있습니다. 그리하여 알람을 뿌리거나 대시보드로 정보를 전송하거나 하는 역할을 할 수 있습니다.
-
로그 대시보드 : 로그 대시보드는 로그 분석 결과를 그래프나 차트로 한눈에 파악할 수 있게 해줍니다. Kibana를 사용할 수 있습니다.
트레이싱
중앙 집중형 로깅 솔루션을 사용하면 모든 로그를 중앙 저장소에 보관할 수 있습니다. 그러나 여전히 트랜잭션의 전 구간을 추적하는 것은 거의 불가능합니다. 여러 마이크로서비스에 걸쳐 있는 트랜잭션의 전 구간을 추적하려면 하나의 연관 ID가 있어야 합니다.
이때 시스템 분산 추적 시스템을 사용할 수 있습니다. 분산형 추적은 구간(SPAN)과 추적(TRACE)의 개념으로 동작합니다. 구간이란 작업의 단위로 볼 수 있는데, 하나의 서비스 호출을 구간, 여러 개의 구간으로 이루어진 한 세트를 추적이라고 할 수 있습니다. 추적 ID를 이용해 서비스의 호출을 처음부터 끝까지 추적할 수 있습니다.
위의 그림을 보면 개념이 확실하게 잡히실겁니다. 이런 추적 ID가 없으면 API 게이트웨어로, 그리고 이어서검색 마이크로서비스로 오는 호출을 추적하거나 연결 짓는 것은 거의 불가능에 가까울 것입니다.
추적 ID를 생성하는데에는 spring cloud sleuth를 많이 사용하며 트레이싱에는 트위터의 zipkin을 사용할 수 있습니다.
마무리
오늘은 이렇게 MSA에서의 로깅과 모니터링에 대해서 알아보았습니다. 다음시간에는 트레이싱
을 실습해보도록 하겠습니다.
감사합니다.
참조
스프링 5.0 마이크로서비스 2/e
'infra > 로깅과 트레이싱' 카테고리의 다른 글
[MSA] Elastic Stack을 이용한 중앙 집중형 로깅_실제 운영 환경 (0) | 2019.12.18 |
---|---|
[MSA] Filebeat와 Logstash의 비교 (4) | 2019.12.13 |
[MSA] Elastic Stack을 이용한 중앙 집중형 로깅_1 (0) | 2019.12.09 |
[MSA] Spring Cloud Sleuth와 Zipkin을 이용한 분산 시스템 Tracing_2 (0) | 2019.12.07 |
[MSA] Spring Cloud Sleuth와 Zipkin을 이용한 분산 시스템 Tracing_1 (0) | 2019.12.05 |
댓글