반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
AI 인공지능
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
APM Solution
애플리케이션 관리
URL 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
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팀에서 제품 개발과 기술 지원을 담당하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
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
쿠버네티스(K8s) 모니터링에서 가장 중요한 두 가지?!
쿠버네티스(K8s) 모니터링에서 가장 중요한 두 가지?!
2022년 CNCF의 연간 조사에 따르면 전 세계 기업의 96%가 쿠버네티스를 활용 중이거나 활용을 고려 중인 것으로 나타났습니다. 또한 가트너는 쿠버네티스(Kubernetes, K8s) 시장의 규모가 올해 1조 2천억 원대를 돌파할 것으로 내다봤습니다. 이처럼 쿠버네티스가 '대세'로 자리 잡고 있는 가운데, 쿠버네티스 활용에 대한 어려움을 겪는 기업도 많아지고 있습니다. 클러스터 내의 리소스 할당/운영과 쿠버네티스 콘솔(대시보드)의 구성이 가장 큰 어려움으로 꼽히는데요, 이러한 어려움을 극복하기 위한 첫 번째 조건은 바로 올바른 '쿠버네티스 모니터링'입니다. 효과적이고 올바른 쿠버네티스 모니터링을 위해선 두 가지를 '꼭' 기억해야 하는데요, 지금부터 그 두 가지를 자세히 알아보겠습니다. ㅣ올바른 쿠버네티스 모니터링을 위한 두 가지 조건 첫 번째, 쿠버네티스의 주요 항목을 한눈에 볼 수 있어야 합니다 쿠버네티스 환경은 규모가 크고 동적이며 복잡한 구조를 가지고 있습니다. 그렇기 때문에 리소스 사용률, 에러 로그 등의 중요 정보를 실시간으로 파악할 수 있어야 합니다. 따라서 쿠버네티스 모니터링을 효과적으로 수행하기 위해 첫 번째로 기억해야 할 것은 '쿠버네티스 환경을 한 화면에서 종합적으로 볼 수 있어야 한다는 점'입니다. 우선 종합적인 모니터링을 통해 리소스 사용률, 트래픽 패턴 등의 중요 정보를 실시간으로 파악할 수 있어 문제 발생 시 빠르게 원인을 진단하고 해결할 수 있습니다. 또한 쿠버네티스 운영의 핵심은 효율적인 리소스 관리인데, 종합적인 모니터링을 통해 리소스 낭비를 줄이고 애플리케이션의 성능을 최적화할 수 있습니다. 이와 더불어 시스템의 이상 유무를 지속적으로 모니터링함으로써, 예기치 않은 다운타임 등의 오류를 방지할 수도 있죠. 따라서 쿠버네티스 모니터링 솔루션에는 각 구성요소들 간의 관계와 영향도를 '한 눈'에 파악할 수 있는 모니터링 View가 반드시 필요합니다. 더불어 쿠버네티스 환경을 관리하는 운영자나 조직마다 중요하게 생각하는 데이터 지표가 다릅니다. 때문에 운영자가 자신의 필요에 따라 모니터링 화면을 자유롭게 구성할 수 있다면, 더욱 효과적으로 시스템을 관리할 수 있습니다. [그림1] (왼) 클러스터 상세 모니터링 View, (중) 클러스터 메인 모니터링 View, (오) 주요 Service 모니터링 View 더 자세한 설명을 위해 제니우스(Zenius)의 쿠버네티스 모니터링 솔루션인 Zenius-K8s을 예로 살펴보겠습니다. 우선 [그림1]에 나와있는 것처럼 쿠버네티스 모니터링 솔루션은 여러 클러스터 현황을 한눈에 확인할 수 있는 요약 뷰를 제공해야 합니다. 이를 통해 클러스터의 상세한 현황과 노드, 파드, 컨테이너, 서비스 등을 통합적으로 모니터링할 수 있기 때문이죠. 이러한 기능은 운영자로 하여금 시스템 전반에 대한 신속한 이해를 가능하게 하고, 업무 효율성을 크게 높여줍니다. [그림2] (왼) Zenius-K8s 운영현황 오버뷰 (오) 사용자가 직접 정보를 구성할 수 있는 컴포넌트 수정창 여기에 더해서 Zenius-K8s처럼 쿠버네티스 주요 데이터 지표를 '사용자 관제 목적'에 따라 자유롭게 구성이 가능하고 가시성 높은 다양한 차트와 컴포넌트를 포함한 오버뷰를 제공한다면, 더욱더 성공적인 쿠버네티스 활용이 가능해집니다. 두 번째, 클러스터 별로 상세한 성능을 확인할 수 있어야 합니다 효과적이고 올바른 쿠버네티스 모니터링을 위한 두 번째 조건은, '클러스터 별로 상세한 성능을 확인할 수 있어야 한다는 것'입니다. 특히 쿠버네티스 환경을 관리하고 최적화함에 있어서 핵심적인 역할을 하는 클러스터 현황(노드, 파드, 컨테이너), 성능 지표(CPU 사용량, Memory 사용량), 이벤트 현황을 연관 지어 직관적으로 모니터링할 수 있어야 합니다. 이를 통해서 운영자는 클러스터의 전반적인 상태를 실시간으로 모니터링하고, 발생 가능한 문제를 조기에 식별하여 시스템의 안정성과 성능을 지속적으로 높일 수 있기 때문이죠. 또한 클러스터의 각 구성 요소가 서로 다른 역할을 수행하기 때문에 각 노드, 파드, 컨테이너별로 상세히 모니터링하는 것도 매우 중요합니다. [그림3] 클러스터 별 상세정보 요약 뷰 지금 살펴본 내용을 Zenius-K8s 예시 화면을 통해 다시 한번 되짚어 보겠습니다. 먼저 위 [그림3]에서 보이는 것처럼 주요 클러스터 현황(노드, 파드, 컨테이너 등), 주요 성능 지표(CPU, Memory 사용률 등), 이벤트 현황 등을 한 화면에서 확인할 수 있는 요약 뷰가 있어야 합니다. [그림4] Zenius-K8s 토폴로지 맵 특히, Zenius-K8s의 경우 수집한 데이터를 기반으로 자동으로 각 구성요소 간의 연관관계와 서비스 상태를 토폴로지 맵(Topolgy Map) 형태로 구성할 수 있습니다. 또한 다양한 조회 기준(노드, 네임스페이스, 서버)과 상세 정보 조회 기능을 제공하고 있죠. 쿠버네티스 모니터링 솔루션에는, 직관적이고 효율적인 모니터링을 위해 반드시 위와 같은 기능이 포함되어 있어야 합니다. [그림5] 노드(Node) 별 상세 모니터링 [그림6] 파드(Pod) 별 상세 모니터링 [그림7] 컨테이너(Container) 별 상세 모니터링 마지막으로 위의 Zenius-K8s의 예시 화면들처럼, 클러스터 내 각각의 구성요소에 대한 상세한 모니터링이 필요합니다. 이를 통해 산재된 데이터에 대한 효율적인 관리가 가능하기 때문이죠. 。。。。。。。。。。。。 지금까지 성공적인 쿠버네티스 모니터링을 위한 두 가지 조건을 살펴봤습니다. 쿠버네티스의 활용도와 중요성이 더 커지는 가운데, 운영의 안정성과 효율성을 높여주는 쿠버네티스 모니터링 솔루션 도입은 이제 선택이 아닌 필수가 되었습니다. 쿠버네티스 현황을 한눈에 볼 수 있고, 세부 요소를 세밀하게 들여다볼 수 있는 모니터링 솔루션을 통해서 성공적으로 쿠버네티스를 활용하시기 바랍니다.
2024.04.05
금융권에서 꾸준히 각광받는 제니우스(Zenius)
금융권에서 꾸준히 각광받는 제니우스(Zenius)
지난해 10월 일본의 은행 간 결제 시스템이 이틀간 '먹통'이 된 사태가 발생했었습니다. 그리고 한 달 후에는 카드 결제 데이터를 처리하는 일본 카드 네트워크의 시스템 오류로 인해 일본 각지에서 7시간 넘게 시민들이 카드 사용을 못 하는 불편이 발생하기도 했죠. 일본의 사례와 같이 은행이나 카드회사 등의 금융회사에서 네트워크/서버의 장애가 발생할 경우 궁극적으로 이익과 신뢰도의 급감으로 이어질 수 있습니다. 그렇기 때문에 '사고 없는' IT 인프라 환경 운영을 위한 노력을 이어가는 가운데, 브레인즈컴퍼니의 제니우스(Zenius)을 활용하는 금융기관이 꾸준히 증가하고 있습니다. ㅣ제니우스, 금융기관에서 꾸준히 각광받다 앞서 언급한 대로, 제니우스를 도입하고 활용하는 금융기관이 꾸준히 늘고 있습니다. 최근 수협중앙회는 '통합관제 및 운영 자동화'를 위해, 그리고 새마을금고는 '빅데이터 플랫폼 고도화'를 위해 제니우스를 도입했습니다. 또한 한국수출입은행과 한국 주택금융공사도 서버와 네트워크 관리를 위해 제니우스를 활용하고 있습니다. 이 밖에도 NH 뱅크, 신협중앙회, 광주은행, IBK 투자증권, DB손해보험 등에서도 꾸준히 제니우스를 활용하고 있습니다. 그렇다면 금융기관에서 제니우스를 꾸준히 사용하고 있는 이유는 무엇일까요? ㅣ제니우스의 네 가지 강점 금융기관에서 꾸준히 각광받는 제니우스는 크게 네 가지의 강점이 있습니다. [1] IT 인프라에 대한 통합 관리 제니우스는 금융기관의 복잡한 IT 환경을 통합 관리할 수 있는 기능들을 제공합니다. 이를 통해 IT 인프라의 성능 및 장애 정보를 빠르게 파악할 수 있어서, 운영 효율성과 안정성을 크게 높을 수 있습니다. [2] 보안 강화 금융기관에 필수적인 높은 수준의 보안을 유지할 수 있도록 제니우스는 통합 로그 관리, 보안 취약점 점검 등의 보안 기능을 제공합니다. 이를 통해 보안 위협에 대응하고 사전에 예방할 수 있습니다. [그림] 제니우스(Zenius) 오버뷰 예시화면 [3] 장애 대응 및 예방 실시간 모니터링과 자동 장애 복구 기능으로 시스템 장애에 대한 신속한 예방과 대응이 가능합니다. 이를 통해 서비스 중단을 최소화하고, 고객 만족도를 높일 수 있습니다. [4] 클라우드 서비스 지원 쿠버네티스 활용을 비롯한 클라우드 환경으로의 전환은 금융기관의 중요한 이슈로 떠오르고 있습니다. 제니우스는 모든 클라우드 환경(퍼블릭, 프라이빗, 하이브리드)에 대한 모니터링이 가능하여, 클라우드 서비스 안정성과 효율성을 크게 높여줍니다. 제니우스(Zenius)는 앞서 살펴 본 금융기관뿐 아니라, 공공기관과 기업을 포함한 1,000곳 이상에서 활발히 활용되고 있습니다. CSAP 인증과 GS 인증 1등급도 획득한 제니우스를 통해 성공적인 IT 인프라를 관리하시기 바랍니다.
2024.04.16
좋은 대시보드(Dashboard) 설계를 위한 4가지 핵심 가이드
좋은 대시보드(Dashboard) 설계를 위한 4가지 핵심 가이드
급변하는 IT 환경에서 우리는 많은 데이터를 접하고 있습니다. 이러한 방대한 데이터를 효율적으로 관리하고 시각화하기 위해 '대시보드'가 등장한 후 널리 활용되고 있습니다. 대시보드(Dashboard)는 필요한 데이터를 통합하여 시각화하는 화면으로, 사용자에게 중요한 정보를 한눈에 보여주는 도구입니다. 2023년 가트너(Gartner) 연구에 따르면, 전 세계 기업 72%가 데이터 시각화 도구를 사용하고 있기도 합니다. 데이터 시각화 도구를 활용한 기업이 비활용 기업에 비해 의사 결정 속도가 5배 빠르다는 연구 결과도 나왔죠. 그렇다면 기업운영에 있어 대시보드가 왜 중요한지, 좀 더 자세히 살펴보겠습니다. │대시보드(Dashboard), 왜 중요할까요? 대시보드가 중요한 이유는 여러 가지 있지만, 그중에서도 가장 핵심적인 이유는 다음과 같습니다. 첫째, 대시보드는 빠르고 정확한 의사 결정을 가능하게 합니다. 대시보드는 실시간으로 데이터를 시각화하고 중요한 정보를 즉각적으로 제공하여, 빠르고 정확한 의사 결정을 가능하게 합니다. 예를 들어 서버의 성능 문제나 네트워크 장애를 실시간으로 감지하고 즉각적으로 대응할 수 있습니다. 이는 기업이 비즈니스 연속성을 유지하고, 예기치 않은 문제로 인한 손실을 최소화할 수 있게 도와주죠. 둘째, 대시보드는 전체적인 상황을 한눈에 파악할 수 있게 합니다. 여러 출처에서 수집된 데이터를 하나의 화면에 통합하여 보여주기 때문에, 전체적인 상황을 한눈에 파악할 수 있습니다. 이를 통해 데이터 간의 관계를 쉽게 분석하고, 복잡한 문제를 효율적으로 해결할 수 있죠. 이는 전략적 계획 수립과 운영 효율성을 높이는 데 매우 중요한 역할을 합니다. 위에서 살펴본 두 가지 핵심 이유로 인해서 대시보드는, 기업의 비즈니스 경쟁력 확보를 위한 핵심 도구로 자리 잡고 있습니다. │어떤 종류의 대시보드가 있을까요? 대시보드 종류는 매우 다양한데요. IT 인프라 통합 관리 대시보드 기준에서, 대표적으로 세 가지 대시보드 유형을 살펴보겠습니다. 서비스형 대시보드 [그림] Zenius 서비스형 대시보드 일반적으로 많이 사용하는 서비스형 대시보드는 IT 서비스 성능 상태를 실시간으로 모니터링할 수 있게 도와줍니다. CPU, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등을 한눈에 확인할 수 있죠. 이를 통해 성능 저하나 장애가 발생하면 즉각 알림을 받아 빠르게 대응할 수 있습니다. 또한 클라우드와 온 프레미스 환경 모두 사용 가능해 유연성이 뛰어납니다. 지도형 대시보드 [그림] Zenius 지도형 대시보드 지도형 대시보드는 여러 지역에 분산된 IT 인프라를 한 지도에서 통합적으로 보여줍니다. 서버, 데이터 센터, 네트워크 장비 위치와 상태를 지도 위에 표시해 한눈에 파악할 수 있죠. 이때 특정 지역에서 문제가 발생하면 즉시 감지하고 대응할 수 있습니다. 또한 지리적 데이터를 바탕으로 장애 패턴을 분석하여 효율적인 관리가 가능하며, 실제 지리 정보 시스템(GIS)와 연동해 정교한 위치 기반 관리도 가능합니다. 이러한 기능 덕분에 이 대시보드는, 특히 글로벌 기업이나 여러 지사와 데이터 센터를 운영하는 조직에서 유용하게 사용됩니다. 구성도형 대시보드 [그림] Zenius 구성형 대시보드 구성도형 대시보드는 네트워크 자원의 상태와 관계를 시각적으로 표현해 줍니다. 이를 통해 네트워크 장비 간의 트래픽 흐름을 실시간으로 모니터링하고, 병목 지점이나 장애 발생 지점을 쉽게 찾아낼 수 있습니다. 또한 각 장비의 상태, 성능 지표, 로그 데이터를 시각적으로 제공해 문제를 조기에 발견하고 해결할 수 있도록 도와줍니다. 더 나아가 네트워크 트래픽을 분석해 최적화 방안을 도출할 수 있으며, 다양한 네트워크 인프라를 지원해 유연한 관리가 가능합니다. 하지만 이러한 대시보드는 '어떻게 구현하고 설계했느냐'에 따라서 좋은 대시보드가 될 수도, 그렇지 못할 수도 있는데요. 그렇다면 좋은 대시보드를 만들기 위해 어떤 점을 고려해야 할까요? 다음 내용을 통해 자세히 살펴보겠습니다. │좋은 대시보드를 만들기 위한 고려사항 핵심 데이터 우선 제공 우선 좋은 대시보드를 만들기 위해 가장 먼저 고려해야 할 점은, 시각화할 대상과 데이터를 명확히 파악해야 한다는 것입니다. 어떤 데이터가 가장 중요한지, 결정하는 것이 우선이죠. 반대로 너무 많은 데이터를 시각화하지 않도록 주의해야 합니다. 과도한 데이터 시각화는 사용자가 중요한 정보를 파악하는 데 어려울 수 있습니다. 따라서 핵심 데이터를 선별하여 우선적으로 표시해야 합니다. 좀 더 구체적인 사례를 통해 살펴볼게요. 대시보드는 서버, 네트워크, DB 등 기본 인프라 데이터를 수집하고 시각화해야 하는데요. 이 데이터는 CPU, 메모리, bps, 스토리지, 데이터 파일 등과 같이 시스템 성능과 운영 상태를 파악하는 필수적인 핵심 지표들입니다. 이러한 핵심 데이터를 명확하게 정의하고 제공하는 것은 대시보드 설계의 첫 번째 단계에서 중요한 요소이죠. [그림] Zenius 서비스형 대시보드 Zenius 대시보드는 이러한 기본 인프라 데이터를 우선적으로 수집하고 시각화하여, 사용자가 가장 중요한 정보를 빠르게 파악할 수 있도록 합니다. 사용자가 어떤 데이터를 가장 먼저 확인해야 하는지, 즉 우선순위를 명확히 하여 중요한 정보를 놓치지 않도록 도와주죠. 효율적이고 직관적인 정보 전달 좋은 대시보드를 만들기 위해 두 번째로 고려해야 할 점은, 사용자가 필요한 정보를 쉽고 빠르게 확인할 수 있도록 설계되어야 합니다. 데이터의 가독성을 높이는 색상과 그래픽 요소를 적절히 사용하여, 사용자 인터페이스가 직관적이고 사용하기 쉬워야 합니다. 여기서 유의할 점은 시각적 요소에 너무 몰두하지 않도록 주의해야 합니다. 디자인에만 집중하면 필요한 정보가 제대로 전달되지 않을 위험이 있기 때문이죠. 따라서 실용성과 사용성을 중시하여 사용자 중심의 인터페이스를 설계해야 합니다. 이번에도 대시보드 사례를 통해 구체적으로 살펴볼게요. Zenius는 '사용자 맞춤형 대시보드'를 제공하고 있는데요. 사용자의 모니터링 환경에 맞게 자유롭게 편집할 수 있습니다. 관리 대상이 많아지거나, 관리 목표를 변경해도 컴포넌트와 디스플레이 항목을 손쉽게 편집할 수 있습니다. 또한 Zenius의 직관적이고 유연한 편집 기능을 통해, 사용자에게 필요에 따라 색상이나 차트 유형을 쉽게 변경할 수 있도록 설계했습니다. 데이터를 가독성 있게 시각화하여 사용자가 인터페이스 직관적이고 사용하기 쉽도록 구성했죠. 외부 데이터 통합 좋은 대시보드를 만들기 위해 세 번째로 고려해야 할 점은, 기업 내 여러 솔루션의 핵심 지표를 한 화면에서 확인할 수 있도록 구성해야 합니다. 외부 데이터와의 연동으로 여러 시스템의 데이터를 통합하면, 전체 상황을 한눈에 파악할 수 있는데요. 이를 통해 분석과 의사결정을 용이하게 해줍니다. Zenius 사례를 통해 다시 한번 살펴보겠습니다. Zenius 대시보드는 3rd Party 시스템 연동을 통해, 외부 데이터를 통합하여 한 화면에서 핵심 지표를 확인할 수 있도록 설계했습니다. 이를 통해 사용자가 기업 내 다양한 솔루션 지표를 한눈에 파악할 수 있죠. 비즈니스 전반의 통합 관제 좋은 대시보드를 만들기 위해 네 번째로 고려해야 할 점은, 비즈니스 관점에서 모니터링과 이상 상황을 감지할 수 있도록 설계되어야 합니다. 조직의 전반적인 운영 상태를 실시간으로 파악하고, 문제 발생 시 신속하게 대응해야 하기 때문이죠. 또한 서비스 단위로 인프라를 구성하여, 비즈니스 문제 여부를 즉각적으로 파악할 수 있도록 해야 합니다. 다시 Zenius 사례를 통해 살펴볼게요. Zenius 대시보드는 수집된 다양한 정보를 바탕으로, 최상위 레벨에서 비즈니스 관점 모니터링과 이상 상황을 감지할 수 있는 화면을 제공합니다. 다양한 컴포넌트와 차트, 다이나믹한 요소들을 적용하여 시각적인 효과를 극대화할 수 있죠. 이번 시간에는 대시보드가 왜 필요한지, 좋은 대시보드를 구현하기 위해서는 어떠한 점들을 고려해야 하는지 알아보았습니다. 하지만 이러한 좋은 대시보드를 성공적으로 구현하기 위해서는, 전문가의 도움이 필요합니다. 데이터를 시각화하여 구성하는 것은 보는 이에 따라 관점이 다르고 다양하여, 하나부터 열까지 구성하는 것이 어려울 수 있기 때문이죠. 또한 조직 상황이나 사용자 관점마다 중요한 데이터가 다르고 시각화해야 하는 방식도 다를 수 있습니다. 따라서 제니우스(Zenius)와 같이 수많은 구축 노하우를 보유하고 있고, 고객의 상황에 따라 최적화된 대시보드 구현이 가능한 솔루션 활용을 통해 비즈니스 경쟁력을 확보하시기 바랍니다. ?더보기 Zenius Dashboard 더 자세히 보기
2024.07.26
다음 슬라이드 보기