반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
최신이야기
검색
기술이야기
ICMP와 SNMP를 비롯한 NMS의 구성요소와 주요 기능은?
기술이야기
ICMP와 SNMP를 비롯한 NMS의 구성요소와 주요 기능은?
지난 포스팅을 통해서 NMS의 기본 개념과 시대별 변화, 그리고 활용 사례 등을 살펴보았는데요. 오늘은 ICMP와 SNMP를 비롯한 NMS의 구성 요소와 주요 기능에 대해서 자세히 알아보겠습니다. 。。。。。。。。。。。。 │ NMS(네트워크 관리 시스템)의 구성 요소와 역할 NMS의 구성 요소와 역할은 크게 다섯 가지로 나눌 수 있습니다. NMS Manager NMS Manager는 Managed Device를 모니터링하고 제어하는 역할을 합니다. SNMP, ICMP, RMON 등의 망 관리 프로토콜을 이용하여 Managed Device 정보를 수집하며 User Interface도 제공합니다. Management Agent (SNMP Agent) 독자적으로 트래픽을 모니터링하고, 통계 정보를 자신의 MIB에 저장해 두었다가 트래픽 정보 요구나 특정 동작 요청에 응답합니다. 또한 망 관리 프로토콜을 활용하여 Manager에게 관리 정보를 전달합니다. Managed Device 백본, 스위치, 라우터, 허브와 같은 네트워크 장비를 말하며 Management Information을 수집하여 MIB에 보관합니다. MIB (Management Information Base) Managed Device의 정보를 포함한 Database 역할을 수행합니다. 관리되는 정보들을 계층적 트리 구조로 구성되고, 망 관리용 프로토콜인 SNMP 등에 의해서 읽힙니다. SNMP Protocol 네트워크 장치로부터 정보를 수집하여 작업을 수행하는 응용 계층의 프로토콜입니다. MIB에 정의되어 있는 객체들의 OID 값을 전달받아 해당 장비의 상태를 나타냅니다. │ NMS 구성 요소의 상호작용 NMS 구성 요소의 상호 작용을 자세히 살펴보면 각각의 네트워크 장비에는 SNMP Agent가 내장되어 있고, MIB를 이용해 네트워크의 상태 및 구성에 대한 정보를 요청하고 응답받습니다. Agent는 관리 정보를 수집하며, SNMP 프로토콜을 이용하여 NMS Manager와 통신을 합니다. NMS Manager의 Server 단에서는 SNMP가 수집한 데이터를 기반으로 분석, 가공, 성능, 구성, 장애, 보안, 운영 등의 관리 작업을 수행합니다. 또한 DB 단에서는 이벤트 및 로그를 기록하여 문제 해결 및 보고에 사용하는데요. 최종적으로는 User Interface를 통해 운영자가 네트워크 장비들을 효율적으로 모니터링하고 관리하기 위한 가시적인 화면을 제공합니다. │ NMS의 데이터 수집 방식 (관련 프로토콜) NMS는 여러 가지 성능 정보를 수집하여 모니터링하기 위해 다양한 프로토콜을 사용합니다. ① SNMP(Simple Network Management Protocol) 네트워크 장비를 관리하고 모니터링하기 위해 사용되는 인터넷 표준 프로토콜입니다. 네트워크 관리자가 네트워크에 연결된 상태를 확인하고 필요한 경우 설정을 변경할 수 있도록 설계되었고, 대부분 NMS 상에 구현되어 이용되고 있습니다. TCP/IP 기반에서 망관리를 위한 프로토콜이며, 관리 대상과 시스템 간 관리 정보(MIB)를 주고받기 위한 규정입니다. Manager(NMS), Agent, MIB(Management Information Base), Managed Device 등으로 구성됩니다. SNMP의 처리 단계는 Get/Set/Trap의 단순 명령 구조로 구성됩니다. SNMP의 메시지 타입은 Get/Set/Trap의 단순 명령 구조로 구성되는데요, 메세지 타입별 역할은 아래와 같습니다. ② ICMP (Internet Control Message Protocol) IP(Internet Protocol) 네트워크의 기기들이 서로 통신 상태 정보와 오류 메시지를 교환하기 위해 사용하는 네트워크 레벨 프로토콜로, 주로 네트워크 장비와 서버 간의 연결 문제를 진단하고 보고하는 데 사용됩니다. ICMP의 주요 기능은 크게 두 가지입니다. ◾ 오류보고(Error Reporting): 네트워크에서 데이터를 전송하는 동안 발생할 수 있는 여러 종류의 오류를 감지하고, 이에 대한 정보를 송신자에게 알리는 기능 ◾ 진단도구(Diagnostic Functions): 네트워크 연결 문제를 진단하는 데 사용되는 유틸리티(예: ping, traceroute)는 ICMP 메시지를 활용하여 네트워크의 상태를 확인합니다. 이를 통해 네트워크의 연결 상태, 지연 시간, 패킷 손실 등을 평가할 수 있습니다. 먼저 SNMP와 ICMP를 살펴보았는데요, 잠깐 두 가지 방식을 자세히 비교해 보면 SNMP는 장치 모니터링, 구성 변경, 이벤트 알림을 제공하며 주로 관리자 중심의 기능을 수행합니다. 반면 ICMP는 네트워크 통신의 에러 및 상태를 보고하고 호스트 간의 연결성을 테스트하는 데 사용되며, 주로 이벤트 기반 및 연결성 확인을 위한 메시지를 전송하는 데 중점을 둡니다. NMS의 데이터 수집 방식에 대해서 계속 살펴보겠습니다. ③ RMON (Remote Network Monitering) SNMP의 확장 형태로 개발된 RMON은, 분산되어 있는 망에 대한 트래픽을 측정하여 망을 감시하고 분석을 제공하는 프로토콜입니다. 원격에 위치한 Probe에서 망자원의 상태 정보를 수집하여 에러를 방지하고 효율적으로 이용하는 것을 목적으로 합니다. NMS의 대표적인 수집 방식을 살펴보았는데요, 이 외에도 다양한 방식이 있기 때문에 NMS 솔루션은 다양한 방식을 지원하는 것이 중요합니다. (*브레인즈컴퍼니의 Zenius-NMS는 SNMP와 ICMP 외에도 RMON, CDP, LLDP 프로토콜 등 다양한 수집 방식을 지원하고 있습니다.) │ NMS의 경보 알림 연계 방식 네트워크 내의 장애나 이상 상태를 감지했을 때 관리자나 담당자에게 이를 알리는 방법으로, NMS의 핵심이라고 할 수 있습니다. 다양한 경보 알림 방식이 있으며, 각 방식은 특정 상황이나 니즈에 맞게 선택되고 있는데요 가장 대표적인 방식들을 알아보겠습니다. 이메일(E-mail) 알림 네트워크 성능이 저하되는 등의 문제가 발생하면, 이메일 시스템과 연계하여 설정된 이메일 주소로 자동으로 알림을 발송합니다. 문제 발생 시 기록을 남기기 쉽다는 장점이 있지만, 긴급한 문제에는 이메일을 확인하는데 지연이 발생할 수 있습니다. 문자 메시지(SMS) 알림 네트워크의 문제 감지 시, NMS는 사전에 등록된 휴대전화 번호로 경보의 성격과 간단한 설명을 포함한 SMS 메시지를 보냅니다. 신속한 알림이 가능하다는 장점은 있지만, 메시지 길이에 제한이 있다는 단점도 있습니다. 메신저 및 협업 툴을 사용한 알림 최근 많이 사용되는 슬랙, 텔레그램, 팀스, 카카오톡을 통해 네트워크의 이상을 알리는 방식입니다. 문자 메시지와 같이 신속한 알림이 가능하면서 메시지 길이에 크게 제한이 없다는 장점도 있습니다. Dashboard를 통한 이벤트 관제 특정 경보가 발생하면, 웹 기반의 대시보드에 경보 메시지를 포함하여 관리자가 시각적으로 확인할 수 있도록 알립니다. 직관적으로 실시간 네트워크 상태를 모니터링할 수 있는 것이 가장 큰 장점입니다. 서버, 네트워크, 부대설비 모듈을 포함한 Zenius-Dashboard 예시 화면 위와 같이 다양한 알림 연계 방식을 통해, 담당자에게 즉시 장애 처리를 할 수 있도록 지원하는 기능도 중요합니다. NMS에서 즉각적인 장애를 처리하기 위해 제공하는 기능은 다음과 같습니다. ◾ 다중 수신자 지원: 여러 관리자나 담당자에게 동시에 경보를 전송하여 여러 관리자가 신속하게 대응할 수 있게 합니다. ◾ 알림 임계값 설정: 관리자는 경보 발생을 위한 임계값을 설정할 수 있습니다. (예: 특정 장치의 성능이 일정 수준 이하로 떨어질 때 알림을 발생시키도록 설정) ◾ 장애 관리 자동화: 특정 이벤트에 대해 미리 정의된 복구 스크립트 및 시나리오를 통해 장애 감지부터 처리까지의 장애 관리 업무를 자동화할 수 있습니다. NMS의 경보 알림 방식을 살펴보았는데요, 이제 NMS의 주요 기능을 자세하게 알아보겠습니다. │ NMS의 주요 기능 자세히 보기 NMS는 네트워크의 효율성, 가용성, 보안 등을 관리하고 감시하기 위한 다양한 기능을 제공합니다. 보편적으로 NMS에서 제공하는 상세 기능들은 아래와 같이 정리할 수 있습니다. NMS는 장애 관리, 구성 관리, 성능 관리를 중심으로 다양한 세부 기능을 가지고 있습니다. NMS의 많은 기능 중에서도 특히 네트워크 장비들을 실시간으로 모니터링할 수 있는 '성능 관리' 기능과, 성능 저하 또는 병목 현상을 빠르게 식별하여 해결할 수 있는 '장애 관리' 기능이 중요합니다. │ NMS의 발전 방향 NMS는 복잡하고 빠르게 변화하는 기술 트렌드에 맞춰 지속적으로 발전하고 있습니다. 클라우드, 가상화, 5G, IoT와 같은 기술의 발전에 따라서 사용자에게 높은 품질의 서비스를 제공하기 위한 방향으로 진화하고 있습니다. 온 프레미스와 클라우드의 조화 온 프레미스 환경은 보안, 규정 준수, 네트워크 제어와 같은 니즈 때문에 여전히 중요한 역할을 하고 있습니다. 반면 클라우드 기반 NMS 솔루션은 비용 효율성, 안정성, 용이한 배포와 같은 이점을 제공하는데요. 따라서 NMS도 온 프레미스와 클라우드의 장점을 조화롭게 포함하며 발전하고 있습니다. 클라우드 네이티브 환경으로의 진화 기업과 기관들이 클라우드 서비스를 적극적으로 채택함에 따라 NMS는 클라우드의 유연성, 확장성, 효율성을 극대화하는 등 클라우드 환경에 더욱 적합한 구조로 발전하고 있습니다. 분산형 아키텍처와 기술 혁신 최근의 NMS는 중앙 집중식에서 벗어나 더욱 분산된 아키텍처를 채택하고 있습니다. 마이크로 서비스 아키텍처(MSA)를 통해 모듈화되고 유연한 시스템 구조를 도입하여, 필요한 기능을 쉽게 추가하거나 변경할 수 있습니다. 또한 AI 기반의 NMS는 네트워크 데이터를 분석하고, 문제의 예측 및 해결 능력 향상에 기여하고 있습니다. 이 밖에도 NMS는 5G와 IoT 등의 신기술에 효과적으로 대응하기 위해 지속적으로 발전하고 있습니다. 。。。。。。。。。。。。 NMS의 구성 요소와 주요 기능 그리고 발전 방향에 대해서 살펴봤습니다. NMS 솔루션을 선택할 때는 기본적인 기능을 잘 갖추고 있을 뿐 아니라, 혁신적인 기술과 트렌드를 적극적으로 채택하고 지속적인 연구와 개선을 지속하는 기업의 솔루션을 선택해야 합니다. 안정적인 네트워크 운영은 이제 비즈니스의 필수 요소입니다. 성공적인 NMS 솔루션 선택을 통해 네트워크 성능을 극대화하여 비즈니스의 경쟁력을 확보하시기 바랍니다!
2024.02.08
기술이야기
NMS(네트워크 관리 시스템)에 대해서 꼭 알아야 할 네 가지
기술이야기
NMS(네트워크 관리 시스템)에 대해서 꼭 알아야 할 네 가지
산업 분야를 통틀어서 최근 모든 기업과 공공기관들의 ‘네트워크’ 활용도와 의존도가 빠르게 증가하고 있습니다. 따라서 이제 ‘안정적인 네트워크 관리 = 성공적인 비즈니스 운영’이라고도 할 수 있는데요. 오늘은 네트워크를 안정적으로 유지해서 성공적인 비즈니스 운영을 도와주는, NMS(Network Management System, 네트워크 관리 시스템)에 대해서 자세히 알아보겠습니다. NMS의 등장 배경, 시대별 변화, 그리고 핵심 개념과 실제 사례까지 NMS에 대해서 꼭 알아야 할 네 가지는 무엇일까요? 。。。。。。。。。。。。 │NMS(네트워크 관리 시스템)의 기본 개념과 등장 배경 NMS란 다양한 이기종 네트워크 장치(Network device)를 중앙에서 관리하고 감시할 수 있는 시스템입니다. 즉 전체 네트워크를 중앙 시스템을 통해 모니터링, 진단, 분석, 가용성을 유지하기 위해 만들어진 시스템을 말합니다. NMS의 필요성과 등장 배경은 OSI의 SMFAs(Specific Management Functional Areas)의 다섯 가지 영역(FCAPS)로 정리할 수 있습니다. 장애관리(Fault Management): 경보 감시, 고장 위치의 측정 시험 등 NMS의 첫 번째 관심사는 네트워크의 가용성을 보장하는 것입니다. 네트워크에서 발생하는 장애를 감지·격리·복구하는 과정으로, 네트워크 가동 시간을 최대화하고 서비스 중단을 최소화하는 것이 목적입니다. 구성 관리(Configuration Management): 설비제공, 상태 제어, 설치 지원 등 네트워크의 구성 요소(하드웨어, 소프트웨어, 네트워크 설정 등)를 관리하는 과정으로, 네트워크의 변경 사항을 추적하고 일관된 네트워크 성능과 안정성을 유지하는 데 중요합니다. 계정관리(Accounting Management): 계정(과금) 정보의 수집/저장/제어 등 네트워크 자원의 사용량을 추적하고 기록하는 과정이며, 자원의 할당과 과금에 사용됩니다. 사용량, 사용시간, 서비스 품질, 장비 사용률 등 네트워크 관리 및 운영에 관한 비용 할당 시 필요합니다. 성능 관리(Performance Management): 성능감시/트래픽 관리/품질관리/통계관리 네트워크의 트래픽이 특정 시간에 급증하는 것을 성능 관리 시스템이 감지했을 때, 이 정보를 사용하여 네트워크 용량을 적절히 조정하거나 트래픽을 분산시킬 수 있습니다. 보안 관리(Security Management): 보안/안전/기밀 관리 등 보안 관리 시스템은 사용자의 무단 엑세스 시도를 감지하며 즉시 차단할 수 있는 접근 제어, 인증, 암호화, 키관리 등을 관리하는 것과 관련이 있습니다. 네트워크 인프라의 로그 모니터링을 통해 잠재적인 보안 문제를 사전에 예방할 수 있습니다. 위와 같은 등장 배경과 필요성을 가진 NMS, 시대별로는 어떻게 변해왔는지 살펴보겠습니다. │NMS(네트워크 관리 시스템)의 시대별 변화 1980년대 초부터 현재에 이르기까지 NMS의 시대별 변화를 간략히 살펴보면 다음과 같습니다. 1980년대 ~ 2010년대 초 1980년대에 등장한 초기 NMS는 단순한 모니터링과 제어에 둔 간단한 형태였고, 특정 벤더의 하드웨어에 종속되고 표준화가 제대로 이루어지지 않았었습니다. 1990년대에 들어서 네트워크의 복잡성이 커지면서 NMS의 필요성도 증가했습니다. 이때 보안 기능이 향상된 SNMPv2와 같은 표준 프로토콜이 도입되면서, 다양한 제조사의 장비를 하나의 시스템으로 통합 관리할 수 있게 되었습니다. 또한 네트워크뿐만 아니라 서버까지 같이 관리하기 위한 SNMS(Server and network Management System)와, 더 나아가 EMS(ITIM)도 나오게 되었습니다. 이후 2000년대 초반에 웹 기반 NMS 솔루션이 등장하면서, 사용자 친화적인 인터페이스와 원격 접근 기능 등을 통해 효율적인 네트워크 관리가 가능해졌습니다. 2010년대 중반 ~ 2010년대 후반 NMS는 2010년대 중반부터 등장한 클라우드 컴퓨팅, 빅데이터, 인공지능(AI) 등의 기술과 함께 더욱 고도화되었습니다. 점점 더 다양한 네트워크와 서비스를 통합 관리하며, 자동화된 분석과 의사결정을 지원하게 되었습니다. 최신 동향 최근에는 AI와 머신러닝을 활용하여 예측 분석, 네트워크의 자동 최적화, 사이버 보안 통합 등이 NMS의 중요한 요소로 강조되고 있습니다. 또한 새로운 네트워크 기술인 5G의 도입으로 NMS는 더욱 복잡해지고 다양한 네트워크 환경을 관리하게 되었습니다. 이처럼 NMS는 네트워크 기술의 발전과 산업의 변화에 발맞추어, 지속적이고 빠르게 발전하고 있습니다. 이제 NMS의 구조에 대해서 자세히 알아보겠습니다. │NMS(네트워크 관리 시스템)의 3-Tier 아키텍처 NMS는 3-Tier 아키텍처(수집-저장-표출)로 구성되어 있습니다. 각각 독립된 계층으로 구분되어 있는데요. 특정 부분의 업그레이드가 필요할 때 해당 계층만 영향을 주기 때문에 시스템을 보다 쉽게 관리할 수 있습니다. 다시 정리한다면 NMS Manager에서 SNMP · ICMP · RMON 등 다양한 네트워크 프로토콜을 활용하여, 네트워크 자원의 성능 데이터를 수집합니다. 만약 Managed Device 장비들이 한계치에 도달하거나 장애가 발생했을 경우, 즉각적으로 User Interface를 통해 사용자에게 알립니다. 그렇다면 NMS의 핵심 기능은 무엇일까요? │NMS(네트워크 관리 시스템)의 핵심 기능 네트워크 장애에 대한 신속한 파악과 대응이 반드시 필요한 NMS의 핵심 기능에는 어떤 것들이 있는지 자세히 살펴보겠습니다. 장애 관리 네트워크 인프라의 결함이나 오류를 탐지하고 경고 및 알림을 생성하여, 관리자가 신속하게 대응할 수 있도록 지원합니다. 이를 통해 다운타임을 최소화하고 서비스 지속성을 보장합니다. 예를 들어 네트워크의 라우터가 다운될 경우, NMS는 즉시 관리자에게 경고를 보내 신속한 문제 해결을 도와줍니다. 성능 관리 네트워크 구성 자원인 트래픽 가용성, 응답시간, 사용량, 오류량, 처리 속도 등을 추적하고 최적화합니다. 또한 부하가 발생하지 않도록 문제점을 미리 검출해 안정적인 네트워크 운영이 될 수 있도록 합니다. 예를 들어 특정 애플리케이션이 과도한 대역폭을 소비할 경우, NMS가 문제를 정확히 찾아내서 관리자가 네트워크를 최적화할 수 있도록 돕습니다. ▲ 제니우스(Zenius)를 활용한 성능 모니터링 화면 예시 구성 관리 관리자는 NMS를 통해 분산된 네트워크 장치 구성 프로세스를 자동화하여, 네트워크 전반에 걸쳐 일관성과 정확성을 보장할 수 있습니다. 이러한 핵심 기능을 하는 NMS의 구체적인 활용 사례를 살펴보겠습니다. │NMS(네트워크 관리 시스템)의 활용 사례 IT 분야뿐 아니라 제조업, 금융, 여행, 유통 및 물류 등 전 분야에 걸쳐서 NMS가 사용되고 있습니다. 특히 처리 속도, 가용성, 보안 등이 중요한 금융산업의 경우에 NMS를 통한 안정적인 관리가 중요한데요. 브레인즈컴퍼니의 제니우스(Zenius) EMS를 사용하고 있는 S금융사의 사례를 자세히 살펴보겠습니다. S금융사, Zenius NMS를 통해 완벽하게 네트워크를 관리하게 되다 S금융사는 서버만 800ea, NW 14,000ea 이상의 대규모 인프라를 보유하고 있었습니다. 하지만 Zenius NMS 도입 전까지는 서비스 장애에 영향을 준 네트워크 장애 원인 파악을 위한 장기간 투자하고 있는 상황이었고, 네트워크 운영 현황 데이터 수집과 분석에 많은 시간이 소요되고 있었습니다. 무엇보다 신속한 장애 인지와 처리가 어려워서 큰 고민이 있었는데요. 위 도표에서도 살펴본 것처럼 Zenius NMS 도입을 통해, 이전에 고민과 단점을 극복하고 안정적으로 네트워크 관리를 할 수 있게 되었습니다. 특히 Zenius NMS는 고성능의 Manager를 제공하고 있어 대규모 환경에서도 장애를 신속하게 판단하여, 타사 대비 많은 자원을 효율적으로 관리할 수 있습니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼 NMS는 네트워크 인프라를 효율적으로 관리하는데 가장 중요한 역할을 합니다. 제니우스(Zenius) NMS처럼 고성능의 Manager를 기반으로 네트워크 상태를 신속하게 판단하며, 유저 중심의 통합 UI를 제공하는 NMS 솔루션을 꼭 선택하시기 바랍니다!
2024.01.31
회사이야기
제니우스(Zenius), 웰메이드 드라마와 언론사에서도 주목하다
회사이야기
제니우스(Zenius), 웰메이드 드라마와 언론사에서도 주목하다
오늘 벌써 금요일이네요! 여러분들은 주말 동안 어떻게 보내시나요? 대부분 휴식 시간을 갖거나 등, 소중한 사람들과 함께 시간을 보내실 텐데요. 저 또한 주말 동안 푹 쉬면서, 웰메이드 드라마 를 보며 충전하는 편입니다. 최근에 저는 ENA에서 방영했던 ‘악인전기’를 몰아봤습니다. 악인전기는 생계형 변호사가 엘리트 악인으로 변모하는 이야기를 담고 있습니다. 개인적으로 웰메이드의 완성은 명품 연기력이라고 생각하는데요. 흠잡을 때 없는 명품 연기를 선보여주신 신하균 배우님이 출연하여, 드라마에 더 몰입할 수 있었습니다. 그렇게 악인전기를 몰아보며 에너지를 충전하던 중, 깜짝! 놀라고야 말았는데요. 。。。。。。。。。。。。 웰메이드 드라마에 등장한 어디서 많이 본 화면 ▲악인전기 5화 캡쳐 ⓒGENIE TV 악인전기 5화에 정말 낯익은 화면을 볼 수 있었습니다. 바로 제니우스(Zenius) 모니터링 화면이었습니다. 극 중에서 서버 관련된 에피소드 중, 제니우스 SMS(Zenius SMS) 모니터링 화면이 등장한 것이죠! 이 장면을 캡처해서 같은 팀원분들에게 자랑하기도 하고, 메일로도 공유했습니다. 매번 보는 Zenius 제품이었지만, 드라마를 통해 볼 수 있어서 신기하고 뿌듯했습니다. 여기서 잠깐! Zenius SMS의 깨알 자랑을 더 한다면, 초 단위 실시간 그래프를 통해 주요 성능 정밀한 분석이 가능합니다. 이 밖에도 임계치 기반의 장애를 감지하고 통보하며, 체계적인 장애관리를 지원하고 있습니다. Zenius SMS는 모니터링뿐만 아니라, 보안 관리까지 추가적으로 제공해 드리고 있는데요. 행정안전부가 권고하는 보안 항목들을 자동적으로 점검해 드리며, 보안 가이드까지 제공하여 사용자 편의성을 향상시킵니다(더 많은 자랑을 하고 싶지만 일단 여기까지..!). 한국인터넷진흥원도 선택한 제니우스 대시보드 ▲ⓒvoakorea 사실 드라마 ‘악인전기’뿐만 아니라, 제니우스 대시보드(Zenius Dashboard)가 기사와 신문 지면에 노출된 이력도 있는데요. 위 사진은 한국인터넷진흥원(KISA) 침해대응센터에 제공해 드린 대시보드 화면입니다. 고객사에서 사용하던 로그와 데이터를 연계하여, 원하는 방향으로 화면을 커스터마이징한 것인데요. ‘맞춤’으로 제작된 대시보드를 통해 보안 침해 상황을 직관적이고 효율적으로 관리할 수 있어, 고객사에서도 크게 만족하셨습니다. 특히 최근 소프트웨이브2023 전시회에서도 “대시보드가 예쁘다”라는 피드백과 참관객들 또한 매우 많았습니다. 。。。。。。。。。。。。 제가 재미있게 본 드라마에서 제니우스 제품을 우연히 발견하며, 신기하고 자랑스럽기도 했던 순간이었습니다. 앞으로도 제니우스 찾기는 계속 됩니다 To be continued-!
2024.01.12
기술이야기
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
기술이야기
쿠버네티스와 Helm 등 CNCF의 주요 프로젝트
지난 포스팅을 통해 정리한 것처럼 CNCF는 클라우드 네이티브 생태계의 활성화를 위해, 다양한 오픈소스 프로젝트를 개발하고 공급하고 있습니다. 또한 프로젝트 채택 단계부터 사용 빈도까지의 성숙도를 관리하기 위한, 프로세스 체계를 보유하고 있는데요. 이번 시간에는 CNCF의 주요 프로세스인 쿠버네티스(K8s), Helm 등과 CNCF 프로세스에 대해서 알아보고자 합니다. 。。。。。。。。。。。。 CNCF 프로젝트 프로세스 2023년 10월 기준으로 약 170여 개의 CNCF 프로젝트가 진행 중인데요. 이들 프로젝트는 성숙도에 따라서 샌드박스(Sandbox), 인큐베이팅(Incubating), 졸업(Graduated)으로 나뉩니다. 성숙도 수준에 대한 평가는 CNCF 위원회 멤버들에 의해서 결정되며, 졸업(Graduated) 단계의 프로젝트로 인정받기 위해서는 3분의 2 이상의 찬성 표가 필요합니다. ▲프로젝트 성숙도 단계 Step1. 샌드박스(Sandbox) CNCF의 새로운 프로젝트가 채택되면 Sandbox 단계에서 시작합니다. 이 단계에서는 프로젝트가 CNCF의 가이드라인과 정책에 부합되는지를 확인하는 절차를 주로 거칩니다. Step2. 인큐베이팅(Incubating) Sandbox를 통과한 프로젝트는 Incubating 단계로 집입하며, 이 단계에서는 프로젝트의 커뮤니티와 기술적 성숙도를 더욱 강화하도록 합니다. 해당 프로젝트의 커뮤니티의 규모와 다양성을 평가하고 기능들의 안정성을 검증합니다. Step3. 졸업(Graduated) Incubating 단계를 성공적으로 통과한 프로젝트는 Graduated 단계로 올라갑니다. 높은 수준의 품질과 안정성이 보장되어야 이 단계에 올라갈 수 있는 거죠. 커뮤니티가 활발하게 유지되고 관련자의 참여가 적극적으로 이루어져야 하며, 실제 사용 사례에서 성공한 경험들이 존재해야 합니다. Step4. 사용 사례 검증 Graduated 프로젝트 중 실제로 다양한 산업에서 사용되고, 기업과 조직이 해당 프로젝트를 많이 채택하는지를 평가하여, 지속적인 성장 가능성과 성숙도를 평가합니다. CNCF에서 관리하는 프로젝트 영역은 꽤 넓고 다양한데요. 애플리케이션 개발을 위한 도구부터 컨테이너 오케스트레이션, 서비스 프로비저닝, 모니터링 도구 등 소프트웨어 개발부터 운영까지를 위한 도구들이 존재합니다. 이제부터는 가장 성공적인 프로젝트인 쿠버네티스를 포함하여, Incubating 단계 이상의 프로젝트를 알아보고자 합니다. CNCF의 주요 프로젝트 쿠버네티스(kubernetes) 쿠버네티스는 CNCF에서 최초로 Graduated 단계에 진입한 프로젝트입니다. 컨테이너 오케스트레이션 기능을 통해, 애플리케이션 컨테이너 기반으로 자동화하고 확장할 수 있는 플랫폼을 제공합니다. A. 컨테이너 오케스트레이션 기능 컨테이너화된 애플리케이션을 자동으로 배포·확장하고 관리하는 기능을 제공합니다. 애플리케이션의 변경이 필요할 경우, 개발자가 애플리케이션을 빠르게 수정 및 배포하고 운영할 수 있게 합니다. B. 스케일링 기능 리소스 사용량이나 사용자 트래픽 증가에 따라 자동으로 애플리케이션을 확장·축소하는 오토 스케일링 기능을 제공합니다. C. 롤백 기능 문제가 발생된 애플리케이션의 경우, 롤백 기능을 제공하여 서비스 장애에 신속히 대응합니다. Helm Helm은 쿠버네티스 환경에서 애플리케이션을 관리하기 위한 도구로 사용됩니다. Helm은 차트라고 불리는 패키지로 애플리케이션을 패키징 하는데요. 이 차트에는 애플리케이션의 설치부터 관리에 필요한 모든 것을 포함합니다. 쉽게 말하면 이 차트라는 기능을 통해 애플리케이션을 탬플릿화하고, 배포하며, 롤백 및 공유하는 역할을 하는 프로젝트입니다. Envoy ▲Envoy를 사용하는 주요 업체 리스트 ⓒenvoyproxy.io Envoy는 클라우드 네이티브 환경에서 애플리케이션의 네트워크 트래픽을 관리하고, 제어하기 위한 프로젝트입니다. 프록시 기능을 수행하고, 클라이언트 서버 간의 통신을 관리하며, 애플리케이션 간의 통신의 보안 향상시킵니다. 여러 애플리케이션 사이에서 부하 분산을 자동화하여 가용성과 성능을 향상시킬 수 있도록 합니다. 부하 분산을 함에도 불구하고 특정 시스템에 부하가 생겨 장애 발생이 생길 경우, 트래픽을 가중치에 따라 다른 시스템으로 분산시키는 역할을 합니다. Containerd Containerd는 쿠버네티스 환경에서 컨테이너를 만들고 실행하는 데 도움을 주는 프로젝트입니다. 개발자가 컨테이너를 만들고 실행시키는 역할을 하며, 필요할 때는 중지하거나 삭제하는 작업을 지원합니다. 컨테이너 실행에 필요한 파일과 설정을 모아 놓은 이미지를 다운로드하고, 저장하며, 불러오는 역할과 같은 이미지 관리 기능도 제공하고 있습니다. Prometheus Prometheus는 시스템이나 애플리케이션의 동작을 실시간으로 모니터링하고, 이상 상황이 발생할 경우 알림을 줄 수 있는 도구입니다. 다양한 데이터를 수집하고 기록하여 차후 분석 용도로 활용할 수 있습니다. 또한 핵심 지표들을 유형 및 종류별로 제공하여, 다각적인 관점에서의 관찰을 지원합니다. 시스템의 리소스부터 애플리케이션의 동작 및 응답 상태를 적시에 확인하게 해줍니다. Fluentd ▲Fluentd 개념 설명 ⓒfluentd.org Fluentd는 다양한 시스템에서 발생되는 로그 데이터를 수집·처리·전송하는 데이터 수집 도구로서, 스플렁크(SPLUNK)와 유사한 역할을 수행하는 프로젝트입니다. 다양한 소스에서 발생되는 로그를 수집할 수 있을 뿐만 아니라, 원하는 목적지의 저장소까지 전송하는 역할을 수행합니다. 예를 들어 Syslog 등을 실시간 수집하고, 이를 Elasticsearch나 Amazon S3 등의 원하는 저장소로 목적지를 설정할 수 있게 합니다. 。。。。。。。。。。。。 지금까지 살펴본 것처럼, CNCF에서 클라우드 네이티브 생태계 활성화를 위해 다양한 프로젝트를 진행하고 있는데요. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능 등을 속속 출시하고 있습니다. 대표 제품인 제니우스(Zenius)를 통해 클라우드 네이티브의 핵심요소인 컨테이너(Docker)의 상태와 리소를 실시간으로 모니터링할 수 있습니다. MSA 환경을 만들기 위한 필수 도구인 쿠버네티스(K8s)의 Cluster·Node·Pod 등의 구성과 변화를 관찰하며, 이상 상황 알림을 통해 선제적 장애 대응 또한 가능합니다. Zenius에 대해 더 자세히 알고 싶으시다면, 바로 아래 링크를 클릭해 주세요! 🔍더보기 Zenius로 클라우드 네이티브 모니터링하기 CNCF 세 가지 핵심가치(1탄)도 있어요
2024.01.03
기술이야기
카프카를 통한 로그 관리 방법
기술이야기
카프카를 통한 로그 관리 방법
안녕하세요! 저는 개발4그룹에서 제니우스(Zenius) SIEM의 로그 관리 기능 개발을 담당하고 있는 김채욱 입니다. 제가 하고 있는 일은 실시간으로 대용량 로그 데이터를 수집하여 분석 후, 사용자에게 가치 있는 정보를 시각화하여 보여주는 일입니다. 이번 글에서 다룰 내용은 1) 그동안 로그(Log)에 대해 조사한 것과 2) 최근에 CCDAK 카프카 자격증을 딴 기념으로, 카프카(Kafka)를 이용하여 어떻게 로그 관리를 하는지에 대해 이야기해 보겠습니다. PART1. 로그 1. 로그의 표면적 형태 로그(Log)는 기본적으로 시스템의 일련된 동작이나 사건의 기록입니다. 시스템의 일기장과도 같죠. 로그를 통해 특정 시간에 시스템에서 ‘어떤 일’이 일어났는지 파악할 수도 있습니다. 이렇게 로그는 시간에 따른 시스템의 동작을 기록하고, 정보는 순차적으로 저장됩니다. 이처럼 로그의 핵심 개념은 ‘시간’입니다. 순차적으로 발생된 로그를 통해 시스템의 동작을 이해하며, 일종의 생활기록부 역할을 하죠. 시스템 내에서 어떤 행동이 발생하였고, 어떤 문제가 일어났으며, 유저와의 어떤 교류가 일어났는지 모두 알 수 있습니다. 만약 시간의 개념이 없다면 어떻게 될까요? 발생한 모든 일들이 뒤섞이며, 로그 해석을 하는데 어려움이 생기겠죠. 이처럼 로그를 통해 시스템은 과거의 변화를 추적합니다. 똑같은 상황이 주어지면 항상 같은 결과를 내놓는 ‘결정론적’인 동작을 보장할 수 있죠. 로그의 중요성, 이제 조금 이해가 되실까요? 2. 로그와 카프카의 관계 자, 그렇다면! 로그(Log)와 카프카(Kafka)는 어떤 관계일까요? 우선 카프카는 분산 스트리밍 플랫폼으로서, 실시간으로 대용량의 데이터를 처리하고 전송하는데 탁월한 성능을 자랑합니다. 그 중심에는 바로 ‘로그’라는 개념이 있는데요. 좀 더 자세히 짚고 넘어가 보겠습니다. 3. 카프카에서의 로그 시스템 카프카에서의 로그 시스템은, 단순히 시스템의 에러나 이벤트를 기록하는 것만이 아닙니다. 연속된 데이터 레코드들의 스트림을 의미하며, 이를 ‘토픽(Topic)’이라는 카테고리로 구분하죠. 각 토픽은 다시 *파티션(Partition)으로 나누어, 단일 혹은 여러 서버에 분산 저장됩니다. 이렇게 분산 저장되는 로그 데이터는, 높은 내구성과 가용성을 보장합니다. *파티션(Partition): 하드디스크를 논리적으로 나눈 구역 4. 카프카가 로그를 사용하는 이유 로그의 순차적인 특성은 카프카의 ‘핵심 아키텍처’와 깊게 연결되어 있습니다. 로그를 사용하면, 데이터의 순서를 보장할 수 있어 대용량의 데이터 스트림을 효율적으로 처리할 수 있기 때문이죠. 데이터를 ‘영구적’으로 저장할 수 있어, 데이터 손실 위험 또한 크게 줄어듭니다. 로그를 사용하는 또 다른 이유는 ‘장애 복구’입니다. 서버가 장애로 인해 중단되었다가 다시 시작되면, 저장된 로그를 이용하여 이전 상태로 복구할 수 있게 되죠. 이는 ‘카프카가 높은 가용성’을 보장하는 데 중요한 요소입니다. ∴ 로그 요약 로그는 단순한 시스템 메시지를 넘어 ‘데이터 스트림’의 핵심 요소로 활용됩니다. 카프카와 같은 현대의 데이터 처리 시스템은 로그의 이러한 특성을 극대화하여, 대용량의 실시간 데이터 스트림을 효율적으로 처리할 수 있는 거죠. 로그의 중요성을 다시 한번 깨닫게 되는 순간이네요! PART2. 카프카 로그에 이어 에 대해 설명하겠습니다. 들어가기에 앞서 가볍게 ‘구조’부터 알아가 볼까요? 1. 카프카 구조 · 브로커(Broker) 브로커는 *클러스터(Cluster) 안에 구성된 여러 서버 중 각 서버를 의미합니다. 이러한 브로커들은, 레코드 형태인 메시지 데이터의 저장과 검색 및 컨슈머에게 전달하고 관리합니다. *클러스터(Cluster): 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합 데이터 분배와 중복성도 촉진합니다. 브로커에 문제가 발생하면, 데이터가 여러 브로커에 데이터가 복제되어 데이터 손실이 되지 않죠. · 프로듀서(Producer) 프로듀서는 토픽에 레코드를 전송 또는 생성하는 *엔터티(Entity)입니다. 카프카 생태계에서 ‘데이터의 진입점’ 역할도 함께 하고 있죠. 레코드가 전송될 토픽 및 파티션도 결정할 수 있습니다. *엔터티(Entity): 업무에 필요한 정보를 저장하고 관리하는 집합적인 것 · 컨슈머(Consumer) 컨슈머는 토픽에서 레코드를 읽습니다. 하나 이상의 토픽을 구독하고, 브로커로부터 레코드를 소비합니다. 데이터의 출구점을 나타내기도 하며, 프로듀서에 의해 전송된 메시지를 최종적으로 읽히고 처리되도록 합니다. · 토픽(Topic) 토픽은 프로듀서로부터 전송된 레코드 카테고리입니다. 각 토픽은 파티션으로 나뉘며, 이 파티션은 브로커 간에 복제됩니다. 카프카로 들어오는 데이터를 조직화하고, 분류하는 방법을 제공하기도 합니다. 파티션으로 나눔으로써 카프카는 ‘수평 확장성과 장애 허용성’을 보장합니다. · 주키퍼(ZooKeeper) 주키퍼는 브로커를 관리하고 조정하는 데 도움을 주는 ‘중앙 관리소’입니다. 클러스터 노드의 상태, 토픽 *메타데이터(Metadata) 등의 상태를 추적합니다. *메타데이터(Metadata): 데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터 카프카는 분산 조정을 위해 주키퍼에 의존합니다. 주키퍼는 브로커에 문제가 발생하면, 다른 브로커에 알리고 클러스터 전체에 일관된 데이터를 보장하죠. ∴ 카프카 구조 요약 요약한다면 카프카는 1) 복잡하지만 견고한 아키텍처 2) 대규모 스트림 데이터를 실시간으로 처리하는 데 있어 안정적이고 장애 허용성이 있음 3) 고도로 확장 가능한 플랫폼을 제공으로 정리할 수 있습니다. 이처럼 카프카가 큰 데이터 환경에서 ‘어떻게’ 정보 흐름을 관리하고 최적화하는지 5가지의 구조를 통해 살펴보았습니다. 이제 카프카에 대해 조금 더 명확한 그림이 그려지지 않나요? 2. 컨슈머 그룹과 성능을 위한 탐색 카프카의 가장 주목할 만한 특징 중 하나는 ‘컨슈머 그룹의 구현’입니다. 이는 카프카의 확장성과 성능 잠재력을 이해하는 데 중심적인 개념이죠. 컨슈머 그룹 이해하기 카프카의 핵심은 ‘메시지를 생산하고 소비’ 하는 것입니다. 그런데 수백만, 심지어 수십억의 메시지가 흐르고 있을 때 어떻게 효율적으로 소비될까요? 여기서 컨슈머 그룹(Consumer Group)이 등장합니다. 컨슈머 그룹은, 하나 또는 그 이상의 컨슈머로 구성되어 하나 또는 여러 토픽에서 메시지를 소비하는데 협력합니다. 그렇다면 왜 효율적인지 알아보겠습니다. · 로드 밸런싱: 하나의 컨슈머가 모든 메시지를 처리하는 대신, 그룹이 부하를 분산할 수 있습니다. 토픽의 각 파티션은 그룹 내에서 정확히 하나의 컨슈머에 의해 소비됩니다. 이는 메시지가 더 빠르고 효율적으로 처리된다는 것을 보장합니다. · 장애 허용성: 컨슈머에 문제가 발생하면, 그룹 내의 다른 컨슈머가 그 파티션을 인수하여 메시지 처리에 차질이 없도록 합니다. · 유연성: 데이터 흐름이 변함에 따라 그룹에서 컨슈머를 쉽게 추가하거나 제거합니다. 이에 따라 증가하거나 감소하는 부하를 처리할 수 있습니다. 여기까지는 최적의 성능을 위한 ‘카프카 튜닝 컨슈머 그룹의 기본 사항’을 다루었으니, 이와 관련된 ‘성능 튜닝 전략’에 대해 알아볼까요? 성능 튜닝 전략 · 파티션 전략: 토픽의 파티션 수는, 얼마나 많은 컨슈머가 활성화되어 메시지를 소비할 수 있는지 영향을 줍니다. 더 많은 파티션은 더 많은 컨슈머가 병렬로 작동할 수 있음을 의미하는 거죠. 그러나 너무 많은 파티션은 *오버헤드를 야기할 수 있습니다. *오버헤드: 어떤 처리를 하기 위해 간접적인 처리 시간 · 컨슈머 구성: *fetch.min.bytes 및 *fetch.max.wait.ms와 같은 매개변수를 조정합니다. 그다음 한 번에 얼마나 많은 데이터를 컨슈머가 가져오는지 제어합니다. 이러한 최적화를 통해 브로커에게 요청하는 횟수를 줄이고, 처리량을 높입니다. *fetch.min.bytes: 한 번에 가져올 수 있는 최소 데이터 사이즈 *fetch.max.wait.ms: 데이터가 최소 크기가 될 때까지 기다릴 시간 · 메시지 배치: 프로듀서는 메시지를 함께 배치하여 처리량을 높일 수 있게 구성됩니다. *batch.size 및 *linger.ms와 같은 매개변수를 조정하여, 대기 시간과 처리량 사이의 균형을 찾을 수 있게 되죠. *batch.size: 한 번에 모델이 학습하는 데이터 샘플의 개수 *linger.ms: 전송 대기 시간 · 압축: 카프카는 메시지 압축을 지원하여 전송 및 저장되는 데이터의 양을 줄입니다. 이로 인해 전송 속도가 빨라지고 전체 성능이 향상될 수 있습니다. · 로그 정리 정책: 카프카 토픽은, 설정된 기간 또는 크기 동안 메시지를 유지할 수 있습니다. 보존 정책을 조정하면, 브로커가 저장 공간이 부족해지는 점과 성능이 저하되는 점을 방지할 수 있습니다. 3. 컨슈머 그룹과 성능을 위한 실제 코드 예시 다음 그림과 같은 코드를 보며 조금 더 자세히 살펴보겠습니다. NodeJS 코드 중 일부를 발췌했습니다. 카프카 설치 시에 사용되는 설정 파일 *server.properties에서 파티션의 개수를 CPU 코어 수와 같게 설정하는 코드입니다. 이에 대한 장점들을 쭉 살펴볼까요? *server.properties: 마인크래프트 서버 옵션을 설정할 수 있는 파일 CPU 코어 수에 파티션 수를 맞추었을 때의 장점 · 최적화된 리소스 활용: 카프카에서는 각 파티션이 읽기와 쓰기를 위한 자체 *I/O(입출력) 스레드를 종종 운영합니다. 사용 가능한 CPU 코어 수와 파티션 수를 일치시키면, 각 코어가 특정 파티션의 I/O 작업을 처리합니다. 이 동시성은 리소스에서 최대의 성능을 추출하는 데 도움 됩니다. · 최대 병렬 처리: 카프카의 설계 철학은 ‘병렬 데이터 처리’를 중심으로 합니다. 코어 수와 파티션 수 사이의 일치는, 동시에 처리되어 처리량을 높일 수 있습니다. · 간소화된 용량 계획: 이 접근 방식은, 리소스 계획에 대한 명확한 기준을 제공합니다. 성능 병목이 발생하면 CPU에 *바인딩(Binding)되어 있는지 명확하게 알 수 있습니다. 인프라를 정확하게 조정할 수도 있게 되죠. *바인딩(Binding): 두 프로그래밍 언어를 이어주는 래퍼 라이브러리 · 오버헤드 감소: 병렬 처리와 오버헤드 사이의 균형은 미묘합니다. 파티션 증가는 병렬 처리를 촉진할 수 있습니다. 하지만 더 많은 주키퍼 부하, 브로커 시작 시간 연장, 리더 선거 빈도 증가와 같은 오버헤드도 가져올 수도 있습니다. 파티션을 CPU 코어에 맞추는 것은 균형을 이룰 수 있게 합니다. 다음은 프로세스 수를 CPU 코어 수만큼 생성하여, 토픽의 파티션 개수와 일치시킨 코드에 대한 장점입니다. 파티션 수와 컨슈머 프로세스 수 일치의 장점 · 최적의 병렬 처리: 카프카 파티션의 각각은 동시에 처리될 수 있습니다. 컨슈머 수가 파티션 수와 일치하면, 각 컨슈머는 특정 파티션에서 메시지를 독립적으로 소비할 수 있게 되죠. 따라서 병렬 처리가 향상됩니다. · 리소스 효율성: 파티션 수와 컨슈머 수가 일치하면, 각 컨슈머가 처리하는 데이터의 양이 균등하게 분배됩니다. 이로 인해 전체 시스템의 리소스 사용이 균형을 이루게 되죠. · 탄력성과 확장성: 트래픽이 증가하면, 추가적인 컨슈머를 컨슈머 그룹에 추가하여 처리 능력을 증가시킵니다. 동일한 방식으로 트래픽이 감소하면 컨슈머를 줄여 리소스를 절약할 수 있습니다. · 고가용성과 오류 회복: 컨슈머 중 하나가 실패하면, 해당 컨슈머가 처리하던 파티션은 다른 컨슈머에게 자동 재분배됩니다. 이를 통해 시스템 내의 다른 컨슈머가 실패한 컨슈머의 작업을 빠르게 인수하여, 메시지 처리가 중단되지 않습니다. 마지막으로 각 프로세스별 컨슈머를 생성해서 토픽에 구독 후, 소비하는 과정을 나타낸 소스코드입니다. ∴ 컨슈머 그룹 요약 컨슈머 그룹은 높은 처리량과 장애 허용성 있는 메시지 소비를 제공하는 능력이 핵심입니다. 카프카가 어떤 식으로 운영되는지에 대한 상세한 부분을 이해하고 다양한 매개변수를 신중하게 조정한다면, 어떠한 상황에서도 카프카의 최대 성능을 이끌어낼 수 있습니다! ------------------------------------------------------------ ©참고 자료 · Jay Kreps, “I Hearts Logs”, Confluent · 위키피디아, “Logging(computing)” · Confluent, “https://docs.confluent.io/kafka/overview.html” · Neha Narkhede, Gwen Shapira, Todd Palino, “Kafka: The Definitive Guide” ------------------------------------------------------------
2023.09.19
기술이야기
[브레인저가 알려주는 IT#1] 네트워크 관리, SNMP가 뭔가요?
기술이야기
[브레인저가 알려주는 IT#1] 네트워크 관리, SNMP가 뭔가요?
1. SNMP(Simple Network Management Protocol)란? 컴퓨터 네트워크 장치를 관리하고 모니터링하기 위해 사용되는 네트워크 관리 프로토콜이에요. 네트워크 장치, 서버, 라우터, 스위치, 프린터 등과 같은 네트워크 장치들의 상태를 모니터링하고 구성할 수 있는 표준 방법 또한 제공하고 있어요. 요약한다면 네트워크에 있는 장비들을 관리하기 위한 프로토콜이라고 이해하시면 된답니다! (1) SNMP의 역사 • SNMPv1(1988)초기 SNMP 버전으로 RFC 1067에 정의되었어요. 간단한 모니터링과 설정 변경 기능을 제공했으나, 보안 측면에서 취약점이 있었어요. 커뮤니티 문자열(Community String)을 사용하여 인증을 수행했어요. • SNMPv2(1993) SNMPv1의 한계와 보안 이슈를 개선하기 위해 개발되었어요. 여러 개의 추가 기능을 제공하려 했으나, 규격이 복잡해졌고 보안 문제로 인해 널리 채택되지 않았어요. • SNMPv2c(1996) SNMPv2의 복잡성을 줄이고 보안을 개선한 버전이에요. 커뮤니티 문자열을 계속 사용하여 보안적인 취약성은 여전히 존재했어요. • SNMPv3(1998) 현재까지 널리 사용되고 있는 최신 버전이에요. 보안 기능을 크게 강화하여 데이터 암호화, 사용자 인증, 데이터 무결성 검사 등을 제공하고 있어요. 비동기적인 알림 메커니즘으로 Trap 메시지와 함께 메시지의 암호화 및 보안 기능을 지원해요. • SNMPv3의 보안 개선(2002 이후~) SNMPv3에서 시작된 보안 향상이 계속 발전되어 왔어요. 데이터 암호화와 사용자 인증 등의 기능이 더욱 강화되고, 다양한 보안 솔루션과 표준이 제안되었어요. 2. SNMP의 주요 특징과 역할 (1) 클라이언트-서버 모델 SNMP는 관리자의 명령을 수행하는 에이전트와, 에이전트의 정보를 수집하는 매니저 간의 통신을 기반으로 해요. (2) MIB(Management Information Base) 네트워크 장치의 정보를 계층 구조로 정의한 데이터베이스입니다. 각 정보 항목은 OID(Object Identifier)로 식별되며, 매니저는 OID를 통해 특정 정보를 요청하고 수집할 수 있어요. (3) 동작 방식 • GET: 매니저가 에이전트에게 특정 정보의 값을 요청해요. • SET: 매니저가 에이전트에게 특정 정보의 값을 변경하도록 요청합니다. • TRAP: 에이전트가 이벤트 발생 시 매니저에게 알림을 보내요. (4) 보안 • SNMPv1: 초기 버전으로, 보안에 취약한 프로토콜이었어요. • SNMPv2c: SNMPv1을 확장한 버전으로, 여전히 보안에 취약했어요. • SNMPv3: 보안 강화 버전으로 데이터 암호화, 사용자 인증, 데이터 무결성 검사 등을 지원하여 보안을 강화했어요. (5) 확장 가능성 SNMP는 다양한 버전과 확장 프로토콜을 지원하여 새로운 기능을 추가하거나 보완할 수 있어요. (6) 주요 용도 • 네트워크 장치 모니터링: 장비의 성능, 상태, 트래픽 등 정보를 수집하여 네트워크를 모니터링해요. • 구성 관리: 장치의 설정 변경 및 관리를 원격으로 수행할 수 있어요. • 이벤트 알림: 장애나 이상 상태가 발생하면 즉시 알림을 받을 수 있어요. 이처럼 SNMP는 네트워크 관리에 필수적인 프로토콜 중 하나로, 네트워크의 안정성과 성능을 유지하며 문제를 신속하게 해결하는 데 도움을 준답니다! 3. Zenius에서의 SNMP 활용 안내 (1) NMS 모니터링 SNMP GET 방식으로 데이터를 수집할 수 있어요. SNMP를 활용하여 장비모니터링 화면, 등록된 장비의 장비명, IP, 성능데이터 등을 확인 할 수 있어요. 장비의 상세한 데이터를 모니터링 할 수 있어요. IF 포트의 UP/DOWN과 트래픽 데이터를 수집하여 확인 가능해요. • NMS in/out bps 전일 대비 In/Out bps의 데이터 확인 및 추이 분석기능도 제공하고 있어요. 사진과 같이 초 단위 실시간 데이터를 통한 상세 트랙픽 분석도 가능하답니다! 성능 데이터를 수집하여 그래프 형태로 보관하고 제공하고 있어요. 수집 시간대별 데이터도 제공해요. 해당 데이터를 통하여, 트래픽사용량이 많이 발생한 시간을 찾을수 있어요. • 장비등록 화면 SNMP 모든 버전에 대해서 모니터링을 제공하고 있어요. 장비 설정에 따라서, 버전 및 정보 입력하여 등록하여 모니터링 할 수 있어요. (2) TRAP 모니터링 • 네트워크 장비와 시스템에서 발생하는 이벤트나 상태 변화를 실시간으로 알려주기 위한 SNMP의 비동기적인 메시지에요. 이벤트 발생 시, 장치가 주도적으로 SNMP 매니저에게 알림을 보내는 방식으로 작동해요. Trap은 장애 상황이나 경고 상태 등에 대한 신속한 대응을 가능하게 해요. • Trap은 네트워크 관리자에게 실시간 정보를 제공해요. 장비나 시스템의 이상 상태를 빠르게 감지하고 대응하여, 서비스의 가용성과 신뢰성을 유지하는 데 중요한 역할을 하고 있죠. • Trap의 활용✅ 장애 관리: 장비나 시스템의 고장이나 다운 상태 등의 이벤트가 발생하면 즉시 Trap이 생성되어 매니저에게 알려줘요.✅ 경고 및 알림: 주의가 필요한 상황에서도 Trap을 활용하여 관리자에게 알림을 제공해요.✅ 보안 이벤트: 불법 로그인 시도나 보안 위반 등의 이벤트가 발생하면, 해당 정보를 Trap으로 매니저에게 전송하여 보안 조치를 취할 수 있어요. Trap 발생시, 모니터링 화면을 통해서 내용을 확인 할 수 있어요. Trap 받은 내역을 저장하여, 기간 검색 등을 통하여 활용할 수 있어요. 이제 Zenius를 활용하여 네트워크 장비를 모니터링 해보는 것은 어떨까요?
2023.09.05
회사이야기
'Zenius-SIEM v2.0' GS인증 1등급 획득
회사이야기
'Zenius-SIEM v2.0' GS인증 1등급 획득
브레인즈컴퍼니는 지난 8월 22일 한국정보통신기술협회(TTA)로부터 Zenius-SIEM v2.0에 대한 GS인증 1등급을 획득했습니다. GS인증은 Good Software의 약자로 양질의 품질을 갖춘 SW 제품에 국가가 부여하는 인증 제도 입니다. ISO 국제표준을 기반으로 기능 적합성, 성능 효율성, 보안성 등 여러 테스트를 거쳐 결과가 우수한 제품에 인증이 부여됩니다. GS인증을 받은 제품은 공공기관 우선 구매 대상으로 지정할 수 있습니다. 이번에 GS인증 1등급을 받은 Zenius-SIEM v2.0은 다양한 대용량 로그의 수집, 분석 및 통합 관리 시스템으로, 컴플라이언스(Compliance)를 준수하고 보안 위협에 대한 감시 · 대응 체계를 수립할 수 있는 통합로그 관리 시스템입니다. CC인증에 이어 GS인증 1등급을 획득한 Zenius-SIEM v2.0은 제품의 보안성이 강화되고 안정성을 검증받아 제주특별자치도청과 한국금형산업진흥회에 구축을 완료하였습니다. Zenius-SIEM v2.0은 SaaS(Software as a Service) 형태의 서비스를 제공하기 위해 개발 중에 있으며, On-Premise와 클라우드 환경에서 더 많은 고객들이 안정적으로 대용량 로그를 관리하고 보안 환경을 유지하도록 지원할 예정입니다.
2023.08.30
기술이야기
[Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지?
기술이야기
[Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지?
평온한 오후 퇴근 준비가 한창인데 불길한 전화가 걸려 옵니다. “서비스가 먹통이어서 확인 좀 해야 하는데 서버가 엄청 버벅거리고 반응이 느려요!! 이거 왜 이러죠??” 왜!! 도대체 왜!! 한 번쯤은 겪어보았을 급작스러운 Linux 서버의 상태 이슈! 불행하게도 무척이나 다양한 원인으로 인해 발생하게 됩니다. 우리의 목표는 이 다양한 원인 중 실제 발생 원인을 빠르게 특정하는 것! 기본적인 항목들의 체크리스트를 통해 빠르게 원인을 파악 해 봅시다. Linux 서버 상태 이슈 체크리스트 1. 서버의 CPU 부하 확인하기 2. BUFFER, CACHE, SWAP 상태 확인하기 3. 디스크 상태 확인하기 Zenius를 통한 데이터 추이 분석!! 장애의 발생은 순식간에 일어나지만, 장애 발생 시점의 데이터만을 확인해서는 원인을 파악하기가 쉽지 않은 경우가 많습니다. Zenius를 활용하여 앞서 정한 체크리스트를 빠르게 확인해 봅시다. 1. 서버의 CPU 부하 확인하기 - CPU 부하 확인의 Point는 Load Average Load Average는 CPU 사용 대기 중인 프로세스와 I/O 완료를 대기하고 있는 프로세스의 수를 의미합니다. 따라서, Load Average가 높다는 것은 CPU가 바쁘며 시스템에 걸리는 부하가 있다는 뜻입니다. 화면과 같이 1분, 5분, 15분의 로드 평균을 확인 해 보도록 합시다. 1분 로드 평균은 순간적으로 증가하는 경우가 있지만, 5분 15분 데이터상에도 이전과 비교하였을 때 높은 수치를 보인다면, CPU의 부하가 의심스러운 상황입니다. 그렇다면 CPU의 사용률과 I/O 대기율은 어떨까요? user가 사용한 CPU 사용률은 일정하지만, Iowait 수치가 올라간 것을 볼 수 있습니다. 이 경우 CPU의 리소스 부족이기보다는 I/O로 인한 부하로 판단할 수 있고, 자세히는 메모리나 프로세스의 현황 확인이 필요한 경우입니다. 반대로 user 수치가 높은 경우에는 물리적인 CPU 자체의 리소스 부족이라 볼 수 있습니다. 2. BUFFER, CACHE, SWAP 상태 확인하기 - 메모리 사용률과 Swap, Buffer, Cache 메모리 사용률이 높다 = 서버에 부하가 있다?? 답은 No !! Linux 서버의 메모리 사용률은 Buffer/Cache의 사용량이 포함되어 표현되게 됩니다. 따라서, 우리는 그 추이를 통하여 이슈를 확인하는 것이 중요합니다. 위의 검은 바탕의 그래프는 메모리 사용률이 높지만, 일정한 수치를 유지하고 있습니다. 이런 경우 서버의 메모리 사용은 안정적인 영역에서 이루어진다고 판단이 가능합니다. 그 이유는 실제 메모리 사용량과 Buffer/Cache에 할당량의 수치가 할당 가능한 수치 내에서 이루어지기 때문에 사용률이 유지된다고 볼 수 있기 때문입니다. 반면 흰 바탕의 그래프는 메모리 사용률이 점차 증가하며 결국 100%까지 도달한 것을 확인할 수 있는데요, 이경우에는 프로세스가 연산에 필요한 공간을 할당받지 못하여 프로세스 행이 발생하게 됩니다. 그렇다면 Buffer Cache Swap은 어떨까요? 먼저 Buffer Cache에 관해 확인 해 보도록 하겠습니다. *Buffer – 메타데이터를 메모리에 저장. *Cache – Page Cache, Slab을 메모리에 저장. 쉽게 말해, 둘 다 용도에 맞는 정보를 저장하여 수행 속도에 도움을 주는 영역입니다. 메모리 사용량이 늘어나면 이 Buffer, Cache 영역이 줄어들게 되고, 저장 영역이 줄어든다는 것은 속도가 떨어져 성능 저하로 이어지게 됩니다. 아래 그래프는 메모리 사용률이 올라가고 있는 상태의 서버 데이터입니다. 다음으로 이 시점의 Buffer, Cache의 영역을 확인해 보겠습니다. 추이 그래프를 통해 메모리 사용률이 올라갈수록 Buffer, Cache 영역이 줄어드는 것을 확인할 수 있습니다. 그렇다면 이 시점의 I/O는 어떨까요? 보시는 바와 같이 Iowait 수치가 급격히 올라갔음을 확인 할 수 있으므로, “메모리 사용률의 상승은 Buffer, Cache 영역을 줄어들게 하여 속도 저하를 발생시킨다.” 라는 결론을 도출할 수 있습니다. 또한, 메모리 사용률의 상승은 Swap에도 영향을 끼치게 됩니다. *Swap – 디스크 공간에 할당하여 메모리 역할로 사용하는 공간. 따라서, Swap 영역의 사용은 실제 메모리가 아닌 디스크를 사용하기 때문에 속도 저하가 발생 됩니다. 위 그래프는 Swap 사용률이 증가하고 있는 서버의 데이터입니다. 이 시점의 디스크의 상태를 보면 Read와 Write가 점차 Swap과 동일하게 상승하는 것을 볼 수 있습니다. 이렇게 메모리 대신 디스크 영역을 사용하면서 속도가 저하하게 되는 것입니다. 3. 디스크, 확인하기 - Mount Point 별 디스크 사용량, 작업량 추이 확인 디스크의 여유 공간이 없으면 시스템이 파일 생성을 못 하게 되고 결국엔 서버의 운영에 영향을 끼치게 됩니다. 각각의 마운트 지점의 사용률을 체크하여 여유 공간을 확보하는 것이 필요합니다. 디스크의 사용량이 급작스럽게 늘어난 경우는 신규 파일이 업로드되었다거나, 로그파일이 급작스럽게 많이 쌓이는 경우가 있습니다. 그렇기에 각 Mount Point의 사용률을 확인하고 해당 지점의 이슈 사항을 파악하는 것이 가장 좋습니다. 위 그래프와 같이 1시간 이내에 /data 지점의 사용률이 급등하였다면, 해당 지점에 쌓이는 데이터나 로그파일이 급격하게 증가한 것이므로 확인이 필요합니다. 다음으로는 디스크 사용 추이를 확인 해 보도록 하겠습니다. 서버에서 사용하는 물리 디스크는 각각의 성능의 한계가 있습니다. 이 한계를 직관적으로 확인할 수 있는 데이터로는 Disk Busy Rate(작업률)와 Disk Wait Rate(대기율)이 있는데요, Read 및 Write의 양이 한계치까지 치솟게 된다면 Busy Rate 값이 증가하게 되고, 이에 따른 Wait Rate 가 늘어나면서 서버의 성능 저하를 불러오게 됩니다. 어떻게 관리해야 할까? 앞서 확인한 서버의 상태 이슈들, 물론 급작스럽게 발생하는 경우는 어쩔 수 없지만 미리 대비가 가능한 것들은 Zenius-EMS를 이용하여 임계치 기반의 사전 모니터링과, 모니터링 페이지를 통한 직관적인 관리가 가능합니다. 각각의 항목들에 세부적으로 단계별 임계치를 걸어서 서버의 상태 이슈를 사전에 인지하고, 요약 페이지를 통해 빠르게 상태를 파악하여 우리의 퇴근 시간을 사수해 보는 건 어떨까요?
2023.08.08
기술이야기
서버 모니터링 데이터의 3가지 활용 방법
기술이야기
서버 모니터링 데이터의 3가지 활용 방법
서버는 기업의 핵심 시스템과 데이터를 보관하고, 애플리케이션과 서비스를 호스팅하며, 비즈니스에 필요한 작업을 수행합니다. 이러한 서버가 원활하게 작동하지 않거나 성능 이슈가 발생할 경우, 업무 중단, 데이터 손실, 고객 서비스 저하 등 심각한 문제가 발생할 수 있습니다. 따라서 서버의 안정적인 운영과 성능 관리는 비즈니스의 지속 가능성과 경쟁력에 직결되는 중요한 요소입니다. 서버 모니터링은 이러한 서버의 상태와 동작을 지속적으로 감시하고, 성능 및 이상 상황을 식별하는 프로세스입니다. 이를 통해 시스템 관리자나 운영팀은 잠재적인 문제를 사전에 감지하고 조치를 취할 수 있습니다. 서버 모니터링을 통해 수집하는 데이터는 다양합니다. CPU 사용률, 메모리 사용량, 디스크 공간, 응답 시간, 서비스 가용성, 로그데이터 등 다양한 데이터를 통해 서버의 상태와 동작을 감시합니다. 앞에 언급한 데이터들 외에도 네트워크 연결 상태, 서비스 상태, 프로세스 실행 상태 등 다양한 데이터를 모니터링할 수 있으며, 서버의 운영 환경과 요구사항에 따라 수집되는 데이터의 종류가 달라질 수 있습니다. 이렇게 수집한 데이터들은 어떻게 활용할 수 있을까요? 먼저 병목 현상 식별, 리소스 확장 등을 통해 성능 최적화를 하는 데에 활용될 수 있습니다. 관리자는 수집한 모니터링 데이터를 분석하여 병목 현상을 식별할 수 있습니다. CPU 사용률이 지나치게 높거나 메모리 사용량이 극단적으로 증가하는 경우에는 해당 자원에 대한 최적화가 필요하다는 사실을 인지할 수 있습니다. 또 데이터를 분석하여 서버 리소스의 부족을 파악하고, 필요한 경우 리소스를 확장할 수 있습니다. 예를 들어, CPU 부하가 높다면 CPU를 추가로 할당하거나, 메모리 부족이 발생하면 메모리 용량을 늘릴 수 있습니다. 리소스뿐만 아니라 프로세스의 동작 또한 최적화할 수 있습니다. 특정 프로세스가 많은 CPU 사용량을 차지하고 있다면 해당 프로세스를 최적화하여 자원 사용을 줄일 수 있습니다. 디스크 I/O의 경우 역시 성능을 분석하여 디스크 병목 현상을 확인할 수 있습니다. 그 후 필요에 따라 디스크 용량을 확장하거나 디스크 성능을 향상시킬 수 있습니다. 디스크 공간이 부족한 경우 쓰기 작업을 최적화하여 디스크 공간을 효율적으로 활용할 수 있습니다. 두 번째로 용량 계획에 참고할 수 있습니다. 예를 들어, 서버 모니터링 데이터를 사용하여 트래픽 패턴을 분석하고 예측할 수 있습니다. 특정 시간대에 트래픽이 증가하는 경향을 발견할 수 있다면 해당 시간대에 필요한 용량을 예측하여 서버 리소스를 적절히 조정할 수 있습니다. 이를 통해 예상되는 트래픽 증가에 대비하여 서버의 용량을 조정하고 성능을 유지할 수 있습니다. 또 서버 모니터링 데이터를 사용하여 서버의 성능 패턴을 분석할 수 있습니다. 예를 들어, 특정 시간대에 서버의 응답 시간이 급격히 증가하는 경향을 발견할 수 있다면 해당 시간대에 용량이 부족한 것으로 예상할 수 있습니다. 이를 기반으로 용량을 조정하거나 추가 리소스를 할당하여 성능을 최적화할 수 있습니다. 예비 용량 계획 역시 수립할 수 있습니다. 예를 들어, 서버의 CPU, 메모리, 디스크 사용량 등을 모니터링하고 기준치를 설정한 후, 해당 기준치에 도달하거나 근접할 때 추가 용량을 확보하는 계획을 세울 수 있습니다. 이를 통해 예상치 못한 용량 부족 상황을 방지하고 서버의 안정성과 성능을 유지할 수 있습니다. 마지막으로 장애 예측 및 대응에 활용할 수 있습니다. 서버 모니터링 데이터를 실시간으로 분석하여 이상 상황을 감지하고 경고를 발생시킬 수 있습니다. 예를 들어, CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등을 모니터링하고 미리 설정한 임계값을 초과하는 경우에는 이상 상황으로 판단하고 관리자에게 경고 알림을 보내도록 설정할 수 있습니다. 이를 통해 잠재적인 장애 상황을 사전에 인지하고 대응할 수 있습니다. 혹은 서버 모니터링 데이터를 사용하여 이전의 장애 패턴을 분석하고 예측할 수 있습니다. 예를 들어, 특정 작업이나 트래픽 패턴에 따라 일정한 주기로 장애가 발생했던 경우, 해당 패턴을 파악하여 동일한 상황에서 장애가 발생할 가능성을 예측할 수 있습니다. 이를 기반으로 예방적인 조치를 취하거나 대응 전략을 수립하여 장애를 예방하거나 대응할 수 있습니다. 로그 분석을 통해 서버 모니터링 데이터와 로그 파일을 연계하여 장애 분석 및 대응이 가능합니다. 로그 파일에는 서버 동작 상태, 오류 메시지, 경고 등이 기록되어 있으므로, 장애 발생 시 해당 로그를 분석하여 장애의 원인을 찾고 대응할 수 있습니다. 로그 분석을 통해 예상치 못한 동작, 오작동, 예외 상황 등을 식별하여 이에 대한 조치를 취할 수 있습니다. 서버 모니터링 데이터는 다양한 방식으로 수집되고, 성능 최적화, 용량 계획, 장애 예측 및 대응 등 여러가지 방식으로 활용됩니다. 이를 바탕으로 IT 인프라 관리자와 서버를 사용하는 이용자들이 원활하고 안정적으로 서버를 이용할 수 있도록 도와줍니다.
2023.07.04
회사이야기
2023년 상반기 협력업체 상생 세미나 성료…”신규 기능 소개, 상생 지속 도모”
회사이야기
2023년 상반기 협력업체 상생 세미나 성료…”신규 기능 소개, 상생 지속 도모”
지난 21일 본사 8층 대회의실에서 ‘2023년 상반기 협력업체 상생 세미나’를 진행했습니다. 브레인즈컴퍼니는 급변하는 IT인프라 시장 환경에 적극 대응하고 협력사와의 협력을 더욱 강화하기 위해 협력업체 상생 세미나를 운영하고 있습니다. 올해부터 세미나를 상, 하반기 2회 실시하기로 하였는데요, 기존에 EMS를 설치 및 활용하는 교육 중심에서 제니우스의 새로운 기능을 소개하는 중심으로 세미나에 변화를 주었습니다. 이날 행사는 먼저 프리세일즈팀에서 회사 소개를 하였고, 이어서 Technical Consulting 팀 정채린 차장이 제니우스 8.0의 신규 기능을 소개하였는데요, 20개 이상의 신규 기능에는 WNMS, ERMS, 웹토폴로지 등이 포함되어 있습니다. 그리고 막간을 이용해 통합로그관리, Zenius LogManager을 소개하는 시간도 가졌습니다. WNMS는 분산된 AP 장비의 상태를 한 곳에서 통합 모니터링할 수 있을 뿐만 아니라, AP 장비의 Up/Down 링크, WAN Traffic 등을 실시간으로 모니터링하고, AP 장비의 부하를 효율적으로 컨트롤하도록 접속자 수, 사용자 수, 최대 동시접속자 수 등의 근거데이터를 모니터링하고 자료로 확보할 수 있습니다. ERMS(Event Relation Management System)은 문제 원인 추적을 위한 이벤트의 연관성을 분석하는 기능입니다. 기존 서비스맵의 기능에 AND/OR, 이상 등의 다양한 연산조건 및 통보기능을 추가하여 개별적 이벤트가 아닌 복합적인 이상 상황을 감지할 수 있습니다. 웹토폴로지는 기존에는 CS 형식으로 제공되었던 토폴로지맵의 활용도를 높이기 위해 Web기반으로 구현하여 오버뷰와 함께 활용할 수 있도록 구현하였습니다. 마지막은 클라우드 모니터링을 소개하고 시현을 통해 클라우드 가상화 자원을 모니터링하여 가상 자원의 적절한 운영 효율성을 향상시킬 수 있는지 선 보였습니다. 이번 세미나에는 영진인포텍, 한신정보, 시원 등 협력업체 관계자뿐만 아니라 디와이, 더존비즈온 같은 고객사에서도 참여했습니다. 참여한 협력업체는 이런 형식의 세미나가 자주 있었으면 좋겠다, 그리고 정기적인 온라인 교육을 희망한다는 의견을 주셨습니다. 반면 참여한 고객사는 제니우스 8.0으로 업그레이드를 결정하는 데 많은 도움이 되었다고 합니다. 세미나를 주관한 소감은 “제품 중심으로 소개하는 세미나는 처음인데 예상보다 질문이 많았고 관심이 뜨거운 것을 보고 앞으로 제품을 소개하는 기회를 자주 가지면 좋겠다”입니다. 참여해 주신 모든 분께 감사 인사 전합니다.
2023.06.23
회사이야기
강선근 대표이사, ‘중소기업인 대회’ 산업포장 수상
회사이야기
강선근 대표이사, ‘중소기업인 대회’ 산업포장 수상
강선근 브레인즈컴퍼니 대표이사가 20일 중소기업DMC타워에서 열린 ‘중소기업인 대회’에서 산업포장을 수상했습니다. 올해 34회째를 맞은 중소기업인 대회는 일자리, 수출, 사회기여 등 한국경제 발전에 공헌한 중소/벤처기업인의 성과를 되짚어 보고, 자긍심을 높이는 중소 기업계 최대 축제입니다. 중소기업인 대회는 기술력 뿐만 아니라 재무적 실적과 사회 공헌에 얼마나 이바지 했는지를 종합적으로 평가하며 일회성 공적이 아닌 얼마나 꾸준한 업적이 쌓았는지를 보고 수상자를 선발합니다. 강선근 대표이사는 IT 인프라 통합관리 솔루션, Zenius(제니우스)의 우수한 기술력으로 관제 분야의 국산화 및 국내 SW산업 수준을 향상시킨 공로를 인정 받았습니다. 또한 교육 기관에 기부금 전달 및 산학 협력 업무협약을 체결해 소프트웨어산업 인재 양성에 힘쓰고 있는 점을 인정받아 산업포장을 수상하게 되었습니다. △기술력: 다양한 이기종 IT 인프라에 대한 통합관리 시스템 Zenius EMS를 기반으로, 웹 애플리케이션 성능 모니터링 Zenius APM, 통합로그관리 Zenius SIEM , IT서비스 관리 Zenius ITSM 등으로 구성된 소프트웨어 발전 기여 △실적: 공공기관, 관제부분 실적 1위 △사회공헌: 산학 협력 등 일자리 창출 이번 행사는 서울지방중소벤처기업청과 중소기업중앙회 서울지역본부가 공동 주최하고 서울시가 후원하였습니다.
2023.06.21
회사이야기
[행사] Picnic with BRAINZER
회사이야기
[행사] Picnic with BRAINZER
5월의 마지막 날에 BB데이가 열렸습니다! 이번 BB데이는 '피크닉'을 콘셉트로 진행됐습니다. 한강에서 볼법한 텐트, 웨건, 피크닉 바구니, 테이블 등이 브레인즈에 채워졌는데요. 음식 역시 피크닉에 맞춰 바베큐와 과일, 치즈, 와인 등으로 준비했습니다. 8층 라운지에 일찍 올라온 브레인저들이 역대급이라는 입소문을 내며...... 많은 브레인저들이 함께했습니다! 이번에도 빠짐없이 신규 입사자들이 참석해, 타 부서 브레인저들과 교류하며 뜻깊은 시간을 보냈습니다. 브레인저들의 소통 창구로 자리잡은 BB데이! 다음 달에 또 새로운 모습으로 찾아오겠습니다.
2023.06.02
1
2
3
4
5
6
7