반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
[행사] 브레인즈컴퍼니 신년회, 2023년을 돌아보고 2024년을 내다보다
이화정
2024.01.05
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
테라폼(Terraform)의 모든 것, 그리고 AWS EC2 생성하기
브레인저들의 새해를 여는
2024년 신년회
가 지난 4일(목) 본사 8층 라운지에서 열렸습니다.
오랜만에 브레인저 모두가 모인 자리에서 2023년을 돌아보고, 2024년을 함께 내다보는 시간을 가졌습니다. 그리고 장기근속자, 우수팀, 승진을 발표하고 축하하는 시간과 고기파티까지 열렸는데요! 신년회의 생생한 현장을 지금부터 살펴보겠습니다.
。。。。。。。。。。。。
[16:00]
2023년을 돌아보고 2024년을 내다보다
브레인즈컴퍼니의 각 분야를 담당하고 있는 본부장님들의 발표로 본격적인 신년회가 시작되었습니다.
첫 번째 순서는 전략사업본부의 은숙님이 맡아주셨습니다. 은숙님은 9부터 시작해서 1까지 각 숫자와 연관되어 있는 내용으로 2023년 회고와 2024년 계획을 말씀해 주셨습니다. 브레인즈컴퍼니의 영업
·
마케팅
·
고객관리를 총괄하고 계신만큼, 많은 고민과 진심이 담긴 발표였습니다!
은숙님은 발표를 통해
“2023년 어려운 시장 환경 가운데서도 모두 노력해서 많은 고객을 만나고 소프트웨이브같은 큰 행사도 성공적으로 치렀던 것 처럼, 2024년에도 모든 브레인저가 힘을 합치면 목표보다 더 높은 곳에 오를 수 있을 것”
이라고 강조해 주셨습니다.
다음으로 브레인즈컴퍼니의 중심! 개발그룹을 대표해서 자환님이 발표를 진행해 주셨습니다. 자환님은
“2023년에 빠르게 변화하고 있는 IT 환경과 고객 니즈에 맞춘 서비스를 지속적으로 개발하고 배포했다. 2024년에도 기존 출시된 쿠버네티스(Kubernetes) 모니터링 제품의 기능 고도화를 포함하여, 완성도 높은 기능과 서비스들을 선보일 계획”
이라고 밝혀주셨습니다.
마지막으로 경영지원팀 현보님은
“지난해 만족도가 높았던 해외연수(만족도 4.43/5)와 패밀리데이(만족도 4.56/5)를 포함하여, 2024년에는 더 다양한 행사와 교육 등을 통해 건강한 사내 문화를 만들겠다. 또한 브레인저들의 능력을 높일 수 있도록 지속적으로 노력하겠다”
라고 포부를 밝혀주셨습니다.
이렇게 각 본부별 2023년 회고와 2024년 비전을 알아볼 수 있었는데요. 본부장님들이 발표 중간중간 감사하고 수고했던 브레인저분들께, 진심 어린 감사의 마음을 전하며 마음이 따뜻해 지기도 했습니다.
[16:45]
재걸님의 총평 “2024년 우리가 꼭 기억해야 할 것은”
다음 순서로 브레인즈컴퍼니의 운영을 총괄하시는 재걸님(부사장)께서 2023년 한 해를 되돌아보는 총평과, 2024년 계획에 대해 발표하는 시간을 가졌습니다.
우선 2023년에 어려운 경제환경 속에서도 제니우스(Zenius)의 고객이 꾸준히 증가한 것과 큰 행사를 잘 마무리한 것, 그리고 쉬지 않고 새로운 서비스 개발에 힘쓴 것에 대해 격려해 주셨습니다.
2024년에는 브레인즈컴퍼니가 더 높이 도약할 수 있도록 Zenius의 경쟁력을 높이고, 자회사인 에이프리카와의 협업을 강화할 것을 강조하셨습니다.
[17:20]
깜짝 ‘나락’퀴즈쇼!
잠시 분위기를 바꿔 브레인즈 나락 퀴즈쇼도 진행됐습니다. 퀴즈를 맞추거나, 틀려도 나락(?)에 갈 수 있는 위험하고 재밌는 시간이었는데요. 한 분을 제외하곤 모두 정답을 맞춰주셨습니다
(자세한 내용 해당 브레인저들의 더 이상의 추락을 막기 위해 비공개로..)
. 이 퀴즈쇼를 통해 모든 브레인저가 함께 웃을 수 있었던 시간이었습니다.
[17:40]
각종 포상 수상식
다음으로는 각종 포상 및 승진자를 발표하고 축하하는 시간이 이어졌습니다. 먼저 장기근속자(5/10/15)들에 대한 포상이 진행되었는데요. 여기서 깨알 복지!
*브레인즈컴퍼니는 5년 근속자는 현금 100만 원 지급, 10년 근속자는 현금 300만 원과 휴가 3일 지급, 15년 근속자는 500만 원과 휴가 5일을 지급합니다.
다음으로는 2023 최우수 부서(디자인팀), 협력지원 포상에 이어 승진자 발표가 이어졌습니다. 모두 진심으로 축하드립니다?
[18:00]
신년회의 ‘꽃’ 회식
신년회에는 맛있는 음식이 빠질 수 없죠! 팀원들 간의 행복한 저녁 시간을 보내기 위해 근처 고깃집으로 향했는데요. 큰 규모의 식당을 단독으로 대관해 편하게 즐길 수 있었습니다.
팀원분들끼리 그간 못 했던 말들도 하고, 포상과 승진을 한 브레인저에게 서로 축하 인사를 하며, 회포를 푸는 시간을 가졌습니다.
이번 신년회를 통해 2023년 한 해를 되돌아보고, 2024년을 희망차고 행복하게 시작할 수 있었습니다. 무엇보다 브레인저분들이 함께 있어 더 뜻깊었던 시간이었습니다!
이렇게 브레인즈컴퍼니의 2024년은 힘차게 시작되었습니다.
#신년회
#사내문화
#사내복지
#행사
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
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
옵저버빌리티(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
웹 애플리케이션 모니터링 솔루션, Zenius APM의 주요기능과 특장점
웹 애플리케이션 모니터링 솔루션, Zenius APM의 주요기능과 특장점
웹 애플리케이션은 이제 단순한 서비스 제공 도구를 넘어 기업의 경쟁력을 좌우하는 중요한 요소로 자리 잡았습니다. 웹 애플리케이션의 성능은 사용자 경험의 품질을 결정짓는 중요한 요소이기 때문에, 매출 증가와 브랜드 신뢰도 형성에 직접적인 영향을 미칩니다. 그러나 트랜잭션 처리량이 급격히 증가하고, 데이터의 양과 복잡성이 더해지면서, 웹 애플리케이션의 안정적이고 효율적인 운영을 위해 실시간 모니터링과 정교한 성능 관리가 반드시 필요합니다. Zenius APM은 이러한 복잡한 요구를 충족시킬 수 있는 솔루션으로, 웹 애플리케이션의 성능 최적화와 운영 안정성 강화를 위한 다양한 기능을 제공합니다. 특히, 실시간 모니터링, 심층 분석, 장애 관리와 같은 핵심 역량을 기반으로 IT 환경의 복잡성을 효과적으로 관리하고 운영 효율성을 높일 수 있도록 돕습니다. Zenius APM이 제공하는 주요 기능과 특장점을 자세히 살펴보겠습니다. Zenius APM의 주요기능 [1] 효과적인 실시간 모니터링 Zenius APM은 웹 애플리케이션의 성능을 실시간으로 모니터링하여 운영자가 시스템 상태를 시각적으로 파악하고, 잠재적 문제를 조기에 발견해 신속히 대응할 수 있도록 지원합니다. 우선 Zenius APM의 대시보드는 사용자별로 맞춤 설정이 가능합니다. WYSIWYG 방식을 채택하여 운영자가 원하는 모니터링 항목을 직관적으로 구성할 수 있습니다. 운영자는 드래그 앤 드롭으로 모니터링 항목을 배치하고, 데이터 포인트를 중심으로 상황판을 제작해 각자의 운영 환경에 최적화된 대시보드를 손쉽게 구축할 수 있습니다. Real-Time Topology Map은 트랜잭션의 흐름과 병목 구간을 시각적으로 보여주는 기능입니다. 응답 시간과 처리량을 색상과 노드로 표시하며, 문제 발생 지점을 직관적으로 파악할 수 있도록 설계되었습니다. 병목 구간이나 성능 저하가 발견될 경우, 해당 노드를 클릭하여 상세한 분석 화면으로 즉각 이동할 수 있어 문제를 신속히 해결할 수 있습니다. Zenius APM이 제공하는 주요 모니터링 항목으로는 트랜잭션 응답 시간과 병목 구간, JVM 힙 메모리와 CPU 사용량, JDBC 연결 상태와 SQL 실행 건수, 동시 접속 사용자 수와 TPS(초당 트랜잭션 처리량) 등이 있습니다. 이러한 지표를 통해 운영자는 성능 최적화와 안정성을 효과적으로 관리할 수 있습니다. [2] 장애 관리 지원 Zenius APM은 웹 애플리케이션의 안정적인 운영을 위해 장애를 사전에 방지하고, 발생한 장애를 신속하고 정확하게 분석할 수 있는 기능을 제공합니다. 우선, 장애 정책 기반 이벤트 감지 기능을 통해 서비스 처리량(TPS), 응답 시간, JVM 자원 사용률 등 주요 성능 지표에 임계치를 설정할 수 있습니다. 임계치가 초과되면 SMS, 이메일, Push App 등을 통해 실시간 경고를 전송하여 운영자가 즉각적으로 대응할 수 있도록 지원합니다. 또한, Snapshot 분석 기능은 장애가 발생한 시점의 성능 데이터를 Raw 데이터 기반으로 재현하여 문제를 정밀하게 분석할 수 있도록 도와줍니다. 이를 통해 장애의 정확한 원인을 파악하고, 향후 동일한 문제가 발생하지 않도록 사전에 대비할 수 있습니다. 이와 더불어, 통합 이벤트 관리 기능은 발생한 이벤트 이력을 체계적으로 기록하고 관리합니다. 이를 통해 장애 처리 과정을 명확히 추적할 수 있으며, 과거 데이터를 기반으로 유사한 상황이 발생했을 때 신속하고 효과적인 대처가 가능합니다. 이벤트 관리 시스템은 처리 상태, 발생 시간, 지속 시간, 장애 유형 등의 세부 정보를 저장하며, 운영자는 이를 활용하여 문제 해결 프로세스를 최적화할 수 있습니다. [3] 다양한 성능 분석 지원 Zenius APM은 다양한 성능 분석 도구를 통해 운영자가 애플리케이션 성능 데이터를 심층적으로 이해하고, 데이터 기반의 최적화된 결정을 내릴 수 있도록 지원합니다. 주제별 성능 분석은 애플리케이션 및 데이터베이스 성능을 심층적으로 이해하고 개선하는 데 중요한 역할을 합니다. 애플리케이션 분석은 호출 건수, 실패 건수, 응답 시간 등을 통해 애플리케이션 상태를 종합적으로 파악할 수 있도록 돕습니다. 반면, SQL 분석은 데이터베이스 쿼리 호출 빈도, 평균 응답 시간, 실패 건수 등 세부 데이터를 제공하여 비효율적인 SQL 쿼리를 식별하고 데이터베이스 성능을 최적화할 수 있도록 지원합니다. 또한, 품질 이슈 분석은 Exception과 Error 발생 원인을 트랜잭션 데이터와 연관시켜 문제를 효과적으로 해결할 수 있도록 돕습니다. 특히, 자동 연관 분석은 SQL, 애플리케이션, 트랜잭션 데이터를 연결하여 성능 문제의 원인과 연관성을 시각적으로 표현합니다. 이를 통해 복잡한 데이터를 직관적으로 이해하고, 문제 해결에 필요한 핵심 정보를 빠르게 파악할 수 있습니다. 마지막으로, 기간별 증감 추이 비교 기능은 특정 기간 동안의 호출 건수, 응답 시간 등의 데이터를 비교하여 성능 변화 추이를 명확히 파악할 수 있습니다. 이를 기반으로 성능 저하의 원인을 식별하고, 구체적인 시스템 개선 방향을 도출할 수 있습니다. [4] 사용자 맞춤형 통계 및 보고서 Zenius APM은 사용자 맞춤형 데이터 시각화와 보고서 생성을 통해 운영자가 필요한 정보를 효율적으로 제공하며, 데이터 기반 의사결정을 지원합니다. 통계 템플릿 기능은 Zenius APM이 제공하는 대표적인 사용자 편의 도구 중 하나로, 방문자 수, 시스템 자원 사용률, 트랜잭션 처리 건수 등 35개 이상의 주요 성능 지표를 기반으로 템플릿을 저장하고 재활용할 수 있습니다. 이를 통해 운영자는 빈번히 사용하는 보고서 양식을 템플릿화함으로써 반복적인 작업 시간을 줄이고, 데이터 분석과 의사결정에 더 많은 시간을 할애할 수 있습니다. 또한, 다양한 유형의 보고서를 생성할 수 있는 기능은 Zenius APM의 또 다른 강점입니다. 성능 비교, 이벤트 발생 현황 분석, 자원 증설 필요성 평가 등 다양한 보고서를 통해 운영 상황을 종합적으로 분석하고, 개선 방안을 도출할 수 있습니다. 이러한 맞춤형 통계와 보고서는 운영자에게 명확하고 유용한 인사이트를 제공하여, 효율적이고 전략적인 시스템 운영을 가능하게 합니다. 이러한 맞춤형 통계와 보고서는 단순한 데이터 시각화 도구를 넘어, 운영자가 운영 상태를 명확히 이해하고 전략적인 결정을 내릴 수 있도록 지원하는 중요한 역할을 합니다. Zenius APM의 특장점 지능형 IT 인프라 통합 관리 솔루션인 Zenius의 핵심 구성 요소인 Zenius APM은 다양한 IT 자원의 연관성을 체계적으로 분석하며, 효율적이고 신뢰할 수 있는 모니터링 환경을 제공합니다. EMS Framework를 기반으로 구축된 Zenius APM은 웹 애플리케이션과 서버, 네트워크 등 다양한 인프라를 중앙에서 집중적으로 모니터링할 수 있는 기능을 지원합니다. 또한, 하드웨어와 미들웨어를 포함한 이기종 인프라를 통합 관리하기 위한 도구를 제공하며, Overview와 Service Map을 통해 시스템 전반의 상호작용을 명확히 파악할 수 있습니다. 특히, 서버와 DBMS를 비롯한 IT 인프라 전반의 상호작용을 분석하여 장애의 원인과 영향을 신속히 파악하고, 이를 바탕으로 심층적이고 효율적인 관리를 지원합니다. 이러한 기능을 통해 운영자는 문제를 조기에 발견하고 신속히 해결할 수 있으며, 안정적이고 효율적인 IT 환경을 유지할 수 있습니다. 또한 최근 많이 활용되는 쿠버네티스 모니터링 솔루션(Zenius K8s)과의 연계를 통해 컨테이너 기반의 마이크로서비스 아키텍처 및 분산 환경에서도 뛰어난 관리 성능을 발휘합니다. 쿠버네티스 클러스터의 POD와 컨테이너 상태를 실시간으로 모니터링하며, 자동 스케일링과 같은 클라우드 네이티브 기능을 통해 변화가 잦은 환경에서도 안정적인 서비스 운영을 보장합니다. 또한 Zenius APM은 장애가 발생한 특정 시점(예: 예외 발생 또는 오류 시점)의 애플리케이션 성능 정보를 정밀하게 재현할 수 있습니다. Raw 데이터 기반의 스냅샷 분석을 활용하여 과거의 실시간 운영 상태를 정확히 복원하며, 이를 통해 문제의 원인을 신속하고 정밀하게 파악할 수 있습니다. 사용자가 필요에 따라 분석 항목과 화면 구성을 선택적으로 조정할 수 있어, 상황에 맞춘 유연하고 효율적인 분석이 가능합니다. Zenius APM은 세분화된 장애 심각도 설정과 SMS, 이메일, Push 알림 등 다양한 방식으로 장애 발생을 빠르게 알립니다. 또한, 에스컬레이션 통보 기능을 통해 운영자는 중요한 장애가 누락되지 않도록 관리하며 대응 시간을 단축할 수 있습니다. 이와 더불어, 애플리케이션과 인스턴스를 논리적으로 그룹화하여 비즈니스 관점에서 실시간 서비스 성능을 모니터링할 수 있도록 지원합니다. 이를 통해 인스턴스 관점과 비즈니스 관점의 실시간 듀얼(Dual) 모니터링 환경을 제공하며, 실제 서비스와 연계된 성능 관리를 더욱 효과적으로 수행할 수 있습니다. Zenius APM은 복잡한 IT 환경에서 웹 애플리케이션의 성능을 최적화하고 운영 안정성을 보장하는 데 필요한 모든 기능을 제공합니다. 실시간 모니터링, 장애 관리, 성능 분석, 그리고 사용자 맞춤형 보고서 기능은 운영자가 문제를 사전에 예방하고 효율적으로 대처할 수 있는 기반을 마련합니다. 이를 통해 기업은 안정적이고 효율적인 IT 운영을 실현하며 비즈니스 경쟁력을 강화할 수 있습니다.
2024.11.29
통합로그관리가 필요한 3가지 이유
통합로그관리가 필요한 3가지 이유
로그는 IT 인프라에서 발생하는 모든 상황들을 기록한 데이터입니다. 쉽게 말해 사용자가 어떤 루트로 사이트에 접속했고, 접속한 시점부터 어떤 행동을 취했는지가 모두 기록으로 남게 되는데, 이 기록들이 로그입니다. 로그는 IT 환경에서 가장 많이 발생하지만, 데이터 처리 기술이 발달하지 않았던 시기에는 처리 비용에 비해 가치가 낮은 데이터로 여겨졌습니다. 하지만 최근들어 IT 서비스와 인프라가 다양해지고 디지털 트랜스포메이션이 가속화되면서, 로그의 양이 기하급수적으로 증가하고 사물인터넷(IoT), 빅데이터 등과 같은 신기술이 발전하면서 그 효용성 또한 날로 증가하고 있습니다. 그렇다면, 이 로그는 실제로 어떻게 활용될까요? 개발 영역에서는 버그 혹은 크래시율 수집 및 상시 트래킹, 이슈 발생 후 롤백 및 대응, 특정 기능에 대한 사용성 진단에 활용됩니다. 마케팅 분야는 채널별 ROI 진단 및 비용 최적화, 배너/프로모션/이벤트 효과 측정, 유저 세그멘테이션 및 타게팅에 사용합니다. 기획 및 디자인 영역은 기능 개선을 위한 A/B 테스트, 유저 Journey 경로 분석을 통한 UX/UI 최적화 등에서 쓰이고 있습니다. 이처럼 여러 영역에서 다양하게 쓰이는 로그를 관리하지 않고 방치해두면 어떤 일이 발생할까요? 통합로그관리가 필요한 이유에 대해 알아보겠습니다. ----------------------------------------------- I. 보안 대응체계 구축 저장만 하고 관리되지 않은 로그는 IT 시스템의 장애나 문제 발생 시 그 원인을 찾아내기가 어렵습니다. 또, 로그 데이터의 중요 정보가 외부로 유출될 위험도 커집니다. 끊임없이 발생하는 보안 사고에 대비하기 위해 통합로그관리는 반드시 필요합니다. 관리된 로그는 장애나 사고 발생 시에 그 원인을 파악하고 빠른 대처를 위한 근거 데이터로 사용할 수 있으며, 보안 체계를 마련하는 데에도 활용가능 합니다. 기업들은 로그관리 제품을 사용해 사이버 침해위협을 예방 및 감시하고, 정기적인 로그분석을 통해 강력한 보안대응체계를 구축하고 있습니다. 통합로그관리 솔루션은 보안장비(Firewall, IDC, IPS 등)의 로그와 해킹, 악성코드 등 보안/침해 관련 로그를 지속적으로 분석해 예방 체계를 구축합니다. 또, 대용량 로그의 상관분석을 통해 보안위협을 탐지하고 이상징후를 모니터링하는 등 강력한 보안 대응체계를 구축할 수 있습니다. II. 컴플라이언스 준수 로그는 보안 사고가 발생했을 때 가장 기본적인 증거 및 모니터링 자료로 활용됩니다. 이에 따라 정부에서는 데이터 관리에 대해 각종 법률을 규정하고 있어, 공공기관을 비롯한 개인정보를 다루는 온라인 사업자 및 기업 등은 해당 법규를 준수해야 합니다. 안전한 데이터 이용을 위해 2018년에 발의된 '데이터 3법' 개정안은 2020년 1월 9일 국회 본회의를 통과했습니다. 데이터 3법은 개인정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등 3가지 법률을 통칭합니다. 로그 관리 관련 규제의 주요 내용은 다음과 같습니다. i. 개인정보보호를 위해 접근 권한 부여, 변경 또는 말소 기록을 3년 이상 보관해야 합니다. ii. 개인정보 취급자는 개인정보처리시스템의 접속기록을 월 1회 이상 점검해야 하고, 그 활동의 증거를 남기기 위해 시스템에 접속했다는 기록을 1년 이상 보관해야 합니다. iii. 정보통신서비스 제공자는 접근 권한 내역을 5년간 보관하고, 접속 기록의 위·변조 방지를 위해 반드시 백업 보관해야 합니다. III. 빅데이터 처리 플랫폼 IT 인프라 확대 및 기타 비정형 로그 유입에 따라 대용량 로그에 대한 관리가 요구되고 있습니다. 특히 수집된 로그를 실시간으로 분석∙판단해 IT 서비스의 안정적 운영을 도모해야 하는 수요가 증대되고 있는데요. 오늘날의 데이터는 기존 데이터에 비해 양이 매우 방대해 기존 방법이나 도구로는 관리가 어렵습니다. 따라서 빅데이터 기술을 기반으로 하는 대용량 통합 로그관리 솔루션은 이제 IT 운영을 위한 필수 솔루션으로 자리잡았습니다. ----------------------------------------------- 이처럼 기업은 보안위협 및 이상징후 대응/컴플라이언스 준수/대용량 로그 관리를 위해 통합로그관리 솔루션을 필수로 갖춰야합니다. 브레인즈컴퍼니의 통합로그관리 솔루션 '제니우스(Zenius) Logmanager'는 이기종 장비에서 발생되는 정형∙비정형 로그 데이터의 수집/분석/관리 등을 위한 빅데이터 플랫폼입니다. 제니우스 로그매니저가 어떻게 구성돼 있는지 살펴보겠습니다. 제니우스 로그매니저는 정형/반정형 또는 비정형 로그에 대한 실시간 수집 및 신속한 분석 기능을 제공하며, 이러한 정보들을 다양한 차트와 대시보드를 통해 직관적으로 가시화합니다. 특히 로그매니저는 독보적인 인덱싱 및 검색 속도를 제공하며 확장성, 편의성, 효율성, 호환성 등의 특장점을 보유한 제품입니다. 로그 이벤트 발생 시 즉각적인 알람을 통해 빠른 문제 해결과 높은 가용성을 확보하도록 지원합니다.
2022.11.10
다음 슬라이드 보기