이직한 회사에 입사한 후 입사 과제로 모니터링 시스템을 구축해 봤습니다.
그 과정과 프로세스를 끄적여 보겠습니다.
참고로 저는 네트워크 지식은 일자무식이었는데요, 이 과정을 통해 인프라팀과 커뮤니케이션하면서 네트워크 지식을 쌓게 되었습니다. 물론 지금 네트워크 지식이 대단하다! 이런 건 아니고... 옛날보단 발전했다 정도입니다...
완성된 모니터링 프로세스를 정리하자면 아래와 같습니다.
1. Spring Boot Actuator를 통해 매트릭 정보를 수집
2. 프로메테우스를 이용하여 실제 운영 서버에 대한 매트릭 데이터 분석
3. Prometheus에서 분석한 매트릭 데이터를 Grafana로 모니터링 UI 출력
대략 이런 프로세스입니다.
이해를 돕기 위해 단순히 그렸는데요, 세부적으로 설명하면 그림이 조금 달라집니다.
실제 운영서버는 2대였는데요. 그중 한대에만 프로메테우스를 설정해 주었습니다.
그럼 나머지 한대에 대한 데이터는 어떻게 수집해 왔냐?
prometheus.yml 파일에서 타겟을 설정할 수 있습니다.
yml 파일에 1번 서버의 서비스 정보, 2번 서버의 서비스 정보를 입력 후 프로메테우스를 빌드하면 수집하고자 하는 모든 서버에 프로메테우스를 설치하지 않아도 한 번에 분석할 수 있습니다.
이렇게 분석한 매트릭 데이터를 3번 서버에서 빌드한 그라파나를 통해 최종적인 UI를 확인할 수 있었습니다.
그라파나와 프로메테우스를 한 서버에서 모두 빌드해도 됩니다만 당시의 저의 생각으로는...
하나의 서버에 모든 프로그램을 몰아넣고, 이후 해당 서버가 장애가 발생하는 상황이 발생하면 그라파나, 프로메테우스가 한 번에 작업이 중단되는 상황이 발생하지 않을까 라는 걱정에서 두 프로그램의 서버를 분리했습니다.
프로메테우스 동작 원리
프로메테우스는 매트릭을 push로 받아오는 게 아니라 직접 pull 해오는 방식인데요.
한마디로 매트릭 정보를 줄 때까지 기다리는 것이 아니라 매트릭 정보 내놔! 하고 직접 매트릭 정보를 수집해 온다는 것입니다. 때문에 매트릭을 수집하던 서비스가 내려간 상황에서 매트릭 수집에 실패했다는 로그가 서버에 계속해서 찍히는 현상이 발생합니다.
데이터 저장 기간
프로메테우스는 데이터 저장 기간이 디폴트로 15일로 설정되어 있습니다.
저장 기간을 너무 길게 잡으면 용량을 쓸데없이 과부하로 잡아먹게 되고, 너무 짧게 잡으면 지표를 확인하는 데에 어려움이 생길 수 있으니 적절한 기간으로 설정하는 것이 좋습니다.
데이터 유실
모니터링에서 가장 중요한 것 중에 하나가 데이터 유실이라고 생각하는데요. 저는 도커를 사용했기 때문에 볼륨을 이용함으로써 이 문제를 해결했습니다. 프로메테우스가 실행 중인 컨테이너가 삭제될 경우 이전 모니터링 기록들이 모두 지워지게 됩니다. 도커가 컨테이너를 만들어 프로메테우스를 빌드하고, 컨테이너를 기반으로 빌드된 프로메테우스는 관련 정보들을 컨테이너 내에서 관리를 하고 있기 때문입니다. 저는 볼륨을 생성하고 생성된 볼륨에 프로메테우스 관련 데이터를 데이터 마운트 해줌으로써 컨테이너가 삭제되더라도 새로운 컨테이너에서 이전 데이터를 마운트 해올 수 있게 설정했습니다.
모니터링 시스템 환경을 구축하면서 부딪혔던 문제가 2가지 있었는데요,
1. spring actuator, swagger 충돌 문제
2. docker compose로 docker service start 시 서버 내려가는 문제
1번의 경우 Spring Boot2.6.0 이상 버전에서 swagger와 spring boot actuator를 동시에 사용하면 당연히 발생하는 문제입니다.
이런 문제가 발생하는 원인은 swagger는 모든 endpoint에 대해 documentation을 역할을 합니다. 그런데 actuator 또한 몇 가지 endpoint(refresh, beans, health 등)를 생성하기 때문에 의존성이 충돌하게 되는 것입니다.
SpringFox에서는 이 문제에 대해 업데이트를 하지 않았다고 합니다.
저는 WebMvcEndpointHandlerMapping을 이용해서 의존성이 충돌 나지 않게 핸들링해주는 코드를 추가해 주었습니다.
2번 문제는 원인을 찾는 것조차 힘들었습니다.
사실 제가 직접 원인을 찾은 것도 아니고 다른 개발자분이 찾아주셔서 정확한 원인을 알게 된 것입니다...
제가 작업하던 운영 서버에서는 지금까지 docker를 한 번도 사용하지 않았기 때문에 제가 처음으로 docker를 설치한 상황이었습니다. docker를 설치하고 docker compose를 이용해서 빌드를 더 간단히 하고자 하였는데, docker compose를 start 함과 동시에 서버가 죽어버렸습니다;;
그 와중에 제가 docker compose 설정 파일을 작성할 때 서버가 재부팅될 때 docker가 자동으로 빌드되게 설정을 해놔서(이렇게 설정하는 게 더 안정성이 보장된다고 생각했음...) 죽은 서버를 재구동 시킬 때마다 docker가 자동으로 빌드되고, 서버는 다시 죽어버리는 현상이 무한 반복 되었습니다.
불행 중 다행인 것은 해당 서버가 운영서버는 아니었고 QA서버였기 때문에 실서비스에 영향이 가진 않았습니다.
저와 같은 현상을 겪는 사람이 있는지 정말 열심히 찾아보았는데 결국 원인은 찾지 못했으며,
'docker compose를 사용하면서 여러 설정파일들을 만들었는데 거기서 뭔가 문제가 발생했고, 도커가 올라갈 때마다 서버가 죽는구나..' 이 정도만 추측하고 있었습니다.
그래서 처음부터 docker compose를 사용하지 않고 docker만으로 컨테이너를 하나씩 빌드하면서 차근차근 작업을 수행해 나가니 서버가 죽는 현상은 더 이상 발생하지 않았다. 그러나 이건 올바른 해결책이 아니었습니다.
근본적으로 서버가 죽었던 원인을 알지 못한 채 '돌아가만 가게' 한 것이었기 때문입니다.
결론적으로 도커 컴포즈 실행 시 서버가 죽었던 이유는 ip 대역대 충돌 때문이었습니다.
현재 근무하는 회사의 인프라팀에서 말하길 docker에서 디폴트로 사용하는 ip 대역대와, 현직장에서 사용하는 ip 대역대가 겹쳐서 발생하는 문제라고 했습니다. 도커는 172.20.xxx.xxx를 사용하는데 현직장에서도 저 대역대를 사용하고 있었습니다. 저게 충돌이 나니까 서버가 죽어버렸던 것입니다...
즉 완벽한 해결책은 도커 빌드 시 ip 대역대가 겹치지 않게 수동으로 ip 대역대 설정 후 docker service start를 해주는 것입니다. daemon.json 파일을 생성하여 ip 대역대를 수동으로 지정 후 하면 ip대역대를 자유롭게 컨트롤할 수 있습니다.
모니터링 시스템을 구축하면서 네트워크를 공부하고, 인프라팀과 많은 커뮤니케이션을 하면서 순수 개발 이외의 지식을 쌓을 수 있었습니다. 그리고 네트워크를 잘 모르고 순수 코딩만 잘하는 개발자는 그리 좋은 개발자 같진 않습니다.
그런 의미에서 모니터링 구축을 통해 도메인 발급, 온프레미스와 aws 환경에서의 접근 권한 차이, ip/port의 역할, health check, LB방식 등 기본적인 네트워크 지식을 공부할 수 있는 기회가 되어 좋았습니다.
더 나아가 ip 대역대 충돌로 인한 서버 죽음 현상에 대한 원인을 스스로 찾지 못했던 이유에 대해서 생각해 보았습니다.
첫 번째로 네트워크에 대한 지식이 아예 없었습니다. 그래서 서버가 죽는 현상을 마주하는 순간 어디서부터 어떻게 찾아봐야 할지 갈피조차 잡지 못했습니다. 그저 현재 벌어진 현상을 통해 '유추'만 가능한 실력인 것입니다.
두 번째는 운영 경험 부족입니다. 지금까지 순수 코딩만 하는 작업만 많이 했기 때문에 운영 경험이 거의 없었습니다. 그래서 서버 이상 현상이 발생했을 때 뭐부터 해야 할지 알지 못했습니다.
결론은 네트워크 공부, 운영 경험 쌓기를 통해 레벨업을 해야 할 것 같다!
'기타 > 모니터링' 카테고리의 다른 글
| Prometheus 개념 및 동작 원리 / 아키텍처 분석 (1) | 2023.06.09 |
|---|
댓글