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

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

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

블로그

기술이야기

기술이야기 리눅스와 윈도우의 시스템 로그를 효과적으로 모니터링하는 법 기술이야기 리눅스와 윈도우의 시스템 로그를 효과적으로 모니터링하는 법 대부분의 운영체제(OS)와 프로그램은 시스템 상태를 기록하기 위해 다양한 로그를 생성합니다. 이 로그들은 시스템의 장애를 감지하고, 예측하며, 침입을 탐지하고, 서비스가 정상적으로 작동하는지를 확인할 수 있습니다. 그렇다면 모든 운영체제가 동일한 방식으로 로그를 남길까요? 정답은 NO!입니다. 우리가 주로 사용하는 리눅스(Linux)와 윈도우(Window) 운영체제는 로그 관리 방식이 서로 다릅니다. 리눅스는 여러 위치에 로그를 분산해 저장하는 반면, 윈도우는 이벤트 로그라는 중앙 집중화된 방식으로 관리합니다. 따라서 이번 글에서는 각 운영체제의 로그 체계가 어떻게 구성되어 있는지, 이러한 로그들이 왜 중요하고, 효과적으로 모니터링하는 방법은 무엇인지 살펴보도록 하겠습니다. 1. 리눅스 로그 종류 리눅스의 주요 로그는 /var/log 디렉토리에 저장되며, 파일 형태 또는 바이너리(이진법) 형태로 기록됩니다. 이 로그 파일들은 특정 상황을 기록하고, 장애 발생 시 필요한 정보를 제공합니다. 리눅스 로그는 크게 시스템 로그, 부팅 로그, 보안 로그로 분류하여 관리합니다. 시스템 로그는 syslog나 rsyslog에 의해 관리되며, 설정에 따라 특정 항목을 제외한 대부분의 시스템 이벤트가 기록됩니다. 시스템 로그에는 메모리 부족으로 인한 성능 저하나 애플리케이션 종료와 같은 자원 문제뿐 아니라, 네트워크 연결 오류로 인해 네트워크 인터페이스 카드(NIC)에서 발생한 문제, 프로그램이 시스템 내 잘못된 경로나 리소스에 접근하려 할 때의 오류가 포함됩니다. 문제가 발생했을 때 가장 먼저 확인하는 로그 파일로, 문제 원인 분석과 해결에 중요한 역할을 합니다. 서버에는 운영 체제(OS) 외에도 데이터베이스(DB), 웹 애플리케이션 서버(WAS) 등 다양한 애플리케이션이 실행됩니다. 이때 시스템 자원 문제는 애플리케이션 성능을 저하시킬 수 있고, 반대로 애플리케이션 오류가 시스템에 영향을 주기도 합니다. 시스템 로그는 이러한 상호작용을 파악하고 장애를 조기에 진단하는 데 필요한 데이터를 제공합니다. 부팅 로그는 서버가 시작될 때 발생하는 주요 이벤트를 기록하여 시스템이 정상적으로 초기화되었는지 확인하는 데 사용됩니다. 이 로그는 커널 업데이트나 BIOS 펌웨어 변경으로 서버를 재부팅하거나 설정이 변경될 때 유용한 자료가 됩니다. 부팅 로그는 주로 두 파일로 구성되는데요. boot.log는 각 서비스가 정상적으로 시작되었는지 기록하고, dmesg는 커널이 기록한 하드웨어 상태와 초기 설정 정보를 포함합니다. 이를 통해 서버가 정상적으로 부팅되지 않거나 서비스가 제대로 작동하지 않을 때 문제의 원인을 파악할 수 있습니다. 보안 로그는 서버에 접근한 기록과 인증 정보를 담고 있습니다. 예를 들어 telnet, SSH, FTP 등을 통해 서버에 로그인할 때마다 어떤 방식을 접속했는지 secure 로그 파일에 기록됩니다. 보안 로그는 특히 해킹 시도나 비정상적인 접근이 발생했을 때 중요한 자료가 되며, 반복적인 로그인 실패와 같은 의심스러운 활동을 추적하는 데 사용됩니다. 시스템 로그와 보안 로그는 로그 레벨에 따라 로깅의 내용이 달라집니다. 로그 레벨이 높아지면 더 많은 정보가 기록되지만, 그만큼 불필요한 내용까지 출력되기 때문에 상황에 맞게 조절해야 합니다. 특히 ERR 등급 이하의 로그는 시스템이나 프로그램의 정상 작동에 영향을 줄 수 있는 항목이기 때문에, 이러한 이벤트가 발생하면 빠르게 대응하는 것이 필요합니다. 2. 윈도우 로그 종류 윈도우 로그는 이벤트 로그 형식으로 중앙 집중화되어 관리됩니다. 시스템 로그가 한 곳에서 관리되기 때문에 문제가 발생했을 때 접근이 용이합니다. 이벤트 로그는 [시작] → [제어] → [관리 도구] → [이벤트 뷰어] 또는 eventvwr 명령어로 쉽게 확인할 수 있습니다. 윈도우의 이벤트 로그는 시스템, 보안, 애플리케이션, 설치 이렇게 네 가지 카테고리로 통합되어 관리됩니다. 각 이벤트에는 고유한 ID가 부여되어 있어, 문제 발생 시 검색 기능을 통해 빠르게 조회할 수 있습니다. 프로그램이 충돌하여 종료되거나 하드웨어 장애 같은 시스템 문제가 발생하면 이벤트 로그에 오류로 기록되며, 이러한 오류 이벤트가 발생하면 신속한 대응이 필요합니다. 3. 효율적으로 시스템 로그 모니터링하는 법 리눅스와 윈도우가 서로 다른 방식으로 시스템 로그를 관리함에 따라, 각각의 로그 시스템의 상태를 실시간으로 파악하고 문제 발생 시 신속하게 대응할 수 있어야 합니다. 하지만 서버의 개수가 많아질수록 이러한 로그들을 24시간 내내 모니터링 하기란 쉽지 않습니다. 특히 예상치 못한 상황에서 빠르게 대응하려면 효율적인 모니터링 솔루션이 필수입니다. 로그 모니터링이 가능한 Zenius SMS은 시스템 로그의 잠재적인 문제를 사전에 감지하고, 문제가 발생했을 때 즉각적인 알림을 통해 서비스가 안정적으로 운영될 수 있도록 지원합니다. 모니터링이 필요한 로그 파일 경로와 특정 장애 문자열을 설정하면, 커널로그뿐만 아니라 운영 중인 다양한 서비스 로그까지 모니터링할 수 있습니다. 다음 내용을 통해 좀 더 자세한 기능을 살펴보겠습니다. 3-1. 로그 감시 (일반 정규식) Zenius SMS는 기본적으로 일반 정규식을 사용하여 특정 장애 문자열이 포함된 로그 항목을 간단히 감지할 수 있습니다. 예를 들어 'error'와 같은 특정 단어를 설정해두면, 해당 단어가 포함된 로그가 발생할 때마다 자동으로 탐지하여 관련 이벤트로 기록됩니다. 이러한 기능은 간단한 오류 모니터링에 적합하며, 빠르게 문제 상황을 파악할 때 유용합니다. 3-2. 로그 감시 (확장 정규식) Zenius SMS는 보다 정교한 모니터링이 필요한 상황을 위해 확장 정규식 기능도 지원합니다. 특정 패턴이나 조건을 설정하여 로그 이벤트를 세밀하게 감지할 수 있습니다. 예를 들어 변수 문자열을 활용하거나 특정 컨테이너가 'running' 상태가 아닐 때만 탐지하거나, 특정 서비스 이름과 오류 메시지가 함께 포함된 경우만 감지하는 등의 설정이 가능합니다. 이러한 기능은 복잡한 시스템 환경에서 더욱 세부적인 조건을 감지하고 대응하는 데 유리합니다. 윈도우의 이벤트 로그의 중요도에 따라 서버에 직접 접속하지 않고도 실시간으로 확인할 수 있습니다. 또한 '내보내기' 기능을 통해 특정 로그 이벤트의 이력을 별도로 저장하고 관리할 수 있습니다. 3-3. 윈도우 이벤트 로그 감시 Zenius SMS는 윈도우 이벤트 로그에서 특정 내용이나 이벤트 ID를 지정하여 선택적인 모니터링이 가능합니다. 발생 횟수, 유효 기간, 구분(예:시스템), 종류(예:정보) 등의 다양한 조건과 이벤트 ID를 설정하여, 설정된 조건에 맞는 이벤트만 필터링할 수 있습니다. 이를 통해 중요한 이벤트에 집중하여 효율적으로 로그를 관리할 수 있습니다. 3-4. 로그 파일 모니터링 로그 파일은 단순히 장애 문자열을 감지하는 용도뿐만 아니라, 파일 내 특정 값을 추출해 수치 데이터로 관리할 수 있는 다양한 기능을 제공합니다. Zenius SMS 모니터링 솔루션은 이러한 로그 파일에서 추출한 데이터를 차트 형태로 시각화하여 실시간 모니터링이 가능합니다. 로그 감시 설정에서 특정 값에 변수를 지정하면, 로그 파일에서 추출한 count 값이나 현재 상태를 실시간으로 추적할 수 있습니다. 이러한 기능을 통해 서버 상태뿐 아니라, 데이터베이스(DB) 결과 값이나 웹 애플리케이션 서버(WAS) 상태 등도 한눈에 파악할 수 있습니다. 서버 환경이 점차 복잡해질수록 시스템 로그 모니터링의 중요성은 더욱 커지고 있습니다. 특히 리눅스(Linux)와 윈도우(Window) 등 운영체제에서 발생하는 로그 파일을 실시간으로 모니터링하고, 문제가 발생하면 즉각 대응할 수 있는 체계는 안정적인 서비스 운영에 필수입니다. Zenius SMS와 같은 솔루션은 정규식 기반의 로그 감지, 실시간 알림, 데이터 시각화 기능을 통해 잠재적인 문제를 신속하게 파악할 수 있도록 지원합니다. 이러한 기능을 갖춘 솔루션을 통해 서버 상태를 명확히 파악하고, 예기치 않은 상황에서도 안정적인 서비스를 운영해 보시길 바랍니다! 2024.11.05
기술이야기 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
기술이야기 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
기술이야기 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
기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(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

1