기술이야기 | 브레인즈컴퍼니

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

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 리눅스 서버 TCP 세션 상태, 제니우스(Zenius) SMS로 정밀하게 모니터링하기 기술이야기 리눅스 서버 TCP 세션 상태, 제니우스(Zenius) SMS로 정밀하게 모니터링하기 리눅스 서버를 운영하다 보면, 어느 순간 접속이 느려지거나 예기치 않게 서비스가 불안정해지는 상황을 마주하게 됩니다. 이런 문제가 발생했을 때, 운영자가 가장 먼저 점검해야 할 항목 중 하나가 바로 TCP 세션 상태입니다. ESTABLISHED, CLOSE_WAIT, TIME_WAIT 같은 세션 상태는 단순한 연결 여부만을 보여주는 것이 아니라, 애플리케이션의 처리 흐름, 외부의 비정상적인 접근 시도, 포트 자원 고갈 등 다양한 시스템 이상 징후를 담고 있습니다. 이런 세션 정보를 파악하기 위해 일반적으로는 netstat이나 ss 같은 명령어를 사용합니다. 하지만 수많은 연결 중에서 문제가 되는 세션을 빠르게 식별하기는 어렵고, 시간 흐름에 따른 변화나 포트별 집중 현상까지 함께 분석하려면 복잡한 수작업이 필요합니다. 특히 여러 서버를 동시에 운영하거나 실시간 대응이 필요한 환경에서는 이 같은 방식만으로는 한계가 명확합니다. Zenius SMS이러한 문제점을 해결해주는 기능을 갖추고 있습니다. Zenius는 리눅스 서버의 TCP 세션 상태를 실시간으로 수집하고, 상태별로 자동 분류해 시각적으로 보여줍니다. 운영자는 별도의 명령어 입력 없이도 단일 화면에서 전체 세션 현황을 한눈에 파악할 수 있으며, 세션 수 급증, 포트 집중, 세션 누수, 외부 접속 이상 등 문제 징후를 빠르고 정확하게 진단할 수 있습니다. 제니우스(Zenius) SMS를 활용해 리눅스 서버의 TCP 세션 상태를 어떻게 정밀하게 모니터링할 수 있는지, 그리고 이를 통해 운영 안정성과 대응 효율성을 어떻게 높일 수 있는지 자세히 살펴보겠습니다. Zenius에서 리눅스 TCP 세션 상태를 모니터링하는 절차 Zenius SMS에서는 리눅스 서버의 TCP 세션 상태를 실시간으로 수집하고 시각화하여, 운영자가 문제 징후를 직관적으로 파악할 수 있도록 지원합니다. 이를 위해 Zenius는 세션 상태 정보를 단계적으로 탐색할 수 있는 기능을 제공합니다. 전체 흐름은 다음과 같이 네 단계로 구성됩니다. 첫 번째 단계는 모니터링 대상 서버를 선택하는 과정입니다. [SMS > 모니터링] 경로로 진입하면 관리 중인 서버 목록이 표시되며, 이 중에서 세션 상태를 분석할 서버를 선택할 수 있습니다. 이는 분석 범위를 좁히고, 특정 인스턴스에 집중할 수 있도록 돕습니다. 두 번째 단계는 ‘TCP 상태’ 탭을 통한 전체 세션 상태 파악입니다. 이 탭에서는 현재 연결된 TCP 세션의 상태를 종류별로 나누어 실시간으로 보여주며, ESTABLISHED, TIME_WAIT, CLOSE_WAIT 등 각 상태별 세션 수와 최대값을 그래프 형태로 확인할 수 있습니다. 이 기능은 세션 수의 급증 또는 특정 상태의 지속 여부를 시간대별로 분석하는 데 유용합니다. 세 번째 단계는 ‘네트워크 상태’ 탭을 통한 세션 단위 상세 분석입니다. 이 화면에서는 각 세션의 로컬 IP와 포트, 원격 IP와 포트, 연결 상태, 사용 프로토콜 등 구체적인 세션 정보를 개별적으로 확인할 수 있습니다. 이를 통해 특정 포트나 IP에 세션이 집중되는 현상을 탐지하거나, 외부 접근의 흔적을 식별할 수 있습니다. [모니터링 상세보기 > 서비스 > 네트워크 상태]에서 확인할 수 있습니다. 마지막 단계는 기간 설정 기능을 활용한 시계열 분석입니다. [모니터링 상세보기 > 서비스 > 기간 설정]에서 기본적으로는 1시간, 3시간, 6시간, 12시간, 24시간 단위의 시간 필터를 제공하며, 필요 시 특정 시간 구간만을 지정해 분석할 수도 있습니다. 이 기능은 이상 현상이 발생한 시간대를 중심으로 세션 수의 추이를 파악하고, 문제 발생 시점과 원인을 유기적으로 연결하는 데 효과적입니다. 리눅스 서버 TCP 세션 상태별 의미와 모니터링 기준 TCP 세션 상태는 단순히 연결 여부를 나타내는 정보가 아니라, 네트워크와 애플리케이션의 내부 상태를 간접적으로 보여주는 지표입니다. 그중에서도 운영자가 주목해야 할 주요 상태는 다음과 같습니다. ESTABLISHED는 정상적으로 연결된 세션을 의미합니다. 이 값이 갑자기 증가했다면 외부 요청이 급격히 증가했거나, 애플리케이션에서 기존 연결을 재사용하지 못하고 새로 생성하고 있을 가능성이 있습니다. 경우에 따라서는 세션 누수나 연결 유지 시간 과다로 인한 자원 낭비로 이어질 수 있습니다. CLOSE_WAIT는 상대방이 연결 종료 요청을 보낸 이후, 로컬 시스템에서 해당 세션을 닫지 못한 상태입니다. 이 상태가 계속 유지된다면 애플리케이션의 종료 처리 로직에 문제가 있을 수 있으며, 장시간 쌓일 경우 파일 디스크립터나 포트 자원 고갈을 초래할 수 있습니다. TIME_WAIT는 세션 종료 이후 일정 시간 동안 포트 재사용을 방지하기 위해 대기하는 상태입니다. 정상적인 TCP 동작의 일부이지만, 이 수치가 급격히 늘어나면 포트 고갈로 인해 새로운 연결이 실패할 수 있으며, 서버가 높은 접속 빈도에 제대로 대응하지 못할 수 있습니다. 이 외에도 LISTEN, SYN_SENT, FIN_WAIT1, LAST_ACK 등 다양한 상태들이 존재하며, 각각의 상태는 연결 성립 또는 종료 과정 중 어디에 있는지를 의미합니다. ZeniusSMS는 이러한 상태를 명확히 구분하고 실시간으로 수치를 제공함으로써, 운영자가 네트워크 연결 구조를 보다 명확히 이해하고 제어할 수 있도록 지원합니다. 운영 환경에서 활용할 수 있는 분석 시나리오 Zenius의 TCP 세션 모니터링 기능은 단순한 상태 조회를 넘어, 다양한 운영 시나리오에서 실질적인 문제 해결 도구로 활용될 수 있습니다. 첫 번째 활용 사례는 특정 시간대에 세션 수가 급증한 현상 분석입니다. TCP 상태 탭을 통해 ESTABLISHED 세션 수의 시간대별 변화를 확인하면, 특정 시간에 외부 요청이 비정상적으로 증가했는지, 혹은 애플리케이션의 세션 종료 누락이 있었는지를 빠르게 확인할 수 있습니다. 시간 필터 기능(예: 3H, 6H, 12H, 24H)을 활용하면 세션 패턴의 반복성도 함께 파악할 수 있습니다. 두 번째는 연결된 세션의 상세 정보 분석입니다. 네트워크 상태 탭에서는 각 TCP 세션의 로컬/원격 IP, 포트, 연결 상태, 프로토콜 정보를 확인할 수 있으며, 특정 포트(예: 5432, 8009 등)에 세션이 집중되는 경우 해당 서비스의 부하 상태나 외부의 의도된 트래픽 유입 여부를 분석하는 데 유용합니다. 세 번째는 포트별 세션 분포 및 집중도 분석입니다. 동일한 포트에 세션이 과도하게 집중된다면, 로드밸런싱이 제대로 작동하지 않거나, 특정 애플리케이션에서 비효율적인 연결 관리를 하고 있을 가능성이 있습니다. 이를 실시간으로 파악하면 서비스 확장, 구성 변경 등의 운영 대응을 사전에 계획할 수 있습니다. 이러한 분석들은 netstat 같은 명령어 기반 도구만으로는 쉽지 않은 작업입니다. Zenius는 이 모든 정보를 실시간으로 수집하고 시각화하여, 운영자의 분석 속도와 정확도를 크게 향상시켜줍니다. 리눅스 서버에서의 TCP 세션 상태는 단순한 연결 여부를 넘어, 시스템 내부의 이상 징후를 파악할 수 있는 중요한 지표입니다. 접속 세션 수가 갑자기 증가하거나 특정 상태가 장시간 유지되는 현상은 서비스 장애의 전조일 수 있으며, 외부 침입 시도, 애플리케이션의 비정상적인 처리 흐름, 혹은 포트 자원 고갈 같은 심각한 문제로 이어질 수 있습니다. 이러한 상황을 빠르게 감지하고 대응하기 위해서는 TCP 세션 상태를 실시간으로 추적하고, 상태별로 분류해 변화 양상을 정확히 해석할 수 있는 체계적인 모니터링 환경이 필요합니다. Zenius SMS는 이러한 요구를 충실히 반영한 통합 모니터링 솔루션으로, 리눅스 서버의 TCP 세션 상태를 실시간으로 수집하고 시각화하여 운영자가 이상 징후를 빠르게 인지하고 즉시 대응할 수 있도록 지원합니다. Zenius SMS는 명령어 기반의 netstat 분석보다 훨씬 더 빠르고 정밀하게 세션 흐름을 파악할 수 있으며, 직관적인 사용자 인터페이스를 통해 다양한 서버의 상태를 한눈에 확인하고, 필요 시 정확한 조치를 빠르게 내릴 수 있게 해줍니다. 이는 단순한 상태 조회를 넘어, 운영자가 시스템의 건강 상태를 능동적으로 관리하고, 장애를 예방하는 데 실질적인 도움을 줍니다. TCP 세션 모니터링은 이제 단순한 관제가 아닌, 서비스 품질과 보안 수준을 유지하기 위한 핵심 운영 역량입니다. Zenius SMS는 이 과정을 자동화하고 시각화함으로써, 운영자에게 실질적인 통찰과 대응력을 제공하는 강력한 도구로 자리잡고 있습니다. Zenius SMS를 통해 리눅스 서버의 세션 상태를 더 똑똑하고 빠르게, 그리고 무엇보다 정확하게 관리해보시기 바랍니다. 2025.07.10
기술이야기 전산설비관리 시스템, Zenius FMS의 주요 기능과 특장점 기술이야기 전산설비관리 시스템, Zenius FMS의 주요 기능과 특장점 클라우드 네이티브 환경의 확산과 서버 가상화 기술의 발전은 오늘날 IT 인프라 운영의 중심을 논리적인 계층으로 이동시켰습니다. 많은 기업들이 가상 머신과 컨테이너, 클라우드 리소스 중심의 모니터링에 집중하는 경향이 짙어지고 있습니다. 그러나 이러한 추세 속에서도 간과해서는 안 되는 영역이 있습니다. 바로 물리적 인프라, 즉 전산실 내부에 존재하는 UPS, 항온항습기, 온습도 센서 등 각종 부대설비의 실시간 상태 모니터링과 제어를 위한 관리 체계입니다. 물리 인프라는 눈에 띄지 않지만, 전력 이상, 공조 시스템 오류, 급격한 온도 변화 등으로 인해 실제 서비스 중단의 주요 원인이 되곤 합니다. 논리적 시스템이 아무리 안정적으로 설계되어 있어도, 물리 환경의 불안정은 전체 IT 서비스에 심각한 영향을 미칠 수 있습니다. 따라서 현재의 IT 환경에서도 전산설비 관리 시스템(FMS)은 여전히 중요한 역할을 담당하며, 이전보다 더 정교한 관제 기능과 신속한 대응 역량이 요구되고 있습니다. 이러한 변화에 대응하기 위해, 많은 기관과 기업들은 FMS를 적극 도입해 운영 리스크를 최소화하고 안정성을 강화하고 있습니다. 그중에서도 Zenius FMS는 물리 인프라 운영에 특화된 통합 관리 플랫폼으로, 실시간 모니터링부터 지능형 장애 대응, 자동 제어, 리포팅까지 폭넓은 기능을 제공하며, 디지털 전환 시대의 안정적인 인프라 운영을 위한 핵심 솔루션으로 널리 활용되고 있습니다. 전산설비 관리 시스템, Zenius FMS의 주요 기능 5가지 Zenius FMS는 전산실 내 UPS, 항온항습기, 온습도 센서, IoT 센서 등 다양한 부대설비를 하나의 플랫폼에서 통합적으로 관리하고, 실시간 상태 감시, 성능 분석, 장애 대응, 자동 제어, 리포팅까지 일원화된 방식으로 제공합니다. Zenius FMS는 물리 인프라 운영의 가시성을 높이고, 장애 대응력을 강화하며, 전체 IT 인프라의 안정성을 실질적으로 확보할 수 있도록 설계되었습니다. 1) 실시간 모니터링 Zenius FMS는 UPS, 항온항습기, 온습도 센서, IoT 센서 등 전산실 내 다양한 부대설비의 동작 상태를 1초 단위로 수집하고 시각화함으로써, 실시간 감시 체계를 정밀하게 구축할 수 있도록 지원합니다. 운영자는 각 설비의 특성과 관리 목적에 따라 구성된 동적 View를 통해 현재의 상태를 직관적으로 확인할 수 있으며, 변동이 발생할 경우 즉시 시각적으로 반영되기 때문에 위험 상황에 대한 선제적 대응이 가능합니다. 이와 함께 제공되는 상황판 기능은 주요 설비의 핵심 지표만을 선별해 한 화면에 통합하여 표시하며, 부서 또는 기능 단위의 설비 그룹을 구성해 특정 영역에 대한 집중적인 관제도 손쉽게 수행할 수 있도록 설계되어 있습니다. 이러한 구성은 다수의 설비를 동시에 관리하는 환경에서도 실시간성, 가독성, 운영 효율성을 모두 만족시킵니다. 2) 성능 추이 분석 및 시계열 시각화 실시간 모니터링으로 수집된 데이터는 Zenius FMS 내에서 자동으로 축적되며, 이를 기반으로 설비 성능의 시간 흐름에 따른 변화를 정밀하게 분석할 수 있습니다. 사용자는 일간, 주간, 월간, 연간 단위의 시계열 데이터를 조회할 수 있고, 단일 항목뿐만 아니라 복수 항목을 동시에 분석할 수 있는 멀티차트 구성을 통해 설비 간 비교 분석도 수행할 수 있습니다. 이 기능은 운영자가 단순히 현재 상태만을 보는 데 그치지 않고, 장비의 성능 추세를 정량적으로 파악할 수 있도록 하며, 예기치 못한 성능 저하나 이상 징후를 조기에 발견하는 데 도움을 줍니다. 특히 각 항목은 직관적인 아이콘, 색상, 단위로 구분되어 시각적 인지력이 높으며, 이를 기반으로 한 분석 결과는 향후 설비 교체 주기 결정, 예측 유지보수 전략 수립 등 운영 전략 수립에도 실질적인 기여를 합니다. 3) 장애 감시 및 자동 대응 Zenius FMS는 단순한 이상 감지를 넘어, 사전 정의된 조건에 따라 장애를 자동으로 탐지하고 즉각적으로 대응할 수 있는 자동화 체계를 갖추고 있습니다. 운영자는 OID 단위로 임계치를 설정하거나 이벤트 조건을 정의할 수 있으며, 특정 수치가 기준을 초과하거나 조건을 만족할 경우 시스템은 자동으로 장애 이벤트를 생성합니다. 더 나아가, 해당 이벤트에 연동된 제어 동작이 함께 설정되어 있다면, 냉방기 가동, 전력 차단, 경광등 점등과 같은 설비 제어가 자동으로 실행됩니다. 또한, 장애 발생 시에는 SMS, 이메일, 사운드 등 다양한 알림 방식으로 관계자에게 통보되며, 최대 세 명까지의 담당자에게 순차적으로 전송하는 단계적 통보 체계를 통해 긴급 상황 대응의 공백을 방지합니다. 장애 이력은 시스템 내에 모두 기록되며, 원인, 발생 시각, 조치 내용 등을 포함한 상세 이력은 유사 장애 재발 시 빠르고 정확한 대응을 가능하게 합니다. 4) 구성 및 운영 관리 Zenius FMS는 다양한 설비 환경에 유연하게 대응할 수 있도록 설계되어 있으며, 구성과 운영의 편의성을 고려한 여러 기능을 제공합니다. SNMP 프로토콜을 지원하는 장비는 물론, 기존에 별도 시스템으로만 관리되던 시리얼 통신 기반의 장비 역시 신호변환 컨트롤러를 통해 FMS 시스템에 통합할 수 있습니다. 설비 등록 시에는 Excel 템플릿을 통해 다수의 장비를 일괄 등록할 수 있으며, 항목별 OID 등록도 제조사별로 정리된 참조 DB를 통해 손쉽게 수행할 수 있어, 신규 장비 도입 시 초기 세팅 시간을 크게 절감할 수 있습니다. 운영자 인터페이스는 MS Office 사용자에게 익숙한 메뉴 구조와 UI 흐름으로 구성되어 있어 별도의 교육 없이도 직관적으로 사용할 수 있으며, 관리 항목 수정, 알람 설정, 뷰 구성 등 대부분의 기능을 빠르게 설정할 수 있도록 도와줍니다. 이를 통해 Zenius FMS는 실무자의 운영 부담을 줄이면서도, 체계적인 설비 관리를 실현할 수 있는 환경을 제공합니다. 5) 리포팅 및 분석 Zenius FMS는 설비 데이터를 기반으로 한 다양한 유형의 리포팅 기능을 내장하고 있어, 운영 현황을 체계적으로 정리하고 이를 다양한 관점에서 분석할 수 있도록 지원합니다. 사용자는 분석 목적에 따라 성능 비교, 기간별 추이 분석, 증설 필요성 평가, 항목 간 상관관계 분석, 시간대별 부하 분포, 성능 예측 등의 보고서를 생성할 수 있으며, 이를 사전에 정의된 템플릿을 바탕으로 빠르게 작성할 수 있습니다. 각 보고서는 일간, 주간, 월간, 분기별로 자동 생성되며, 메일을 통해 관계자에게 정기적으로 전달되도록 설정할 수 있습니다. 출력 포맷은 PDF, Excel, Word, PowerPoint, HTML 등 다양한 형식을 지원하며, 대내외 보고용 문서로 바로 활용이 가능하도록 구성되어 있습니다. 또한, 모든 보고서는 시스템 내에 이력으로 저장되기 때문에 시점별 운영 데이터를 비교하거나, 과거 분석 결과를 참조하는 데에도 매우 유용합니다. 이 기능은 단순히 운영 현황을 정리하는 데 그치지 않고, 향후 자원 투자, 용량 계획, 장애 예방 전략 수립 등 상위 의사결정에 필요한 기반 정보를 제공하는 역할을 합니다. 전산설비 관리 시스템, Zenius FMS의 세 가지 특장점 Zenius FMS는 단순한 모니터링 툴을 넘어, 전산실 내 다양한 부대설비를 유연하게 통합 관리하고, 직관적인 관제 환경과 실무 친화적인 운용 구조를 갖춘 지능형 설비 통합관리 플랫폼입니다. 다음은 Zenius FMS가 갖는 세 가지 주요 특장점입니다. 1) 다양한 설비를 아우르는 유연한 통합 관리 구조 Zenius FMS는 SNMP를 기본으로 지원하는 장비뿐만 아니라, SNMP를 지원하지 않는 아날로그 설비나 폐쇄형 프로토콜 장비까지도 통합 관리할 수 있도록 설계되었습니다. 이를 가능하게 하는 핵심은 신호 변환용 컨트롤러의 활용입니다. 이 컨트롤러는 설비에서 출력되는 비표준 신호를 FMS 시스템이 수집 가능한 형식으로 변환해 주며, 이를 통해 설비의 상태 모니터링뿐 아니라 자동 제어 및 이벤트 연동까지 수행할 수 있습니다. 이처럼 다양한 제조사, 다양한 통신 방식을 사용하는 이기종 설비를 하나의 플랫폼에서 일괄적으로 관리할 수 있는 구조는 실제 운영 환경에서의 호환성과 확장성을 크게 높여 줍니다. 결과적으로, 구축 초기부터 이후 설비 추가·변경까지 물리 인프라 변화에 유연하게 대응할 수 있는 환경을 제공합니다. 2) Topology 기반 시각 중심 장애 관제 기능 Zenius FMS의 Topology Map 기능은 전산실 설비의 실제 물리 배치와 연결 구조를 시각적으로 재현함으로써, 장애 발생 시 해당 설비의 위치와 영향 범위를 한눈에 파악할 수 있도록 돕는 핵심 관제 도구입니다. 사용자는 설비 간의 상호 연계 관계를 기반으로 장애 발생 원인과 그에 따른 파급 효과를 직관적으로 인식할 수 있으며, 복잡한 텍스트 로그나 수치만으로 파악하던 기존 방식보다 훨씬 빠르고 정확한 장애 대응이 가능해집니다. 특히 복수 설비의 이상 상황이 동시에 발생하거나, 하나의 장애가 연쇄적으로 다른 장비에 영향을 줄 수 있는 구조에서는 이러한 시각 중심의 관제 방식이 운영 판단의 민첩성과 효율성을 높이는 데 매우 효과적입니다. 3) 학습 비용을 줄이는 사용자 친화적 인터페이스 Zenius FMS는 시스템의 초기 도입과 실무 적용 과정에서의 부담을 최소화할 수 있도록, 운영자 경험을 고려한 UI/UX 설계를 갖추고 있습니다. MS Office에 익숙한 사용자라면 별도의 교육 없이도 메뉴 구성과 인터페이스에 쉽게 적응할 수 있으며, Excel을 기반으로 한 설비 일괄 등록, 드래그앤드롭 방식의 뷰 구성, 아이콘 중심의 시각 요소 배치 등은 실무자가 빠르게 구성·운용할 수 있도록 설계되어 있습니다. 이러한 사용성 중심의 인터페이스는 실제 환경에서 관리 업무의 복잡도를 줄이고, 시스템 활용도를 높이며, 팀 간 협업을 원활하게 만드는 기반이 됩니다. 특히 전문 IT 인력이 아닌 일반 시설 관리자도 빠르게 운용에 참여할 수 있어, 조직 내 전산실 운영의 연속성과 범용성을 강화하는 데 유리합니다. 논리 인프라가 아무리 탄탄하게 구축되었더라도, 물리 인프라가 불안정하다면 전체 시스템은 언제든지 위험에 노출될 수 있습니다. 특히 전산실과 같은 핵심 물리 환경이 관리 체계 밖에 놓이게 되면, 단일 설비의 이상이 전체 서비스 장애로 확대될 가능성도 배제할 수 없습니다. Zenius FMS는 이러한 리스크를 원천적으로 줄이기 위한 전산설비 중심의 통합 관리 플랫폼입니다. 실시간 상태 감시, 자동 제어, 시각적 장애 인식, 설비 등록 자동화, 리포팅 기능 등 운영자가 필요로 하는 모든 기능을 하나의 시스템으로 통합하여 제공합니다. 결국, 디지털 인프라의 완성은 물리 기반의 안정성에서 비롯됩니다. Zenius FMS는 그 기반을 견고히 하여, 전체 시스템의 신뢰성을 한층 높여주는 유용한 도구입니다. 2025.07.04
기술이야기 네트워크 모니터링 툴을 통한 LLDP 오토맵 구성 및 활용 방법 기술이야기 네트워크 모니터링 툴을 통한 LLDP 오토맵 구성 및 활용 방법 디지털 인프라 환경이 점차 복잡해지면서, 네트워크 구성도 보다 유연하고 다층적인 구조로 변화하고 있습니다. 다양한 벤더의 장비가 혼재되어 운영되고, 포트 연결은 수시로 변경되며, 구성도는 시간이 지날수록 실제 환경과 일치하지 않는 경우가 많습니다. 이러한 변화 속에서 운영자는 전체 네트워크 구조를 정확히 파악하고 관리하는 데 어려움을 겪게 됩니다. 연결 상태를 명확히 확인하지 못하면 장애 대응이 지연되고, 트래픽 흐름이나 장비 간 영향도 분석이 제한될 수밖에 없습니다. 문서화된 구성도만으로 실시간 상태를 파악하는 데는 분명한 한계가 있습니다. 이럴 때 LLDP(Link Layer Discovery Protocol)를 활용하면, 장비 간의 연결 정보를 자동으로 수집하고 시각적으로 표현할 수 있어, 현재의 네트워크 상태를 보다 직관적으로 파악할 수 있습니다. Zenius NMS와 같은 네트워크 모니터링 툴은 이러한 LLDP 정보를 기반으로 오토맵을 자동 구성해, 운영자가 수작업 없이도 네트워크의 실제 연결 상태를 명확히 확인하고 효율적으로 관리할 수 있도록 지원합니다. 그렇다면 LLDP 기반 오토맵의 개념과 이를 통해 기대할 수 있는 운영상 효과, 그리고 네트워크 모니터링 툴인 Zenius NMS에서 이를 어떻게 구체적으로 활용할 수 있는지를 차례대로 살펴보겠습니다. LLDP 기반의 오토맵은 무엇이고 어떤 문제를 해결할 수 있을까? LLDP는 네트워크 장비 간의 연결 정보를 자동으로 수집하는 프로토콜입니다. Cisco에서 사용하는 CDP(Cisco Discovery Protocol)와 유사한 기능을 하지만, LLDP는 특정 벤더에 종속되지 않아 다양한 제조사의 장비 환경에서도 유연하게 활용할 수 있습니다. 네트워크 모니터링 툴 Zenius NMS는 이러한 LLDP 정보를 활용해 장비 간 실제 연결 상태를 자동으로 시각화하는 오토맵 기능을 제공합니다. 별도의 수작업 없이도 실시간 구성도 수준의 네트워크 맵을 생성할 수 있어, 운영자가 현재 네트워크 구조를 보다 직관적으로 파악할 수 있도록 돕습니다. 특히 구성 정보가 부실하거나 최신화되지 않은 환경에서도 유용하며, 수년간 운영되며 복잡해진 네트워크 구조도 LLDP 오토맵을 통해 효과적으로 시각화할 수 있습니다. 장애가 발생했을 때는 어떤 포트가 어느 장비와 연결되어 있는지를 즉시 확인할 수 있어, 원인 파악과 대응 속도를 높이는 데 도움이 됩니다. 또한 각 인터페이스의 상태 정보(BPS, PPS, 최대 전송 속도 등)도 함께 표시되어, 트래픽 흐름을 보다 정확하게 분석할 수 있습니다. 결과적으로 LLDP 기반 오토맵은 구성도가 없는 환경에서도 네트워크 연결 상태를 명확하게 파악하고, 장애 대응과 성능 분석의 효율을 높이는 데 실질적으로 활용할 수 있습니다. 이제 Zenius NMS를 통해 LLDP 오토맵을 어떻게 구성하고 활용할 수 있는지 자세히 살펴보겠습니다. Zenius NMS에서 LLDP 기반 오토맵 구성 및 활용 방법 오토맵 구성 절차 Zenius NMS는 LLDP로 수집한 장비 간 연결 정보를 바탕으로, 네트워크 토폴로지를 자동으로 구성할 수 있는 기능을 제공합니다. 아래와 같은 절차를 통해 오토맵을 손쉽게 생성하고, 운영 환경에서 실시간으로 활용할 수 있습니다 [Step 01] [EMS > 토폴로지 > 맵목록관리 > 맵등록]: 먼저 오토맵을 구성할 새로운 맵을 등록합니다. 이 단계에서는 맵의 이름, 유형 등을 입력하고 기본 설정을 저장합니다. [Step 02] [EMS > 토폴로지 > 등록맵 선택 > 편집]: 등록한 맵을 선택한 후, [편집] 버튼을 클릭하여 맵 에디터 모드를 활성화합니다. [Step 03] [EMS > 토폴로지 > 등록맵 선택 > 편집 > NMS 자동맵 > 대상 Drag]: NMS 자동맵 기능을 선택한 뒤, 자동 구성을 적용할 장비(스위치, 라우터 등)를 화면으로 드래그합니다. 이후 [맵구성] 버튼을 클릭하면, 선택한 장비를 중심으로 LLDP 기반의 연결 구조가 자동 생성됩니다. [Step 04] [EMS > 토폴로지 > 등록맵 선택 > 편집]: 자동 생성된 맵이 화면에 나타나면, 각 장비의 위치를 드래그하여 보기 좋게 배치할 수 있습니다. [Step 05] [EMS > 토폴로지 > 등록맵 선택 > 편집]: 구성한 맵이 완성되면, [오토맵 저장]을 눌러 현재 상태를 저장합니다. 이후 해당 맵은 Zenius EMS/NMS에서 실시간 모니터링 화면과 연동되어 사용됩니다. 이와 같은 절차를 통해 구성된 LLDP 오토맵은, 구성도가 없는 환경에서도 네트워크 전반의 실제 구조를 빠르게 파악하고, 운영 중 발생하는 연결 변화나 장애 상황을 실시간으로 모니터링하는 데 유용하게 활용할 수 있습니다. 이제 이러한 오토맵 기능이 실제 운영 환경에서 어떻게 적용되는지, 세 가지 구체적인 예시를 통해 살펴보겠습니다. 구체적인 활용 가이드 ① 복잡한 네트워크 구성 한눈에 파악하기 일반적으로 네트워크 토폴로지는 조직 내부에서 보유한 구성도에 따라 수작업으로 구성되며, 이를 기반으로 주요 장비의 장애 상태를 모니터링합니다. 그러나 이러한 구성도가 오래되었거나 존재하지 않는 경우, 실제 네트워크 연결 구조를 정확하게 파악하기 어려운 경우가 많습니다. 이런 상황에서 LLDP 기반 오토맵 기능은 수집된 연결 정보를 바탕으로 자동으로 네트워크 구조를 시각화해줍니다. 운영자는 구성도 없이도 전체 네트워크 구성을 실시간으로 확인할 수 있으며, 각 장비 간의 물리적 관계를 직관적으로 파악할 수 있습니다. [네트워크 구성도 기반 구성한 토폴로지의 사례] 구체적인 활용 가이드 ② 연결 장비의 트래픽 정보 자동 확인하기 스위치 장비는 여러 개의 인터페이스를 통해 다양한 장비와 트래픽을 주고받습니다. 이러한 환경에서 각 인터페이스가 어떤 장비와 연결되어 있는지, 어떤 구간에 트래픽이 집중되고 있는지를 수작업으로 확인하는 것은 현실적으로 매우 어렵습니다. 특히 별도의 분석 도구나 관리 시스템이 없을 경우, 문제 발생 시 신속한 대응이 더욱 어려워집니다. Zenius LLDP 오토맵은 이러한 연결 정보를 자동으로 시각화할 뿐 아니라, 각 연결 구간의 인터페이스 트래픽 정보도 함께 표시합니다. 이를 통해 운영자는 트래픽이 집중되는 구간, 병목 현상이 발생할 수 있는 지점을 빠르게 확인하고 사전에 대응할 수 있습니다. [오토맵을 통한 연결 장비 트래픽 확인 사례] 구체적인 활용 가이드 ③ 인터페이스 장애 영향도 분석하기 오토맵을 통해 트래픽이 몰리는 특정 연결 구간을 식별한 이후에는, 해당 구간에 연결된 인터페이스의 상세 정보를 확인할 수 있습니다. 연결된 포트의 상태, 전송 속도(BPS/PPS), 최대 속도(Max Speed) 등 다양한 지표를 기반으로 문제의 원인을 보다 구체적으로 분석할 수 있습니다. 예를 들어, MainSwitch와 Switch755fa 간의 연결을 조회하면 MainSwitch의 gi4 포트를 통해 연결되어 있다는 점을 확인할 수 있고, 해당 포트의 트래픽 수치까지 함께 확인 가능합니다. 이를 통해 인터페이스 장애가 전체 네트워크에 미치는 영향도 보다 정확하게 판단할 수 있습니다. 구체적인 활용 가이드 ④ CDP, LLDP 연결정보 확인 하기 이뿐만 아니라, Zenius NMS는 Cisco 장비에서 제공하는 CDP(Cisco Discovery Protocol)와 LLDP 정보를 모두 지원합니다. 이를 통해 오토맵 구성 외에도 정적인 장비 연결 정보 점검이 가능하며, 다양한 환경에서 유연한 연결 정보 수집이 가능합니다. 운영자는 NMS > 모니터링 > 장비 > 대상 클릭 > 부가정보 메뉴를 통해 각 장비에 대한 CDP 및 LLDP 연결 정보를 확인할 수 있으며, 이를 통해 오토맵 구성 외에도 정적인 장비 연결 정보 확인 및 점검이 가능합니다. [NMS > 모니터링 > 장비 > 대상 클릭 > 부가정보 ] CDP, LLDP 정보 Zenius LLDP 오토맵 기능은 실제 운영 환경에서도 효과적으로 활용되고 있습니다. 예를 들어, B제약사는 주요 스위치를 제외한 장비의 연결 상태를 명확히 파악하기 어려운 상황에서 LLDP 기반 오토맵 도입을 요청한 고객사입니다. 특히 대부분의 장비가 Cisco가 아닌 타 벤더 장비로 구성되어 있어, 기존의 CDP 기반 구성으로는 한계가 있었습니다. 이에 따라 Zenius를 통해 LLDP 기반 웹 오토맵 기능이 POC 형태로 제공되어 실제 환경에 적용되었습니다. 도입 이후에는 기존에 파악되지 않았던 스위치 간 연결 관계와 인터페이스 수준의 상태까지 시각적으로 확인할 수 있게 되었고, 관리의 사각지대였던 영역도 체계적으로 관리할 수 있게 되었습니다. 이를 통해 B제약사는 운영 효율성과 문제 대응 속도를 동시에 개선할 수 있었습니다. LLDP 기반 오토맵은 단순히 장비 간 연결 상태를 보여주는 도구에 그치지 않습니다. 실제 환경에 적용해보면, 운영자가 놓치기 쉬운 연결 구조를 시각적으로 재구성하고, 네트워크 상의 다양한 상호작용을 보다 명확하게 이해하는 데 도움이 됩니다. 특히 장애나 트래픽 변화처럼 빠른 대응이 필요한 순간에는, 자동화된 시각 정보가 판단과 조치의 속도를 좌우할 수 있습니다. 인터페이스 수준의 상세 정보까지 함께 제공되기 때문에, 문제가 발생한 구간의 영향도를 실시간으로 파악하고, 사전에 우선 대응할 수 있는 근거도 마련됩니다. 도입 사례를 통해 확인할 수 있었듯이, 기존 관리 체계만으로는 파악하기 어려웠던 장비 간 연결이나 관리 사각지대 역시 오토맵을 통해 자연스럽게 드러나며, 운영 체계 전반의 신뢰성을 높이는 계기가 됩니다. 정적인 문서나 수작업 기반의 관리에서 벗어나, 실시간 연결 정보를 바탕으로 네트워크를 보다 직관적으로 운영하고자 한다면, LLDP를 기반으로 한 Zenius의 오토맵 기능을 통해 보다 효율적이고 안정적인 네트워크 운영 환경을 구축할 수 있습니다. 2025.06.04
기술이야기 하이브리드 클라우드 환경에서 네트워크 모니터링 솔루션 도입 시 고려사항 5가지 기술이야기 하이브리드 클라우드 환경에서 네트워크 모니터링 솔루션 도입 시 고려사항 5가지 반드시 하나 이상의 퍼블릭 클라우드와 프라이빗 클라우드(또는 온프레미스 인프라)를 함께 사용하는 하이브리드 클라우드는, 유연한 확장성과 높은 보안성을 동시에 활용할 수 있어서 다양한 비즈니스 환경에서 사용되고 있습니다. 그러나 하이브리드 클라우드는 서로 다른 네트워크 구성과 보완 요구사항을 통합해야 하기 때문에, 전체 상태를 효과적으로 모니터링하지 않으면 성능 저하나 보안 문제가 발생할 수 있습니다. 그렇다면 하이브리드 클라우드 환경에서 네트워크 모니터링 솔루션을 도입할 때, 필수적으로 고려해야 할 요소는 무엇인지 자세히 살펴보겠습니다. 1. 이기종 네트워크 환경 간 통합 가시성 하이브리드 클라우드 환경에서 프라이빗 클라우드와 퍼블릭 클라우드(AWS, Azure 등) 간 네트워크는 서로 다른 프로토콜(TCP, UDP, HTTP 등)과 장비로 구성되기 때문에 관리가 복잡해집니다. 따라서 네트워크 모니터링 솔루션은 각기 다른 네트워크 요소를 실시간으로 통합하여 한눈에 확인할 수 있는 가시성을 갖춰야 합니다. 구체적으로 네트워크 모니터링 솔루션은 각 클라우드의 네트워크 트래픽을 실시간으로 모니터링하여 패킷 손실이나 지연, 비정상적인 트래픽이 발생하는 순간 이를 빠르게 감지하고 문제의 위치를 파악해 정확히 대응할 수 있어야 합니다. 예를 들어 퍼블릭 클라우드 데이터베이스가 프라이빗 클라우드의 애플리케이션과 연결될 때 특정 구간에서 지연이 발생하는 경우, 해당 구간의 원인을 분석하여 즉각적인 대응 방안을 제시해야 합니다. 또한 API 연동을 통해 각 클라우드의 모니터링 데이터를 하나의 대시보드에 통합하여, 클라우드 전체의 트래픽 흐름을 실시간으로 파악하고 성능을 최적화할 수 있어야 합니다. 2. 네트워크 지연 문제와 트래픽 최적화 하이브리드 클라우드 환경에서는 프라이빗 클라우드와 퍼블릭 클라우드 간 물리적 거리와, 여러 네트워크 장치를 거치는 특성상 지연 문제가 발생할 수 있습니다. 이를 해결하기 위해 네트워크 모니터링 솔루션은 트래픽 경로와 성능 데이터를 실시간으로 수집하고 분석하여 지연의 원인을 파악하고, 최적화된 경로로 트래픽을 조정하는 기능이 필요합니다. 또한 Qos(Quality of Service) 정책을 통해 애플리케이션의 중요도에 따라 트래픽 우선순위를 설정하여, 중요한 애플리케이션의 대역폭을 확보할 수 있어야 합니다. 클라우드 리전 간 데이터 전송 시에는, AI 기반 라우팅 알고리즘을 통해 최적의 경로를 실시간으로 선택해 지연 시간을 줄여야 합니다. 이를 통해 예기치 못한 트래픽 증가나 장애 상황에서도 대체 경로를 자동으로 탐색하여, 서비스 연속성을 보장할 수 있어야 합니다. 3. 대규모 데이터 전송과 대역폭 관리 하이브리드 클라우드 환경에서는 대규모 데이터 전송이 빈번하게 이루어질 뿐만 아니라 데이터 복제, 동기화, 마이그레이션으로 인해 대역폭 사용량이 급증할 수 있습니다. 따라서 네트워크 모니터링 솔루션은 대역폭 사용 현황과 트래픽 패턴을 실시간으로 파악하여, 특정 시간대에 발생하는 과부하를 미리 예측하고 대응할 수 있는 기능이 필요합니다. 대역폭 관리 기능을 통해 데이터 전송이 몰리는 시간대에 대역폭을 자동으로 재할당하거나, 특정 시간대에 데이터 전송을 예약하여 네트워크 부하를 효과적으로 분산할 수 있어야 합니다. 또한 데이터 압축과 캐싱을 활용해, 불필요한 데이터 전송을 줄이고 전송 효율을 최적화하는 것도 중요합니다. 클라우드 서비스 제공 업체마다 데이터 전송 비용이 다를 수 있어, 비용 최적화를 위한 경로와 전송 시점을 조정하는 기능도 필요합니다. 예를 들어 비용이 낮은 시간대를 선택하거나 효율적인 경로를 자동 선택하여, 대규모 데이터 전송의 효율성과 비용 절감을 동시에 확보할 수 있어야 합니다. 4. 보안 및 규정 준수 강화 하이브리드 클라우드 환경에서 퍼블릭 및 프라이빗 클라우드 간 빈번한 데이터 이동은 네트워크의 취약성을 높일 수 있기 때문에, 보안 관리가 특히 중요합니다. 이를 위해 네트워크 모니터링 솔루션은 엔드-투-엔드 암호화 기능을 제공하여 이동중인 데이터가 제3자가 내용을 볼 수 없도록 보호하고, 데이터가 무단으로 수정되거나 유출될 경우 즉시 경고할 수 있어야 합니다. 또한 하이브리드 환경에서는 퍼블릭 및 프라이빗 네트워크 보안 표준이 각각 다릅니다. 따라서 통합 보안 정책 관리 기능을 통해 일관된 보안 정책 적용을 보장하고, 침입 탐지 시스템 (IDS)와 침입 방지 시스템 (IPS)와 연동하여 보안 위협을 실시간 분석하고 차단할 수 있어야 합니다. 규정 준수 또한 중요합니다. 특히 금융, 의료, 공공기관 등에서는 개인 데이터 보호와 같은 엄격한 규정을 요구하기 때문에, 모니터링 솔루션은 데이터 접근 및 사용 내역을 실시간으로 기록하고 컴플라이언스 상태를 자동으로 평가해 보고하는 기능을 갖춰야 합니다. 예를 들어 유럽의 데이터 보호 규정(GDPR)이나 미국의 의료 정보 보호법(HIPAA) 준수 여부를 실시간으로 모니터링하여, 규제 대응에 필요한 보고서를 제공할 수 있어야 합니다. 5. 네트워크 장애 대응 및 고가용성(HA)설계 하이브리드 클라우드 환경에서는 각 클라우드 인프라에서 예기치 못한 장애가 발생하더라도, 신속하게 복구하고 안정적으로 운영하기 위한 고가용성(HA) 설계가 필요합니다. 이를 위해 네트워크 모니터링 솔루션은 멀티패스 라우팅 기능을 제공하여 리전 내 특정 경로에 문제가 생기면, 자동으로 대체 경로를 선택해 트래픽을 우회하여 서비스 중단을 방지할 수 있어야 합니다. 또한 네트워크 상태를 실시간으로 모니터링하고 장애 가능성을 사전에 감지해 경고하는 예측 기반 모니터링 시스템도 필요합니다. 이 시스템은 장애 발생 시 자동으로 복구 절차를 실행해 서비스 중단 시간을 최소화할 수 있어야 합니다. 다중 리전 페일오버 기능도 지원해야 합니다. 리전 전체에 네트워크 장애가 발생하더라도, 즉시 다른 리전으로 트래픽을 전환하여 운영을 지속할 수 있어야 합니다. 특정 네트워크 장비의 장애 상황에서도 운영을 유지할 수 있도록 지리적 이중화 설계도 필요합니다. 마지막으로 장애 원인을 분석하고 재발을 방지하는 사후 보고 기능이 중요합니다. 장애 발생 시점과 원인, 영향을 상세히 기록하여 유사한 문제가 반복되지 않도록 해야 합니다. 하이브리드 클라우드 환경에서 네트워크 모니터링 솔루션을 도입할 때는, 앞서 언급한 5가지 요소를 충족하여 네트워크 상태를 체계적으로 관리할 수 있어야 합니다. 특히 모니터링 솔루션을 통해 클라우드 간 데이터 이동이나 대규모 트래픽 상황에서는 네트워크 상태를 실시간으로 모니터링하여, 즉각적으로 필요한 조치를 취해 성능과 안정성을 유지할 수 있습니다. 또한 보안 관리와 규정 준수를 지원하는 모니터링 기능은, 데이터 보호와 컴플라이언스 요건을 충족하여 서비스의 신뢰성을 높이는 데 도움을 줍니다. 이처럼 구체적이고 체계적인 모니터링 솔루션은 하이브리드 클라우드에서 발생할 수 있는 복잡한 문제를 효과적으로 관리하며, 안정적이면서도 효율적인 서비스를 지속하게 합니다. 2024.10.29
기술이야기 하이브리드 클라우드의 5가지 도전과제 기술이야기 하이브리드 클라우드의 5가지 도전과제 클라우드를 활용하는 기업들은 일반적으로 하이브리드 클라우드 환경을 구성합니다. 단일 클라우드 환경에 비해서 여러 가지 장점이 있기 때문입니다. 하이브리드 클라우드는 멀티 클라우드의 일종입니다. 멀티 클라우드(Multi Cloud)는 하나 이상의 클라우드 환경을 병행하여 활용하는 것을 의미합니다. 클라우드 환경이 퍼블릭이든 프라이빗이든 상관없습니다. 멀티 클라우드는 특히 퍼블릭 클라우드 서비스를 활용할 때 하나의 서비스 제공업체에 종속되지 않고, 각 서비스의 특화된 기능을 조합하여 성능과 비용 효율성을 극대화하기 위해서 주로 활용됩니다. 하이브리드 클라우드(Hybrid Cloud)는 반드시 하나 이상의 퍼블릭 클라우드와 프라이빗 클라우드(또는 온프레미스 인프라)를 함께 사용하는 방식을 일컫습니다. 이 방식은 프라이빗 클라우드의 높은 보안성과 퍼블릭 클라우드의 유연한 확장성을 동시에 활용할 수 있다는 장점이 있습니다. 예를 들어 보안 유지와 규제 준수가 요구되는 민감한 데이터는 프라이빗 클라우드에 안전하게 저장하고, 트래픽의 변동성이 커서 유연성과 확장성이 필요한 서비스는 퍼블릭 클라우드에서 처리하는 방식입니다. 이를 통해 기업은 데이터 보안과 확장성 간의 균형을 유지하며, 비용을 절감할 수 있습니다. 레거시 환경에서부터 출발하여 클라우드 전환을 실행한 대부분의 조직들은 이와 같은 하이브리드 클라우드 환경을 갖추고 있다고 볼 수 있습니다. 두 개 이상의 퍼블릭 클라우드 서비스와 기업 내부의 프라이빗 클라우드 시스템 또는 온프레미스 시스템을 동시에 활용하기 때문입니다. 그러나 이러한 하이브리드 클라우드 장점을 최대한 활용하려면 몇 가지 도전 과제가 있습니다. 이 과제들을 어떻게 해결하느냐에 따라 하이브리드 클라우드의 성공적인 도입과 운영이 좌우됩니다. 이러한 도전 과제들에 대해 자세히 살펴보겠습니다. 통합 운영 및 자동화 체계 구축 각 클라우드 환경은 서로 다른 가상화 기술을 기반으로 운영되기 때문에, 이를 하나의 통합된 인터페이스에서 관리하려면 고유한 관리 도구와 API를 통합하고 상호 호환성을 확보하는 작업이 필수입니다. 또한, 클라우드 간에 워크로드를 자유롭게 이동하거나 자원을 효율적으로 관리하려면 일관된 오케스트레이션 체계를 구축해야 하지만, 각 클라우드가 고유의 관리 프로토콜을 사용하기 때문에 이를 통합하는 과정에서 기술적인 어려움이 발생할 수 있습니다. 이와 같은 통합 문제는 자동화 시스템 구축에서도 큰 난제로 작용합니다. 퍼블릭 클라우드의 오토스케일링(Auto Scaling)이나 리소스 프로비저닝(Resource Provisioning)과 같은 기능은 퍼블릭 클라우드에 특화된 기술로, 이를 프라이빗 클라우드에 동일하게 구현하는 것에도 어려움이 따릅니다. 이러한 기술적 차이를 해결하기 위해서는 양쪽 클라우드 환경을 통합하는 자동화 시스템을 설계해야 하며, 이 과정에서 복잡한 기술적 이슈가 제기될 수 있습니다. 예를 들어 퍼블릭 클라우드의 확장성과 유연성을 프라이빗 클라우드에서도 동일하게 적용하려면, 각 환경에 적합한 자동화 규칙과 관리 프로세스를 개발해야 합니다. 하지만 이 과정에서 많은 리소스와 시간이 요구되며, 결국 운영 효율성을 저하시키고, 자동화 시스템의 불완전함으로 인해 운영자의 수동 개입이 필요하게 되는 상황을 초래할 수 있습니다. 데이터 관리 하이브리드 클라우드 환경에서의 데이터 관리는 이동성, 일관성, 보존, 거버넌스 등 다양하고 복잡한 과제가 따릅니다. 특히 데이터가 여러 물리적 위치에 분산되어 저장하고 처리되기 때문에 모든 위치에서 일관된 상태를 유지하는 것이 어렵습니다. 예를 들어 프라이빗 클라우드에서 수정된 데이터가 퍼블릭 클라우드와 즉시 동기화되지 않을 경우, 데이터 불일치가 발생할 수 있으며 비즈니스 프로세스에 중대한 영향을 줄 수 있습니다. 또한 클라우드 간의 데이터 이동은 네트워크 성능에 크게 의존합니다. 대용량 데이터를 전송할 때 네트워크 지연이 발생하면 시스템 성능이 저하될 수 있으며, 특히 실시간 데이터 처리가 중요한 애플리케이션에는 이러한 지연이 심각한 성능 문제로 이어질 수 있습니다. 따라서 실시간 데이터 처리 환경에서는 네트워크 대역폭을 최적화하고 지연 시간을 최소화하는 것이 핵심 과제이며, 이를 제대로 해결하지 못하면 비즈니스의 신속한 의사 결정과 대응 능력이 저하될 수 있습니다. 추가적으로 데이터를 여러 클라우드 환경에 복제하여 관리할 경우, 불필요한 데이터 중복이 발생할 수 있어 스토리지 비용이 크게 증가할 수 있습니다. 이러한 비용 증가를 방지하려면 철저한 데이터 복제 정책과 함께 효율적인 스토리지 관리 전략을 반드시 수립해야 합니다. 비용 관리 하이브리드 클라우드는 유연한 비용 구조를 제공하지만, 이를 효과적으로 관리하지 못할 경우 비용이 급격히 증가할 수 있습니다. 프라이빗 클라우드와 퍼블릭 클라우드는 서로 다른 방식으로 비용을 책정하기 때문에, 이를 통합 관리하는 것은 쉽지 않은 일입니다. 특히 퍼블릭 클라우드는 사용한 만큼 요금을 부과하는 구조라서, 예상치 못한 리소스 사용이나 자원의 과도한 할당이 발생하면 비용이 급격히 증가할 위험이 있습니다. 반면, 프라이빗 클라우드는 고정된 인프라 유지 비용이 지속적으로 발생하기 때문에 두 환경의 비용을 동시에 효율적으로 통제하지 않으면 예기치 못한 지출로 이어질 수 있습니다. 따라서 이러한 이질적인 비용 모델을 결합해 장기적으로 비용을 예측하고 최적화하는 것이 매우 까다롭습니다. 워크로드의 특성에 따라 어느 환경이 더 비용 효율적인지를 판단하는 리소스 최적화 역시 복잡성을 더하는 요소입니다. 모든 워크로드가 퍼블릭 클라우드에서 비용 효율적인 것은 아니며, 프라이빗 클라우드에서 더 적합한 워크로드도 존재하기 때문에 이러한 선택이 적절히 이루어지지 않으면 불필요한 비용이 발생할 수 있습니다. 네트워크 관리 하이브리드 클라우드 환경에서 네트워크 성능은 시스템 전반의 안정성과 효율성이 직결되는 핵심 요소입니다. 프라이빗 클라우드와 퍼블릭 클라우드 간에 데이터 전송 시, 물리적 거리에 따른 네트워크 지연(latency)이 발생할 수밖에 없습니다. 이러한 지연은 대규모 데이터 처리 애플리케이션이나 실시간 트랜잭션을 요구하는 워크로드에서 치명적인 성능 저하를 초래할 수 있습니다. 이러한 문제를 완화하기 위해 네트워크 경로 최적화, 지능형 트래픽 관리 및 QoS(Quality of Service) 설정과 같은 고급 네트워크 성능 튜닝이 필요합니다. 또한 하이브리드 클라우드 환경에서 빈번하게 발생하는 대규모 데이터 전송은 대역폭 제한을 초래할 수 있습니다. 적절한 네트워크 프로비저닝과 데이터 압축, 캐싱 기법을 적용하지 않으면 네트워크 병목현상이 발생하여 시스템 성능에 부정적인 영향을 미칠 수도 있습니다. 더불어 네트워크 장애는 클라우드 서비스 전체에 심각한 중단을 일으킬 수 있기 때문에, 이를 예방하고 빠르게 복구할 수 있는 사전 준비가 필요합니다. 장애에 대비하려면 고가용성(HA) 네트워크 설계, 자동으로 장애를 감시하는 시스템, 그리고 멀티패스(multipath) 라우팅 같은 복구 방법을 적용해야 합니다. 하지만 이러한 작업은 여러 네트워크 계층이 얽혀 있고, 클라우드 시스템 간 상호작용이 복잡하기 때문에, 높은 기술력과 체계적인 관리를 필요로 합니다. 보안 및 규제 준수 프라이빗 클라우드와 퍼블릭 클라우드라는 이질적인 환경에서 데이터를 동시에 관리하고 보호해야 하기 때문에, 다양한 보안 위협과 복잡한 규제 요구사항을 충족시키는 것이 기술적으로 까다롭습니다. 특히 프라이빗 클라우드에서는 기업이 자체적으로 설정한 보안 정책과 방화벽, 액세스 제어 등을 사용할 수 있습니다. 반면 퍼블릭 클라우드에서는 클라우드 서비스 제공자가 제공하는 보안 프로토콜과 방어 체계가 의존해야 하므로, 이 두 환경을 일관되게 통합해 운영하는 것이 매우 복잡합니다. 데이터 보호 측면에서 암호화와 키 관리가 중요한 역할을 하지만, 각 클라우드 플랫폼이 사용하는 암호화 표준 및 키 관리 프로토콜이 상이할 수 있어 이를 일관되게 적용하는 것도 중요한 이슈입니다. 또한 하이브리드 클라우드 환경에서 규제를 준수하는 것은 매우 중요한 문제입니다. 그러나 데이터가 저장된 국가나 지역마다 규제 요구사항이 다르기 때문에, 모든 규정을 충족하는 것이 어려울 수 있습니다. 예를 들어 유럽연합의 GDPR, 미국의 HIPAA 같은 규제를 준수해야 하는 경우 퍼블릭 클라우드 제공자가 데이터가 저장하는 위치나 처리 방식을 명확하게 제공하지 않으면 규제 위반 가능성이 높아질 수 있습니다. 따라서 데이터 주권을 유지하기 위한 데이터 로컬리티 정책을 엄격하게 설정하고, 이를 지속적으로 모니터링하여 규제 준수 여부를 확인하는 추가적인 노력이 필요합니다. 하이브리드 클라우드의 성공적인 운영은 앞서 설명한 다섯 가지 핵심 과제들을 '얼마나 효과적으로 해결하느냐'에 달려 있습니다. 클라우드 간의 통합 관리, 비용 효율적인 운영, 그리고 보안 및 규제 준수의 문제는 단순히 기술적 과제일 뿐만 아니라 기업의 전략적 의사결정과도 깊이 연관되어 있습니다. 따라서 이러한 문제에 대한 종합적인 접근과 체계적인 해결책이 필요합니다. 2024.10.08
기술이야기 Fluentd vs Logstash vs Filebeat, 어떤 로그 수집기를 선택할까? 기술이야기 Fluentd vs Logstash vs Filebeat, 어떤 로그 수집기를 선택할까? 이전 시간에는 Fluentd라는 로그 수집기에 대해 자세히 알아보았습니다(이전 글 보기). 이와 더불어 Logstash, Filebeat가 로그 데이터를 수집하고 처리하는 도구로 많이 쓰이고 있는데요. 이번 시간에는 이 세 가지 도구가 어떤 점에서 비슷하고, 어떤 점에서 다른지 살펴보겠습니다. │Fluentd vs Logstash, Filebeat 로그 데이터 수집 및 처리 Fluentd, Logstash, Filebeat는 모두 다양한 소스에서 로그 데이터를 수집하고 처리하는데요. 파일, 데이터베이스, 네트워크 프로토콜, 메세지 큐 등 다양한 입력 소스를 지원합니다. 수집된 로그 데이터를 분석하기 좋은 형태로 변환하고 필터링해주죠. 처리된 로그 데이터는 Elasticsearch, Kafka, HDFS, S3 같은 다양한 저장소와 분석 시스템으로 전송할 수 있습니다. ▷ Fluentd는 JSON 형식을 주로 사용해서 데이터를 처리합니다. 다양한 소스에서 데이터를 수집하고 변환할 수 있으며, 특히 쿠버네티스 같은 클라우드 네이티브 환경에서 최적화되어 있습니다. 또한 다양한 컨테이너와 마이크로서비스로부터 로그를 모아서 중앙에서 관리하죠. ▷ Logstash는 Elashtic Stack에서 로그 데이터를 수집, 변환, 전송하는데 주로 사용됩니다. 복잡한 데이터 변환과 필터링을 위한 강력한 기능을 제공하고 다양한형식으로 로그 데이터를 변환할 수 있죠. Elasticsearch와 Kibana와의 통합 덕분에 강력한 검색과 시각화 기능을 사용할 수 있습니다. ▷ Filebeat는 경량의 로그 수집기로 설계되어 있고, 주로 로그 파일을 모니터링하고 수집하는 데 최적화되어 있습니다. 서버 리소스를 거의 사용하지 않으면서도 효율적으로 로그 데이터를 수집할 수 있죠. 주로 Logstash나 Elasticsearch로 데이터를 전송해서 중앙에서 분석할 수 있게 해줍니다. 플러그인 시스템 Fluentd와 Logstash는 플러그인 시스템을 통해 기능을 확장할 수 있는데요. 다양한 입력, 필터, 출력, 플러그인을 제공해서 필요에 따라 시스템을 유연하게 구성할 수 있습니다. ▷ Fluentd는 500개 이상의 플러그인을 통해 다양한 데이터 소스와 목적지에 대한 통합을 지원합니다. 그래서 사용자는 다양한 요구에 맞춰 시스템을 쉽게 구성할 수 있죠. ▷ Logstash도 200개 이상의 플러그인을 통해, 다양한 입력 소스와 출력 목적지에 맞춤형 데이터 파이프라인을 구성할 수 있는데요. 복잡한 데이터 처리와 분석 요구 사항을 충족할 수 있습니다. ▷ Filebeat는 모듈 기반 아키텍처를 통해 특정 로그 파일 형식에 맞춘 구성을 제공합니다. 설정이 간단하고 빠르게 배포할 수 있는 것이 장점이죠. 플러그인 대신 모듈을 통해 다양한 로그 형식에 대응할 수 있습니다. 실시간 데이터 처리 세 도구 모두 실시간으로 로그 데이터를 수집하고 처리할 수 있습니다. 이는 급변하는 환경에서 로그 데이터를 즉시 분석하고 대응하는 데 매우 중요하죠. ▷ Fluentd와 Logstash는 실시간으로 수집된 데이터를 변환하고 필터링해서, 필요한 데이터를 즉시 사용할 수 있는 형태로 만들어줍니다. 이를 통해 실시간 모니터링 시스템에서 발생하는 로그 데이터를 빠르게 처리하고 문제를 신속히 해결할 수 있습니다. ▷ Filebeat는 경량화된 설계 덕분에 실시간 로그 수집에 최적화되어 있는데요. 서버 리소스를 최소화하면서도 안정적으로 데이터를 전송할 수 있습니다. 어떤 로그 수집기를 선택하면 좋을까요? 그렇다면 Fluentd, Logstash, Filebeat 중 우리 기업에 맞는 로그 수집기는 무엇인지 핵심만 정리한다면 다음과 같습니다. Fluentd ✔️ 다양한 소스에서 데이터를 수집하고 통합하는 경우 ✔️ 특히 클라우드 네이티브 환경에서 운영되는 경우 ✔️ 유연성과 확장성이 중요하고, 다양한 플러그인을 통해 쉽게 확장할 수 있는 도구가 필요한 경우 ✔️ 쿠버네티스와 같은 컨테이너화된 환경에서 로그를 수집하는 경우 Logstash ✔️ Elastic Stack을 사용해서 강력한 검색 및 시각화 기능을 필요한 경우 ✔️ 복잡한 데이터 변환과 필터링이 필요한 환경에서 로그 데이터를 처리하는 경우 ✔️ 다양한 입력 소스와 출력 목적지에 맞춤형 데이터 파이프라인을 구성하는 경우 Filebeat ✔️ 경량의 로그 수집기가 필요한 경우 ✔️ 서버 리소스를 최소화하면서 로그 데이터를 수집하고 전송해야 하는 경우 ✔️ 설치와 설정이 간단하고 빠르게 배포할 수 있는 도구가 필요한 경우 ✔️ 주로 로그 파일을 모니터링하고 수집하는 작업이 주된 경우 이처럼 각 도구는 기업 또는 사용자의 환경과 요구 사항에 맞춰, 적절한 도구를 선택하는 것이 중요한데요. 브레인즈컴퍼니의 경우는 높은 성능과 유연한 로그 데이처 처리를 위해 Logstash와 Filebeat를 사용하고 있습니다. 이번 시간에 살펴본 내용처럼 Fluentd와 Logstash, Filebeat는 모두 로그 데이터를 효과적으로 수집하는 강력한 도구입니다. 하지만 로그는 수집에서 끝나는 것이 아닌, 어떻게 안정적으로 관리하느냐도 중요합니다. 이때 로그를 수집부터 관리까지 할 수 있는 통합로그관리가 필요한데요. Zenius SIEM과 같은 솔루션을 통해 로그를 수집부터 관리까지 할 수 있고, 보안 위협에 대비하는 것이 정말 중요합니다. 데이터의 중요성이 더욱더 커지는 상황에서, 효과적인 로그 수집 및 관리를 통해 비즈니스 경쟁력을 높이시길 바랍니다. ?더보기 Zenius SIEM 더 자세히 보기 ?함께 읽으면 더 좋아요 • 로그 수집기 Fluentd에 대해 알아야 할 5가지! 2024.07.28
기술이야기 오픈소스 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
기술이야기 엣지 컴퓨팅을 위한 CNCF 프로젝트, KubeEdge 활용법 기술이야기 엣지 컴퓨팅을 위한 CNCF 프로젝트, KubeEdge 활용법 최근 몇 년 간 IT 분야는 급속한 발전을 거듭하고 있습니다. 특히 2010년대 중반부터 데이터를 온라인에 저장하는 기존 방식을 넘어서, 보다 진보된 컴퓨팅 기술이 등장하며 클라우드 컴퓨팅이 중요한 역할을 하게 되었습니다. 아마존 웹 서비스(AWS), 마이크로소프트(Microsoft), 구글(Google) 등의 대형 기업들이 클라우드 서비스를 주도해 나갔죠. 하지만 점점 IT 산업이 커지고 사물인터넷(IoT) 기술이 발전하면서 IT 장비에서 생성되는 데이터양이 기하급수적으로 많아졌습니다. IDC의 2018년 자료에 따르면, 2025년에는 전 세계에서 생성되는 데이터가 175ZB(*제타바이트1)에 도달할 예정이라고 합니다. 이처럼 수많은 데이터가 생성되고 중앙 서버에 저장/연산이 될 경우, 서버에 부하가 증가하는 문제가 발생하게 됩니다. *1. 1 ZB = 1021 bytes = 1,000,000,000,000,000,000,000 bytes 이를 해결하기 위해 2020년부터 중앙 서버에만 저장하지 않고, 클라우드 하위개념인 '클라우드렛'을 통해 데이터를 분산 처리하는 새로운 기술이 등장했는데요. 그 기술이 바로 엣지 컴퓨팅(Edge Computing)입니다. │엣지 컴퓨팅(Edge Computing)이란? 엣지 컴퓨팅은 데이터를 중앙 집중형 데이터 센터나 클라우드 대신, 데이터가 생성되는 가장 가까운 곳에서 처리하는 기술입니다. 쉽게 말해 중앙 서버가 아닌 데이터가 발생하는 '엣지(가장자리)'에서 직접 처리하는 것을 의미하죠. 엣지 컴퓨팅의 목적은 데이터 처리 응답 지연을 없애고, 실시간 성능을 개선하는 것입니다. 따라서 엣지 컴퓨팅의 가장 큰 특징이 '분산 처리 기능'이기도 합니다. 즉 가까운 곳에서 데이터를 처리하여, 부하를 분산하고, 통신 지역을 최소화하는 것이 엣지 컴퓨팅의 주목적입니다. │Edge Computing 필요성 그렇다면 엣지 컴퓨팅은 왜 점점 중요해지고 있을까요? 앞에서 언급했던 것처럼, IoT 시대가 도래하면서 다양한 디바이스에서 처리하는 데이터의 양이 폭발적으로 증가하고 있습니다. 이에 따라 요구되는 처리 속도와 응답 속도도 높아지고 있죠. 방대한 양의 데이터를 처리하기 위해서는 대규모 데이터 센터가 필요하지만, 각 위치에 데이터 센터를 두는 것보다 한 곳에서 중앙 집중식으로 처리하는 것이 더 효율적입니다. 이것이 클라우드 컴퓨팅이 대중화된 이유 중 하나입니다. 그러나 인터넷을 통해 클라우드로 데이터를 전송하고 처리한 후 반환할 때, 약간의 시간 지연이 발생합니다. 물론 로봇과 산업 장비의 센서 기술은 나날이 발전하고 있어, 어느 순간에도 상황을 정확하게 파악할 수 있게 되었습니다. 하지만 데이터 처리와 반응 사이에 시간 지연이 발생하면 정교한 *센싱 기술2 은 아직 어려운 편이죠. *2. 센싱 기술: 다양한 센서를 활용해 물리적 환경으로부터 데이터를 감지하고 수집하는 기술 이처럼 정밀하고 복잡한 동작을 수행하는 디바이스에는 고정밀 IoT가 필요한데요. 이를 위해서는 최대한 실시간에 가깝게 정보와 데이터를 주고받아야 하는데, 엣지 컴퓨팅가 이를 가능하게 합니다. 따라서 엣지 컴퓨팅은 IoT가 다음 단계로 나아가기 위해 필요한 기술로 주목받고 있죠. │Edge Computing 장점 엣지 컴퓨팅의 구체적인 이점은 무엇일까요? 엣지 컴퓨팅을 활용하면 얻을 수 있는 이점을 살펴보겠습니다. • 네트워크 트래픽 감소: 엣지 컴퓨팅은 데이터를 중앙 클라우드 서버로 보내지 않고 엣지(사용자 근처 단말기)에서 직접 처리하기 때문에, 네트워크 트래픽이 큰 폭으로 감소합니다. • 빠른 데이터 처리 응답시간: 데이터를 단말기에서 바로 처리하므로, 데이터 처리 응답 시간이 매우 빠릅니다. 실시간 응답이 중요한 애플리케이션에서는 큰 이점이죠. • 향상된 보안성: 개인정보 등 중요한 데이터를 중앙 데이터 센터로 전송하지 않아도 되므로 보안성이 높아집니다. 데이터가 로컬에서 처리되기 때문에 데이터 유출 위험이 줄어듭니다. • 장애 포인트 감소: 서버에 장애가 발생할 경우, 전체 서비스로 장애가 확대되는 클라우드 컴퓨팅과 달리 엣지 컴퓨팅은 개별 엣지의 장애가 다른 엣지로 전파되지 않게 합니다. 따라서 전체 시스템의 안정성이 향상되고 장애 포인트가 감소됩니다. │Edge Computing 활용 분야 엣지 컴퓨팅 활용분야는 다양하지만, 대표적인 엣지 컴퓨팅 적용사례로 스마트팩토리가 있습니다. 스마트 팩토리는 IoT, AI를 활용해 공정을 자동화하고 최적화하는 공장을 의미하는데요. 스마트팩토리에서는 제품 생산 과정에서 발생하는 모든 데이터를 중앙 클라우드 서버에 저장하면, 서버에 부하가 걸리기 쉽습니다. 이를 해결하기 위해 단순히 매일 반복되는 프로세스는 근처 엣지서버에 저장하고 데이터 연산 작업을 진행하죠. 반면 복잡하고 자주 처리되지 않는 데이터는 중앙 클라우드 서버에 저장합니다. 이렇게 하면 AI가 기기를 운영할 때 실시간 데이터 처리가 가능하여 지연 시간을 줄이고 효율성을 높일 수 있습니다. 여기서 엣지 서버는 지사 개념으로, 중앙 클라우드 서버는 본사 개념으로 이해할 수 있습니다. 엣지 컴퓨팅 활용 분야는 계속해서 확대되고 있습니다. 스마트팩토리 외에도 에너지 스트리밍, 게임, 헬스케어, 농업, 데이터센터, 자율주행, 스마트 시티 등 대규모 산업분야에 많이 사용되고 있습니다. │Edge Computing 도전 과제 하지만 엣지 컴퓨팅 기술에는 여러 도전과제가 있는데요, 대표적으로 애플리케이션 배포관리가 있습니다. 다양한 엣지 환경에서 애플리케이션을 배포하고 관리하는 것은, 생각만 해도 복잡한 프로세스이기 때문이죠. 이때 애플리케이션 버전 관리를 일관되게 하고 다양한 엣지 장치와 위치에서 호환성을 유지하려면, 효율적인 오케스트레이션 배포 시스템이 필요합니다. 이러한 과제를 해결하기 위해 여러 솔루션들이 연구되고 있는데요. 그중 하나가 쿠버네티스(Kubernetes, K8s)입니다. 쿠버네티스는 컨테이너화된 애플리케이션을 자동 배포하고, 확장하며, 관리하기 위한 오픈 소스 플랫폼입니다. 이때 쿠버네티스 기술에 + Edge를 접목한 것이 바로 KubeEdge입니다. 좀 더 자세히 알아볼까요? │KubeEdge란? KubeEdge는 쿠버네티스를 확장하여 엣지 컴퓨팅 환경을 지원하는 오픈 소스 플랫폼입니다. 엣지 컴퓨팅의 잠재력을 최대한 활용할 수 있는 플랫폼이죠. KubeEdge는 클라우드 컴퓨팅과 엣지 컴퓨팅의 경계를 허물기 위해 설계되었는데요. CNCF 재단에서 엣지 컴퓨팅 커뮤니티 구성원에 의해 개발되었고, 2018년 11월 상하이 KubeCon에서 처음 발표되었습니다. 쿠버네티스 기반으로 설계된 KubeEdge는, 2019년 3월에 첫 릴리즈 이후로 점차 안정화되고 있습니다. │KubeEdge 주요 기능 KubeEdge는 쿠버네티스를 사용해 클라우드와 엣지 리소스를 일관되게 관리할 수 있습니다. 또한 클라우드에서 운영하던 애플리케이션과 서비스를 동일한 방식으로 다룰 수 있죠. 이 밖에도 KubeEdge 주요 기능은 다음과 같습니다. • 엣지 클러스터 관리: KubeEdge는 엣지 환경에서도 쿠버네티스 클러스터를 효율적으로 관리할 수 있습니다. • 데이터 처리: 엣지에서 생성된 데이터를 로컬에서 처리하여, 네트워크 대역폭을 절약하고 응답 시간을 단축합니다. • 애플리케이션 오케스트레이션: 클라우드와 유사한 방식으로 엣지 애플리케이션을 배포하고 관리할 수 있습니다. • 보안: 엣지와 클라우드 간의 안전한 통신을 보장하여, 데이터 보안을 강화합니다. │KubeEdge 주요특징 KubeEdge 기능이 좀 더 원활하게 작업을 할 수 있도록 도와주는 주요 특징이 있는데요. 자세히 살펴보겠습니다. • 분산 아키텍처: KubeEdge는 클라우드와 엣지를 각각 포함하는 분산된 환경을 지원합니다. 클라우드에는 Kube-apiserver가 있으며, 엣지에는 실제 IoT 디바이스가 있습니다. 이를 통해 중앙 집중식 관리와 로컬 처리를 모두 가능하게 합니다. • 쿠버네티스 API 호환성: KubeEdge는 쿠버네티스 API와 호환됩니다. 이를 통해 기존에 쿠버네티스에 익숙한 사용자는 엣지 컴퓨팅 환경을 쉽게 관리할 수 있죠. • 리소스 제약 환경 지원: 엣지 디바이스는 일반적으로 제한된 컴퓨팅 자원을 가지고 있습니다. KubeEdge는 이러한 환경을 고려하여 설계되었기 때문에, 리소스가 제한된 환경에서도 효율적으로 작동합니다. • 오프라인 작동 지원: 엣지 노드는 네트워크에 연결되어 있지 않더라도, 일정 부분을 독립적으로 작동할 수 있습니다. 이는 인터넷 연결이 불안정한 환경에서 매우 유용합니다. • 경량화된 엣지 컴포넌트: KubeEdge는 엣지 측에 'EdgeCore'라는 경량화된 컴포넌트를 사용합니다. EdgeCore는 IoT 디바이스와의 통신/관리를 담당합니다. • 효율적인 통신: 클라우드와 엣지 사이의 통신은 *MQTT3와 같은 프로토콜을 사용하여 효율적으로 이루어집니다. 이는 데이터의 신속한 전송과 처리를 가능하게 합니다. *3. MQTT: Message Queuing Telementry Transport의 약자로 경량 메시지 전송 프로토콜 │KubeEdge 구성도 KubeEdge 구성도를 살펴보면 크게 Cloud, Edge, Device로 나누어져 있는데요. 각각 구성요소에 대한 설명은 아래와 같습니다. • Edged: Edge에서 컨테이너화된 애플리케이션을 관리합니다. 이는 엣지 디바이스에서 애플리케이션을 배포하고 실행하는 역할을 합니다. • EdgeHub: Edge에 위치한 통신 인터페이스 모듈로, 엣지 컴퓨팅을 위해 클라우드 서비스와 상호 작용하는 *웹 소켓4 클라이언트입니다. 클라우드와 실시간 데이터 통신을 담당합니다. • CloudHub: 클라우드에서의 통신 인터페이스 모듈입니다. 클라우드 측의 변경 사항을 감시하고, EdgeHub에 메시지를 캐싱하고 보내는 역할을 담당하는 웹 소켓 서버입니다. • Edge Controller: Edge 노드를 관리하는 모듈입니다. 이 모듈은 데이터를 특정 엣지 노드로 전달될 수 있도록, 엣지 노드와 포드 *메타데이터5를 관리합니다. 즉 Edge Controller는 쿠버네티스 컨트롤러 역할을 확장하여, 엣지 컴퓨팅 환경에서도 효율적인 노드 관리와 데이터 흐름을 가능하게 합니다. • EventBus: MQTT를 사용하여 내부 엣지 통신을 처리하는 모듈입니다. 이는 MQTT 서버와 상호 작용하여 다른 구성 요소에 게시와 구독 기능을 제공하는 MQTT 클라이언트 역할을 합니다. • Device Twin: 장치 메타 데이터를 처리하는 장치용 소프트웨어 미러입니다. 이 모듈은 장치 상태를 처리하고 이를 클라우드에 동기화하는 데 도움을 줍니다. 또한 경량 데이터베이스(SQLite)에 연결되어, 애플리케이션에 대한 쿼리 인터페이스도 제공합니다. • MetaManager: Edge 노드에서 메타데이터를 관리하는 모듈입니다. 이는 Edged와 EdgeHub 사이의 메세지 프로세서로, 경량 데이터베이스(SQLite)와의 메타데이터를 저장/검색하는 역할을 담당합니다. *4. 웹 소켓: 웹 브라우저와 서버 간의 실시간 양방향 통신을 가능하게 하는 프로토콜 *5. 포드 메타데이터: 파일 원본 데이터 외에 추가적인 속성이나 정보를 포함하는 메타데이터 이러한 각 구성 요소는 엣지와 클라우드 간의 원활한 통신, 애플리케이션 배포, 데이터 관리 등을 담당하여 엣지 컴퓨팅의 성능과 효율성을 극대화합니다. 이를 통해 실시간 데이터 처리와 안정적인 시스템 운영이 가능하죠. │엣지 컴퓨팅과 KubeEdge 미래 전망 그렇다면 엣지컴퓨팅과 KubeEdge 미래 전망은 어떨까요? 엣지 컴퓨팅과 KubeEdge의 결합은 데이터 생성 지점에서 즉시 처리를 가능하게 하여 지연 시간을 줄이고, 클라우드 네이티브 애플리케이션을 엣지 환경에서도 원활하게 실행할 수 있도록 지원합니다. 따라서 이러한 기술의 결합은 5g와 함께 자율주행차, 스마트 시티 등 다양한 분야에서 혁신을 이끌며, 향후 지속적인 성장이 예상됩니다. IDC에 따르면, 전 세계 엣지 컴퓨팅 지출은 2023년 2080억 달러에서 2026년까지 연평균 13.1%씩 성장하여 3170억 달러에 이를 것으로 예상됩니다. 이러한 성장은 디지털 전환 이니셔티브의 중요한 요소로 엣지 컴퓨팅의 역할이 확대되면서 더욱 가속화될 예정입니다. 국내에서도 엣지 컴퓨팅과 관련한 기술 발전과 시장 확장이 활발히 이루어지고 있습니다. 정부가 민간사업에게 5G 주파수를 할당하면서 이음 5G(5G 특화망) 서비스가 시작되었고, 이를 통해 자율 주행 로봇 등의 엣지 컴퓨팅 관련 서비스가 확대되고 있습니다. 결론적으로 엣지 컴퓨팅과 KubeEdge의 결합은, 미래의 디지털 트랜스 포메이션을 가속화할 핵심 기술로 자리 잡을 것으로 전망하고 있습니다. 이들의 발전은 다양한 산업 분야에서 새로운 비즈니스 모델과 기회를 창출하여, 우리의 생활 방식을 더욱 안전하고 편리하게 만들어 줄 것입니다. ?참고 자료 • MichaelShirer, "New IDC Spending Guide Forecasts Edge Computing Investments Will Reach $232 Billion in 2024", IDC • GordonHaff, "Edge computing: 4 trends for 2023", enterprisersproject • ShirleyStark, "Future Of Edge Computing: Top 6 Trends 2023", justtotaltech • TonyFyler, "Edge computing trends in 2023", techhq • Bluefriday, "KubeEdge concept", tistory • Mansoor Ahmed, "Kubernetes Native Edge Computing Framework, KubeEdge", linkedin • "TDK의 고급 HDD 헤드 기술은 사회의 디지털 변혁을 가속화합니다", shunlongwei • 양대규기자, 엣지에서 AI와 시각적 처리가 증가하는 이유, aitimes 2024.07.26
기술이야기 APM의 핵심요소와 주요기능은?! 기술이야기 APM의 핵심요소와 주요기능은?! 지난 글을 통해서 APM의 필요성과 '트랜잭션' 현황 파악의 중요성에 대해서 알아봤습니다. 이번 시간에는 트랜잭션을 어떤 방식으로 추적하는지 APM 동작 과정을 통해 살펴보고, APM 시스템을 최적화하는 핵심 요소와 기능은 무엇인지 자세히 알아보겠습니다. │APM 동작 과정 APM은 Client-Web Application-DBMS와 같은 구성요소 사이에 트랜잭션1을 추적할 수 있어야 합니다. 이를 통해 웹 서비스 전반적인 성능을 모니터링하고, 문제가 발생했을 때 원인을 신속하게 진단할 수 있기 때문인데요. 그렇다면 각 단계별로 APM가 어떻게 트랜잭션1을 추적하는지 좀 더 자세히 살펴보겠습니다. *트랜잭션1: 쉽게 말해 데이터베이스에 실행되는 작업 단위를 의미합니다. 트랜잭션은 작은 여러 작업들을 하나의 그룹으로 묶어 처리하기 때문에, A라는 작업에서 일부가 성공했다고 하더라도 하나의 트랜잭션 처리가 비정상적으로 종료되면 모두 실패한 것이죠. 클라이언트(Client) 웹 서비스 사용자가 이용하는 디바이스 또는 브라우저입니다. 클라이언트에서 발생하는 요청과 응답을 추적하여 페이지 로딩 시간, 사용자 활동, 에러 발생 등을 파악할 수 있습니다. 이 정보들을 통해 사용자 경험을 분석하고 개선하는데 기초 자료로 사용되죠. 웹서버(Web Server) 클라이언트 요청을 받아, 적절한 답을 생성하여 보내는 서버입니다. 이 단계에서 APM은 서버(예: Apache, Nginx) 로그와 성능 지표를 분석하여 요청 처리 시간, 데이터 전송량, 서버 오류 등 정보를 모니터링하고 기록합니다. 웹 애플리케이션 서버(WAS) WAS는 Web Application Server의 약자로, 애플리케이션에서 사용하는 데이터를 저장하고 관리하는 시스템입니다. 이 단계에서 APM은 데이터베이스 성능을 모니터링하여 DB 쿼리 실행시간과 DB 서버 부하 등을 측정하고, 성능 문제를 파악하는 데 도움을 줍니다. WAS 종류로는 WebLogic, Websphere, JEUS, Tomcat 등이 있습니다. 데이터베이스(DBMS) DBMS(Database Management System)는 기업에서 발생하는 모든 데이터를 저장하고 관리하는 소프트웨어입니다. 이 단계에서는 DB 성능 관리 솔루션을 통해, 애플리케이션 개발자가 작성한 SQL 튜닝과 DBMS 소프트웨어 병목 현상 등을 모니터링할 수 있습니다. 특히 데이터베이스는 IT 인프라에서 필수 요소입니다. 기업 서비스 대부분이 데이터베이스에 접근하여, 데이터를 조회하고 수정해야 하기 때문에 DB 관리는 매우 중요하다 할 수 있죠. 이처럼 APM은 Client-Web Server-Was-DB 각 구성요소 사이에 있는 트랜잭션을 추적하여 웹 서비스 성능을 평가할 수 있습니다. 그다음으로는 APM 시스템 전체적인 성능을 평가하고 최적화하는 핵심 요소는 무엇인지 살펴보겠습니다. │APM 성능을 최적화하는 핵심요소 APM 시스템은 크게 5가지 요소를 통해, 전체적인 성능을 최적화할 수 있습니다. 우선 Resource는 시스템 성능과 안정성을 평가하는데 중요한 역할을 하며, DataBase는 SQL 쿼리의 실행 계획이나 DB 연결 상태와 같은 세부 정보를 분석하여 데이터베이스 성능을 최적화합니다. Alert는 모니터링된 데이터에서 문제를 식별하고 사용자나 운영자에게 경고를 보내며, User 경험과 행동을 추적하여 서비스 품질을 평가합니다. WAS는 서버 내부에서 발생하는 이벤트를 모니터링하고, 서버 성능을 평가하는 역할을 합니다. Resource-Database-Alert-User-WAS 이 5가지 요소는 APM 아키텍처를 구성하는 핵심 요소이기도 한데요. 다음 내용을 통해 APM 아키텍처를 좀 더 자세히 살펴보겠습니다. │APM 아키텍처 APM 아키텍처는 Agent를 통해 WAS(관리대상) 실시간 데이터를 수집하고 → Manager에서 데이터를 수집/분석/가공 한 뒤 → 다양한 UI로 시각화합니다. 특히 꼭 기억해야 할 APM 아키텍처 핵심 3가지는 에이전트, 데이터베이스, 통신방식인데요. 좀 더 자세히 알아보겠습니다. 에이전트 APM 관리대상(예시: WebSphere, WebLogic, JBoss, JEUS, Tomcat 등)에 Agent라고 불리는 소프트웨어를 설치합니다. 그다음 모니터링 대상 시스템(WAS)에서 데이터를 수집하죠. 에이전트는 애플리케이션 내부 동작을 모니터링하고, 성능 데이터를 수집하는 역할을 합니다. 이러한 데이터를 활용하여 에이전트는 서비스 구간별 현황과 초당 처리 건수, 서비스 응답시간, 동시 접속자 수, 트랜잭션 거래량, 에러 등 상세한 지표를 제공해 주죠. 데이터베이스 수집된 데이터를 보관하고 분석하기 위해서는, 데이터베이스(DataBase)를 사용합니다. 이 데이터베이스는 대규모 데이터를 저장하고 관리하는 구조여야 하며, 분석하고 보고서를 생성하는데 필요한 데이터를 효율적으로 쿼리 할 수 있어야 합니다. 통신방식 APM 시스템은 보통 다양한 통신 프로토콜(Communication Protocol)을 사용하여, 데이터를 수집하고 전송합니다. 예를 들어 웹 소켓(WebSocket)을 통해 실시간 데이터를 전송하거나 http(s)를 사용하여 주기적으로 데이터를 전송하는 방식이 일반적입니다. 그다음으로는 APM은 어떤 주요 기능을 제공하는지 알아보도록 하겠습니다. │APM 주요기능 APM은 대표적으로 웹사이트와 소프트웨어 애플리케이션 및 서비스에서, 성능을 모니터링하고 분석하는 기능이 있는데요. 좀 더 자세한 APM 기능을 살펴보겠습니다. 실시간 성능 통합 모니터링 [그림] Zenius-APM 토폴로지 맵 APM은 Tomcat, Jboss, WebLogic, JEUS 등 다양한 애플리케이션 서버(WAS) 환경에서 실행되는 애플리케이션 통합 모니터링을 제공합니다. 시스템 간의 처리 성능과 현황 정보는 토폴로지 뷰를 통해 시각적으로 파악할 수 있죠. [그림] Zenius-APM 모니터링 상황판 또한 각 서버의 트랜잭션 처리량, 처리 속도, 자원 사용량을 실시간으로 분석하여 시스템 성능을 관리합니다. 특정 트랜잭션 실행 경로를 추적하고 분석하여, 성능 병목 현상도 식별할 수 있습니다. [그림] Zenius-APM 모니터링 서비스 응답분포 APM은 서비스 응답 분포도를 제공하여, 비정상적인 트랜잭션을 집중적으로 조회하고 분석할 수 있습니다. 장애관리 APM은 메모리 누수, 서비스 응답 지연과 같은 장애 원인을 실시간으로 추적하고 분석하는 기능을 제공합니다. Rawdata를 기반으로 장애 발생 시점을 재현하여, 문제의 근본 원인을 파악하는 데 도움을 주죠. 또한 자동 이벤트 처리는 장애 관리 규칙(Rule)에 따라 이루어지며, 문제 발생 시에는 사용자에게 즉각적인 알림을 제공합니다. 성능 분석과 통계 APM은 애플리케이션 성능을 다양한 지표(예: 성능비교, 기간비교, 증설 필요성, 시간대별 등)를 통해 분석하고, 여러 파일 형식의 보고서로 제공합니다. 또한 애플리케이션 성능 문제와 SQL 쿼리 간의 연관성을 분석하여 성능 개선 방안을 제안합니다. 다양한 환경 지원 레거시 시스템에서 클라우드 인프라에 이르기까지, APM은 다양한 IT 환경을 효과적으로 지원합니다. 또한 WAS 중심 성능 관리와 MSA(마이크로 서비스 아키텍처) 환경 모니터링을 가능하게 하는 기술을 제공하죠. 이번 시간에 알아본 내용처럼 APM은 다양한 애플리케이션 서버(WAS) 환경에서 실행되며, 트랜잭션 성능을 관리하는 통합 모니터링 제품입니다. Zenius-APM와 같이 다양한 WAS 환경에서의 통합 모니터링과 트랜잭션 처리 현황을 체계적으로 파악할 수 있는 APM을 통해, 효과적으로 웹 애플리케이션을 관리해 보세요! 2024.07.19
기술이야기 무선 AP에 대해서 꼭 알아야 할 세 가지 기술이야기 무선 AP에 대해서 꼭 알아야 할 세 가지 지난 시간에는 무선 AP를 '어떻게' 하면 효과적으로 관리할 수 있는지에 대한 TIP을 알려 드렸었는데요(링크). 여기서 잠깐, 무선 AP란? '무선 AP'는 Access Point의 약자로 Wireless Access Point 라고 하며, WAP으로 불리기도 합니다. 실제 인터넷으로 연결되는 신호는, 무선 신호를 받아서 유선 신호 체계로 전달해 주는 매개체가 필요한데요. 이를 AP가 담당합니다. 이름 그대로 Access Point로서 유선 신호를 무선으로 바꿔주거나, 무선 신호를 유선으로 바꾸는 접촉 지점의 역할을 하죠. 이번 시간에는 구성요소, 주요 활용사례, 관리 시스템 등 AP와 관련해서 꼭 알아야 할 세 가지를 살펴볼 예정입니다. 우선 그전에 무선 AP가 최근에 '왜' 필요해졌는지부터 짚어보겠습니다. │무선 AP의 필요성 무선 AP는 일반적인 유선 공유기보다, 설치 장소에 구애받지 않는다는 점에서 차별점을 가지고 있습니다. 무선 안테나가 AP에 자체적으로 내장되어 있고 PoE 기능을 통해 일반적인 가정에서 사용하는 유선 공유기보다 자유롭게 설치될 수 있죠. 이외에도 AP는 아래와 같은 특장점으로 각광받고 있습니다. 가용성 무선 AP는 일반적인 유무선 공유기보다 무선으로 연결된 기기를 더 많이 수용할 수 있는데요. 대규모 인원을 수용해야 하는 기업/공공 지자체/백화점/카페 등 대규모 클라이언트가 필요한 장소의 원활한 네트워크 연결을 용이하게 한다는 점에서 가용성이 뛰어납니다. 관리적 측면 무선 AP는 자신을 포함하여 대역을 무선으로 연결해 주는 기능이 기본적인 역할입니다. 하지만 부가적으로 무선관리 시스템으로부터 중앙 컨트롤을 받으며, 클라이언트의 통신 상태를 체크하는 기능을 가지고 있는데요. 사용자 확인부터 트래픽 양, 웹 접속 권한 설정과 알람까지 폭넓은 관리 기능을 제공하고 있습니다. 대규모 클라이언트 지원 일반적인 가정이 아닌 학교/기업/공공장소와 같은 대규모 클라이언트에 동시 접속을 하기 위해선, 대규모 접속을 처리할 수 있는 무선 AP가 필요합니다. 일반적인 공유기의 경우 약 한정된 IP만 할당받을 수 있으며, 인원이 많아질수록 속도 저하나 부하가 발생하기 때문이죠. 반면 무선 AP는 이러한 대규모 환경에서 접속을 효과적으로 처리할 수 있습니다. 편리성 무선 AP는 *SSID(Service Set Identifier)1가 하나로 통합되어, 접속 환경이 달라지더라도 무선 신호를 다시 잡을 필요가 없습니다. 반면 가정용 공유기의 경우 SSID가 별도로 분리되어 있어, 무선 신호 연결을 할 때마다 별도의 인증 절차를 거치게 되죠. 물론 공유기도 AP 모드로 SSID를 통합하여 사용할 수 있지만, 이는 네트워크 속도의 저하를 일으킬 수 있습니다. *SSID1: Wifi 공유기 검색할 때 나오는 명칭 이름(ex. SK_WifiXXXX) │무선 AP를 활용한 주요 사례 무선 AP는 앞에서도 언급했지만 대규모 환경에 적합하여, 다양한 분야에서 지속적으로 확대되고 있는데요. 몇 가지 대표적인 사례를 통해 좀 더 살펴보겠습니다. 디지털 뉴딜 정책 : 공공 와이파이 전환 사업 한국지능정보진흥원(NIA)에서는 2023년에 전국의 공공장소에 무선 인터넷 인프라를 대폭 확장하는 사업을 진행했습니다. 이 계획에 따라 그 해에만 4,400개의 새로운 공공장소에 공공 와이파이가 설치되어, 전체적으로 5.8만 개의 공공장소에서 공공 와이파이를 이용할 수 있게 되었습니다. 당진시 공공 와이파이 존 구축 당진시는 2018년까지 꾸준히 인구가 증가한 도시 중 하나입니다. 이러한 변화에 맞춰 교통과 물류의 인프라가 획기적으로 개선되었습니다. 더불어 당진시는 공공 와이파이 수요 증가에 대응하기 위해, Cisco AP 제품을 사용하여 시내 주요 지점에 공공 와이파이존을 확대하는 사업을 추진했습니다. 이 밖에도 국내 여러 도시에서는 스마트 시티 구축을 목표로, 도시 곳곳에 무선 AP를 설치하여 시민들이 어디서나 인터넷에 쉽게 접속할 수 있는 환경을 조성하고 있습니다. 대형 쇼핑몰, 카페 체인점(ex. 스타벅스), 호텔 등 상업 시설에서도 고객 경험 개선을 위해 무선 AP를 활용한 와이파이 서비스를 제공하고 있죠. 그렇다면 네트워크 환경에서 AP가 잘 관리될 수 있도록, 필수적으로 확인해야 하는 구성 요소는 무엇일까요? │무선 AP의 네트워크 환경 구성 요소 [그림] 무선 AP의 네트워크 환경 구성 요소 무선 AP를 구축하고 잘 관리하기 위해서는 AP 컨트롤러, LWAPP 프로토콜, PoE, UI 구성 요소들이 필요한데요. 각각 구성 요소들이 어떤 역할을 하는지 파악해 보겠습니다. AP 컨트롤러 AP 컨트롤러(WLC, Wireless Lan Controller)는 다량의 AP를 관리합니다. AP의 작동 상태를 실시간으로 모니터링하며, 접속 상태 확인과 AP 설정하는 역할을 담당하죠. 또한 로드밸런싱(대역폭 분산)과 함께 일부 AP 장애 시 주변 AP를 통한 장애 감지 기능, 플랫폼을 통한 클라이언트 접속 상태에 대한 실시간 모니터링 기능을 제공합니다. LWAPP 프로토콜 이때 AP 컨트롤러와 무선 AP 간의 통신을 위한 프로토콜인 LWAPP(Lightweight Access Point Protocol)가 필요한데요. LWAPP 프로토콜을 통해 각 AP는 컨트롤러로부터 자동으로 구성되고, 보안 업데이트를 받으며, 사용자 접속을 관리할 수 있기 때문이죠. 예를 들어 LWAPP 프로토콜 덕분에 쇼핑몰 방문객들은 어디서나 끊김 없는 와이파이 접속을 경험할 수 있으며, 운영자는 효율적으로 네트워크를 관리할 수 있습니다. PoE PoE(Power of Ethernet)는 무선 AP에 붙어 있는 이더넷 전원 장치로, 인터넷 케이블 하나에 데이터와 전원을 동시에 보내는 기술입니다. PoE를 이용하여 전원 코드를 따로 꽂을 필요가 없어, 설치가 간편하죠. 또한 별도의 어댑터 연결 없이 PoE 전송이 가능한 WAN 케이블 연결만 하면, 네트워크 기능과 전원 기능을 모두 구현할 수 있습니다. 이를 통해 AP의 벽면이나 천장에 설치가 가능합니다. UI AP 컨트롤러와 연계된 UI(UserInterface)로 AP 관리가 가능하며, AP에 연결된 클라이언트까지 확인할 수 있습니다. UI 화면을 통해 어느 정도의 트래픽을 사용했는지 확인할 수 있으며, AP의 이름(SSID)과 암호를 지정할 수 있습니다. 또한 AP에 연결된 클라이언트의 외/내부 관리가 가능합니다. Cisco Meraki와 Ruckus의 경우, AP 컨트롤러와 AP를 웹 화면으로 관리할 수 있는 UI 환경을 제공하는데요. 다음 사례를 통해 좀 더 자세히 살펴보겠습니다. │무선 AP와 컨트롤러 관리 시스템 앞에서 살펴본 것처럼 대규모의 무선 AP와 컨트롤러를 관리하기 위해서는 UI 환경, 즉 '모니터링'이 필수적인데요. 무선 AP와 컨트롤러를 모니터링할 수 있는 대표적인 사례를 살펴본다면 다음과 같습니다. Cisco Meraki [그림] Cisco Meraki 주요 장비 Cisco Meraki는 Cisco의 주요 AP, WAN, 스위치, 제품에 대한 모니터링이 가능합니다. Cisco 자체의 대시보드를 통해 장비와 현황 헬스 체크가 가능하며, 클라이언트의 실시간 사용속도와 AP에 연결된 클라이언트 리스트 역시 확인할 수 있죠. 또한 구글맵을 연동하여 주요 네트워크 장비의 위치 기반 모니터링이 가능합니다. Ruckus Networks Ruckus는 자사 네트워크 장비인 스위치, AP, AP 컨트롤러와 클라우드 관리 시스템을 제공하는 AP 전문 기업입니다. 컨트롤러와 연계된 웹 UI로 네트워크 상태를 원격으로 파악할 수 있죠. 또한 Ruckus의 대시 보드를 통해 주요 장비의 네트워크의 지리적 위치와 AP, 그리고 클라이언트 모니터링이 가능합니다. WNMS AP 벤더가 제공하는 AP 컨트롤러 관리 솔루션 외에도 WNMS(Wireless Network Monitoring System)를 통한 이기종 AP 관리가 가능합니다. 대규모 엔터프라이즈 환경에서는 다양한 이기종의 AP를 사용하는 경우가 많은데요. 이러한 환경에서 WNMS는 트래픽과 클라이언트 사용량을 확인할 수 있을 뿐만 아니라, 다양한 종류의 AP를 함께 관리할 수 있습니다. 이처럼 다양한 제조사의 AP를 하나의 시스템에서 통합적으로 관리할 수 있기 때문에, 대규모 환경에서 네트워크 관리를 효율적으로 운영할 수 있겠죠. [그림] Zenius-WNMS 모니터링 뷰 Zenius-WNMS 모니터링 화면을 보며 좀 더 자세히 살펴볼게요. Cisco와 Ruckus는 자사의 AP 무선 장비만 모니터링할 수 있는 솔루션인 반면, Zenius-WNMS는 AP 장비의 전체 운영 상황과 세부정보들을 모니터링할 수 있습니다. 컨트롤러, AP 장비 운영 상태, 벤더명, 주요 모델 및 트래픽 현황, 접속된 클라이언트 수 등 또한 확인이 가능합니다. [그림] Zenius-WNMS로 보는 무선 AP 트래픽 현황 이뿐만 아니라 Zenius-WNMS는 현재 운영중인 AP의 2.4GHz 대역, 5GH 대역에서의 트래픽 현황과 연결된 클라이언트 이벤트 현황도 모니터링할 수 있습니다. 다양한 감시 항목 설정을 통해, 주요 AP와 관련된 장애 이벤트와 운영 항목에 대한 모니터링도 가능합니다. 이를 통해 네트워크 관리자는 복잡한 네트워크 환경에서 발생할 수 있는 다양한 문제를 빠르게 대응할 수 있고, 네트워크의 성능 저하를 일으킬 수 있는 요소를 즉각적으로 식별하고 조치할 수 있죠. [그림] **대학교 종합상황판 Zenius-WNMS의 대표적인 사례로 **대학교를 들어볼 수 있는데요. 3,000여 개 이상의 대량 무선 AP를 관리하기 위해 통합 대시보드 UI 환경을 구축하였습니다. 이처럼 대규모 환경에서도 Zenius-WNMS는 효과적으로 무선 네트워크를 관리할 수 있습니다. 무선 AP와 이를 구성하는 요소들을 관리하는 체계적인 모니터링 시스템은, 이제 현대 사회에서 필수적으로 자리 잡았습니다. Zenius-WNMS을 활용하여 무선 AP를 하나의 시스템에서 통합적으로 관리하고, 대량의 무선 AP를 효율적으로 관리해 보세요! 2024.05.21
기술이야기 SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?! 기술이야기 SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?! 지메일, 유튜브, 구글맵스, 구글 클라우드까지.. 구글은 자사의 다양한 서비스들이 어디에서나 원활하게 돌아갈 수 있도록, 전 세계 곳곳의 수많은 데이터 센터를 운영하고 있습니다. 구글의 한 데이터 센터 전경(출처ⓒ google.com) 그리고 이 데이터 센터간의 효율적이고 안정적인 '네트워크' 구축을 위해, 다양한 노력을 펼치고 있습니다. 사용자에게 빠른 서비스를 제공하기 위해선 데이터 센터간의 높은 연결성과 효율성이 필수조건이기 때문이죠. 구글의 네트워크 운영은 2012년에 큰 전환점을 맞이합니다. 이 변화의 중심에는 SDN(Software Defined Network, 소프트웨어 정의 네트워크)이란 기술이 있는데요. 구글의 네트워크 운영 효율과 안정성을 극적으로 개선시킨 SDN은 과연 무엇일까요? 우선 SDN의 주요 특징부터 살펴보겠습니다. ㅣSDN의 두 가지 핵심특징 SDN은 네트워크 관리를 간소화하고 네트워크 구성의 유연성을 높이기 위해 고안된 기술입니다. SDN에는 두 가지 핵심적인 특징이 있는데요. 첫 번째 특징, 컨트롤 플레인과 데이터 플레인의 분리 SDN을 대표하는 첫 번째 특징은, 네트워크 장비의 전반적인 데이터를 중앙 집중적으로 관리할 수 있는 컨트롤 플레인(Control Plane)과, 트래픽 전송 역할을 하는 데이터 플레인(Data Plane)이 분리된 것입니다. 이러한 분리에 따른 두 가지 효과를 살펴보겠습니다. (1) 최적의 로드밸런싱이 가능해짐 기존에는 라우터와 스위치 등의 네트워크 장비가 경로를 결정했었습니다. 이 장비들은 주로 최단 경로 알고리즘을 통해 패킷을 전달하기 때문에, 네트워크 관리자가 특정 경로를 원하는대로 설정하기엔 어려움이 있었습니다. 즉 '로드밸런싱'이 어려웠었죠. 하지만 SDN은 이러한 상황의 변화를 가져왔습니다. [그림] SDN 로드밸런싱 예를 들어 보겠습니다. 기존에는 경로 정보가 있을 때 U에서 나가는 트래픽을 V와 X에 각각 분산시키고 싶을 경우, 기존의 최단 알고리즘을 통하면 항상 최단의 경로로만 라우팅할 수 있었습니다. 하지만 위 [그림]처럼 SDN을 사용하면 네트워크 관리자는 전체 네트워크의 상태를 실시간으로 파악하고, 트래픽을 V와 X로 균등하게 분산시키는 등 세밀한 조정을 할 수 있습니다. 이를 통해 네트워크의 효율성을 극대화하고, 트래픽 과부하나 장애 발생 시 빠르게 대응할 수 있게 되었죠. (2) 비용 절감과 효율성 증대 SDN을 통해 기업들은 고가의 전용 네트워크 장비를 사용하지 않고도, 필요한 네트워크 기능을 구현할 수 있게 되었습니다. 이에 따라서 초기 장비 투자 비용(CapEx)과 네트워크의 운영 비용(OpEx)을 모두 줄일 수 있습니다. 또한 네트워크 관리의 자동화와 최적화로 운영의 효율성을 높여주며, 장기적으로는 인적 자원에 대한 비용 절감으로도 이어집니다. 두 번째 특징, 중앙 집중식 관리 시스템 SDN을 대표하는 또다른 특징은 소프트웨어(SDN 컨트롤러)가 중앙에서 제어한다는 것입니다. 이 소프트웨어가 네트워크의 '두뇌' 역할을 하며, 네트워크의 각 기능이 어떻게 동작할지 지시합니다. 이러한 특징으로 인한 대표적인 효과를 살펴보겠습니다. (1) 유연성과 신속한 대응 기존 네트워크 시스템은 하드웨어 중심으로 돌아가기 때문에, 이 변화에 적응하기 위해선 실제 장비를 교체하거나 수동으로 설정을 변경해야 했습니다. 하지만 SDN에서는 모든 제어 기능이 '중앙'에서 소프트웨어로 이루어지기 때문에, 변경 사항이나 새로운 요구 사항이 발생했을 경우 관리자는 물리적 장비에 접근하거나 개별 설정을 조정할 필요없이 소프트웨어를 통해 네트워크를 즉시 업데이트할 수 있게 되었습니다. 이 덕분에 기존에 며칠이나 몇 주가 걸리던 네트워크 변경 작업을 몇 분 안에 할 수 있게 됐습니다. (2) 보안과 성능 최적화 기존의 전통적인 네트워크 관리 방식에서는, 네트워크의 각 부분에 대해서 심층적으로 들여다 보는 것이 어려웠습니다. 네트워크 장비와 시스템이 서로 다른 플랫폼과 프로토콜을 사용했기 때문에, 전체적인 네트워크 상태의 모니터링이 사실상 불가능했었죠. 하지만 SDN은 소프트웨어를 통한 중앙집중식 관리 시스템으로 이루어져 있기에, 네트워크의 모든 부분에 대한 실시간 통합 관리가 가능합니다. 이를 통해서 보안 위협을 빠르게 식별하고 대응할 수 있게 되었죠. 또한 트래픽 패턴을 정밀하게 분석하여 재분배하고, 트래픽 병목 현상을 예방하여 전반적인 네트워크 성능도 개선할 수 있게 됐습니다. SDN의 두 가지 특징과 그로 인한 효과를 알아봤는데요. 이제 SDN의 아키텍처와 구현 방식에 대해서도 한번 살펴보겠습니다. ㅣSDN의 아키텍처와 구현 방식 SDN 아키텍처: 세 가지 주요 계층 SDN은 네트워크 관리를 더 유연하고 효율적으로 만들기 위해, '세 가지' 주요 계층으로 구성되어 있습니다. 세 가지 계층은 앞서 언급했던 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인), 그리고 Application Plane(응용 프로그램 계층)입니다. 각 계층은 네트워크를 관리하고 운영하는데 있어 중요한 역할을 하는데요. 각 계층별 역할과 연관성에 대해서 알아보겠습니다. 우선 아래 [그림]에 가장 하단에 위치한 Data Plane(데이터 플레인)은 Control Plane(컨트롤 플레인)이 내린 결정에 따라 실제 데이터 패킷(Data packet)을 전송하는 역할을 합니다. 데이터 플레인은 스위치, 라우터 같은 물리적 장비를 통해 구현되며, 이들 장비는 데이터 패킷을 처리하고 전달하죠. [그림] SDN 아키텍처 중간에 위치한 Control Plane(컨트롤 플레인)은 네트워크에서 어떤 데이터가 어디로 가야 하는지 결정하는 역할을 합니다. 즉 Control Plane(컨트롤 플레인)은 네트워크 트래픽을 어디로 보낼지 결정하는 역할을 합니다. 가장 위에 위치한 Application Plane(응용 프로그램 계층)은 사용자에게 서비스를 제공하는 소프트웨어 애플리케이션을 말합니다. 이 계층은 SDN의 나머지 두 계층 위에 있으며, 네트워크의 다양한 리소스를 활용해 실제 사용자에게 서비스를 제공합니다. 클라우드 스토리지 서비스나 스트리밍 서비스 같은 것이 여기에 해당됩니다. 이 서비스들은 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인)을 통해 데이터를 주고 받으며, 사용자에게 콘텐츠를 제공하죠. 이처럼 세 계층은 서로 밀접하게 연결되어 있습니다. 다시 말해 Control Plane(컨트롤 플레인)이 네트워크의 전반적인 관리와 결정을 담당하면, Data Plane(데이터 플레인)은 그 결정을 바탕으로 실제 데이터를 전송하죠. 그리고 Application Plane(응용 프로그램 계층)은 이 모든 네트워크 인프라 위에서 동작하며, 최종 사용자에게 서비스를 제공합니다. SDN의 구현 방식 위에서 살펴본 것 처럼 SDN은 세 개의 층으로 이루어져 있는데요. 이 각각의 층이 '제대로' 역할을 수행하기 위해서 꼭 필요한 것이 SDN Controller, OpenFlow 프로토콜입니다. OpenFlow 프로토콜은 SDN 컨트롤러와 네트워크 장비 사이에서 동작하는 프로토콜입니다. 컨트롤 플레인과 데이터 플레인 사이의 소통을 담당하고 있죠. OpenFlow 프로토콜은 컨트롤 플레인이 네트워크 장비에 구체적인 지시를 내리고, 그 지시에 따라 트래픽을 어디로 보낼지 결정할 수 있게 해줍니다. [그림] SDN 컨트롤러, OpenFlow 프로토콜 SDN 컨트롤러는 이 모든 과정을 조율하는 '중앙 집중식 지휘소'라 할 수 있는데요. 컨트롤러는 네트워크의 전반적인 상황을 파악하고, 데이터 플로우를 최적화하기 위한 결정을 내리며, OpenFlow를 통해 그 결정을 네트워크 장비에 전달합니다. 컨트롤러가 없다면 마치 중앙 교통 관리 시스템이 없이 각자의 판단에 따라 움직이는 차량들처럼 혼란스러워 지겠죠. 이처럼 SDN 컨트롤러와 OpenFlow 프로토콜을 통해 구현된 중앙 집중식 네트워크 관리는 효율적이고 유연한 트래픽 조정을 가능하게 합니다. 이제 마지막으로 맨 앞에서 잠시 살펴 본 구글(Google)의 사례를 자세히 들여다보겠습니다. ㅣ사례를 통해 보는 SDN: 구글의 G-Scale 구글의 'G-Scale SDN 프로젝트(2012)'는 SDN을 가장 효과적으로 활용한 대표적인 사례입니다. 이 프로젝트는 구글이 2010년부터 진행한 OpenFlow 프로젝트의 일환으로, 구글 데이터센터 백본(BackBone)1 구간을 SDN 기반으로 전환하는 대담한 시도였죠. 구글 이 프로젝트를 통해 성취한 결과는 인상적인 수준을 넘어, 네트워크 관리 방식에 혁신을 일으켰다고 평가받고 있습니다. 구글은 얻은 대표적인 세 가지 이득을 살펴보겠습니다. *1: 백본: 전산망 속에서 근간이 되는 네트워크를 연결시켜주는 대규모 전송회선 [그림] 구글 G-Scale 프로젝트를 통해 구축된 데이터 센터(2012) 1. 인프라 리소스의 최적 활용 구글은 OpenFlow를 기반으로 한 SDN을 적용해 기존에 40~50% 수준에 머물렀던 네트워크 인프라의 활용도를 거의 100% 가까이 끌어올렸습니다. 기존 네트워크 시스템에서는 다양한 벤더의 장비들이 서로 완벽하게 호환되지 않은 문제로 인해, 전체 네트워크 장비의 효율성이 제한되곤 했었죠. 하지만 구글의 SDN 구현은 이러한 한계를 넘어서, 네트워크 자원을 훨씬 유연하게 관리할 수 있는 방법을 제시할 수 있게 했습니다. 2. WAN 대역의 경로 최적화 WAN(Wide Area Network)에서의 데이터 전송 속도와 효율성은, 전 세계 사용자들에게 고품질의 서비스를 제공하는 데 핵심적인 요소인데요. 구글은 SDN을 통해 이러한 WAN 대역의 데이터 전송 경로를 최적화하여, 사용자 경험을 크게 향상시킬 수 있었습니다. 이는 전 세계 서비스를 제공하는 구글에게 있어 대단히 중요한 성과였죠. 3. 네트워크 구축 비용의 절감 구글은 SDN 컨트롤러와 화이트박스 스위치의 조합을 통해, 데이터센터 내 네트워크 구축 비용을 대폭 낮출 수 있었습니다. 화이트박스 스위치는 사용자가 네트워크 장비의 동작방식을 직접 결정할 수 있게 하는 개방형 장비로, 구글은 이를 통해 더 효율적이고 경제적인 네트워크 인프라를 구축할 수 있게 됐습니다. 또한 구축 비용의 절감 뿐 아니라 전반적인 서비스 품질의 향상 효과도 거둘 수 있었습니다. [그림] 구글의 다양한 SDN 기술 이처럼 구글의 'G-Scale SDN 프로젝트'는 단순히 기술적 성공을 넘어서, 전 세계 통신사와 네트워크 장비 제조사들이 SDN을 도입하고 네트워크 가상화에 뛰어들게 만든 결정적 계기가 되었습니다. 구글은 여기서 한 발자국 더 나아가 BGP, Espresso, B4, Andromeda, Jupiter 등 다양한 SDN 기술을 적극적으로 활용하고 있습니다. 이러한 노력은 네트워크의 효율성을 극대화하고, 비용을 최적화하여, 데이터 중심의 세계에서 경쟁력을 유지하고, 사용자에게 더 나은 서비스를 제공하는 성과를 만들어내고 있습니다. 구글의 G-Scale 프로젝트라는 큰 성공을 만들어낸 SDN도 '어떻게 하면 안정적으로 네트워크를 관리하고 운영할 수 있을까?'라는 고민에서 시작됐습니다. 네트워크 관리의 중요성은 더욱 더 커지고 있습니다. SDN이라는 혁신적인 기술을 바로 도입하는 것도 물론 좋지만, 그 전에 현재의 네트워크를 제대로 모니터링 하고 있는지 부터 점검해봐야 합니다. 여러분의 네트워크는 제대로 관리되고 있나요? 2024.05.09
기술이야기 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

1 2