한빛N MSA #9 Monitoring 세미나 - 2023년 12월

한빛N에서 기획한 주니어 개발자를 위한 모니터링 세미나(발표자 강동호님)를 듣고 정리한 글입니다. 

 

 

정글에 와드는 열심히 박으면서 서버는 왜 모니터링을 안 하나?

• 잘하는 개발자들이 있는 회사와 평범한 개발자들이 있는 회사의 차이
  • 슬랙을 어떻게 쓰느냐에서 보인다고 함
• 잘하는 개발자들은 슬랙에 뭔가 항상 울린다
  • 열심히 와드(알림)를 박아놔서 자기들 티타임 하고 있다가도 알림이 오면 달려감
• 평범한 개발자들의 회사의 경우
  • 문제 상황을 알게 되는 시점
    • 고객한테 전화가 옴
    • 사장님이 보고 나서
• 이런 부분에 대해 개발자들에게 경각심 같은 걸 어떻게 줄 수 있을까 해서 기획하게 된 세미나

 

서론

• 개발 직후 배포 시 AWS EC2 인스턴스를 어떤 걸로 해야 하는지 고민
  • 어떤 크기? 고객이 늘어나면 어떻게 대응해야 하는지?
    • 이때 필요한 것이 모니터링
• 모니터링은 초기 세팅이 잘 되어 있어야 의미 있는 데이터(가용성, 처리량, 레이턴시 등) 수집 가능

모니터링 도입이 어려운 이유

1. 도입할 시간 부족
   • 요구사항 분석
   • FE에게 API 제공
     • 시스템 설계 → 기획 내용 바탕으로 DB 설계 → API 작업
   • 테스트 코드, 버그 수정 등 비즈니스 검증 요소 작업
   • 코드 리뷰
     • 팀 내 컨벤션까지 확인
   • 배포
2. 대부분 재시작으로 해결할 수 있어서
   • e. g. 배치 실패, 지난번에도 이랬으니 재시작하겠다, 그런 뒤 정상적으로 동작 확인
3. 아직은 문제가 발생하지 않아서
   • 정확하지 않은 가용성 체크
     • 운영 배포 사이즈를 이전에 배포했던 내용과 같이 감으로 진행
     • 사례
       • 가용성 체크를 확인하지 않은 채 Spring 서비스를 AWS EC2 t4g XLarge로 세팅
       • 알파(테스트) 환경에서 선착순 테스트 진행 시 정상적인 동작
       • 실제 운영에서는 더 많은 사용자가 몰릴 것이고, 그 사용자의 수 또한 감당하는 범위인지 알 수 없음
4. 그 외
   • 잠재적 문제의 누적
   • 팀 리더의 반대

모니터링의 중요성

• 모니터링의 의미
  • 사전적 정의로 지속적인 감시 관찰을 통해 상태나 가용성
  • 그리고 변화 등을 확인하고 대비하는 것
• 모니터링 종류
  • 서비스를 담당하는 애플리케이션 모니터링
  • 가용성 부분을 체크할 수 있는 인프라 모니터링
  • 비즈니스 히스토리를 기록하는 로그 모니터링
  • DB의 부하를 파악할 수 있는 DB 모니터링
• 모니터링 사례
  • 서비스 배포 후 특정 시점에서 갑자기 CPU가 100%로 스파이크 치게 됨
    • 메모리까지 80% 이상으로 치게 됨
  • 이 상황에서 고객 접근 시 하얀색 화면을 보고, 동작이 되지 않는 문제 발생
    • 고객이 고객 지원 사이트를 통해 문의
    • CS 담당자가 확인하겠다 한 뒤 관련 내용을 개발자한테 전달하기까지 많은 시간 소요
  • 이때 만약 모니터링이 적용되어 있다면
    • CPU나 메모리 지표 확인
    • 그 시점에 API 혹은 추가적인 동작을 확인
    • 신규 API가 트리거가 된 것을 확인
    • 기존 API가 정상 동작하기 위해 롤백 진행
    • 로직 보완 후 재배포
    • → 고객 지원 이후 개발자에게 문의를 통해 대응하는 것보다 빠르게 문제 해결이 가능해짐

백엔드 개발자는 서버의 가용성 내에서 로직을 안정적으로 구동할 수 있게끔 운영해야 함

가용성 내에 안정적으로 운영하기 위해 4가지 중요점

1. 성능 최적화
   • 모니터링을 통해 부하가 발생한 위치를 파악, 성능 최적화 지점을 확인
2. 가용성 보장
   • 지표를 미리 체크하여 고객 문의 이전에 문제 상황을 확인, 비즈니스 연속성을 보장
3. 안정성 유지
   • 오류 상황을 빠르게 파악하여 시스템의 안정성을 유지
4. 보안 강화
   • 모니터링 과정에서 악성 사용자의 비정상적인 동작을 확인

모니터링의 기본 지표 이해

• CPU (로직을 처리하기에 사용되는 엔진의 부하량)
  • 사용률 ↔ 가용률
    • 정확한 동작을 위해 사용률 50% 이내로 유지를 권장
  • 평균 로드
    • 평균적인 부하
  • idle 시간
    • 쉬고 있는 시간
  • context switch
  • cpu 인터럽트
• 부하가 없는 타이밍에 배포하여 안정성 확보
• 메모리
  • 총 메모리 사용량
    • 전체 메모리 크기 대비 현재 사용 중인 메모리의 양
  • 가용 메모리
    • 현재 사용 가능한 메모리의 양
  • 메모리 캐시
    • 자주 접근하는 데이터를 빠르게 액세스 하기 위해 사용
  • 스왑 사용량
    • 메모리 크기가 부족하여 메모리가 아닌 디스크에 저장
    • 임시 메모리처럼 사용하는 부분을 의미
  • Page Faults
    • Page Fault는 스왑이 일어나서 메모리에 데이터 주소가 없는 경우 발생
    • 메모리 사용량이 충분치 않음을 의미
    • → 메모리 최적화 필요
• 메모리는 CPU와 함께 동작에 사용되는 지표
• 메모리 모니터링을 통해 시스템 접근 속도와 안정성을 개선할 수 있음

 

• 디스크 (파일 처리 관련)
  • 사용량
    • 총 용량 대비 사용 중인 용량의 비율
  • I/O
    • 디스크의 인풋과 아웃풋을 의미
    • 읽기 및 쓰기 작업량
  • 대기 시간
    • I/O 요청이 처리되기까지 걸리는 시간
    • → 해당 지표가 크면 레이턴시에 부정적인 영향을 줄 수 있음
  • iops
    • 초당 디스크 I/O 작업의 수
  • throughput
    • 시간당 디스크를 통해 전송되는 데이터의 양
  • 에러율
    • I/O 작업 중 발생하는 에러 비율
    • → 이 지표가 높으면 디스크 물리적 손상이나 다른 기술적 문제를 의미
• 디스크 지표는 파일 처리 성능, 서비스 실행, 빠른 액세스를 보장하기 위한 중요한 지표

 

• 네트워크
  • 대역폭 사용률
    • 네트워크 용량 대비 실제 사용량
  • 트래픽 흐름
    • 네트워크를 통해 이동하는 데이터의 양과 방향
  • 지연 시간
    • 패킷이 다른 지점까지 도달하는 데 걸리는 시간
    • → 이 지표가 높아지면 실시간 처리에 영향을 줌
  • 패킷 손실 비율
    • 네트워크를 통해 전송되는 패킷의 비율
  • 에러율
    • 네트워크 장비에서 감지되는 에러의 비율
  • 연결 상태
    • 네트워크 장애 상태
      • 서비스의 다운 타임을 빠르게 탐지하기 위해
• 네트워크 모니터링은 연결성을 지속적으로 검사, 최적화하기 위해 사용
• 효율성과 안정성을 개선하는데 중요한 역할

 

모니터링 도구

• 유료 (상용 서비스)
  • 데이터독
    • 클라우드 환경에 특화 간 지표 간 연계 가능
      • apm 기능 특화
  • 와탭
    • 클라우드 환경 및 설치형 인스턴스 제공
    • 서버 모니터링 5대 무료
  • 뉴렐릭
    • 주로 APM 위주
    • 사용자 경험 분석에 특화된 도구
• 무료 (오픈소스)
  • Zabbix
    • 인프라 모니터링 특화
    • 네트워크, 가용성 모니터링에 특화
  • Prometheus
    • 쿠버네티스 환경 특화
      • 시계열 데이터 수집에 용이
        • (시계열 데이터 : 일정한 시간 동안 수집된 일련의 순차적으로 정해진 데이터 셋)
    • 쿼리 기반 대시보드 지원 (PromQL)
  • ELK Stack(ElasticSearch, LogStash, Kibana)
    • 로그 및 데이터 분석을 위한 조합으로 사용

도구를 선택하는 기준

• 비용, 시간적 리소스 확인
  • 오픈소스 모니터링 툴의 경우 환경에 맞게 설치하는 비용이 발생
  • 가성비 좋은 상용 모니터링 툴을 사용하여 세팅 시간 단축하는 것도 괜찮은 방법
  • 상황과 조건에 따라 본인만의 선택 기준을 갖고 모니터링 툴을 조합하는 것이 중요

 

실시간 모니터링 전략

• 주간 모니터링
  • 개발하기엔 집중이 잘 안 되는 평일 오전
  • 팀 내에서 돌아가면서 모니터링
  • 어제랑 비교하면서 cpu 사용량 비교
• 배포 시점 모니터링
  • 사용량을 확인한 후 배포 진행
  • 배포 이후 정상 동작 확인
    • 문제 확인 시 이전 버전으로 롤백
• 알림을 통한 모니터링
  • 개발자가 직접 관제하지 않는 모니터링
    • 알림 기능을 활용하여 관제 없이 장애 상황을 대응하는 프로세스 구축 가능
  • 임계치 설정을 통한 알림
  • 특정 임계치 지속 시간에 대한 알림

모니터링 알림 설정

• 기본적으로 평소 상황에 10~20% 정도 더한 값에 70% 이하의 임계값 지정
• 임계값은 어떤 서비스를 운영하는지에 따라 다르게 적용

 

로그 모니터링의 중요성

• 로그 : SW에서 기록되는 데이터
• 로그 레벨
  • 로그 레벨을 통해 중요도 설정
  • debug : 개발하는 과정
  • info : 어떤 사용자가 처리했는지 (e. g. 유저 어카운트 id)
  • warn : validation이나 중복 처리 관련
  • error : 비즈니스 로직에 대한 오류
• 로그 관리 전략이 필요한 이유
  • 기능이 많아지고, 처리량이 많아짐에 따라 로그의 양도 늘어남
  • 개인정보나 시스템의 중요 정보는 로그에 접근할 수 있는 사람들에게 다 노출되기 때문에
  • 핵심적인 부분은 노출되지 않도록 마스킹하는 것이 중요
• 로그 관리 전략
  • 시간, 로그 레벨을 포함하여 기록 (중요도와 시점을 같이 기록)
    • 모든 내용을 기록하면 필터링을 통한 오류 파악이 어려움
    • 저장소 관리 측면에서도 비효율적
  • exception 로그
    • 모든 에러를 기록하는 게 아닌 필요한 에러만 기록
      • e. g. email validation의 경우 단순한 에러이고 비즈니스 관점에서는 정상적으로 처리한 부분
        • 이런 케이스는 로깅에 포함 X
      • e. g. 송금 시 얼마를 보냈고, 실제로 얼마로 보내졌다
        • 이런 케이스를 로깅에 포함 O
    • 송금과 같이 비즈니스 레벨의 에러는 슬랙 알림 채널로 전달

로그 세팅

• Spring Boot 사용 시 Spring 프레임워크가 지원하는 Logback
• 롤링 정책 설정(Rolling Policy)
  • maxHistory 7일, fileSize 100mb 이내 (발표자의 경우)
  • 7일이 지나면 필요하지 않은 로그로 판단, 로그 파일 삭제

 

모니터링의 성공 효과

1. 성공 예시
   • 특정 상품을 한정 판매해야 하는 상황
   • 기존에 2XLarge 인스턴스 하나당 천 명의 사용자를 커버
   • 기존 사용자 수의 1.5배 정도로 스케일아웃
   • 안정적인 인프라 예측
     • 장애 예방 및 추후 업무 중요도 상승
2. 성공 예시
   • 서비스 A에서 CPU 30%, 메모리 40% 정도 사용
   • 인스턴스 개수를 4개에서 3개로 줄여도 충분히 감당되지 않을까?
   • 기존 인프라 비용 대비 4분의 3으로 절감
     • 회사에 돈 벌어다 주는 팀원

모니터링과 보안

1. 크롤링 감지
   • 동일한 외부 IP의 반복적인 호출
     • 반복 호출이 감지되면 슬랙 알림
     • 해당 IP 임시 차단 or 세션이 포함되어 있는 계정이라면 사용자에게 경고 메일 전송
       • 비정상적 접근에 대한 네트워크 비용 감소, 가상 유저를 감소시켜 서비스의 안정성 상승
2. 기업 데이터 보안 증대
   • 비즈니스 모델 보호
3. 사람에 의한 데이터 변경 추적
   • e. g. 운영 변경으로 인해 DB 데이터를 100건 수정
     • 데이터가 잘못 들어가면서 초기 값으로 개발자가 직접 변경
       • 단순 오류 수정이 아니라 금전적인 내용이 포함되어 있다면?

 

미래의 모니터링과 기술 동향

• 차트 모양을 학습시켜 알림 제공
• 현재는 기계 학습을 넘어 ChatGPT 같은 AI 기술과 쿠버네티스와 같은 클라우드 기술의 등장
• 아마존에서 도입한 AIOps
  • 머신러닝 데이터 분석을 위해 문제 상황을 자동으로 파악할 수 있는 서비스(Amazon DevOps Guru)
  • 지표 관련 분석(Amazon Lookout for Metrics)
  • AIOps
    • 기존 모니터링 데이터에서 실행 가능한 인사이트 도출
      • 반복적인 작업 대신 중요한 작업에 더 많은 시간 사용 가능
      • 운영 비용 절감
    • 문제 완화 시간 단축
      • 실시간 데이터를 분석하고 시스템 이상을 가리킬 수 있는 패턴 설정
      • 자동화된 시스템을 통해 근본 원인 분석을 수행하고 문제를 즉시 해결

클라우드 기반 모니터링

• 과거 IDC에서 물리적인 장비가 아닌 AWS, Azure 등 클라우드 서비스를 이용하는 추세
  • 물리적인 작업 없이 인스턴스의 개수나 용량을 손쉽게 변경할 수 있음
• Kubernetes의 HPA(HorizontalPodAutoscaler, 수평 스케일)
  • 부하에 따라 Pod의 수를 증가, 감소시킬 수 있음
• 클라우드 환경에서는 인스턴스의 개수나 용량을 손쉽게 변경할 수 있음
• 부하에 따라 자동으로 파드 수 증가, 감소

 

정리

• 모니터링은 시작이 반이다
• 처음 도입은 어렵지만 판을 깔아주면 동료가 하나씩 더해가면서 완성할 수 있다.

요약

• 상용 서비스를 사용할 경우 모니터링 세팅은 생각보다 쉬움
• 모니터링을 하기 위해 항상 대시보드를 들여다볼 필요는 없다
  • 배포 전 / 후
  • 주간 모니터링
  • 임계치 알람
• 비즈니스 로직 등 중요한 부분에는 로그나 알림을 걸자
• 세팅하고 난 이후에는 자연스럽게 팀원이 스스로 세팅하는 문화가 만들어진다
• 소 잃고 외양간 고치지 맙시다