본문 바로가기 주메뉴 바로가기

최신IT소식

데이터베이스 모니터링 시 주시해야 할 4가지 핵심 관점

관리자 2020-09-02 조회수 111



데이터베이스 모니터링 시 주시해야 할 4가지 핵심 관점

 

데이터베이스 모니터링은 데이터베이스 성능 척도 및 리소스 추적을 포함한 여러 계층으로 구성됩니다. 그리고 데이터베이스 서버의 하드웨어와 소프트웨어의 성능과 핵심 애플리케이션 인프라의 가용성에 영향을 미치는 문제를 파악하고 방지하는 것이 목표입니다.

 

효과적인 데이터베이스 모니터링을 위해서는 데이터베이스의 여러 중요한 지표에 주의를 기울여야 합니다. 데이터베이스 성능 문제의 원인은 생각보다 훨씬 더 깊은 곳에 있는 경우가 많기 때문입니다. 아래에서 설명하는 4개의 관점에서 모니터링해야 하는 대상, 그리고 데이터베이스 성능에 가장 큰 영향을 미칠 수 있는 영역을 세부적으로 살펴봅니다.

 


1) SQL 측면의 모니터링


애플리케이션은 데이터베이스 인스턴스를 대상으로 끊임없이 SQL 쿼리를 보낸 다음, 결과를 서식화해서 사용자에게 제공합니다 이 수준에서의 병목 현상 원인은 주로 비효율적인 SQL 문입니다. 비효율적인 SQL 문은 지연과 오류를 유발하고, 처리량과 동시성을 저해합니다.

 

문제가 되는 SQL을 추적하려면 다음 영역에 데이터베이스 모니터링의 초점을 맞추십시오.

 

● 옵티마이저 통계 - 쿼리 옵티마이저는 모든 관계형 데이터베이스 관리 시스템(RDBMS)의 핵심 구성 요소이며, 쿼리를 실행하고 필요한 행을 추출할 가장 효율적인 방법을 파악해야 하므로 SQL 성능에 중요한 역할을 합니다. 쿼리 옵티마이저가 최적의 상태로 작동하려면 다양한 스키마 객체에 대한 정확한 통계가 필요합니다.

 

●실행 계획 - 실행 계획에는 데이터를 추출하는 데 필요한 단계가 포함됩니다. a 지점에서 b 지점으로 가는 가장 효율적인 방법을 알려주는 “GPS”와 같습니다. 또한 실행 계획에는 데이터베이스 객체와 관련된 인덱스, SQL 문 실행에 있는 모든 단계의 영향/비용과 같은 중요한 정보도 포함됩니다. I/O 비용, CPU 비용, 서브트리 비용과 같은 각 지표는 SQL 문이 데이터베이스 성능에 미치는 영향을 나타냅니다.

 

● 와일드 카드 - 와일드 카드는 남용하기가 쉽습니다(예를 들어 SELECT *와 같은 문). 레코드가 얼마 없는 작은 테이블의 경우 그로 인한 성능 영향은 무시해도 되는 수준입니다. 그러나 데이터베이스의 크기가 커지면 실제 필요한 것보다 훨씬 더 많은 레코드를 SELECT로 선택하는데 따르는 오버헤드도 커집니다.

 

● 필터링 - 필터링을 위한 WHERE 절은 쿼리에서 최대한 조기에 사용해야 합니다. 전체 데이터 집합을 당면한 문제에 답하는 데 필요한 데이터로 추리는 과정이 빠를수록 논리적 객체와 물리적 리소스에 가해지는 부담은 낮아집니다.

 

● 묵시적 변환 - 데이터의 형식을 변환해야 할 필요가 없도록 합니다. 테이블에서 열의 데이터 형식이 varchar이고 이 열의 값을 정수와 비교하려는 경우 묵시적 변환이 필요합니다. 이 경우 중요한 CPU 자원이 불필요하게 소모됩니다. 따라서 SQL 쿼리에 데이터 형식을 맞추는 것이 좋습니다.

 

● 행 단위의 처리 - 모든 데이터베이스는 각 테이블에서 행 단위의 반복적인 처리 보다는 세트 단위로 처리 시에 가장 좋은 성능이 나옵니다.


● 인덱스 ­- 인덱스가 너무 많거나 너무 적을 수도 있지만 인덱스를 비활성화하는 것은 실수입니다. 예를 들어 SQL Server에서 인덱싱 컬럼에 함수를 사용하는 경우 의도하지 않게 데이터베이스에서 인덱스를 사용하지 못하게 되는 경우가 있습니다.

 

2) 인스턴스/데이터베이스 측면의 모니터링


오라클이나 SQL 서버와 같은 관계형 데이터베이스 시스템을 관리하든, PostgreSQL, MySQL, MongoDB와 같은 오픈소스 및 NoSQL 플랫폼을 관리하든 이런 플랫폼의 조합을 관리하든 각 플랫폼은 성능에 영향을 미치는 요소입니다.

 

플랫폼 수준에서의 데이터베이스 모니터링은 데이터베이스의 원활한 실행에 필요한 모든 구동부에 대한 시야를 제공한다는 면에서 중요합니다. 모니터링하는 데이터베이스 플랫폼이 하나이든 여러 개이든 다음과 같은 영역을 주시해야 합니다.

 

● I/O 경합 - 가장 중요한 입력/출력 척도는 일반적으로 주어진 SQL 문에 의해 발생하는 논리적 읽기의 수입니다. 좋은 SQL을 쓰는 기술에는 데이터베이스에서 논리적 읽기를 수행하는 횟수를 줄이기 위한 끊임없는 노력이 수반됩니다. 따라서 I/O 경합은 SQL 쿼리 최적화의 중요한 척도입니다.

 

● 잠긴 객체 - 잠금은 트랜잭션이 ACID(원자성, 일관성, 독립성, 지속성) 테스트를 통과하기 위한 트랜잭션 동시성의 핵심입니다. 인덱스 자체와 같은 잠긴 객체를 검사하면 시스템에서 잠금의 근본 원인을 신속하게 찾아 해결하는 데 도움이 됩니다. SQL 문은 개별 세션 컨텍스트에서 실행됩니다. 모든 데이터베이스 세션이 활성(포그라운드에서 실행)은 아니므로 비활성 세션은 성능에 영향을 미칠 가능성이 낮습니다. 그러나 데이터베이스 잠금으로 인해 세션이 차단될 수 있습니다.

 

● 대기 통계 분석 - 대기(wait) 이벤트는 CPU, 메모리, 네트워크 리소스와 같은 특정 리소스와 관련됩니다. 이러한 리소스에서의 병목 현상은 해당 리소스에 의존하는 개별 SQL 문에 영향을 미칠 수 있습니다. 또한 잠김/차단(LCK), I/O 문제(PAGEIOLATCH), 래치 경합(LATCH) 및 네트워크 속도 저하(NETWORK)를 포함한 데이터베이스에서 작동하는 다양한 대기유형을 해석하는 방법을 알면 도움이 됩니다.

 

● 매개변수 - 모든 RDBMS에는 데이터베이스의 성능에 큰 영향을 미칠 수 있는 구성 매개변수가 있습니다. 여기에는 메모리 매개변수, 옵티마이저 매개변수, 파일 매개변수 등이 포함됩니다.

 

● 파일 - RDBMS 시스템에는 데이터 파일, 트랜잭션 로그, 실행 취소(undo) 등 다양한 파일이 있습니다. 이러한 파일이 올바르게 구성되도록 하는 것이 중요합니다. 최적의 성능을 보장하기 위한 크기 및 관련 매개변수와 연관되기 때문입니다.

 

3) 인프라 측면의 모니터링


물론 플랫폼과 SQL을 받치는 운영체제와 하드웨어가 없으면 무의미한 이야기일 뿐입니다. 이 수준에서는 다음과 같은 요소를 주시해야 합니다.

 

● CPU - 모든 쿼리에는 CPU 자원이 필요합니다. 가장 많은 자원을 소비하는 쿼리가 무엇인가요? CPU에 과도한 부담을 가하는 쿼리가 있습니까? 대부분의 활성 프로세스가 CPU 자원을 소비하는 추세가 있습니까?

 

● 메모리 - CPU 자원과 마찬가지로 쿼리에는 메모리가 필요합니다. 대량의 RAM이 교착 상태에 빠지면 다른 쿼리는 그만큼 더 오랜 시간을 기다려야 합니다. 전체 메모리 사용량을 세부적으로 살펴봐야 각 프로세스가 소비하는 메모리의 크기를 알 수 있습니다.

 

● 스토리지 하위 시스템 - 논리적 읽기는 메모리의 I/O를 참조하지만 데이터베이스는 메모리의 데이터로 쿼리에 답할 수 없는 경우 디스크에서 읽습니다. 이 경우 속도가 상대적으로 더 느리고, 읽고 쓰는 바이트가 클수록 성능에 미치는 영향도 커집니다.

 

●네트워크 - 특정한 쿼리가 네트워크 자원을 과다하게 소모합니까? 그리고 해당 쿼리는 반드시 수행되어야 합니까? 대부분의 시간을 ASYNC_NETWORK_IO 로 소비하는 쿼리가 네트워크 문제를 꼭 야기하지는 않으며, 시스템이 클라이언트에 단순히 많은 데이터를 공급하는 경우일 수도 있습니다. 그러나 높은 네트워크 사용량은 쿼리가 의도치 않게 읽기와 쓰기 요청을 네트워크로 과도하게 보내고 있음을 의미할 수 있습니다.

 

4) 사용자/세션 측면의 모니터링


사용자 측면, 그리고 때로는 세션 측면에서 심하게 착시를 할 수 있습니다. 사용자들이 불평을 제기 한다면 어딘가에 문제가 있다는 뜻이므로 문제를 찾아서 해결해야만 합니다.

 

하지만 만약 불평을 하지 않는다면? 그것으로 안심해도 좋다는 뜻일까요?

 

지금 당장 데이터베이스가 원활하게 실행된다고 해서 내일 골치 아픈 문제가 발생하지 않는다는 보장은 없습니다. 데이터베이스 모니터링은 사용자 수준에서 문제가 발견되기 전 사전에 문제를 식별할 수 있게 해줍니다.



데이터베이스 모니터링을 여러 측면에서 해야 되는 이유


4가지 측면 모두에서 데이터베이스 모니터링이 필요한 이유는 무엇일까요? 사용자 수준에서 불만을 제기하는 경우 인프라 수준에서 하드웨어에 투자해 문제를 해결하고 싶은 생각이 듭니다. 일부 IT 팀은 진단 기술에 비해 하드웨어 전문 지식이 더 높아 자연스럽게 CPU 성능과 메모리, 디스크 용량 및 기가비트 급의 처리 성능을 증설하는 방향으로 고민합니다. 마치 망치를 좋아하는 사람에게 모든 문제가 못으로 보이는 것과 같습니다.

 

물리적 환경과 가상 환경, On-Premise 와 Cloud 모두 데이터베이스 모니터링은 다양한 측면의 접근 방법을 고려하십시오. 높은 운영 시간과 낮은 지연 시간, 높은 가용성과 같은 서비스 수준 계약(SLA)을 유지하는 데 있어서 이것은 필수적입니다. 

  • 등록된 댓글이 없습니다.