반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
스토리지 관리
예방 점검
APM Solution
애플리케이션 관리
URL 관리
브라우저 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
AI 인공지능
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
잘파세대(Z세대 + 알파 세대)에 대한 모든 것
SMS를 통한 서버관리는 꼭 이렇게 해야만 한다?!
이화정
2024.02.22
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
네트워크 정보 수집 프로토콜의 모든 것 (SNMP, RMON, ICMP, Syslog)
Gartner에서 진행한 연구에 따르면 기업에서 서버의 다운타임이 발생할 경우, 시간당 약 748억 ~ 1,202억의 손실 비용이 발생한다고 합니다.
또한 서버 다운타임등 서버를 제대로 관리하지 못했을 경우에는, 금전적인 손실뿐 아니라 고객이탈이나 브랜드이미지 하락 등의 치명적인 손실도 입게 되죠.
따라서 올바른 서버 관리를 통해 문제를 미리 예방하고, 혹여나 문제가 발생할 경우에는 빠르게 대응할 수 있어야 합니다. 그렇다면
'올바른 서버 관리'란 정확히 무엇을 의미하는 걸까요?
ㅣ올바른 서버 관리를 위한 첫 걸음
ⓒoutsource2india
올바른 서버 관리를 위한 첫걸음은 바로 '통합 서버 관리' 도구의 도입입니다. 가장 많이 활용하는 도구가 바로 SMS(Server Management System)죠.
SMS는 복잡한 IT 인프라를 효과적으로 관리하고, 모니터링할 수 있는 해결책을 제공하여, 서버 사태를 쉽게 파악하고, 필요한 조치를 신속하게 처리할 수 있도록 도와줍니다.
SMS는 기업의 서비스 안정성과 비즈니스 연속성을 보장하는 데 필수적인 도구인 셈이죠. 최근에는 관리하는 서버의 규모와 상관없이 대부분 SMS을 사용하고 있습니다.
하지만 SMS를 도입하고 구축만 한다고 해서, 모든 과제를 해결할 수 있을까요?
ㅣSMS를 제대로 활용하는 방법
SMS를 '제대로' 활용하기 위해서는 단순한 모니터링을 넘어, 문제 발생 시 알림을 받고 이를 통해 신속하게 문제를 해결할 수 있는 적극적인 조치가 필요합니다.
적극적인 조치 중의 대표적인 예이자 서버 관리의 핵심은 바로 '감시 설정'입니다. 그렇다면 구체적으로 '감시 설정'을 통해 어떻게 서버를 관리해야 하는지, 이를 위한 SMS의 조건은 무엇인지 살펴보겠습니다.
최적화된 감시 설정 값을 간편하게 설정할 수 있어야 한다
SMS의 감시항목설정은 사용자가 기본적인 모니터링 환경을 빠르게 구축할 수 있도록 간편하게 설정할 수 있어야 합니다. 통합 서버 관리에 대한 경험이 부족한 사용자더라도, 제품을 쉽게 설정하고 사용할 수 있도록
최적화된 감시 설정 값을 제공
해야 하죠. 예를 들면 CPU 사용률이 몇% 였을 때 심각하고 위험한지를 각 항목별로 제공해야 합니다.
Zenius SMS의 경우 사용자의 OS에 따라 감시 설정 항목(CPU 사용률, MEM 사용률 등)의 심각도와 임계치 조건은 어떻게 해야 하는지 기본적인 디폴트 값을 제공합니다.
더불어서 제니우스만의 최적의 감시 설정 가이드라인을 제공하여, 복잡한 설정 과정을 거치지 않더라도 모니터링할 수 있도록 도와주죠. 물론 기업과 조직의 환경에 맞춰 감시 설정을 조정할 수 있습니다.
필수적인 감시 설정 기능을 갖추고 있어야 한다
또한 SMS의 감시 항목을 설정할 때는
필요한 주요 기능으로 구성
되어야 합니다. 사용자는 복잡한 설정 절차 없이 필요한 감시 항목을 설정해야 하고, 서버 관리에 소요되는 시간을 줄일 수 있어야 하기 때문이죠.
예를 들어 시스템의 중요한 지표(예: CPU 사용량, 메모리 사용량, 디스크 I/O 사용률)를 확인할 수 있는 감시 항목 설정이 있는지, 각 감시 항목에 대해 심각도 수준과 임계치를 설정할 수 있는지, 다양한 방식의 알림 방식 기능을 제공하는지 등을 직관적으로 확인할 수 있어야 합니다.
Zenius SMS의 경우 사용자에게 꼭 필요한 기능(감시 항목, 서버, 심각도, 임계치, 알림 설정, 복구 스크립트 등)만 집중할 수 있도록 구성되어 있습니다.
감시 항목에서는 사용 중인 OS를 설정하고, 원하는 감시 항목을 선택하여, 원하는 서버를 감시 설정 할 수도 있죠. 또한 심각도와 임계치 설정에서는 무해-주의-위험-긴급-치명 각 값에 맞게 임계치 값을 설정할 수 있습니다.
예를 들어 '긴급'이라는 항목에 80%라고 설정했는데 임계치 값이 80%를 넘어설 경우, 사용자에게 즉각적으로 알려줍니다. 또한 지속시간을 1분 발생 횟수를 1이라고 설정할 경우, 1분을 넘길 때 사용자에게 알림을 통보해 주죠.
알림 통보 서비스가 잘 갖춰져 있어야 한다
감시 항목 설정 중
알림 통보는 서버를 관리하는 데 있어 매우 중요한 기능
입니다. 서버에 문제점이 발생할 경우, 사용자에게 즉각적으로 알려줄 수 있는 장치이기 때문이죠. 또한 문제가 더 심각해지기 전에 신속하게 조치를 취할 수 있게 해주며, 시스템의 다운타임을 최소화하는 데 결정적인 역할을 합니다.
이 밖에도 알림 통보 기능에서는 사용자의 업무 환경과 선호도에 따라, 알림의 유형이나 수신자를 유연하게 선택할 수 있어야 합니다.
Zenius SMS를 예를 들어 살펴보면 감시 설정에 임계값을 초과하거나, 예상치 못한 이벤트가 발생했을 때 다양한 형태로 알림 서비스를 제공하고 있습니다. 이메일, 문자 Push App은 물론 외부 연동을 통해 슬랙이나, 카카오톡으로도 편리하게 알람을 받아볼 수 있죠.
이 밖에도 알림의 임계값과 조건, 적용 시간이나 요일, 알림을 받을 사용자도 별도로 지정할 수 있습니다.
자동화 복구스크립트 기능을 제공해야 한다
서버에 문제가 감지되었을 때는 알림 통보 기능뿐만 아니라,
사전에 정의된 스크립트를 자동으로 실행하여 문제를 신속하게 해결
할 수 있어야 합니다. 예를 들어 데이터베이스 서버의 응답 지연이 감지될 때 '캐시를 클리어하고 서비스를 재시작해 줘!'라는 스크립트 실행을 통해 즉각적으로 문제를 해결할 수 있어야 하죠.
이러한 자동화 복구스크립트 기능은 사용자가 알림을 받고 대응하기까지의 시간을 대폭 줄여줄 수 있고, 이에 따라 시스템 다운타임을 최소화할 수 있습니다. 또한 반복적이거나 단순한 문제 해결 과정을 자동화함으로써, 더 중요한 작업에 집중할 수 있겠죠.
위에 언급한 내용을 Zenius SMS를 통해 살펴보면, 장비에 장애가 발생할 경우 즉시 복구스크립트가 구동되어 문제를 자동적으로 해결할 수 있게 합니다.
예를 들어 A 서버에 임계치를 80%로 설정한 후, 복구스크립트를 통해 'C라는 방법으로 조치를 취해줘!'라고 미리 설정할 경우 자동적으로 문제를 해결할 수 있죠. 이러한 자동화 복구스크립트 기능은 수백 혹은 수천 대의 서버와 장비를 효율적으로 관리할 수 있어, 관리 부담을 줄이는 데 매우 효과적입니다.
또한 '정상 복구 시 통보' 옵션을 설정하면, 복구 스크립트가 완료됨에 따라 알림 통보를 사용자에게 재차 알려줍니다. 이 과정을 통해 사용자는 만족도와 제품에 대한 신뢰도를 높일 수 있겠죠.
감시 항목들을 한눈에 관리할 수 있어야 한다
이젠 앞에서 감시 설정하고 등록했던 감시 항목들을 모니터링할 수 있어야 하겠죠? 이때 중요한 점은
필수적인 감시 항목은 보여주되, UI는 단순화
해야 한다는 점입니다. 이는 주요 감시 항목의 상태를 신속하게 파악하고, 문제가 발생했을 때 즉각적으로 대응하기 위해서죠.
또한 감시 항목 상태를 색상 코드(예: 녹색은 정상, 노란색은 경고, 빨간색은 심각)와 아이콘으로 구분하여, 사용자가 감시 항목의 상황을 즉각적으로 인식할 수 있도록 해야 합니다.
Zenius SMS의 경우 주요 감시 항목들의 현황을 통합적으로 모니터링할 수 있습니다. 불필요한 항목들을 줄이고 핵심적인 항목들만 선별하여, 서버의 감시 항목을 신속하게 모니터링할 수 있죠.
감시 현황은 직관적인 UI가 중요한 만큼, 심각도 현황(정상-무해-주의-위험-긴급-치명)을 색상으로 구분하여 문제가 생겼을 때 신속하게 대응할 수 있도록 구성하였습니다. 또한 사용자의 환경에 맞춰 필수적인 감시 항목을 쉽게 선택하여 모니터링할 수 있습니다.
이 밖에도 많은 서버의 감시 항목을 관리하다 보면, 중요한 감시 항목을 추가하지 못한 상황이 발생할 수 있는데요. 최악의 경우에는 막대한 손실 비용 발생 등의 심각한 결과를 초래할 수 있겠죠.
이에 따라 감시 현황은 더더욱 직관적으로 모니터링할 수 있어야 합니다. 주요한 감시 항목을 실수로 설정하지 않더라도, 신속하게 파악하고 등록하여 대처할 수 있기 때문이죠. Zenius SMS는 감시 설정해 둔 항목 수가 예상과 다를 경우(예: 만약 관리하는 서버에 감시 항목이 2건이어야 하는데 → 1건으로 표기된 경우) 미등록 건 감시 항목을 조회하여 등록할 수 있습니다.
주요 감시 항목을 설정하고 동작여부에 '미등록' 항목으로 검색하면, 감시 설정하지 않은 항목을 조회할 수 있죠. 이처럼 Zenius SMS은 자칫 놓칠 수 있는 주요 감시 항목도 신속하게 찾아 등록할 수 있습니다.
。。。。。。。。。。。。
지금까지 살펴본 것처럼 Zenius와 같은 SMS를 통해서
서버를 한눈에 모니터링하고, 감시 설정 기능을 통해 체계적으로 관리하며, 문제 발생 시 다양한 알림과 자동화된 복구스크립트로 문제점을 신속히 해결
해야 합니다. Zenius SMS 대규모 서버자원을 관리하고 있는 한 고객사 관계자의 말씀으로 이 글을 마무리하려고 합니다.
"이 많은 서버의 감시 항목들을 휴일 없이 24시간 동안 지켜볼 수는 없잖아요. 그래서 서버를 통합 관리할 수 있는 Zenius SMS을 도입했죠. 이용하면서 좋았던 점은 감시 현황 페이지를 통해 한눈에 감시 항목을 관리할 수 있어 편리하다는 점이에요.
감시 설정을 걸어둔 항목들이 많아 종종 등록을 못한 경우가 발생해도, 직관적으로 확인하고 감시 항목을 추가할 수 있어요. 특히 복구 스크립트 기능을 애용하는 편인데요. 서버에 장애가 발생했을 때 복구 스크립트를 미리 걸어두면, 장비에 장애가 발생해도 신속하게 문제 해결을 할 수 있어 매우 만족스럽습니다!"
#SMS
#서버
#서버관리
#서버모니터링
#Zenius
#ZeniusSMS
#통합서버관리
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링
eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링
예전에는 네트워크 성능을 모니터링할 때 tcpdump로 패킷을 캡처하거나, netstat으로 연결 상태를 확인하거나, NetFlow/sFlow 기반 분석을 많이 사용했습니다. 하지만 네트워크 환경이 복잡해지고 암호화 트래픽이 늘어나면서, 그리고 컨테이너·MSA 환경으로 서비스가 쪼개지면서 기존 방식의 패킷 기반 모니터링은 점점 한계를 드러냈습니다. 성능 부하는 커지고, 세부 가시성은 부족했습니다. 이 문제를 해결해 준 게 바로 eBPF(extended Berkeley Packet Filter)입니다. eBPF는 커널 내부 함수에 직접 훅(Hook)을 걸어서 데이터를 가져올 수 있기 때문에, 서비스에 큰 영향을 주지 않고도 운영 환경에서 실시간 성능 분석이 가능합니다. 쉽게 말해, 예전에는 netstat으로 “포트가 지금 어떤 상태인지”만 볼 수 있었다면, eBPF를 쓰면 “그 포트의 상태가 어떻게 변하고 있는지”까지 관찰할 수 있습니다. 그래서 최근 클라우드 네이티브 환경이나 초저지연 서비스 운영에서는 eBPF가 차세대 네트워크 모니터링 기술로 주목받고 있습니다. eBPF란? eBPF는 커널 안에서 안전하게 실행되는 작은 프로그램으로, 네트워크·시스템 동작을 실시간으로 추적하는 데 강점을 가집니다. 네트워크 모니터링 관점에서 자주 쓰이는 기능은 다음과 같습니다. • kprobe/kretprobe: 커널 함수 진입·종료 시점 후킹 • tracepoint: 커널 이벤트 발생 시점 후킹 • BPF Map: 커널과 사용자 공간 간 데이터 공유 • BPF Helper 함수: 커널 리소스 접근 API eBPF는 Verifier(검증기)가 프로그램의 안전성을 보장하지 못하면 로드를 거부합니다. 과거에는 Verifier가 루프의 종료를 판별하지 못해 루프 사용이 전혀 허용되지 않았지만, 최근에는 단순 반복문은 사용할 수 있게 되었습니다. 또한 BTF(BPF Type Format)와 CO-RE(Compile Once – Run Everywhere) 기술 덕분에, 커널 버전이 달라져도 동일한 eBPF 프로그램을 별도 빌드 과정 없이 그대로 운용할 수 있습니다. eBPF 사용 방법 제가 공부하면서 가장 흥미로웠던 예제는 BCC 툴셋에 포함된 **tcpstates**입니다. TCP 연결 상태 변화를 추적하는 예제인데, 구조를 간단히 정리하면 다음과 같습니다. • bpf.c: 커널에서 실행되는 함수 중 “어떤 걸 관찰할지”와 “관찰 시 어떤 데이터를 수집할지” 정의 • .h: 커널과 유저 공간이 공유하는 데이터 구조체 정의 • .c: 수집된 데이터를 가공해서 사용자에게 출력 예를 들어, tcpstates.bpf.c에서는 커널 tracepoint inet_sock_set_state를 후킹해서 TCP 상태 변화를 잡아냅니다. 아래 코드를 보면 이해가 쉬우실 겁니다. int handle_set_state(struct trace_event_raw_inet_sock_set_state *ctx) { struct sock *sk = (struct sock *)ctx->skaddr; __u16 family = ctx->family; __u16 sport = ctx->sport; __u16 dport = ctx->dport; __u64 *tsp, delta_us, ts; struct tcpstates_t tcpstates = {}; if (ctx->protocol != IPPROTO_TCP) return 0; ts = bpf_ktime_get_ns(); tcpstates.skaddr = (__u64)sk; tcpstates.ts_us = ts / 1000; tcpstates.pid = bpf_get_current_pid_tgid() >> 32; tcpstates.oldstate = ctx->oldstate; tcpstates.newstate = ctx->newstate; tcpstates.family = family; tcpstates.sport = sport; tcpstates.dport = dport; bpf_get_current_comm(&tcpstates.task, sizeof(tcpstates.task)); if (family == AF_INET) { bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_rcv_saddr); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_daddr); } else { /* family == AF_INET6 */ bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_v6_rcv_saddr.in6_u.u6_addr32); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32); } // 상태가 변경되면 유저 공간에 알리는 부분 bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &tcpstates, sizeof(tcpstates)); return 0; } 핵심 로직은 단순합니다. 커널에서 inet_sock_set_state가 호출되면 handle_set_state 함수가 실행되고, 이때 변경된 TCP 상태를 잡아내 사용자 공간으로 전달합니다. 언뜻 보면 복잡해 보일 수 있지만, 사실 bpf.c의 역할은 데이터를 가공하는 것이 아니라 수집하는 것입니다. 결국 중요한 것은 “내가 원하는 값이 구조체의 어디에 들어 있는지”를 정확히 찾아내는 일입니다. 그 값을 Map에 담아 사용자 공간으로 넘기면 됩니다. netstat으로 보이는 출력은 아래와 같죠. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.0.10:22 192.168.0.55:54321 ESTABLISHED 2048/sshd: user@pts/0 netstat은 사용자가 명령어를 실행한 시점의 상태만 스냅샷 형태로 보여줍니다. 그래서 LISTEN, ESTABLISHED, CLOSE_WAIT처럼 비교적 오래 유지되는 상태만 주로 확인할 수 있습니다. 반면 tcpstates를 활용하면 커널 내부에서 발생하는 모든 TCP 상태 변화를 이벤트 단위로 추적할 수 있습니다. 덕분에 기존 툴로는 관찰하기 어려웠던 3-way handshake와 4-way handshake 과정까지 실제로 확인할 수 있다는 점이 흥미로웠습니다. 조금 더 실무적으로 활용하자면, CLOSE_WAIT이 비정상적으로 쌓이는 경우 커넥션 누수를 빠르게 탐지할 수 있고, TIME_WAIT이나 FIN_WAIT2 패턴을 분석하면 리소스 사용량 문제를 조기에 파악할 수 있습니다. 관측용 예제지만, 확장하면 운영 환경에서도 충분히 유용한 진단 도구가 될 수 있습니다 다음으로 유저 공간의 tcpstates.c는 커널 eBPF 프로그램이 보낸 이벤트를 받아서 보기 좋게 출력하는 역할을 합니다. 흐름은 단순합니다. ①eBPF 오브젝트 열기 (tcpstates_bpf__open()) ②프로그램 커널 로드 (tcpstates_bpf__load()) ③훅 부착 (tcpstates_bpf__attach()) ④필요 시 cgroup 필터 등록 (open(), bpf_map_update_elem()) ⑤주기적으로 Map을 읽거나 이벤트를 받아 상태 출력 현재는 TCP 상태 변경 이벤트가 발생할 때마다 화면에 출력하는 방식으로 동작하지만, 필요하다면 일정 주기마다 netstat을 호출하듯이 현재 상태를 스냅샷 형태로 출력하도록 구현할 수도 있습니다. 마무리하며 이처럼 간단한 코드만으로도 tcpdump나 netstat보다 훨씬 세밀하게 네트워크 흐름을 분석하는 프로그램을 만들 수 있습니다. tcpstates 같은 예제는 단순하지만, eBPF의 장점을 잘 보여줍니다. • 저부하 eBPF는 패킷 전체를 캡처하지 않고, 연결 상태나 세션 정보 같은 핵심 메타데이터만 선택적으로 수집합니다. 이로 인해 CPU와 메모리 사용 부담이 최소화되며, 운영 중인 서비스에 성능 저하를 거의 일으키지 않습니다. 즉, 실서비스 환경에서도 안정적으로 적용 가능한 경량 모니터링 방식입니다. • 높은 가시성 단순히 IP와 포트 수준의 정보만 보여주는 데 그치지 않고, 프로세스명·PID·서비스 단위까지 트래픽을 구분할 수 있습니다. 이를 통해 “어떤 서비스가 얼마만큼의 네트워크 자원을 소비하는지”를 즉시 파악할 수 있으며, 서비스별 자원 사용 현황을 보다 세밀하게 모니터링할 수 있습니다. • 확장성 기본적인 송·수신량 분석을 넘어, RTT(왕복 지연시간), 재전송률, 패킷 드롭률 등 다양한 지표를 손쉽게 확장할 수 있습니다. 필요한 메트릭을 커널 훅(Hook)에 연결해 Map에 저장하기만 하면, 곧바로 시각화와 분석에 활용할 수 있습니다. 이 덕분에 환경 변화나 분석 요구에도 유연하게 대응 가능한 구조를 제공합니다. 브레인즈컴퍼니 역시 이 기술을 Zenius NPM(Network Performance Monitoring)에 적용하면서 기존 방식으로는 확인하기 어려웠던 세밀한 성능 데이터를 확보할 수 있었습니다. 이를 통해 단순한 모니터링을 넘어 서비스 간 통신 병목을 실시간으로 파악하고, 장애 분석 시간을 크게 줄일 수 있는 솔루션을 완성할 수 있었던 점이 큰 성과였습니다. 앞으로도 이러한 경험을 바탕으로 eBPF 활용을 더 넓혀가고자 합니다.
2025.09.18
복잡한 네트워크 트래픽, Zenius NMS·TMS·NPM으로 정확하게 분석하기
복잡한 네트워크 트래픽, Zenius NMS·TMS·NPM으로 정확하게 분석하기
오늘날 기업의 IT 인프라는 클라우드, 가상화, 마이크로서비스(Kubernetes)로 빠르게 전환되고 있습니다. 서비스는 점점 더 세분화되고 연결 구조는 복잡해지면서, 단일 지점에서 발생한 문제라도 전체 서비스 품질에 즉각적인 영향을 미칠 수 있습니다. 그러나 기존의 네트워크 모니터링 방식은 주로 장비 단위에 국한되어 있어, 트래픽 증가나 지연 같은 현상이 발생했을 때 원인을 신속하고 정확하게 파악하기가 쉽지 않습니다. 이러한 환경에서는 단순한 장비 레벨 모니터링을 넘어, 인터페이스 → 트래픽 흐름 → 프로세스 단위까지 네트워크를 다각도로 관찰하는 체계가 필요합니다. Zenius의 NMS, TMS, NPM은 각각의 레벨에서 데이터를 수집·분석함으로써, 네트워크 전반을 단계적으로 추적하고 문제 지점을 빠르게 규명할 수 있도록 돕습니다. 이번 글에서는 세 가지 솔루션을 연계하여 실제 운영 환경에서 어떻게 트래픽 원인을 분석할 수 있는지를 구체적으로 살펴보겠습니다. Zenius NMS·TMS·NPM: 각 솔루션의 특징과 차이점 Zenius NMS, TMS, NPM의 정의와 역할을 먼저 정리해보겠습니다. 각각의 솔루션은 모두 네트워크 트래픽을 모니터링하고 분석하는 기능을 제공하지만, 적용되는 관점과 수집 방식, 그리고 활용 목적에서 분명한 차이가 있습니다. Zenius NMS(Network Management System)는 SNMP를 기반으로 라우터, 스위치 등 네트워크 장비의 물리 인터페이스 관점에서 트래픽을 모니터링합니다. 이를 통해 장비별 포트 사용량, bps/pps, 에러 발생 여부 등을 실시간으로 확인할 수 있으며, 네트워크 전반의 기본적인 상태를 빠르게 파악하는 데 유용합니다. 반면 Zenius TMS(Traffic Management System)는 NetFlow, sFlow, IPFIX와 같은 Flow 데이터를 활용하여, 네트워크를 경유하는 IP·Port 단위 트래픽 흐름을 분석합니다. 스위치를 경유하는 트래픽에 대해 bps/pps와 같은 기본 지표를 확인할 수 있을 뿐 아니라, 애플리케이션별·서비스별·포트별로 트래픽을 분류하고 TopN 분석을 제공하기 때문에, 백본이나 라우터 구간에서 어떤 서비스가 대역폭을 가장 많이 사용하는지 직관적으로 파악할 수 있습니다. 마지막으로 Zenius NPM(Network Performance Monitoring)은 eBPF 기술을 기반으로 서버 및 컨테이너 환경의 커널 레벨 통신을 모니터링합니다. 단순 트래픽량뿐만 아니라 Latency, RTT, Jitter, Retransmit 등 정밀한 성능 지표까지 수집할 수 있어, Kubernetes나 MSA 기반 서비스처럼 복잡한 구조에서 세밀한 원인 분석이 가능합니다. 정리하자면, NMS는 장비·인터페이스 레벨, TMS는 네트워크 경로·서비스 레벨, NPM은 서버·프로세스 레벨에서 각각 네트워크를 해석합니다. 이 세 가지를 유기적으로 결합하면, 물리적 인터페이스 → 네트워크 경로 → 커널 기반 통신까지 다층적으로 추적할 수 있어, 복잡한 네트워크 환경에서 발생하는 트래픽 문제를 효과적으로 해결할 수 있습니다. 이제 각 솔루션이 실제로 어떻게 연계되어 활용되는지, 구체적인 기능 구성 및 분석 절차를 하나씩 살펴보겠습니다. NMS·TMS·NPM 기반 트래픽 분석 기능 구성 및 확인 절차 본격적으로 NMS·TMS·NPM 기반 트래픽 분석 절차를 살펴보겠습니다. 이번 사례는 쿠버네티스(K8s) 기반 WAS 서비스의 트래픽 흐름을 추적하며, 각 구간을 어떤 방식으로 점검할 수 있는지를 단계별로 살펴보겠습니다. [Step 1] 운영환경과 트래픽 흐름 구간 확인 먼저 운영환경의 기본 구성도를 확인하고 분석 대상이 되는 구간을 정리합니다. 본 사례에서는 DB POD → WAS POD → Worker Node → 내부 L3 → 백본 → 방화벽으로 이어지는 흐름을 점검 대상으로 삼습니다. 이러한 흐름을 명확히 정의해두면 이후 어떤 도구와 지표를 중점적으로 확인해야 할지 쉽게 구분할 수 있습니다. [Step 2] 구간별 모니터링 체계 구성 다음으로 각 구간을 어떤 방식으로 수용하고 분석할지 체계를 구성합니다. - 내부 L3, 백본, 방화벽은 SNMP를 통해 NMS에 연계하여 인터페이스 단위 트래픽을 수집합니다. - 백본은 NetFlow, sFlow 등의 Flow 데이터를 TMS에 수용해 애플리케이션 및 서비스 흐름을 분석합니다. - Worker Node는 Agent 기반으로 NPM에 연결해 POD 간 세밀한 통신 현황을 추적합니다. 이렇게 구성하면 서버, 네트워크 장비, 서비스 경로까지 계층별로 입체적인 모니터링이 가능합니다. [Step 3] 구간별 상세 분석 ① POD ↔ WAS POD DB POD와 WAS POD 사이의 통신은 [NPM > 모니터링 > 트래픽 > View, 필터 조건 검색] 경로를 통해 확인합니다. 여기서 IP와 Port를 기준으로 필터링하면, 해당 세션의 트래픽량뿐 아니라 Latency, RTT, Jitter, Retransmit 같은 세밀한 성능 지표를 함께 살펴볼 수 있습니다. 또한, [NPM > 모니터링 > 트래픽현황 > View, 필터 조건 검색] 메뉴를 이용하면 DB POD Port를 기준으로 실제 트래픽 흐름이 어떻게 연결되는지를 시각적으로 파악할 수 있습니다. ② WAS POD ↔ Worker Node ↔ 내부 L3 그다음에는 [NPM > 모니터링 > 트래픽현황] 화면에서 Worker Node 전체 기준으로 트래픽을 점검합니다. 이 과정에서는 상위 트래픽 발생 호스트, 송수신 바이트, Latency, Jitter 추이를 시간대별로 확인할 수 있어, 특정 시점에서 발생한 지연 현상을 이벤트와 연관 지어 분석하기에 적합합니다. ③ Worker Node ↔ 내부 L3 내부 L3 구간은 [NMS > 모니터링 > 장비 > 인터페이스] 메뉴에서 확인합니다. bps, pps, 에러 발생 여부 같은 항목을 중심으로 살펴보면 링크의 안정성과 과부하 여부를 빠르게 점검할 수 있습니다. 또한, [NMS > 모니터링 > 성능 > 인터페이스] 메뉴를 활용하면 시간대별 bps/pps 그래프를 통해 트래픽 패턴 변화를 확인할 수 있으며, 이는 NPM에서 관측한 Latency나 Jitter 지표와 교차 검증하는 데 도움이 됩니다. ④ 내부 L3 ↔ 백본 ↔ 방화벽 마지막으로 백본 구간은 TMS를 통해 흐름을 분석합니다. [TMS > TopN > 어플리케이션] 메뉴에서 HTTPS, PostgreSQL 등 주요 애플리케이션별 트래픽 분포를 확인할 수 있으며, [TMS > TopN > 트래픽, Port] 화면에서는 IP와 Port를 기준으로 어떤 서비스가 대역폭을 점유하고 있는지 빠르게 파악할 수 있습니다. [ TMS > TopN > 트래픽, Port ] IP, Port 등 다양한 기준의 백본 경유 트래픽 분석 결국, NPM은 POD·서버 간 세밀한 지연과 통신 성능을, NMS는 네트워크 장비 인터페이스 단위 안정성을, TMS는 서비스 및 애플리케이션 흐름을 각각 보여줍니다. 이렇게 다층적인 분석을 통해, 단일 구간이 아닌 전체 서비스 경로를 종합적으로 추적할 수 있으며, 이는 재현이 어려운 네트워크 장애 원인 파악에 큰 도움이 됩니다. 활용 예시 “특정 Worker Node 트래픽 급증” 원인 추적하기 쿠버네티스(K8s) 환경의 서비스는 일반적으로 다수의 POD가 상호 연결되어 하나의 서비스를 제공합니다. 이러한 구조에서는 특정 Worker Node의 트래픽이 급격히 증가했을 때, 기존의 일반 모니터링 도구(SMS) 만으로는 증가 원인을 정확히 분석하기 어렵습니다. SMS는 대개 NIC 단위 트래픽 수준까지만 보여주기 때문입니다. 따라서 Zenius NPM을 활용해 OS(커널) 관점에서 IP·Port 기준의 세밀 분석을 수행해야만, 어떤 POD·세션·포트가 원인인지 구체적으로 밝혀낼 수 있습니다. 1) NPM으로 포트/세션 단서 포착 먼저 [NPM > 모니터링 > 트래픽 > View, 필터 조건 검색]에서 문제의 Worker Node를 기준으로 플로우 목록을 정렬합니다. 다수의 POD에서 동일 포트(예: 8081) 로 통신하는 패턴이 확인되면, 수집 트래픽 증가 가능성이 높습니다. → 8081은 Zenius APM 데이터 수집 포트이므로, APM 수집량 증가에 따른 네트워크 사용량 상승을 1차 가설로 설정합니다. 2) NPM 트래픽 맵으로 대상·방향 확정 다음으로 [NPM > 모니터링 > 트래픽현황 > View, 필터 조건 검색]에서 RemotePort = 8081로 필터링합니다. 트래픽 맵을 통해 어떤 POD들이 8081 수집 지점으로 트래픽을 보내는지와 연결 방향을 직관적으로 확인할 수 있습니다. 본 사례에서는 4개의 POD에서 동일 포트로 집중되는 흐름이 나타났고, 추가 8081 통신 대상은 확인되지 않았습니다. 3) K8s에서 트래픽 발생 POD 상태 교차 검증 이제 [Zenius K8s > 모니터링 > 파드]에서 트래픽 발생 POD(예: 192.168.0.216) 를 선택해 상태와 자원 사용률(CPU/메모리), 네트워크(bps) 를 확인합니다. 본 사례에서는 상태가 정상이고 Limit 대비 사용률도 안정적이어서, 트래픽 증가는 장애가 아닌 정상적인 수집 과정에서 발생한 현상으로 판단할 수 있습니다. 4) APM 지표로 맥락 검증 마지막으로 [Zenius APM > 모니터링] 대시보드에서 요청 건수, 응답 시간, 동시 사용자 등의 애플리케이션 지표를 확인합니다. NPM에서 포착된 8081 증가 시점과 APM 지표가 동조하면, 네트워크 증가는 APM 수집 트래픽 증가(정상 동작)로 판단할 수 있습니다. 반대로 APM 지표가 평온한데 8081만 치솟는다면, 이는 수집 설정이나 라우팅 구성의 이상을 의심해야 합니다. 이 경우, 동일 조건을 재현해 문제를 다시 발생시켜 보고, 원인이 확인되면 수집 주기·라우팅·리소스 할당 등을 조정(튜닝)하여 최적화할 수 있습니다. NPM–NMS–TMS–K8s–APM을 유기적으로 연결해, 특정 Worker Node 트래픽 급증 이슈를 포트/세션 단서 포착 → 흐름 확인 → POD 상태 교차 검증 → 애플리케이션 지표로 맥락 확인의 순서로 좁혀가는 방법을 살펴봤습니다. 핵심은 커널 레벨의 정밀 지표(NPM)로 원인을 가설화하고, 맵/인터페이스/서비스 흐름을 통해 이를 빠르게 검증하는 것입니다. 이 흐름을 표준 운영 절차로 적용하면, 재현이 어려운 상황에서도 원인 구간의 신속한 특정과 실질적인 조치(설정·라우팅·리소스 튜닝)도 가능합니다. 이번 글에서는 Zenius NMS·TMS·NPM을 통해 네트워크 트래픽을 다층적으로 분석하는 방법을 살펴보았습니다. 각 솔루션이 담당하는 관점과 역할은 다르지만, 함께 연계해 활용하면 장애 원인을 더 빠르고 정확하게 파악할 수 있습니다. 복잡해지는 인프라 환경에서 이런 분석 체계를 마련해 두는 것이 안정적인 서비스 운영의 핵심입니다.
2025.09.23
다음 슬라이드 보기