반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
카프카를 통한 로그 관리 방법
메모리 누수 위험있는 FinalReference 참조 분석하기
김진광
2023.10.12
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 ‘가을문화행사 2023’
Java에서 가장 많이 접하는 문제는 무엇이라 생각하시나요? 바로 리소스 부족 특히 ‘JVM(Java Virtual Machine) 메모리 부족 오류’가 아닐까 생각해요.
메모리 부족 원인에는 우리가 일반적으로 자주 접하는 누수, 긴 생명주기, 다량의 데이터 처리 등 몇 가지 패턴들이 있는데요. 오늘은 좀 일반적이지 않은(?) 유형에 대해 이야기해 볼게요!
Java 객체 참조 시스템은 강력한 참조 외에도 4가지 참조를 구현해요. 바로 성능과 확장성 기타 고려사항에 대한 SoftReference, WeakReference, PhantomReference, FinalReference이죠. 이번 포스팅은
FinalReference를 대표적인 사례
로 다루어 볼게요.
PART1. 분석툴을 활용해 메모리 누수 발생 원인 파악하기
메모리 분석 도구를 통해 힙 덤프(Heap Dump)를 분석할 때, java.lang.ref.Finalizer 객체가 많은 메모리를 점유하는 경우가 있어요. 이 클래스는 FinalReference와 불가분의 관계에요. 나눌 수 없는 관계라는 의미죠.
아래 그림 사례는 힙 메모리(Heap Memory)의 지속적인 증가 후 최대 Heap에 근접 도달 시, 서비스 무응답 현상에 빠지는 분석 사례인데요. 이를 통해 FinalReference 참조가 메모리 누수를 발생시킬 수 있는 조건을 살펴볼게요!
Heap Analyzer 분석툴을 활용하여, 힙 덤프 전체 메모리 요약 현황을 볼게요. java.lang.ref.Finalizer의 점유율이 메모리의 대부분을 점유하고 있죠. 여기서 Finalizer는, 앞에서 언급된 FinalReference를 확장하여 구현한 클래스에요.
JVM은 GC(Garbage Collection) 실행 시 해제 대상 객체(Object)를 수집하기 전, Finalize를 처리해야 해요.
Java Object 클래스에는 아래 그림과 같이 Finalize 메서드(Method)가 존재하는데요. 모든 객체가 Finalize 대상은 아니에요.
JVM은 클래스 로드 시, Finalize 메서드가 재정의(Override)된 객체를 식별해요. 객체 생성 시에는 Finalizer.register() 메서드를 통해, 해당 객체를 참조하는 Finalizer 객체를 생성하죠.
그다음은 Unfinalized 체인(Chain)에 등록해요. 이러한 객체는 GC 발생 시 즉시 Heap에서 수집되진 않아요. Finalizer의 대기 큐(Queue)에 들어가 객체에 재정의된 Finalize 처리를 위해 대기(Pending) 상태에 놓여있죠.
위 그림과 같이 참조 트리(Tree)를 확인해 보면, 많은 Finalizer 객체가 체인처럼 연결되어 있어요. 그럼 Finalizer 객체가 실제 참조하고 있는 객체는 무엇인지 바로 살펴볼까요?
그림에 나온 바와 같이 PostgreSql JDBC Driver의 org.postgresql.jdbc3g.Jdbc3gPreparedStatement인 점을 확인할 수 있어요. 해당 시스템은 PostgreSql DB를 사용하고 있었네요.
이처럼 Finalizer 참조 객체 대부분은 Jdbc3gPreparedStatement 객체임을 알 수 있어요. 여기서 Statement 객체는, DB에 SQL Query를 실행하기 위한 객체에요.
그렇다면, 아직 Finalize 처리되지 않은 Statement 객체가 증가하는 이유는 무엇일까요?
먼저 해당 Statement 객체는 실제로 어디서 참조하는지 살펴볼게요. 해당 객체는 TimerThread가 참조하는 TaskQueue에 들어가 있어요. 해당 Timer는 Postgresql Driver의 CancelTimer이죠.
해당 Timer의 작업 큐를 확인해 보면 PostgreSql Statement 객체와 관련된 Task 객체도 알 수도 있어요.
그럼 org.postgresql.jdbc3g.Jdbc3gPreparedStatement 클래스가 어떻게 동작하는지 자세히 알아볼까요?
org.postgresql.jdbc3g.Jdbc3gPreparedStatement는 org.postgresql.jdbc2.AbstractJdbc2Statement의 상속 클래스이며 finalize() 메서드를 재정의한 클래스에요. Finalize 처리를 위해 객체 생성 시, JVM에 의해 Finalizer 체인으로 등록되죠.
위와 같은 코드로 보아 CancelTimer는, Query 실행 후 일정 시간이 지나면 자동으로 TimeOut 취소 처리를 위한 Timer에요.
정해진 시간 내에 정상적으로 Query가 수행되고 객체를 종료(Close) 시, Timer를 취소하도록 되어 있어요. 이때 취소된 Task는 상태 값만 변경되고, 실제로는 Timer의 큐에서 아직 사라지진 않아요.
Timer에 등록된 작업은, TimerThread에 의해 순차적으로 처리돼요. Task는 TimerThread에서 처리를 해야 비로소 큐에서 제거되거든요.
이때 가져온 Task는 취소 상태가 아니며, 처리 시간에 아직 도달하지 않은 경우 해당 Task의 실행 예정 시간까지 대기해야 돼요.
여기서 문제점이 발생해요.
이 대기 시간이 길어지면 TimerThread의 처리가 지연되기 때문이죠. 이후 대기 Task들은 상태 여부에 상관없이, 큐에 지속적으로 남아있게 돼요.
만약 오랜 시간 동안 처리가 진행되지 않는다면, 여러 번의 Minor GC 발생 후 참조 객체들은 영구 영역(Old Gen)으로 이동될 수 있어요.
영구 영역으로 이동된 객체는, 메모리에 즉시 제거되지 못하고 오랜 기간 남게 되죠. 이는 Old(Full) GC를 발생시켜 시스템 부하를 유발하게 해요. 실제로 시스템에 설정된 TimeOut 값은 3,000초(50분)에요.
Finalizer 참조 객체는 GC 발생 시, 즉시 메모리에서 수집되지 않고 Finalize 처리를 위한 대기 큐에 들어가요. 그다음 FinalizerThread에 의해 Finalize 처리 후 GC 발생 시 비로소 제거되죠. 때문에 리소스의 수집 처리가 지연될 수 있어요.
또한 FinalizerThread 스레드는 우선순위가 낮아요. Finalize 처리 객체가 많은 경우, CPU 리소스가 상대적으로 부족해지면 개체의 Finalize 메서드 실행을 지연하게 만들어요. 처리되지 못한 객체는 누적되게 만들죠.
요약한다면 FinalReference 참조 객체의 잘못된 관리는
1) 객체의 재 참조를 유발 2) 불필요한 객체의 누적을 유발 3) Finalize 처리 지연으로 인한 리소스 누적을 유발
하게 해요.
PART2.
제니우스 APM을 통해 Finalize 객체를 모니터링하는 방법
Zenius APM에서는 JVM 메모리를 모니터링하고 분석하기 위한, 다양한 데이터를 수집하고 있어요. 상단에서 보았던
FinalReference 참조 객체의 현황에 대한 항목도 확인
할 수 있죠.
APM 모니터링을 통해 Finalize 처리에 대한 문제 발생 가능성도
‘사전’
에 확인
할 수 있답니다!
위에 있는 그림은 Finalize 처리 대기(Pending)중인 객체의 개수를 확인 가능한 컴포넌트에요.
이외에도 영역별 메모리 현황 정보와 GC 처리 현황에 대해서도 다양한 정보를 확인 할 수 있어요!
이상으로 Finalize 처리 객체에 의한 리소스 문제 발생 가능성을, 사례를 통해 살펴봤어요. 서비스에 리소스 문제가 발생하고 있다면, 꼭 도움이 되었길 바라요!
------------------------------------------------------------
©참고 자료
◾ uxys, http://www.uxys.com/html/JavaKfjs/20200117/101590.html
◾ Peter Lawrey, 「is memory leak? why java.lang.ref.Finalizer eat so much memory」, stackoverflow, https://stackoverflow.com/questions/8355064/is-memory-leak-why-java-lang-ref-finalizer-eat-so-much-memory
◾ Florian Weimer, 「Performance issues with Java finalizersenyo」, enyo,
https://www.enyo.de/fw/notes/java-gc-finalizers.html
------------------------------------------------------------
#APM
#Finalize
#제니우스
#메모리 누수
#Zenius
#FinalReference
#제니우스 APM
김진광
APM팀(개발3그룹)
개발3그룹 APM팀에서 제품 개발과 기술 지원을 담당하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
브레인즈컴퍼니, NHN 클라우드와 진행한 [솔루션 설명회] 성료
브레인즈컴퍼니, NHN 클라우드와 진행한 [솔루션 설명회] 성료
브레인즈컴퍼니가 지난 17일 국내 대표적인 CSP(Cloud Service Provider)인 NHN 클라우드와 함께 [NHN 마켓 플레이스 솔루션 설명회]를 진행했습니다. 지난 4월 이후 두 번째로 열린 이번 행사 소식을 알아보겠습니다. │NHN 클라우드 솔루션 설명회는? NHN 클라우드는 자사의 마켓 플레이스 고객사에게 다양한 인사이트와 솔루션을 소개하기 위해 정기적으로 '솔루션 설명회'를 진행하고 있습니다. 브레인즈컴퍼니가 함께 진행한 이번 설명회에도 다수의 NHN 마켓 플레이스 고객사 및 IT 분야 관계자가 초청되었습니다. [그림] 발표 진행 중인 지혜님 웨비나로 진행된 이날 설명회에서 브레인즈컴퍼니는 '분산된 대용량 로그의 효율적인 관리 방안'이라는 제목의 발표를 맡았습니다. 발표는 '분산된 로그에 대한 통합 관리의 필요성-통합 관리 솔루션 소개-실제 고객 사례'의 순서로 신지혜 님이 진행했습니다. 대용량 로그 관리에 대한 다양한 인사이트와 구체적인 솔루션, 그리고 실제 적용 사례가 더해져서 참여자들의 많은 관심을 모았습니다. [그림] 솔루션 설명회 진행화면 지혜님은 이날 발표에서 "원활하게 IT 서비스와 인프라를 운영하고, 보안 위협에 빠르게 대응하는 것이 점점 더 중요해지고 있다. 따라서 로그 수집/저장/검색 및 시각화 기능을 제공하며, 이벤트 발생 시 즉각적인 알람을 통하여 빠른 문제 해결을 지원하는 로그 관리 솔루션 선택은 이제 필수"라고 말했습니다. 지혜님은 또한, "Zenius LogManager를 도입하게 되면 대용량 로그에 대한 통합 관리 체계와 사이버 침해 위협에 대한 보안 대응 체계를 마련할 수 있다. 또한 상급기관 및 법률에서 요구하는 지침과 법규를 준수할 수 있고, 궁극적으로 로그관리의 질적 향상과 분석 결과의 신뢰도를 확보할 수 있게 된다"라고 강조했습니다. 많은 관심을 모은 만큼 발표 후에도 많은 질문이 졌는데요, 이날 소개된 브레인즈컴퍼니의 솔루션은 Zenius LogManager입니다. │Zenius LogManager는? Zenius LogManager는 이기종의 다양한 장비에서 발생되는 대용량 로그(Log)를 수집/분석하고 통합하여 모니터링할 수 있는 시스템으로 정형/비정형 로그에 대한 실시간 수집과 신속한 분석 기능을 제공합니다. 또한 이러한 정보들을 다양한 차트와 대시보드를 통해 시각화할 수 있습니다. [그림] Zenius LogManager 예시 화면 Zenius LogManager는 독보적인 인덱싱 및 검색 속도를 제공할 뿐 아니라 확장성, 편의성, 효율성, 호환성 등의 장점을 가지고 있습니다. 또한 로그에 대한 수집, 저장, 분석, 시각화 기능을 통해 로그에 대한 전체 라이프사이클을 손쉽게 관리할 수 있게 지원합니다. 금융 등 다수 고객사에서 이미 검증받은 Zenius LogManager는 NHN 클라우드를 비롯한 다양한 클라우드 마켓에서 SaaS(Software as a Service) 형태로 편하게 이용하실 수 있습니다. 브레인즈컴퍼니는 이번에 소개된 Zenius LogManager뿐만 아니라, EMS/APM/ITSM 와 같은 솔루션을 통해 고객사의 비즈니스 경쟁력을 높일 수 있도록 최선을 다하겠습니다. Zenius에 대한 궁금증이 있으시면 여기 링크를 통해 확인해 주세요!
2024.07.29
하이브리드 클라우드 모니터링, 왜 필요한가?
하이브리드 클라우드 모니터링, 왜 필요한가?
최근 하이브리드 클라우드가 점점 더 중요한 역할을 하고 있습니다. 하이브리드 클라우드(Hybrid Cloud)는 온프레미스 환경과 프라이빗 클라우드, 퍼블릭 클라우드를 결합한 클라우드 환경을 의미하는데요. 쉽게 말해 필요에 따라 자체 인프라와 외부 클라우드 서비스를 동시에 사용할 수 있는 클라우드 환경입니다. 2024년까지 하이브리드 클라우드 시장은 연평균 22% 성장하여 약 3조 원 규모에 이를 것으로 예상될 정도로 각광받고 있습니다. 그렇다면 하이브리드 클라우드가 점점 더 주목을 받는 이유는 무엇일까요? │하이브리드 클라우드가 각광받는 이유 하이브리드 클라우드가 점점 더 주목을 받는 이유는 유연함 때문입니다. 기업들은 중요한 데이터를 프라이빗 클라우드에 저장하고, 일시적으로 많은 자원이 필요한 작업은 퍼블릭 클라우드를 사용하여 두 가지 클라우드의 장점을 모두 누릴 수 있습니다. 보안과 성능을 유지하면서도 필요한 만큼 자원을 사용할 수 있는 것이죠. 즉 프라이빗 클라우드의 퍼블릭 클라우드를 잘 조화하면 기업은 최적의 IT 환경을 구축할 수 있습니다. 하이브리드 클라우드의 이러한 장점은, 기업들이 경쟁력을 유지하고 빠르게 변화하는 시장 환경에 대응하는 데 큰 도움이 됩니다. 특히 클라우드 서비스 제공업체(CSP)의 다양한 서비스와 솔루션을 활용하면, 하이브리드 클라우드를 더욱 효과적으로 운영할 수 있는데요. 다음 내용을 통해 주요 클라우드 서비스 제공업체에 대해 좀 더 자세히 알아보겠습니다. │주요 클라우드 서비스 제공업체(CSP) 특징 클라우드 서비스 제공업체(CSP)으로 대표적으로 AWS(Amazon Web Services)와 마이크로소프트(Microsoft Azure)가 있습니다. 다음 내용을 통해 각각의 주요 특징을 살펴보겠습니다. Amazon Web Services (AWS) AWS는 서버, 스토리지, 데이터베이스, 네트워크 등 다양한 IT 인프라 서비스를 제공하는 아마존의 클라우드 플랫폼입니다. "AWS의 서버가 먹통이 되면, 시장에 혼돈이 온다."는 말이 있을 정도로 많은 기업이 AWS를 사용하고 있죠. AWS의 주요 특징은 아래와 같이 정리해 볼 수 있는데요. AWS의 주요 특징 1. AWS의 글로벌 인프라 AWS는 CSP 중 전 세계에서 가장 많은 리전을 보유하고 있습니다. 31개의 리전과 99개의 가용 영역을 운영하여, 사용자가 원하는 리전을 선택해 지연 시간을 단축할 수 있습니다. 다양한 지역에서 리전을 운영하는 만큼, 서비스 제공 범위가 넓고 안정성도 높습니다. 또한 엣지 로케이션을 통해 콘텐츠를 빠르게 전달하여 사용자 경험을 개선합니다. AWS는 CSP의 선두주자로서 AWS는 IaaS(인프라 서비스) 영역에서 시장 점유율이 가장 높고 안정적인 서비스를 제공합니다. 2. API 기반 서비스 AWS의 모든 서비스는 API를 통해 제어할 수 있으며, 다양한 프로그래밍 언어에서 사용 가능한 코드를 제공하여 다른 서비스를 연동할 수 있습니다. API Gateway라는 서비스를 통해 외부 애플리케이션과의 통신을 안전하게 관리할 수도 있죠. 3. 다채로운 서비스 AWS는 단순히 서버와 저장소를 제공하는 것을 넘어 S3(객체 스토리지), EC2(가상 서버), Lambda(서버리스 컴퓨팅), RDS(관계형 데이터베이스) 등 다양한 주요 서비스를 지원합니다. 최근에는 머신러닝과 AI 서비스까지 제공하고 있습니다. Microsoft Azure Microsoft Azure는 마이크로소프트가 제공하는 클라우드 컴퓨팅 플랫폼으로, AWS 다음으로 많은 기업들이 사용하고 있습니다. 애저라고도 많이 불리죠. 특히 PaaS(Platform as a Service)와 SaaS(Software as a Service) 분야에서 1위를 달리는 퍼블릭 클라우드라고 할 수 있습니다. Azure의 주요 특징은 다음과 같은데요. Microsoft Azure 주요 특징 1. Microsoft 제품과의 통합성 Azure의 가장 큰 장점은 Microsoft 제품과 쉽게 연동된다는 점입니다. 예를 들어 Office 365와 통합되며, 최근에는 생성형 AI 서비스인 Copilot 과의 통합으로 주목받고 있습니다. Microsoft 제품을 많이 사용하는 기업들에게 매우 유용하죠. 2. 웹 서비스에 집중 Azure는 특히 웹 서비스에 강점을 가지고 있습니다. 인프라(IaaS)에서는 다양한 유형을 수용하면서도, 애플리케이션 플랫폼(PaaS) 측면에서는 웹 서비스에 집중하고 있는데요. PC 웹, 모바일, API 등 모든 접속 유형을 하나의 앱 서비스에서 지원하며 가상 머신, 컨테이너, 서버리스 등 다양한 구성 방식을 제공합니다. 이처럼 AWS와 Microsoft Azure는 각각 고유한 강점을 가지고 있으며, 기업의 필요에 따라 적절한 서비스를 선택하여 사용할 수 있는데요. 하지만 이러한 다양한 클라우드 서비스의 특징과 이점을 제대로 활용하기 위해서는 클라우드 서비스 모니터링이 필수적입니다. 클라우드 인프라는 자원 사용량과 트래픽이 시시각각 변동되므로, 실시간 모니터링 없이는 문제를 사전에 발견하고 대응하기 어렵기 때문인데요. 다음 내용을 통해 어떤 솔루션이 필요한지 살펴보도록 하겠습니다. │하이브리드 클라우드 모니터링이 필요한 이유 앞서 언급한 내용처럼 AWS, Azure, GCP 등 다양한 퍼블릭 클라우드의 서비스 상태와 성능 지표를 확인하기 위해서는, 클라우드 서비스 모니터링 솔루션이 필요합니다. 물론 AWS의 *CloudWatch1처럼 자체적인 퍼블릭 클라우드 모니터링 도구들도 있는데요. * CloudWatch1 : AWS 클라우드 리소스를 모니터링하고 관리하는 서비스 통합적인 IT 환경에서 발생할 수 있는 다양한 문제를 예방하고 효율적으로 관리하기 위해서는, 퍼블릭 클라우드나 프라이빗 클라우드뿐만 아니라 온프레미스 인프라까지 함께 모니터링할 수 있는지 살펴보아야 합니다. 대표적인 사례로 Zenius CMS 솔루션을 통해, 어떤 방식으로 클라우드 서비스를 모니터링할 수 있는지 살펴보겠습니다. 하이브리드 클라우드의 통합 모니터링 Zenius CMS는 물리적인 서버, 네트워크 장비, DB와 같은 온프레미스 인프라와 퍼블릭 클라우드를 통합적으로 모니터링합니다. 사용자는 한 플랫폼 안에서 전체 인프라의 상태를 종합적으로 신속하게 장애를 파악할 수 있기 때문에, 다양한 환경에서 발생하는 성능 저하와 장애를 빠르게 식별하고 그 원인을 정확히 분석할 수 있죠. CloudWatch와 Alert History를 사용한 데이터 수집 Zenius CMS는 AWS의 CloudWatch나 Azure의 Alert History 같은 API를 사용해서 다양한 모니터링 데이터를 제공합니다. 예를 들어 CloudWatch가 기본적으로 제공하는 성능 지표뿐만 아니라 특정 서비스에 관심이 있다면, 그 서비스만 타겟으로 설정해서 모니터링할 수 있습니다. 이렇게 하면 사용하는 지역의 주요 서비스들만 선택해서 볼 수 있어, 필요한 정보를 더욱 쉽게 확인할 수 있는 장점이 있습니다. Billing(과금) 서비스 정보 제공 Zenius CMS를 통해 클라우드 자원의 사용량을 실시간으로 확인하여 예산을 더 잘 관리하고, 예상치 못한 과금이 발생하는 것을 막을 수 있습니다. 또한 비용이 어떻게 발생하는지 투명하게 파악할 수 있어 필요할 때 적절히 조정할 수 있죠. 자동 경고 기능을 통해 특정 비용 한도를 초과할 때 즉시 알림을 받아 효율적으로 관리할 수 있습니다. 이번 시간에는 하이브리드 클라우드 모니터링이 왜 중요해지고 있는지 중점적으로 알아보았습니다. 특히 클라우드 인프라는 자원 사용량이 수시로 변하기 때문에 실시간 모니터링이 중요합니다. 더불어 다양한 인프라를 통합 관리할 수 있는 온프레미스 환경도 함께 구축되어 있어야, 클라우드 인프라에 문제가 발생했을 때 빠르고 정확하게 대응할 수 있죠. 이제 하이브리드 클라우드 통합 관리와 온프레미스 환경 관제가 모두 가능한 Zenius CMS로, 클라우드 서비스를 더욱 효율적으로 관리해 보세요!
2024.07.29
하이브리드 클라우드 모니터링에 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
제니우스, 주요 CSP 5곳 마켓플레이스에 등록...클라우드 시장 공략 가속화
제니우스, 주요 CSP 5곳 마켓플레이스에 등록...클라우드 시장 공략 가속화
클라우드 환경에서 제니우스를 간편하게 이용할 수 있게 접근성 높여 브레인즈컴퍼니(099390)는 IT 인프라 통합관리 소프트웨어 ‘Zenius EMS’와 애플리케이션 관리 소프트웨어 ’Zenius APM’이 국내 주요 클라우드 서비스 제공기업(CSP) 5곳의 마켓플레이스에 모두 등록됐다고 26일 밝혔다. ‘Zenius(제니우스) EMS’는 클라우드 기반으로 서버, 네트워크, 데이터베이스 및 웹서비스(URL) 등을 단일화된 플랫폼에서 통합관리하는 소프트웨어다. ‘Zenius APM’은 WAS(Web Application Server)에서 일어나는 트랜잭션의 추적 및 장애 원인 분석 기능을 제공하는 제품이다. 도커(Docker)와 같은 컨테이너 기반의 애플리케이션 관리 및 오토 스케일링(Auto-Scaling) 자동화 기능 등 클라우드 맞춤형 서비스를 제공한다. 고객은 Zenius를 통해 백엔드부터 클라이언트 영역에 이르는 서버, 데이터베이스, 애플리케이션, 네트워크 및 웹서비스 응답시간을 통합적으로 추적 관찰할 수 있다. 또, 대시보드 등과 같은 모니터링 중앙화 도구를 통해 여러 IT 자원 간의 연관관계 및 영향 등을 분석할 수 있는 옵저버빌리티(Observability) 환경을 쉽게 구현할 수 있다. ‘Zenius EMS’와 ‘Zenius APM’은 현재 KT클라우드, 네이버클라우드, NHN클라우드, 카카오i클라우드, 가비아클라우드 총 5곳에 등록을 완료한 상태다. 고객은 각 CSP 웹사이트에서 원하는 서비스를 구입해 즉시 사용할 수 있으며, 월 구독 방식으로도 이용이 가능하다. 강선근 브레인즈컴퍼니 대표는 “이번 주요 클라우드 마켓플레이스 등록을 통해, 클라우드 기반으로 웹어플리케이션을 운영하거나 온프레미스에서 클라우드로 전환하려는 고객에게 쉽고 빠르게 접근해 더 많은 고객을 유치할 것으로 기대한다”고 말했다.
2022.12.26
다음 슬라이드 보기