반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
서버 모니터링 데이터의 3가지 활용 방법
[브레인즈 소식] ‘원격 서비스 응답 블로킹 대기 상태의 트랜잭션 제어 시스템 및 방법’ 특허 취득
오다인
2023.07.19
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지?
브레인즈컴퍼니는 지난 6월 27일, APM(Application Performance Management) 관련 특허를 취득했습니다. 2022년 12월에 출원 신청한 것으로, 명칭은 ‘원격 서비스 응답 블로킹 대기 상태의 트랜잭션 제어 시스템 및 방법’입니다.
이번에 출원한 특허는 기존 Zenius APM에서 트랜잭션을 추적하고, 처리 중인 트랜잭션을 종료시키는 기능을 고도화한 기술인데요. 특히 MSA(Micro Service Architecture) 환경에서 애플리케이션 성능을 모니터링하고 안정적인 서비스 운영 환경을 만들기 위해 개발되었습니다.
IT 서비스 구조가 Monolithic에서 MSA 형태로 변화함에 따라, IT 서비스를 구성하는 환경은 점점 복잡해지고 있습니다. 이전에는 단순히 하나의 큰 애플리케이션으로 서비스를 구성하고 있었다면, 현재는 여러 개의 작은 애플리케이션으로 서비스가 나뉘어 있고, 또 각각의 서비스들은 네트워크를 통해 복잡하게 연결되어 있는 형태죠. 이런 구조에서는 서비스 간 연계 구간에서의 지연이 전체 서비스의 장애를 유발할 가능성이 높아집니다.
APM에서는 웹 애플리케이션에서 병목을 일으키는 트랜잭션을 모니터링하고 제어할 수 있는 기능을 제공합니다. 하지만 WAS 영역보다 확장된 네트워크 측면에서의 응답 지연이 발생하는 경우에는 해당 트랜잭션을 중지시킬 수 없어 병목을 유발하고 전체 서비스의 성능 저하로 이어질 수 있죠.
이번에 취득한 특허 기술은 이런 이슈에 대한 즉각적인 병목 해소를 통해, 실질적인 서비스 품질을 향상시킬 수 있습니다. 또한, Micro Service Architecture 시대에 IT 서비스를 영위하는 기업에 더욱 효과적인 모니터링 환경을 제공하게 됩니다.
Zenius APM은 이번에 취득한 특허 기술을 통해 MSA 구조의 분산된 환경에서 최적화되어, 애플리케이션 품질을 향상시키고 IT 서비스 연속성을 확보해 고객 만족도가 높아질 것으로 기대됩니다. 브레인즈컴퍼니는 앞으로도 지속적인 기술 개발을 통해 레거시는 물론, 클라우드 네이티브 환경에서의 모니터링 툴 활용도를 극대화하고, IT 인프라 관리자의 고민을 덜 수 있는 서비스를 만들기 위해 끊임없이 노력하겠습니다.
#브레인즈컴퍼니
#APM
#제니우스
#Zenius
#MSA
#웹 애플리케이션
#트랜잭션
#WAS
오다인
프리세일즈팀
사업 수주를 위한 업무를 수행하며 Zenius의 위닝 포인트를 만들어 갑니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
옵저버빌리티 향상을 위한 제니우스 대표 기능들
옵저버빌리티 향상을 위한 제니우스 대표 기능들
이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다.
2023.04.19
클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치
클라우드 네이티브의 핵심! CNCF의 세 가지 핵심가치
최근 디지털 트랜스포매이션(Digital Transformation)이 IT 트렌드로 자리 잡았습니다. 기업과 조직은 빠르게 변화하는 환경에 대응하고 경쟁에서 앞서기 위해 '클라우드 네이티브 컴퓨팅' 기술을 채택하고 있는데요. 여기서 클라우드 네이티브 컴퓨팅 기술을 연구 및 발전시키고, 생태계를 촉진하는데 중추적인 역할을 하는 커뮤니티가 바로 'CNCF(Cloud Native Computing Foundation)'입니다. 현재 CNCF에서는 Google, Intel, Azure 등 700여 곳 이상의 회원사들이 활동에 참가하고 있습니다. 이번 시간에는 CNCF가 정확히 무엇이고, 추구하는 핵심가치와 주요 프로젝트에 대해 자세히 알아보겠습니다. 。。。。。。。。。。。。 CNCF(Cloud Native Computing Foundation)란 CNCF는 2015년 12월에 리눅스 재단에 의해서 출범된 비영리 단체로, 네이티브 컴퓨팅 기술의 채택을 촉진하는 오픈소스 소프트웨어 재단입니다. CNCF는 클라우드 네이티브 컴퓨팅 플랫폼에서 사용하며, 확장 가능한 애플리케이션을 개발하는데요. 이와 관련된 기술인 컨테이너, 마이크로서비스, 서비스 메쉬 등의 발전을 촉진하여 이러한 기술 패턴을 누구나 이해하고 활용할 수 있도록 하는 것이 목표입니다. ▲총 24개의 CNCF Platinum Members 이러한 클라우드 네이티브 컴퓨팅 환경을 대중화하기 위해 Google Cloud, AWS, MS Azure, Cisco, IBM, Apple, Oracle, Red Hat, VMware, SAP 등 유수의 기업들이 플래티넘 회원사로 참여하여 뜻을 같이 하고 있습니다. CNCF의 세 가지 핵심 가치 CNCF의 핵심가치는 1) 클라우드 네이티브 기술의 촉진 2) 오픈소스 프로젝트 생태계 육성 3) 기술의 표준화 수립으로 정리할 수 있습니다. 이 세 가지 핵심 가치를 더 자세하게 살펴볼까요? CNCF 핵심가치1 : 클라우드 네이티브 기술의 촉진 CNCF는 현대적이고 미래 지향적인 '클라우드 네이티브 기술의 촉진'을 중요한 핵심 가치로 규정하고 있는데요. 이는 CNCF가 오늘날의 IT 생태계의 중심에 서서, 클라우드 네이티브 기술을 지속적으로 연구 및 개발하여 새로운 디지털 전환의 시대를 선도하고자 하는 의지가 담겨 있다고 볼 수 있습니다. CNCF는 기존 온 프레미스(On-Premise) 환경, 그리고 모놀리식(Monolithic)한 개발 환경에서 탈피한 컨테이너, 마이크로서비스, 서비스 메시, 서버리스 등. 보다 혁신적이고 미래지향적인 기술 영역을 보급하고 대중화하기 위한 노력과 지원을 아끼지 않습니다. ▲기존 모놀리식 아키텍처와 마이크로서비스 아키텍처 비교 또한 디지털 트랜스포메이션 과정에서 클라우드 환경으로의 전환이 더욱 효율적으로 이루어질 수 있도록, 클라우드 네이티브 기술과 기업들의 서비스 모델을 재구성하기 위한 방법들을 안내하고 있습니다. 이렇게 새로운 서비스 모델 구축을 통해 민첩성과 효율성을 강화하여, 빠르게 변화하는 IT서비스의 수요에 기민하게 대응하고 고객 요구에 부응할 수 있도록 지원합니다. 여기서 계속 언급되고 있는 '클라우드 네이티브'는 정확히 무엇을 뜻할까요? CNCF의 활동에 대한 이해도를 높이기 위해, 클라우드 네이티브의 의미를 짚어보겠습니다! 📑클라우드 네이티브(Cloud Native)란? 클라우드 네이티브는, 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축·배포·관리할 때의 소프트웨어 접근 방식입니다. 기업과 조직은 고객의 요구를 충족하기 위해 신속하게 업데이트할 수 있는 확장성과 유연성, 그리고 복원력이 뛰어난 애플리케이션을 구축하고자 합니다. 이를 위해 클라우드 네이티브에서 사용되는 기술들은, IT 서비스에 영향을 미치지 않고 애플리케이션을 신속하게 변경합니다. 또한 리소스를 효율적으로 활용하여 빠르게 변화에 대응할 수 있도록 지원하고 있습니다. 위의 개념을 '클라우드 컴퓨팅'과 비교한다면 보다 더 쉽게 이해할 수 있는데요. 클라우드 컴퓨팅은, 클라우드 서비스 제공 업체가 단순히 리소스와 인프라를 클라우드 형태로 제공하는 방식입니다. 여기서 서비스 제공 방식은 기존 '모놀리식' 방식과 크게 다르지 않습니다. ▲클라우드 네이티브의 핵심요소 ⓒPivotal 클라우드 네이티브는 마이크로서비스 아키텍처(MSA)와 컨테이너를 기반으로, IT 서비스의 확장·변경 등에 대응이 용이한 환경입니다. 예를 들어 Ex1) 서비스 수요가 폭증하거나 장애가 생겼을 경우 Ex2) 자동적으로 애플리케이션을 확장하거나 장애가 발생했을 경우에는 대체 가능한 모델을 바로 적용하여 Fail-Over가 손쉽게 이루어질 수 있도록 합니다. CNCF에서는 위 그림과 같이 클라우드 네이티브의 핵심 요소를 마이크로서비스, 컨테이너, 애플리케이션의 개발·통합·배포의 의미를 내포하는 DevOps, CI/CD의 개발 방법론을 포함하여 설명하고 있습니다. CNCF 핵심가치2 : 오픈소스 프로젝트 생태계 육성 CNCF는 다양하고 혁신적인 '오픈소스 프로젝트'를 개발·공급·대중화하여, 클라우드 네이티브 생태계를 활성화하는데 큰 기여를 하고 있습니다. 또한 클라우드 네이티브 컴퓨팅 환경을 구성하고 효율적으로 운영하기 위해, 다양한 오픈소스를 개발하고 있는데요. 누구나 이와 같은 기술들을 이용할 수 있도록 지원합니다. 가장 성공적인 프로젝트는 2018년 8월에 컨테이너 오케스레이션 플랫폼인 'Kubernetes' 프로젝트이며, 컨테이너 생성·실행·종료 등의 역할을 하는 'Containerd', 시스템 모니터링 및 경고 역할을 하는 'Prometheus' 그리고 여러 시스템의 트래픽을 균등하게 분배하여 로드밸런싱을 제공하는 'Envoy' 등이 있습니다. 이처럼 클라우드 네이티브 생태계 활성화를 위한 다양한 프로젝트를 실행하며 배포하고 있습니다. ▲CNCF 개발 완료된 프로젝트 이외에도 클라우드 네이티브 커뮤니티인 이벤트·웨비나·워크샵 등을 활성화하여, 온오프라인 영역에서 개발자들 간의 교류를 원활하게 합니다. 개발자들이 오픈소스 프로젝트를 효과적으로 활용할 수 있도록, 사용법에 대한 교육과 튜토리얼을 제공하기도 합니다. 이를 통해 많은 기업과 이용자들이 클라우드 네이티브 환경에 손쉽게 접근할 수 있도록 지원하고 있습니다. CNCF 핵심가치3 : 기술의 표준화 수립 CNCF는 클라우드 네이티브 관련 기술의 무분별한 확장과 사용으로 인한 혼란을 방지하고자, 기술의 표준화를 촉진하고 정책의 일관성을 확보하는 노력 또한 지속하고 있는데요. 기술의 안정성과 품질 확보를 위해 재단 자체적으로 테스트와 벤치마킹 등을 수행하고, Best Practice를 공유하여, 기술의 표준화와 성숙도를 유지합니다. 이 외에도 CNCF는 새로운 기술의 적용 가능성과 성숙도를 평가하고, 클라우드 관련 기술을 보유한 회원사 및 파트너와의 협력을 촉진합니다. 이처럼 다양한 형태로 클라우드 네이티브 생태계의 지속적인 발전을 지원하고 있습니다. 。。。。。。。。。。。。 이번 시간에는 CNCF의 정의와 핵심가치를 알아보았는데요. CNCF는 앞에서 소개해 드린 내용처럼, 클라우드 네이티브 생태계 활성화를 위해 다양한 노력을 기울이고 있습니다. 브레인즈컴퍼니 역시 클라우드 네이티브 모니터링을 위한 다양한 제품과 기능들을 속속 출시하고 있으니, 많은 관심 부탁드립니다. 다음 시간에는 [CNCF의 핵심 프로젝트] 주제로 돌아오겠습니다!
2023.12.27
쿠버네티스와 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
오픈소스 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
다음 슬라이드 보기