최신이야기 | 브레인즈컴퍼니

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

메인 페이지로 이동
블로그
최신이야기

블로그

최신이야기

기술이야기 WAS(웹 애플리케이션 서버) 성능, APM을 통해 최적화하는 법 기술이야기 WAS(웹 애플리케이션 서버) 성능, APM을 통해 최적화하는 법 WAS(Web Application Server)는 현대 기업들이 운영하는 다양한 웹 애플리케이션이 원활하고 안정적으로 작동하도록 돕는 핵심 인프라입니다. 온라인 쇼핑몰, 인터넷 뱅킹, 병원 정보 시스템 등, 일상생활에서 자주 접할 수 있는 부분에서 WAS의 역할이 두드러지게 나타나죠. 대표적으로 온라인 쇼핑몰을 예를 들어 볼까요? 블랙프라이데이와 같은 쇼핑 성수기에는 많은 사람들이 동시에 웹사이트에 접속하기 때문에, 서버에 큰 부담이 생깁니다. 이때 WAS는 부하 분산 기능과 세션 관리를 통해 이런 부담을 효과적으로 나누어 처리하고, 각 사용자의 접속 상태를 잘 관리하여 웹사이트가 원활하게 작동하도록 돕는데요. 만약 WAS가 제대로 작동하지 않으면 웹사이트가 느려지거나 접속이 되지 않아 고객들이 불편을 겪고, 결국 매출 손실로 이어질 수도 있습니다. 이러한 이유들로 인해 WAS를 안정적으로 운영하기 위해서는 APM(Application Performance Management)이 필요합니다. APM은 애플리케이션 성능을 실시간으로 모니터링하고, 최적화하며, 성능 저하나 장애를 사전에 예방할 수 있도록 도와주는 시스템을 의미하는데요. 그렇다면 APM을 통해 어떤 방식으로 WAS를 관리할 수 있을까요? │APM으로 WAS(Web Application Server)를 관리하는 방법 우선 첫 번째로는, WAS에서 실행 중인 애플리케이션을 실시간으로 모니터링할 수 있습니다. 즉 WAS에서 실행 중인 애플리케이션이 제대로 작동하는지 실시간으로 확인할 수 있어, 문제가 발생해도 신속하게 해결할 수 있도록 도와주죠. [그림] Zenius APM : 실시간 모니터링 상황판 Zenius APM을 통해 자세히 살펴볼게요. Zenius APM은 한 화면에서 전체 또는 인스턴스 별로 수행되고 있는 트랜잭션의 처리 현황을 종합적으로 파악할 수 있는데요. 서버의 상태와 애플리케이션 성능이 정상적으로 작동하는지 한눈에 확인할 수 있고, 문제가 발생할 경우 빠르게 대응할 수 있습니다. • • • • • • 두 번째로는, 애플리케이션의 서비스가 지연되는 현황을 확인할 수 있습니다. 사용자 웹 페이지가 느려지면, 지연 원인을 빠르게 파악하고 조치해야 하기 때문에 이러한 문제를 직관적으로 파악할 수 있어야 합니다. [그림] Zenius APM : 액티브 서비스 모니터링 Zenius APM을 통해 살펴보면 액티브 서비스 처리 현황을 확인할 수 있습니다. 이 현황을 통해 스피드 메타 차트를 통해 전체 실시간 트랜잭션 유입량과 처리 상태, 그리고 서비스 지연 여부를 확인할 수 있는데요. 사용자의 웹 페이지가 느려질 경우 위 그림처럼 빨간 표기로 지연된 부분을 파악할 수 있습니다. [그림] Zenius APM : 액티브 서비스 현황 모니터링 만약 처리가 지연되고 있다면 인스턴스, 액티브 서비스 현황 차트를 통해 보다 명확하게 확인할 수 있습니다. 위 그림과 같이 이퀄라이저 차트에서 주황색 또는 붉은색으로 표시된 부분을 통해, 인스턴스에서 발생한 잠재적인 문제를 확인할 수 있죠. 이렇게 지연된 서비스가 발견된 인스턴스에서 처리 중인 트랜잭션 목록을 확인할 수 있습니다. 또한 지연된 트랜잭션이 어느 단계에서 멈춰 있는지도 파악할 수 있습니다. [그림] Zenius APM : 서비스 응답 분포 및 트랜잭션 상세 모니터링 처리 완료된 트랜잭션의 지연 구간은 서비스 응답 분포를 통해 확인할 수 있으며, 이슈 정보를 통해 좀 더 상세한 지연 위치를 알 수 있습니다. • • • • • • 세 번째는, 과거 장애 시점에 대한 정밀한 장애 원인을 분석할 수 있습니다. 이 기능은 장애 재발을 막고 시스템의 안정성을 높이기 위해 중요한 부분인데요. [그림] Zenius APM : 스냅샷 분석 예시를 통해 자세히 알아보겠습니다. Zenius APM과 같은 APM 솔루션은 장애 시점에 대한 정보를 스냅샷을 통해 과거 실시간 상황을 동일하게 재현하여, 당시의 시스템 상태와 성능을 정확히 파악할 수 있게 도와줍니다. 또한 모든 세부 정보를 포함한 Raw 데이터를 기반으로 하는데요. 과거 시점에 장애 원인 분석을 보다 정밀하게 파악할 수 있어, 장애 재발을 방지하고 시스템 안정성을 확보할 수 있습니다. • • • • • • 지금까지 APM을 통해 어떻게 WAS를 관리하는지 살펴보았습니다. 하지만 여기서 한 가지 더 알아야 할 것은, 애플리케이션 성능 저하가 WAS만의 문제는 아니라는 점입니다. CPU, 메모리, 디스크 I/O 등 서버 자원의 부족이나 데이터베이스 쿼리 성능 저하 등 다양한 원인에 의해 발생할 수도 있죠. 따라서 이러한 모든 요소들을 종합적으로 모니터링하는 것이 중요한데요. 이러한 요구를 해결하기 위해 Zenius APM은 서버와 데이터베이스를 자동으로 매핑하여 연관 관계를 시각적으로 확인할 수 있는 '토폴로지 맵'을 제공합니다. 이를 통해 애플리케이션 성능 저하가 서버 자원의 부족 때문인지, 데이터베이스 쿼리 성능 저하 때문인지 명확히 파악할 수 있습니다. 이번 시간에는 APM으로 WAS를 어떻게 관리하는지 알아보았습니다. 결론적으로 기업에서 안정적이고 신뢰할 수 있는 웹 애플리케이션 환경을 구축하기 위해서는, APM은 더 이상 선택이 아닌 필수입니다. 이제 Zenius APM을 통해 WAS 관리를 효과적으로 관리하여, 최적의 웹 애플리케이션 성능을 유지해 보세요! 🔍더보기 Zenius APM으로 WAS 관리하기 📝함께 읽으면 더 좋아요 • APM에서 꼭 관리해야 할 주요 지표는? • APM의 핵심요소와 주요기능은? • 옵저버빌리티 vs APM, 우리 기업에 맞는 솔루션은? • 오픈소스 APM만으로 완벽한 웹 애플리케이션 관리, 가능할까? 2024.07.29
기술이야기 오픈소스 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
기술이야기 옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?! 기술이야기 옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?! 지난 글을 통해 웹 애플리케이션을 전반적으로 모니터링하고 관리하기 위한 좋은 도구인, APM의 핵심요소와 기능에 대해서 알아봤습니다(지난 글 보기). APM은 분명 좋은 도구이지만 문제 원인이 애플리케이션, 웹, WAS, DB가 아닌 특정한 시스템 오류이거나 클라우드 네이티브 환경에서의 장애일 경우 문제 발생 원인을 명확히 밝히기 어려울 수 있습니다. 따라서 이번 시간에는 APM의 한계성은 무엇이고, 이를 보완하기 위한 방법은 무엇인지 자세히 살펴보겠습니다. │APM 한계성 불과 얼마 전까지만 해도 예상치 못한 장애를 탐지하고 분석하는 것은, 기존 APM만으로 충분했었습니다. 기존에는 모놀리식 구조로 되어있어 애플리케이션이 적은 수로 구성되어 있었고, Web-WAS-DB가 모두 단일 구조로 구성되어 있었기 때문입니다. 하지만 현재 대다수 기업들은 MSA 환경에서 서비스를 구축하고, DevOps 구조로 업무를 진행하는 경우가 많습니다. 즉 클라우드 네이티브 환경에서는 기존 모놀리식 구조의 APM의 한계가 하나둘씩 보이기 시작한 것이죠. 이러한 이유로 클라우드 네이티브 방식에는 서비스 장애 원인을 분석하기 위한 새로운 모니터링 툴이 필요했습니다. 이때 등장하는 것이 바로 옵저버빌리티(Observability)입니다. │Observability란? 그렇다면 Observability란 무엇일까요? 옵저버빌리티는 IT 인프라에 대한 근본적인 장애 원인을 분석하기 위한 방법론입니다. 관찰 가능성이라고 표현되기도 하죠. Obsevability는 비교적 최근에 사용한 용어이지만, 옵저버빌리티를 위한 고민은 오래전부터 지속되어왔습니다. 시스템이 내가 의도한 대로 작동하고 있을까? 예상치 못한 장애 탐지와 장애 근본 원인은 어떻게 분석할 수 있을까? IT 인프라 운영 환경에 문제가 발생했을 때, 문제 식별을 위해 필요한 객관적인 지표는 어떻게 도출할 수 있을까? 하지만 소프트웨어 애플리케이션에서 Observability는, 위와 같은 고민이 발생하거나 겪어보지 못했던 현상이 생길 때 이를 이해하고 설명할 수 있는 지표를 분석해 줍니다. │Obsevability의 등장배경 및 필요성 앞에서 옵저버빌리티가 무엇인지 살펴봤는데요. 이어서 Observability가 등장하게 된 이유와 필요성에 대해 자세히 살펴보겠습니다. MSA 전환에 따른 복잡성 증가 옵저버빌리티가 등장하게 된 첫 번째 이유는, 모놀리식 아키텍처에서 MSA 환경으로 전환함에 따라 복잡성이 증가했기 때문입니다. 우선 그림을 통해 자세히 살펴보겠습니다. [그림(왼)]은 모놀리식 아키텍처를 나타내는데요. 애플리케이션의 모든 구성 요소가 하나의 인프라로 통합되어 있는 형태입니다. 배포가 간단하며, 확장성이 쉽고, E2E 테스트가 용이하다는 장점이 있습니다. 하지만 조그마한 수정 사항이 있으면, 다시 구성 환경을 빌드하고 배포해야 한다는 단점이 있습니다. 또한 일부 오류가 전체 아키텍처에 영향을 미친다는 치명적인 단점도 존재하죠. 반면 [그림(오)]에 해당하는 MSA(Micro Service Architecture)는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어, 변경과 조합이 가능합니다. 작은 서비스의 독립적 배포라는 강력한 장점을 앞세워 Netflix, PAYCO와 같은 다양한 기업들이 앞다투어 MSA를 받아들였습니다. 여기서 문제는 MSA로 변화함에 따라 통합 테스트나 E2E 테스트 검증이 필요해졌는데요. 이처럼 여러 서비스의 API를 검증해야 하므로, 복잡성이 증가하고 많은 시간과 비용이 소모되었습니다. 무엇보다 각 서비스 별로 자체적인 데이터베이스가 있어, 트랜잭션에 대한 파악이 어려워지기도 했죠. 따라서 기존 APM이 담당하는 트랜잭션 모니터링의 복잡성은 더욱 증가했고, Observability의 필요성이 대두되었습니다. DevOps와 클라우드 네이티브 환경으로서의 전환 옵저버빌리티가 등장하게 된 두 번째 이유는, DevOps와 클라우드 네이티브 환경으로 전환하기 위해 필요한 도구이기 때문입니다. DevOps의 핵심은 소프트웨어의 개발(Deployment)과 운영(Operation)을 분리하는 것이 아닌, 하나로 통합된 업무 처리 방식으로 진행됩니다. 이때 관리하는 서비스 전반에 대한 가시성이 충분히 확보되지 않으면, DevOps 조직은 근본적인 원인을 찾는 데 어려움을 겪게 됩니다. 이러한 어려움을 해결하기 위해서는 서비스를 구성하는 아키텍처부터 트랜잭션까지 가시성이 확보되어야 합니다. 이를 통해 DevOps의 목표인 지속적인 개발과 운영의 통합을 만들어낼 수 있죠. 또한 Observability는 클라우드 네이티브 환경으로 전환하기 위한 필수 조건입니다. 기업에서 운영 중인 서비스/IT 인프라가 클라우드 네이티브 환경으로 전환되면서, 이전에 발생하지 않았던 모든 장애 가능성에 대한 인지를 위해 Observability가 선행되어야 합니다. │Observability와 Monitoring 차이점 그렇다면 기존의 모니터링(Monitoring)과 옵저버벌리티(Observability)의 차이점은 무엇일까요? 기존의 모니터링 역할은 IT 인프라의 '정상 작동 확인'을 위한 도구 역할에 초점이 맞춰져 있었습니다. 모니터링 구성 요소인 대시보드와 사용자 알람을 통해 가시성을 확보하고, 장애를 쉽게 감지할 수 있었죠. 즉 모니터링은 인프라 성능 지표, 구성 관리, 사용자 알람에 주 목적을 둔 IT 운영 담당자에 포커스를 맞춘 도구입니다. Observability는 기존 모니터링이 맡는 알람(Alerting), 메트릭(Metric) 외에도 로그(시스템, 애플리케이션), 트레이스, 디버깅과 같은 작업이 가능합니다. 이를 통해 앞으로 발생할 수 있는 장애를 미리 예측하고, 발생한 장애에 대한 근본적인 원인을 찾아내는 데 초점이 맞춰져 있습니다. │Observability 확보를 위한 핵심 구성 요소 옵저버빌리티는 앞서 언급했듯이 메트릭(Metric), 로깅(Logging), 트레이싱(Tracing) 등 작업이 가능한데요. 좀 더 자세히 살펴보겠습니다. Metric 모니터링 분야에서 Metric(메트릭)이란, 인프라 혹은 서비스 성능과 상태를 나타내는 지표입니다. 여기서 중요한 점은 단순히 현재 상태를 보기 쉽게 표현하는 것에서 더 나아가 '시계열 데이터' 형태로 변화하는 데이터를 보여줘야 합니다. 예를 들어 CPU 사용률, 메모리 사용률, 스레드 사용률과 같이 시간이 지남에 따라 어떻게 변화하는지 효율적으로 보여줄 수 있어야 하죠. 또한 메트릭은 여러 AI 분석툴과 오픈소스와 결합하여, 직관적인 파라미터를 통해 시계열 데이터의 다양한 패턴을 자동 감지할 수 있어야 합니다. 운영자와 개발자에게 필요한 리소스를 선택할 수 있도록 성능 예측하는 지표도 필요합니다. Logging Logging(로깅)은 운영 중인 시스템과 애플리케이션에서 발생하는 다양한 이벤트와 에러 등을 기록하는 과정입니다. Observability는 여기서 더 나아가 클라우드 시스템의 모든 로그를 수집하여, 해당 로그를 통해 문제 원인을 식별할 수 있어야 합니다. 물론 각 로그 스트림은 단일 인스턴스에 대한 이벤트를 알려주기 때문에, 마이크로 서비스 환경에서 전체적인 문제 원인을 파악하기 어려울 수 있습니다. 하지만 중앙 집중식 로깅을 사용하면, 애플리케이션 로그를 한곳에 저장할 수 있습니다. 이를 통해 여러 서비스로 구성된 MSA 환경에서 로그를 효과적으로 검색하고 모니터링할 수 있죠. 이러한 작업을 하기 위해서 ELK Stack1 과 같은 로그 수집 활용 도구가 필요한데요. 이 도구는 로그 관리를 단순화화여, 전체 시스템 문제를 더 쉽게 분석할 수 있도록 도와줍니다. *ELK Stack1: Elastic Search. Logstash, Kibana의 약자로 데이터를 수집하고 분석하는 도구 모음 Tracing 트레이싱은 애플리케이션 실행 정보를 기록하는 '특별한 로깅' 방식을 의미합니다. 사실 로깅과 트레이싱을 구분하는 것에 큰 의미는 없습니다. 하지만 Observability 관점에서 트레이싱은, 전체 로그 중 문제를 일으키는 특정 로그들을 시각화하고 이를 선택적으로 관찰하는데 의미가 있습니다. Debugging Observability에서 말하는 디버깅은, 시스템과 서비스 성능을 확인하고 검사할 수 있는 다양한 도구입니다. 장애 원인을 찾을 경우 그 장애 원인뿐만 아니라, 연관관계를 가진 여러 인프라와 애플리케이션을 함께 보여줄 수 있어야 하죠. RUM RUM은 Real User Monitoring 약자로, 사용자의 인터랙션을 추적하여 웹사이트나 애플리케이션 성능을 실시간으로 모니터링하는 기술입니다. 옵저버빌리티는 앞서 언급했듯, 더 이상 IT 인프라 운영자를 위한 도구가 아닙니다. DevOps를 위한 통합적인 가시성을 제공하는 도구이죠. 따라서 운영자와 개발자를 위한 '실제 사용자 관점'에서 모니터링을 제공해야 합니다. 이처럼 옵저버빌리티 시스템은 애플리케이션의 전체적인 상태를 깊이 있게 파악하고, 문제 원인을 분석하는 데 중점을 두는 접근 방식입니다. 그렇다면 애플리케이션 성능 관리 시스템인 APM 도구와는 어떤 차이점이 있을까요? │APM과 Observability 차이점 어떻게 보면 APM과 Observability는 비슷해 보이지만, 문제 원인과 인프라를 분석하는 시각에 따라서 다양한 차이점을 지니고 있습니다. 우선 첫 번째 차이점으로는 모니터링 목적 대상에 따른 차이가 있습니다. APM은 E2E(End-to-End) 성능 구간에 주목합니다. WEB-WAS-DB에 걸친 이 과정을 실제 서비스 사용자의 *액티브 서비스2에 초점을 맞춰, 애플리케이션 성능을 분석하고 모니터링하죠. *액티브 서비스: 현재 시점에서 사용자에게 제공되고 있는 상태 Observability는 APM에서 주목하는 E2E보다, 더 많은 범위를 모니터링합니다. 시스템 인프라, WAS, DB에 대한 정밀 성능 분석과 장애 감지는 물론. 운영 중인 인프라와 서비스를 통합하여 문제 원인을 찾는 데 집중합니다. [그림] Zenius-APM 사용자 정의 실시간 모니터링 상황판 따라서 두 번째 차이점으로는, 측정하는 지표에도 많은 차이가 있는데요. APM은 사용자 요청에 따른 응답 시간과 응답 분포, 액티브 서비스 상태, 트랜잭션 처리율, 이슈 중심으로 '사용자 요청' 관점에 따라 주요 지표를 확인할 수 있습니다. Observability는 사용자의 요청 관점이 아닌, 발생할 수 있는 '모든 이벤트 지표'에 주목합니다. 보다 더 전방위적인 모니터링이 가능하죠. 또한 옵저버빌리티는 기존 APM에서 발생하는 주요 장애 원인뿐 아니라, 예측하지 못한 장애를 객관적인 지표로 보여줍니다. 정리한다면 인프라와 서비스를 분석하고 장애를 탐지한다는 점에서 APM과 Observability는 동일한 역할을 갖지만, 결국 사용자가 무엇을 더 초점에 맞추느냐에 따라 사용 목적은 아래와 같이 달라질 수 있습니다. 우리 기업은 Observability가 맞을까, APM가 맞을까? APM Type Observability Type 애플리케이션 성능 최적화가 필요한 경우 애플리케이션 코드 내의 문제를 식별하고 해결하는 데 중점을 둘 경우 MSA 환경이 아닌 모놀리식 아키텍처에서 서비스를 구성하고 있는 경우 MSA 환경에서의 분산 시스템을 통해 서비스를 구성하는 경우 단순한 애플리케이션 성능을 넘어 전체 IT 인프라 환경에 대한 통찰력 확보가 필요한 경우 인프라 운영자, 개발자, 보안담당자 모두가 통합 모니터링 환경이 필요한 경우 이번 글에서는 옵저버빌리티의 중요성과 APM의 차이점을 자세히 살펴보았습니다. 결론적으로 옵저버빌리티와 APM 중 어느 하나를 더 좋다고 할 수 없으며, 각 조직의 요구사항과 사용 편의성에 맞춰 선택해야 합니다. 그러나 점점 복잡해지는 IT 환경을 고려한다면, 옵저버빌리티를 기반으로 한 Zenius-APM과 같은 도구를 활용하여 좀 더 효율적으로 웹 애플리케이션을 관리해 보는 것은 어떨까요? 🔍더보기 Zenius APM 더 자세히 보기 📝함께 읽으면 더 좋아요 • APM에서 꼭 관리해야 할 주요 지표는?! • APM의 핵심요소와 주요기능은?! 2024.07.24
기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-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
기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 지난 블로그에서는 옵저버빌리티가 기존 모니터링과 어떻게 다른지 비교해봤습니다. 간략히 되짚어보면, 옵저버빌리티란 IT 환경이 다양해지고 기업의 서비스가 점점 복잡해짐에 따라 빠르게 문제를 찾아 해결하기 위해 서비스의 내부 상태와 동작을 이해하는 능력입니다. 옵저버빌리티는 IT 인프라별로 어떤 것이 문제라는 기준을 중심으로 모니터링하는 기존 방식에서 벗어나 모든 데이터를 실시간으로 수집하고 분석하여 IT시스템의 근본 원인에 접근하고, IT 운영 전문가의 노하우를 바탕으로 각 메트릭별 상관관계를 분석해 미래의 장애를 예측하는 인사이트를 강조합니다. 이번 블로그에서는 옵저버빌리티 확보에 가장 기본이자 중요한 정보 소스인 로깅, 메트릭, 트레이싱을 중심으로 알아보겠습니다. 이 세가지 소스는 시스템의 정확한 모니터링을 보장하고, 문제가 발생할 때 무엇이 잘못됐는지 근본원인을 추적하고, 전체 기능을 개선하는 데 도움이 되는 방법들입니다. 물론 이 세가지 방법만으로 옵저버빌리티가 확보됐다고 할 수는 없습니다. 옵저버빌리티 확보를 위해서는 로깅, 메트릭, 트레이싱을 통합해 이벤트의 상관관계를 분석하고, 데이터 시각화로 사용자에게 인사이트를 제공하는 능력이 추가돼야 합니다. l Logging : 시스템 내에서 발생하는 이벤트를 인지하고 향후 분석을 위해 저장하는 프로세스 l Metric : 응답 시간 또는 오류율과 같은 시스템 성능을 설명하는 숫자 값 l Tracing: 개발자가 병목 현상과 성능 문제를 식별할 수 있도록 서비스 호출 경로와 시간을 추적하는 프로세스 Logging 로깅은 로그를 남기는 것으로 로그를 수집하고, 저장하는 프로세스입니다. 로깅은 시스템 동작을 이해하고 문제를 진단하는 데 필요한 것으로, 향후 분석을 위해 저장하는 데이터인 만큼 올바른 세부 기준에 따라 의미가 있는 로그를 추출하는 것이 필요합니다. 그리고 예를 들어 웹 애플리케이션에 문제가 발생한 경우 로그를 남기는데, 메트릭을 통해서는 이 문제를 발견할 수 없으므로 그래서 로그는 중요합니다. 로그의 수집은 간단한 텍스트 파일에서 ELK(Elasticsearch, Logstash, Kibana)처럼 정교한 프레임워크에 이르기까지 다양한 형태를 취할 수 있습니다. 그래서 로그는 정형화하기 어렵고 그 양이 방대함으로 로그를 수집, 저장하고 분석할 때 다음과 같은 사항을 유의해야 합니다. l 과도한 로깅은 스토리지 비용을 증가시키고 로그의 검색 효율을 떨어뜨릴 수 있습니다. 따라서 어떤 데이터를 기록하고, 어떤 데이터를 기록하지 않을지 필터링하는 것이 중요합니다. l 장기간 보관할 필요가 없는 로그 효율적인 로깅 시스템을 위한 로그 보관 정책이 필요합니다. l 로그에는 인사이트를 제공할 수 있는 모든 컨텍스트 정보가 포함돼야 합니다. l 로깅은 다른 프로세스에 영향을 미치지 않도록 비동기 방식이어야 합니다. l 민감한 데이터가 로그에 남겨지지 않도록 마스킹을 해야 합니다. 그럼 로그 분석을 통해 알 수 있는 정보는 무엇이 있을까요? l 시스템의 상태: 로그에는 어떤 액션을 수행했는지, 어떤 데이터가 처리됐는지, 또 어떤 오류가 발생했는지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 시스템의 상태를 파악할 수 있습니다. l 이슈 파악: 로그에는 어떤 오류가 발생했고, 어떤 요청이 실패했는지, 어떤 리소스가 부족한지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 이슈를 파악하고, 빠르게 대응할 수 있습니다. l 보안성 강화: 로그에는 로그인 시도, 권한 부여, 보안 이벤트 발생 등의 정보가 담겨 있으므로 이러한 정보를 분석해 보안 이슈를 파악하고, 보안성을 강화할 수 있습니다. Metric 로그가 텍스트라면 메트릭은 단순한 수치입니다. 메트릭은 시스템의 상태를 측정하고, 모니터링하는데 사용되는 숫자 측정값입니다. 조금 더 자세히 설명하면, 메트릭은 측정 항목을 정의하고 해당 항목을 수치로 측정해, 그 결과를 보고하고 시스템이 정상적으로 동작하는지 확인하거나 장애를 빠르게 감지하기 위한 소스입니다. 메트릭의 측정 대상은 CPU 사용률, 메모리 사용률, 네트워크 트래픽 등 인프라의 성능이나 초당 수신하는 요청수, 응답에 걸린 시간, 사용자에게 오류를 다시 보낸 응답 수 등 애플리케이션의 상태와 관련돼 있습니다. 메트릭을 통한 수집 가능한 범위는 모니터링 도구 사용 여부에 따라 달라집니다. 일반적인 방식은 에이전트를 이용해 모니터링 대상으로부터 데이터를 수집하는 것으로, 수집할 메트릭을 정의하기가 유연하고 성능이나 안정성 등의 이슈에 대한 정보도 수집할 수 있는 장점이 있습니다. 에이전트를 사용하지 않고 운영 체제나 애플리케이션에서 제공하는 메트릭 수집 API를 사용하는 방식도 있는데, 수집하는 메트릭이 비교적 제한적입니다. 단순히 메트릭을 수집하는 것만으로 시스템을 모니터링하기에 충분하지 않습니다. 메트릭 데이터를 잘 활용하기 위해서는 분석 방법이 중요한데, 분석을 위해서는 몇가지 단계를 거쳐야 합니다. l 먼저, 데이터를 시각화하여 쉽게 이해할 수 있는 형태로 변환해야 합니다. 차트나 그래프, 대시보드 등을 통해 데이터의 패턴과 추세를 파악할 수 있으며, 시스템의 상태를 실시간으로 모니터링할 수 있습니다. l 다음으로, 데이터를 분석하여 시스템의 문제를 식별합니다. 예를 들어, 응답 시간이 지연되는 경우, 이를 발생시키는 주요 요인을 파악하여 시스템을 개선해야 합니다. 이를 위해 데이터를 세분화하여 요소를 파악하고, 문제를 식별하는 데 도움이 되는 경향성을 찾아야 합니다. l 마지막으로 이전 데이터와 비교하고 평가에 활용합니다. Metric 데이터를 분석할 때는 이전 데이터와 비교하여 시스템의 개선 정도를 파악하는 것이 중요하고, 이를 통해 시스템의 성능 개선 여부를 판단하고, 추가적인 개선 방안을 모색할 수 있습니다. Tracing 트레이싱은 분산 시스템에서의 서비스 호출 경로와 시간을 추적하는 기술입니다. 즉, 서비스 간의 호출 관계와 시간 정보를 추적해 각 서비스의 응답 시간을 파악하고, 이를 시각화해 병목 현상을 파악할 수 있습니다. 트레이싱은 크게 세 가지 구성 요소로 이뤄져 있습니다. l Trace: Trace는 서비스 간의 호출 경로와 시간 정보를 담고 있는 데이터 레코드입니다. Trace는 Span과 Trace ID, Parent Span ID 등의 정보를 가지며, 각 Span은 서비스 내부에서의 호출 관계와 시간 정보를 담고 있습니다. l Span: 분산 추적에서 가장 기본이 되는 논리 단위로 여러 개의 span 이 모여 trace를 완성한다는 개념입니다. 각각의 Span은 작업이름, 시작 시간과 종료 시간, key value 형태의 tags 와 Logs, span contexts를 가지고 있습니다. Span contexts는 분산추적을 하기위해 Trace 구간에서 종속된 Span을 구별할 수 있는 Span id와 Trace id를 말합니다. l Collector: Collector는 Trace 정보를 수집하고 저장하는 역할로, Trace 정보를 수집하기 위한 에이전트와 수집된 Trace 정보를 저장하고 분석하기 위한 Backend로 이뤄져 있습니다. (출처: [MSA] OpenTracing, 분산추적(Distributed Tracing) 과 Span context, KSR의 저장소) 이렇게 옵저버빌리티를 구현하기 위한 로깅, 매트릭, 트레이싱 등 세 가지의 중요한 정보 소스들을 다루기 위해서는 여러가지 기술들이 조합되어야 합니다. 다음 블로그에서는 그와 같은 정보 소스들을 다루어 옵저버빌리티를 구현하기 위해서 널리 사용되는 대표적인 오픈 소스들을 알아보고 Zenius-EMS에서는 옵저버빌리티 향상을 위해서 어떤 기능들을 제공하고 있는지 살펴보겠습니다. 2023.04.19
기술이야기 Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기 기술이야기 Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기 옵저버빌리티는 "무슨 일이 일어났는가?", "왜 그런 일이 일어났는가?"와 같은 질문에 답하는 것을 목표로 합니다. 옵저버빌리티는 IT시스템 전체적인 관점에서 문제를 신속하게 식별하고 근본 원인을 분석할 수 있습니다. 최근 IT 인프라의 종류가 다양해지고, 수가 기하급수적으로 많아지고, 복잡도가 급격히 증가함에 따라 IT 인프라의 가용성을 보장하기 위해서 전통적으로 행해지던 모니터링의 범주를 넘어서는 옵저버빌리티라는 개념이 등장했습니다. 모니터링과 옵저버빌리티라는 두 용어들은 때로는 비슷한 개념으로 서로 바꿔서 사용되기도 하지만, 시스템 관리에 대한 다른 접근 방식을 나타냅니다. 이번 블로그에서는 모니터링과 옵저빌리티의 차이점을 알아보겠습니다. Monitoring이란? 모니터링은 IT 시스템에서 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 데이터를 수집하고 분석해 성능과 동작을 파악하는 것입니다. 모니터링의 목표는 시스템에 문제가 있는 것으로 추정되는 이상한 동작이나 조건을 감지하고 경고하는 것입니다. 모니터링은 종종 문제를 나타낼 수 있는 특정 메트릭이나 이벤트에 대한 알람 설정을 포함합니다. 이 접근 방식은 일반적으로 예측 가능한 개별 시스템에 사용합니다. 전통적인 모니터링 방법은 일정한 간격으로 수집되는 사전 정의된 메트릭이나 로그에 의존합니다. 예를 들어, 서버의 CPU 사용량을 1분마다 확인하고 사용량이 특정 임계값을 초과하면 알람을 보낼 수 있습니다. 이러한 방식은 특정 유형의 문제를 감지하는 데 효과적이지만, IT 시스템 동작을 전체적으로 파악하거나 근본 원인 분석에 대한 심층적인 인사이트는 제한적일 수 있습니다. Observability란? 옵저버빌리티는 IT 시스템 관리에 대한 새로운 접근 방식으로, 시스템의 내부 동작을 이해하는 것에 중점을 둡니다. 옵저버빌리티의 목표는 시스템의 동작을 깊이 이해하고 발생 가능한 모든 문제의 근본 원인을 파악하는 것입니다. 옵저버빌리티는 메트릭, 추적, 로그 등을 실시간으로 수집하고 분석하는 것을 포함합니다. 참고로 메트릭은 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 시스템 성능과 관련된 정량적 정보를, 추적은 요청의 호출 순서 및 응답 시간과 같은 시스템 동작에 대한 정보를, 로그는 사용자 작업 및 오류를 포함해 시스템 활동을 제공합니다. 옵저버빌리티가 필요한 이유 옵저버빌리티는 복잡하고 동적인 시스템에서는 문제를 빠르게 찾고 해결하기 위해 시스템의 동작과 성능을 측정하고 분석할 필요가 있습니다. 옵저버빌리티를 통해 다음과 같은 이점을 얻을 수 있습니다. 옵저버빌리티가 필요한 이유 1. 문제 해결 속도 향상: 옵저버빌리티를 사용하면 복잡한 시스템에서 발생하는 문제를 더욱 빠르게 파악할 수 있습니다. 이를 통해 시스템 장애나 성능 저하와 같은 문제를 빠르게 해결할 수 있습니다. 2. 전체 시스템 이해도 증가: 옵저버빌리티를 사용하면 전체 시스템의 내부 동작을 쉽게 이해할 수 있습니다. 이는 문제를 예방하거나 빠르게 대처할 수 있도록 도와줍니다. 3. 대규모 시스템 관리 가능: 대규모 분산 시스템에서는 옵저버빌리티가 필수적입니다. 이를 통해 수많은 서버, 네트워크, 애플리케이션 등에서 발생하는 다양한 데이터를 수집하고 분석할 수 있습니다. 4. 문제 예방 및 최적화: 옵저버빌리티를 사용하면 시스템의 성능을 지속적으로 모니터링하고 문제를 예방할 수 있습니다. 또한 시스템의 최적화를 위해 데이터를 분석하고 개선할 수 있습니다. 따라서, 옵저버빌리티는 복잡한, 여러 개의 세분화된 시스템으로 구성된 전체 시스템에서 필수적인 도구로, 시스템의 성능 개선과 장애 대응 등 다양한 측면에서 가치를 제공합니다. Monitoring vs Observability 모니터링과 달리, 옵저버빌리티는 사전에 정의된 메트릭과 알람에 의존하는 대신, 시스템 동작의 더욱 전체적인 관점을 제공합니다. 옵저버빌리티는 여러 소스에서 수집한 데이터를 같이 분석함으로써 쉽게 찾을 수 없는 어떤 패턴과 상관관계를 발견하는 데 도움을 줄 수 있습니다. 이 접근 방식은 예측할 수 없는 동작을 가진 복잡한 시스템에서 특히 유용합니다. 모니터링과 옵저버빌리티의 또 다른 중요한 차이점은 사람의 개입 수준입니다. 모니터링은 특정 이벤트 또는 조건을 감지하고 해당 이벤트 또는 조건이 발생할 때 경고를 트리거하도록 설계되므로 모니터링을 설정하고 구성하는데 사람의 개입이 필요할 수 있지만 일단 도구가 셋업되면 사람의 개입 없이 자동으로 작동하는 편입니다. 반면에, 옵저버빌리티는 데이터를 해석하고 결정을 내리고 조치를 취하는데 IT 운영자의 전문 지식을 사용해 프로세스에 관여합니다. 이러한 접근 방식은 시간이 더 많이 소요될 수 있지만, 문제의 근본 원인에 대한 더 많은 인사이트를 제공할 수도 있습니다. 올바른 어프로치 선택하기 모니터링과 옵저버빌리티는 각각 장단점이 있으며, 시스템의 특정 요구사항에 따라 어떤 접근 방식을 선택할지 달라져야 합니다. 비교적 상황 파악이 어렵지 않은 간단한 시스템의 경우, 전통적인 모니터링 도구로 충분할 수 있습니다. 그러나 복잡하고 시스템이 분산된 경우, 시스템 동작을 완전히 이해하기 위해 옵저버빌리티가 필요할 수 있습니다. 결국, 효과적인 시스템 관리의 핵심은 문제를 빠르게 감지하고 해결하기 위한 적절한 도구와 프로세스를 갖추는 것입니다. 모니터링 또는 옵저버빌리티를 선택하든, 시스템과 조직의 요구에 부합하는지 정기적으로 검토하고 개선하는 것이 중요합니다. 적절한 도구와 프로세스에 투자함으로써, 시스템의 신뢰성과 성능을 개선하고 비용이 많이 드는 다운타임과 서비스 중단을 피할 수 있습니다. Zenius EMS 브레인즈컴퍼니는 20년 이상 축적된 노하우를 바탕으로 레거시 환경은 물론 최근 더욱 복잡해지고 있는 클라우드 네이티브 시스템까지 모니터링과 옵저버빌리티 모두를 제공함으로써 고객이 원하는 방식으로 사용이 가능합니다. Zenius EMS는 SMS, NMS, APM 등 각 인프라별 모니터링을 통합해 시스템을 더욱 안정성 있게 관리하고 자동화된 장애대응 환경을 제공하며 객관적인 데이터 기반으로 리포팅이 가능한 지능형 IT 성능 모니터링입니다. 또한 쿠버네티스, 오픈 스택을 지원하는 클라우드 환경을 모니터링합니다. 국내 공공분야 관제 SW 1위, 제니우스의 상관관계 분석, 인공지능을 활용한 성능예측 등 옵저버빌리티 기술을 통해 다양한 시스템 레이어에서 성능, 장애, 구성에 대한 인사이트를 얻으시기 바랍니다. 2023.03.28
회사이야기 제니우스, 주요 CSP 5곳 마켓플레이스에 등록...클라우드 시장 공략 가속화 회사이야기 제니우스, 주요 CSP 5곳 마켓플레이스에 등록...클라우드 시장 공략 가속화 클라우드 환경에서 제니우스를 간편하게 이용할 수 있게 접근성 높여 브레인즈컴퍼니(099390)는 IT 인프라 통합관리 소프트웨어 ‘Zenius EMS’와 애플리케이션 관리 소프트웨어 ’Zenius APM’이 국내 주요 클라우드 서비스 제공기업(CSP) 5곳의 마켓플레이스에 모두 등록됐다고 26일 밝혔다. ‘Zenius(제니우스) EMS’는 클라우드 기반으로 서버, 네트워크, 데이터베이스 및 웹서비스(URL) 등을 단일화된 플랫폼에서 통합관리하는 소프트웨어다. ‘Zenius APM’은 WAS(Web Application Server)에서 일어나는 트랜잭션의 추적 및 장애 원인 분석 기능을 제공하는 제품이다. 도커(Docker)와 같은 컨테이너 기반의 애플리케이션 관리 및 오토 스케일링(Auto-Scaling) 자동화 기능 등 클라우드 맞춤형 서비스를 제공한다. 고객은 Zenius를 통해 백엔드부터 클라이언트 영역에 이르는 서버, 데이터베이스, 애플리케이션, 네트워크 및 웹서비스 응답시간을 통합적으로 추적 관찰할 수 있다. 또, 대시보드 등과 같은 모니터링 중앙화 도구를 통해 여러 IT 자원 간의 연관관계 및 영향 등을 분석할 수 있는 옵저버빌리티(Observability) 환경을 쉽게 구현할 수 있다. ‘Zenius EMS’와 ‘Zenius APM’은 현재 KT클라우드, 네이버클라우드, NHN클라우드, 카카오i클라우드, 가비아클라우드 총 5곳에 등록을 완료한 상태다. 고객은 각 CSP 웹사이트에서 원하는 서비스를 구입해 즉시 사용할 수 있으며, 월 구독 방식으로도 이용이 가능하다. 강선근 브레인즈컴퍼니 대표는 “이번 주요 클라우드 마켓플레이스 등록을 통해, 클라우드 기반으로 웹어플리케이션을 운영하거나 온프레미스에서 클라우드로 전환하려는 고객에게 쉽고 빠르게 접근해 더 많은 고객을 유치할 것으로 기대한다”고 말했다. 2022.12.26

1