기획은 주말에 잠깐 나와서 마무리했고 오늘부터는 피드백을 처리하고 서서히 토대부터 쌓아올리고 있다.

스코프를 적당히 작게 설정한 만큼 조급해지지 말고 테스트 코드같은 습관부터 잘 들여가면서 정리해나가고 있다.

챌린지반 - 로그와 모니터링

기능에서 벗어나 서비스의 운영을 담당하는 영역에서 로그와 모니터링은 핵심적인 역할이다.

회사를 다닐 때도 운영팀 영업팀에서 확인 요청이 꽤 자주 들어왔었기에 이런 일을 쉽고 정확하게 처리하는 것도 리소스를 줄이는 것이라 생각한다.

그 외에도 튜터님은 장애가 발생했을 때 파악하기 위한 운영적인 측면에서 다뤄주셨다

ELK 스택

ELK는 Elastic Search, Logstash, Kibana 의 약자다.

각 어플리케이션에서 발생한 로그는 컴퓨터 특정 경로에 저장된 후 Beats라는 서비스가 외부로 전송되는데 외부는 Logstash, Elasticsearch에 전송되어 Kibana가 출력해준다.

Logstash는 Beat가 보내준 파일을 여러 인스턴스의 로그를 종합해 의미있는 Data set으로 만들고

ElasticSearch에 해당 데이터가 저장되고

Kibana가 대시보드로 보여준다.

사실 로그 하나가 이렇게 많은 서비스를 거치는지는 몰랐다.

Logger

생각없이 가장 단순한 println을 많이 쓰게될 수도 있지만 사실 콘솔창에 남기는게 주요 역할이고 실행이 끝날 때까지 점유하는 문제도 있어서 Logger를 활용하는게 주로 추천되기도 한다.

이런 이유 말고도 Logger를 쓰면 Instance의 특정 경로에 파일로 로그를 남기는 것이 이번에 중요한 목적중 하나라 볼 수 있다.

Logger중에서도 Spring은 Logback (spring-boot-starter-logging 기본 포함) 을 이용할 수 있다.

resource 경로 밑에 spring-logback.xml 파일을 만들어서 원하는 Logback 설정이 가능하다. 기본적으로는 console에 출력해주지만 file로 출력할 수도 있고 양식같은 설정 자체를 다양하게 할 수도 있다.

Interceptor

일반적으로는 그냥 우리가 확인하기 위한 Log를 많이 남기지만 실무에선 사용자 요청에 대한 Request / Response를 남기는 Log를 남기곤 한다.

이런 Log를 일일이 찍을 순 없으니 Interceptor의 운용을 고려해서 적용하면 된다.

Log Level

Error, Warn, Info, Debug, Trace 5가지 레벨로 Error가 가장 크고 trace가 낮다.

이 중 Error, Warning은 AEM으로 연동되어 알림을 보내는 설정까지 가능하기에 주의해야한다. 특히 Error는 즉시 대응해야하는 경우에만 사용하는 것을 권장한다.

Info는 운영중에 남기는 정보성 Log로 구체적으로 정보를 담고(여러 줄로 분리 x) 검색하기 위한 Keyword를 포함시키는 것이 좋다. 다만 Info도 너무 많이 남겨서는 안된다.

중요하지 않은 경고가 계속 발생하는 오탐 현상이 잦아지면 에러 채널에 대해 관심도가 떨어져 진짜 중요 에러를 놓칠 수가 있다.

모니터링

자주 사용되는 모니터링 대시보드 도구는 Grafana다.

System 자원에 대한 Metric이 기본적으로 나오지만 어플리케이션에 특화된 Metric도 설정해 확인할 수 있다. (회원가입 수, 실패 횟수 등)

어플리케이션이 micrometer 표준 측정 방식에 따른 metric을 쌓고 프로메테우스가 수집해서 저장 후 그라파나가 조회하는 방식으로 프로메테우스가 ElasticSearch, 그라파나가 Kibana의 역할을 한다고 볼 수 있다.

어플리케이션, 프로메테우스, 그라파나 총 3대의 서버가 필요하다고 볼 수도 있다.

모니터링을 감지해서 알림을 보내주는 Alarm도 있다.

Metric

spring-boot-starter-actuator를 추가하면 기본적으로 수집되는 Metric을 손쉽게 확인할 수 있다.

프로메테우스를 쓴다고 하면 수집된 내 Metric에 접근하는 /actuator/prometheus Endpoint를 호출해서 Metric을 수집해간다.

프로메테우스는 숫자가 증가하기만 하는 Counter, 사용률처럼 늘었다 줄었다 하는 Guage 가 있다.

마무리

장애는 언제든 발생할 수도 있지만 로그가 안남아서 아예 대응이 안될 때가 제일 치명적인 상황이라고 생각한다. 이는 개발자 입장 말고도 사용자 입장에서 아니 이런 거 로그도 안남김? 이라는 생각이 들 때가 있으니 더더욱 중요하다고 본다.

회사에서도 로그에 지출하는 돈도 꽤 있었고 적당히가 중요하긴 하겠지만 실제 서비스 운영이라면 이는 굉장히 중요하고 팀의 생존 수단중 하나로 사용하기 좋다.

구현 자체가 쉬운 편이니 여력이 된다면 Prometheus & Grafana 를 사용한 환경 구축은 해보는 것이 좋을 것 같다.