최신이야기 | 브레인즈컴퍼니

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

메인 페이지로 이동
블로그
최신이야기

블로그

최신이야기

기술이야기 하이브리드 클라우드와 쿠버네티스 모니터링 시 반드시 고려해야 할 4가지 기술이야기 하이브리드 클라우드와 쿠버네티스 모니터링 시 반드시 고려해야 할 4가지 많은 기업과 기관은 퍼블릭 클라우드와 프라이빗 클라우드(또는 온프레미스)를 병행하는 하이브리드 클라우드 환경을 도입하고 있으며, 그 위에서 쿠버네티스(Kubernetes, K8s)를 활용해 수십 개의 마이크로서비스를 독립적으로 배포하고 확장하는 방식을 채택하고 있습니다. 이러한 구조는 높은 유연성과 확장성을 제공하지만, 동시에 운영 복잡성을 크게 증가시키는 특징이 있습니다. 이에 따라 다양한 모니터링 도구와 대시보드가 활용되고 있지만, 실제로 장애가 발생하면 원인을 파악하기까지 여전히 많은 시간이 소요됩니다. 데이터 자체는 충분히 수집되고 있으나, 사용자 요청에서 애플리케이션과 컨테이너, 네트워크, 클라우드 리소스에 이르는 흐름이 하나의 시간축으로 유기적으로 연결되지 않기 때문입니다. 결국 각 지표가 분절된 조각으로만 보이면서, 문제의 전반적인 맥락을 명확하게 파악하기 어렵게 됩니다. 따라서 이제 모니터링의 목적은 단순한 데이터 수집을 넘어야 합니다. 수집된 데이터를 유기적으로 연결된 관점에서 해석하고, 복잡한 분산 환경의 특성을 반영하며, 탐지 이후에는 신속하게 조치와 대응으로 이어질 수 있는 체계를 마련하는 것이 중요합니다. 그렇다면 하이브리드 클라우드와 쿠버네티스 환경에서 모니터링을 수행할 때, 구체적으로 어떤 부분을 반드시 고려해야 할까요? 지금부터 그 핵심 요소들을 차례로 살펴보겠습니다. 하이브리드 클라우드와 쿠버네티스 모니터링, 반드시 고려해야 할 4가지 1) End-to-End Observability로 장애 원인을 빠르게 찾을 수 있어야 한다 모니터링은 사용자 경험에서 시작해 애플리케이션, 컨테이너와 노드, 네트워크, 그리고 클라우드 리소스까지 하나의 흐름으로 이어져야 합니다. 예를 들어 사용자가 웹 애플리케이션에서 지연을 겪는다면, 해당 요청의 트레이스를 열어 어느 구간에서 지연이 발생했는지 확인하고, 같은 시각의 CPU·메모리·입출력(IO) 사용량과 데이터베이스나 메시지 큐 같은 클라우드 매니지드 서비스의 상태를 함께 살펴야 합니다. 이렇게 해야 단순히 “느리다”라는 현상에서 멈추는 것이 아니라, “어떤 서비스의 어떤 호출이 병목이며, 어떤 인프라 자원이 영향을 주었는가”라는 구체적 결론으로 이어질 수 있습니다. 이를 위해서는 데이터가 일관된 방식으로 연결되어야 합니다. 트레이스 식별자(Trace ID)와 서비스·환경 태그 같은 공통 메타데이터가 전체 수집 계층에 적용되어야 하며, 로그·메트릭·트레이스는 이 기준을 통해 즉시 상관 분석이 가능해야 합니다. 화면 구성도 마찬가지입니다. 서비스 개요에서 시작해 트랜잭션 세부, 컨테이너와 노드 지표, 네트워크와 클라우드 리소스로 자연스럽게 이어지는 드릴다운 구조가 마련되어야 운영자가 불필요하게 여러 화면을 오가며 시간을 낭비하지 않습니다. 또한 사용자 경험 지표를 백엔드 데이터와 연결하는 과정도 필요합니다. 실제 사용자 모니터링(RUM, Real User Monitoring) 기능 등을 통해 웹 성능의 핵심 지표를 함께 확인해야 합니다. LCP(Largest Contentful Paint·핵심 내용이 화면에 표시되기까지의 시간), INP(Interaction to Next Paint·사용자 입력에 대한 반응성), CLS(Cumulative Layout Shift·레이아웃 안정성)와 같은 지표를 백엔드 트레이스와 매칭하면, 지연의 원인이 서버 처리인지, 네트워크 왕복 시간인지, 외부 리소스 때문인지 명확히 설명할 수 있습니다. 2) 쿠버네티스 주요 이벤트를 실시간 성능 데이터와 함께 볼 수 있어야 한다 쿠버네티스는 끊임없이 변화하는 동적 분산 시스템입니다. Pod는 생성과 종료를 반복하고, 오토스케일러는 순간적인 부하에 따라 리플리카 수를 조정하며, 롤링 업데이트와 롤백은 하루에도 여러 번 발생합니다. 이런 특성 때문에 단순히 CPU와 메모리 사용률 같은 정적 지표만 확인해서는 문제를 제대로 이해하기 어렵습니다. 쿠버네티스 환경에서는 반드시 이벤트와 성능 지표를 같은 시간축에서 함께 해석해야 합니다. 예를 들어 특정 시점에 오류율이 급증했다면, 원인은 단순한 리소스 부족일 수도 있습니다. 그러나 API Server 지연이나 etcd 병목, 혹은 롤링 업데이트 과정에서 트래픽 전환이 매끄럽지 않아 발생한 문제일 가능성도 있습니다. 만약 Pod 재시작이나 CrashLoopBackOff 이벤트가 성능 저하와 같은 시점에 발생했다면, 이는 추측이 아니라 근거 있는 원인 분석으로 이어질 수 있습니다. 또한 서비스 간 통신에서 병목을 찾으려면 서비스 메쉬 지표나 eBPF 기반 네트워크 관측이 효과적입니다. 이들은 동서 트래픽의 RTT, 오류율, 지연 분포를 보여주어 호출 경로상의 문제 지점을 명확히 드러냅니다. 여기에 HPA 동작이나 롤백 시점을 성능 지표와 함께 기록하면, 배포가 실제 성능 저하의 원인이었는지도 빠르게 확인할 수 있습니다. 결국 쿠버네티스 모니터링은 지표와 이벤트를 분리해 보는 것이 아니라, 하나의 시간선에서 연결해 해석해야 합니다. 그래야 단순히 “문제가 있다”라는 수준에 머무르지 않고, “이 시점, 이 이벤트, 이 서비스가 원인이다”라는 실행 가능한 결론으로 이어질 수 있습니다. 3) 클라우드 계정·리전·비용·보안을 하나의 기준으로 관리할 수 있어야 한다 하이브리드 클라우드는 유연성을 제공하지만, 동시에 운영 복잡성과 관리 부담을 크게 높입니다. 사업자마다 지표 체계와 콘솔이 다르고, 계정과 리전이 분산되면 운영자는 조각난 정보를 이어 붙이는 데 많은 시간을 소모하게 됩니다. 이러한 문제를 줄이려면 반드시 메타데이터 규칙을 정의하고 이를 일관되게 적용해야 합니다. 클라우드 계정과 리전 인벤토리는 자동으로 동기화되어야 하며, 모든 리소스에는 팀·서비스·환경 정보가 태그로 부여되어야 합니다. 비용, 성능, 가용성 지표는 이 태그를 기준으로 정렬·비교되어야 하며, 이를 통해 특정 서비스나 팀 단위의 문제를 빠르게 좁혀갈 수 있습니다. 비용 관리 또한 단순히 총액 확인을 넘어 예산·예측·이상 비용 감지까지 하나의 화면에서 제공되어야 실제 운영과 의사결정에 도움이 됩니다. 보안 역시 운영과 별도로 다루지 않고 같은 시각에서 관리해야 합니다. 퍼블릭 버킷 노출, 과도한 보안그룹 개방, 장기간 미사용 액세스 키와 같은 항목은 운영 대시보드에 함께 표시되어야 하며, 이를 통해 비용·성능·보안을 종합적으로 고려한 균형 잡힌 결정을 내릴 수 있습니다. 또한 재해복구 관점에서는 리전 간 지표 정합성과 복구 목표치(RTO, Recovery Time Objective·복구 시간 목표 / RPO, Recovery Point Objective·복구 시점 목표) 달성 여부를 주기적으로 점검해야 합니다. 이러한 데이터가 체계적으로 관리될 때 실제 장애 상황에서도 신속하게 대응할 수 있습니다. 결국 하이브리드 클라우드 모니터링은 각 사업자의 시스템을 따로따로 보는 것이 아니라, 하나의 기준과 규칙으로 통합 관리해야만 진정한 효과를 발휘합니다. 4) 운영 자동화와 알림 체계가 효과적으로 갖춰져 있어야 한다 모니터링의 목적은 데이터를 보여주는 것이 아니라 문제를 신속히 해결하는 데 있습니다. 따라서 알림 체계는 단순히 많은 경고를 쏟아내는 것이 아니라, 운영자가 즉시 판단하고 대응할 수 있을 만큼 충분한 정보를 담아야 합니다. 정적 임계치만으로는 환경 변화를 따라가기 어렵습니다. 시스템은 정상 상태를 스스로 학습해 기준선을 조정할 수 있어야 하며, 유사한 성격의 이벤트는 상관관계 분석을 통해 하나의 사건으로 묶여야 합니다. 이렇게 해야 알림 소음을 줄이고, 운영자가 진짜 중요한 신호에 집중할 수 있습니다. 알림은 단순한 메시지가 아니라 증거를 함께 제공해야 합니다. 예를 들어 “CPU 사용률 초과”라는 경고만으로는 부족합니다. 같은 시점의 로그, 트레이스 링크, 최근 배포 이력, 리소스 스냅샷 등이 함께 제시되어야 운영자가 알림에서 곧바로 확인과 조치로 이어질 수 있습니다. 전달 방식 또한 중요합니다. 메신저 알림이나 모바일 푸시처럼 실제 대응이 이루어지는 채널을 사용해야 하며, 에스컬레이션은 시간과 역할에 따라 명확히 정의되어야 합니다. 교대 근무 체계와 연동된 프로세스까지 갖춰져야 운영 공백을 최소화할 수 있습니다. 궁극적으로는 탐지 → 증거 수집 → 조치 → 복구 확인까지 이어지는 과정이 표준 절차로 자리 잡아야 합니다. 사건 종료 후에는 포스트모템이 자동 기록되어 재발 방지로 이어져야 하며, 이러한 체계가 반복될수록 평균 대응 시간(MTTA)과 평균 복구 시간(MTTR)은 꾸준히 단축됩니다. 운영 자동화와 알림 체계가 제대로 작동할 때, 모니터링은 단순한 관찰을 넘어 실질적인 운영 성과로 연결됩니다. 클라우드와 쿠버네티스 환경은 앞으로도 더 확장되고 다양해질 것입니다. 서비스는 더 많은 리전에 걸쳐 배포되고, 애플리케이션은 더 많은 마이크로서비스로 쪼개지며, 운영자는 더 많은 데이터와 알림에 둘러싸이게 될 것입니다. 이 상황에서 단편적인 모니터링만으로는 대응 속도와 품질을 보장할 수 없습니다. 지금 필요한 것은 데이터를 연결된 시각으로 읽어내고, 이벤트와 지표를 하나의 시간선에서 해석하며, 클라우드 리소스를 일관된 규칙으로 관리하고, 알림을 실제 조치로 이어주는 운영 체계입니다. 이 네 가지는 기술적으로는 별개의 영역처럼 보이지만, 실제 운영에서는 긴밀히 맞물려 작동해야만 효과가 있습니다. 결국 모니터링의 목표는 단순히 상태를 보여주는 것이 아니라, 문제 해결과 서비스 안정성을 보장하는 데 있습니다. 하이브리드 클라우드와 쿠버네티스 환경에서 이 네 가지 관점을 충실히 반영한다면, 복잡성을 줄이고, 장애 대응 시간을 단축하며, 미래의 확장성까지 확보할 수 있습니다. 2025.09.25
기술이야기 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
회사이야기 브레인즈컴퍼니, [K-ICT Week in BUSAN 2025] 참가 후기 회사이야기 브레인즈컴퍼니, [K-ICT Week in BUSAN 2025] 참가 후기 지난 7월 15일부터 17일까지, 부산 벡스코(BEXCO)에서 개최된 ‘2025 K-ICT WEEK in BUSAN’에 브레인즈컴퍼니가 참가했습니다. 브레인즈컴퍼니는 이번 전시회에서 단순한 기능 소개를 넘어서, 실제 고객 환경에서 Zenius가 어떤 방식으로 운영 효율성과 인프라 안정성을 높일 수 있는지를 구체적으로 전달하기위해 노력했습니다. 많은 참관객의 높은 관심과 긍정적인 반응을 얻을 수 있었던 이번 전시회를 함께 자세히 돌아보겠습니다. │[K-ICT WEEK in BUSAN 2025]는?! ‘K-ICT WEEK in BUSAN’은 과학기술정보통신부, 부산광역시, 부산시교육청이 공동 주최하고, 정보통신산업진흥원(NIPA), 부산정보산업진흥원, 벡스코가 주관하는 부산/경남권 최대 IT 전시회입니다. 올해는 ‘인공지능 기술과 혁신의 중심지 부산(AI Core BUSAN)’이라는 주제로 열렸으며, AI KOREA, CLOUD EXPO KOREA, IT EXPO BUSAN 등 세 개의 행사가 함께 개최되었습니다. 170개 이상의 국내외 기관과 기업이 참여했고, 행사 기간 동안 4만 명이 넘는 관람객이 방문하며 역대 최대 규모를 기록했습니다. 전시뿐 아니라 클라우드 콘퍼런스, AI 체험관, 양자정보기술 세미나, 투자 상담회 등 다양한 프로그램이 함께 진행되기도 했습니다. 브레인즈컴퍼니는 이번 행사에서 부스 운영을 통해 지능형 IT 인프라 통합관리 소프트웨어인 제니우스(Zenius)의 주요 기능과 활용 사례를 선보였습니다. │[K-ICT WEEK in BUSAN 2025]에서 브레인즈컴퍼니는?! 브레인즈컴퍼니는 이번 전시회에서 Zenius 제품군을 중심으로 부스를 운영했습니다. 구체적으로는 클라우드와 온프레미스 환경의 모든 IT 인프라를 통합적으로 모니터링하는 Zenius EMS, 보안 로그를 기반으로 이상 행위를 탐지하고, 위협에 신속하게 대응하는 Zenius SIEM, IT 서비스 요청과 장애, 변경 등의 이슈를 체계적으로 관리하고 추적하는 Zenius ITSM이 전시되었습니다. 특히 이번 행사에서는 머신러닝 기반의 이상 탐지 기능을 제공하고 최근에 GS 1등급 인증도 획득한 Zenius AI도 함께 전시되었습니다. 브레인즈컴퍼니는 이를 통해 다양한 로그와 메트릭 데이터를 분석해 장애를 사전에 예측하고, 운영 리스크를 효과적으로 줄이는 방안을 제시했습니다. 이에 따라 참관객들은 브레인즈컴퍼니 부스에서 클라우드와 온프레미스를 아우르는 통합 관측(Observability) 체계와, AI 기반 자동화 운영(AIOps) 기술이 실제 환경에서 어떻게 적용되는지를 구체적으로 확인할 수 있었습니다. 단순한 성능 모니터링을 넘어, 이상 징후의 사전 탐지와 자동 대응, 실시간 분석 기반의 인프라 최적화 과정까지 전반적인 IT 운영 관리 흐름을 한눈에 살펴볼 수 있어 많은 관심이 이어졌습니다. │브레인즈컴퍼니 부스, 많은 관심이 이어지다. 브레인즈컴퍼니 부스에는 전시 첫날부터 마지막 날까지 꾸준히 참관객들의 발걸음이 이어졌습니다. 참관객들은 특히 대규모 인프라 환경에서도 안정적으로 작동하는 모니터링 기능과 실시간 이상 탐지 및 대응이 가능한 AI 기반 기능에 큰 관심을 보였습니다. 한 참관객은 “현재 타사의 모니터링 솔루션을 사용하고 있지만, 세분화된 데이터 분석이 부족해서 아쉬움을 느껴 왔다”며, “보다 정밀하고 직관적인 통합 모니터링 솔루션을 찾던 중 Zenius의 직관적인 대시보드 구성과 AI 기반 이상 탐지 기능이 특히 인상 깊었고, 도입을 긍정적으로 검토할 계획”이라고 밝혔습니다. 다른 참관객은 “쿠버네티스 기반 서비스 운영 중, 리소스 낭비나 서비스 불안정성을 사전에 파악할 방법이 필요했는데, Zenius는 세분화된 지표 수집과 이상 탐지, 직관적인 대시보드까지 모두 제공해 매우 인상 깊었다”고 말했습니다. 브레인즈컴퍼니 부스에 방문한 참관객들은 Zenius의 통합 모니터링 기능과 확장성 있는 구조에 깊은 관심을 보였습니다. 특히 하이브리드 클라우드 도입이 활발해지는 가운데, 온프레미스와 클라우드 자원을 효과적으로 통합관리하고 장애나 이상 징후에 선제적으로 대응할 수 있는 장점이 많은 참관객들로부터 높은 평가를 받았습니다. 이번 부스에 방문한 다수의 기업/기관 관계자들과는 도입을 전제로 한 추가 미팅도 진행 할 예정입니다. 이번 K-ICT WEEK in BUSAN 2025는 브레인즈컴퍼니가 단순한 제품 기능을 넘어, 실제 현장의 운영 환경과 과제를 직접 듣고, 그에 대한 기술적 해법을 구체적으로 제시할 수 있었던 뜻깊은 자리였습니다. 브레인즈컴퍼니는 앞으로도 고객의 목소리에 귀 기울이며, 더 나은 IT 운영 환경을 위한 모니터링 솔루션을 만들 수 있도록 노력하겠습니다. 2025.07.22
기술이야기 하이브리드 클라우드 모니터링에 Zenius EMS가 필요한 4가지 이유 기술이야기 하이브리드 클라우드 모니터링에 Zenius EMS가 필요한 4가지 이유 오늘날 기업의 IT 인프라는 퍼블릭 클라우드와 프라이빗 클라우드(또는 온프레미스 환경)를 함께 사용하는 하이브리드 클라우드 구조로 빠르게 전환되고 있습니다. 이처럼 두 환경의 장점을 결합한 하이브리드 클라우드는 유연한 확장성과 높은 보안성을 동시에 확보할 수 있어, 다양한 산업 분야에서 널리 채택되고 있습니다. 하지만 하이브리드 클라우드 환경은 운영 가시성을 확보하고, 시스템 전반을 효율적으로 관리하는 부분 등에서 어려움이 있습니다. 특히 서로 다른 환경을 하나의 관점에서 통합적으로 모니터링하려면, 기존의 단일형 관제 시스템만으로는 분명한 한계가 존재합니다. Zenius EMS는 이러한 복잡성을 해결하기 위해 설계된 지능형 IT 인프라 통합 모니터링 솔루션입니다. 다양한 인프라를 하나의 프레임워크 안에서 통합 관리할 수 있도록 돕고, 자동화된 장애 대응 기능과 대규모 인프라 수용 능력을 함께 갖추고 있어, 복잡한 클라우드 운영 환경에서도 안정성과 효율성을 동시에 실현할 수 있습니다. 그렇다면 구체적으로 Zenius EMS가 하이브리드 클라우드 모니터링에 왜 필요한지 네 가지로 나눠서 살펴보겠습니다. Zenius EMS가 하이브리드 클라우드 모니터링에 필요한 네 가지 이유 1) 다양한 인프라를 하나의 화면에서 통합 관리 Zenius EMS는 각 인프라 유형에 최적화된 전용 모듈을 통해 인프라 상태와 성능을 체계적으로 수집하고 분석합니다. 예를 들어, CMS 모듈(Zenius CMS)은 클라우드 서비스별 리소스 상태, 사용 지표, 비용 초과 알림 등을 통합해 관리하며, K8s 모듈(Zenius K8s)은 클러스터 전체 구성요소의 상태, 리소스 사용률, 이벤트 발생 내역을 실시간으로 관제합니다. 또한 자동 생성되는 Topology Map을 통해 워크로드 간 연관 관계와 서비스 흐름을 시각적으로 표현할 수 있어, 클러스터 내부에서 발생하는 병목이나 장애 영향을 직관적으로 파악할 수 있습니다. APM 모듈(Zenius APM)은 웹 애플리케이션의 트랜잭션 처리량, 응답 지연, 사용자 행동 흐름 등을 실시간 분석하며, 동시에 WAS, DB, 외부 연계 시스템 등 전체 요청 경로 상의 성능 병목을 식별할 수 있습니다. NPM 모듈(Zenius NPM)은 커널 수준에서 수집한 네트워크 트래픽 데이터를 기반으로, 장비 단위가 아닌 프로세스 단위의 통신 현황을 분석하여 어떤 서비스가 어느 포트, 어느 서버와 언제 얼마나 통신했는지를 정확하게 추적할 수 있도록 돕습니다. 특히 Zenius EMS의 큰 강점은, 이러한 각기 다른 모듈들이 단순히 병렬적으로 구성되는 것이 아니라, 하나의 통합 관제 프레임워크 내에서 상호 연동되어 작동한다는 점입니다. 예를 들어, K8s 모듈과 APM 모듈을 연계하면, 클러스터 내 서비스의 성능 저하가 애플리케이션 차원에서 어떤 영향을 주는지를 교차 분석할 수 있으며, 그 결과를 기반으로 장애 발생 원인을 보다 정밀하게 추적할 수 있습니다. Zenius EMS는 단일 뷰 기반의 통합 화면 구성과 모듈 간 연계 분석 기능을 통해, 복잡한 하이브리드 인프라 환경에서도 인프라 상태를 실시간으로 가시화하고, 장애의 흐름과 구조를 맥락적으로 이해할 수 있도록 지원합니다. 2) 운영 자동화와 예측 분석으로 장애 대응 시간 최소화 하이브리드 클라우드 환경에서는 장애가 언제, 어디서, 어떤 형태로 발생할지 예측하기 어렵기 때문에, 수동적인 장애 대응 방식으로는 복잡한 인프라 환경을 안정적으로 운영하기 어렵습니다. Zenius EMS는 운영자의 개입을 최소화하면서도 정확하고 빠르게 대응할 수 있는 자동화된 장애 관리 체계를 내장하고 있습니다. 먼저, Agent가 각 인프라 노드나 애플리케이션에 설치되어 이벤트 발생을 실시간으로 감지하며, 감시정책에 따라 자동으로 알림을 전송하고, 장애의 심각도에 따라 최대 3단계까지 에스컬레이션 (escalation)되는 체계를 제공합니다. 복구가 완료되면, 시스템은 정상 상태로의 전환 여부를 다시 감지하고, 담당자에게 자동 통보함으로써 알림 누락이나 대응 지연을 최소화합니다. 또한 Zenius EMS는 장애 발생 당시의 인프라 상태를 Snapshot 형태로 저장하여 이후 원인 분석에 활용할 수 있습니다. 단순한 수치 기록을 넘어서 해당 시점의 구성요소 상태, 트래픽 흐름, 애플리케이션 반응 시간 등 실시간 운영 데이터 전체를 캡처할 수 있어 문제 발생의 맥락을 복원하는 데 용이합니다. 저장된 장애 이력은 Knowledge DB에 축적되며, 유사 장애 발생 시 자동으로 과거의 대응 이력을 불러와 선제적인 조치를 제안합니다. 이와 함께 Zenius EMS는 AI 알고리즘 기반의 성능 예측 기능도 지원합니다. 장기간 축적된 메트릭 데이터를 분석해 자원 사용률 급증, 트래픽 편중, 프로세스 과부하 같은 이상 징후를 사전에 감지하고, 장애로 이어지기 전 조치를 취할 수 있도록 도와줍니다. 이로써 Zenius EMS는 장애 탐지, 원인 분석, 대응, 재발 방지, 선제 대응까지 운영 전 과정을 자동화하고 지능화된 방식으로 처리할 수 있는 환경을 제공합니다. 3) 대규모 환경에서도 안정적으로 작동하는 구조 Zenius EMS는 복잡한 구성과 대규모 트래픽이 동시에 존재하는 엔터프라이즈급 인프라 환경에서도 안정성과 성능을 유지할 수 있는 구조적 기반을 갖추고 있습니다. 단일 Manager Set만으로도 최대 1,500대 이상의 서버를 동시에 관제할 수 있으며, SIEM 모듈 기준 초당 160만 건의 데이터 입력을 처리할 수 있는 고성능 분석 엔진을 보유하고 있습니다. 이는 TTA 인증을 통해 공식적으로 성능을 입증받은 결과입니다. Zenius EMS는 전체 시스템이 초경량 매니저 및 에이전트 구조로 설계되어 있어 낮은 리소스 점유율로도 높은 처리 효율을 유지할 수 있습니다. 모듈 간 데이터 전달 및 상호작용도 최소한의 네트워크 부하로 작동되도록 설계되어, 대용량 환경에서도 병목 없이 관제 품질을 유지합니다. 특히 확장된 환경에서는 모듈 추가만으로 수용량을 유연하게 늘릴 수 있어, 인프라 확장에 따른 별도의 구조 변경 없이 유연한 확장 대응이 가능해, 인프라 변화에 빠르게 적응할 수 있습니다. 또한 Zenius EMS는 국내외 주요 클라우드 서비스 제공업체(CSP)의 마켓플레이스 8곳에 등록되어 있어, 클라우드 환경에서도 간편하고 신속한 도입이 가능합니다. 이미 다양한 산업의 대규모 고객 환경에 적용되어 성능과 안정성을 입증했으며, 이를 통해 높은 기술적 신뢰성을 확보하고 있습니다. 4) 검증된 안정성과 지속적인 기술 지원 Zenius EMS는 기능적 완성도뿐 아니라, 현장 중심의 운영 안정성과 체계적인 기술 지원 역량을 함께 갖춘 IT 인프라 관제 솔루션입니다. 현재까지 공공, 금융, 의료, 제조 등 다양한 산업 분야에서 1,000여 개 이상의 고객사에 도입되어 실제 운영되고 있으며, 10년 이상 장기 사용 고객 비율이 34%를 넘어설 만큼 높은 충성도와 신뢰를 확보하고 있습니다. 구축 이후에도 Zenius EMS는 단순한 모니터링 시스템을 넘어, 지속 가능한 운영 경험을 제공합니다. 고객 전담 엔지니어가 상시 유지보수와 기술 지원을 전담하며, 운영 중 발생하는 이슈에 신속하고 일관된 대응이 가능하도록 ServiceDesk 체계가 마련되어 있습니다. 또한, 15년 이상의 현장 경험을 가진 전문 엔지니어 인력이 직접 대응하며, QA 전담 테스트팀은 신규 기능이나 환경 변경 시 사전 안정성 검증을 통해 서비스 품질을 철저히 관리합니다. 더불어, 정기적인 제품 고도화와 보안 패치가 지속적으로 이루어지고 있으며, 고객 환경의 변화에 따른 모듈 기능 확장이나 커스터마이징 요청에도 유연하게 대응하고 있습니다. 이러한 운영 지속성과 기술 지원 체계는 Zenius EMS의 큰 강점으로 꼽힙니다. 하이브리드 클라우드 환경은 단순히 퍼블릭과 프라이빗 인프라를 병행해 사용하는 차원을 넘어, 가상화, 컨테이너, 다양한 클라우드 리소스들이 유기적으로 얽혀 있는 복잡한 구조로 변화하고 있습니다. 이처럼 다양한 인프라가 서로 연결되어 있는 환경에서는 단일 장애가 전체 서비스에 어떤 영향을 주는지를 파악하는 일조차 쉽지 않으며, 과거의 이슈와 연관된 맥락까지 함께 분석할 수 있어야 보다 정확하고 신속한 운영이 가능해집니다. Zenius EMS는 단일 리소스 중심의 수치나 지표 제공에 머무르지 않고, 전체 인프라 구조를 맥락적으로 해석하고, 실시간 자동화 및 예측 분석 기능을 통해 장애를 사전에 방지하며, 발생한 이슈에 대해서도 구조적 흐름 안에서 진단할 수 있는 환경을 제공합니다. 여기에 더해, 대규모 인프라 환경에서도 안정적으로 동작할 수 있는 구조와 운영자의 부담을 줄여주는 기술 지원 체계, 그리고 수많은 현장 경험을 통해 검증된 운영 안정성까지 더해지면서, Zenius EMS는 단순한 모니터링 도구를 넘어 하이브리드 인프라 운영을 실질적으로 뒷받침하는 기반 플랫폼으로 자리 잡고 있습니다. 2025.06.12
기술이야기 이상 징후 탐지 솔루션, Zenius AI의 주요기능과 특장점 기술이야기 이상 징후 탐지 솔루션, Zenius AI의 주요기능과 특장점 IT 인프라의 복잡성과 운영 환경이 점점 더 고도화됨에 따라, 시스템 장애를 사전에 탐지하고 선제적으로 대응하는 기술의 중요성이 크게 부각되고 있습니다. 기존의 장애 관리 방식은 주로 장애 발생 이후에 원인을 분석하고 복구 조치를 취하는 사후 대응(Post-Mortem Response) 중심이었습니다. 그러나 이러한 접근 방식은 서비스 다운타임 증가, 운영 비용 상승, 장애의 반복 발생과 같은 문제를 야기하며, 기업의 디지털 운영 안정성을 위협합니다. Zenius AI는 이러한 한계를 극복하기 위해 머신러닝 기반의 이상징후 탐지 및 장애 예측 기능을 제공하는 이상 징후 탐지 솔루션입니다. 대규모 IT 인프라 환경에서 수집되는 로그, 메트릭, 이벤트 데이터를 실시간으로 분석하여 정상 패턴에서 벗어나는 이상 징후를 조기에 감지하고, 잠재적인 장애를 사전에 예측할 수 있도록 지원하는 Zenius AI의 주요기능과 특장점을 자세히 알아보겠습니다. 이상 징후 탐지 솔루션, Zenius AI의 주요 기능 Zenius AI는 IT 운영 환경에서 이상징후를 실시간으로 감지하고 대응할 수 있도록 설계된 AI 기반의 모니터링 솔루션입니다. 이 솔루션은 데이터 수집 및 관리, AI 모델 학습 및 예측, 이상징후 감지 및 대응, 대시보드 시각화 및 운영관리의 네 가지 핵심 기능을 제공합니다. 1) 데이터 수집 및 관리 Zenius AI는 Kafka 기반의 고성능 메시징 시스템과 OpenSearch 기반의 스토리지 및 검색 엔진을 통해, 대규모 로그 및 메트릭 데이터를 실시간으로 안정적이고 유실 없이 수집할 수 있도록 설계되었습니다. 이를 통해 시스템 전반에서 발생하는 다양한 이벤트 및 상태 정보를 정밀하게 추적하고, 이상징후 탐지에 최적화된 정제된 학습용 데이터셋을 구축할 수 있습니다. 특히 Zenius EMS(Enterprise Monitoring System)와의 직접적인 연동 기능을 제공함으로써, 서버, 네트워크, 애플리케이션 등 다양한 IT 인프라에서 생성되는 실시간 성능 데이터를 효과적으로 수집할 수 있습니다. 이를 통해 기존 IT 운영 환경과 유기적으로 연결된 데이터 수집·분석 체계를 구현할 수 있으며, 수집된 데이터를 기반으로 한 AI 기반 이상징후 탐지 및 선제적 대응 체계 구축이 가능해집니다. 또한, 데이터 수집 단계에서부터 AI 학습 및 예측 모델 구축에 이르기까지 전체 파이프라인이 긴밀하게 통합되어 있어, 운영 효율성과 데이터 신뢰성을 동시에 확보할 수 있는 것이 Zenius AI의 큰 강점입니다. 2) AI 모델 학습 및 예측 Zenius AI는 시계열 데이터 기반의 정밀한 이상징후 탐지를 위해 Amazon Web Services(AWS)에서 제공하는 DeepAR 시계열 예측 모델을 활용합니다. DeepAR은 다수의 시계열 데이터를 동시에 처리하고, 시간 축을 따라 변화하는 패턴을 학습하여 정상 범위를 벗어나는 이상 징후를 사전에 감지할 수 있도록 지원합니다. 이를 통해 단순 임계값 기반 감지를 넘어선 지능형 예측 분석이 가능해집니다. 또한, Zenius AI는 AutoGluon 기반의 AutoML 기능을 통합하여 모델 개발 전반을 자동화합니다. 하이퍼파라미터 최적화, 특성 선택, 다양한 알고리즘 기반 학습 등을 자동으로 수행하고, 정확도 기준에 따라 최적의 모델을 자동으로 선택함으로써 분석 정확도와 효율성을 동시에 향상시킵니다. 데이터의 특성과 계절성이 반영된 학습 모델은, 각 서비스에 맞는 맞춤형 예측 알고리즘으로 적용되며, 모델 자동 배포, 버전 관리, 스케줄 기반 재학습 기능을 통해 지속적으로 개선되고 고도화됩니다. 3) 이상 징후 감지 및 대응 Zenius AI는 머신러닝 기반의 시계열 예측 모델을 활용하여, 시간에 따라 변화하는 메트릭 데이터의 정상적인 흐름을 학습하고, 예측값과 실제 관측값 간의 오차를 분석함으로써 예상 범위를 벗어나는 이상징후를 조기에 감지합니다. 이 방식은 단순한 임계치 설정을 넘어서, 모델이 정상 상태를 스스로 학습하고 예외 상황을 자동으로 판별함으로써, 더 높은 민감도와 신뢰성을 갖춘 예측 기반 감지 체계를 구현합니다. 또한, 감지된 이상징후에 대해 이벤트의 심각도를 자동 분류하고, 사전에 정의된 조건에 따라 이메일, 문자, 사운드 등 다양한 채널을 통한 실시간 알림을 제공함으로써, 운영자가 신속하게 대응할 수 있도록 지원합니다. 뿐만 아니라, Zenius AI는 메트릭 기반 탐지 외에도 로그 기반 이상징후 감지 기능을 제공합니다. 특히, 로그가 정상적으로 수집되지 않거나 누락될 경우를 실시간으로 탐지하는 로그 미수집 감지 기능을 통해, 분석에 필요한 데이터의 공백을 사전에 차단하고 이상 탐지 누락을 방지할 수 있습니다. 이 기능은 장애의 근본 원인을 조기에 식별하는 데 중요한 역할을 하며, 호스트 단위의 로그 수집 현황을 시각화하여 운영자가 이상 상황을 한눈에 파악하고 조치할 수 있도록 지원합니다. 4) 대시보드 및 시각화 기능 Zenius AI는 실시간 이상징후 감지 결과를 직관적으로 파악할 수 있도록, 고도화된 대시보드 및 시각화 기능을 제공합니다. 서비스 그룹, 호스트, 모델별로 논리적으로 구성된 시각화 컴포넌트를 통해, 운영자는 전체 IT 인프라의 상태와 이상징후 발생 현황을 한눈에 파악할 수 있으며, 각종 지표에 대한 심층 분석도 즉각적으로 수행할 수 있습니다. 또한, WYSIWYG(What You See Is What You Get) 기반의 시각 보고서 생성 기능을 통해, 이상징후 탐지 결과와 예측 데이터를 시각적으로 정리하고, 이를 분기별 보고서, 사용자 정의 통계 리포트 등 다양한 형식으로 출력할 수 있어 IT 운영팀 및 경영진과의 효율적인 커뮤니케이션과 의사결정을 지원합니다. 운영관리 측면에서는 사용자 권한 및 알림 통보 설정 기능이 포함되어 있어, 역할 기반 접근 제어(RBAC)를 통해 사용자별 접근 권한을 세밀하게 관리할 수 있습니다. 장애 또는 이상 이벤트 발생 시에는 이메일, 문자, 사운드 알람 등 다양한 매체를 통해 실시간 경보를 전송하고, 알림의 심각도, 전송 시간대, 수신자 그룹 등을 세분화하여 설정할 수 있어 운영의 유연성과 대응 속도를 크게 향상시킵니다. 이상 징후 탐지 솔루션, Zenius AI의 특장점 Zenius AI는 실시간 데이터 분석 역량과 AI 기반 모델 최적화 기능을 결합한 차세대 이상징후 탐지 솔루션으로, 기존 시스템 대비 한층 정교하고 신속한 대응 체계를 제공합니다. 이를 통해 IT 운영 환경에서 보다 신뢰도 높은 장애 예측과 효율적인 운영 관리가 가능해집니다. 첫째, Zenius AI는 초고속 인덱싱 및 검색 성능을 통해 대규모 로그 데이터를 실시간으로 분석할 수 있습니다. 최대 162만 EPS(Events Per Second)의 로그 인덱싱 처리 속도를 제공하며, 1TB 규모의 로그도 단 0.02초 내에 검색할 수 있어, 장애 발생 시 즉각적인 원인 진단과 대응이 가능합니다. 또한, 대용량 환경에서도 로그 유실 없이 안정적인 저장 및 분석이 가능하여, 운영 신뢰성과 가용성을 크게 향상시킵니다. 둘째, Zenius AI는 AI 기반의 자동화된 모델 관리 기능을 갖추고 있어, 모델의 학습, 최적화, 배포를 전 과정 자동화할 수 있습니다. 수작업 없이도 성능을 지속적으로 개선할 수 있으며, 스케줄 기반 학습 관리를 통해 최신 데이터를 반영한 정기적 모델 업데이트가 가능합니다. 또한, Zenius EMS(Enterprise Monitoring System) 및 다양한 3rd Party 시스템과의 연동 기능을 통해 기존 IT 인프라와 유기적으로 통합된 분석 환경을 구현할 수 있습니다. 셋째, 머신러닝 기반의 이상징후 조기 탐지 및 대응 체계를 통해 서비스 장애를 사전에 감지하고 신속하게 대응할 수 있습니다. 예측값과 실제값의 오차 기반 분석을 통해 정밀한 이상징후를 탐지하며, 장애 패턴 분석 기능을 통해 유사 장애의 반복 가능성을 최소화합니다. 이를 통해 운영자는 보다 체계적이고 선제적인 장애 대응이 가능하며, 전체 IT 서비스의 안정성과 연속성을 효과적으로 유지할 수 있습니다. Zenius AI는 AI 기반의 이상징후 탐지를 통해 IT 운영의 효율성을 높이고, 장애를 사전에 방지할 수 있도록 지원합니다. 머신러닝 기반의 학습과 장애 패턴 분석을 통해 장애 재발 가능성을 최소화하고, 선제적인 예방 및 대응 체계를 구축함으로써 장애 원인을 조기에 차단할 수 있습니다. 이를 통해 서비스 다운타임을 최소화하고, 안정적인 운영 환경을 유지하여 서비스품질과 신뢰도를 향상시킵니다. 또한, Zenius AI는 운영 비용 절감과 IT 생산성 향상에도 기여합니다. 장애 처리에 소요되는 인력과 시간을 절감해 운영팀이 핵심 업무에 집중할 수 있도록 돕고, 자동화된 감지 및 대응 시스템을 통해 전반적인 운영 부담을 효과적으로 완화합니다. 이상 징후 탐지 솔루션 Zenius AI도입을 통해 IT 운영의 안정성과 효율성을 강화하고, 보다 신뢰도 높은 서비스 환경을 구축하시기 바랍니다. 2025.04.03
기술이야기 효과적인 쿠버네티스 모니터링을 위한 6가지 고려사항 기술이야기 효과적인 쿠버네티스 모니터링을 위한 6가지 고려사항 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes, K8s)는 자동화된 확장성과 자가 복구 기능을 통해 서비스의 안정성과 운영 효율성을 높이는 장점이 있습니다. 따라서 다양한 마이크로서비스 아키텍처(MSA)와 클라우드 환경에서 널리 활용되고 있습니다. 그러나 쿠버네티스는 파드(Pod), 노드(Node), 네트워크 등 각 요소가 끊임없이 동적으로 변화하며 상호작용하는 복잡한 구조이기 때문에, 체계적이고 세밀한 모니터링 없이는 운영에 어려움을 겪을 수 있습니다. 그렇다면 효과적인 쿠버네티스 모니터링을 위한 필수 고려사항은 무엇인지 6가지로 나눠서 알아보겠습니다. [1] 파드 및 컨테이너 모니터링 파드(Pod)와 컨테이너는 쿠버네티스에서 애플리케이션이 실행되는 가장 기본적인 단위이자 핵심 구성 요소입니다. 따라서 애플리케이션의 가용성과 성능을 안정적으로 유지하기 위해서는 각 파드와 컨테이너의 상태를 정밀하게 모니터링 하는 것이 중요합니다. 파드가 제대로 스케줄링되지 않거나, 컨테이너가 크래시 루프(CrashLoopBackOff) 상태에 빠지면 애플리케이션 성능이 저하되거나 서비스가 중단될 수 있습니다. 이러한 문제를 사전에 방지하려면 각 파드의 CPU, 메모리 사용량, 네트워크 I/O와 같은 자원 사용 현황을 실시간으로 모니터링하는 체계가 필요합니다. 특히, 자원 사용량을 지속적으로 추적하여 비정상적인 사용 패턴이나 과부하 상태를 사전에 감지하는 것이 중요합니다. 또한, 쿠버네티스의 오토스케일링(Auto-Scaling) 기능과 연계된 모니터링 솔루션을 통해 파드가 실시간 트래픽 변화에 맞춰 자동으로 확장 또는 축소될 수 있도록 설정하는 것이 자원 효율성 측면에서도 유리합니다. 이와 같은 종합적인 모니터링 솔루션은 파드와 컨테이너의 상태 변화에 대한 정확한 정보를 제공하고, 문제가 발생하기 전에 이를 사전에 탐지하고 대응할 수 있는 능력을 제공합니다. [2] 클러스터와 노드 상태 모니터링 쿠버네티스 클러스터는 다수의 노드로 구성된 분산 시스템으로, 각 노드는 파드(Pod)를 실행하는 주체로서 클러스터 전반의 성능과 안정성에 중요한 영향을 미칩니다. 각 노드의 CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등 주요 리소스 사용량을 실시간으로 모니터링함으로써 리소스 과부하나 잠재적 장애를 사전에 감지하고 예방할 수 있습니다. 특히, 노드 간 리소스 사용의 불균형은 클러스터 전체 성능에 부정적인 영향을 미칠 수 있으며, 특정 노드에서 발생하는 비정상적인 리소스 소모는 장애의 전조로 볼 수 있습니다. 예를 들어, CPU나 메모리 자원의 지속적인 고갈, 네트워크 트래픽의 급격한 증가 등은 장애를 유발할 수 있는 주요 지표로, 이를 사전에 감지하고 신속하게 대응하는 것이 중요합니다. 이를 위해 각 노드의 메트릭 데이터를 분석하고, 비정상적인 패턴을 자동으로 탐지할 수 있는 쿠버네티스 모니터링 솔루션을 도입하는 것이 필요합니다. 이러한 솔루션은 클러스터 내 모든 노드의 상태를 실시간으로 모니터링하고, 비정상적인 리소스 사용을 빠르게 인식할 수 있게 해줍니다. 또한, 자동화된 경고 시스템을 통해 잠재적인 문제가 발생하기 전에 관리자에게 즉시 알림을 제공하며, 리소스 사용 추세를 기반으로 한 예측 분석 기능을 통해 향후 발생할 수 있는 문제를 미리 방지할 수 있도록 지원합니다. [3] 네트워크 모니터링 쿠버네티스는 내부 네트워크와 외부 네트워크 간 통신이 빈번하게 이루어지는 복잡한 분산 시스템입니다. 파드 간의 통신 오류나 클러스터 외부와의 연결 문제는 애플리케이션 성능 저하로 이어질 수 있기에, 네트워크 상태를 정밀하게 모니터링해야 합니다. 주요 모니터링 지표로는 네트워크 지연(latency), 패킷 손실(packet loss), 네트워크 인터페이스 속도와 대역폭 등이 있으며, 이러한 지표들은 애플리케이션 가용성과 성능에 직접적인 영향을 미칠 수 있습니다. 특히 서비스 메시(Service Mesh)와 같은 고급 네트워크 구성 요소를 도입한 환경에서는 네트워크 복잡성이 더욱 증가하므로, 네트워크 트래픽 경로를 시각화하고 트래픽 흐름을 분석할 수 있는 고도화된 모니터링 솔루션이 필요합니다. 이러한 시스템을 통해 비정상적인 트래픽 패턴이나 병목 현상을 사전에 감지하고, 네트워크 문제를 신속하게 해결할 수 있는 역량을 확보하는 것이 중요합니다. 특히, 네트워크 모니터링은 전체 클러스터의 안정성과 애플리케이션 성능을 보장하는 데 중요한 역할을 합니다. [4] 로그 및 메트릭 수집과 분석 모니터링의 핵심은 적절한 로그와 메트릭 데이터를 수집하고 이를 분석하여 시스템 상태를 지속적으로 파악하는 데 있습니다. 쿠버네티스는 클러스터 내에서 발생하는 다양한 이벤트를 로그로 기록하고, 각 파드, 컨테이너, 노드에서 발생하는 자원 사용량과 성능 관련 데이터를 메트릭으로 제공합니다. 이러한 로그와 메트릭을 실시간으로 수집하고 분석함으로써, 문제가 발생했을 때 그 원인을 빠르게 파악하고 대응할 수 있습니다. 예를 들어, 특정 파드에서 반복적으로 발생하는 에러 로그는 애플리케이션의 특정 기능이 문제가 있음을 시사하며, 이를 통해 운영자는 그 원인을 정확히 파악할 수 있습니다. 또한, 성능 저하가 발생할 때 메트릭 데이터를 분석하여 CPU, 메모리, 네트워크 등 리소스 부족이 원인인지 식별할 수 있습니다. 이러한 정보가 실시간으로 제공되기 때문에, 운영자는 문제를 조기에 발견하고 빠르게 대응할 수 있으며, 그 결과 시스템 장애나 성능 저하를 미연에 방지할 수 있습니다. 또한, 실시간으로 로그와 메트릭 변화를 추적하고 모니터링 솔루션의 경고 알림 기능 등을 활용하면, 문제를 사전에 예측하고 조치를 취할 수 있습니다. [5] 자동화 기능과의 긴밀한 연동 쿠버네티스의 주요 기능 중 하나는 자동화된 확장과 자가 치유(Self-Healing) 기능으로, 이를 통해 클러스터의 안정성과 가용성을 유지할 수 있습니다. 자동화된 확장은 클러스터 상태를 실시간으로 모니터링하여 자원이 부족할 때 자동으로 새로운 파드를 생성하고, 부하를 분산함으로써 성능 저하를 방지합니다. 또한 자가 치유 기능은 장애가 발생한 파드나 노드를 감지하여, 파드를 자동으로 재시작하거나 장애가 발생한 파드들을 다른 건강한 노드로 이동시키는 역할을 합니다. 이러한 기능이 원활하게 작동하려면, 모니터링 솔루션이 클러스터의 상태를 정확하게 파악하고, 자원 사용 현황 및 노드 상태에 대한 신뢰할 수 있는 데이터를 제공해야 합니다. 이를 위해 모니터링 솔루션은 높은 확장성과 안정성을 보장할 수 있는 설정이 필수적입니다. 예를 들어, 파드의 자원 부족이 발생하면 이를 실시간으로 감지하여 적절한 확장 작업이 즉시 이루어질 수 있도록 지원해야 합니다. 결과적으로, 쿠버네티스의 자동화 기능이 성공적으로 활용되려면 쿠버네티스 모니터링 솔루션과의 긴밀한 연동이 반드시 필요합니다. [6] 보안 및 규정 준수 분산 아키텍처를 기반으로 하는 쿠버네티스 클러스터는 외부 공격에 더욱 취약할 수 있으며, 다양한 보안 위협에 노출될 가능성이 존재합니다. 이러한 위협을 효과적으로 방어하기 위해서는 네트워크 트래픽 모니터링을 통해 비정상적인 활동이나 의심스러운 트래픽 패턴을 신속히 감지하고, 보안 정책 위반, 의도치 않은 구성 변경, 혹은 취약점 발견 시 자동으로 경고를 발송하는 보안 모니터링 체계가 필요합니다. 이와 함께, 컨테이너 이미지의 보안 취약점 분석을 사전에 실시하여 악성 코드나 알려진 취약점으로부터 클러스터를 보호하고, 이를 기반으로 하는 보안 스캔 자동화가 중요합니다. 또한, 클러스터 전반에서 발생하는 모든 활동을 실시간으로 감사(Audit) 및 기록하여 컴플라이언스 요구사항을 충족시키는 중앙 집중형 로그 관리 시스템이 필요합니다. 이러한 감사 로그는 규정 준수를 위한 기본적인 요소일 뿐만 아니라, 보안 사고 발생 시 원인 분석 및 대응을 위한 핵심 자료로 활용될 수 있습니다. 쿠버네티스와 같은 분산 시스템을 성공적으로 운영하기 위해서는 그 안에서 발생하는 다양한 이벤트를 실시간으로 모니터링하는 것이 매우 중요합니다. 6가지 고려사항을 통해 클러스터의 상태를 세밀하게 추적하고 분석함으로써, 예상치 못한 문제를 미리 발견하고 대비할 수 있습니다. 특히, 노드나 파드의 자원 소모가 비정상적으로 급증할 때 이를 빠르게 인식하고 조치를 취함으로써, 시스템의 성능 저하를 방지할 수 있습니다. 또한, 네트워크 상태와 보안 위협에 대한 철저한 모니터링은 전체 서비스의 가용성을 높이는 데 큰 도움이 됩니다. 이처럼 체계적인 모니터링 전략을 통해 쿠버네티스 환경에서의 안정성을 확보할 수 있으며, 서비스 중단 없이 원활한 운영을 이어갈 수 있습니다. 2024.10.24
기술이야기 오픈소스 APM만으로 완벽한 웹 애플리케이션 관리, 가능할까? 기술이야기 오픈소스 APM만으로 완벽한 웹 애플리케이션 관리, 가능할까? 지난 글을 통해 옵저버빌리티(Observability) 중요성과 APM 차이점을 자세히 살펴보았습니다(자세히 보기). 옵저버빌리티는 APM 한계성을 극복하는 방법은 맞지만, 어느 하나가 더 나은 방법이라기 보단 조직이나 사용자 상황에 따라 적합한 선택해야 하는 것이 주요 포인트였습니다. 하지만 상용 APM 제품은 다소 높은 구매 비용으로 인해, 규모가 작은 기업의 경우 부담이 될 수 있는데요. 이 때 오픈소스 APM 솔루션이 효과적인 대안이 될 수 있는데요. 따라서 이번 시간에는 주요 오픈소스 APM 알아보고, APM 상용 제품과는 어떤 차이점이 있는지 살펴보겠습니다. │오픈소스(Open Source) 소프트웨어란? 오픈소스(Open Source)란 개발 핵심 소스 코드를 공개하여 누구나 접근하고, 수정하여, 배포할 수 있는 소프트웨어를 말합니다. 얼핏 자유 소프트웨어와 비슷하게 느껴질 수 있지만 조금 다른 의미를 가지는데요. 자유 소프트웨어는 사용자의 '자유'를 강조하지만, 오픈소스는 소스 코드의 '접근성과 협업'을 중시합니다. 대표적으로 관계형 데이터베이스인 MySQL, 웹 브라우저인 Firefox, 컨테이너 가상화 플랫폼인 Docker가 대표적인 오픈소스 소프트웨어라고 할 수 있습니다. 현재 국내 디지털플랫폼 정부 구축 정책 기조에 따르면, 오픈소스 소프트웨어는 여러가지 장점을 갖고 있는데요. 오픈소스 장점 오픈소스의 첫번 째 장점은 진입 비용이 낮다는 점입니다. 공개된 소스를 기반으로 수정과 배포가 가능하기 때문에 새로운 기반 기술을 만들어 갈 경우, 비용을 줄일 수 있습니다. 두 번째 장점은 MSA 아키텍처의 기술적 토대가 오픈소스에 기반한다는 점입니다. 최근 소프트웨어 개발 환경은 오픈소스 의존도가 높아지고 있는데요. 이는 오픈소스가 특정 벤더에 종속되지 않아 독립성을 보장한다는 점에서, 오픈소스의 가장 큰 장점이라고 할 수 있습니다. 그에 반해 오픈소스 단점도 명확한데요. 오픈소스 단점 첫 번째 단점은 상용 소프트웨어와 비교해 매뉴얼이 빈약한 경우가 많다는 점입니다. 이에 따라 실제 개발 단계에서 운영이 지연될 가능성이 높아지죠. 두 번째 단점으로는 기술 지원 체계는 오픈소스 커뮤니티에 의존하고 있기 때문에, 유지보수에 큰 어려움이 따른다는 점입니다. 물론 특정 벤더에 종속되지 않는 독립성을 취할 수 있지만, 지속적인 기술지원은 어렵죠. 그렇다면 현재 국내에서 가장 많이 사용하는 오픈소스 APM 소프트웨어는 무엇인지, 자세히 살펴보겠습니다. │오픈소스 APM 종류 오픈소스 APM 종류는 다양하지만 대표적으로 Scouter, Pinpoint, Prometheus & Grafana에 대해 알아보겠습니다. 1. Scouter 첫 번째로 소개해 드릴 오픈소스 APM은 스카우터(Scouter)입니다. 스카우터는 LG CNS에서 만든 오픈소스 APM 소프트웨어로, 자바를 사용하는 애플리케이션과 컴퓨터 시스템 성능을 모니터링합니다. 이 소프트웨어는 Window, Linux, Mac 등 다양한 운영체제(OS)에서 사용할 수 있으며, 주로 이클립스 플랫폼에서 개발되었습니다. 즉 여러 환경에서 자바 애플리케이션 데이터를 수집하고, 성능 상태를 효과적으로 할 수 있다는 점이 스카우터의 주요 기능입니다. 1-1. Scouter 아키텍처 Scouter는 주로 네 가지 주요 컴포넌트로 구성되어 있는데요. 자세히 살펴보도록 하겠습니다. Java Agent Java 기반의 웹 애플리케이션(예: Tomcat, JBoss, Resin)과 스탠드얼론 Java 애플리케이션을 모니터링하는 모듈입니다. 이 에이전트는 웹 애플리케이션 서버(WAS)에 설치되어 애플리케이션 성능 정보(예: 메소드 실행 시간, 사용자 요청 처리 시간 등)를 수집하고 Scouter 서버로 전송합니다. Host Agent 이 에이전트는 운영 체제(예: Linux, Unix, Windows 등)에 설치되어 시스템 하드웨어 리소스 사용 상태를 모니터링합니다. CPU 사용률, 메모리 사용량, 디스크 I/O와 같은 정보를 수집하여 Scouter Server로 보내주는 역할을 합니다. Scouter Server(Collector) 이 서버는 Java Agent와 Host Agent로부터 데이터를 수집해 저장합니다. 사용자는 클라이언트를 통해 이 데이터에 접근할 수 있으며, 이를 통해 애플리케이션의 성능을 모니터링하고 분석할 수 있습니다. Scouter Client 사용자는 Scouter Client를 통해 서버에 접속하여, 서버로부터 수집된 데이터를 조회할 수 있습니다. 이 클라이언트는 다양한 성능 지표를 기반으로 한 시각적인 대시보드를 제공하여, 애플리케이션과 시스템 성능 상태를 효과적으로 모니터링할 수 있게 도와줍니다. 1-2. Scouter 주요기능 출처ⓒ tistory_chanchan-father Scouter의 주요기능 중 하나는 'XLog'인데요. 이 기능은 트랜잭션 응답 시간을 시각적으로 표현하여 시스템 성능을 모니터링하는 데 유용합니다. 액티브 서비스가 종료될 때마다 XLog 차트에 점으로 나타나기 때문에, 개발자는 트랜잭션 처리 시간을 간편하게 확인할 수 있습니다. 각 점을 클릭하여 관련 트랜잭션의 자세한 정보를 얻을 수 있으며, 시스템 분석과 성능 개선 작업에도 도움을 줍니다. 2. Pinpoint 두 번째로 소개해 드릴 오픈소스 APM는 '핀포인트(Pinpoint)'입니다. 핀포인트는 네이버에서 2012년 7월부터 개발을 시작해, 15년 초에 배포한 오픈소스 APM 솔루션입니다. 핀포인트는 MSA를 위한 국산 오픈소스 APM으로 각광 받아왔습니다. 2-1. Pinpoint 아키텍처 핀포인트 아키텍처는 다음과 같은 네 가지 주요 구성요소는 이루어져 있는데요. 아래 내용을 통해 자세히 살펴보겠습니다. Agent 핀포인트의 에이전트는 애플리케이션 서버에 java-agent 형태로 추가되어, 애플리케이션 성능 데이터를 실시간으로 수집합니다. 이 에이전트는 수집한 데이터를 Collector로 전송하며, 이 과정을 통해 성능 모니터링과 문제 해결에 필요한 중요 정보를 제공합니다. Collector Agent로부터 받은 프로파일링 데이터를 수집하고 처리하는 역할을 합니다. Collector는 이 데이터를 구조화하여 빅데이터 데이터베이스인 HBase로 전송합니다. 이를 통해 데이터가 안정하게 저장되고 필요할 때 쉽게 접근할 수 있습니다. HBase Hbase는 분산 데이터베이스로서, 핀포인트 시스템에서 성능 데이터를 저장하고 검색하는 중심적인 역할을 합니다. 대규모 데이터 볼륨을 효율적으로 처리할 수 있는 구조로 설계되어 있으며, 수집된 데이터의 신속한 처리와 안정적인 저장을 보장합니다. Web UI 웹 인터페이스를 통해 사용자에게 데이터를 시각적으로 제공하는 구성 요소입니다. 이 데이터는 핀포인트 에이전트가 애플리케이션 서버에서 수집한 정보를 기반으로 생성됩니다. 이렇게 수집된 데이터는 서버를 통해 Web UI로 전송되면, 사용자는 UI를 통해 다양한 형태의 성능 지표를 조회하고 분석할 수 있습니다. 이러한 구성을 통해 네이버 핀포인트는 애플리케이션 성능 문제를 진단하고 해결하는 데 필요한 정보를 제공합니다. 2-2. Pinpoint 주요기능 그 다음으로 핀포인트의 대표적인 주요 기능에 대해 자세히 알아보겠습니다. 서버맵 이 기능은 분산 환경에서 각 노드 간의 트랜잭션 흐름을 시각적으로 표현하여, 트랜잭션 성공/실패와 응답 시간 분포를 실시간으로 모니터링할 수 있습니다. 이를 통해 시스템 부하 상태와 성능 병목 지점을 식별할 수 있죠. 콜스택 콜스택(Call Stack) 기능은 트랜잭션의 세부 실행 과정을 추적하여, 성능 문제 원인을 분석하고, 코드 최적화를 지원합니다. 이 기능은 각 콜스택에서 소요되는 시간과 발생하는 예외 상황까지 자세히 보여주어, 성능 병목 현상 진단에 도움을 줍니다. 트랜잭션 필터 사용자는 트랜잭션 필터 기능을 이용해 응답 시간이 긴 트랜잭션, 특정 사용자나 IP 주소에서 발생한 트랜잭션 등을 세부적으로 필터링하여 분석할 수 있습니다. 이는 특정 조건에 따른 트랜잭션의 세부 사항을 더 깊이 이해하는 데 유용합니다. Application Inspector 이 기능은 애플리케이션 성능 지표를 시간별/일별로 분석하며 CPU 사용률, 메모리 사용량, JVM 상태 등을 체계적으로 관리하는 기능을 제공합니다. 이를 통해 애플리케이션의 전반적인 성능 관리가 가능합니다. 3. Prometheus 세 번째로 소개해 드릴 오픈소스 APM는 '프로메테우스(Prometheus)'입니다. 프로메테우스는 관제 대상으로부터 모니터링 메트릭 데이터를 저장하고, 검색할 수 있는 시스템인데요. 무엇보다 CNCF 재단으로부터 '클라우드 네이티브에 적합한 오픈소스 모니터링'으로 각광 받아 쿠버네티스(Kubernetes, K8s) 이후 두번째로 졸업한 프로젝트입니다. 프로메테우스는 CNCF 졸업 인증서를 받은 이후 시장에서 많은 주목을 받았습니다. 구조가 간단해서 운영이 쉽고, 다양한 모니터링 시스템과 연계할 수 있는 여러 플러그인을 보유하고 있기 때문이죠. 이러한 장점은 클라우드 네이티브를 위한 기초적인 오픈소스로 각광 받게 되었습니다. 3-1. Prometheus 아키텍처 프로메테우스에서 가장 큰 특징은 에이전트(Agent)가 아닌, 메트릭(Metric)을 통해 데이터를 수집한다는 점입니다. 메트릭이란 이전 시간에도 살펴봤듯이, 현재 상태를 보기 위한 시계열 데이터를 의미합니다. 프로메테우스는 이러한 메트릭 수집을 위해 다양한 수집 도구를 사용하는데요. 좀 더 자세히 살펴보도록 하겠습니다. Application 위 아키텍처에서 수집하고자 하는 대상은, 애플리케이션으로 표현됩니다. 주로 MySQL DB과 Tomcat과 같은 웹 서버까지 다양한 서버와 WAS가 모니터링 대상이 됩니다. 프로메테우스는 이를 주로 Target System으로 표현하고 있습니다. Pulling 프로메테우스에서는 각 Target System에 대한 메트릭 데이터 수집을 풀링(Pulling) 방식을 통해 데이터를 수집합니다. 프로메테우스는 앞서 언급했듯 별도의 에이전트로 데이터를 수집하지 않습니다. Prometheus Server에서 자체적인 Exporter를 통해 메트릭 읽는 방식을 사용하죠. 보통 모니터링 시스템 에이전트는, 모니터링 시스템으로 메트릭을 보내는 푸쉬(Push) 방식을 사용합니다. 특히 푸쉬 방식은 서비스가 오토 스케일링 등과 같이 환경이 가변적일 경우 유리한데요. 풀링 방식의 경우 모니터링 대상이 가변적으로 변경될 경우, 모니터링 대상의 IP 주소를 알 수 없기 때문에 정확한 데이터 수집이 어려워집니다. Service Discovery 이처럼 정확한 데이터 수집을 해결하기 위한 방안이 서비스 디스커버리(Service Discovery) 방식입니다. 서비스 디스커버리는 현재 운영 중인 대상 목록과 IP 주소를 동적으로 수집하는 프로세스입니다. 예를 들어 file_sd, http_sd 방식부터 디스커버리 전용 솔루션인 Consul을 사용하죠. Exporter Exporter는 모니터링 대상 시스템에서 데이터를 수집하는 역할을 합니다. 별도의 에이전트는 아니지만, 에이전트와 비슷하게 데이터를 수집하는 역할을 합니다. HTTP 통신을 통해 메트릭 데이터를 수집하며, Exporter를 사용하기 어려울 경우 별도 Push gateway를 사용합니다. Prometheus Server 프로메테우스 서버는 데이터 수집, 저장, 쿼리를 담당하는 중앙 구성 요소입니다. HTTP 프로토콜을 사용하는 것이 특징이며, Exporter가 제공하는 HTTP 엔드포인트에 접속해 메트릭 데이터를 수집합니다. Alert Manager 사용자에게 알람을 주는 역할을 담당합니다. Prometheus는 타 오픈소스 모니터링 솔루션과 달리 Alert Manager UI 기능을 제공하여 일부 제한된 데이터를 시각화할 수 있습니다. 하지만 시각화 기능이 제한적이므로, 보통 Grafana라는 오픈소스 대시보드 툴을 사용하여 UI를 보완합니다. 3-2. Grafana '그라파나(Grafana)'에 좀 더 자세히 설명한다면, 데이터 분석을 시각화하기 위한 오픈소스 대시보드 도구입니다. 다양한 플러그인을 이용해 프로메테우스와 같은 모니터링 툴과 *그라파이트(Graphite)1, *엘라스틱서치(Elasticsearch)2, *인플럭스DB(InfluxDB)3 와 같은 데이터베이스와 연동하여 사용자 맞춤형 UI를 제공합니다. 특히 방대한 데이터를 활용해 맞춤형 대시보드를 쉽게 만들 수 있는 것이 그라파나의 큰 장점이죠. *1. Graphite: 시계열 데이터를 수집하고 저장하며, 이를 그래프로 시각화하는 모니터링 도구 *2. Elasticsearch: 다양한 유형의 문서 데이터를 실시간으로 검색하고 분석하는 분산형 검색 엔진 *3. InfluxDB: 시계열 데이터의 저장과 조회에 특화된 고성능 데이터베이스 그라파나의 주요 특징은 플러그인 확장을 통한 데이터 시각화와 템플릿 지원으로, 다른 사용자 대시보드 템플릿을 쉽게 가져와 사용할 수 있다는 점입니다. 이처럼 Promeheus 장점은 Exporter를 통한 다양한 메트릭 데이터 수집과 3rd Party 솔루션과 연계가 수월하다는 점입니다. 오픈소스로 IT 인프라를 구성하는 기업의 경우 Prometheus와 Grafana를 연계하여, 서비스 운영현황을 모니터링 할 수 있습니다. 지금까지 오픈소스 APM가 무엇이고, 각각의 아키텍처와 주요 기능은 무엇인지 살펴보았는데요. 그렇다면 상용 APM 제품과, 오픈소스 APM는 어떤 차이점이 있을까요? │상용 APM 제품 vs 오픈소스 APM 제품 앞에서 소개해 드린 오픈소스 APM 중, 대표적으로 프로메테우스와 핀포인트를 상용 APM 제품과 비교해 보겠습니다. Prometheus vs 상용 APM 제품 우선 프로메테우스를 대표하는 장점은 유연한 통합성입니다. 마이크로서비스가 대세 기술로 자리 잡으면서, 인스턴스를 자주 확장하거나 축소하는 것이 자유로운 요즘인데요. 만약 이 작업을 수동으로 관리한다면 매우 어려울 수 있습니다. 하지만 프로메테우스를 사용하면 이런 문제를 해결할 수 있죠. 프로메테우스는 쿠버네티스와 같은 여러 서비스 디스커버리 시스템과 통합되어, 쿠버네티스 클러스터 내의 모든 노드와 파드에 발생하는 매트릭을 자동으로 수집할 수 있습니다. 이러한 기능은 마이크로서비스 환경에서 효율적으로 모니터링 할 수 있습니다. 하지만 한계점도 있는데요. 바로 실시간 데이터 확인이 어렵다는 점입니다. 프로메테우스는 풀링(Pulling) 주기를 기반으로 메트릭 데이터를 수집하기 때문에, 순간적인 스냅샷 기능이 없습니다. 수집된 데이터는 풀링하는 순간 스냅샷 데이터라고 볼 수 있죠. 이러한 단점은 APM에서 일반적으로 지원하는 실시간성 트랜잭션 데이터를 대체하기 어렵습니다. 반면에 상용 APM 제품은 어떨까요? 대표적으로 Zenius APM 사례를 통해 살펴보겠습니다. Zenius APM은 에이전트가 자동으로 메트릭을 수집하여 서버로 전송하여, 데이터를 실시간으로 처리할 수 있습니다. 또한 에이전트가 푸쉬(Push) 방식이기 때문에, 데이터의 지연이 풀링 방식에 비해 적고 데이터가 더 정확하게 수집되죠. 또한 Raw Data 기반의 실시간 과거 데이터를 통해 정밀한 장애 원인 분석이 가능합니다. 과거 시점 스냅샷 기능도 있어 문제 발생 시점을 정확히 파악하여, 문제 해결 시간을 단축시킬 수 있죠. Pinpoint 장단점 vs 상용 APM 제품 그 다음으로는 핀포인트를 대표하는 장점에 대해 알아 보겠습니다. 핀포인트 장점으로는 클라우드 환경에서 뛰어난 가시성을 보여준다는 점입니다. 클라우드에서의 웹 애플리케이션 서버(WAS)는 유연성과 확장성이 뛰어나지만, 복잡한 시스템 구조로 인해 모니터링이 어려울 수 있는데요. 핀포인트는 이러한 환경에서, 각 가상 서버의 성능을 실시간으로 파악하고 문제를 신속하게 진단하는데 큰 도움을 줍니다. 그에 반해 핀포인트에 단점은 다양한 기능이 부족합니다. 핀포인트는 JVM 기반 데이터의 모니터링이 일부 제한되는데요. 대시보드의 'Inspector'와 같은 일부 기능이 지원되지 않아, 이용에 어려움이 있습니다. 또한 다수 트랜잭션이 동시에 실행될 때 특정 트랜잭션이 오래 걸리거나 에러가 발생할 경우, 그 원인을 파악하기 어렵습니다. 이는 세부적인 콜백 정보를 충분히 제공하지 않았기 때문이죠. 그렇다면 상용 APM 제품은 어떨까요? 이번에도 Zenius APM를 통해 자세히 살펴보겠습니다. Zenius APM은 다양한 트랜잭션 모니터링 기능을 제공하는데요. 이를 통해 사용자는 트랜잭션 성능을 실시간으로 파악하고, 잠재적 문제를 빠르게 진단할 수 있습니다. 또한 이 시스템은 대량으로 동시 접속자를 대량으로 관리할 수 있어, 피크 타임에 발생할 수 있는 성능 저하를 사전에 감지하고 대응할 수 있도록 지원합니다. 비교표 구분 Zenius APM Prometheus Pinpoint Scouter 기술지원 벤더 지원을 통한 빠른 초기 설정, 기술지원 용이 오픈소스 기반의 기술지원 불가로 초기 학습 필요 오픈소스 기반의 기술 지원 불가로 초기 학습 필요 오픈소스 기반의 기술 지원 불가로 초기 학습 필요 사용자 인터페이스 실시간 트랜잭션 처리, 액티브 서비스 모니터링, 동시 접속 사용자 수 등, 사용자 정의 실시간 모니터링 상황판 구성 Grafana 플러그인 연계로 다양한 컴포넌트 모니터링 가능 토폴로지 일부 모니터링 불가, 제한적으로 사용자 동시 접속자 수 모니터링 가능, 사용자 정의 기반 모니터링 불가 기능 제한에 따른 간소화된 UI 제공, 사용자 정의 기반 모니터링 불가 컨테이너 모니터링 가능 가능 가능 불가 쿠버네티스 모니터링 가능 가능 불가 불가 연관 인프라 정보 모니터링 연관된 WAS 서버, DB서버, DB확인, 해당 인프라 상세 정보 제공 불가 재한적으로 연관 인프라 모니터링 제공 불가 Raw Data 과거 시점 재현 초 단위 데이터를 기준으로 장애 발생시점 등 과거 상황을 그대로 재현함 불가 불가 불가 리포팅 사용자 정의 기반 리포팅 서비스 제공 써드 파티를 이용한 제한적인 리포팅 기능 제공 불가 불가 이번 시간에는 주요 오픈소스 APM와 상용 APM 차이점을 살펴보았습니다. 각 솔루션은 분명한 장단점을 갖고 있으며, 모든 상황에 완벽한 솔루션은 없습니다. 그러나 여기서 주목해야 할 것은, APM의 핵심이 '트랜잭션을 얼마나 효과적으로 모니터링할 수 있는가'라는 점입니다. 이 측면에서 오픈소스 APM은 한계가 있으나, 상용 APM 제품은 이를 효과적으로 수행할 수 있습니다. 물론 비용 면에서 오픈소스 APM와 비교해, 상용 APM 제품이 부담스러울 순 있습니다. 하지만 트랜잭션 모니터링 관리의 중요성을 고려한다면, 이러한 투자는 가치가 있습니다. 더 나아가 심층적인 실시간 데이터 모니터링, 신속한 데이터 처리, 전문적인 기술적인 기술 지원, 보다 복잡한 시스템 환경에서 효과적인 트랜잭션 관리를 우선시 한다면 Zenius APM 제품이 더더욱 적합할 것입니다. ?더보기 Zenius APM 더 자세히 보기 ?함께 읽으면 더 좋아요 • APM에서 꼭 관리해야 할 주요 지표는? • APM의 핵심요소와 주요기능은? • 옵저버빌리티 vs APM, 우리 기업에 맞는 솔루션은? 2024.07.26
기술이야기 옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?! 기술이야기 옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?! 지난 글을 통해 웹 애플리케이션을 전반적으로 모니터링하고 관리하기 위한 좋은 도구인, APM의 핵심요소와 기능에 대해서 알아봤습니다(지난 글 보기). APM은 분명 좋은 도구이지만 문제 원인이 애플리케이션, 웹, WAS, DB가 아닌 특정한 시스템 오류이거나 클라우드 네이티브 환경에서의 장애일 경우 문제 발생 원인을 명확히 밝히기 어려울 수 있습니다. 따라서 이번 시간에는 APM의 한계성은 무엇이고, 이를 보완하기 위한 방법은 무엇인지 자세히 살펴보겠습니다. │APM 한계성 불과 얼마 전까지만 해도 예상치 못한 장애를 탐지하고 분석하는 것은, 기존 APM만으로 충분했었습니다. 기존에는 모놀리식 구조로 되어있어 애플리케이션이 적은 수로 구성되어 있었고, Web-WAS-DB가 모두 단일 구조로 구성되어 있었기 때문입니다. 하지만 현재 대다수 기업들은 MSA 환경에서 서비스를 구축하고, DevOps 구조로 업무를 진행하는 경우가 많습니다. 즉 클라우드 네이티브 환경에서는 기존 모놀리식 구조의 APM의 한계가 하나둘씩 보이기 시작한 것이죠. 이러한 이유로 클라우드 네이티브 방식에는 서비스 장애 원인을 분석하기 위한 새로운 모니터링 툴이 필요했습니다. 이때 등장하는 것이 바로 옵저버빌리티(Observability)입니다. │Observability란? 그렇다면 Observability란 무엇일까요? 옵저버빌리티는 IT 인프라에 대한 근본적인 장애 원인을 분석하기 위한 방법론입니다. 관찰 가능성이라고 표현되기도 하죠. Obsevability는 비교적 최근에 사용한 용어이지만, 옵저버빌리티를 위한 고민은 오래전부터 지속되어왔습니다. 시스템이 내가 의도한 대로 작동하고 있을까? 예상치 못한 장애 탐지와 장애 근본 원인은 어떻게 분석할 수 있을까? IT 인프라 운영 환경에 문제가 발생했을 때, 문제 식별을 위해 필요한 객관적인 지표는 어떻게 도출할 수 있을까? 하지만 소프트웨어 애플리케이션에서 Observability는, 위와 같은 고민이 발생하거나 겪어보지 못했던 현상이 생길 때 이를 이해하고 설명할 수 있는 지표를 분석해 줍니다. │Obsevability의 등장배경 및 필요성 앞에서 옵저버빌리티가 무엇인지 살펴봤는데요. 이어서 Observability가 등장하게 된 이유와 필요성에 대해 자세히 살펴보겠습니다. MSA 전환에 따른 복잡성 증가 옵저버빌리티가 등장하게 된 첫 번째 이유는, 모놀리식 아키텍처에서 MSA 환경으로 전환함에 따라 복잡성이 증가했기 때문입니다. 우선 그림을 통해 자세히 살펴보겠습니다. [그림(왼)]은 모놀리식 아키텍처를 나타내는데요. 애플리케이션의 모든 구성 요소가 하나의 인프라로 통합되어 있는 형태입니다. 배포가 간단하며, 확장성이 쉽고, E2E 테스트가 용이하다는 장점이 있습니다. 하지만 조그마한 수정 사항이 있으면, 다시 구성 환경을 빌드하고 배포해야 한다는 단점이 있습니다. 또한 일부 오류가 전체 아키텍처에 영향을 미친다는 치명적인 단점도 존재하죠. 반면 [그림(오)]에 해당하는 MSA(Micro Service Architecture)는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어, 변경과 조합이 가능합니다. 작은 서비스의 독립적 배포라는 강력한 장점을 앞세워 Netflix, PAYCO와 같은 다양한 기업들이 앞다투어 MSA를 받아들였습니다. 여기서 문제는 MSA로 변화함에 따라 통합 테스트나 E2E 테스트 검증이 필요해졌는데요. 이처럼 여러 서비스의 API를 검증해야 하므로, 복잡성이 증가하고 많은 시간과 비용이 소모되었습니다. 무엇보다 각 서비스 별로 자체적인 데이터베이스가 있어, 트랜잭션에 대한 파악이 어려워지기도 했죠. 따라서 기존 APM이 담당하는 트랜잭션 모니터링의 복잡성은 더욱 증가했고, Observability의 필요성이 대두되었습니다. DevOps와 클라우드 네이티브 환경으로서의 전환 옵저버빌리티가 등장하게 된 두 번째 이유는, DevOps와 클라우드 네이티브 환경으로 전환하기 위해 필요한 도구이기 때문입니다. DevOps의 핵심은 소프트웨어의 개발(Deployment)과 운영(Operation)을 분리하는 것이 아닌, 하나로 통합된 업무 처리 방식으로 진행됩니다. 이때 관리하는 서비스 전반에 대한 가시성이 충분히 확보되지 않으면, DevOps 조직은 근본적인 원인을 찾는 데 어려움을 겪게 됩니다. 이러한 어려움을 해결하기 위해서는 서비스를 구성하는 아키텍처부터 트랜잭션까지 가시성이 확보되어야 합니다. 이를 통해 DevOps의 목표인 지속적인 개발과 운영의 통합을 만들어낼 수 있죠. 또한 Observability는 클라우드 네이티브 환경으로 전환하기 위한 필수 조건입니다. 기업에서 운영 중인 서비스/IT 인프라가 클라우드 네이티브 환경으로 전환되면서, 이전에 발생하지 않았던 모든 장애 가능성에 대한 인지를 위해 Observability가 선행되어야 합니다. │Observability와 Monitoring 차이점 그렇다면 기존의 모니터링(Monitoring)과 옵저버벌리티(Observability)의 차이점은 무엇일까요? 기존의 모니터링 역할은 IT 인프라의 '정상 작동 확인'을 위한 도구 역할에 초점이 맞춰져 있었습니다. 모니터링 구성 요소인 대시보드와 사용자 알람을 통해 가시성을 확보하고, 장애를 쉽게 감지할 수 있었죠. 즉 모니터링은 인프라 성능 지표, 구성 관리, 사용자 알람에 주 목적을 둔 IT 운영 담당자에 포커스를 맞춘 도구입니다. Observability는 기존 모니터링이 맡는 알람(Alerting), 메트릭(Metric) 외에도 로그(시스템, 애플리케이션), 트레이스, 디버깅과 같은 작업이 가능합니다. 이를 통해 앞으로 발생할 수 있는 장애를 미리 예측하고, 발생한 장애에 대한 근본적인 원인을 찾아내는 데 초점이 맞춰져 있습니다. │Observability 확보를 위한 핵심 구성 요소 옵저버빌리티는 앞서 언급했듯이 메트릭(Metric), 로깅(Logging), 트레이싱(Tracing) 등 작업이 가능한데요. 좀 더 자세히 살펴보겠습니다. Metric 모니터링 분야에서 Metric(메트릭)이란, 인프라 혹은 서비스 성능과 상태를 나타내는 지표입니다. 여기서 중요한 점은 단순히 현재 상태를 보기 쉽게 표현하는 것에서 더 나아가 '시계열 데이터' 형태로 변화하는 데이터를 보여줘야 합니다. 예를 들어 CPU 사용률, 메모리 사용률, 스레드 사용률과 같이 시간이 지남에 따라 어떻게 변화하는지 효율적으로 보여줄 수 있어야 하죠. 또한 메트릭은 여러 AI 분석툴과 오픈소스와 결합하여, 직관적인 파라미터를 통해 시계열 데이터의 다양한 패턴을 자동 감지할 수 있어야 합니다. 운영자와 개발자에게 필요한 리소스를 선택할 수 있도록 성능 예측하는 지표도 필요합니다. Logging Logging(로깅)은 운영 중인 시스템과 애플리케이션에서 발생하는 다양한 이벤트와 에러 등을 기록하는 과정입니다. Observability는 여기서 더 나아가 클라우드 시스템의 모든 로그를 수집하여, 해당 로그를 통해 문제 원인을 식별할 수 있어야 합니다. 물론 각 로그 스트림은 단일 인스턴스에 대한 이벤트를 알려주기 때문에, 마이크로 서비스 환경에서 전체적인 문제 원인을 파악하기 어려울 수 있습니다. 하지만 중앙 집중식 로깅을 사용하면, 애플리케이션 로그를 한곳에 저장할 수 있습니다. 이를 통해 여러 서비스로 구성된 MSA 환경에서 로그를 효과적으로 검색하고 모니터링할 수 있죠. 이러한 작업을 하기 위해서 ELK Stack1 과 같은 로그 수집 활용 도구가 필요한데요. 이 도구는 로그 관리를 단순화화여, 전체 시스템 문제를 더 쉽게 분석할 수 있도록 도와줍니다. *ELK Stack1: Elastic Search. Logstash, Kibana의 약자로 데이터를 수집하고 분석하는 도구 모음 Tracing 트레이싱은 애플리케이션 실행 정보를 기록하는 '특별한 로깅' 방식을 의미합니다. 사실 로깅과 트레이싱을 구분하는 것에 큰 의미는 없습니다. 하지만 Observability 관점에서 트레이싱은, 전체 로그 중 문제를 일으키는 특정 로그들을 시각화하고 이를 선택적으로 관찰하는데 의미가 있습니다. Debugging Observability에서 말하는 디버깅은, 시스템과 서비스 성능을 확인하고 검사할 수 있는 다양한 도구입니다. 장애 원인을 찾을 경우 그 장애 원인뿐만 아니라, 연관관계를 가진 여러 인프라와 애플리케이션을 함께 보여줄 수 있어야 하죠. RUM RUM은 Real User Monitoring 약자로, 사용자의 인터랙션을 추적하여 웹사이트나 애플리케이션 성능을 실시간으로 모니터링하는 기술입니다. 옵저버빌리티는 앞서 언급했듯, 더 이상 IT 인프라 운영자를 위한 도구가 아닙니다. DevOps를 위한 통합적인 가시성을 제공하는 도구이죠. 따라서 운영자와 개발자를 위한 '실제 사용자 관점'에서 모니터링을 제공해야 합니다. 이처럼 옵저버빌리티 시스템은 애플리케이션의 전체적인 상태를 깊이 있게 파악하고, 문제 원인을 분석하는 데 중점을 두는 접근 방식입니다. 그렇다면 애플리케이션 성능 관리 시스템인 APM 도구와는 어떤 차이점이 있을까요? │APM과 Observability 차이점 어떻게 보면 APM과 Observability는 비슷해 보이지만, 문제 원인과 인프라를 분석하는 시각에 따라서 다양한 차이점을 지니고 있습니다. 우선 첫 번째 차이점으로는 모니터링 목적 대상에 따른 차이가 있습니다. APM은 E2E(End-to-End) 성능 구간에 주목합니다. WEB-WAS-DB에 걸친 이 과정을 실제 서비스 사용자의 *액티브 서비스2에 초점을 맞춰, 애플리케이션 성능을 분석하고 모니터링하죠. *액티브 서비스: 현재 시점에서 사용자에게 제공되고 있는 상태 Observability는 APM에서 주목하는 E2E보다, 더 많은 범위를 모니터링합니다. 시스템 인프라, WAS, DB에 대한 정밀 성능 분석과 장애 감지는 물론. 운영 중인 인프라와 서비스를 통합하여 문제 원인을 찾는 데 집중합니다. [그림] Zenius-APM 사용자 정의 실시간 모니터링 상황판 따라서 두 번째 차이점으로는, 측정하는 지표에도 많은 차이가 있는데요. APM은 사용자 요청에 따른 응답 시간과 응답 분포, 액티브 서비스 상태, 트랜잭션 처리율, 이슈 중심으로 '사용자 요청' 관점에 따라 주요 지표를 확인할 수 있습니다. Observability는 사용자의 요청 관점이 아닌, 발생할 수 있는 '모든 이벤트 지표'에 주목합니다. 보다 더 전방위적인 모니터링이 가능하죠. 또한 옵저버빌리티는 기존 APM에서 발생하는 주요 장애 원인뿐 아니라, 예측하지 못한 장애를 객관적인 지표로 보여줍니다. 정리한다면 인프라와 서비스를 분석하고 장애를 탐지한다는 점에서 APM과 Observability는 동일한 역할을 갖지만, 결국 사용자가 무엇을 더 초점에 맞추느냐에 따라 사용 목적은 아래와 같이 달라질 수 있습니다. 우리 기업은 Observability가 맞을까, APM가 맞을까? APM Type Observability Type 애플리케이션 성능 최적화가 필요한 경우 애플리케이션 코드 내의 문제를 식별하고 해결하는 데 중점을 둘 경우 MSA 환경이 아닌 모놀리식 아키텍처에서 서비스를 구성하고 있는 경우 MSA 환경에서의 분산 시스템을 통해 서비스를 구성하는 경우 단순한 애플리케이션 성능을 넘어 전체 IT 인프라 환경에 대한 통찰력 확보가 필요한 경우 인프라 운영자, 개발자, 보안담당자 모두가 통합 모니터링 환경이 필요한 경우 이번 글에서는 옵저버빌리티의 중요성과 APM의 차이점을 자세히 살펴보았습니다. 결론적으로 옵저버빌리티와 APM 중 어느 하나를 더 좋다고 할 수 없으며, 각 조직의 요구사항과 사용 편의성에 맞춰 선택해야 합니다. 그러나 점점 복잡해지는 IT 환경을 고려한다면, 옵저버빌리티를 기반으로 한 Zenius-APM과 같은 도구를 활용하여 좀 더 효율적으로 웹 애플리케이션을 관리해 보는 것은 어떨까요? ?더보기 Zenius APM 더 자세히 보기 ?함께 읽으면 더 좋아요 • APM에서 꼭 관리해야 할 주요 지표는?! • APM의 핵심요소와 주요기능은?! 2024.07.24
기술이야기 EMS, NPM, AIOps까지! NMS의 진화 자세히 보기 기술이야기 EMS, NPM, AIOps까지! NMS의 진화 자세히 보기 앞선 글들을 통해서 NMS의 기본 개념, 구성요소와 기능, 정보 수집 프로토콜에 대해서 알아봤었는데요. 이번 글에서는 NMS의 역사와 진화 과정, 그리고 최근 트렌드에 대해서 자세히 알아보겠습니다. EMS, NPM, 그리고 AIOps에 이르기까지 네트워크의 빠른 변화에 발맞추어 진화하고 있는 NMS에 대해서 하나씩 하나씩 살펴보겠습니다. ㅣNMS의 역사와 진화 과정 우선 NMS의 전반적인 역사와 진화 과정을 살펴보겠습니다. [1] 초기 단계 (1980년대 이전) 초기에는 네트워크 관리가 수동적이었습니다. 네트워크 운영자들은 네트워크를 모니터링하고 문제를 해결하기 위해 로그 파일을 수동으로 분석하고 감독했습니다. [2] SNMP의 등장 (1988년) SNMP(Simple Network Management Protocol)의 등장으로 네트워크 장비에서 데이터를 수집하고 이를 중앙 집중식으로 관리하는 표준 프로토콜을 통해 네트워크 관리자들이 네트워크 장비의 상태를 실시간으로 모니터링하고 제어할 수 있게 됐습니다. [3] 네트워크 관리 플랫폼의 출현 (1990년대 중후반) 1990년대 후반부에는 상용 및 오픈 소스 기반의 통합된 네트워크 관리 플랫폼이 등장했습니다. 이러한 플랫폼들은 다양한 네트워크 장비와 프로토콜을 지원하고, 시각화된 대시보드와 경고 기능 등을 제공하여 네트워크 관리의 편의성을 높였습니다. [4] 웹 기반 NMS (2000년대 중반) 2000년대 중반에는 웹 기반의 NMS가 등장했습니다. 이러한 시스템은 사용자 친화적인 웹 인터페이스를 통해 네트워크 상태를 모니터링하고 관리할 수 있게 했습니다. [5] 클라우드 기반 NMS (2010년대 이후) 최근 몇 년간 클라우드 기반 NMS의 등장으로 네트워크 관리의 패러다임이 변화하고 있습니다. 또한 빅데이터 기술과 인공지능(AI) 기술을 활용하여 네트워크 성능을 최적화하고, 향후 성능을 예측할 수 있는 성능 예측 기능까지 NMS에서 제공하고 있습니다. ㅣNMS에서 EMS로의 진화 네트워크 환경은 빠르게 변화하게 되고, 이에 따라서 NMS도 EMS로 진화하게 됩니다. NMS의 진화는 총 세 가지 세대로 나눌 수 있습니다. 1세대: 디바이스 관리 시스템 기존의 NMS는 외산 제조사에서 제공하는 전용 네트워크 솔루션이 주를 이루었습니다. CISCO의 시스코웍스(CiscoWorks), IBM의 넷뷰(NetView) HP의 네트워크 노드 매니저(Network Node Manager) 등 다양한 벤더들이 자사의 제품에 대한 모니터링 서비스를 제공하기 위해 특화된 디바이스 관리 솔루션을 내놓았죠. HP Network Node Manager 예시 화면(출처ⓒ omgfreeet.live) 물론 자사의 제품을 관리하기 위한 목적에서 출발한 솔루션이었기에, 대규모 이기종 IT 인프라 환경에 대한 모니터링 기능은 제공하지 못했습니다. 2세대: IT 인프라 관리 시스템 EMS의 등장 1세대의 NMS의 경우 빠르게 급변하는 네트워크 트렌드를 따라갈 수 없었습니다. 가상랜(VLAN), 클라이언트-서버 기술이 발달하게 되자, IP 네트워크 관계만으로 실제 토폴로지를 파악하기 어려웠습니다. 또한 네트워크장비 및 회선의 상태뿐 아니라, 서버 등의 이기종 IT 인프라 통합 모니터링에 대한 니즈와 함께 EMS(Enterprise Management System)의 시대가 시작됩니다. 이에 따라 서비스 관리 차원의 통합 관제 서비스가 등장합니다. 기존의 네트워크 모니터링뿐 아니라 서버, DBMS, WAS 등 IT 서비스를 이루고 있는 모든 인프라들에 대한 통합 모니터링에 대한 관심과 니즈가 증가했기 때문입니다. 3세대: 클라우드 네이티브 환경의 EMS 2010년 중 이후 서버, 네트워크 등 IT 인프라에 대한 클라우드 네이티브로의 전환이 가속화되었습니다. 기존의 레거시 환경에 대한 모니터링과 함께 퍼블릭, 프라이빗 클라우드에 대한 모니터링 니즈가 증가하면서 모든 환경에 대한 통합적인 가시성을 제공해 줄 수 있는 EMS가 필요하게 되었죠. 이외에도 AI의 발전을 통해 AIOps, Observability라는 이름으로 인프라에 대한 장애를 사전적으로 예측할 수 있는 기능이 필요하게 됐습니다. ㅣ네트워크 환경 변화(가상화)와 NMS의 변화 이번에는 네트워크 환경 변화에 따른 NMS의 변화에 대해서 알아보겠습니다. 네트워크 환경 변화(네트워크 가상화) 네트워크 구성 방식은 지속적으로 변화해왔습니다. 클라이언트-서버 모델부터 중앙 집중식 네트워크, MSA 환경에서의 네트워크 구성까지 이러한 변화는 기술 발전, 비즈니스 요구 사항, 보안 요구 사항 등 다양한 요인에 의해 영향을 받았는데요. 무엇보다 가장 중요한 변화는 전통적인 온 프레미스 네트워크 구조에서 네트워크 자원이 더 이상 물리적인 장비 기반의 구성이 아닌 가상화 환경에서 구성된다는 점입니다. ▪소프트웨어 정의 네트워킹(SDN, 2000년대 후반 - 현재): 네트워크 관리와 제어를 분리하고 소프트웨어로 정의하여 유연성과 자동화를 향상시키는 접근 방식입니다. SDN은 네트워크 관리의 복잡성을 줄이고 가상화, 클라우드 컴퓨팅 및 컨테이너화와 같은 새로운 기술의 통합을 촉진시켰습니다. ▪네트워크 가상화 (NFV, 현재): 기존 하드웨어 기반 전용 장비에서 수행되던 네트워크 기능을 소프트웨어로 가상화하여 하드웨어 의존성과 장비 벤더에 대한 종속성을 배제하고, 네트워크 오케스트레이션을 통해 네트워크 환경 변화에 민첩한 대응을 가능하게 합니다. ㅣ클라우드, AI 등의 등장에 따른 NMS의 방향 클라우드 네이티브가 가속화되고, AI를 통한 인프라 관리가 주요 화두로 급부상하면서 네트워크 구성과 이를 모니터링하는 NMS의 환경 역시 급변하고 있습니다. 클라우드 내의 네트워크: VPC VPC(Virtual Private Cloud)는 퍼블릭 클라우드 환경에서 사용할 수 있는 전용 사설 네트워크입니다. VPC 개념에 앞서 VPN에 대한 개념을 단단히 잡고 넘어가야 합니다. VPN(Virtual Private Network)은 가상사설망으로 '가상'이라는 단어에서 유추할 수 있듯이 실제 사설망이 아닌 가상의 사설망입니다. VPN을 통해 하나의 네트워크를 가상의 망으로 분리하여, 논리적으로 다른 네트워크인 것처럼 구성할 수 있습니다. VPC도 이와 마찬가지로 클라우드 환경을 퍼블릭과 프라이빗의 논리적인 독립된 네트워크 영역으로 분리할 수 있게 해줍니다. VPC가 등장한 후 클라우드 내에 있는 여러 리소스를 격리할 수 있게 되었는데요. 예를 들어 'IP 주소 간에는 중첩되는 부분이 없었는지', '클라우드 내에 네트워크 분리 방안' 등 다양한 문제들을 VPC를 통해 해결할 수 있었습니다. ▪서브넷(Subnet): 서브넷은 서브 네트워크(Subnetwork)의 줄임말로 IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위망을 말합니다. AWS, Azure, KT클라우드, NHN 등 다양한 퍼블릭 클라우드의 VPC 서브넷을 통해 네트워크를 분리할 수 있습니다. ▪서브넷은 크게 퍼블릿 서브넷과 프라이빗 서브넷으로 나눌 수 있습니다. 말 그대로 외부 인터넷 구간과 직접적으로 통신할 수 있는 공공, 폐쇄적인 네트워크 망입니다. VPC를 이용하면 Public subnet, Private subnet, VPN only subnet 등 필요에 따라 다양한 서브넷을 생성할 수 있습니다. ▪가상 라우터와 라우트 테이블(routing table): VPC를 통해 가상의 라우터와 라우트 테이블이 생성됩니다. NPM(Network Performance Monitoring) 네트워크 퍼포먼스 모니터링(NPM)은 전통적인 네트워크 모니터링을 넘어 사용자가 경험하는 네트워크 서비스 품질을 측정, 진단, 최적화하는 프로세스입니다. NPM 솔루션은 다양한 유형의 네트워크 데이터(ex: packet, flow, metric, test result)를 결합하여 네트워크의 성능과 가용성, 그리고 사용자의 비즈니스와 연관된 네트워크 지표들을 분석합니다. 단순하게 네트워크 성능 데이터(Packet, SNMP, Flow 등)를 수집하는 수동적인 과거의 네트워크 모니터링과는 다릅니다. 우선 NPM은 네트워크 테스트(Synthetic test)를 통해 수집한 데이터까지 활용하여, 실제 네트워크 사용자가 경험하는 네트워킹 서비스 품질을 높이는데 그 목적이 있습니다. NPM 솔루션은 NPMD라는 이름으로 불리기도 합니다. Gartner는 네트워크 성능 모니터링 시장을 NPMD 시장으로 명명하고 다양한 데이터를 조합하여 활용하는 솔루션이라고 정의했습니다. 즉 기존의 ICMP, SNMP 활용 및 Flow 데이터 활용과 패킷 캡처(PCAP), 퍼블릭 클라우드에서 제공하는 네트워크 데이터 활용까지 모든 네트워크 데이터를 조합하는 것이 핵심이라 할 수 있습니다. AIOps: AI를 활용한 네트워크 모니터링 AI 모델을 활용한 IT 운영을 'AIOps'라고 부릅니다. 2014년 Gartner를 통해 처음으로 등장한 이 단어는 IT 인프라 운영에 머신러닝, 빅데이터 등 AI 모델을 활용하여 리소스 관리 및 성능에 대한 예측 관리를 실현하는 것을 말합니다. 가트너에서는 AIOps에 대한 이해를 위해 관제 서비스, 운영, 자동화라는 세 가지 영역으로 분류해서 설명하고 있습니다. ▪관제(Observe): AIOps는 장애 이벤트가 발생할 때 분석에 필요한 로그, 성능 메트릭 정보 및 기타 데이터를 자동으로 수집하여 모든 데이터를 통합하고 패턴을 식별할 수 있는 관제 단계가 필요합니다. ▪운영(Engine): 수집된 데이터를 분석하여 장애의 근본 원인을 판단하고 진단하는 단계로, 장애 해결을 위해 상황에 맞는 정보를 IT 운영 담당자에게 전달하여 반복적인 장애에 대한 조치 방안을 자동화하는 과정입니다. ▪자동화(Automation): 장애 발생 시 적절한 해결책을 제시하고 정상 복구할 수 있는 방안을 제시하여, 유사 상황에도 AIOps가 자동으로 조치할 수 있는 방안을 마련하는 단계입니다. 위의 세 단계를 거쳐 AIOps를 적용하면 IT 운영을 사전 예방의 성격으로 사용자가 이용하는 서비스, 애플리케이션, 그리고 인프라까지 전 구간의 사전 예방적 모니터링을 가능하게 합니다. 또한 구축한 데이터를 기반으로 AI 알고리즘 및 머신 러닝을 활용하여 그 어떠한 장애에 대한 신속한 조치와 대응도 자동으로 가능하게 합니다. Zenius를 통한 클라우드 네트워크 모니터링 참고로 Zenius를 통해 각 퍼블릭 클라우드 별 VPC 모니터링이 가능합니다. VPC의 상태 정보와 라우팅 테이블, 서브넷 목록 및 서브넷 별 상세 정보 (Subnet ID, Available IP, Availability Zone 등)에 대한 모니터링 할 수 있습니다. Zenius-CMS를 통한 AWS VPC 모니터링 이외에도 각 클라우드 서비스에 대한 상세 모니터링을 통해 클라우드 모니터링 및 온 프레미스를 하나의 화면에서 모니터링하실 수 있습니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼, 네트워크의 변화에 따라서 NMS는 계속해서 진화하고 있습니다. 현재의 네트워크 환경과 변화할 환경을 모두 완벽하게 관리할 수 있는 NMS 솔루션을 통해 안정적으로 서비스를 운영하시기 바랍니다. 2024.04.03
기술이야기 서버 모니터링의 두 가지 방식 기술이야기 서버 모니터링의 두 가지 방식 이번 블로그에서는 일반적으로 서버 모니터링 소프트웨어들이 널리 쓰고 있는 서버 모니터링의 두 가지 방식에 대해서 논의하고 그 차이점을 알아보겠습니다. 지난 블로그에서 언급했듯이, 서버 모니터링은 컴퓨터 서버의 성능을 관찰하고 분석해 최적의 상태로 실행되고 있는지 확인하는 작업입니다. 이 프로세스에는 일반적으로 CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 및 응용 프로그램 성능과 같은 다양한 메트릭에 대한 데이터를 수집하는 소프트웨어 도구의 사용이 포함됩니다. 서버 모니터링 소프트웨어는 데이터 수집 후 추세, 패턴 및 이상 현상을 식별하기 위해 데이터를 분석합니다. 분석을 통해 잠재적인 문제가 심각해지기 전에 식별하고 서버 관리자가 시정 조치를 취할 수 있도록 합니다. 예를 들어, CPU 사용률이 지속적으로 높은 경우 서버의 성능이 부족해 더 많은 리소스를 할당해야 할 수 있음을 나타낼 수 있습니다. 또는 디스크 I/O가 느린 경우 서버의 저장소가 과부하됐거나 최적화가 필요함을 나타낼 수 있습니다. 서버 모니터링 소프트웨어에는 관리자가 서버 성능을 파악하는데 도움이 되는 대시보드, 경고 및 보고 기능이 포함되는 경우가 많습니다. 대시보드는 핵심 성과 지표의 실시간 보기를 제공하는 동시에 특정 임계값을 초과하거나 문제가 감지되면 관리자에게 알림을 보냅니다. 서버 관리자는 보고 기능을 통해 시간 경과에 따른 성능 추세 및 문제에 대한 보고서를 생성할 수 있으며, 이를 통해 용량 계획 및 리소스 할당 결정을 알리는데 사용할 수 있습니다. 서버 모니터링은 일반적으로 에이전트 없는 서버 모니터링과 에이전트 기반 서버 모니터링, 이 두 가지 주요 접근 방식이 있습니다. 두 가지 모두 장단점이 있으며 어떤 것을 선택하느냐는 특정 요구 사항과 선호도에 따라 달라집니다. 에이전트 기반 서버 모니터링 에이전트 기반 서버 모니터링에는 모니터링하려는 각 서버에 ‘에이전트’라고 하는 별도의 서버용 모니터링 소프트웨어를 설치해 데이터를 수집하는 방식을 말합니다. 에이전트는 서버에서 다양한 성능 메트릭에 대한 데이터를 수집해 모니터링 시스템으로 다시 보냅니다. 이 접근 방식은 에이전트 없는 모니터링보다 더 상세하고 세분화된 데이터와 기능을 제공합니다. 또, 데이터를 암호화하고 보안 채널을 사용해 데이터를 전송하므로 일반적으로 에이전트 없는 모니터링보다 더 안전합니다. 에이전트 기반 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 성능 모니터링: 에이전트는 CPU, 메모리, 디스크 사용률, 네트워크 트래픽 등의 정보를 수집할 수 있습니다. 이를 이용해 서버의 성능을 모니터링하고, 부하가 높아지면 적시에 대처할 수 있습니다. ∙ 로그 모니터링: 에이전트는 서버에서 발생하는 로그를 수집할 수 있습니다. 이를 이용해 서버에서 발생한 이벤트의 원인 파악에 도움을 줄 수 있습니다. ∙ 보안 모니터링: 에이전트는 서버 내부의 보안 상태를 모니터링할 수 있습니다. 예를 들어, 악성 코드 감지, 사용자 로그인 상태, 파일 권한 등을 체크해 보안 위협을 조기에 감지할 수 있습니다. ∙ 애플리케이션 모니터링: 에이전트는 서버에 설치된 애플리케이션의 상태를 모니터링할 수 있습니다. 예를 들어, 웹 서버에서는 HTTP 요청, 응답 코드, 응답 속도 등을 모니터링해 애플리케이션의 상태를 파악할 수 있습니다. ∙ 자동화된 조치: 에이전트는 모니터링 데이터를 기반으로 자동화된 조치를 수행할 수 있습니다. 예를 들면, CPU 부하가 높아지면 자동으로 스케일 업 또는 스케일 아웃을 수행할 수 있습니다. 에이전트 리스 서버 모니터링 에이전트가 없는 서버 모니터링은 서버 자체에 소프트웨어를 설치할 필요가 없습니다. 대신 모니터링 소프트웨어가 별도의 서버나 워크스테이션에 설치되고, SNMP 또는 WMI와 같은 네트워크 프로토콜을 사용해 대상 서버에서 데이터를 원격으로 수집합니다. 이 접근 방식은 각 서버에 소프트웨어 에이전트를 설치하고 관리할 필요가 없어 일반적으로 설정 및 유지 관리가 더 쉽고 빠릅니다. 또, 에이전트 기반보다 같은 자원을 이용해서 더 많은 수의 서버를 모니터링할 수 있어 경제적입니다. 대신 기능이 제한적이고 프로토콜이 의존해 데이터를 수집하기 때문에 보안 문제가 발생할 수 있습니다. 에이전트 리스 서버 모니터링의 주요 기능은 다음과 같습니다. ∙ 원격 모니터링: 에이전트 없는 모니터링 도구는 원격 데이터 센터, 지사 또는 클라우드 환경에 있는 서버를 포함해 모든 곳에 있는 서버를 원격으로 모니터링할 수 있습니다. 이러한 유연성을 통해 조직의 전체 서버 인프라를 중앙집중식으로 모니터링하고 관리할 수 있습니다. ∙ 확장성: 에이전트 없는 모니터링은 서버 인프라 또는 워크로드 요구사항의 변화를 수용하기 위해 쉽게 확장 또는 축소할 수 있습니다. 추가 에이전트 소프트웨어 설치 또는 구성 없이 모니터링 시스템에 추가 서버를 추가할 수 있습니다. ∙ 포괄적인 모니터링: 에이전트 없는 모니터링은 서버 성능 메트릭을 추적하고 문제를 식별하며, 실시간 경고를 제공함으로써 관리자가 서버 인프라의 상태를 유지하고 중요한 애플리케이션과 서비스가 원활하게 실행되도록 합니다. ∙ 손쉬운 유지 관리 및 업데이트: 에이전트 없는 모니터링을 사용하면 모니터링 되는 각 시스템에서 에이전트 소프트웨어를 관리하고 업데이트할 필요가 없습니다. 이는 유지보수를 단순화하고 모니터링 시스템을 항상 최신 상태로 유지합니다. Zenius(제니우스)의 서버 모니터링 브레인즈컴퍼니의 지능형 IT 인프라 통합관리 소프트웨어 ‘Zenius(제니우스)’는 고객의 시스템 상황에 따라 에이전트 기반 및 리스 방식 모두 가능합니다. 에이전트 기반의 통합 모니터링 소프트웨어 ‘Zenius SMS’는 HTML5 기반 Web UI와 토폴로지 맵을 통해 서버 성능과 상태 및 서버 간 연관관계를 직관적으로 파악합니다. 특히, Zenius SMS는 애플리케이션 단위에 성능이나 로그를 세밀하게 모니터링 및 분석이 가능합니다. Zenius SMS의 주요 기능은 아래와 같습니다. Zenius SMS의 주요 서버 모니터링 기능 1. 프로세스: 프로세스 상태(Up/Down) 및 성능 모니터링(CPU/MEM) 2. 로그: 프로세스나 시스템 로그와 같은 각종 로그 모니터링 3. GPU: GPU의 상태 및 성능 모니터링 4. 보안: 서버의 보안 취약점 점검 5. 자동화: 모니터링 데이터를 기반으로 자동화된 조치 수행 6. 기타: 코어별 온도 모니터링, 서비스 포트별 네트워크 상태, S/W 목록, 환경변수, 계정, 그룹, 스케쥴링, 공유폴더 현황 등 ‘Zenius SMS’ 도입을 통해 체계화된 서버 통합관리를 할 수 있습니다. 반복적이고 수동적인 업무는 자동화돼 업무 효율성을 향상시키며, 객관적인 데이터를 기반으로 정확한 성능 현황 및 비교분석이 가능합니다. 이는 곧 서비스 연속성 확보로 이어지며, 향후 고객 만족도 향상을 기대할 수 있습니다. 반면, 고객 서버에 에이전트 탑재가 불가능한 경우에는 에이전트 리스 방식으로도 사용 가능합니다. 브레인즈컴퍼니의 에이전트 리스 제품으로는 ‘Zenius VMS’가 있습니다. ‘Zenius VMS’는 VMware, Citrix Xen Server, Hyper-V와 같은 서버 가상화 환경에서 호스트 서버와 게스트 서버의 리소스 할당 및 사용 현황, 관계 등을 통합적으로 관제합니다. ‘Zenius VMS’는 프라이빗 클라우드 환경을 모니터링하는데 효과적입니다. Open API로 프라이빗 클라우드 인프라와 통신해, 가상머신의 상태 및 성능, 스토리지 활용도 및 네트워크 트래픽과 같은 환경의 다양한 측면에 대한 데이터를 수집합니다. 수집된 데이터를 분석해 잠재적 문제를 나타낼 수 있는 경향, 패턴 및 이상 현상을 식별하고, 크게 CPU, 메모리, 디스크, MIB 이 4가지 정보를 기본적으로 제공합니다. ‘Zenius VMS’는 VM 상세 관리를 위해 SMS 추가 확장이 용이한 제품입니다. VMS를 통해 호스트-게스트 간 연관관계 기반의 모니터링을 시행하고, 별도로 가상화 서버에 SMS 모듈을 추가해 보다 다양한 모니터링 항목으로 정밀하게 관리함으로써 효과적인 통합관리 환경을 조성할 수 있습니다. 2023.05.09
기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다. 2023.04.19
기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 지난 블로그에서는 옵저버빌리티가 기존 모니터링과 어떻게 다른지 비교해봤습니다. 간략히 되짚어보면, 옵저버빌리티란 IT 환경이 다양해지고 기업의 서비스가 점점 복잡해짐에 따라 빠르게 문제를 찾아 해결하기 위해 서비스의 내부 상태와 동작을 이해하는 능력입니다. 옵저버빌리티는 IT 인프라별로 어떤 것이 문제라는 기준을 중심으로 모니터링하는 기존 방식에서 벗어나 모든 데이터를 실시간으로 수집하고 분석하여 IT시스템의 근본 원인에 접근하고, IT 운영 전문가의 노하우를 바탕으로 각 메트릭별 상관관계를 분석해 미래의 장애를 예측하는 인사이트를 강조합니다. 이번 블로그에서는 옵저버빌리티 확보에 가장 기본이자 중요한 정보 소스인 로깅, 메트릭, 트레이싱을 중심으로 알아보겠습니다. 이 세가지 소스는 시스템의 정확한 모니터링을 보장하고, 문제가 발생할 때 무엇이 잘못됐는지 근본원인을 추적하고, 전체 기능을 개선하는 데 도움이 되는 방법들입니다. 물론 이 세가지 방법만으로 옵저버빌리티가 확보됐다고 할 수는 없습니다. 옵저버빌리티 확보를 위해서는 로깅, 메트릭, 트레이싱을 통합해 이벤트의 상관관계를 분석하고, 데이터 시각화로 사용자에게 인사이트를 제공하는 능력이 추가돼야 합니다. l Logging : 시스템 내에서 발생하는 이벤트를 인지하고 향후 분석을 위해 저장하는 프로세스 l Metric : 응답 시간 또는 오류율과 같은 시스템 성능을 설명하는 숫자 값 l Tracing: 개발자가 병목 현상과 성능 문제를 식별할 수 있도록 서비스 호출 경로와 시간을 추적하는 프로세스 Logging 로깅은 로그를 남기는 것으로 로그를 수집하고, 저장하는 프로세스입니다. 로깅은 시스템 동작을 이해하고 문제를 진단하는 데 필요한 것으로, 향후 분석을 위해 저장하는 데이터인 만큼 올바른 세부 기준에 따라 의미가 있는 로그를 추출하는 것이 필요합니다. 그리고 예를 들어 웹 애플리케이션에 문제가 발생한 경우 로그를 남기는데, 메트릭을 통해서는 이 문제를 발견할 수 없으므로 그래서 로그는 중요합니다. 로그의 수집은 간단한 텍스트 파일에서 ELK(Elasticsearch, Logstash, Kibana)처럼 정교한 프레임워크에 이르기까지 다양한 형태를 취할 수 있습니다. 그래서 로그는 정형화하기 어렵고 그 양이 방대함으로 로그를 수집, 저장하고 분석할 때 다음과 같은 사항을 유의해야 합니다. l 과도한 로깅은 스토리지 비용을 증가시키고 로그의 검색 효율을 떨어뜨릴 수 있습니다. 따라서 어떤 데이터를 기록하고, 어떤 데이터를 기록하지 않을지 필터링하는 것이 중요합니다. l 장기간 보관할 필요가 없는 로그 효율적인 로깅 시스템을 위한 로그 보관 정책이 필요합니다. l 로그에는 인사이트를 제공할 수 있는 모든 컨텍스트 정보가 포함돼야 합니다. l 로깅은 다른 프로세스에 영향을 미치지 않도록 비동기 방식이어야 합니다. l 민감한 데이터가 로그에 남겨지지 않도록 마스킹을 해야 합니다. 그럼 로그 분석을 통해 알 수 있는 정보는 무엇이 있을까요? l 시스템의 상태: 로그에는 어떤 액션을 수행했는지, 어떤 데이터가 처리됐는지, 또 어떤 오류가 발생했는지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 시스템의 상태를 파악할 수 있습니다. l 이슈 파악: 로그에는 어떤 오류가 발생했고, 어떤 요청이 실패했는지, 어떤 리소스가 부족한지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 이슈를 파악하고, 빠르게 대응할 수 있습니다. l 보안성 강화: 로그에는 로그인 시도, 권한 부여, 보안 이벤트 발생 등의 정보가 담겨 있으므로 이러한 정보를 분석해 보안 이슈를 파악하고, 보안성을 강화할 수 있습니다. Metric 로그가 텍스트라면 메트릭은 단순한 수치입니다. 메트릭은 시스템의 상태를 측정하고, 모니터링하는데 사용되는 숫자 측정값입니다. 조금 더 자세히 설명하면, 메트릭은 측정 항목을 정의하고 해당 항목을 수치로 측정해, 그 결과를 보고하고 시스템이 정상적으로 동작하는지 확인하거나 장애를 빠르게 감지하기 위한 소스입니다. 메트릭의 측정 대상은 CPU 사용률, 메모리 사용률, 네트워크 트래픽 등 인프라의 성능이나 초당 수신하는 요청수, 응답에 걸린 시간, 사용자에게 오류를 다시 보낸 응답 수 등 애플리케이션의 상태와 관련돼 있습니다. 메트릭을 통한 수집 가능한 범위는 모니터링 도구 사용 여부에 따라 달라집니다. 일반적인 방식은 에이전트를 이용해 모니터링 대상으로부터 데이터를 수집하는 것으로, 수집할 메트릭을 정의하기가 유연하고 성능이나 안정성 등의 이슈에 대한 정보도 수집할 수 있는 장점이 있습니다. 에이전트를 사용하지 않고 운영 체제나 애플리케이션에서 제공하는 메트릭 수집 API를 사용하는 방식도 있는데, 수집하는 메트릭이 비교적 제한적입니다. 단순히 메트릭을 수집하는 것만으로 시스템을 모니터링하기에 충분하지 않습니다. 메트릭 데이터를 잘 활용하기 위해서는 분석 방법이 중요한데, 분석을 위해서는 몇가지 단계를 거쳐야 합니다. l 먼저, 데이터를 시각화하여 쉽게 이해할 수 있는 형태로 변환해야 합니다. 차트나 그래프, 대시보드 등을 통해 데이터의 패턴과 추세를 파악할 수 있으며, 시스템의 상태를 실시간으로 모니터링할 수 있습니다. l 다음으로, 데이터를 분석하여 시스템의 문제를 식별합니다. 예를 들어, 응답 시간이 지연되는 경우, 이를 발생시키는 주요 요인을 파악하여 시스템을 개선해야 합니다. 이를 위해 데이터를 세분화하여 요소를 파악하고, 문제를 식별하는 데 도움이 되는 경향성을 찾아야 합니다. l 마지막으로 이전 데이터와 비교하고 평가에 활용합니다. Metric 데이터를 분석할 때는 이전 데이터와 비교하여 시스템의 개선 정도를 파악하는 것이 중요하고, 이를 통해 시스템의 성능 개선 여부를 판단하고, 추가적인 개선 방안을 모색할 수 있습니다. Tracing 트레이싱은 분산 시스템에서의 서비스 호출 경로와 시간을 추적하는 기술입니다. 즉, 서비스 간의 호출 관계와 시간 정보를 추적해 각 서비스의 응답 시간을 파악하고, 이를 시각화해 병목 현상을 파악할 수 있습니다. 트레이싱은 크게 세 가지 구성 요소로 이뤄져 있습니다. l Trace: Trace는 서비스 간의 호출 경로와 시간 정보를 담고 있는 데이터 레코드입니다. Trace는 Span과 Trace ID, Parent Span ID 등의 정보를 가지며, 각 Span은 서비스 내부에서의 호출 관계와 시간 정보를 담고 있습니다. l Span: 분산 추적에서 가장 기본이 되는 논리 단위로 여러 개의 span 이 모여 trace를 완성한다는 개념입니다. 각각의 Span은 작업이름, 시작 시간과 종료 시간, key value 형태의 tags 와 Logs, span contexts를 가지고 있습니다. Span contexts는 분산추적을 하기위해 Trace 구간에서 종속된 Span을 구별할 수 있는 Span id와 Trace id를 말합니다. l Collector: Collector는 Trace 정보를 수집하고 저장하는 역할로, Trace 정보를 수집하기 위한 에이전트와 수집된 Trace 정보를 저장하고 분석하기 위한 Backend로 이뤄져 있습니다. (출처: [MSA] OpenTracing, 분산추적(Distributed Tracing) 과 Span context, KSR의 저장소) 이렇게 옵저버빌리티를 구현하기 위한 로깅, 매트릭, 트레이싱 등 세 가지의 중요한 정보 소스들을 다루기 위해서는 여러가지 기술들이 조합되어야 합니다. 다음 블로그에서는 그와 같은 정보 소스들을 다루어 옵저버빌리티를 구현하기 위해서 널리 사용되는 대표적인 오픈 소스들을 알아보고 Zenius-EMS에서는 옵저버빌리티 향상을 위해서 어떤 기능들을 제공하고 있는지 살펴보겠습니다. 2023.04.19

1 2