프로젝트를 진행하면서 이후 유저에게 서비스를 제공하는 상황을 대비하여 배포 서버에 대한 모니터링 환경 구축을 해보고자 합니다.
데이터 수집 툴 선택
우선 EC2를 모니터링하기 위한 방식을 선택할 때 2가지의 선택지를 고민했었습니다.
첫 번째 선택지는 InfluxDB였고, 두 번째는 Prometheus였습니다. 둘 다 TSDB(Time Series DataBase)로써 시계열 데이터를 다루는 데에 특화된 데이터베이스입니다.
저는 이 두 TSDB 중에서 아래의 글들을 참고하여 Prometheus를 선택하였습니다.
https://multicloud.tistory.com/m/84
위 글 내용을 참고하여 Prometheus를 선택한 이유를 간단히 설명드리겠습니다.
InfluxDB는 Push-based Monitoring System입니다. 이는 모니터링하고자 하는 응용 프로그램이 직접 데이터를 넘겨주어야 함을 의미합니다. 이는 메인 응용 프로그램에 불필요한 관심사가 추가되는 것이라 생각하였습니다.
하지만 Prometheus는 Pull-based Monitoring System입니다. 이는 메인 응용 프로그램이 있는 서버에서 exporter를 설정해주기만 한다면 Prometheus가 알아서 데이터를 수집해 오게 됩니다.
위의 차이점에서 우선 저는 Prometheus가 자신의 메인 관심사에만 관심을 가지면 된다는 점이 매력적이라고 생각하였습니다.
또한 Prometheus는 오픈소스로써 완전히 무료로 제공됩니다. 하지만 InfluxDB는 무료 버전과 유료 버전이 나뉜다는 점에서 추후 유료 버전에만 있는 기능을 사용하는 데에 제한이 있을 것이라 판단하여 Prometheus를 선택하였습니다.
Prometheus란?
Prometheus란 오픈소스 시스템 모니터링 및 알림 툴킷입니다. Prometheus는 metric 이름과 키/값 쌍으로 이루어진 시계열 데이터를 다루는 데에 특화되어 있습니다. 시계열이란 시간에 따른 변화를 기록하는 것을 말합니다.
여기서 metric이란 시간이 지남에 따라 변하는 데이터(ex) 메모리 사용률, 스레드 사용률 등)을 의미합니다.
PromQL(Prometheus Query Language)를 사용하여 시계열 데이터를 실시간으로 선택하고 집계하는 기능을 제공합니다.
Prometheus는 아래와 같은 구조를 가지고 있습니다.
간단히 설명드리면 Exporter를 이용하여 target에서 시계열 데이터인 metrics를 가져옵니다.
이후 Prometheus의 TSDB에 저장하게 되고 이를 Grafana에서 시각화할 수 있습니다.
이때 필요하다면 Alertmanager를 사용하여 알림 기능을 사용 가능합니다.
저는 이 중에서 Exporter를 이용하여 metrics를 가져오고 Grafana를 이용하여 이 데이터를 시각화하는 데에 집중하여 Prometheus를 사용하였습니다.
Prometheus 사용을 위한 설정 - 배포 서버
Prometheus에서 SpringBoot 프로젝트와 EC2 서버에 대한 정보를 pull 해올 수 있게 정보를 노출시켜주어야 합니다.
우선 SpringBoot 프로젝트에서 Spring Actuator를 적용하여 실행 중인 애플리케이션의 내부 metrics를 api로 제공하여 줍니다.
이를 위해서 build.gradle에 아래와 같은 코드를 추가해 줍니다.
implementation 'org.springframework.boot:spring-boot-starter-actuator'
이 설정 만으로 actuator 설정은 끝나게 됩니다.
이때 저희는 actuator으로 prometheus에 데이터를 줄 예정이기 때문에 build.gradle에 아래와 같은 코드도 추가해 줍니다.
implementation 'io.micrometer:micrometer-registry-prometheus'
위와 같이 설정하신 후 서버에 배포하시면 [서버의 도메인]/actuator에 들어가면 아래와 같은 출력이 나오게 됩니다.
이제 스프링 프로젝트에서 해주어야 할 일은 끝났고 기존에 배포가 진행 중이던 서버의 EC2에 접속합니다.
저희는 이제 EC2의 정보를 외부로 노출시키기 위해서 node-exporter를 사용할 것입니다.
저는 기존에 docker를 이용해서 배포를 진행하고 있었기 때문에 node-exporter를 설정하는 부분이 간단했습니다.
docker pull prom/node-exporter
docker run --name node-exporter -d -p 9100:9100 prom/node-exporter
위의 두 코드를 차례대로 입력해 주시면 node-exporter의 설정이 끝나게 됩니다.
이때 EC2에서 inbound 규칙에 9100 port를 열어주는 것을 주의해야 합니다. inbound 규칙에 이 port를 추가하는 이유는 prometheus가 이 port를 통해서 EC2에 들어와야 하기 때문입니다.
위와 같이 설정하신 후 [서버의 도메인]:9100/metrics에 접속하시면 아래와 같은 화면이 나오게 됩니다.
이제 기존 배포 서버에서 해주어야 할 일이 끝났고 모니터링 서버에서의 작업을 시작하도록 하겠습니다.
Prometheus 사용을 위한 설정 - 모니터링 서버
저는 배포를 하는 용도의 서버와 모니터링하는 서버를 별도로 분리하였습니다.
이와 같이 구성한 이유는 기존 배포를 진행하던 서버가 모종의 이유로 서비스가 불가할 때 모니터링을 통해서 이 이유를 알아내야 하지만 모니터링 서버가 배포 서버와 같은 EC2 환경에 있다면 이것이 불가능하기 때문입니다.
또한 배포 서버와 모니터링 서버를 한 곳에 둔다면 모니터링을 위해서 EC2에 접근을 하더라도 실제 요청 때문에 서버에 부하가 가중되었는지 모니터링 때문에 가중되었는지 알기 힘들기 때문에 이 두 서버를 분리하는 것이 맞다고 생각하여 이와 같이 진행하였습니다.
EC2 환경 구축은 아래의 글을 참고해서 작성하였습니다.
이제 모니터링 서버에 prometheus를 위한 설정을 시작해 보도록 하겠습니다.
우선 prometheus.yml 파일의 내용을 아래와 같이 작성합니다.
global:
scrape_interval: 10s
evaluation_interval: 10s
scrape_configs:
- job_name: 'spring-boot-server'
metrics_path: /actuator/prometheus
static_configs:
- targets: ['서버 도메인']
- job_name: 'ec2-server'
metrics_path: /metrics
static_configs:
- targets: ['서버 도메인:9100']
위 파일의 내용은 10초에 한 번씩 배포 서버에서 분석 결과를 가져오겠다는 것이고 actuator를 이용한 분석 결과와 node-exporter를 이용한 분석 결과를 받아와서 스프링부트 어플리케이션과 EC2의 환경을 모두 모니터링한다는 내용입니다.
만약 http 요청으로 들어온 즉 80 port로 들어온 요청을 load balancing을 통해서 스프링부트 어플리케이션으로 연동해주지 않았다면 아래와 같이 spring-boot-server 부분을 수정해 주시면 될 거 같습니다.
만약 다른 port로 스프링부트를 열었다면 해당 port를 작성해 주시면 됩니다.
- job_name: 'spring-boot-server'
metrics_path: /actuator/prometheus
static_configs:
- targets: ['서버 도메인:8080']
이후 이 환경에도 docker를 설치한 후 아래의 두 명령어를 쳐서 image를 받아옵니다.
docker pull prom/prometheus
docker pull grafana/grafana
이때 prom/prometheus는 프로메테우스를 위한 image이고 프로메테우스만 사용하는 것은 가독성이 좋지 않기 때문에 데이터 시각화를 위한 grafana도 같이 사용하기 위해 해당 image도 함께 가져옵니다.
이제 이 두 이미지를 컨테이너로 편하게 사용하기 위해서 docker-compose를 사용해 줍니다. 이를 위해서 docker-compose.monitoring.yml 파일을 아래와 같이 작성합니다.
version: '3'
services:
prometheus:
image: prom/prometheus
container_name: prometheus
volumes:
- ./prometheus.yml:/prometheus/prometheus.yml:ro
ports:
- 19090:9090
command:
- "--web.enable-lifecycle"
restart: always
networks:
- promnet
user: root
grafana:
image: grafana/grafana
container_name: grafana
volumes:
- ./grafana-volume:/var/lib/grafana
restart: always
networks:
- promnet
ports:
- 13030:3000
user: root
networks:
promnet:
driver: bridge
기존에 작성한 prometheus.yml을 prometheus 내부에 연결해 주고 read only로 설정해 줍니다. 또한 필요한 port를 지정해 주는 작성을 진행하였습니다.
위 파일을 작성하셨으면 아래의 명령어로 컨테이너들을 실행합니다.
docker compose -f docker-compose.monitoring.yml up -d
이제 필요한 설정이 모두 끝났습니다.
Prometheus, Grafana 작동 확인
이제 설정한 내용들이 제대로 동작하는지 확인해 보도록 하겠습니다.
우선 prometheus는 모니터링 서버의 19090 port로 연결해 두었습니다.
따라서 해당 port로 접근한 후 상단의 status를 눌러 targets에 들어가면 아래와 같은 화면이 나오게 되면 성공입니다.
이제 grafana를 확인하도록 하겠습니다.
grafana 또한 모니터링 서버에서 미리 지정해 둔 13030 포트로 접근해 줍니다. 이때 로그인 화면이 나오면 기본 아이디, 비밀번호는 admin입니다.
이제 모니터링 결과를 시각화하기 위해서 dashboard로 들어가 줍니다.
dahsboard에 들어간 후 new를 눌러 새로운 dashboard를 생성합니다.
위 화면에서 import dashboard를 눌러서 dashboard template들을 가져와줍니다.
저는 EC2 환경 모니터링을 위해서는 1860번 template을 사용하겠습니다.
1860 숫자 옆의 load를 누르면 아래와 같은 화면이 나오게 됩니다.
select a prometheus data source를 눌러서 prometheus 설정을 진행해 줍니다.
위 화면에서 prometheus를 누릅니다.
위 화면에 prometheus와 연결해 줍니다.
url에는 http://[모니터링 서버 도메인]:19090을 넣으시면 됩니다.
위와 같이 설정 후 가장 아래의 save & test를 하면 됩니다.
이후 기존 dashboard 편집 칸에서 새로 고침을 하면 prometheus를 선택하실 수 있고 이제 import를 누르시면 됩니다.
그럼 dashboard에서 위와 같은 화면을 확인하실 수 있고 배포 EC2 서버에 대한 처리가 끝났습니다.
이제 마지막으로 스프링부트 어플리케이션 모니터링을 진행하겠습니다.
다른 설정은 모두 똑같고 grafana 템플릿 아이디만 14430으로 설정해 주시면 됩니다.
이제 스프링 어플리케이션에 대한 설정도 끝났습니다. 근데 이때 HTTP Server Requests Count에 대한 Panel 부분을 확인해 보시면 Prometheus에서 데이터 수집을 위한 요청이 너무 많이 발생해서 다른 요청들을 제대로 확인하기 어렵습니다.
따라서 아래와 같이 uri가 /actuator/prometheus인 요청은 보지 않겠다고 설정해 주면 좀 더 깔끔한 panel을 만들 수 있습니다.
이번 게시글에서는 TSDB인 Prometheus를 이용하여 모니터링 환경을 구축하였고, Grafana를 통해서 데이터를 시각화할 수 있었습니다.
위와 같은 모니터링 환경은 실제로 배포를 진행하고 이에 대한 분석을 위해 필수적이라 생각합니다.
이제 사용자들이 어떤 API를 사용하는지, 언제 서버에 부하가 심하게 오는지 등에 대한 정보를 알 수 있게 되었고 이를 토대로 성능 개선 및 서버 부하 최소화를 위해서 어떤 작업을 해줄 수 있는지 등에 대해서 분석할 수 있게 되었습니다.
'배포' 카테고리의 다른 글
Logback을 이용한 EC2 환경 로그 관리 (0) | 2024.07.17 |
---|---|
AWS ec2 + rds 이용 스프링 프로젝트 배포 (4) - 스프링 프로젝트 배포 (1) | 2024.01.22 |
AWS ec2 + rds 이용 스프링 프로젝트 배포 (3) - rds 설정 (1) | 2024.01.22 |
AWS ec2 + rds 이용 스프링 프로젝트 배포 (2) - ec2 연결 (0) | 2024.01.21 |
AWS ec2 + rds 이용 스프링 프로젝트 배포 (1) - ec2 생성 및 설정 (0) | 2024.01.21 |
댓글