[ 토스 기술 블로그 ] SLASH 21 - Day 1 토스의 서버 인프라 모니터링

토스의 서버 인프라 모니터링

 

모니터링 시스템의 변화

토스는 모니터링 시스템에서 2019년 -> 2021년 사이 인프라 변화가 있었음

 

DC/OS , Vamp -> Istio , kubernetes ( k8 ) 이렇게 모니터링 시스템의 변화가 생김

 

쿠버네티스를 주로 사용하다보니 프로메테우스가 메인 모니터링 시스템이 되었음

 

Service Mesh는 분산 API Gateway로 서버사이드 로드 밸런싱이 아니라 클라이언트 사이드 로드 밸런싱임

-> 하나의 Api Gateway에 장애가 발생해도 영향이 적었음

 

서비스 메쉬?
마이크로서비스 아키텍처에서 서비스 간의 통신을 관리하고 제어하기 위한 인프라 계층입니다. 각 마이크로서비스는 네트워크 상에서 서로 통신하며, 이때 발생하는 복잡한 네트워크 트래픽, 보안, 로드 밸런싱, 장애 복구, 모니터링 등을 효과적으로 관리하기 위해 서비스 메쉬가 사용됩니다.

 

사이드카 패턴 ? 
마이크로서비스 아키텍처에서 널리 사용되는 디자인 패턴 중 하나입니다. 이 패턴은 애플리케이션의 주요 프로세스와 독립적으로 동작하는 보조 프로세스를 별도의 컨테이너나 프로세스로 실행하여, 주 애플리케이션의 기능을 확장하거나 보완하는 역할을 합니다.

 

토스는 Aws route 53을 통해서 블랙박스 모니터링 중이다

 

USE method

하드웨어 모니터링

USE method : Utilization, Saturation, Errors

 

• 이용률(Utilization): 이 자원이 얼마나 사용되고 있는가?

• 포화 상태(Saturation): 이 자원이 포화 상태에 있는가? 대기열이나 지연이 발생하고 있는가?

• 오류(Errors): 이 자원에서 오류가 발생하고 있는가?

 

이 3개를 파악하여 시스템에 모니터링을 함

 

CPU

CPU 사용량 혹은 saturation을 보고 영향을 주는 원인이 CPU인지 확인을 했음

 

OS 입장에서 디스크 사용량을 확인해봤음

 

하지만 서버 인프라는 디스크에 어떤 것을 저장하지 않음 -> 왜 어플리케이션이 디스크를 많이 쓰는지 원인을 찾아봄

 

네트워크

네트워크 사용량을 비교해보고 특정 어플리케이션이 대역폭을 차지하여 방해하면 그것을 제한하는 방식을 사용함

 

CPU나 메모리는 독립적으로 사용할 수 있으나 디스크는 독립적으로 사용하기 어려움

 

이러한 OS, 네트워크 등의 지표를 활용해 쿠버네티스의 모니터링을 함

 

 

에러 처리

장비 에러문제  ->  기존부터 있는 문제라 쉬웠는데

 

쿠버네티스에서 이러한 문제를 막기는 여러 문제가 있었다 ( 이상이 있는 장비 제거에 걸리는 시간,  헬스체크하는 시간 )

 

그래서 모든 머신에 1초마다 ping을 보내 헬스체크를 했고 이상이 있으면 엔드포인트를 모두 제거했음

 

> 1초마다 ping을 보내면 부하가 되지 않을까??하는 생각

 

프로메테우스를 통해 모니터링을 하게 되면 이게 죽었을때 문제가 발생하게 된다.

 

그래서 트래픽 추적해서 삭제도 해보고 했지만 근본적 해결 방법은 아니었음

 

그래서 프로메테우스를 여러개 둬서 1개당 맡는 타겟을 분리하였음 

 

결론

네트워크 제어권을 강화해 네트워크 문제를 판단할 수 있는 메트릭을 생성

 

발생하는 이슈와 메트릭 사이의 상관관계를 높임

 

모니터링 인프라도 스케일 아웃 가능하도록 구성함