종강 기념 프로젝트 Step 3 - WPM 자동화 프로젝트 - Prometheus & Grafana 설치 및 DB Replication 설정 자동화(CentOS7)

이번 주에 정보 처리 기사 필기 시험을 신청했는데, 공부할게 점점 많아지다 보니 평소에는 진행할 여력이 안되었다..

진작에 시험볼 생각을 했어야했는데... 그만큼 더 해야한다 다짐하고 더 생각을 멈췄다!

 

아무튼 오늘 수행한 작업은 이번 프로젝트 목표의 절반 단계로 아래와 같다.

 

 Shell Script를 통한 Monitoring 환경 설치와 DB Replication 설정 자동화

 

이것저것 해본다고 고생했는데, 그러한 점은 마지막에 적어보겠다.

 

수행 순서는 Monitoring 환경 설치 자동화 후에 DB Replication 자동화를 수행하였다.

 

설명에 앞서 최종적으로 사용한 환경과 설치한 패키지 버전을 확인하면 다음과 같다.

OS: CentOS-7-x86_64-DVD-2009.iso
PHP: 7.4.
WordPress: wordpress-6.0.2-ko_KR
MariaDB 10.4
Node Exporter: 1.6.0
Prometheus: 2.45Grafana: 10.0.1 - OSS
나머지 패키지: YUM 기본 저장소 패키지 사용 설치

---

Monitoring 환경 설치

1. Node Exporter & Prometheus & Grafana란?

우선 작성한 코드의 동작 방식을 이해하기 위하여, Node Exporter와 Prometheus 설치에서 대해서 가볍게 동작 방식을 살펴보자. 

현재 프로젝트 환경에서 모니터링 환경 다이어그램

인터넷에 떠도는 다이어그램을 가져오고 싶었지만, 누군가의 고생을 무단으로 사용하고 싶지 않아 가볍게라도 다이어그램을 만들어보았다.

 

결국 현재 인프라 환경에서 모니터링 구조는 위와 같은데, 총 3가지의 구성요소가 존재한다.

 

• 존재하는 위치의 시스템 메트릭을 수집하는 Node Exporter
• 시스템 메트릭 서비스가 제공하는 엔드 포인트로 부터 이를 수집하여 관리하는 Prometheus
• Prometheus가 관리하는 시스템 메트릭을 통해 강력한 시각화 도구를 제공하는 Grafana

Node Exporter 말고도 다양한 기능을 수행하는 시스템 메트릭 수집기들이 존재하기 때문에, 데이터베이스에 저장하는 설정을 수행하거나, 그 외의 기능이 필요할 때는 별도의 메트릭 수집기를 사용할 수 있다.

Prometheus와 Grafana는 별도의 서비스이지만 각자의 공식 문서에서 서로를 어떻게 사용하는지 친절하게 알려줄 정도로 호환성이 높고 자주 사용되는 모니터링 스택이라고 볼 수 있다.

 

다이어그램에서 표시한 화살표의 방향과 텍스트에서 확인할 수 있듯이, Node Exporter에서 Prometheus로 수집한 정보를 전달하는 것이 아니라, Prometheus에서 Node Exporter가 제공하는 End-Point(기본 9100 포트)로 접속하여 시스템 메트릭을 가져오는 방식이다.

Grafana를 사용할 때도 Prometheus에서는 포트(기본 9100 포트)를 열어주기만 하면 Grafana에서 자세한 설정을 통해 Prometheus가 관리하는 정보들을 가져와 시각화 서비스를 제공한다.

 

이를 이해하면, 세 가지 서비스들을 설치하고 설정하는 위치와 이유를 쉽게 파악할 수 있다고 생각하여 한번 기술해 보았다. 나중에 다시 안적으려고..

---

2. Node Exporter 설치 과정

따라서, Node Exporter를 설치하는 과정은 매우 간단하다. 해당 가상머신에 설치만 수행하고 프로세스를 동작시키기만 하면 기본적으로 9100 포트에서 자신의 시스템 메트릭을 수집하고 확인할 수 있기 때문이다.

 

다만, Node Exporter와 Prometheus를 설치하는 과정을 살펴보면 yum 같은 패키지 저장소에서 설치가 되지 않는다.

 

이는 다운로드 받는 형식을 확인해보면 알 수 있는데, 기본적으로 서비스 데몬 형태를 제공하지 않기 때문에 흔히 사용하는 systemctl 명령어를 통해 해당 서비스를 키고, 영구적으로 동작을 원한다면 별도의 서비스 데몬으로 생성(지정)해주는 과정이 필요하다.

만약, 서비스 데몬에 등록시키지 않는다면, 다운로드 받은 패키지 안의 Node Exporter 스크립트 파일을 그냥 실행시켜 프로세스를 동작시키면 된다. 이럴 경우 기기가 재부팅될 때 자동으로 프로세스를 실행시키는 것이 불편해진다.

 잡다한 설명은 이만하고, 바로 설치하는 과정을 확인해보면 다음과 같다.

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz -P /tmp/
useradd -m -s /bin/bash prometheus # 사용자 추가
sudo tar xfz /tmp/node_exporter-* -C /home/prometheus/
mv /home/prometheus/node_exporter-* /home/prometheus/node_exporter
sudo tee /etc/systemd/system/node_exporter.service << EOF
[Unit]
Description=Prometheus Node Exporter
Documentation=https://prometheus.io/docs/guides/node-exporter/
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Restart=on-failure
ExecStart=/home/prometheus/node_exporter/node_exporter

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start node_exporter
systemctl enable node_exporter

이 과정을 간단하게 살펴보면, wget을 통해 node exporter를 다운로드받고, 이 서비스를 실행시킬 별도의 사용자를 prometheus라는 이름으로 생성한다.

별도의 서비스 데몬을 생성하여 사용할 것이기 때문에, root 외의 별도의 사용자를 만들어 사용하는 것이 보안 상 유리하기 때문에 이런 과정을 거쳤다.

 

이후 해당 사용자의 홈 디렉토리(/home/prometheus)로 다운로드받은 압축파일을 해제하고 디렉토리 명을 간단하게 변경하였다.

 

이후 너무나도 원초적인 방법으로 서비스 데몬을 생성하였다.

 

서비스 데몬을 다시 불러온 이후 Node Exporter 서비스 데몬을 실행하면 정상적으로 동작한다.

Node Exporter가 제공하는 EndPoint 접속 결과!(기본 9100 포트)

---

3. Prometheus 설치 과정

이는 Node Exporter와 동일한 과정을 거치지만, 추가적으로 Node Exporter들이 제공하는 End-Point에서 시스템 메트릭을 가지고와야하기 때문에 별도의 추가 설정이 필요하다.

wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz -P /root/MGMT/FILES/
useradd -m -s /bin/bash prometheus
sudo tar xfz /root/MGMT/FILES/prometheus-* -C /home/prometheus/
mv /home/prometheus/prometheus-* /home/prometheus/prometheus
sudo tee /etc/systemd/system/prometheus.service << EOF
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target

[Service]
User=prometheus
Restart=on-failure
ExecStart=/home/prometheus/prometheus/prometheus --config.file=/home/prometheus/prometheus/prometheus.yml --storage.tsdb.path=/home/prometheus/prometheus/data

[Install]
WantedBy=multi-user.target
EOF

echo "  - job_name: 'web1'
    static_configs:
      - targets: ['192.168.2.101:9100']
  - job_name: 'web2'
    static_configs:
      - targets: ['192.168.2.102:9100']
  - job_name: 'web3'
    static_configs:
      - targets: ['192.168.2.103:9100']">>/home/prometheus/prometheus/prometheus.yml

systemctl daemon-reload
systemctl start prometheus
systemctl enable prometheus

 

전체적인 과정은 Node Exporter와 완전히 동일하기 때문에 별도의 추가적인 설명 없이 넘어간다.

 

중간에 echo 부분이 추가되었는데, 이 부분이 각각의 엔드포인트들로부터 시스템 메트릭을 전달받는 부분이다.

 

너무나도 수준낮은 방법으로 prometheus.yml 파일에 정보를 입력했는데, 보기 쉽게하려고 일부러 이렇게 짰다고 봐주시면 감사할 것 같다. 

 

아무튼 이렇게 수행하면 프로메테우스를 위한 설정까지 모두 가능하다.

Prometheus가 제공하는 GUI. 우측은 가벼운 시각화의 예시이다.( 기본 9090 포트)

---

4. Grafana(그라파나) 설치 과정 - admin 비밀번호 재설정

그라파나는 사실 이번 프로젝트에서 프로메테우스로 Data Source를 지정하는 구문까지 작성해보고 싶었는데, 이를 수행하려면 훨씬 각잡고 Grafana가 제공하는 API를 이해하여 Token 발급 과정과 HTTP 요청까지 보내야 했기 때문에 여력이 안되어서 이 부분은 자동화까진 못하였다. 다만 가볍게 설치 과정을 확인해보고 Grafana에서 Prometheus와 연동하는 과정만 확인해보자.

sudo yum install -y https://dl.grafana.com/oss/release/grafana-10.0.1-1.x86_64.rpm
sudo /bin/systemctl daemon-reload
systemctl restart grafana-server.service
systemctl enable granfana-server.service

grafana-cli admin reset-admin-password admin123 # admin 비밀번호 변경

Grafana를 설치하는 것 자체는 굉장히 간단하기 떄문에 별도의 설명은 하지 않겠다.

 

자동화하여 Grafana를 설정하고 싶다면 아래의 공식 문서를 확인하면 될 것 같다. - API 사용법!

Data source HTTP API | Grafana documentation

 

아무튼 위의 과정을 거쳐서 설치하고 해당 가상머신의 3000 포트로 접속하면 아래의 로그인 창이 뜨고 위에서 설정한 아이디, 비밀번호로 접속이 가능하다(admin & admin123).

Grafana 최초 접속!

들어가서 좌측 상단의 메뉴 버튼을 누른 후 Connection을 선택하면 다양한 연동 서비스들이 존재하는데, 이중에서 Prometheus를 검색하여 연동을 시작할 수 있다.

Data Source Connection - Prometheus

지금까지 모든 서비스들은 HTTP 요청을 통해서 데이터를 주고받기 때문에, 마찬가지로 상세하게 프로메테우스 서버의 IP 및 포트번호를 기입하고, 저장 완료하면 별도의 작업 없이 매우 간단하게 연동이 시작된다. - 강력한 모니터링 도구인 이유!

가벼운 대시보드

위와 같이 메트릭을 선택하여 대시보드로 시각화하는 것이 가능하고, PromQL 이라는 문법을 사용하여 질의을 통해 시스템 메트릭을 쿼리할 수도 있다.

---

5. 모니터링 환경 설치 자동화

아무튼 위의 과정을 거쳐 본인은 아래 스크립트를 동작시키면 모든 서비스가 설치되도록 구성하였다.

Prometheus &Grafana 연동은 제외이다.

echo "-----------------Node Exporter 설치 시작---------------------"
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz -P /root/MGMT/FILES/
ansible webservers -m copy -a "src=/root/MGMT/FILES/node_exporter-1.6.0.linux-amd64.tar.gz dest=/tmp/"
ansible webservers -m copy -a "src=/root/MGMT/INSTALL/install_NE.sh dest=/tmp/"
ansible webservers -m shell -a "chmod +x /tmp/install_NE.sh && /tmp/install_NE.sh node_exporter-1.6.0.linux-amd64"

echo "-----------------Node Exporter 설치 완료---------------------"


echo "-----------------Prometheus 설치 시작---------------------"
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz -P /root/MGMT/FILES/
/root/MGMT/INSTALL/install_PT.sh
echo "-----------------Prometheus 설치 완료---------------------"


echo "-----------------Grafana 설치 시작---------------------"
sudo yum install -y https://dl.grafana.com/oss/release/grafana-10.0.1-1.x86_64.rpm
sudo /bin/systemctl daemon-reload
systemctl restart grafana-server.service
systemctl enable granfana-server.service
echo "-----------------Grafana 설치 완료---------------------"
grafana-cli admin reset-admin-password admin123

이 과정에 대해서도 가볍게 설명하면, 기본적으로 wget을 통해 인터넷에서 다운로드 받아야하는 파일들은 Ansible Host 가상머신에서 다운로드 받고 이를 목표하는 가상머신에 넘겨주어 사용하는 방식을 사용했다. WordPress 설치에서도 동일하게 구조를 변경했다.

 

이를 통해 생각보다 시간이 단축되고 네트워크 사용량을 줄일 수 있었다.

 

Node Exporter의 경우 ansible 명령어를 통해 2개의 파일을 호스트들에게 전송하는데, AnsibleHost에서 작성한 스크립트 파일을 Remote Host에서 동작시켜야 하므로 이러한 구조를 사용하였다.

---

DB Replication 설정 자동화

이는 기존에 완성했던 2개의 데이터베이스에 대하여 Master & Slave 설정을 하여 Relication 설정을 수행한 과정이다.

 

사실 DB Replication 만을 사용해서는 큰 장점이 존재한다고 보긴 힘들고, HA 구성을 수행해야지 궁극적인 Replication의 장점을 가질 수 있기 때문에, 구성한 이유는 넘어가보려고 한다. 복사본이 있는 것 자체가 없는 것 보단 낫지만..

 

MariaDB에서 제공하는 공식 문서는 아래와 같다.

Setting Up Replication

1. Master DB 설정

echo "[mysqld]
server-id = 1
log-basename = master1
log-bin
binlog-format=mixed">>/etc/my.cnf

sudo systemctl restart mariadb

sudo mysql -h localhost -u root -ptest123 -e "grant all privileges on*.* to rpUser@'192.168.3.%' identified by 'test123'"
sudo mysql -h localhost -u root -ptest123 -e "FLUSH PRIVILEGES"

기본적으로 /etc/my.cnf 설정파일 내에 위와 같은 설정을 [mysqld] 밑에 작성하면 된다.

server-id는 기본적으로 Unique한 값을 부여해야한다고 한다.

 

이후 MariaDB를 재시작하여 설정을 반영하고, Relication을 위한 별도의 사용자를 지정한다.

---

2. Slave DB 설정

LOG_FILE=$1
LOG_POS=$2

echo "[mysqld]
server-id = 2">>/etc/my.cnf

sudo systemctl restart mariadb

sudo mysql -h localhost -u root -ptest123 -e "CHANGE MASTER TO MASTER_HOST='192.168.3.201', MASTER_USER='rpUser', MASTER_PASSWORD='test123', MASTER_LOG_FILE='${LOG_FILE}', MASTER_LOG_POS=${LOG_POS}, MASTER_PORT=3306"

sudo mysql -h localhost -u root -ptest123 -e "START SLAVE"

slave DB에서도 /etc/my.cnf 설정파일에 server-id를 부여해주고 이를 반영시킨다.

 

추가적으로 MASTER 설정을 진행해야하는데, 여기에서 MASTER DB의 IP 주소와 사용자, 비밀번호 등을 같이 넣어줘야 한다.

 

MASTER_LOG_FILE과 MASTER_LOG_POS에 값을 지정해주어야 하는데, 이는 Master DB로 지정한 데이터베이스에서 특정 값을 확인해야한다. 이는 Master DB에서 아래와 같이 확인이 가능하다.

MariaDB [(none)]> SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| master1-bin.000001 |      646 |              |                  |
+--------------------+----------+--------------+------------------+
1 row in set (0.000 sec)

여기에서 File과 Position 값을 각각 MASTER_LOG_FILE과 MASTER_LOG_POS에 지정해주어야한다.

 

본인은 이러한 부분을 자동화하기 위해서 별도로 값을 받아와서 이를 위의 스크립트의 첫번째와 두번째 인수로 입력하여 Slave 설정을 수행했다.

 

CHANGE MASTER 쿼리를 수행하고 나면, 최종적으로 "START SLAVE" 명령문을 통하여 SLAVE 설정을 동작시키면 된다.

 

정상적으로 MASTER & SLAVE 구성이 완료되었다면, SLAVE DB에서 아래와 같이 확인이 가능하다.

 

SHOW SLAVE STATUS \G 를 통해 SLAVE 동작 확인

이렇게 확인이 된다면 정상적으로 Master & Slave 구조의 DB Replication이 동작한다.

---

3. DB Replication 자동화

위의 과정을 하나의 스크립트로 수행하면 아래와 같다.

echo "--------------Master 설정-------------------"
ansible 192.168.2.201 -m copy -a "src=/root/MGMT/DBCONFIG/master_config.sh dest=/tmp/"
ansible 192.168.2.201 -m shell -a "chmod 700 /tmp/master_config.sh && /tmp/master_config.sh"
echo "-------------Master 구성 완료---------------"

MASTER_INFO=$(ansible 192.168.2.201 -m shell -a "sudo mysql -h localhost -u root -ptest123 -e 'SHOW MASTER STATUS'" | tail -1)
FILE=$(echo $MASTER_INFO | gawk '{print $1}')
POS=$(echo $MASTER_INFO | gawk '{print $2}')

echo "$FILE"
echo "$POS"

echo "--------------Slave 설정-------------------"
ansible 192.168.2.202 -m copy -a "src=/root/MGMT/DBCONFIG/slave_config.sh dest=/tmp/"
ansible 192.168.2.202 -m shell -a "chmod 700 /tmp/slave_config.sh && /tmp/slave_config.sh ${FILE} ${POS}"
echo "-------------Slave 구성 완료---------------"

Master DB와 Slave DB를 별도로 지정하여 스크립트를 수행하도록 동작시켰고, 앞서 말한 Slave DB에서 Master DB의 정보가 필요해서 중간에 이를 입력받아 사용하는 명령어를 추가하였다.

---

현재 프로젝트 단계

현재 자동화 구성 현황

앞서 목표했던 모든 부분 요소는 포함되었다.

 

echo "-------------WPM 설치 & LB 설정------------------"
/root/MGMT/WPM.sh

echo "-------------Monitoring 설치-----------"
/root/MGMT/MONITORING.sh

echo "-------------DB Replication 설정-------"
/root/MGMT/DB_RP.sh

위의 스크립트 파일을 실행하면 위에서 확인 할 수 있는 모든 구성이 설치 및 구성된다.

 

이제 추가적으로 수행할 과정은 ALL.sh의 Playbook으로의 전환이다. 놓지말고 끝까지 수행하자!

Playbook 사용 이유 - Ansible의 장점

현재는 스크립트 기반의 자동화이다.

 

이의 가장 큰 문제점은 기존에 특정 서비스가 이미 존재하더라고 똑같은 동작을 수행하려고 하여 시스템의 리소스를 소모하거나 설정 파일을 수정시켜 불필요한 오류를 발생시킬 수 있다는 것이다.

 

IaC 기술 중 대표적인 원격 호스트 관리 도구인 Ansible과 Ansible의 스크립트 형식인 Playbook을 사용하게 된다면, 코드의 "멱등성"을 보장받을 수 있다.

 

멱등성을 보장받음으로써 몇번을 수행시켜도 추가적인 변경 사항이 없으면 현재 상태를 그대로 유지함으로써 불필요한 리소스 사용과 오류 발생 가능성을 줄일 수 있게 된다.

추가적인 보완 요소 - 발전 가능성

1. DB HA 구성을 통하여 Master DB에 서비스 장애가 발생하면 자동으로 DB2가 Active 상태로 변경하여 서비스를 지속 가능하는 구성 - 고가용성 확보
2. 정적인 WordPress 제공이 아닌 컨테이너 기반의 애플리케이션 서비스를 통하여 가볍고 빠른 배포 구성 - 서비스 배포 속도 향상
3. 컨테이너 기반의 웹 서비스 제공과 더불어 사설 GitLab을 구축하여 커밋 - 이미지 빌드 - 파드 업데이트 - 서비스 배포를 거치는 CI/CD 파이프라인을 통하여 배포 간편화
4. Node Exporter 뿐만아니라 이를 데이터베이스에 저장하여 확인 및 관리하는 모니터링 구조 구축

 

---

추가

해당 프로젝트에서 Ansible을 적용하는 부분은 진행되지 않았고, 현재 진행할 계획이 없습니다. ㅠㅠ