Monitoring 데이터독, 자빅스 등 : 내 인프라 환경엔 뭐가 맞을까?

CPU 100% 안 넘으면 안전할까? 경험 많은 시니어 엔지니어가 폭탄 돌리기 멈춘 방법

엔터프라이즈 환경에서 인프라를 운영하다 보면 누구나 한 번쯤 “서버가 왜 이렇게 느리죠?”라는 날카로운 질문을 받게 됩니다. 특히 Oracle ExaCC 같은 고성능 통합 플랫폼이나 대규모 클라우드 환경을 다룰 때는 식은땀이 절로 납니다. 아주 작은 병목 지점 하나가 서비스 전체를 마비시키는 ‘나비효과’를 현장에서 수없이 목격했기 때문입니다.

예전에는 장애가 터지면 화려한 대시보드부터 켜고 멍하니 쳐다보곤 했습니다. 하지만 수년간 밤을 새우며 장애 분석을 해보니, 진짜 중요한 건 모니터링 툴의 화려함이 아니었습니다. 수많은 데이터 중 ‘지금 진짜 문제가 되는 지표’를 선별하고, 그들 간의 상관관계를 읽어내는 눈이 핵심이었습니다.

단순히 CPU 사용률이 높다고 서버 사양을 올리던 시대는 끝났습니다. 시스템의 물리적 자원(OS)과 그 위에서 돌아가는 워크로드(DB)가 어떻게 연결되어 있는지 모르면 밑 빠진 독에 물 붓기가 되기 십상입니다. 오늘은 제가 현장에서 구르며 깨달은, 반드시 챙겨야 할 핵심 지표와 현대적인 모니터링 솔루션 활용 전략을 가감 없이 공유해 드립니다.

1. OS 레벨: 하드웨어와 커널의 겉모습에 속지 않는 법

OS 모니터링은 시스템의 기초 체력을 보는 단계입니다. 장애가 나면 가장 먼저 열어보는 곳이지만, 단순히 “숫자가 낮으니 괜찮네” 하고 넘어가면 진짜 폭탄을 놓치게 됩니다. 우리는 수치 자체가 아니라 대기 큐(Queue)와 지연 시간(Latency)의 미세한 변화를 포착해야 합니다.

1) CPU 사용률보다 ‘Load Average’와 ‘CPU Steal’에 주목해야 하는 이유

많은 인프라 관리자가 CPU 사용률(Utilization)이 70% 미만이면 시스템이 아주 안정적이라고 안심합니다. 저 역시 초년생 시절엔 그랬습니다. 하지만 실제 사용자가 체감하는 응답 속도를 결정짓는 진짜 범인은 따로 있었습니다.

• Load Average (시스템의 진짜 병목 구간): 이건 단순히 CPU가 얼마나 일하는지가 아니라, ‘내 차례를 기다리며 줄을 서 있는 프로세스의 평균 개수’입니다. 예를 들어 코어가 4개인 서버에서 이 수치가 4라면 CPU가 풀가동 중인 상태입니다. 만약 이 수치가 코어 수를 넘어가면 프로세스들이 줄을 서기 시작합니다. 부하가 심해지면 CPU가 실제 연산을 하기보다 프로세스를 교체하는 데 힘을 다 쓰는 ‘컨텍스트 스위칭(Context Switching)’ 오버헤드가 발생해 시스템이 먹통이 됩니다.
• CPU Steal (클라우드 환경의 자원 도둑): AWS나 GCP 같은 클라우드 환경을 쓰신다면 이 수치를 눈여겨보셔야 합니다. 내 가상 머신(VM)이 일을 하려고 하는데, 하이퍼바이저가 같은 물리 서버를 쓰는 ‘이웃집 VM’에 자원을 먼저 퍼주는 바람에 멍하니 기다린 시간(st)을 뜻합니다. 흔히 말하는 ‘Noisy Neighbor(시끄러운 이웃)’ 문제입니다. 이 스틸(Steal) 값이 지속적으로 5~10%를 넘긴다면, 억울하지만 인프라를 업그레이드하거나 인스턴스를 껐다 켜서 다른 깨끗한 물리 노드로 이사를 가야 합니다.

💡 실무자를 위한 관리 기준 요약

• Utilization (CPU 연산량): 70~80% 수준으로 유지하는 것이 마음 편합니다.
• Load Average (대기 프로세스): 무조건 CPU 코어 수 미만으로 떨어뜨려 놔야 안전합니다.
• CPU Steal (자원 손실): 클라우드 기준 1~3% 미만이어야 이웃을 잘 만난 것입니다.

2) 메모리: “Free 메모리가 없어요!”라며 놀라지 마세요

리눅스 서버를 처음 관리하시는 분들이 가장 많이 하는 실수가 “free 메모리가 0에 가까워요! 서버 터지기 직전입니다!”라며 밤중에 전화를 거는 것입니다. 결론부터 말씀드리면, 리눅스 세계에서 “놀고 있는 Free 메모리는 낭비”입니다.

리눅스 커널은 똑똑해서 디스크 I/O 속도를 높이기 위해 남는 메모리를 ‘페이지 캐시(Page Cache)’와 ‘버퍼(Buffer)’로 꽉꽉 채워 씁니다. 자주 쓰는 데이터를 미리 메모리에 올려두는 것이죠. 따라서 free 영역이 적더라도 buff/cache 영역이 넉넉하다면 시스템이 일을 아주 잘하고 있다는 뜻입니다.

우리가 진짜 소름 돋아야 할 때는 vmstat을 쳤을 때 si(Swap In)와 so(Swap Out)가 찍힐 때입니다.

물리 메모리(RAM)가 부족해지면 커널은 디스크의 일부 공간(Swap)을 메모리처럼 빌려 씁니다. 하지만 디스크는 RAM보다 백 배 이상 느립니다. 데이터가 이 스왑 영역을 오가기 시작(Paging)하면, 디스크 I/O가 폭발하면서 사이트 응답 속도가 눈에 띄게 처참해집니다.

만약 이 페이징 현상을 방치하면 커널은 시스템 전체가 죽는 걸 막기 위해 가장 메모리를 많이 먹는 프로세스를 강제로 사형시킵니다. 이게 바로 악명 높은 OOM(Out Of Memory) Killer입니다. 아침에 출근했는데 DB나 WAS 프로세스가 의문사해 있다면, 높은 확률로 이 녀석 소관입니다. 평소에 /var/log/syslog나 dmesg를 통해 OOM 로그를 실시간으로 감시해야 하는 이유가 바로 여기에 있습니다.

3) Disk I/O: 100% 가동률의 함정

요즘처럼 성능 좋은 SSD나 NVMe 스토리지를 쓰는 환경에서는 “얼마나 많은 양을 전송하느냐(Throughput)”보다 “얼마나 빨리 응답하느냐(Await 지연 시간)”가 훨씬 중요합니다. iostat 명령어를 실행했을 때 %util이 100%를 찍더라도 실제 스토리지의 대역폭은 남아있는 경우가 많으니, 늘 await(I/O 요청 처리 평균 시간)이 5ms를 넘지 않는지 체킹하는 습관이 필요합니다.

2. DB 레벨: OS가 조용하다고 안심할 수 없는 이유

데이터베이스 모니터링은 OS보다 차원이 다르게 복잡합니다. OS 대시보드는 CPU 10%, 메모리 여유로움으로 평온해 보이는데, 실제 서비스는 멈춰버리는 기현상이 자주 일어납니다. DB 내부에서 ‘락(Lock)’이 걸렸거나 자원 경합이 벌어졌을 때 이런 일이 생깁니다.

1) 현업에서 가장 자주 마주치는 대기 이벤트(Wait Events) 3가지

DB 성능 저하의 90% 이상은 무언가를 기다리는 ‘대기’에서 시작됩니다. 특히 Oracle 환경을 기준으로 아래 세 가지 이벤트는 외워두시는 게 좋습니다.

• db file sequential read: 주로 인덱스를 타고 들어가는 싱글 블록 I/O 대기입니다. 이 수치가 비정상적으로 높다면 쿼리가 인덱스를 제대로 못 타고 전체를 헤매고 있거나, 스토리지 자체의 성능이 떨어졌다는 적신호입니다.
• log file sync: 트랜잭션을 끝내고 커밋(Commit)을 칠 때 로그를 디스크에 쓰는 과정(LGWR)이 느려서 발생합니다. 개발 단에서 자잘한 커밋을 너무 자주 남발하고 있지는 않은지, 애플리케이션 로직을 먼저 털어봐야 합니다.
• enq: TX – row lock contention: 이건 인프라 사양을 아무리 높여도 해결되지 않습니다. 특정 행(Row)을 수정하려는데 다른 세션이 이미 락을 쥐고 안 놔줘서 생기는 ‘어플리케이션 로직 충돌’입니다. 개발팀과 머리를 맞대고 코드를 수정해야 합니다.

2) 하드 파싱(Hard Parsing)이라는 CPU 도둑

새로운 SQL문이 들어올 때마다 이를 분석하고 실행 계획을 짜는 과정을 ‘파싱’이라고 합니다. 이 과정이 반복되면 CPU 점유율이 미친 듯이 솟구칩니다. Shared Pool과 Library Cache 적중률을 모니터링하면서, 바인드 변수를 적절히 사용해 이미 짜여진 실행 계획을 재사용하고 있는지 체크해야 합니다.

3. OS와 DB의 연결 고리: 점과 점을 선으로 잇는 방법

성능 문제는 결코 하나의 지표만 보고 파악할 수 없습니다. OS와 DB의 지표를 결합해서 보는 ‘입체적인 시각’이 필요합니다.

• I/O 성능 저하 시나리오: DB에서 db file parallel read 대기가 치솟고 있다면, 곧바로 OS 레벨의 iostat을 확인해야 합니다. 만약 OS에서도 디스크 대기 시간(await)이 함께 늘어났다면 물리 디스크나 스토리지 네트워크(SAN)의 선로 혼잡일 가능성이 큽니다. 반대로 OS는 멀쩡한데 DB만 대기가 높다면 DB 내부 파라미터 튜닝의 영역입니다.
• CPU 과부하 시나리오: DB 세션이 폭발하면서 OS CPU가 100%를 찍을 때, 무작정 개발자에게 쿼리 튜닝을 요구하면 싸움만 납니다. 만약 ExaCC 같은 통합 환경이라면 리소스 매니저(Resource Manager) 설정을 열어 인스턴스 간 자원 격리가 제대로 안 되어 다른 컨테이너의 부하가 침범한 것은 아닌지 먼저 팩트 체크를 해야 합니다.

4. 모니터링 솔루션 3대장 실전 활용 전략

이 방대한 지표들을 매번 명령어 쳐가며 볼 수는 없겠죠. 엔터프라이즈 실무에서 가장 선호되는 솔루션 3가지의 특징과 제 경험을 섞어 정리해 드립니다.

1) 데이터독(Datadog): “어디서 막혔는지 끝까지 추적한다”

SaaS 기반 모니터링의 최강자입니다. 특히 마이크로서비스 아키텍처(MSA)나 클라우드 네이티브 환경에서 빛을 발합니다.

• 실전 활용: APM(Application Performance Monitoring) 기능이 예술입니다. 사용자 요청이 느려졌을 때, 그 요청의 추적 궤적을 따라가다가 “아, 이 녀석이 특정 DB 쿼리 단계에서 멈춰 섰구나”라는 걸 직관적으로 보여줍니다. 동일한 타임라인에 OS 인프라 지표를 겹쳐볼 수 있어서 원인 파악이 정말 빠릅니다.

2) 자빅스(Zabbix): “클래식은 영원하다, 든든한 문지기”

폐쇄망 환경이나 엔터프라이즈의 무거운 물리 하드웨어, 네트워크 장비를 감시할 때 이만한 툴이 없습니다. 오픈소스라 비용 효율성도 극상입니다.

• 실전 활용: 에이전트를 설치할 수 없는 스토리지나 백본 스위치 같은 장비들을 SNMP 프로토콜로 묶어 정밀 감시합니다. 실무에서는 특정 프로세스가 다운되었을 때 자빅스 래퍼(Wrapper) 기능을 통해 자동으로 서비스를 재시작(Auto-healing)하는 스크립트를 연동해 유용하게 써먹었습니다.

3) 다이나트레이스(Dynatrace): “장애 원인을 AI가 직접 짚어준다”

대규모 하이브리드 클라우드를 운영하는 대기업에서 가장 탐내는 툴입니다. AI 엔진인 Davis®가 탑재되어 있어 운영자의 피로도를 획기적으로 줄여줍니다.

• 실전 활용: 서버를 켜기만 하면 Smartscape 기능이 인프라 구성 요소 간의 복잡한 의존 관계를 자동으로 지도로 그려줍니다. 장애가 터지면 수백 개의 알람을 보내는 게 아니라, 딱 하나의 근본 원인 알람을 보냅니다. *”현재 가입 서비스가 지연되는 원인은 B 호스트의 메모리 스왑 발생 때문입니다”*라고 명쾌하게 답을 줍니다. 비용은 비싸지만 값어치를 합니다.

📊 모니터링 솔루션 핵심 비교 한눈에 보기

5. 마치며: 지금 당장 내 서버에서 체크해야 할 것

이제 단순히 특정 임계치(예: CPU 80%)를 넘기면 문자나 슬랙으로 알람을 던져주는 방식은 구식이 되었습니다. 머신러닝이 알아서 평소 트래픽 패턴을 학습하고, 평일 이 시간에 나올 수 없는 이상 징후(Anomaly)가 포착될 때만 스마트하게 알려주는 시대입니다.

하지만 아무리 도구가 똑똑해져도 결국 최종 의사결정을 내리고 시스템 구조를 개선하는 것은 엔지니어의 통찰력입니다. “메모리 점유율이 80%네?” 하고 넘기지 마십시오. 그 뒤에 숨겨진 페이징 활동량과 DB 대기 이벤트를 엮어서 서비스의 흐름을 읽을 줄 알아야 진정한 솔루션 아키텍트가 될 수 있습니다.

오늘 글을 닫으면서 한 가지만 제안해 드립니다. 지금 바로 운영 중인 서버에 접속하셔서 Swap In/Out 수치를 확인해 보세요. 그리고 여러분의 모니터링 알람이 단순한 ‘생존 신고’ 수준에 머물러 있지는 않은지 재점검해 보시기 바랍니다. 작은 지표 하나를 꼼꼼히 챙기는 습관이, 새벽에 걸려 오는 장애 전화를 막아줄 유일한 방패입니다.

전문가의 인사이트 : 함께 읽어 보세요.

[RHEL 9.6 기반 톰캣(Tomcat) 설치 및 최적화 운영 전략: 임베디드 vs 독립형]

참조 및 출처 URL:

https://access.redhat.com/solutions/20985