AAS로 데이터베이스 부하와 병목 원인을 추적한다

Average Active Sessions(AAS, 평균 활성 세션 수)는 데이터베이스에서 동시에 활동하는 세션의 평균을 나타내는 지표다. CPU 사용률이나 초당 입출력 작업 수(IOPS)만으로는 알기 어려운 부하의 크기와 원인을 살펴볼 수 있어 데이터베이스 성능 모니터링과 문제 진단에 활용된다.

세션은 특정 작업이나 SQL 쿼리를 실행하는 사용자 프로세스를 가리킨다. 여기서 ‘활성’은 데이터베이스에 연결만 된 상태가 아니라 실제로 무언가를 처리하는 상태를 뜻한다. AAS는 정해진 수집 구간 동안 활성 세션이 평균 몇 개였는지를 나타낸다. 그래프의 막대 하나가 5초를 나타낸다면, 그 막대의 값은 해당 5초 동안 동시에 실행된 SQL 쿼리의 평균 개수다. AAS는 Active Session History(ASH)의 일부이며, 데이터베이스 활동을 시간에 따라 기록하는 시계열 지표다.

AAS는 세션이 CPU를 사용했는지, 잠금·버퍼·래치에서 대기했는지, 입출력을 기다렸는지 등 쿼리가 시간을 보낸 여러 지점을 한 지표로 살펴보게 한다. 값이 0에 가까우면 데이터베이스가 거의 유휴 상태임을 시사한다. 쿼리가 전혀 없다는 뜻이라기보다 쿼리 수와 처리 속도가 매우 낮아 지표에 거의 잡히지 않는 경우일 수 있다.

AAS가 1보다 작으면 모든 세션이 각기 다른 속도로 진행 중이며 차단된 세션이 없다는 뜻이라고 설명한다. AAS가 가상 CPU(vCPU) 수보다 낮으면 시스템에 여유 용량이 있고 작업이 원활히 실행될 것으로 볼 수 있지만, 이 경우에도 세션 하나가 차단돼 있을 수 있다. AAS가 vCPU 수를 넘으면 일부 세션이 대기하는 포화 상태일 가능성을 나타내며, 차이가 커질수록 병목도 두드러질 수 있다.

아마존에서 여섯 자릿수 규모의 데이터베이스 인스턴스를 분석했을 때 AAS가 vCPU 수의 5배를 넘으면 시스템에 심각한 병목이 있다고 판단되는 경우가 거의 항상 나타났다고 설명한다. 이에 따라 고객에게 잠재적인 성능 문제를 알리는 기본 경보 기준으로 AAS 5배 vCPU를 설정했다. 이 기준은 애플리케이션이나 쿼리 지연 시간의 기대치를 알아야 하는 다른 지표와 달리 여러 시스템과 애플리케이션에 적용할 수 있다는 것이 글의 설명이다. 다만 높은 AAS가 언제나 문제를 뜻하지는 않는다. 시스템이 적절히 조정돼 있고 자원을 효율적으로 사용한다면, 높은 값은 데이터베이스가 바쁘게 일하고 있음을 나타낼 수도 있다.

AAS 그래프와 다른 지표의 차이

AAS 그래프에서 막대 높이는 각 구간의 평균 활성 세션 수를 나타낸다. 색상은 세션의 대기 유형이나 상태를 구분한다. CPU 작업 중인지, 입출력을 기다리는지, 다른 세션의 처리를 기다리는지 색상으로 살펴볼 수 있어 특정 대기 상태에 세션이 몰리는 패턴을 찾는 데 도움이 된다.

CPU 사용률은 현재 사용 중인 프로세서 용량을 백분율로 나타내지만, 100%에 도달했다는 사실만으로 수요가 공급을 얼마나 초과하는지는 알 수 없다. 어떤 사용자나 SQL 쿼리가 CPU를 많이 쓰는지도 보여주지 않는다. 예를 들어 vCPU 16개인 시스템에서 실행 가능한 쿼리 16개가 있든 32개가 있든 CPU 사용률은 100%로 표시될 수 있다. 하지만 두 번째 상황에서는 CPU를 기다리는 쿼리가 더 많다. AAS는 두 번째 상황의 값이 32라고 나타내 수요가 첫 번째 상황의 두 배임을 보여줄 수 있다.

IOPS도 수행된 입출력의 양은 보여주지만 누가 입출력을 일으켰는지는 알려주지 않는다. AAS 데이터를 상위 사용자나 상위 SQL 쿼리별로 묶으면 I/O 대기가 많은 원인을 좁힐 수 있다. CPU 사용률이 100%일 때도 같은 방식으로 데이터를 나눠 어느 사용자와 쿼리가 CPU를 많이 쓰는지 살펴볼 수 있다. 따라서 AAS는 용량을 표시하는 데 그치지 않고 성능 문제의 원인을 조사하는 진단 도구로 쓰인다.

AAS는 활성 세션을 표본 추출한 데이터에서 만들어진다. 각 표본은 특정 시점의 데이터베이스 상태를 담으며, 실행 중인 쿼리와 사용자, 대기 상태, 접속한 애플리케이션 서버 등의 정보가 포함될 수 있다. 이 데이터를 상위 사용자, SQL 쿼리, 대기 상태 같은 기준으로 나누어 살펴보면 성능 문제를 더 세밀하게 분석할 수 있다.

CPU 사용률이 100%여도 원인을 모를 때 상위 사용자나 SQL별로 AAS를 분류하면 CPU를 많이 쓰는 대상을 찾을 수 있다. 최대 IOPS에 도달했을 때는 사용자나 SQL별로 I/O 대기를 살펴볼 수 있다. AAS 그래프에 표시되는 Max CPU 선은 시스템이 사용할 수 있는 최대 CPU 용량을 나타낸다. vCPU가 16개라면 이 선은 AAS 그래프의 16에 놓인다. CPU 항목의 AAS가 이 선을 넘으면 처리 능력에 대한 수요가 시스템 용량보다 클 수 있다. 예를 들어 AAS가 32이고 Max CPU가 16이라면 평균적으로 CPU를 요구하는 활성 세션이 처리 용량의 두 배이며, 세션의 절반은 CPU를 기다리는 상황을 뜻한다.

이런 상황에서는 SQL 쿼리 최적화, 작업 부하 분산, CPU 자원 확장 등을 검토할 수 있다고 설명한다. 다만 AAS가 문제의 가능성과 맥락을 알려주는 것이지, 특정 조치가 항상 해결책이라는 뜻은 아니다.

시간 지표로서의 AAS

AAS는 각 그래프 구간 동안 동시에 실행된 SQL 쿼리의 평균이자, 초당 데이터베이스가 SQL 쿼리 처리에 소비한 경과 시간의 양으로 설명된다. AAS와 초당 평균 쿼리 실행 횟수를 알면 쿼리당 평균 경과 시간을 계산할 수 있다. 계산은 AAS를 초당 실행 횟수로 나누는 방식이다. 예를 들어 AAS가 2이고 초당 쿼리 실행 횟수도 2라면 쿼리당 평균 경과 시간은 1초다. 글은 이를 AAS가 동시 부하뿐 아니라 쿼리 처리 시간에 관한 정보도 제공하는 방식으로 제시한다.

사례와 흔한 오해

한 조직은 특정 시간대마다 CPU 사용률이 100%에 이르고 애플리케이션이 느려졌지만, 기존 지표만으로는 원인을 파악하지 못했다. AAS를 분석하자 이 시간대에 값이 높았고 최대 CPU 용량 선을 넘기도 했다. 상위 SQL별로 데이터를 나눈 결과 복잡한 쿼리 몇 개가 해당 시간대에 활성화된 것을 찾아냈으며, 쿼리를 다시 작성해 최적화한 뒤 AAS와 CPU 사용률이 크게 낮아졌다고 사례는 설명한다.

다른 회사는 높은 I/O 대기로 성능 저하를 겪었지만 기존 지표로는 원인이 된 사용자와 SQL을 찾지 못했다. AAS 데이터를 I/O 대기별로 분석하자 대량의 데이터를 전송하는 특정 쿼리를 소수의 사용자가 실행하고 있었다. 해당 쿼리와 사용자를 파악한 뒤 일부 테이블을 재색인하고 SQL을 수정해 I/O 대기를 크게 줄였다고 한다. 이 사례들은 원문이 제시한 사례이며, 실험 조건이나 수치 비교는 제시되지 않았다.

글은 AAS를 단순한 용량 지표로만 보는 것, 시간 기반 성능 분석과 관련이 없다고 보는 것, 높은 AAS가 항상 나쁘다고 보는 것을 오해로 꼽는다. AAS는 동시성과 경합에 관한 정보를 제공하고, 시간에 따른 쿼리 활동과 관련되며, 높은 값만으로 문제가 확정되지는 않는다는 설명이다. 시스템이 효율적으로 작동한다면 높은 AAS는 가치 있는 작업을 많이 처리하고 있다는 뜻일 수 있다.

향후 활용과 설계 배경

글은 클라우드 데이터베이스의 병목 파악, AI·머신러닝을 활용한 성능 조정과 예측, 실시간 분석 도구, 자율형 데이터베이스의 성능 관리에서 AAS가 활용될 가능성을 제시한다. 이는 앞으로의 활용 전망으로 소개된 내용이다.

AAS를 처음 설계한 사람은 존 베레즈니에비치(John Bersniewicz)와 자신이라고 밝힌다. AAS를 설계한 지 20년 동안 교육과 설계, 코딩, 강연과 시연에 집중했지만 글로 설명하는 일은 충분하지 않았다고 회고한다. 오라클, 아마존, Datadog, Embarcadero의 AAS 모니터링 인터페이스 설계에 참여했고, TCL/TK로 그래픽 도구를 만들고 데이터베이스 공유 메모리에서 직접 데이터를 읽는 C 코드도 작성했다고 한다. 연속적으로 활성 연결을 표본 추출하는 프로그램은 뒤에 마르친 프셰피오로프스키(Marcin Przepiorowski)가 확장해 ‘S-ASH’ 또는 Simulated Active Session History 도구로 만들었다고 설명한다. 글은 AAS에 대한 서면 자료가 부족했던 점이 최근 소셜미디어에서 드러난 오해에 한몫했다고 말한다.

AAS의 의미를 둘러싼 논의

제러미 슈나이더(Jeremy Schneider)는 트위터에서 활성 세션이나 연결의 현재 상태를 표본으로 확인하는 지표라며, 잠금 상태의 활성 세션은 용량보다 작업 부하를 더 잘 반영할 수 있다고 말했다. CPU·I/O·네트워크 상태를 보여주는 표본도 실제 용량을 충분히 드러내지 않을 수 있다고 덧붙이며, ‘성능’이 모호하다면 ‘용량’이라는 말이 더 적절한지 물었다.

존 베레즈니에비치(John Beresniewicz)는 자신의 글에서 AAS는 성능 지표이지만 평균 지연 시간이나 트랜잭션 처리량처럼 성능 자체를 직접 측정하는 지표는 아니라고 설명했다. AAS는 핵심 성능 지표인 DB Time의 ‘속도’를 측정한다고 덧붙였다. 그가 제시한 관계식은 다음과 같다.

AAS = 초당 트랜잭션 수 × 트랜잭션당 초

AAS = 평균 지연 시간 × 처리량

트랜잭션 대신 사용자 호출을 써도 같은 관계가 성립한다며, 사용자 호출이 늘거나 호출당 지연 시간이 늘면 AAS가 증가한다고 설명했다. 프랑크 파쇼(Franck Pachot)는 트위터에서 그래프의 색상은 확장 가능성을 보여줄 수 있고, 컴퓨팅 자원이나 디스크는 확장할 수 있지만 잠금과 래치는 그렇지 않다고 말했다.