아이스크림 홈런 관측성 개선 세미나 - 레거시 관측성 올리기 1/10 → 5/10 후기

아이스크림 홈런에 재직하고 계신 범균님과  여명님의 아이스크림 홈런 관측성 세미나가  Festa에 올라오게 되어서, 조직이 레거시를 개선하기 위한 관측성을 올리기 위해 어떤 노력을 하셨는지에 대해 들을 수 있는 좋은 기회라고 생각하게 되어 해당 이야기들을 듣게 되었습니다. 범균님께서는 전체적인 이야기를, 여명님께서는 세부적인 이야기들을 하였고 두개의 세션으로 나누어 진행되었습니다.

1. 레거시 관측성 올리기 1/10 → 5/10 - 최범균

범균님 세미나 1

첫 발표는 범균님의 레거시 관측성 올리기에 대한 세션이었습니다.

0. 발표 주제

  • 관측 가능했던 것
  • 필요했던 것
  • 그래서 했던 것
  • 힘들었던 것

1. 기존 시스템에 대한 설명 

1- 1. 관측성을 개선한 이유 

  • 회사가 6년 사이에 급격히 성장함 => 급격한 성장을 위해 급한 처방을 하게 되었음
  • 그에 따라 레거시가 생기게 됨 ( 대략 100 ~ 200대의 물리 서버 )
  • 그에 비해 소규모인 개발 조직
  • 이로 인해 구조적으로 성장을 따라갈 수 없어서 꾸역꾸역 크게 DB 등의 구조를 잘못 집어넣음 .

1-2. 관측을 위해 가졌던 기존의 수단

  • Scouter + 개발자의 눈 ( Scouter를 개발자가 수동으로 보는 방식 ) => 개발자 부재시 큰 구멍이 생김.
  • Zabbix ( 장비의 상태 ) + Slack ( 알람 받기 )
  • DB Slow Query Monitoring
  • 최고의 수단 => 고객 + 동료
    • 고객이 CS 부서에 연락하면 CS 부서의 동료가 문제를 파악

1-3. 기존의 관측 수단으로 인해 우리가 못 본것 또는 빨리 못 본것 

  • 실시간 상황 파악 =>  트래픽 규모, 오류 증가, 기능오류 발생등을 빠르게 볼 수 없었음
    • ex) 500 error 등의 오류, 기능의 오류가 있어도 잡지를 못함
  • 시스템 분할을 하였으나  추적하기가 어려웠음
  • 무슨일이 있으면 그러한 히스토리를 파악하기 어려웠음

1-4. Mission 및 우리가 처한 상황

  • Mission : 관측성, 모니터링 향상
  • 관측성 ( Logging ) , 메트릭(Metrics), 추적( Tracing )
    • 이벤트를 기록 / 이벤트 모인 데이터 / 순서대로 이벤트를 기록
  • 이러한 관측성, 모니터링을 향상시키자
  • 하지만...
    • IDC 환경 ( IDC 특성상 대역폭의 한계가 있음) => 다행히 대부분의 레거시가 JVM , 스프링이었음
    • 시간 ( 성수기 시간대가 다름 ( 신학기 시즌이 중요 ( 3~4월 전에 빠르게 관측성을 높이자 ))
    • 시작 : 10 ~ 1월까지 ( 마지노선은 2월 )
  • 가장 중요하게 여긴 것은 가성비 ( 주어진 시간이 적어서 시간 대비 효율이 매우 중요했다. )

2.  관측성 개선을 위해 선택한 도구 및 도구의 대한 설명

 2-1. 선택한 도구

  • 오류 수집 : Sentry
  • 오류 추적 : Pinpoint ( 처음에는 Zepkin ) + Scouter
  • 로그 수집 : Elastic
  • Application 메트릭 : MicroMeter
  • 메트릭 플랫폼 : Telegraf + InfluxDB
  • 대시보드 : Grafana + Kibana

2-2. 오류 수집

  • Sentry 사용
    • 10여개 서비스 ( WAS ) 에 적용
    • 중요한 레거시 서비스들을 먼저 Sentry 적용 ( Spring MVC Exception Handler -> AOP -> 수작업 순으로 집어넣음 )
    • Exception이 아닌 일부 Exception들은 제거 ( 중요 Exception이 아니면 제외 )
    • entry -> Slack 통보 ( Alert 간격 1 ~ 5분 / Rule 동일 이벤트 발생시 5분에 1번 ) => 통보 이후에 재통보는 하지 않음
    • 서비스별로 Sentry 프로젝트 생성 / 개발용은 Sentry 1개, 슬랙채널 1개
  • 오류 수집후 알게 된 결과
    • 오류 발생 빈도, 규모, 종류를 파악하였고, / 몰랐던 버그를 찾음

2-3. 서비스 간 추적 

  • PinPoint 사용
    • 적용과 설치가 쉬워서 시작하게 됨
    • Code로 파악했던 서비스 간 연동을 그래프를 통해 확인할 수 있게 됨
    • 현재 Scouter와 상호보완하여 사용
  • Scouter는 x축에 결과가 뜨고, PinPoint는 해당 Exception이 표시되어 상호보완하여 서비스 간의 추적을 좀 더 원활하게 함

2-4. 로그 수집

  • Elastic 사용
  • 2단계 접근으로 로그 수집을 진행하기로 함
    • 1단계는 웹 접근 로그 => 진행 완료
    • 2단계는 WAS 로그 => 추후 작업 예정 , 현재 적용 준비중
  • 전체 서비스에 1단계 접근을 완료하여 Elastic을 통해 수집중
  • 적용 과정
    • Apache Log Format 변경 => Logstash 설정 => FileBeat 설정 후 적용
  • 이를 통해 볼 수 있던 것
    • 실시간 상황 파악 가능 ( 오류 급등 ( 50X, 40X 에러 상태값의 카운트를 파악 )
    • 느린 응답들에 파악을 빠르게 하고, 트래픽의 이상 징후도 볼 수 있었음
  • Access 로그는 Response Byte 로 파악
    • 트래픽 패턴 파악
    • 몇시에 접속하는 사용자가 어느정도 있는지, 사람들이 많이 접속하는 시간대는 어느정도 인지
    • 며칠전, 가까운 과거 등의 비교 또한 가능
  • 물리 대시보드를 통해 쉽게 볼 수 있게 되어 개발자들도 빠르게 파악할 수 있었음
  • Logstash의 수집 관련시 고려사항
    • 1. 파싱 부하
      • 파싱 정보가 많아서 서버가 부하되지 않게 해주어야 함
      • 처음에는 Filebeat 처음 올렸을때 몇달치의 로그가 있었고, 이를 한번에 FileBeat가 Logstash에 집어넣어서 서버 점유율 100%까지 먹음(;;;)
      • 이후 별도 서버에 Logstash를 집어넣음
    • 2. 스토리지 확보
      • 기존의 미사용 장비를 활용
      • 현재는 용량의 제한으로 인해 기준을 두고 스토리지 관리를 함
        • Elastic Index의 경우 1달 반 정도 기간을 둠
        • InfluxDB는 단기와 장기로 구분하여 저장
    • 3. 내부 트래픽의 한계
      • 회사 최대폭 대역의 한계가 있음
      • 내부에서의 트래픽이 덜 발생하는 방식으로 Elastic, Logstash 사용

3. 이러한 관측성 개선을 통해 얻은 것

  • 사전 징후의 일부를 감지 가능하게 되었음
    • 트래픽 이상 증가 (트래픽이 많이 있는 페이지, 오류가 발생하는 URL ) => 로그 확인 => 대형 파일 발견 및 조치 => 네트워크 포화 방지
  •  일부 고객의 오류를 CS를 거치지 않고 미리 발견하여 해결할 수 있었음
  •  명확한 지표가 생김
    • 애매한 많은 것 같다. 라는 것이 아닌 정확한 숫자를 통해 구체적으로 볼 수 있는 지표가 생김
  • 개발자 및 관리자 분들의 행동 유도
    • Sentry => 오류가 나면 Slack으로 이를 보냄 => 추가로 이슈 발생시 Jira에 등록
    • 공개 대시보드 => 개발자 및 관리자 분들이 수시로 확인 가능하게 함
    • Slack 알림을 통해 오류를 지속적으로 감지할 수 있었음

4. 관측성 개선시 어려웠던 점

  • 기본적으로 구축된 장비의 방식이 오래되었다보니 새로운 장비를 구입하기 위해서는 기간이 길고, 이러한 과정이 복잡함
  • 레거시이기 때문에 운영업무 자체가 많음
    • 서비스 운영을 하면서 관측 과정을 병행하기에는 어려움
    • 이를 위해 운영 업무 외에 관측성을 개선하고 담당할 수 있는 인력을 확보, 편성하는 것이 어려웠음
  •  레거시 코드를 변경하는 것이 어려웠음
    • 기존의 레거시 코드 변경시 서비스 장애가 있을 수 있기 때문에 이러한 위험을 최소화하는 것이 필요했음
    • 새로운 라이브러리나 도구를 추가하기 위해 충분한 기간을 두고 천천히 개선을 함 => 대신에 일정에 대한 부담은 있었음
    • 기존의 서비스 위에 관측 서비스를 적용하기 위해 천천히 개선하지만, 촘촘하게 개선해야 했음

2. 전방위적 메트릭 모니터링 시스템 구축 - 우여명

범균님 세미나 2

두번째 세션은 실제 관측성을 개선하기 위해 어떠한 도구를 사용하고 노력했는지에 대한 세션을 우여명님이 발표하셨습니다.

0. 발표 주제

  • 텔레메트리와 메트릭에 대해
  • 관측성을 개선하기 위한 우리의 목표
  • 관측성을 개선하기 위한 도구 선정과 조립
  • 문제 해결
  • 고민거리
  • 부록

1. 텔레메트리와 메트릭에 대해

  • 관측성 개선을 위해 우선 기본적인 단계를 밟아나가기 위해 노력함
  • 텔레메트리란
    • ( 원격 측정 )
    • tele : 관측 대상으로 부터 이격된 지점에서 빠르게 문제를 파악하기 위함
    • metry : 이벤트 측정으로부터 도출된 데이터 ( 시스템 표준  - RequestCounter )
  • 기본적인 목표
    • 중앙집중식 텔레메트리를 구현하고 싶었음
      • 다원적인 시스템이 아니라, 실시간으로 측정하고 데이터 저장, 시각화, 경고들을 하나로 모아서 구축하고 싶었음
    • 여러수준(관점)으로 메트릭을 수집하고, 시스템을 진단하여 쉽고 빠르게 근본적 해결책을 찾고 싶었음
      • ex) 비즈니스, 애플리케이션, 클라이언트 등의 계층
    • 보다 쉽고 빠르게 문제를 해결하고 싶었음
      • 시각화와 정보 라디에이터 : 쉽게 대시보드들을 보여줄 수 있게 함으로서 팀이 쉽게 문제를 알 수 있어서 문제를 인정하고 함께 문제에 맞설 수 있게 노력함
      • 이상 탐지와 경고 =>개발자들인 우리가 먼저 문제를 파악하고 싶었고, 정말 진짜 문제일때 다른 분들에게 알려주기 위한 방법을 생각하고 있고, 아직도 여전히 고민중
      • 도구 선정 : 우리가 가진 상황에서 빠르고 쉽게 할 수 있는 것들을 선정하고 싶었음
        • Telegraf , zabbix, micrometer, zabbix

2. 주요 컴포넌트 소개

  • InfluxDB
    • 시계열 데이터 저장소 랭킹 1위
    • 기존의 RDB 쿼리와 비슷한 버전 제공 =>  (엔터프라이즈 버전에서는 클러스터링 제공 )
    • 쉽게 설치 가능하여 선택
  • Grafana
    • 빠르게 경고 알람을 받을 수 있어서 선택
    • 중앙집중화된 시각화 도구
    • 다양한 시각화 기능과 플러그인을 제공하여 선택
  • MicroMeter
    • JVM 기반
    • 쉽게 비즈니스 매트릭을 추가하기 위하여 선택 ( Micrometer가 메트릭 수집을 추상화 )
    • 현 서비스인 Spring과 쉽게 적용시킬수  있음
  • Telegraf
    • 부담없이 UDP 프로토콜로 메트릭을 수집할 수 있어서 선택
    • 간단한 프로토콜로 메트릭을 수집할 수 있는 도구
    • zabbix와 같이 사용
  • 이러한 도구들을 가지고 여러 관점의 모니터링을 구축
    • ex) 시스템, 비즈니스, 웹서버, 응답 등

3.  도구 선정과 이를 통한 문제 해결 & 임계치 등에 대한 설명 

  • 시스템 모니터링
    • 기존에 Zabbix가 존재
    • Zabbix는 기본기가 탄탄하지만 기능이 복잡하고 대시보드 표현력이 부족했음
    • Zabbix는 Mysql이어서 시계열 데이터 저장소에 비해 많이 느렸음
    • Grafana + InfluxDB로 통합
    • 시스템 모니터링의 도구
      • Zabbix + InfluxDB + Grafana + Grafana Zabbix Plugin + InfluxDB-Zabbix 를 통해 시스템을 모니터링함
      • 이러한 도구의 도입은 Plugin 서치 후 하나하나 대시보드 알람 작성 ( CPU, Memory, Traffic )
      • 이러한 도구의 도입 후 이를 사용하여 WAS ( 톰캣 ) 등의 상태를 봄
  • 비즈니스 모니터링
    • 어플리케이션 계층의 모니터링
    • 실시간 접속자수, 로그인 횟수, 특정 URL Call 등의 횟수등을 파악하고 싶었음
    • 비즈니스 모니터링의 도구
      • MicroMeter, Telegraf, InfluxDB, Grafana로 구성
      • Maven이었기 때문에 Micrometer 의존성 추가 후 코드를 작성하여 데이터가 쌓이면 알람 및 배포
      • 이를 통해 비즈니스 메트릭을 확인 했고, 실시간 측정 및 분석이 가능했다.
  • 웹서버 응답 모니터링
    • 403 / 404 / 500 / 503 등의 HTTP STATUS ERROR 등의 원인 파악을 하고 싶었음
    • 웹서버 응답 모니터링의 도구
    • ElasticSearch + Grafana 사용
      • 이를 통해 전체 요청들의 총합과 클라이언트 Error , 서버 Error 등을 카운트와 그래프로 시각화하여 쉽게 파악
      • 이를 통해 어떤 주소에서 Error가 나는지 파악 가능해짐
  • 네트워크 장비 모니터링
    • 어떤 시간대에 네트워크 포트에서 트래픽을 파악하는지 알고 싶었음
      • ex)  외부에서의 큰 파일, 정적 리소스 등이 잘못된 경우 등
    • 네트워크 장비 모니터링의 도구
      • Cacti + InfluxDB + Grafana 등을 사용
      • 이를 통해 L2 장비 및 바운드 포트 등에 확인이 가능해짐
      • 어떤 서버에서 트래픽이 어떤 시간에 많은지 확인 가능해짐
  • Metry를 Java에 넣을 수 있는 부분 설명
    • Micrometer에 대한 코드 설명
    • MeterRegistery 생성 코드 설명
    • Meter 작성 코드 설명 ( 해당 부분은 사진 생략 )
  • 임계치 선정과 Slack의 경고를 보내는 부분에 대한 설명
    • 우선 임계치는 정말 문제가 있을 때에만 경고를 보내도록 조치해야함
    • 임계치 선정의 과정
      • 일주일간의 추이를 살펴봄
      • 비정상적인 순간이 있으면 그 순간을 일단 Catch
      • 해당 순간의 1.3 ~ 1.5배의 임계치 설정
      • 그 임계치가 자주 발생하였지만 문제가 아니라면 임계치를 올리는 과정으로 작업
  • Grafana Alert 에 대한 설명
    • 15초 동안 체크
    • OK 상태에서 1분동안 Query해온 결과가 임계치 초과시 Pending
    • Pending 상태에서 1분동안 결과 초과시 Alerting
    • 해당 과정은 2번 체크 후 알람을 보냄
  • 정보 라디에이터 구축
    • 대시보드 2대 사용
    • 이를 통해 대시보드를 확인할 수 있음

4. 문제 해결의 과정 설명

  • Q1 : 메트릭을 얼마나 보관을 해야 할까
    • 실시간으로 쌓이는 값을 얼마나 관리해야 할까
    • 오래 보고 싶은 메트릭은 어떻게 해야 할까
      • Retention Policy ( RP ) 기능 사용
      • Continuous Query (CQ) 사용
      • 특정 실시간 쿼리를 오래 저장함
      • CQ에 저장하기 전 이전 데이터는 코드를 이용하여 이를 해결
  • Q2:  Grafana 대시보드의 Panel을 하나하나 그려야 하나
    • Grafana Variable를 통해 Templating할 수 있고 이를 통해 해결
    • 다만 알람을 보낼 수 없어서 알람이 있는 대시보드는 여전히 DashBoard를 직접 그려야 함
  • Q3: InfluxDB-Zabbix Plugin의 문제
    • 중간에 계속꺼짐, 특정테이블을 못가져옴
      • 내 상황에 따라 Plugin을 수정함
      • 오픈 소스의 시간 범위 최소값을 시간단위에서 분단위로 코드 수정
      • 하루에 한번씩 재시작 스케쥴링
  • Q4 : 단순한 임계치로는 판단할 수 없는 이상 상황 발생
    • 트래픽이 없는 시간대에 갑자기 두세배로 트래픽이 증가하는 등과 같은 상황에 대한 판단 필요
      • 전주 대비 비율을 실시간 계산해서 다시 저장
      • 간단한 배치 프로그램 작업을 함

5. 고민거리

  • 이상 패턴을 어떻게 조금 더 세부적으로 파악할 수 있을까?
  • 배포 파이프라인 모니터링 ?
    • 배포 시간 마킹
    • 배포 관련 메트릭 수집 - 대시보드 작성

6. 부록 및 요구사항

  •  Active Monitoring ( Passive Monitoring vs Active Monitoring )
    • Passive : 계속 쌓이고 있는 메트릭을 분석
    • Active : 실시간으로 테스팅하여 서비스가 살아있는지 죽어있는지에 대한 확인
  • 관측성 개선을 위한 요구사항
    • 외부 네트워크 환경 파악
    • 30초 단위로 파악
    • 서버 로그인이 잘 되는지 실시간 체크 -> 기술 검토 및 구현 ( AWS 고려 -> AWS Lamba 선택 -> AWS CloudWatch 스케쥴링 기능 사용
      •  Sentry 로 문제를 전달하고 Sentry가 한번 잡아주어 슬랙에 알람을 보내도록 구현함
    • 주의사항 : Health Check하는지 알아볼 수 있게 구분을 해주어야 함 ( 구분 문자 등 )

3. 생각하는 요점과 소감평

서비스의 개선은 누구나 꿈꾸고, 기존의 레거시의 문제를 관측하여 이를 개선하고 싶지만 쉽지 않은 문제라고 생각합니다. 범균님의 세션은 팀장님의 입장에서 어떻게 이를 개선한 인력을 확보하고, 전체적인 문제를 파악하여 해결할 것인가에 대한 입장을 들을 수 있었고, 여명님의 세션은 실제로 이를 개선하기 위한 개발자로서 노력했던 과정과, 사용했던 도구들에 대한 설명 및 이 과정시의 노고를 엿볼 수 있었습니다. 다음에도 범균님과 여명님의 레거시 개선 추가편이 있다면 무조건 들을 것 같았습니다. 실제 레거시 개발시에 운영인력 이외에 관측 개선 인원을 두는 것이 가장 어렵지 않았나 생각합니다. 이러한 좋은 세미나를 열어주신 아이스크림 에듀 및 범균님과 여명님께 감사드립니다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.