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

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

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

블로그

최신이야기

기술이야기 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 AI의 주요기능과 특장점 기술이야기 이상 징후 탐지 솔루션, Zenius AI의 주요기능과 특장점 IT 인프라의 복잡성과 운영 환경이 점점 더 고도화됨에 따라, 시스템 장애를 사전에 탐지하고 선제적으로 대응하는 기술의 중요성이 크게 부각되고 있습니다. 기존의 장애 관리 방식은 주로 장애 발생 이후에 원인을 분석하고 복구 조치를 취하는 사후 대응(Post-Mortem Response) 중심이었습니다. 그러나 이러한 접근 방식은 서비스 다운타임 증가, 운영 비용 상승, 장애의 반복 발생과 같은 문제를 야기하며, 기업의 디지털 운영 안정성을 위협합니다. Zenius AI는 이러한 한계를 극복하기 위해 머신러닝 기반의 이상징후 탐지 및 장애 예측 기능을 제공하는 이상 징후 탐지 솔루션입니다. 대규모 IT 인프라 환경에서 수집되는 로그, 메트릭, 이벤트 데이터를 실시간으로 분석하여 정상 패턴에서 벗어나는 이상 징후를 조기에 감지하고, 잠재적인 장애를 사전에 예측할 수 있도록 지원하는 Zenius AI의 주요기능과 특장점을 자세히 알아보겠습니다. 이상 징후 탐지 솔루션, Zenius AI의 주요 기능 Zenius AI는 IT 운영 환경에서 이상징후를 실시간으로 감지하고 대응할 수 있도록 설계된 AI 기반의 모니터링 솔루션입니다. 이 솔루션은 데이터 수집 및 관리, AI 모델 학습 및 예측, 이상징후 감지 및 대응, 대시보드 시각화 및 운영관리의 네 가지 핵심 기능을 제공합니다. 1) 데이터 수집 및 관리 Zenius AI는 Kafka 기반의 고성능 메시징 시스템과 OpenSearch 기반의 스토리지 및 검색 엔진을 통해, 대규모 로그 및 메트릭 데이터를 실시간으로 안정적이고 유실 없이 수집할 수 있도록 설계되었습니다. 이를 통해 시스템 전반에서 발생하는 다양한 이벤트 및 상태 정보를 정밀하게 추적하고, 이상징후 탐지에 최적화된 정제된 학습용 데이터셋을 구축할 수 있습니다. 특히 Zenius EMS(Enterprise Monitoring System)와의 직접적인 연동 기능을 제공함으로써, 서버, 네트워크, 애플리케이션 등 다양한 IT 인프라에서 생성되는 실시간 성능 데이터를 효과적으로 수집할 수 있습니다. 이를 통해 기존 IT 운영 환경과 유기적으로 연결된 데이터 수집·분석 체계를 구현할 수 있으며, 수집된 데이터를 기반으로 한 AI 기반 이상징후 탐지 및 선제적 대응 체계 구축이 가능해집니다. 또한, 데이터 수집 단계에서부터 AI 학습 및 예측 모델 구축에 이르기까지 전체 파이프라인이 긴밀하게 통합되어 있어, 운영 효율성과 데이터 신뢰성을 동시에 확보할 수 있는 것이 Zenius AI의 큰 강점입니다. 2) AI 모델 학습 및 예측 Zenius AI는 시계열 데이터 기반의 정밀한 이상징후 탐지를 위해 Amazon Web Services(AWS)에서 제공하는 DeepAR 시계열 예측 모델을 활용합니다. DeepAR은 다수의 시계열 데이터를 동시에 처리하고, 시간 축을 따라 변화하는 패턴을 학습하여 정상 범위를 벗어나는 이상 징후를 사전에 감지할 수 있도록 지원합니다. 이를 통해 단순 임계값 기반 감지를 넘어선 지능형 예측 분석이 가능해집니다. 또한, Zenius AI는 AutoGluon 기반의 AutoML 기능을 통합하여 모델 개발 전반을 자동화합니다. 하이퍼파라미터 최적화, 특성 선택, 다양한 알고리즘 기반 학습 등을 자동으로 수행하고, 정확도 기준에 따라 최적의 모델을 자동으로 선택함으로써 분석 정확도와 효율성을 동시에 향상시킵니다. 데이터의 특성과 계절성이 반영된 학습 모델은, 각 서비스에 맞는 맞춤형 예측 알고리즘으로 적용되며, 모델 자동 배포, 버전 관리, 스케줄 기반 재학습 기능을 통해 지속적으로 개선되고 고도화됩니다. 3) 이상 징후 감지 및 대응 Zenius AI는 머신러닝 기반의 시계열 예측 모델을 활용하여, 시간에 따라 변화하는 메트릭 데이터의 정상적인 흐름을 학습하고, 예측값과 실제 관측값 간의 오차를 분석함으로써 예상 범위를 벗어나는 이상징후를 조기에 감지합니다. 이 방식은 단순한 임계치 설정을 넘어서, 모델이 정상 상태를 스스로 학습하고 예외 상황을 자동으로 판별함으로써, 더 높은 민감도와 신뢰성을 갖춘 예측 기반 감지 체계를 구현합니다. 또한, 감지된 이상징후에 대해 이벤트의 심각도를 자동 분류하고, 사전에 정의된 조건에 따라 이메일, 문자, 사운드 등 다양한 채널을 통한 실시간 알림을 제공함으로써, 운영자가 신속하게 대응할 수 있도록 지원합니다. 뿐만 아니라, Zenius AI는 메트릭 기반 탐지 외에도 로그 기반 이상징후 감지 기능을 제공합니다. 특히, 로그가 정상적으로 수집되지 않거나 누락될 경우를 실시간으로 탐지하는 로그 미수집 감지 기능을 통해, 분석에 필요한 데이터의 공백을 사전에 차단하고 이상 탐지 누락을 방지할 수 있습니다. 이 기능은 장애의 근본 원인을 조기에 식별하는 데 중요한 역할을 하며, 호스트 단위의 로그 수집 현황을 시각화하여 운영자가 이상 상황을 한눈에 파악하고 조치할 수 있도록 지원합니다. 4) 대시보드 및 시각화 기능 Zenius AI는 실시간 이상징후 감지 결과를 직관적으로 파악할 수 있도록, 고도화된 대시보드 및 시각화 기능을 제공합니다. 서비스 그룹, 호스트, 모델별로 논리적으로 구성된 시각화 컴포넌트를 통해, 운영자는 전체 IT 인프라의 상태와 이상징후 발생 현황을 한눈에 파악할 수 있으며, 각종 지표에 대한 심층 분석도 즉각적으로 수행할 수 있습니다. 또한, WYSIWYG(What You See Is What You Get) 기반의 시각 보고서 생성 기능을 통해, 이상징후 탐지 결과와 예측 데이터를 시각적으로 정리하고, 이를 분기별 보고서, 사용자 정의 통계 리포트 등 다양한 형식으로 출력할 수 있어 IT 운영팀 및 경영진과의 효율적인 커뮤니케이션과 의사결정을 지원합니다. 운영관리 측면에서는 사용자 권한 및 알림 통보 설정 기능이 포함되어 있어, 역할 기반 접근 제어(RBAC)를 통해 사용자별 접근 권한을 세밀하게 관리할 수 있습니다. 장애 또는 이상 이벤트 발생 시에는 이메일, 문자, 사운드 알람 등 다양한 매체를 통해 실시간 경보를 전송하고, 알림의 심각도, 전송 시간대, 수신자 그룹 등을 세분화하여 설정할 수 있어 운영의 유연성과 대응 속도를 크게 향상시킵니다. 이상 징후 탐지 솔루션, Zenius AI의 특장점 Zenius AI는 실시간 데이터 분석 역량과 AI 기반 모델 최적화 기능을 결합한 차세대 이상징후 탐지 솔루션으로, 기존 시스템 대비 한층 정교하고 신속한 대응 체계를 제공합니다. 이를 통해 IT 운영 환경에서 보다 신뢰도 높은 장애 예측과 효율적인 운영 관리가 가능해집니다. 첫째, Zenius AI는 초고속 인덱싱 및 검색 성능을 통해 대규모 로그 데이터를 실시간으로 분석할 수 있습니다. 최대 162만 EPS(Events Per Second)의 로그 인덱싱 처리 속도를 제공하며, 1TB 규모의 로그도 단 0.02초 내에 검색할 수 있어, 장애 발생 시 즉각적인 원인 진단과 대응이 가능합니다. 또한, 대용량 환경에서도 로그 유실 없이 안정적인 저장 및 분석이 가능하여, 운영 신뢰성과 가용성을 크게 향상시킵니다. 둘째, Zenius AI는 AI 기반의 자동화된 모델 관리 기능을 갖추고 있어, 모델의 학습, 최적화, 배포를 전 과정 자동화할 수 있습니다. 수작업 없이도 성능을 지속적으로 개선할 수 있으며, 스케줄 기반 학습 관리를 통해 최신 데이터를 반영한 정기적 모델 업데이트가 가능합니다. 또한, Zenius EMS(Enterprise Monitoring System) 및 다양한 3rd Party 시스템과의 연동 기능을 통해 기존 IT 인프라와 유기적으로 통합된 분석 환경을 구현할 수 있습니다. 셋째, 머신러닝 기반의 이상징후 조기 탐지 및 대응 체계를 통해 서비스 장애를 사전에 감지하고 신속하게 대응할 수 있습니다. 예측값과 실제값의 오차 기반 분석을 통해 정밀한 이상징후를 탐지하며, 장애 패턴 분석 기능을 통해 유사 장애의 반복 가능성을 최소화합니다. 이를 통해 운영자는 보다 체계적이고 선제적인 장애 대응이 가능하며, 전체 IT 서비스의 안정성과 연속성을 효과적으로 유지할 수 있습니다. Zenius AI는 AI 기반의 이상징후 탐지를 통해 IT 운영의 효율성을 높이고, 장애를 사전에 방지할 수 있도록 지원합니다. 머신러닝 기반의 학습과 장애 패턴 분석을 통해 장애 재발 가능성을 최소화하고, 선제적인 예방 및 대응 체계를 구축함으로써 장애 원인을 조기에 차단할 수 있습니다. 이를 통해 서비스 다운타임을 최소화하고, 안정적인 운영 환경을 유지하여 서비스품질과 신뢰도를 향상시킵니다. 또한, Zenius AI는 운영 비용 절감과 IT 생산성 향상에도 기여합니다. 장애 처리에 소요되는 인력과 시간을 절감해 운영팀이 핵심 업무에 집중할 수 있도록 돕고, 자동화된 감지 및 대응 시스템을 통해 전반적인 운영 부담을 효과적으로 완화합니다. 이상 징후 탐지 솔루션 Zenius AI도입을 통해 IT 운영의 안정성과 효율성을 강화하고, 보다 신뢰도 높은 서비스 환경을 구축하시기 바랍니다. 2025.04.03
기술이야기 SIEM 솔루션, Zenius SIEM의 주요 기능 기술이야기 SIEM 솔루션, Zenius SIEM의 주요 기능 클라우드 컴퓨팅, 컨테이너 기술, 분산 아키텍처의 확산으로 IT 인프라는 점점 더 복잡해지고 있으며, 이에 따라 로그 데이터의 양도 급격히 증가하고 있습니다. 로그 데이터는 시스템 운영 상태를 진단하고 보안 위협을 탐지하는 데 중요한 역할을 하지만, 방대한 데이터의 체계적인 수집, 저장, 분석 없이는 효과적으로 활용하기 어렵습니다. 이와 함께 운영 환경의 다양성과 복잡성이 증가하면서 보안 위협에 노출될 가능성도 높아지고 있습니다. 로그 데이터를 통합적으로 관리하고 분석하지 못할 경우, 잠재적 위협을 놓치거나 대응이 지연될 위험이 커집니다. 이러한 상황에서 로그 데이터를 통합적으로 관리하고 분석하는 SIEM(Security Information and Event Management) 솔루션이 유용한 도구로 자리잡고 있습니다. 그중에서도, Zenius SIEM은 대규모 로그 데이터를 실시간으로 통합 관리하고, 잠재적 위협을 신속히 탐지하여 기업의 운영 안정성을 높입니다. 또한, 다양한 환경에서 데이터 수집과 분석을 지원하고, 규제 준수 기능을 통해 기업의 보안과 운영 효율성을 강화하며 주목받고 있습니다. Zenius SIEM의 주요 기능과 특장점은 무엇인지 자세히 살펴보겠습니다. SIEM 솔루션, Zenius SIEM의 주요기능 5가지 1. 다양한 환경에서의 로그수집 및 통합 관리 Zenius SIEM은 복잡하고 다변화된 IT 환경에서 로그 데이터를 효율적으로 수집하고 통합 과리할 수 있도록 설계된 고도화된 기능을 제공합니다. 이를 통해 다양한 환경과 데이터 소스에서의 로그 관리가 더욱 체계적으로 이루어질 수 있습니다. - 다양한 로그 소스 수집: Syslog, 파일 기반 로그, 데이터베이스(DB) 등 전통적인 로그 소스는 물론, 클라우드 서비스(AWS, GCP, Azure)와 Kubernetes와 같은 컨테이너 환경에서도 로그를 누락 없이 수집합니다. 이를 통해 복잡한 하이브리드 및 멀티 클라우드 환경에서도 로그 관리의 일관성을 유지할 수 있습니다. - 실시간 로그 수집 현황 모니터링: 대량의 로그 데이터가 실시간으로 수집되는 과정을 직관적인 대시보드에서 시각화해 확인할 수 있습니다. 이는 로그 수집 과정에서 발생할 수 있는 문제를 조기에 발견하고 신속히 대응할 수 있도록 지원합니다. - Syslog 유형 자동 분석: 수집된 Syslog 데이터를 자동으로 분류하고 필터링하며, 로그 정규화를 통해 데이터의 분석 가능성을 높입니다. 이러한 기능은 이기종 환경에서 발생하는 다양한 로그 형식의 비효율성을 제거하고, 더욱 정확한 검색 및 분석 결과를 제공하는 데 기여합니다. Zenius SIEM의 이러한 기능들은 로그 관리의 복잡성을 대폭 줄이고, 사용자가 이기종 IT 환경에서도 신뢰성 높은 데이터를 기반으로 운영 결정을 내릴 수 있도록 합니다. 또한, 실시간 데이터 수집 및 모니터링을 통해 잠재적인 문제를 조기에 탐지함으로써 운영 중단과 같은 심각한 상황을 예방할 수 있습니다. 2. 안정적인 로그 저장 및 무결성 검증 Zenius SIEM은 로그 데이터를 안전하게 저장하고 관리하며, 데이터 무결성을 보장하는 데 필요한 다양한 기능을 제공합니다. - OpenSearch 기반 저장소: 대규모 로그 데이터를 효율적으로 저장하고 빠르게 검색할 수 있도록 설계된 고성능 분산형 스토리지를 사용합니다. 이를 통해 실시간 데이터 액세스와 대량의 로그 데이터 처리가 가능해집니다. - 로그 무결성 검증: SHA-256 기반 암호화 해시 기술을 활용하여 수집된 로그 데이터가 변경되거나 손상되지 않았음을 검증합니다. 이는 보안 사고 발생 시에도 신뢰할 수 있는 데이터로 사건을 분석하고 대응할 수 있는 기반을 제공합니다. - 효율적인 로그 압축 및 장기 보관: 장기적으로 저장해야 하는 로그 데이터를 효율적으로 압축하여 스토리지 사용량을 절감합니다. 또한, 보관 주기를 유연하게 설정하여 일정 기간이 지난 데이터를 자동으로 폐기하거나 다른 스토리지로 이관함으로써 데이터 관리의 효율성을 높입니다. - 다중 복제 및 장애 복구: 저장된 로그 데이터를 여러 노드에 중복 저장하여 데이터 유실 위험을 최소화하고, 장애 발생 시 신속하게 데이터를 복구할 수 있는 안정적인 구조를 제공합니다. 이를 통해 중요한 로그 데이터의 가용성을 항상 보장합니다. 이와 같이 로그 데이터의 무결성과 안정성을 보장함으로써, 규제 준수와 감사 대응 능력을 강화할 수 있습니다. 또한, 대량의 로그 데이터를 효율적으로 저장하고 복구 가능성을 확보함으로써, 운영 비용 절감과 데이터 신뢰성을 동시에 달성할 수 있습니다. 3. 정교한 로그 분석 및 상관관계 분석 Zenius SIEM은 단순히 로그 데이터를 저장하는 것을 넘어, 이를 활용해 조직의 운영 효율성과 보안 강화를 위한 정교한 분석 기능을 제공합니다. 구체적으로 아래와 같은 데이터 처리 분석 능력을 통해 보안 위협을 조기에 탐지하고 예방할 수 있도록 지원합니다. - 정밀 검색 기능: Zenius SIEM은 OpenSearch 기반으로 일반 검색과 상세 검색 두 가지 방식을 제공합니다. 일반 검색은 쿼리 스트림 방식을 활용해 간단하고 빠르게 데이터를 검색할 수 있으며, 상세 검색은 쿼리 빌더(Query Builder)를 통해 DQL(Query DSL) 방식으로 정밀한 데이터 탐색을 지원합니다. 두 방식의 장단점을 활용해 필요에 따라 선택적으로 사용할 수 있도록 설계되어, 폭넓은 검색과 정교한 분석을 모두 지원합니다. - 다차원 상관관계 분석: 복합 이벤트 처리 엔진(CEP)을 통해 다수의 로그 데이터를 연계 분석하여 숨겨진 위협 패턴과 이상 징후를 식별합니다. 이를 통해 보안 사고를 사전에 탐지하거나, 네트워크 이상 현상을 빠르게 발견함으로써 조직의 대응력을 강화합니다. - SQL 기반 분석 및 알림: SQL 쿼리를 활용하여 로그 데이터를 세부적으로 필터링하거나 집계하는 정교한 분석이 가능합니다. 특정 조건에 따라 이벤트를 자동 생성하고, 실시간 경고 알림을 발송해 보안 사고 발생 시 신속한 대응을 지원합니다. - AI 기반 예측 분석: 머신러닝 알고리즘을 적용하여 로그 데이터의 이상 패턴을 학습하고, 미래에 발생할 가능성이 높은 위협을 예측합니다. 이를 통해 잠재적 위험을 사전에 경고하여, 조직의 보안 태세를 더욱 강화합니다. 이와 같은 정교한 분석 및 예측 기능을 통해 조직은 단순히 과거 데이터를 검토하는 데 그치지 않고, 미래에 발생할 수 있는 위협을 사전에 예측하고 대응할 수 있습니다. 이는 보안 사고의 위험을 대폭 줄이고, 효율적인 위기 관리 체계를 구축하는 데 기여합니다. 4. 사용자 중심의 데이터 시각화 Zenius SIEM은 방대한 로그 데이터를 직관적으로 시각화하여 데이터의 가독성을 높이고 분석 과정을 단순화함으로써 IT 관리자와 보안 담당자의 의사결정을 효과적으로 지원합니다. - 다양한 시각화 컴포넌트 제공: 막대 차트, 선형 그래프, 테이블, 실시간 데이터 뷰, 3D 그래프 등 26종 이상의 다양한 시각화 옵션을 제공하여 로그 데이터를 다각도로 분석할 수 있습니다. 이러한 시각화 도구는 사용자 요구에 따라 데이터를 직관적으로 탐색하고 비교하는 데 유용합니다. - 실시간 이벤트 오버뷰: 전체 로그 데이터의 상태와 주요 이벤트를 실시간으로 요약하여 한눈에 파악할 수 있는 대시보드를 제공합니다. 또한, 분석 보고서를 자동으로 생성할 수 있는 기능을 통해 반복적인 보고 작업을 간소화하고 분석 효율성을 높여줍니다. - 맞춤형 보고서: 조직별 요구에 맞춘 정기 리포트를 자동으로 생성하여, 주요 운영 지표와 보안 상태를 간략히 요약합니다. 이 리포트는 IT 관리자와 의사결정자에게 필요한 정보를 명확하고 효율적으로 전달합니다. 이러한 시각화 기능을 통해 데이터의 복잡성을 단순화하여 IT 관리자와 보안 담당자가 중요한 정보를 신속하게 이해하고 조치를 취할 수 있습니다. 5. 효율적인 운영 관리 및 자동화 Zenius SIEM은 단순한 로그 분석 도구를 넘어, IT 인프라의 운영 효율성을 높일 수 있는 포괄적인 관리 기능을 제공합니다. 이를 통해 복잡한 환경에서도 일관되고 안정적인 운영을 지원합니다. - 역할 기반 계정 관리(RBAC): 세부적인 권한 설정을 통해 사용자별 접근 권한을 세밀하게 제어하며, 조직 내 각 사용자의 역할에 맞는 최소한의 권한만 부여해 보안성을 강화합니다. 이는 내부 보안 리스크를 줄이고 권한 오남용을 방지하는 데 효과적입니다. - 운영 자동화: 에이전트 설치, 재시작, 상태 모니터링과 같은 반복 작업을 원격으로 자동화하여 대규모 IT 환경에서도 일관된 운영이 가능합니다. 이를 통해 관리자가 주요 업무에 더 집중할 수 있도록 지원하며, 운영 효율성을 높여줍니다. - 리소스 상태 모니터링: 시스템의 CPU, 메모리, 디스크 사용량 등 주요 리소스를 실시간으로 모니터링하여 잠재적인 병목 현상을 사전에 식별하고 예방합니다. 이 기능은 리소스 최적화와 안정적인 서비스 제공에 중요한 역할을 합니다. - 클러스터 환경 지원: 다수의 장비와 복잡한 분산 시스템에서도 효율적으로 관리 작업을 수행할 수 있도록 설계되었습니다. 클러스터링 기능을 통해 고가용성(High Availability) 환경을 지원하여, 장애 상황에서도 서비스 연속성을 보장합니다. 운영 자동화와 효율적인 관리 기능을 통해 IT 팀의 업무 부담을 줄이고, 복잡한 인프라에서도 일관된 운영 체계를 유지할 수 있습니다. 이는 운영 생산성을 높이는 동시에 운영 중단 시간(Downtime)을 최소화하여 서비스의 안정성을 보장합니다. 다른 SIEM 솔루션과 비교 시, Zenius SIEM의 장점은?! Zenius SIEM은 현대 IT 인프라의 복잡성을 해결하고, 대규모 로그 데이터를 효율적으로 관리 및 분석하도록 설계된 차별화된 SIEM 솔루션입니다. - 실시간 데이터 수집 및 안전한 관리: 클라우드, 컨테이너, 분산 아키텍처로 인해 급증하는 로그 데이터를 실시간으로 수집하고 저장하며, SHA-256 기반의 무결성 검증과 TLS/SSL 암호화 통신을 통해 데이터의 보안과 무결성을 보장합니다. 이러한 기능은 민감한 데이터가 포함된 환경에서도 높은 신뢰성을 제공합니다. - 업계 최고 수준의 성능: Zenius SIEM은 1TB 규모의 데이터를 0.02초 이내에 검색할 수 있는 업계 최고 수준의 검색 속도를 자랑하며, 무중단 스케일 아웃 기능을 지원해 대규모 IT 환경에서도 안정적이고 유연한 확장이 가능합니다. 이는 대규모 엔터프라이즈 환경에서 필수적인 요구 사항을 충족합니다. - 정교한 상관관계 분석: 복합 이벤트 처리(CEP) 엔진을 활용해 다중 로그 이벤트 간의 숨겨진 패턴을 탐지하여 위협을 조기에 식별하고 대응할 수 있습니다. 이를 통해 기존의 단편적인 로그 분석을 넘어선 정교한 위협 탐지와 보안 사고 예방이 가능합니다. - 강력한 검색 및 분석 기능: DQL(Query DSL) 및 OpenSearch Query String 방식을 활용한 정밀 검색과 통계 분석 기능을 통해 사용자는 로그 데이터를 깊이 있게 탐구하고 활용할 수 있습니다. 이 기능은 데이터 중심의 의사결정을 지원하며, 복잡한 IT 환경에서의 로그 분석 효율성을 높입니다. - 사용자 친화적인 시각화 및 대시보드: 25종 이상의 시각화 컴포넌트(차트, 선형 그래프, 테이블 등)를 활용해 수집된 로그 데이터를 직관적으로 표현할 수 있는 대시보드를 제공합니다. 이를 통해 IT 관리자와 보안 담당자는 시스템의 운영 상태를 한눈에 파악하고, 중요한 데이터를 빠르게 이해할 수 있습니다. Zenius SIEM은 이러한 강력한 기능과 뛰어난 확장성을 바탕으로, 로그 관리와 보안 운영에서 차별화된 가치를 제공합니다. 2025.01.24

1