중앙화된 로그 집계 패턴

• 다양한 서비스 등록, 탐색 위한 Service registry , Service discovery 패턴
• 서비스 단일 진입을 위한 API 게이트웨이(gateway) 패턴 & BFF(Backend For Frontend) 패턴
• 외부 구성 저장소 패턴
• 마이크로서비스 인증/인가 패턴
• 장애 및 실패 처리를 위한 서킷 브레이크 패턴
• 모니터링과 추적 패턴
• 중앙화된 로그 집계 패턴
• 서비스 매시(Service Mesh) 패턴

중앙화된 로그 집계 패턴

마이크로서비스의 로그 관리는 어떻게 해야 하는가? 마이크로서비스가 사용량에 따라 탄력적으로 변화하면서 언제든지 인스턴스가 생성/삭제 될 수 있기때문에 기존처럼 로컬의 로그는 초기화 된다.

앞서 언급했던 Twelve-Factor에 ‘로그(Logs)’라는 체크 항목을 보면 로그를 이벤트 스트림(event streams)으로 처리하라고 한다. 로그는 고정된 시작과 끝이 있는 것이 아니라 서비스가 실행되는 동안 계속 흐르는 흐름이라는 말이다. 그리고 서비스는 스트림의 전달이나 저장에 절대 관여하지 않아야 한다고 말한다. 왜냐하면 로그를 전달,저장처리하는 메커니즘 자체가 특정 기술,인프라에 의존될 수 밖에 없고 이런 메커니즘을 직접 마이크로서비스가 구현하면 그 유연성이 떨어지기 때문이다.

그래서 필요한 것이 중앙화된 로그 집계 패턴이다. 서비스에서 발생된 이벤트 스트림 형태의 로그를 수집하고 살펴볼 도구가 필요하다. 대표적으로 많이 쓰이는 기술이 ELK 스택이다. ELK스택은 Elasticsearch, Logstash, Kibana, 세 개의 오픈 소스를 가지고 데이터 분석 환경을 구성한 것이다. 우선 Elasticsearch는 분석 엔진이고, Logstash는 서버 쪽 로그 집합기이다. 그리고 Kibana는 시각적으로 보여주는 대시보드이다.

이 ELK스택을 사용하면 각 서비스의 인스턴스 로그를 집계해서 중앙에서 집중 관리할 수 있으며 쉽게 특정 로그를 검색, 분석할 수 있다. 또한 특정 메시지가 로그에 나타나거나 특정 예외가 날 때 운영자나 개발자에게 직접 통보하게 할 수도 있다.

아래 그림은 마이크로서비스의 로그 수집을 위한 ELK 스택 구축 아키텍처이다. 각각의 서비스에 Logstash가 설치되어 각 로그를 수집해서 레디스 저장소에 보내고 있다. 그 다음 하나의 서비스에서는 Elasticsearch와 Kibana로 로그 중앙 관리 저장소와 대시보드 서비스를 구축한다. 그리고 레디스에서 중앙 관리 저장소에 로그를 보내게 되고 이 로그 저장소에 엘라스틱서치(Elasticsearch)엔진이 로그를 인덱싱하고 그 로그 정보가 키바나(Kibana) 대시보드를 통해 보여진다. 중간에 레디스 DB를 둔 까닭은 마이크로서비스의 Logstash가 바로 로그 저장소에 로그를 보낼 수 있지만 로그 스트림이 너무 몰리면 로그 저장소 서비스 역시 성능에 문제가 생기기 때문에 중간에 임시 저장소를 추가한 것이다.