이미지 출처 : https://1000logos.net/datadog-logo/
👀 DBM에 대해 알아보기
이번에 모니터링 솔루션으로 Datadog을 새롭게 도입하면서,
관련 내용을 좀 정리 해 보려고 한다.
일단 데이터독이 무엇인지 챗지피티에게 물어보니 아래와 같이 답변을 줬다.
서버, 애플리케이션, 데이터베이스, 컨테이너, 클라우드 리소스까지 모두 한 눈에 모니터링할 수 있게 해주는 통합 플랫폼
현재 우리 회사에서는 APM, DBM, Logs, RUM 까지 연동해서 사용하고있는데
나는 그중 DBM 모니터링 연동 방법에 관해 정리 해 보려고 한다!
📝 MYSQL 설정 구성
✏️ 현재 사용중인 DB 정보
일단 현재 회사에서 쓰고 있는 DB 정보는 다음과 같다.
8.0.mysql_aurora.3.05.2
따라서 DBM 설정은 해당 mysql 버전에 맞게 세팅 해 줬으며,
현재 서비스가 EKS 환경으로 세팅 되어 있기 때문에 에이전트 설치는 kubernetes 설정으로 진행해줬다.
먼저, DBM 설정을 위해 Aurora 관리형 MySQL에서 데이터베이스 모니터링 설정 관련 문서를 참고 했다~
다른 DB에 대한 설정도 메뉴에 다 나와있으니 해당 문서를 참고하면 될 듯하다.
✏️ 관련 파라미터 적용하기
먼저, Datadog이 쿼리 성능, 지연시간 등 DB에 관련한 모니터링을 진행하기 위해서는 MySQL의 performance_schema 기능이 필수로 활성화 되어 있어야 한다고 한다.
따라서 DB의 클러스터 파라미터 그룹에서 다음과 같은 파라미터들의 설정을 바꿔줘야 한다.
| 파라미터 | 값 | 설명 |
|---|---|---|
| performance_schema | 1 | 성능 스키마를 활성화합니다. |
| performance_schema_consumer_events_statements_current | 1 | 현재 실행 중인 쿼리를 모니터링할 수 있습니다. |
| performance-schema-consumer-events-waits-current | ON | 대기 이벤트 수집을 활성화합니다. |
| performance_schema_consumer_events_statements_history | 1 | 스레드별로 최근 쿼리 기록을 추적할 수 있습니다. 활성화하면 자주 발생하지 않는 쿼리에서 실행 세부 정보를 캡처할 가능성이 높아집니다. |
| performance_schema_consumer_events_statements_history_long | 1 | 모든 스레드에서 더 많은 수의 최근 쿼리를 추적할 수 있습니다. 활성화하면 자주 발생하지 않는 쿼리에서 실행 세부 정보를 캡처할 가능성이 높아집니다. |
| performance_schema_max_digest_length | 4096 | eventsstatements* 테이블의 SQL 다이제스트 텍스트 크기를 늘립니다. 기본값을 그대로 두면1024자를 초과하는 쿼리는 수집되지 않습니다. |
| performance_schema_max_sql_text_length | 4096 | performance_schema_max_digest_length와 일치해야 합니다. |
여기서, performance_schema, performance_schema_consumer_events_statements_current, performance-schema-consumer-events-waits-current 값만 필수값이라고 표시가 되어있으며, 그 외 항목은 선택 항목인 것 같다. (*나는 모든 항목의 값을 맞춰주었당)
AWS Aurora for MYSQL 기준으로, 연결된 클러스터 파라미터 그룹에 접속하여 해당 값들을 편집 해 준다음 저장해주는 방식으로 진행하면 된다!
또한, DB 재부팅이 필요한 항목이기 때문에 수정 후에는 꼭 재부팅을 해줘야 수정사항이 반영된다.
DB 재부팅까지 완료된 상태에서,
SHOW GLOBAL VARIABLES LIKE 'performance_schema'; 명령으로 쿼리 실행시 상태가 ON으로 나온다면 정상적으로 반영된거다.
❌ 수정사항을 전부 반영했으나 performance_schema가 ON으로 조회되지 않는 경우?
나는 총 4개의 DB에 DBM 설정을 진행했는데, 2번의 문제가 발생했었다 !
💬 첫번째 문제, DB 재부팅 이후 performance_schema OFF로 조회
정상적으로 DBM을 연결하여 사용하던 도중, DB에 문제가 생겨 재부팅을 한번 진행했었는데
그 이후부터 DBM 연결이 끊어지는 문제가 발생했다🤔
(이때, 클러스터 파라미터 그룹 수정도 진행하긴 했다. 하지만 수정한 파라미터 그룹 항목은 performance_schema와 영향이 없는 max_connection 항목이였다.)
게다가, SHOW GLOBAL VARIABLES LIKE 'performance_schema'; 쿼리를 돌려 확인해보니 갑자기 상태가 OFF로 바뀌어 있었음
클러스터 그룹을 다시 확인해보니 이전에 설정해둔 performance_schema 관련된 설정은 그대로 남아있었고, max_connection 외에 다른걸 수정한것도 없었다.
하여튼 이 문제와 관련해서 챗지피티에게 물어보니 DB 재부팅 다시 시도, 인스턴스 파라미터 그룹 수정 시도를 추천해주길래 차례로 수행해봤다.
일단 DB 재부팅을 진행해도 결과는 똑같았고, 인스턴스 파라미터 그룹을 수정한뒤에 DB 재부팅을 다시 진행해도 동일한 결과가 나왔다.
이후에 결과가 똑같길래 인스턴스 파라미터 그룹은 다시 원복해놨고 계속 이것저것 건드리면서 수정해봤는데(performance Insight, 파라미터 그룹 아예 새로 만들어보기..) 결과는 여전히 동일해서 결국 msp 업체에 문의를 진행했었다.
msp 업체에 확인해본 결과 인스턴스 파라미터 그룹을 수정한 적이 있냐고 물어보셨고, 맞다고 말씀드렸더니 인스턴스 파라미터 그룹의 값이 Modified일 때는 인스턴스 파라미터 그룹이 우선 순위로 반영되니 인스턴스 그룹에 performance_schema 관련 옵션들을 활성화 해 달라고 말씀하셨다.
이렇게 설정했더니 다시 됨..! 아니 그 전에도 인스턴스 파라미터 그룹은 수정 했었는데, 이때는 왜 반영이 안된건지.. 그리고 잘 쓰던게 왜 재부팅 이후 OFF로 전환되었는지 의문이였으나
아마 중간에 계속 이것저것 건드려보면서 수정하다보니 아다리가 맞았던걸로.. 그냥 그렇게 생각하기로 했다 ㅜㅜ
여튼 새롭게 알게된 점은 아래 이미지와 같이 인스턴스 파라미터 그룹의 소스 상태가 Modified일 경우에는 인스턴스 파라미터 그룹이 우선순위로 설정된다는 점이다.
-
인스턴스 파라미터 값이 Default 인 경우, 우선 순위 적용 순서
1)클러스터 파라미터
2)인스턴스 파라미터 -
인스턴스 파라미터 값이 Default 가 아닌 경우, 우선 순위 적용 순서
1) 인스턴스 파라미터
2) 클러스터 파라미터
즉, 인스턴스 파라미터 값에서 수정을 한번이라도 했다면 인스턴스 파라미터가 우선 순위로 적용 된다는거~~~ (물론 각 설정값에 관해서!)
💬 두번째 문제, performance_schema 적용 안됨
이번에는 위 문제가 발생한 DB와 다른 DB에 performance_schema를 적용하다가 문제가 발생한건데, performance_schema와 관련된 항목을 클러스터 파라미터에서 모두 적용하고 재부팅을 한 뒤에 SHOW GLOBAL VARIABLES LIKE 'performance_schema'; 쿼리를 돌려보니 OFF로 조회되었다.
인스턴스 파라미터 그룹까지 수정한 뒤에 다시 재부팅 했으나 결과는 동일했고, 해당 DB는 운영 DB라서 재부팅을 마음대로 할 수 있는 상황이 아니라 빠르게 MSP 업체에 문의를 남겼다.
MSP 업체에서 준 답변은, 일단 파라미터 그룹은 잘 적용되어있으나 DB 구성중 성능 개선 도우미 (performance Insight) 항목이 performance_schema에 영향을 줄 수 있다고 하였다.
이때 성능 개선 도우미 항목을 확인해보니 RDS 클러스터 인스턴스는 OFF, 라이터 인스턴스에는 ON 상태로 조회 되었는데 이 부분이 좀 이상하다고 하셨다.
(왜냐면 성능개선 도우미는 클러스터단에서만 ON/OFF 설정이 가능한데, 이 둘의 싱크가 맞지 않는게 이상하다고 하심 -> 확인해보니 내 RDS에서는 클러스터단/인스턴스단 각각 성능 개선 도우미를 ON/OFF 할 수 있는 상태였다.)
여튼 둘의 싱크를 맞춰달라고 하여 둘다 ON 상태로 전환 해 봤는데 여전히 performance_schema의 상태는 OFF로 나왔고, 이번에는 둘다 OFF로 전환 해 달라고 하여 맞춰봤지만 상태는 동일했다.
이때까지만 해도 성능 개선 도우미는 DB 재부팅이 필요 없는 항목이라 재부팅을 따로 진행하지 않았었는데, DB 재부팅까지 필요하다고 하여 결국 재부팅을 시도했다 ㅜㅜ 그 후에는 정상적으로 작동한것 확인!
하여튼 내 문제 상황 + 해결 방법을 요약하면
-
첫번째, 인스턴스 파라미터를 수정하면서 테스트를 하는 과정에서 문제 발생 -> 인스턴스 파라미터를 한번이라도 수정한 경우, 우선순위는 인스턴스 > 클러스터
-
두번째, performance_schema의 설정은 DB의 성능 개선 도우미와 연관 있음 -> 성능 개선 도우미 모두 OFF 상태에서 performance_schema 정상 작동
이렇게 해결 했다!!! 😂
추가로, 각 항목들이 DB에 제대로 적용된건지 확인 하고 싶으면 show global variables LIKE '%performance%' 이런식으로 체크 가능
여기까지 적용하고 그 외 설정은 다음 포스팅에..
