구현 시에는 86. Lab CPU 사용량식별 및 경고 v2.0 문서를 참고.
1. 한 줄 정의
Azure SQL Database의 CPU 사용률이 일정 임계값(예: 평균 80%)을 넘으면 Azure Monitor를 통해 자동으로 이메일 알림이 오도록 Alert Rule을 구성하는 실습을 진행했다.
2. 이걸 왜 하는지 (핵심 개념)
- Signal / Threshold / Action Group 구조가 핵심이다. Signal은 감시할 지표(CPU %), Threshold는 위험 판단 기준(평균 80% 초과), Action Group은 위험할 때 실행할 조치(이메일 알림)를 의미한다.
- 문제가 생긴 후에 로그를 뒤져서 원인을 찾는 것과, 문제가 생기기 전에 미리 알림을 받아 대응하는 것은 다르다. 알림 체계는 후자를 가능하게 해준다.
- Aggregation Type을 Average로 설정하는 이유는, 순간적인 CPU 스파이크(쿼리 하나가 잠깐 튀는 것)와 지속적인 부하(계속 높은 상태가 유지되는 것)를 구분하기 위함이다. 실제로 위험한 건 후자이기 때문에 평균값 기준으로 판단한다.
- Elastic Pool을 쓰는 환경에서는 여러 DB가 CPU/메모리를 공유 자원 풀로 나눠 쓰기 때문에, DB 하나의 부하가 다른 DB의 성능에도 영향을 줄 수 있다. 이런 구조에서는 어느 DB가 원인인지 특정하기 위해 DB별 CPU 알림이 더 중요해진다.
3. 내 프로젝트와 연결
방역로 프로젝트에서 Azure Functions(fn_weather, fn_kahis, fn_disinfection, fn_migratory)로 매일 자동으로 데이터를 수집해 적재하는 파이프라인을 구축했다. 이런 정기 배치 구조를 실제 운영 환경으로 확장한다면, 데이터 양이 늘어나거나 특정 배치 작업이 무거워질 때 DB에 지속적인 부하가 걸릴 수 있다. 이번 실습에서 배운 CPU 알림을 적용하면 이런 상황을 사후에 로그로 확인하는 게 아니라 사전에 감지하고 대응할 수 있다고 생각했다.
4. 예상 꼬리질문 대비
Q. Static threshold 말고 Dynamic threshold는 언제 써요?
A. 트래픽 패턴이 일정하지 않고 가변적인 경우, 고정된 임계값(예: 80%)은 false positive를 자주 발생시킬 수 있다. Dynamic threshold는 ML 기반으로 정상 패턴을 학습해 임계값을 자동 조정하기 때문에, 트래픽이 시간대별로 크게 변하는 서비스에 적합하다. 다만 정확도를 위해 14일 이상의 메트릭 히스토리가 필요하다.
Q. Elastic Pool에서는 이 알림이 왜 더 중요해요?
A. Pool 밖에서는 각 DB가 자원을 독점하기 때문에 한 DB의 부하가 다른 DB에 영향을 주지 않지만, Pool 안에서는 자원을 공유하기 때문에 한 DB의 부하 급증이 다른 DB들의 성능 저하로 이어질 수 있다. 이런 연쇄 영향을 조기에 감지하고 원인 DB를 특정하기 위해 DB별 알림이 더 중요하다.
Q. 알림을 받으면 그다음엔 뭘 해요?
A. 원인 쿼리를 확인해 최적화하거나, 지속적으로 부하가 높다면 더 높은 컴퓨팅 티어로 스케일업을 검토한다. 자동화까지 고려한다면 Action Group에 Webhook이나 Logic App을 연결해 임계값 초과 시 자동 스케일업 같은 대응도 구성할 수 있다.
5. 헷갈렸던 부분 (복습용 메모)
- CPU 80%는 물리적 CPU 성능의 80%가 아니라, 내가 할당받은 컴퓨팅 티어(DTU 또는 vCore) 대비 사용 비율이다.
- 논리 서버(Logical Server)는 실제 컴퓨터가 아니라 로그인/방화벽 등을 관리하는 껍데기이고, CPU 같은 실제 자원은 서버가 아니라 그 안의 개별 DB(또는 Elastic Pool) 단위로 할당된다.
