반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
스토리지 관리
예방 점검
APM Solution
애플리케이션 관리
URL 관리
브라우저 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
AI 인공지능
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
브레인즈컴퍼니 ‘2023 소프트웨어대전’ 참가
클라우드(Cloud) 관리와 AWS가 뭔가요?
이운형
2023.11.16
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[행사] 브레인즈컴퍼니 전략사업본부 ‘happy 호프데이’
오늘날 IT 인프라 운영환경은 매우 복잡해졌어요. 갑작스러운 환경 변화에 따라 신속한 대응도 필요한 시점이죠. 이러한 현상으로 많은 기업들이
온프레미스(On-premise) 환경에서 클라우드(Cloud) 환경으로 전환하는 추세
이기도 해요.
클라우드 컴퓨팅 서비스 중에는 여러 벤더가 있는데요. 대표적으론 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)가 있어요.
그중 ‘AWS’는 국내 클라우드 시장에서 3년 간 70% 내외의 시장점유율로, 1위를 차지했는데요
(*클라우드 서비스 분야 실태조사(2022), 공정거래위원회)
이처럼 높은 점유율을 가진
1) AWS의 주요 서비스를 살펴보고 2) 하이브리드 클라우드 모니터링이 필요한 이유는 무엇인지 3) AWS의 각종 서비스를 모니터링할 수 있는 제니우스(Zenius)
도 함께 소개해 드릴게요!
AWS(Amazon Web Services)란?
AWS는 ‘Amazon Web Services’의 약어로, 아마존 닷컴이 제공하는 클라우드 컴퓨팅 플랫폼 및 서비스의 집합이에요. AWS에서 제공하는 여러 가지 서비스를 이용하면, 기업 및 개인이 필요한 컴퓨팅 리소스를 유연하게 확장하고 관리할 수 있죠. AWS 주요 서비스는 다음과 같아요!
AWS 주요 서비스
▪
Amazon VPC
(Amazon Virtual Private Cloud)
격리된 네트워크 환경을 구성하게 해주는 서비스예요. AWS의 동일 계정이나, 서로 다른 계정 간에 격리된 네트워크를 연결할 수 있도록 다양한 옵션들을 제공해 줘요.
▪
Amazon EC2
(Amazon Elastic Compute Cloud)
AWS에서 가장 많이 사용되는 컴퓨팅 서비스예요. 가상 서버를 호스팅 할 때 사용하죠. 리눅스나 윈도우 환경 등 다양한 인스턴스 유형을 지원하고, 필요에 따라 성능을 조정할 수 있어요. 생성 가능한 인스턴스 타입은 리전 별 차이가 있으나, 100개~300개에 이를 정도로 방대하답니다.
▪AWS Lambda
AWS에서 제공하는 서버리스 컴퓨팅 플랫폼이에요. 여기서 ‘서버리스’란 개발자가 서버의 존재를 신경 쓸 필요가 없다는 뜻이에요. AWS에서는 서버 인프라에 대한 프로비저닝, 유지관리 등을 대신 처리해 주죠. 이처럼 개발자가 비즈니스 로직에 집중하여 코드를 실행하게 해줘요.
▪Amazon S3
AWS에서 제공하는 스토리지 서비스예요. S3는 파일시스템이 아닌 오브젝트 스토리지 서비스로, 모든 파일에 API를 통해 접근 가능해요. 무제한적인 확장성, 높은 가용성과 내구성을 제공하며 단일 파일을 최대 5TB까지 업로드할 수 있어요.
▪Amazon EBS
(Amazon Elastic Block Store)
EC2 인스턴스에 장착하여 사용할 수 있는 가상 저장 장치에요. EBS를 연결하여 파일을 저장하면, EC2 인스턴스와 관계없이 데이터를 영구적으로 보관 가능해요. 이 밖에도 AWS에서 제공하는 서비스는 매우 방대한대요. 아래 URL로 접속 시, 필요한 서비스 목록 확인이 가능하답니다!
?
더 많은 AWS 서비스가 궁금하다면?
온프레미스와 AWS의 차이
온프레미스 방식은, 클라우드 컴퓨팅 서비스가 나오기 전까지 기업에서 전통적으로 사용한 ‘일반적인 인프라 구축 방식’이에요. 온프레미스 환경에서 서버를 운영하면, 호스팅 서비스를 이용하거나 서버를 직접 구매 또는 임대하죠. 그다음 데이터 센터(IDC, Internet Data Center) 또는 기업 전산실에 설치하여 운영해요.
하지만 물리적인 서버를 직접 설치할 경우, 많은 시간과 비용이 소모되어 이를 위한 운영 공간과 인력이 필요할 수 있어요.
예시를 들어 볼게요. 대형 콘서트 예매, 대학교 수강신청, 입시 원서 접수 등 단기간에 트래픽이 급증했다가 감소되는 경우를 생각해 볼까요? 이때 ‘온프레미스 방식’으로 시스템을 구축한다면, 매우 많은 비용 낭비가 발생하게 될 거예요.
반면 AWS의 경우는 어떨까요? 인터넷이 연결된 어디에서든 쉽게 인프라를 구축하고, 사용한 만큼 비용을 지불할 수 있어요. 큰 이벤트를 처리한 후 생성된 리소스를 간편하게 삭제할 수 있죠. 이처럼 온프레미스 방식과 대비한다면, 남는 자원에 대한 비용 고민이 없어지겠죠?
하이브리드 클라우드 모니터링이 필요한 이유
이처럼 AWS는 매우 유연하고 확장성 있는 클라우드 서비스예요. 하지만 모든 서비스를 AWS를 이용해서 서비스하는 것은 한계가 있는데요. 이유는 다음과 같아요.
▪보안 및 규정 준수
민감한 데이터나 규정 준수가 필요한 업무의 경우, 사설 클라우드나 온프레미스 환경의 자체 데이터 센터를 통해 운영하려는 경향이 있어요.
▪비용 효율
AWS는 사용한 만큼 비용을 지불하기 때문에, 예측할 수 없는 트래픽 증가 등에 대응하기에 좋아요. 하지만 서비스에 따라 온프레미스 환경에서 운영하는 것이 비용 측면에서 더 효율적인 경우가 있죠.
이처럼 많은 기업이 AWS를 이용한 클라우드 서비스로 전환하는 추세지만, 당분간 온프레미스 방식과 결합한 하이브리드 클라우드 운영환경이 많은 편이에요.
그렇다면 이러한 하이브리드 클라우드 운영 환경을 모니터링할 수 있는 방법이 없을까요? 바로
‘제니우스’를 활용한다면
가능해요!
제니우스를 이용한 하이브리드 클라우드 모니터링 구성도
제니우스 하이브리드 클라우드 모니터링 프로세스를 간략히 소개할게요!
우선
클라우드 환경
단계에서는 AWS 서비스를 이용하여 구축된 클라우드 환경 정보를 RestAPI 방식으로 수집해요.
CMS Manager
는 AWS 클라우드 환경에서 수집한 정보를 취합 후 스토리지에 저장해 주죠.
EMS Manager
는 온프레미스 환경에서 수집한 정보를 취합 후 스토리지에 저장해 줘요.
Web UI
에서는 스토리지에 저장된 데이터를 이용하여, 사용자에게 모니터링 정보를 제공한답니다!
제니우스에서 AWS 모니터링하기
제니우스를 이용한 ‘하이브리드 클라우드 모니터링 구성’을 좀 더 자세히 살펴볼까요?
▪CMS > 모니터링 > 요약 :
위 그림은
AWS 통합 요약
페이지인데요. EC2, RDS, VPC 등 과금 현황까지 통합 모니터링할 수 있어요.
▪EMS > 토폴로지 > 클라우드 맵 :
리전 별 자동 구성형 클라우드 맵 페이지에서는, AWS 리전 별 이용하는 서비스와 연관관계를 클라우드 맵이 자동으로 구성해 줘요.
▪
CMS > 클라우드서비스 > EC2 > 주요 성능 지표 :
주요 성능지표 모니터링
페이지에서는 AWS 콘솔에 접속하지 않고, AWS 주요 성능 지표에 대한 모니터링 추이를 확인할 수 있어요.
▪EMS > 오버뷰 :
오버뷰를 통한 온프레미스 + AWS 통합 모니터링
페이지에서는, AWS 모니터링 항목과 온프레미스 환경 모니터링 항목의 통합 현황판을 확인할 수 있어요.
이처럼 AWS와 온프레미스 환경은 물론, 더 다양한 환경의 인프라 모니터링을 위해 제니우스를 사용을 해보는 건 어떨까요?
#클라우드
#AWS
#Cloud
#브레인즈컴퍼니
#클라우드컴퓨팅
#제니우스
#AWS클라우드
#하이브리드클라우드
이운형
Technical Consulting팀
Technical Consulting팀에서 제품구축과 유지보수 업무를 수행하고 있습니다.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
[브레인즈 소식] 브레인즈컴퍼니, ‘REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법’ 특허 취득
[브레인즈 소식] 브레인즈컴퍼니, ‘REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법’ 특허 취득
지난 6월에는 브레인즈컴퍼니가 '원격 서비스 응답 블로킹 대기 상태의 트랜잭션 제어 시스템 및 방법' 특허를 획득한 사실을 알려드렸습니다. 이번 7월 31일 'REST API 클라이언트 개발을 위한 가상 REST API 서비스 자동 생성 서버 및 방법' 특허도 취득했어요. 이번에 출원한 특허의 핵심은 AWS나 GCP와 같은 클라우드 서비스를 활용하는 개발 과정에서 가상 REST API 서비스를 자동으로 생성하는 소스 자동 제너레이션 기술입니다. 클라우드 환경을 이용한 개발 과정에서는 주로 REST API(Application Program Interface)를 주로 사용하는데, 이는 웹의 컴퓨터 시스템 간에 표준을 제공하여 시스템이 서로 쉽게 통신할 수 있도록 하는 아키텍처의 하나로, 현재는 공기업 및 사기업의 대부분이 API 서비스를 제공하고 있어, 웹 서비스의 표준 기술로 자리 잡고 있습니다. 클라이언트 개발자들은 개발 단계에서 REST API 서비스를 통해 데이터를 수시로 요청하고 테스트하는 과정을 필수적으로 거치게 되는데, 이 과정에서 서버 개발자들은 각 API에 대한 소스 파일을 일일이 작성하고 추가하는 등의 업무가 가중되고 있습니다. 브레인즈컴퍼니는 이러한 과정에서 특허 기술인 소스 자동 생성 기능을 적용하여, 개발 환경을 개선시키는 데 중점을 두었습니다. 소스 코드의 작성·빌드·배포 과정에서 반복되는 단순 작업들을 절감시키고, API를 이용하는 데 소요되는 비용을 최소화하여 결과적으로는 개발 경쟁력을 확보할 수 있기 때문입니다. 이번에 취득한 특허 기술은 클라우드 서비스 모니터링 시스템인 Zenius-CMS 개발 과정에서 이미 적용되어 성공적으로 검증되었습니다. 이번 특허 기술을 통해 클라우드 환경에서의 개발 속도를 높일 수 있었고, 브레인즈 개발자들은 더욱 효율적이게 업무에 몰두할 수 있는 환경이 마련된 상태입니다. 또한, 향후 REST API를 활용하는 프로젝트가 있을 때에도 신속하고 쉽게 개발이 이루어지고 효율적인 개발과 비용 부담 없는 테스트 과정을 거쳐 기능의 안정성을 확보할 것으로 전망하고 있습니다. 그리고 궁극적으로는 신규 기능을 빠르고 안정적으로 배포하여 고객 만족도가 향상될 것으로 기대하고 있습니다.
2023.08.28
AWS Opensearch(오픈서치) Alerting plugin 활용 방법
AWS Opensearch(오픈서치) Alerting plugin 활용 방법
AWS OpenSearch(오픈서치)는 핵심 기능을 확장하기 위해 다양한 Plugin을 제공합니다. 이를 통해 운영 환경에 맞게 안정적이고 효율적인 기능을 추가할 수 있습니다. 그중에서도 Alerting Plugin 은 조건 기반 탐지와 알림 기능을 제공하며, 보안 모니터링이나 장애 대응 같은 영역에서 자주 활용됩니다. 특정 이벤트를 실시간으로 감시하고, 정의한 조건을 만족할 경우 자동으로 알림을 발생시켜 운영자의 대응 속도를 높일 수 있습니다. 이번 글을 통해서 Alerting Plugin의 주요 구성 요소와, 실제 적용 과정에서 고려해야 할 부분을 함께 살펴보겠습니다. 1. Alerting plugin이란? 보안기능의 기본은 특정 조건에 대한 탐지설정을 하고 설정한 탐지 조건에 만족하는 데이터를 찾게 되면 원하는 형태로 알림을 발생시키는 것입니다. Alerting 은 Opensearch 내에 데이터를 탐지 대상으로 하여 기본 탐지 기능을 안정적으로 제공하는 plugin 입니다. Opensearch 문서에서는 대략적으로 아래 키워드로 설명 하고 있습니다. - Monitor: 검색조건에 해당하는 쿼리를 작성하고, 실행주기를 설정합니다. 여기에서 정의된 쿼리의 실행 결과는 Trigger 의 입력 데이터로 사용됩니다. - Trigger: 입력되는 쿼리 결과를 기준으로 실제 행위를 발생시키는 조건을 정의합니다. - Alert: Trigger 에서 정의된 조건이 만족하는 경우 Alert 이라는 이벤트를 생성합니다. - Action: Alert 이 발생했을 때 수정행 할 작업을 정의합니다. - Notification: Alert 이 발생했을 때 전송되는 알림 메시지를 정의합니다. 2. 어떤 버전을 사용하면 될까? Alerting 기능은 Opensearch 1.1.0 버전부터 제공된다고 되어 있지만, 알림(Notification) 기능이 추가되는 2.0 이후 버전부터 활용성이 높아졌다고 생각되네요. 개발의 편의성이나 시각적인 결과를 원한다면 OpenSearch Dashboards에 도입되는 2.9 버전 부터가 OpenSearch Dashboards 에 도입되기 때문에 시각적인 결과확인이 가능하여 개발이나 테스트 시에 도움이 많이 될 수 있습니다. Openserach 가 설치되어 있다면 다음 방법으로 plugin 상태를 확인해 볼 수 있는데요. curl -X GET http://localhost:9200/_plugins/_alerting 결과 opensearch-alerting 2.16.0.0 opensearch-notifications 2.16.0.0 opensearch-notifications-core 2.16.0.0 실제 사용해봤던 버전은 2.10, 2.16 으로 기능상으로 큰 차이는 없었기에 적당한 버전을 선택하여 사용하면 될 것 같네요. 아래는 openserach-dashboard 명령어로 설치된 plugin 리스트를 확인한 결과입니다. ./opensearch-dashboards-plugin list --allow-root alertingDashboards@2.16.0.0 anomalyDetectionDashboards@2.16.0.0 assistantDashboards@2.16.0.0 customImportMapDashboards@2.16.0.0 ganttChartDashboards@2.16.0.0 indexManagementDashboards@2.16.0.0 mlCommonsDashboards@2.16.0.0 notificationsDashboards@2.16.0.0 observabilityDashboards@2.16.0.0 queryWorkbenchDashboards@2.16.0.0 reportsDashboards@2.16.0.0 searchRelevanceDashboards@2.16.0.0 securityAnalyticsDashboards@2.16.0.0 securityDashboards@2.16.0.0 아래는 Opensearch Dashboard 에서 설치된 plugin 을 메뉴로 확인상태 입니다. 이처럼 필요한 플러그인을 적절한 버전으로 설치했다면, 이제 Alerting의 핵심 기능인 Monitor 와 Trigger 설정 방법을 살펴보겠습니다. 3. Monitor 실제로 탐지를 수행하고 alert을 발생시키기 위한 trigger의 입력 값이 되는 검색조건과 실행 주기를 설정하는 부분입니다. Monitor 는 Alerting 의 출발점이자 이후 Trigger, Alert, Action 으로 이어지는 전체 탐지 프로세스의 기반이 되는 구성 요소입니다. 아래와 같이 몇 가지 검색조건을 구분하는 기능을 제공하는데, Per Query Monitor, Per Bucket Monitor에 대해서 먼저 알아보겠습니다. - Per Query Monitor 설정한 쿼리 결과의 개수를 그대로 Trigger 조건의 입력 값으로 사용하도록 처리하는 방식이기 때문에 기본적이면서 단순 조건을 처리할 때 주로 사용하는 방식입니다. 예를 들어 시스템 로그를 대상으로 특정 사용자에 대한 로그인 실패 이력을 조건으로 건다고 했을때 아래와 같은 쿼리가 가능합니다. { "size": 0, "query": { "bool": { "must": [ { "bool": { "must": [ { "match_phrase": { "userid": { "query": "root", "slop": 0 } } }, { "match_phrase": { "action": { "query": "failed_password", "slop": 0 } } } ] } } ], "filter": [ { "bool": { "must": [ { "range": { "@timestamp": { "from": "now-30m", "to": "now" } } } ] } } 쿼리에 만족하는 조건이 있다면 아래와 같은 결과가 나타납니다. { "_shards": { "total": 9, "failed": 0, "successful": 9, "skipped": 0 }, "hits": { "hits": [], "total": { "value": 4, "relation": "eq" }, "max_score": null }, Per Query Monitor 은 위와 같은 결과가 나왔을 경우 trigger 조건에 만족한다면 단일 alert 이 한 개 발생하는 방식입니다. - Per Bucket Monitor 이 방식은 쿼리에 Aggregation 를 설정하여 Bucket 단위 별로 trigger 조건을 검사하고 alert 을 발생시키는 방식입니다. Per Query Monitor 과 동일한 조건의 쿼리에 아래와 같은 Aggregation query 가 추가되는 형태입니다. "aggregations": { "by_agg": { "terms": { "field": "host.keyword", "order": [ { "_count": "desc" }, { "_key": "asc" } ] } } } host 라는 필드로 group by 와 같은 집계를 하면 결과는 host 단위의 buckets 가 생성되고 각각의 bucket 에 개수가 포함되게 됩니다. 각각의 bucket 에 포함된 개수가 trigger 조건에 만족한다면 만족하는 만큼 alert 이 발생하게 되는데 이 부분이 Per Query Monitor 방식과 차이점이 되겠습니다. { ... "aggregations": { "by_agg": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "doc_count": 2, "key": "testhostname1" }, { "doc_count": 2, "key": "testhostname2" } ] } } } - Monitor API curl -X POST "https://localhost:9200/_plugins/_alerting/monitors/_search?pretty=true" -k -H "Content-Type: application/json" -d '{}' 아래와 같이 등록한 monitor 정보를 JSON 포맷으로 조회할 수 있습니다. Monitor 관련 몇 가지 API를 소개합니다. Create, Update 등 기본적인 기능 외에 설정한 Monitor 를 실행 시킬 수 있는 Monitor RUN API 도 제공 됩니다. 필요에 따라서 자신의 시스템에서 직접 실행시키는 로직을 구현해 볼 수 도 있을 것 같구요. 설정 내용을 미리 시뮬레이션 해서 결과를 테스트 해볼 수 있는 기능으로 활용해도 좋을 것 같습니다. Monitor Create POST _plugins/_alerting/monitors Monitor Update PUT _plugins/_alerting/monitors/<monitor_id> Monitor Delete DELETE _plugins/_alerting/monitors/<monitor_id> Monitor Run POST _plugins/_alerting/monitors/<monitor_id>/_execute 4. Trigger Trigger 는 Monitor 에 설정한 쿼리의 결과를 입력으로 Alert 을 발생 시킬 조건을 설정하는 과정입니다. 이 부분도 Per Query Monitor 과 Per Bucket Monitor 방식이 차이가 있습니다. Per Query Monitor는 쿼리의 결과가 단순 개수(hits)이기 때문에 개수 연상에 대한 true, false 로 결과를 얻습니다. 물론 결과가 true 인 경우에만 alert 이 발생하는 조건이 되겠죠. Per Bucket Monitor 방식은 개수 조건을 설정 하는 건 동일하지만 Aggregation 문에 정의된 key 명을 parent_bucket_path 에 맞춰 줘야 된다는게 다른 점입니다. Trigger condition 에서 설정한 조건이 만족한다면 bucket 단위로 결과 구해지게 됩니다. [ { "doc_count": 3, "key": "testhostname1" }, { "doc_count": 4, "key": "testhostname2" } ] 만약 실제로 이런 결과가 나왔다면 alert testhostname1, testhostname2 두 개의 alert 이 발생하게 됩니다. 5. Alert Monitor -> Trigger 조건이 만족하였다면 Alert 이라는 단위의 알림이 생성됩니다. Alert 은 Action 과 연계되었을 때 외부로 통보 등의 전달 기능을 수행할 수가 있고, 이런 연계 설정이 없다면 단순히 alert 이라는 데이터가 하나 신규로 생성되었다고 보면 됩니다. Opensearch Dashboard Alerts 메뉴에서는 아래와 같이 발생된 Alert 이 조회 됩니다. Alert 단위 별로 구체적으로 확인할 수 있는 방법은 없는 것 같고, Opensearch Dashboard 에서는 조회할 수 있는 정보는 이 정도가 전부인 것 같습니다. Alert은 발생 시점부터 Completed 될 때까지 아래 상태로 관리가 됩니다. - Active 조건이 만족하여 발생된 상태이고 아무런 처리가 되지 않은 상태라고도 합니다. - Acknowledged 관리자가 확인했다 정도의 의미를 부여할 수 있을 것 같은데요. 이 상태로 변경된 후부터 조건이 만족 했는데도 Alert 이 발생하지 않는 것처럼 보여질 수도 있습니다. 하지만 특정 시점이 되면 다시 Alert 이 발생하게 되는데 좀 애매한 운영 상태라고 보여집니다. 정확한 것은 이 상태 이후 실제 Alert을 발생시키는 조건이 해제 되었다가 다시 조건이 만족하게 된다면 Alert 이 발생하게 됩니다. Alert이 계속 발생되는 조건이라면 계속 Acknowledged 상태가 유지 되는 거라서 추가 Alert 이 발생되지 않는다는 오해에 소지가 있을 수도 있겠네요. 1번과 같이 Acknowledged 상태라도 조건이 만족하고 있는 상태라면 기존 상태가 유지가 되고, 2번 처럼 조건이 불만족 상태가 되면 상태는 Completed 상태가 되어 Alert 은 종료 처리됩니다. 3번처럼 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다. - Completed Alert이 발생하는 조건 즉 Trigger 조건이 만족하지 않는 경우 기존 발생된 Alert 상태는 Completed 상태로 전환됩니다. 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다. 개발 중에 이슈 사항 중 하나였다면 Completed 상태를 관리자가 임의로 변경할 수 없다는 것입니다. Alerting 시스템의 철학인지는 모르겠지만 상태 변경은 Acknowledged 만 가능하다는 것입니다. 즉 Completed는 Alerting 자체에서 조건의 만족 상태에 따라 변경해 주는 상태이고, 개발중인 시스템에서 Completed 상태를 별도로 운영하기 위해서는 자체적인 상태 처리 로직이 추가 되어야 됩니다. -Alert API curl -XGET "https://localhost:9200/_plugins/_alerting/monitors/alerts?pretty=true" -k 아래와 같이 발생한 Alert 리스트를 JSON 포맷으로 조회할 수 있습니다. 6. Action Alert 이 발생했을 때 관리자에게 통보하는 방식과 통보 메시지 등을 설정하는 기능입니다. Channel 이라는 설정을 하게 되는데 쉽게 말하면 통보 수단을 의미하는 거고 기본적으로 아래와 같은 통보 수단을 제공합니다. 기존에 자체적인 alert 처리 서비스가 있어서 이 서비스를 활용하고자 Custom webhook 방식을 사용했습니다. Action > Notification 에서 정의하는 Message 를 JSON 형식으로 우리의 alert 처리 서비스에 전달하는게 목적입니다. 전체적인 Action > Notification 설정은 아래와 같습니다. - Message 통보 수단을 통해 전달된 메시지 내용을 정의합니다. { "alertmessage": { "monitor": "{{ctx.monitor.name}}", "monitorid": "{{ctx.monitor._id}}", "trigger": "{{ctx.trigger.name}}", "severity": "{{ctx.trigger.severity}}", "period_start": "{{ctx.periodStart}}", "period_end": "{{ctx.periodEnd}}", "results": {{#toJson}}ctx.results{{/toJson}}, "deduped_alerts": [ {{#ctx.dedupedAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.dedupedAlerts}} ], "new_alerts": [ {{#ctx.newAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.newAlerts}} ], "completed_alerts": [ {{#ctx.completedAlerts}} { "id": "{{id}}", "bucket_keys": "{{bucket_keys}}" } {{/ctx.completedAlerts}} ] } } Message 에 사용할 수 있도록 제공되는 대략적인 정보 입니다. - ctx.monitor : Moniter 설정 정보 - ctx.trigger : Trigger 설정 정보 - ctx.newAlerts : 신규 생성 Alert 정보 - ctx.completedAlert : 완료된 Alert 정보 - ctx.dedupedAlerts : 기존 생성된 Alert 중복 생성 정보 ctx 내용 전체를 확인해 보면 활용할 수 있는 내용이 그렇게 많지는 않습니다. 목표로 했던 기능 중에 Alert 서비스에 발생된 Alert 의 실제 쿼리 범위 시간을 구해야 되는 했던 기능이 있었습니다. 아래 두 가지 값이 제공되어 값을 확인해 보니 조건 쿼리가 실행되는 interval 시간으로 확인 되어 실제로 사용하지는 못했습니다. ctx.periodStart ctx.periodEnd 대신 ctx.periodEnd 시간에 실제 쿼리 내에 정의된 time range 값을 계산하여 실제 쿼리 범위 시간을 구하는 방식으로 처리 했습니다. - Perform action Alert 단위에 대한 Action 처리 방식은 아래와 같은 종류도 설정할 수 있습니다. - Per execution: 조건을 만족하는 alert 이 여러 개여도 action 은 한번만 처리. - Per alert: 조건을 만족하는 alert 이 여러 개면 각각마다 action 을 수행함. 우리는 각각의 Alert 마다 action 처리가 필요하기 때문에 Per alert 방식을 사용했고, Actionable alerts 아래와 같이 설정 했습니다. - New: 신규 Alert 에 대한 Action 처리를 위해서 반드시 필요한 부분이고 - De-duplicated: 이미 생성된 Alert 에 대해 동일한 조건이 만족되었을 때 Action 을 처리할 것인가를 설정하는 내용입니다. 기존 생성된 Alert 의 상태 정보를 업데이트 시켜 주기 위해서는 이 설정을 추가해줘야 됩니다. - Completed: 발생된 Alert 의 조건이 만족하지 않게 된 경우 Action 처리 여부를 설정합니다. 기존 발생된 Alert을 자동으로 완료 처리해주려면 이 설정을 추가해줘야 됩니다. Action 에서 설정된 내용 데로 통보 수단을 통해 충실히 전달된다면, 실제 서비스 로직 에서 제대로 처리해줘야만 됩니다. - Notication message 처리 Alert 을 처리하는 서비스 로직 에서는 아래 같이 Alerting Notication 으로 message 를 전달 받게 됩니다. 자체 서비스 로직 에서는 이 정보를 분석하여 발생된 Alert 를 관리하는 기능을 구현할 수 있습니다. 어떤 감시설정으로 발생된 Alert 인지를 식별할 수 있는 정보입니다. 서비스 로직에서 감시설정, Alert 을 식별하여 처리하는데 필요한 정보 입니다. priod_start, period_end : 감시설정의 조건 쿼리가 실행되는 interval 시간 입니다. 만약 쿼리문에 time range 값이 아래처럼 정의 되어 있고 alert 이 발생된 시점에 time range 를 구하려 한다면 위의 시간 값 만으로는 어렵습니다. "range": { "@timestamp": { "from": "now-30m", "to": "now", "include_lower": true, "include_upper": true, "boost": 1 } } } } Period_start 에 30m을 더하거나 period_end 에서 30m 빼는 방식으로 실제 time range 값을 구할 수 있었습니다. results[0].aggregations.by_agg.buckets 이 값에서는 검색조건 결과에 해당하는 buckets 결과 값을 구체적으로 조회할 수 있습니다. New_alerts : 신규 생성 alert deduped_alerts : 기존 발생된 alert completed_alerts : 완료된 alert 위와 이 서비스 로직에서 alert 의 상태를 구분하여 처리할 수 있습니다. 7. 마치며 이번 글에서는 Alerting Plugin 기능을 큰 카테고리별로 나누어, 주로 OpenSearch Dashboard 를 기반으로 설명했습니다. Alerting Plugin 은 기본적인 API 를 제공하므로, 위에서 다룬 모든 기능은 REST API 를 통해서도 동일하게 활용할 수 있습니다. 따라서 Alerting Plugin 을 탐지 엔진으로 잘 활용한다면, 운영 환경에서 안정적이고 효율적인 탐지 체계를 구축할 수 있습니다.
2025.09.15
스토리지 모니터링 솔루션, Zenius STMS의 주요기능과 특장점
스토리지 모니터링 솔루션, Zenius STMS의 주요기능과 특장점
최근 기업의 IT 인프라는 데이터의 폭발적 증가와 함께 그 복잡성도 빠르게 심화되고 있습니다. 특히 AI와 빅데이터 분석, GPU 기반 워크로드 확산은 스토리지를 단순한 저장 장치가 아니라 서비스 연속성과 업무 안정성을 좌우하는 핵심 인프라로 변화시키고 있습니다. 최근 스토리지 환경에서는 NVMe-oF와 같은 초고속 인터페이스, SDS(Software Defined Storage), 오브젝트 스토리지, GPU 최적화 스토리지 등 새로운 아키텍처가 빠르게 등장하고 있습니다. 하지만 이러한 다양한 스토리지가 혼재된 환경에서는 제조사별 관리 도구와 포인트가 제각각이어서, 운영자가 여러 개별 콘솔을 오가며 상태를 확인해야 하는 비효율성이 발생합니다. 이는 관리 복잡도를 높일 뿐만 아니라 장애 대응 지연이나 용량 부족 문제로 이어져 서비스 중단이라는 위험까지 초래할 수 있습니다. 따라서 오늘날 스토리지 관제의 핵심은 단순히 얼마나 많은 데이터를 저장할 수 있는가가 아니라, 얼마나 안정적으로 전체 스토리지를 통합 관리하고 장애를 사전에 예측·대응할 수 있는가로 바뀌고 있습니다. 이러한 변화의 흐름 속에서 브레인즈컴퍼니는 Zenius STMS를 통해 다양한 벤더의 스토리지 장비를 통합적으로 관리할 수 있는 환경을 제공하고 있습니다. Zenius STMS는 스토리지의 성능을 실시간으로 모니터링하고, 장애를 신속하게 감지·통보하여 안정적인 인프라 운영을 지원하며 널리 활용되고 있습니다. 스토리지 모니터링 솔루션, Zenius STMS의 4가지 주요기능 Zenius STMS는 단순히 데이터를 수집·표시하는 수준을 넘어, 운영자가 직면한 문제를 실제로 해결할 수 있도록 설계된 솔루션입니다. 이기종 스토리지의 성능·용량·장애·구성 정보를 한곳에서 관리할 수 있으며, 직관적인 UI와 자동화된 관제 체계를 통해 운영 복잡도를 획기적으로 줄여줍니다. 지금부터 Zenius STMS가 제공하는 주요 기능과 특장점을 네 가지 측면에서 구체적으로 살펴보겠습니다. [1] 직관적인 이기종 스토리지 통합 모니터링 기능 기업의 스토리지 환경은 Hitachi, Dell EMC, HPE 등 다양한 벤더 장비가 뒤섞여 운영되는 경우가 많습니다. 이때 장비마다 제공하는 관리 콘솔과 지표 체계가 다르기 때문에, 운영자는 동일한 문제를 확인하기 위해 여러 화면을 오가야 하는 비효율에 직면합니다. Zenius STMS는 REST API를 통해 이기종 장비 데이터를 표준화하여 수집하고, 이를 단일 플랫폼에서 통합 제공합니다. 운영자는 한 화면에서 전체 스토리지 현황을 직관적으로 파악할 수 있으며, 보유 현황과 사용률 상위 자원, 점검 필요 여부 등 핵심 정보를 종합적으로 확인할 수 있습니다. 또한 특정 장비의 성능·용량·장애 내역까지 드릴다운하여 살펴볼 수 있어, 복잡한 멀티 벤더 환경에서도 관리의 일관성과 효율성을 확보할 수 있습니다. 시각화 기반 UI 역시 강점입니다. 도형과 색상, 표를 활용한 모니터링 뷰는 각 스토리지의 상태를 명확히 구분해 보여주며, 관리자가 위험 신호를 빠르게 식별하고 우선순위를 정해 대응할 수 있도록 돕습니다. 이는 단순히 현황을 확인하는 단계를 넘어, 이상 징후를 조기에 감지하고 선제적으로 조치할 수 있는 기반을 마련해 줍니다. 또한 이러한 통합 모니터링은 단순한 편의성을 넘어 운영 조직 전체의 의사결정 속도와 품질을 끌어올립니다. 예를 들어, 주간 점검이나 용량 계획 회의에서 STMS의 요약 뷰를 근거 자료로 활용하면, 담당자 간의 정보 격차가 줄어들고 신속하게 공통된 판단을 내릴 수 있습니다. 이는 곧 장애 대응 속도를 높이고, 리스크 관리와 비용 최적화에도 직접적으로 기여합니다. [2] 성능 및 용량 관리의 정밀화 스토리지 운영에서 가장 큰 위험 요소 중 하나는 예기치 못한 용량 부족으로 인한 서비스 중단입니다. Zenius STMS는 이를 방지하기 위해 Volume, Pool, Drive 단위까지 세분화된 모니터링을 수행하며, 일·주·월 단위의 용량 추이 그래프를 제공해 장기적인 사용 패턴을 한눈에 파악할 수 있도록 합니다. 관리자는 단순히 현재 사용량을 확인하는 데 그치지 않고, 데이터 증가 추세를 근거로 증설 계획을 세우거나 자원을 재분배할 수 있어 안정적인 서비스 운영을 보장할 수 있습니다. 또한 성능 저하나 장애로 이어질 수 있는 네트워크 이상을 조기에 탐지하기 위해 포트 단위 모니터링 기능을 제공합니다. Port ID별로 Protocol, Speed, Link Status, Failover 여부 등을 실시간으로 감시하여 작은 이상 징후를 빠르게 식별할 수 있습니다. 더불어 제조사별 특화 항목까지 반영해 Dell EMC의 경우 RAID 구성, SRP, Thin Pool 사용률 등 상세 지표를 모니터링할 수 있습니다. 이러한 기능은 스토리지의 구조적 특성과 운영 상태를 동시에 분석할 수 있게 해주며, 다양한 환경에서도 정밀하고 일관된 성능 관리가 가능하도록 합니다. 결과적으로 Zenius STMS의 성능 및 용량 관리 기능은 단순한 현황 확인을 넘어, 예측 기반의 선제적 운영 관리를 가능하게 합니다. 이를 통해 기업은 리스크를 줄이고, 데이터 증가와 워크로드 변화에도 흔들림 없는 안정성을 유지할 수 있습니다. [3] 자동화된 장애 관리 및 실시간 장애 인지 스토리지 장애는 사전 예방이 가장 이상적이지만, 실제 운영 환경에서는 예기치 못한 문제가 발생할 수 있습니다. 이때 중요한 것은 얼마나 빠르게 장애를 감지하고 대응하느냐입니다. Zenius STMS는 트랩(TRAP) 연동을 통한 실시간 이벤트 감지 기능을 제공하여, 장애 발생 순간부터 즉각적으로 상황을 파악할 수 있도록 합니다. 또한 임계치 기반의 감시 정책을 세밀하게 설정할 수 있어, 특정 성능 지표가 기준치를 벗어나는 순간 자동으로 이벤트가 발생하도록 함으로써 사전 대응력을 높입니다. 알림 기능 역시 다층적으로 설계되어 있습니다. SMS, 이메일, 푸시 알림, 메신저 앱 연계 등 다양한 통보 채널을 지원하며, 1차에서 3차까지 단계별 수신자 체계를 두어 미조치 시간이 길어질수록 더 상위 관리자에게 경보가 전달됩니다. 이를 통해 조직 내 장애 대응의 책임성을 강화하고, 대응 지연으로 인한 리스크를 최소화할 수 있습니다. 또한 Zenius STMS는 이벤트 발생부터 처리 완료까지의 전 과정을 추적·기록할 수 있는 이력 관리 기능을 갖추고 있습니다. 장애 조치 내역은 Knowledge DB로 축적되어, 향후 유사한 장애가 재발했을 때 즉시 참고할 수 있는 자산으로 활용됩니다. 이는 단순한 장애 알림을 넘어, 장애 대응 프로세스를 체계화하고 재발 방지를 위한 학습 효과까지 제공하는 구조입니다. [4] 관리자의 업무효율을 고려한 구성관리 스토리지 관리 환경은 시간이 지날수록 장비와 사용자, 권한 체계가 복잡해지기 마련입니다. Zenius STMS는 이러한 현실을 반영해 관리자의 운영 부담을 줄이고, 체계적인 관리가 가능하도록 다양한 기능을 제공합니다. 우선 관리자는 스토리지 접속 정보를 등록·수정하고 수집 주기를 유연하게 설정할 수 있어, 신규 장비가 추가되거나 구성이 변경되더라도 안정적으로 연동할 수 있습니다. 이는 특히 멀티 벤더 장비가 혼재된 대규모 환경에서 운영 일관성을 유지하는 데 효과적입니다. 또한 사용자·그룹별로 모니터링 권한을 세밀하게 설정할 수 있는 기능은 보안성과 운영 효율을 동시에 보장합니다. 예를 들어 운영팀, 보안팀, 개발팀 등 각 부서의 역할에 따라 필요한 범위만 권한을 부여함으로써 불필요한 정보 접근을 제한하고, 관리 책임을 명확히 할 수 있습니다. 이는 권한 오남용 방지를 넘어, 감사 및 보안 규제 대응 측면에서도 중요한 가치를 가집니다. 확장성 역시 STMS의 큰 장점입니다. 서버, 네트워크, DBMS 등 다양한 관리 대상 솔루션과의 연동을 지원해, 단순히 스토리지 전용 도구에 머무르지 않고 전사적 IT 인프라 관제 플랫폼으로 발전할 수 있습니다. 관리자는 필요에 따라 Add-On 형태로 기능을 확장해 새로운 요구사항이나 환경 변화에 빠르게 대응할 수 있으며, 결과적으로 운영 효율성과 확장 가능성을 동시에 확보할 수 있습니다. 스토리지 모니터링 솔루션, Zenius STMS의 주요 기능 특장점 Zenius STMS는 다양한 제조사의 스토리지 장비가 혼재된 환경에서도 안정적이고 체계적인 통합 모니터링을 제공하는 고도화된 솔루션입니다. 기존처럼 벤더별 관리 콘솔에 의존하는 방식은 단편적이고 비효율적일 수밖에 없지만, STMS는 이를 하나의 플랫폼으로 집약해 운영자가 모든 스토리지의 성능, 용량, 장애 현황을 실시간으로 가시화할 수 있도록 합니다. HTML5 기반의 UI는 별도의 설치 과정 없이 웹 환경에서 즉시 접근 가능하며, 직관적인 도형·컬러·표 형식의 시각화 뷰는 방대한 데이터를 빠르고 명확하게 이해할 수 있게 지원합니다. 이는 단순한 편의성을 넘어, 운영자의 대응 속도와 의사결정 품질을 근본적으로 향상시키는 요소입니다. 더 나아가 Zenius STMS는 EMS 통합 플랫폼 아키텍처를 기반으로 서버, 네트워크, 애플리케이션, DBMS 등 다양한 관리 대상을 유기적으로 연결할 수 있습니다. Add-On 방식으로 확장 가능한 구조 덕분에 스토리지 관제에 국한되지 않고, 전사적 인프라의 성능 및 장애 데이터를 하나의 플랫폼에서 종합적으로 수집·분석할 수 있습니다. 이는 곧 단일 자원 관리에서 서비스 전체 레벨의 안정성 관리로 확장되는 관점 전환을 가능하게 하며, 조직은 장기적인 운영 안정성과 예측 가능성을 확보할 수 있습니다. 이처럼 Zenius STMS는 다양한 벤더 장비가 혼재된 복잡한 스토리지 환경에서도 운영자가 전체 자원을 일관되게 관리할 수 있도록 지원하는 통합 관리 솔루션입니다. 단일 플랫폼에서 성능·용량·장애 정보를 실시간으로 확인할 수 있어 불필요한 관리 복잡도를 줄이고, 직관적인 UI와 자동화된 기능을 통해 대응 속도를 높입니다. 또한 서버, 네트워크, DBMS와 같은 다른 인프라 관리 영역과 유연하게 연동될 수 있는 확장성을 갖추고 있어, 변화하는 IT 환경 속에서도 장기적인 운영 안정성을 확보할 수 있습니다. 공공기관, 금융, 의료, 제조 등 다양한 산업 현장에서 이미 다수의 구축 경험을 통해 검증된 만큼, Zenius STMS는 단순한 모니터링 도구를 넘어 조직 전체의 인프라 운영 수준을 한 단계 높이는 실질적인 관리 체계로 자리 잡고 있습니다. 앞으로도 데이터 증가와 아키텍처 다변화가 가속화되는 상황에서, STMS는 기업과 기관이 안정적이고 효율적인 스토리지 운영을 이어갈 수 있도록 든든한 기반이 될 것입니다.
2025.10.27
다음 슬라이드 보기
