[한빛앤 MSA 세미나] 모니터링 | 강동호

한빛앤 MSA 세미나 강동호 연사님의 "서버 모니터링" 세미나를 듣고 정리한 글 입니다.

 

---

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

1) 개발하는데도 시간이 오래걸림

1. 요구사항 분석
2. 시스템 설계
3. 개발
4. 테스트 및 버그 수정
5. 코드 리뷰
6. 배포
7. 유지보수
8. 버그 수정

2) 대부분은 재시작으로 해결할 수 있어서

• 보통의 운영 서버의 부하 버그인 경우 재시작으로 해결이 가능

3) 아직은 문제가 발생하지 않아서

• 정확하지 않은 가용성 체크
  • ex) 저번에 배포한 서비스도 Spring 인데, 동일하게 EC2 서버크기 세팅할게요
• 잠재적 문제의 누적
  • ex) 알파환경 에서는 선착순 테스트 진행했는데 정상적이었어요
• 팀 리더의 반대
  • “아직 사용자도 적은데 나중에 붙여도 늦지 않다”

---

2. 모니터링의 중요성

모니터링이란

• 모니터링의 사전적 정의는 지속적인 감시, 관찰을 통해 상태나 가용성, 변화 등을 확인하고 대비하는 것을 의미합니다.
• 해당 세미나에서 이야기하는 “모니터링”은 “서버라는 매개체에서 진행하는 모니터링 (어플리케이션, 인프라, 로그, DB 등)” 을 포괄해서 진행합니다.
• 백엔드 개발자가 해야하는 모니터링이란!

 

모니터링의 중요성

ex) 서비스를 배포하고 난 이후 특정 시점 이후 CPU 가 100%

✔️ 만약 모니터링 시스템이 구축되어 있다면?

1. CPU 가 갑자기 치솟은 부분을 확인
2. 직전 시간대의 API 병목점 체크
3. 기존 API 정상 동작을 위한 롤백
4. 로직 보완 후 재배포
5. → 빠른 버그 추출 및 재가동 가능

---

✔️ 모니터링 시스템의 이점

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

→ 서버 모니터링은 IT 인프라의 핵심적인 부분으로, 서버의 건강 상태를 지속적으로 점검하고 시스템의 효율성과 안정성을 유지하기 위해 필수이다

---

3. 기본 지표 이해하기

모니터링에서 기본적으로 사용하는 지표 정리

✔️ CPU 지표

• CPU 사용률
  • CPU 가 얼마나 바쁜지, 얼마나 많은 작업을 처리하고 있는지 나타냅니다.
  • 지속적으로 높은 사용률은 시스템의 오버로드를 의미합니다.
  • 일반적으로 백분율 (%) 표시
• CPU 평균 로드
  • 일정시간 동안 시스템이 경험한 평균적인 부하를 의미
  • 보통 1분, 5분, 15분 간격으로 측정됩니다.
  • 평균 로드가 높으면 “지연”이 발생할 수 있어 높지 않게 유지해야합니다.
• CPU Idle 시간
  • CPU가 작업을 수행하지 않고 쉬고 있는 시간을 의미
  • 적정한 양의 아이들 타임은 중요하지만 너무 많으면 리소스 낭비를 의미합니다.
• Context Switch
  • CPU가 한 작업에서 다른 작업으로 전환되는 빈도
  • 이 지표가 높다면 비효율적인 멀티태스킹을 의미합니다.
• CPU 인터럽트
  • 하드웨어 문제나 악성 프로그램으로 인해 발생할 수 있습니다.

→ CPU 사용량 지표가 높은 상태에서 배포를 진행한다면 “배포 시간이 늘어나고 서버 리소스가 추가적으로 소모” 될 수 있습니다.
→ 되도록이면 CPU 가용룔을 50% 이하로 유지하는게 좋다.

---

✔️ 메모리 지표

• 총 메모리 사용량
  • 전체 메모리 크기 대비 현재 사용 중인 메모리의 크기
  • 메모리 사용량이 높은 경우 → 스왑 공간을 사용할 수 있어, 성능 저하를 야기시킬 수 있습니다.
• 가용 메모리
  • 현재 사용 가능한 메모리 양
• 메모리 캐시
  • 시스템이 자주 접근한느 데이터를 빠르게 액세스하기위해 사용하는 영역
  • 캐시 메모리의 사용량은 시스템 성능에 큰 영향을 줌
• 스왑 사용량
  • 디스크 공간을 임시 메모리 저장소로 사용하는 것
  • 지속적으로 높은 스왑 사용량은 메모리 자원이 부족하다는 신호
• Page Faults
  • 프로세스가 접근하려는 메모리가 현재 메모리에 없을 때 발생
  • 이 지표가 높은 빈도라면, 스왑이 많이 일어나거나 메모리 최적화가 필요

---

✔️ 디스크 지표

파일처리

• 디스크 사용량
  • 디스크의 총 용량 대비 사용 중인 용량의 비율
  • 사용률이 매우 높으면 → 성능 저하의 원인이 될 수 있음 (데이터 누락, 비정상적인 동작 등)
• 디스크 I/O
  • 디스크의 읽기 및 쓰기 작업량
  • 높은 I/O 는 디스크 성능에 영향을 미칠 수 있음
• 디스크 대기 시간
  • 디스크 I/O 요청이 처리되기까지 걸리는 시간
  • 높은 디스크 대기 시간은 디스크 성능 문제를 나타낼 수 있음, 시스템 응답 시간에 부정적인 영향
• IOPS
  • 초당 디스크 I/O 작업의 수
  • IOPS는 디스크 성능과 처리 능력을 나타냄
• 스루풋
  • 시간 당 디스크를 통해 전송되는 데이터 양
  • 높은 스르풋은 디스크가 많은 데이터를 빠르게 처리하고 있다는 것을 나타냅니다.
• 에러율
  • 디스크 읽기/쓰기 작업 중 발생하는 에러의 비율
  • 높은 에러율은 디스크의 물리적 손상이나 다른 기술적 문제를 의미합니다.

 

→ 디스크 지표는 파일 처리 성능을 위해 필수적으로 관리해야합니다.
→ 빠른 액세스를 보장하기 위해 중요

---

✔️ 네트워크 지표

• 대욕폭 사용률
  • 네트워크의 용량 대비 실제 사용량
  • 사용률이 높으면 네트워크 오버러도의 위험을 나타낼 수 있으며, 트래픽 관리 및 용량 계획에 중요한 정보를 제공합니다.
• 트래픽 흐름
  • 네트워크를 통해 이동하는 데이터의 양과 방향
  • 네트워크의 성능과 사용 패턴을 이해는 데 도움이 되며, 네트워크 최적화와 라우팅 계획에 중요한 역할을 합니다.
• 지연 시간
  • 데이터 패킷이 한 지점에서 다른 지점까지 도달하는 데 걸리는 시간
  • 높은 지연 시간은 네트워크 성능 문제를 나타내며, 특히 실시간 데이터 처리에 중요
• 패킷 손실
  • 네트워크를 통해 전송되는 데이어 퍀시 중 손실 비율
  • 패킷 손실이 발생하면, 네트워크의 문제 또는 혼잡을 의미 (데이터 전송의 신뢰성 감소)
• 연결 상태
  • 네트워크 장애 또는 다운 타임을 신속하게 감지하는 데 중요

---

4. 모니터링 도구 소개

✔️ 상용 모니터링 도구 (유료)

1. Data Dog
   1. 클라우드 환경에 특화
   2. 각 지표간 연계 가
   3. APM 기능 특화
2. Whatap
   1. 클라우드 환경 및 설치형 인스턴스 제공
   2. 스타트업 패키지가 있음
   3. 서버 모니터링 5대 무료
3. New Relic
   1. 주로 APM 툴 위주로 사용자 경험 분석 특화

• 모니터링 하기 쉬움
• 고객지원이 됨

---

✔️ 오픈소스 모니터링 도구 (무료)

1.  Zabbix
   1. 인프라 모니터링에 특화
   2. 네트워크, 가용성 모니터링에 특화
2. Prometheus
   1. 쿠버네티스 환경 특화
   2. 시계열 데이터 수집이 용이
   3. 지표 수집 및 쿼리 기반 대시보드 지원
3. ELK Stack
   1. 로그 및 데이터 분석을 위한 강력한 조합
   2. 쿼리 기반 조회를 통한 시각화

---

✔️ 초기 모니터링 도구 선택 기준

• 초반에는 가성비가 좋은 사용 모니터링 서비스가 좋은 선택이 될 수 있다. (빠른 적용 가능)
• 상용 모니터링은 손쉽게 세팅 가능하도록, 모든 패키지를 빌드에서 제공해주고 있음
• ❗️ 오픈소스 모니터링 툴(무료) 와 상용(유료)를 고민 중 이라면, 개발자의 인건비또한 고려해보는게 좋은 선택이다.
  (오픈소스 모니터링 툴을 공부하고 적용하는, 시간또한 비용)

---

5. 실시간 모니터링

✔️ 주간 모니터링 (평일 오전에 진행)

• 어제와 다른 특이점을 비교 (경고 알림은 오지 않았지만 → 평소와는 다른 서버 가용률을 모니터링 → 이슈가 터지기 전에 버그를 잡을 수 있음)
• 서비스, 서버, 연결된 DB 등을 위주로 파악
• 차이가 있다면 연관된 로직을 파악 → 문제 상황 분석

✔️  배포 시점 모니터링

• 배포 전 인스턴스 사요량을 체크 → 부하가 없을 때 배포 진행
• 배포 이후 CPU, 메모리, DB 등에 부하가 발생하지 않았는지 확인
• 문제가 확인되면, 이전 배포 버전으로 롤백

---

6.  알림 시스템의 구축 및 관리

✔️ 특정지표 알림

• 개발자가 관제하지 않아도, 문제를 확인할 수 있어야 함
• 임계값을 손쉽게 설정할 수 있는 시스템을 구축하고, 특정 메신저로 경고알림을 보낼 수 있도록 하자

✔️ 임계값 설정과 조정

언제 알림을 받아야 할까?

• 평소 상황의 +10~20% 정도를 더한값 (통상 70%) 이하 사이로 임계값을 지정
• 임계값은 어떤 서비스를 운영하는지에 따라 다르게 적용되어야 한다.

---

7. 로그 데이터

1) 로그 데이터의 이해

• 컴퓨터 시스템, 네트워크, 또는 응용 프로그램의 동작에 따라 기록되는 데이터
• Log Level
  • trace : debug 보다 세분화된 정보
  • debug : 디버깅하는데 유용한 정보
  • info : 진행상황이나 요청, 응답값 등의 정보 전달에 사용
  • warn : 에러는 아니지만, 잠재적인 오류 원인이 될 수 있는 경고성 정보
  • error : 비지니스 로직의 에러
  • fatal : 종료가 발생할 정도로 치명적인 오류
• 주의 사항
  • 로그가 저장되는 저장소의 용량관리가 필요 (너무 많이 쌓으면 안됨)
  • 개인정보, 시스템 주요 정보가 노출되지 않도록 유의 (마스킹)

 

2) 로그 관리 전략

• 시간, 로그레벨을 포함하여 기록
• 로그는 특정 기간 이후 자동 삭제되도록 지정
• 전사에서 사용하는 에러 코드와 메시지 공통화
• 항상 모든 로그 기록 x → 에러나 비지니스 관련 히스토리 위주로 기록
• 프로덕션 데이터 디버깅
  • 특정 유저 아이디인 경우에 모든 debug level 이 기록되도록 설정
    • 팀원, QA 멤버, VoC 인입 등
  • 로그 총량은 최소화하고 추가적으로 배포하지 않아도 자세한 디버깅 가능
• Exception 로그
  • 일반적으로 발생하느느 에러는 기록 x
    • ex) 이메일 Validation - 비지니스 관점에서 정상적인 처리 로직
  • 비지니스 레벨의 에러는 슬랙 알림 지정

 

3) 로그 세팅하기

Logback 설정

• SpringBoot 에 내장된 로깅 프레임워크
  • 로그 파일 사이즈 설정 가능
  • 기간 설정 가능
  • 로그 파일명, 기록되는 형태를 패턴으로 지정 가능

---

8. 모니터링과 보안

고급 옵션 살펴보기

1. 모니터링을 통한 보안 위협 감지 - ex) 상품 크롤링 감지 (외부 아이피의 반족적인 호출)
   1. 동일한 아이피의 반복 호출 확인시 알림 설정이 가능
   2. 아이피 차단 및 사용자에게 경고성 이메일 전송 등의 대응이 가능해짐
2. 서비스 간의 호출관계 파악 (MSA)
   1. 각 서비스간의 DB 내용이 바뀌었는데 누가 접근했는지 모니터링을 통해 파악이 가능
   2. 각 마이크로 서비스의 Dependency Trace 가능 (추적)
3. 개발자가 수정한 히스토리 파악
   1. 모니터링은, 서비스의 동작을 추적할 수 있는 기본적인 환경
   2. 서비스 내의 모든 동작에 대한 CCTV와 같은 역할

 

 

정리 끝!

 

---

Spring Actuator 를 고민하고 있었는데
상용 서비스인 Whatap 또한 스타트업 패키지(5개 서버 무료) 를 제공하고 있어서
좋은 선택지가 될 것 같다..