0. iTerm2 설치
# iTerm2가 설치되어 있지 않다면 아래 커맨드를 실행해 설치해줍니다.
brew install iterm21. iTerm2를 켭니다.
2. Preferences 메뉴를 클릭합니다.
3. Appearance 탭에서 Theme을 Minimal로 바꿔줍니다.
4. Profiles > Session 으로 이동합니다.
5. 하단의 Status bar enabled를 체크해 활성화하고, Configure Status Bar 버튼을 클릭해줍니다.
6. 터미널에서 보고 싶은 상태창을 드래그-드랍 해줍니다.
7. 색상은 하단의 Auto-Rainbow에서 변경할 수도 있습니다.
8. Status bar의 위치(상/하)는 Appearance > Status bar location (Top / Bottom) 에서 변경할 수 있습니다.
2023.05.16 - [🌏 인프라/모니터링] - Prometheus + Grafana로 Redis 모니터링 구축하기
위의 과제를 진행하면서 한 인스턴스에 각각 다른 버전의 Redis를 설치해주어야 했습니다.
Redis의 기본 포트는 6379이기 때문에, 두 Redis의 포트가 겹치지 않도록 포트 번호를 변경해 설치되도록 진행해보겠습니다!
아래 과정대로 진행해줍니다.
# Redis 소스 코드 다운로드 및 압축 해제
$ wget http://download.redis.io/releases/redis-x.x.x.tar.gz
$ tar xzf redis-x.x.x.tar.gz
$ cd redis-x.x.x
# redis.conf 파일 열고 포트 번호 변경
$ vi redis.conf
# port 6379 -> port 6378
# Redis 서버 컴파일 및 설치
$ make
$ make install
# 변경된 포트 번호로 Redis 서버 실행
$ src/redis-server redis.conf
Redis를 실행했을 때 Port가 6378로 잘 변경된 것을 확인할 수 있습니다.
2023.01.25 - [🌏 인프라/NHN Cloud] - NHN Cloud 인스턴스에 Redis 설치하기 (1) - 압축파일 이용
2023.02.08 - [💻 프로그래밍/Shell] - Redis 설치 자동화 스크립트 (1) - binary 방식
위의 포스팅을 이용해서 Redis를 설치했을 때 초기 실행 화면입니다.
하지만 뭔가 깔끔하지 않고 다음과 같은 메시지들이 떠있는 것을 볼 수 있습니다.
Warning: no config file specified, using the default config. In order to specify a config file use src/redis-server /path/to/redis.conf
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
구글링을 하면 금방 해결할 수 있지만 어떤 의미를 가지는지 한번 자세히 알아보겠습니다.
메시지를 읽어보면 어떤 내용인지, 어떻게 해야 되는지 친절하게 적혀 있기 때문에 하나씩 진행해보겠습니다!
Warning: no config file specified, using the default config. In order to specify a config file use src/redis-server /path/to/redis.conf
warning 메시지 그대로 config 파일이 세부적으로 지정되어 있지 않아서 default config를 사용하고 있음을 알 수 있습니다.
메시지에서 알려주는대로 아래처럼 config 파일을 지정해서 실행합니다.
src/redis-server redis.conf
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
리눅스 설정(/proc/sys/net/core/somaxconn)은 128로 되어 있는데 redis.conf의 TCP backlog는 511로 설정되어 있기 때문에 리눅스 설정 값을 증가하라는 메시지입니다.
$ sysctl -a | grep somaxconn
net.core.somaxconn = 128
sysctl.conf 파일의 somaxconn 값을 변경해줍니다.
$ sudo vi /etc/sysctl.conf
net.core.somaxconn = 4096
설정이 영구적으로 적용되게 하기 위해서 인스턴스를 재부팅하거나 아래 명령어를 실행해줍니다.
$ sudo sysctl net.core.somaxconn=4096
WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Memory overcommit이 반드시 실행되어야 한다고 적혀있습니다.
메모리가 부족하면 백그라운드 저장이나 복제가 실패할 수 있고, 장애가 발생할 수 있습니다.
sysctl.conf 파일의 vm.overcommit_memory 값을 1로 변경해줍니다.
$ sudo vi /etc/sysctl.conf
vm.overcommit_memory = 1
설정이 영구적으로 적용되게 하기 위해서 인스턴스를 재부팅하거나 아래 명령어를 실행해줍니다.
$ sudo sysctl vm.overcommit_memory=1
warning 메시지 없이 깔끔하게 실행되었습니다!
✔️ 이 글에서 진행할 것들
1. Redis 설치
2. Node Exporter 설치
3. Redis Exporter 설치
4. Prometheus 설치
5. Prometheus에 Exporter 연결
6. Grafana 설치
7. Grafana에 Prometheus 연결
8. Grafana에 대시보드 생성
9. Alertmanager 설치 및 Dooray! 인커밍 훅 알림 설정
monitored 인스턴스에 node exporter와 설치한 redis 버전별로 redis exporter를 설치합니다.
monitoring 인스턴스에 prometheus를 설치하고 exporter들을 연결합니다.
monitoring 인스턴스에 grafana를 설치하고 prometheus를 연결해주면, 최종적으로 exporter에서 수집되는 메트릭을 시각화해서 grafana로 확인할 수 있습니다.
이 과정을 아래에서 하나씩 진행해보겠습니다 :)
NIX 커널에 의해 도출된 하드웨어 및 OS 메트릭스 라고 하는데.. 쉽게 설명하자면 스파이와 같다고 볼 수 있습니다.
Node Exporter는 우리가 모니터링 하려는 서버에 설치되어 해당 서버의 메트릭들을 수집합니다.
✅ 공식 문서
https://prometheus.io/docs/guides/node-exporter/
Monitoring Linux host metrics with the Node Exporter | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
prometheus.io
✅ 공식 Github
https://github.com/prometheus/node_exporter
GitHub - prometheus/node_exporter: Exporter for machine metrics
Exporter for machine metrics. Contribute to prometheus/node_exporter development by creating an account on GitHub.
github.com
✅ 공식 Download
https://prometheus.io/download/#node_exporter
Download | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
prometheus.io
Redis를 설치한 인스턴스의 메트릭을 수집할 것이므로 Redis 설치한 인스턴스(monitored)에 Node Exporter를 설치합니다.
1. 설치 및 실행
wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.5.0.linux-amd64.tar.gz
mv node_exporter-1.5.0.linux-amd64.tar.gz node_exporter
cd node_exporter
nohup ./node_exporter > node_exporter.log 2>&1 &
2. 확인
Node Exporter에 의해 수집된 메트릭들을 볼 수 있습니다.
curl http://localhost:9100/metrics | grep "node_"
3. 보안그룹 9100번 열어주기
4. 접속
Node Exporter에 의해 수집된 메트릭들을 웹에서 볼 수 있습니다.
http://[IP]:9100/metrics
✅ 공식 Github
https://github.com/oliver006/redis_exporter
GitHub - oliver006/redis_exporter: Prometheus Exporter for Redis Metrics. Supports Redis 2.x, 3.x, 4.x, 5.x, 6.x, and 7.x
Prometheus Exporter for Redis Metrics. Supports Redis 2.x, 3.x, 4.x, 5.x, 6.x, and 7.x - GitHub - oliver006/redis_exporter: Prometheus Exporter for Redis Metrics. Supports Redis 2.x, 3.x, 4.x, 5.x,...
github.com
Redis를 설치한 인스턴스에 Redis Exporter를 설치합니다.
이는 Redis의 메트릭을 수집하기 위함입니다.
1. Go 설치
redis exporter 설치시 Go 빌드 과정이 있기 때문에 Go를 설치해줍니다.
wget https://go.dev/dl/go1.20.4.linux-amd64.tar.gz
sudo tar xfz go1.20.4.linux-amd64.tar.gz -C /usr/local
sudo vi /etc/profile
###golang
export PATH=$PATH:/usr/local/go/bin
source /etc/profile
go version
# go version go1.20.4 linux/amd64
2. 보안그룹 9120, 9121 열어주기
3. 설치 및 실행
git clone https://github.com/oliver006/redis_exporter.git
cd redis_exporter
go build .
# redis가 띄워져있어야 함
nohup ./redis_exporter -redis.addr=redis://localhost:6379 -web.listen-address=:9121 &
nohup ./redis_exporter -redis.addr=redis://localhost:6378 -web.listen-address=:9120 &
위에서 Node Exporter가 스파이였다면 Prometheus는 국정원과 같습니다.
Node Exporter 등이 서버의 정보(메트릭)를 모아주었다면 Prometheus는 주기적으로 pull 요청을 해 메트릭을 수집합니다.
✅ 공식 문서
https://prometheus.io/docs/prometheus/latest/installation/
Installation | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
prometheus.io
Redis를 설치한 인스턴스 말고 다른 인스턴스(monitoring)에 Prometheus를 설치합니다.
1. 설치 및 실행
wget https://github.com/prometheus/prometheus/releases/download/v2.44.0/prometheus-2.44.0.linux-amd64.tar.gz
tar xvzf prometheus-2.44.0.linux-amd64.tar.gz
mv prometheus-2.44.0.linux-amd64 prometheus
cd prometheus
nohup ./prometheus > prometheus.log /dev/null 2>&1 &
2. 보안그룹 9090번 열어주기
3. 확인
ps -ef | grep prometheus
netstat -lntup | grep prometheus
4. 접속
아래 주소에 접속하면 프로메테우스가 잘 뜨는 것을 확인할 수 있습니다.
http://[IP]:9090/
프로메테우스에 Exporter들을 연결해주겠습니다.
1. prometheus.yml을 열고 targets에 Node Exporter, Redis Exporter 주소를 입력합니다.
vi prometheus.yml
job_name과 targets를 추가해줍니다.
redis를 2가지 버전으로 설치했기 때문에 각각 기입해줍니다.
2. Prometheus 모니터링 페이지에서 연결 확인
3. Prometheus 모니터링 페이지에서 node_exporter 연결 확인
Grafana는 모은 정보를 바탕으로 시각화하는 도구입니다.
✅ 공식 문서
https://grafana.com/grafana/download/9.5.2
Download Grafana | Grafana Labs
Overview of how to download and install different versions of Grafana on different operating systems.
grafana.com
1. 설치 및 실행
wget https://dl.grafana.com/enterprise/release/grafana-enterprise-9.5.2.linux-amd64.tar.gz
tar -zxvf grafana-enterprise-9.5.2.linux-amd64.tar.gz
cd grafana-9.5.2/bin
nohup ./grafana-server > grafana.log 2>&1 &
2. 보안그룹 3000번 열어주기
3. 접속
http://[IP]:3000/
4. ID: admin / PW: admin 으로 로그인
5. 접속
Prometheus에 수집되어 있는 메트릭을 Grafana에서 확인하기 위해 Grafana에 Prometheus 정보를 입력해 연결해줍니다.
1. Administration > Data sources > + Add new data source 클릭
2. Prometheus 선택
3. URL에 IP:9090를 입력하고, 하단에 Save & Test 클릭
현재 연결한 Prometheus에는 총 3개의 exporter가 등록되어 있습니다.
Node Exporter는 node exporter 대시보드 템플릿에 연결,
Redis Exporter는 redis exporter 대시보드 템플릿에 연결해보겠습니다.
추가로 Redis 자체는 Redis Plugin을 설치해서 연결해볼 것입니다.
1) 대시보드 템플릿 다운로드
먼저 잘 만들어진 대시보드 템플릿을 다운로드 받습니다.
Node Exporter 대시보드 템플릿입니다. 들어가서 Download JSON으로 파일을 다운받습니다.
2) Grafana에 import
해당 페이지에서 다운로드 받은 node exporter와 redis exporter용 대시보드 JSON 파일을 업로드하고 하단의 Load 버튼을 누릅니다.
3) 파일별로 Prometheus에 exporter 연결
4) Redis 플러그인 설치
5) Redis 연결
6.2.9와 7.0.11을 각각 연결해줍니다.
이 때 Redis의 외부 통신이 허용되어 있어야 합니다. (redis.conf : bind, protected-mode 속성)
6) 결과
✅ 공식 Github
https://github.com/prometheus/alertmanager
1. Alertmanager 설치
wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
tar xvzf alertmanager-0.25.0.linux-amd64.tar.gz
mv alertmanager-0.25.0.linux-amd64.tar.gz alertmanager
cd alertmanager/
nohup ./alertmanager > alertmanager.log 2>&1 &
2. Prometheus Alert rules 설정
3. Dooray! web hook 연동
alertmanager.yml에 채팅방 웹 훅을 추가합니다.
4. 결과
참고 사이트
✅ 발표 영상
https://www.youtube.com/watch?v=t96l6ry_qmw
✔️ 발표 내용
HA 오픈소스 솔루션 이름
토스의 Live MySQL 데이터베이스 HA 솔루션으로 사용되고 있음
Google에서 개발된 솔루션
버전 업데이트는 중지되어서, 필요 시 자체 업데이트를 하면서 사용 중
MASTER-MASTER 01, 02노드만 MMM이 관리하도록 구성
03번 SLAVE도 MMM이 관리하도록 포함시킬 수 있지만, 신규 MASTER로 failover 하는 과정에서 대응되지 않는 케이스가 있어서
이 구성은 사용하지 않음
1. 데몬 2개 : Monitoring, Agent
2. 애플리케이션 서버 failover를 위해 각 데이터베이스 서버에 올라가는 서비스 IP
MMM이 데이터베이스 Role 변경에 따라 이동시켜 애플리케이션 서버의 failover가 이루어지게 함
이 모니터링 항목에서 이상이 있을 시, MMM이 standby MASTER로 failover 진행
active : DATA-CENTER1
standby : DATA-CENTER2
단방향 복제 구성 : DATA-CENTER 간, standby DATA-CENTER 내의 local MASTER 간
-> IDC failover 시 Role 전환 작업 필요..
신규 active DATA-CENTER의 MySQL 서버를 MASTER-MASTER 구성으로 전환해야 함
DATA-CENTER 간 MySQL 서버의 MASTER-SLAVE 관계도 전환해주어야 함
신규 standby DATA-CENTER의 MySQL 서버는 MASTER-SLAVE 단방향으로 전환해야 함
-> 어려운 작업은 아니지만 번거롭고 부담스러운 작업들 -> 개선 필요!
재난 시 비즈니스 연속성 보장이므로
데이터 센터 failover를 할 경우가 거의 발생하지 않을 거라고 생각했지만
토스의 간편결제 파트너사 증가 -> 무중단 운영의 필요성 증가
-> 무중단 데이터 센터 롤링 작업으로 계획이 됨
-> 데이터베이스 서버도 데이터 센터 failover가 필요해짐
-> 진행하다 보니 데이터베이스 Role 전환 작업에 대한 부담 증가 + 실수로 복제가 깨지는 경우도 발생 + 다운타임 필요 + 위험부담 큰 작업도 발생
-> 데이터 센터 전환 과정을 최대한 간소화시킬 필요가 생김
1. 양쪽 데이터센터 -> 대칭 구조
2. 데이터센터 failover 시, 애플리케이션 서버 커넥션만 이동하고
3. 데이터베이스 레벨에서는 따로 작업할 것이 없는 구조
1. 기존에 단방향으로 있던 DR 복제 채널
2. DR 센터 내에 MASTER-SLAVE 복재 채널
but,, 두 가지 이슈 발생
1. binlog 중복 전송 이슈
01, 02번 -> log_slave_update 옵션을 켜고 운영
sql_thread가 적용한 트랜잭션도 binlog에 기록하는 옵션
1. actvie 데이터센터 01번에서 발생한 트랜잭션의 binlog 생성
2. DR 채널을 따라 standby 데이터센터 01번으로 전송 및 적용됨
3. 적용 이후, standby 데이터센터 01번 서버 -> 이 트랜잭션에 대한 binlog 생성
4. 이때 01번의 slave로 있는 02, 03번 -> 이 binlog를 복제하고 적용하게 됨
단방향 구성 시 binlog 복제 흐름과 동일함
5. 그런데 02번에서 최종 적용한 binlog가 자체 binlog로 생성이 되고,
6. 01번은 02번의 master면서 slave이기 때문에, 이 binlog를 복제해야 하는지 판단함
이 판단 -> 해당 binlog가 처음 생성된 서버의 server-id와 자신의 server-id가 다른지 비교해서 이루어짐
다를 경우 복제 진행
이 binlog는 데이터센터1에서 처음 생성되었기 때문에 server-id 101을 계속 유지하고 있는 상황
server-id 1001인 01번으로 다시 복제가 되어버림
여기서 적용이 되면 다시 또 03, 02번으로 복제 되는 상황이 생길 수 있음..
실제 값 변경이 없었다면 binlog가 생성되지 않는데,
동일 binlog가 적용된 지 1초도 지나지 않은 상황이기 때문에
4번의 상황까지 나올 확률은 적지만
이론적으로는 무한 루프가 가능해져버림
2. MMM이 복제 채널을 구분하지 못하는 이슈
각 데이터센터의 01번 서버는 DR 양방향 복제 채널이 추가됨으로 인해서
DR 복제 채널과 local master-master 복제 채널이 동시에 생성된 멀티소스복제 상태가 됨
이 경우 MMM은 자신이 모니터링 해야 할 채널이 어떤 채널인지 알지 못하게 됨
1. binlog 무한 루프
방법 1) Gtid로 중복 적용 막기
but,, 당시 바로 Gtid 전환은 어려운 상황
Gtid로 가더라도 binlog의 전송 루프 (No I0 Thread skip)은 발생하게 되고
다시 binlog position 방식으로 전환 시 이슈가 되기 때문에.. 중복 전송 자체를 막을 방법이 필요
방법 2) binlog filter 걸기
2. 어떤 채널?
MMM이 MM 채널에 대해서만 모니터링을 하도록 소스를 수정
