지난 ‘XAIOps 톺아보기 1’에 이어, 이번 시간에는 본격적으로 XAIOps(싸이옵스)에 대해서 알아보겠습니다. 

XAIOps

AI기반 IT 운영 지능화 솔루션 XAIOps(싸이옵스)는 시스템 부하와 장애의 빠르고 정확한 예측, 부하의 패턴 분석과 비정상 탐지를 통한 종합적인 근본 원인 분석, 지능적 미래 장애 예측을 통한 선제적 대응, 예측된 비정상 및 장애에 대한 지능적인 스마트 알람 등으로 신속하고 능동적인 문제 해결을 가능하게 한다. 그 뿐만 아니라 XAIOps는 실시간 매트릭 데이터를 기반으로 분석하기 때문에 ‘장애 발생 후 수 분 이내 근본 원인 도출’이 가능한 강력한 성능을 보유하고 있다. 

<XAIOps(싸이옵스)의 실시간 모니터링 뷰>

운영에 문제가 되는 장애들을 해결하는 데 통상 짧으면 수십 분, 치명적인 경우 2~3시간이 소요되는 현실에 비추어 볼 때, XAIOps(싸이옵스)는 실무자들의 부담을 크게 덜어줄 것으로 예상된다. 또한 해외 시장 조사 업체에 따르면 글로벌 AIOps 시장은 연간 27% 이상 고속 성장이 예상되며, 이에 따라 국내 AIOps 시장 수요 또한 제1금융권을 중심으로 급속히 성장하고 있어 XAIOps의 성장세가 기대된다. 특히 코로나19 이후 엄격한 비대면(untact) 트렌드와 재택근무 등 기업 운영 방식의 변화와 더불어 하루가 다르게 거대하고 복잡해지는 IT 비즈니스 환경에서 IT 운영에서의 AI 자동화 요구가 전례 없는 속도로 증가하고 있다. 

딥러닝 기반 "부하 예측(Load Forecast)"

<XAIOps(싸이옵스)의 부하 예측 기술>

주요 지표들에 대한 미래 부하를 사전에 예측하는 기술로, 딥러닝(Deep Neural Network) 기술 중에 하나인 DNN Regression 모델을 사용하여 여러 input 지표들에 대해 다차원 hidden layer간의 연관 분석을 통해 결과 지표를 도출하는 예측 모델과 별도의 잔차(residual) 예측 모델을 추가(ICP: Inductive Conformal Production)하여 신뢰도(default:95%) 기준의 범위로 최종 예측 결과를 도출하는 방식을 도입하였다.

XAIOps는 이러한 딥러닝 모델을 최적화하여 다양한 영역의 WAS, DB, Systerm 등의 지표들에 대한 30분이내 단기 부하 예측을 통해 장애 발생 가능성을 사전에 예측/제시하여 선제적인 장애 대응을 할 수 있는 중요한 기준을 제시할 수 있게 되었다.

이는 일반적인 머신러닝 기술을 적용한 경쟁 솔루션 대비 약 15%이상의 예측 정확도를 보장할 만큼 고도화·정교화 되었다고 본다.

지표별 최적의 “이상 탐지(Anomaly Detection)” 모델 제시

IT운영에서 발생되는 시계열 성능 데이터는 데이터 발생 유형과 성격에 따라 특정한 모델 하나로 학습할 경우 이상 탐지 여부의 정확도에서 신뢰도가 떨어진다. 따라서 XAIOps는 각 지표별로 최적의 성능을 제시할 수 있는 최적의 3가지 알고리즘 모델을 제시하여 최적의 이상 탐지를 찾아낼 수 있도록 고도화하였다. 

3) Robost Autoencoder 모델

더보기

접기

<Robost Autoencoder 모델>

Autoencoder모델 모델의 단점을 극복한 방식으로, Autoencoder로 학습할 때 전체 학습 데이터로부터 비정상 데이터를 스스로 분리하는 방법을 사용해 정상 데이터로만 학습하여 Autoencoder에 비해 성능을 최적화한 모델이다. 

접기

이상 트랜잭션 탐지

<이상 트랜잭션 탐지 모델>

WAS 모니터링을 하다보면 응답시간이 지연되는 트랜잭션에 대해 method level trace 분석을 필요시 진행하는 경우가 있다. 이를 장애시 마다 매번 찾아서 분석하는 작업을 머신러닝 기술인 K-Means Clustering 알고리즘을 적용하여 트랜잭션별 call trace를 학습시킴으로서 평상시와는 다른 패턴으로 실행된 이상 트랜잭션/거래를 자동 추출할 수 있게 되었다. 이렇게 추출된 데이터를 기반으로 시각적으로 빠르게 판단하고 분석할 수 있도록 하는 이상 트랜잭션 탐지 모델은 XAIOps 만의 고유 기술이다.

AI(인공지능) 특허 취득

엑셈은 지난 7월, AI(인공지능)를 활용한 이상 탐지 관련 특허 2건을 취득했다. 2건의 특허는 머신러닝 기술을 적용하여 정상 데이터와 비정상 데이터를 분류하기 위한 정상 데이터 범위를 생성하고, 이에 대한 정확도를 높이기 위해 정상 데이터들의 임곗값을 조정하여, 정상 데이터 판단의 정확도와 이상 탐지의 정확도를 향상하기 위한 기술이다. XAIOps에는 본 특허 기술과 유사한 메커니즘과 더욱 최적화한 머신러닝 상세 알고리즘이 적용되었다. 

현재 XAIOps는 국내 다수의 제1금융권, 공공기관, 대형 유통사 등에서 PoC를 성공적으로 수행하며 가시적인 성과를 앞두고 있습니다. 엑셈의 No.1 모니터링 기술력과 IT 운영 관리 경험에 AI 기술이 더해진 XAIOps. 엑셈의 독보적인 AI 기반 IT 인프라 운영 관리 기술과 서비스를 기대해주세요!

기고 | 신기술본부 류길현

편집 | 사업기획팀 박예영

엑셈의 AI(인공지능) 기반 IT 운영 지능화 솔루션 XAIOps(싸이옵스)에 로그프레소의 빅데이터 플랫폼인 ‘로그프레소 엔터프라이즈’를 탑재했습니다. 이를 통해 이상 징후와 장애의 사전 인지 능력과 사후 분석 능력을 동시에 제공할 수 있는 완성도 높은 기술 기반을 마련했는데요. 이번 시간에는 XAIOps가 내부적으로 어떤 데이터 수집 엔진을 적용했는지 알아보겠습니다.

실시간 빅데이터 기술

실시간 빅데이터 기술은 배치처리의 대상이 되는 이력 데이터(Historical Data)는 물론 실시간 스트리밍 데이터(Real-time Streaming Data) 처리 기술이 포함되어 있는데, 이번에 XAIOps에서 채택한 실시간 빅데이터 기술은 하나의 엔진에서 이 두 가지 형태의 데이터 처리가 가능하다.

<AIOps Platform에서의 실시간 빅데이터, Gartner그림 편집>

배치처리인 맵리듀스(MapReduce)를 필두로 한 하둡(Hadoop)진영이 빅데이터 시장의 서막을 열었고, 곧이어 실시간 스트리밍 데이터 처리의 필요성이 대두되자 스파크(Spark)가 이끄는 스트리밍 기술이 주목 받기 시작하였다. 이 두 가지 기술의 등장과 함께 람다 아키텍처(Lambda Architecture)가 동거를 시작했다. 그러나 실시간과 배치는 시계열의 스펙트럼에서의 한시적인 구분일 뿐 데이터 자체는 동일했기 때문에, 실시간 시스템에서 생성된 데이터를 다시 배치 시스템으로 밀어 넣는 과정에서 성능 이슈, 정합성의 이슈가 빈번히 발생하게 되어 람다 아키텍처는 사실상 하나의 신화(myth)로 전락하게 되었다. 

또한 람다 아키텍처는 빅데이터에서는 실시간, 배치 빅데이터를 동시에 다루는 것이 필요하며, 특히 양립한 복수의 시스템에 데이터를 전달하는 것은 비효율적이라는 것을 증명하는 계기가 되었다. 그렇기 때문에 XAIOps를 구성할 때 실시간 처리와 배치성 처리를 하나의 엔진에서 수행할 수 있는 빅데이터 처리 엔진의 채택은 아키텍처로 인한 여러 가지 문제를 사전에 차단하는 좋은 선택이었다.

실시간 이벤트 프로세싱 기술

실시간 스트림 처리는 실시간 분석이 가능한 기술이지만, 시간의 흐름에 따라 차곡차곡 처리하는 방식이기 때문에 특정 이벤트가 나중에 나타난 이벤트와 연관을 지어 분석해야 할 경우 배치처리에 의존할 수밖에 없다. XAIOps의 경우에도 복잡한 이벤트에 대해 실시간 알람을 수행해야 하는 경우가 발생하는데, 이를 클라이언트에 집중시키거나 할 경우 복잡도가 급격히 증가하고, 전체 성능도 가늠할 수 없기 때문에 선행 사건과 후행 사건을 연관 지어 실시간 분석하는 방식은 반드시 필요하다. 

이번에 도입한 실시간 빅데이터 기술은 CEP(Complex Event Processing)도 통합되어 있기 때문에 실시간 스트림 처리에서 쿼리 방식으로 활용이 가능하다. 실시간 이벤트 처리는 선행 이벤트가 발생하면 CEP 엔진에 이벤트에 관한 정보를 등록하고 후행 이벤트에서 선행 이벤트가 발생했는지 여부를 확인하는 방식으로 활용된다. 

고속 인덱스 기술

빅데이터에서 다루는 데이터는 상당한 대용량이다. 실시간으로 하루 10GB의 데이터를 처리해서 저장한다고 해도 1년이 되면 3.6TB에 달하게 된다. 실시간 처리 이후에는 이 데이터를 대상으로 검색이나 분석을 수행하게 되기 때문에 고속 검색과 분석 기술을 확보하는 것은 매우 중요하다. 

이 중 검색은 대량의 데이터에서 소량의 일부 데이터를 빠르게 찾아오는 기술이다. 인덱스는 데이터 처리에 있어 거의 기본이기 때문에, 빅데이터 뿐만 아니라 DBMS에서도 일반적으로 사용된다. 그러나 RDBMS에서 주로 사용되는 인덱싱 방식이 B*Tree라면 검색엔진 빅데이터 기술에서 사용되는 인덱스는 역인덱스(Inverted Index)이다.

<빅데이터와 RDBMS 인덱스의 차이점, 출처 : 로그프레소>

B*Tree는 인덱스 컬럼 값에 따라 정렬된 형태로 저장되며 Root, Branch, Leaf 블록을 계층 형태로 구성하여 데이터를 검색할 때 값을 비교하여 탐색하게 된다. Leaf블록에는 순서대로 정렬된 컬럼 값과 함께 실제 데이터가 저장된 위치를 알 수 있는 정보가 있어 이를 통해 원본에 접근하게 된다. 위 그림에서 만약 97이라는 값을 찾는다고 가정하면 Root 블록의 값인 122보다 작기 때문에 왼쪽 Branch 블록으로 이동한다. Branch에서도 비교를 통해 오른편 Leaf 블록으로 이동하고 여기서 순서대로 탐색하여 97을 찾아낸다. 이렇게 B*Tree 인덱스는 정렬이 되어 있어 탐색이 빠른 장점이 있는 반면, 정렬을 유지하기 위해서 데이터가 저장될 때 인덱스의 기록은 순차적으로 되어야 하는 단점이 있다. 또한 나뭇잎이 많은 나무는 가지가 크고 많아지는 것처럼 데이터가 증가함에 따라 인덱스의 깊이가 깊어져 성능이 점차 떨어지게 된다. 이러한 단점으로 인해 B*Tree 인덱스는 빅데이터에서 적합한 솔루션으로 자리 잡지 못하게 된 것이다.

반면 역인덱스는 본래 검색엔진에서 주목받기 시작하여 빅데이터에서도 꾸준히 활용되고 있다. 역인덱스가 다루는 데이터는 보통 비정형/반정형이 많기 때문에 이를 검색에서 활용되는 토큰을 추출하는 토크나이징 과정이 필요하다. 토크나이징만 되면 토큰에 원본을 찾을 수 있는 정보를 계속해서 추가하게 되고, 검색은 토큰에 매달린 주소들로 원본을 찾아가는 방식이다. B*Tree와 달리 인덱싱에 들어가는 비용은 토크나이징과 추가(Append)밖에 없기 때문에 고속의 인덱싱이 가능하고 탐색도 토큰만 빨리 찾기만 하면 성능이 보장된다. 하지만 이 방법도 단점이 존재한다. B*Tree의 경우 탐색의 효율을 위해 생성 시 정렬을 하게 되는데, 역인덱스는 정렬을 하지 않기 때문에 검색 성능이 복불복일 수밖에 없게 된다. 무엇보다 없는 토큰을 찾기 위해서는 모든 토큰을 확인해야 하므로 검색 결과가 0일 때 가장 많은 시간이 소요된다. 또한 탐색 자체가 IO이기 때문에 인덱스의 크기가 커짐에 따라 탐색하는 시간이 비례한다는 것도 문제가 된다. 

XAIOps에서 채택한 기술은 이러한 문제를 역인덱스 뒤에 블룸필터 인덱스를 덧대어 놓는 것으로 해결하였다. 블룸필터는 일종의 해시 함수로 빠른 검색이 가능하도록 해준다. 역인덱스의 결과를 블룸필터 인덱스로 인덱싱을 하게 되면 데이터의 유무와 위치를 고속으로 탐색할 수 있게 된다. 그리고 역인덱스 토큰 정보에 비해 미미한 수준의 크기만 필요하기 때문에 인덱스의 크기에 크게 영향을 받지 않는다. 여기에 인덱싱 과정에서 데이터에 타입을 부여하는 정형화 과정을 거쳐 타입, 필드 형태의 필드 인덱스 기술이 추가되었다. 블룸필터 인덱스가 탐색을 위한 인덱스 아키텍처의 보완이라면 필드 인덱스는 탐색 후 처리를 위한 보완이라고 볼 수 있다. 

토크나이징을 거친다는 것은 모든 데이터를 문자열로 인식한다는 것이 전제되어 있다. 문자열은 숫자와 다른 정렬 방식을 가지는 특성뿐만 아니라 맥락이 존재하지 않기 때문에 이후 재검색이 추가로 필요하게 될 수도 있어 검색 후에서 성능 저하 요소가 잔존하게 된다. 필드 인덱스는 인덱싱 단계에서 데이터의 필드와 타입을 가지고 생성되기 때문에 맥락에 따른 정확한 인덱싱이 가능하며 and/or 조건으로 탐색을 하는 경우에도 탐색 대상을 좁혀서 원본에 접근할 가능성이 커지게 되어 최적의 성능을 보장할 수 있게 해 준다. 이러한 인덱싱 기술에 힘입어 리눅스 서버 한 대에서 1TB 데이터(약 25억건)를 랜덤 인덱스 검색을 수행할 경우 1초 미만의 검색 성능을 보여주고 있다.

컬럼 스토리지 기술

인덱스는 대량의 데이터에서 소량의 데이터를 빠르게 가져오는 기술이다. 그러나 분석, summary의 경우는 대량의 데이터에서 일부 컬럼들 전체를 대상으로 연산을 수행한다. 빅데이터는 처음부터 대량의 데이터에 대한 IO 집약적인 처리 방식을 염두에 두고 나온 기술이기 때문에 분산이라는 기술을 당연하게 여기고 있었다. 그러나 데이터가 점점 더 늘어날수록 분산에 투입되는 서버 자원도 늘어남에 따라 분산의 한계가 드러나기 시작했다. 분산의 노드와 마스터 간의 네트워크를 통한 데이터 교환의 한계가 나타나기 시작한 것이다. 여기에 추가 투입되는 하드웨어 자체의 비용과 관리 비용의 증가도 눈에 띄게 되어 대용량 처리의 제약으로 작용하기 시작했다. 

이와 달리 XAIOps에서 채택한 빅데이터 기술은 하나의 서버에서 확보할 수 있는 성능을 취하는 관점으로 설계가 되어 대용량의 Aggregation을 위해 분산이 아닌 VLDB에서 사용되는 Columnar 기술을 내장하고 있다.

<Row기반 Storage와 Column기반 Storage, 출처: 로그프레소>

DW DB에서는 거의 기본으로 row 기반 저장 방식을 사용한다. 우리가 다루는 데이터의 최소 단위는 건(row)이고 이 row는 여러 개의 컬럼으로 구성되어 있다. 기본적으로는 데이터가 들어오는 방식 그대로 row를 차곡차곡 저장하게 된다. 

Columnar는 row 형태로 저장하는 것이 아니라 row를 컬럼 단위로 해체하여 동일한 컬럼끼리 저장하는 방식이다. 이렇게 저장하는 것이 Summary에 특화되는 것은 전체 row가 아니라 일부 컬럼만을 선택하여 연산하는 Aggregation과 같은 분석의 특성 때문이다. 대량의 데이터를 모두 가져와 필요한 컬럼만을 남기고 버리는 것이 아니라, 필요한 처음부터 필요한 컬럼을 가져오도록 하여 최적의 성능을 취할 수 있게 해 주는 것이다. 주목해야 할 점은 정형 데이터가 아니라 로그 데이터와 같은 비정형/반정형 데이터에 대해서도 Columnar를 적용할 수 있다는 점이다. 

XAIOps가 선택한 컬럼 스토리지 기술은 쿼리에서 집계하는 대상 컬럼 데이터를 높은 효율로 읽을 수 있도록, 열 단위로 값 벡터를 나열하여 불필요한 I/O 작업을 회피하고 CPU 캐시 활용을 극대화하고 있다. 이로 인해 스키마리스 컬럼 스토리지 기술은 원본 로그 저장과 포맷의 변화를 수용하면서도 높은 OLAP 분석 성능을 낼 수 있게 된다. 또한 전사 시스템, 애플리케이션 로그 등도 분석의 대상이 될 수 있기 때문에 이러한 형태의 데이터를 Columnar로 다룰 수 있게 되면 장기간 분석도 굉장히 빠른 시간 내에 처리가 가능하게 된다.

JIT 쿼리 컴파일 기술

XAIOps는 AI 기술이 근간을 이루면서 학습을 위한 데이터 전처리는 일정 부분 빅데이터 처리 엔진에서 담당해주어야 전체 시스템의 성능을 보장할 수 있게 된다. 이 작업은 앞서 언급한 단순히 저장된 데이터를 빠르게 가져오는 것이 전부가 아니고 디스크나 메모리에서 획득한 데이터의 연산 성능도 영향을 미치게 된다. 가장 좋은 방법은 연산에 필요한 처리 조직을 최적화하여 미리 컴파일해 놓는 방법이지만, 사이트 별로 요구 사항이 다른 상황에서는 각각 자유롭게 대응할 수 있도록 쿼리를 지원하는 것이 좋다. 이는 이미 수십 년 전 데이터베이스가 도입될 때 증명이 된 사실이기도 하다. 

기고 | 로그프레소 김한도

편집 | 사업기획팀 박예영

테이블은 MSSQL에서 가장 최소단위의 데이터 집합 단위입니다.

데이터의 양이 많을수록 테이블을 읽고 쓰고 수정하는 데 필요한 비용이 늘어나는데, 이를 개선하기 위한 기능으로 분할된(Partitioned) 테이블이 존재하고, 이 기능은 관리 효율성과 성능 면에서 다음과 같은 이점이 있습니다. 

1. 데이터 하위 집합을 빠르고 효율적으로 전송하거나 액세스할 수 있을 뿐만 아니라 데이터 컬렉션의 무결성을 유지할 수 있습니다.

2. 하나 이상의 파티션에서 유지 관리 작업을 더 빠르게 수행할 수 있습니다. 

   전체 테이블 대신 이 데이터 하위 집합만 대상으로 하기 때문에 작업이 더 효율적입니다.

3. 자주 실행하는 쿼리 유형과 사용 중인 하드웨어 구성에 따라 쿼리 성능이 향상될 수 있습니다.

4. 전체 테이블이 아니라 파티션 수준에서 잠금 에스컬레이션을 설정하여 성능을 향상시킬 수 있습니다.

그리고 분할된 테이블을 사용하게 되면 통계적 측면에서도 이점이 생깁니다. 증분통계(Incremental)옵션이 그 기능입니다. 

통계는 기본적으로 인덱스를 생성할 때 같은 이름의 통계가 자동 생성됩니다. (인덱스가 없는 column을 조건으로 조회했을 때 생기기도 합니다.) 이렇게 생성된 통계 정보는 Query를 수행했을 때 사용되는 비용을 예측하여, 최적화된 실행 계획을 세울 수 있게 해줍니다. 

하지만 데이터를 수정·변경·삭제할 때 통계 데이터도 업데이트가 되고, 테이블의 모든 데이터를 기반으로 업데이트 하고 있기 때문에 그에 따른 비용이 많이 발생합니다. 비효율적인 예시로, 최근 대량의 데이터가 삽입, 수정, 삭제되는 상황에서는 과거 데이터에 대한 통계에 변화가 없습니다. 

하지만 통계가 업데이트가 될 때에는 테이블의 전체 데이터를 기반으로 샘플링하여 업데이트를 하게 되고, 과거 데이터까지 포함하여 통계 업데이트가 되기 때문에 이 부분에서 비효율이 발생합니다. 증분 통계는 그 비효율을 감소시킬 수 있습니다.

이제 Partition의 효율을 확인하기 위해 일반테이블과 분할된 테이블의 조회에 대한 I/O 비교와 일반 통계와 증분 통계의 통계 업데이트에 쓰이는 I/O 비교를 해보겠습니다.

2. 인덱스는 ModifiedDate 컬럼에 Non Clustered로 생성하였습니다.

3. 전체 테이블의 row 수는 약 378만이고, 단독 Partition으로 구성되어 있습니다.

4. 해당 쿼리를 수행하면 Table Scan을 하게 됩니다. 모든 데이터를 스캔하여 제시된 조건에 맞는 데이터만 결과 집합으로 나타냅니다.

   논리적 읽기를 44,274만큼 합니다.

분할된 테이블

1. 파티션 데이블은 데이터를 특정 컬럼(ModifiedDate)에 기준을 만들어서 분할하는 테이블입니다.

2. TestSalesOrderDetail에서 ModifiedDate 컬럼을 연도별로 기준을 지정했고, 그 기준에 따라 분할되어 저장했습니다.

3. Partition을 각각 확인해보면, 전체 테이블의 row 수는 약 368만이고, 

   1번 partition은 6,718, 2번은 315,247, 3번은 1,875,219, 4번은 1,482,530입니다.

4. 이전과 동일한 쿼리를 수행하면 Table Scan을 하지만, 테이블의 전체 데이터를 스캔하지 않고, 

   제시된 조건이 포함하는 Partition만 스캔하여 결과 집합으로 나타냅니다. 

   논리적 읽기를 4,519로 일반 테이블에 비해 1/10 정도 감소한 것으로 볼 수 있습니다.

5. 일반 테이블과 분할된 테이블의 StmtText를 비교해 보면, 분할된 테이블에서는 

   조회하고자하는 데이터가 속한 Partition을 먼저 탐색한 후에 스캔을 하기 때문에 논리적 읽기 수를 많이 줄일 수 있습니다. 

   위가 일반, 아래가 Partitioned 테이블의 동일한 쿼리에 대한 StmtText입니다.

일반적인 통계

1. 일반적인 테이블이나 분할된 테이블에서 인덱스를 생성하면 모두 통합된 통계로 생성됩니다.

   아래에 보이는 것은 내부적으로 수행되는 Trace인데, 통계를 생성하기 위한 I/O가 쓰이는 것을 볼 수 있고, 

   통계 데이터를 조회해보면 테이블의 전체 데이터를 기반으로 샘플링하는 것을 확인할 수 있습니다.

2. 특정 파티션에 해당하는 데이터만 변경했을 때에도 옵티마이저는 테이블의 전체 데이터를 샘플링하여 통계를 업데이트합니다. 

   (샘플링은 데이터 양에 따라 비율이 조정됩니다.) 테이블이 분할되어 있어도 통계 데이터는 분할되어 있지 않기 때문입니다. 

   통계가 자동 업데이트 될 수 있도록 임계치 이상의 데이터를 업데이트 하였고, 관측한 통계 업데이트에 사용되는 I/O는 1,947입니다.

증분 통계

1. 이런 비효율을 해결할 수 있는 옵션은 Incremental(증분 통계) 업데이트 입니다.

2. 이 옵션은 테이블이 Partitioning 되어있을 경우 ON/OFF 할 수 있는 옵션이며, SQL Server 2014 이상 버전에서 사용이 가능합니다.

3. 옵션을 ON으로 설정하게 되면 기존의 통계를 분할된 통계로 재생성하게 됩니다.

4. 분할된 통계로 구성된 이후에 데이터를 수정하거나 변경이 있어 통계가 업데이트 되는 경우, 모든 데이터의 통계를 업데이트하지 않고 변경된 데이터가 속한 Partiton의 통계만 업데이트하게 됩니다. 통계 업데이트에 쓰이는 I/O는 185로 일반 통계에 비해 1/11 정도 감소한 것을 알 수 있습니다.

분할된 테이블 및 증분 통계 옵션을 통한 기대효과를 아래 표로 정리하며 마무리하겠습니다.

<분할된 테이블 및 증분 통계 옵션을 통한 기대효과>

기고 | 신기술본부 김국현

편집 | 사업기획팀 박예영

많은 사랑을 받고 있는 엑셈의 InterMax가 한단계 더 진화했습니다.

고객이 조금 더 편리하게 사용할 수 있도록 개선된 내용을 소개합니다.

1. APM의 효율적인 Application 병목 분석을 위한 콜트리 표현 개선안

APM 에서 Application 병목 현상을 분석하기 위해 콜트리(Class & Method)를 수집합니다. 콜트리를 수집하는 방법은 통계 기반 콜트리와 시계열 기반 콜트리의 2가지 유형으로 분류 가능하고, 유형별 장단점이 있습니다. (아래 [콜트리 유형 및 장단점 비교] 참고)

통계 기반 콜트리 표현의 장점이 많긴 하지만, 시계열 기준으로 분석을 꼭 해야만 장애분석이 가능한 경우가 분명 존재 하기 때문에 (특히 금융 거래 패턴 업무) 두 가지 유형을 모두 APM 에서 제공하는 것이 바람직합니다. 

<콜트리 유형 및 장단점 비교>

<통계 or 시계열 콜트리 선택적 적용>

2. 업무별 방문자 수 Validation의 중요성

시스템을 사용하는 사용자가 얼마나 많은지에 대한 판단 기준이 되는 방문자 수는 보통 주기적으로 업무 보고에 사용되는 APM 수집 주요 성능 지표 중에 하나입니다. 업무 담당자는 방문자 수의 추이로 어떤 업무에 방문자가 몰리고 있는지, 그리고 인프라 담당은 시스템의 증설 판단 기준으로 활용할 수 있습니다. 

그래서 이 값의 Validation이 정확치 않으면 업무담당 or 인프라담당의 의사 결정에 CRITICAL한 실수를 유발 시킬 수 있습니다. 방문자 수는 보통 개별 Agent 기준이 아닌 Agent 의 Group으로 대표 되는 업무 기준으로 정확히 추출하는 것이 중요한데요. 

웹 환경을 예로 들어서 설명 드리면 Web Browser에서 서비스 요청 시 동일 사용자의 요청은 여러 Agent(WAS)에서 처리가 될 수 있어 Agent 기준으로 방문자 수를 unique하게 산출하여 Agent 그룹인 업무로 SUM을 하게 되면 Agent 개수 만큼 동일 사용자수가 중복 될 수 있기 때문에 정확한 업무별 unique 방문자 수 산출을 위해서는 업무에 속한 Agent 대상 모두를 바라보고 unique 한 방문자수 처리를 해야 합니다.

3. 사용자 정의형 – Query 통계 기반 보고서 생성 필요성

APM Solution 을 포함한 기타 SMS, NMS, DPM etc 의 모든 모니터링 Solution 들은 보고서 기능을 포함하고 있습니다. Solution에 따라서 Reporting tool 과 연계하여 상대적으로 보고서 기능이 강한 제품도 있고 상대적으로 보고서 기능이 약한 Solution 도 있습니다. 보고서 기능이 아무리 뛰어나더라도 고객의 모든 사용자 보고서를 자동으로 만족시킬 수 없는 한계는 존재 합니다. 그래서 사용자가 직접 통계 정보 추출용 쿼리를 생성하여 데이터를 추출해서 보고서화 할 수 있는 기능이 있으면 사용자가 얼마든지 쿼리 기준으로 본인이 원하는 항목에 대해 값을 추출 할 수 있습니다. 

또한 성능 테스트 과정에서도 참조하기 위한 값을 실시간으로 추출한다던지, 활용 범위가 많아 쿼리 베이스의 데이터 추출 기능은 여러 가지 업무에 도움을 줄 수 있습니다. 일단 어떤 상황에서든 필요에 의해 임시로 만들어둔 쿼리 베이스의 추출 데이터를 정기 보고서로 사용하길 원한다면 해당 쿼리 기준으로 고객이 원하는 화면을 추후 제공하는데 참조 할 수도 있습니다.

<쿼리 베이스의 보고서 제공>

4. 트랜잭션 처리 시간에 대한 패턴 분석의 의미

Application 장애가 발생 전 정상적인 트랜잭션 처리 응답시간이 나오지 않고 가로, 세로 줄을 서는 패턴을 종종 보게 됩니다. 이 패턴이 보이면 추후 업무가 되지 않는 큰 장애와 연관될 확률이 높아 이 패턴을 최대한 빠르게 인지 할 수 있으면 장애 전 사전 대응이 가능해짐으로 인해 업무의 안정성을 확보하는데 도움이 됩니다. 가로, 세로 줄서는 패턴이 보이는 CASE에 대한 Application 처리 상황을 간단히 정리하면 아래와 같습니다.

위와 같은 트랜잭션 응답 시간 처리 패턴에 대한 분석을 AI(머신러닝)기반으로 한 차원 더 깊게 분석이 가능하게 되면 좀 더 다양한 트랜잭션 응답 처리 시간 패턴에 대해 세분화된 장애 징후를 미리 인지 할 수 있을 것으로 판단됩니다.

<트랜잭션 이상 징후 탐지 - 트랜잭션 가로 세로 분석>

앞으로도 지속적으로 고객에게 최고의 솔루션을 제공할 수 있도록 노력하겠습니다.

인공지능(AI)과 전력 빅데이터 분석

인공지능은 센스나 장비, 기기 등의 현 상태를 모니터링 하는 단순 영역부터 복잡하고 불확실한 미래상황을 추론하는 영역까지 다양한 영역에서 적용되고 있다. 가트너에서는 AI가 2021년까지 3천 3백조원의 비즈니스 가치와 7조 시간을 절약하는 업무 생산성 향상을 가져다 줄 것으로 예상하고 있다. 기계학습(머신러닝, Machine Learning)이나 심층학습(딥러닝, Deep Learning)은 모두 인간의 지능을 대체한다는 점에서 인공지능이라고 정의된다.

현재 MaxGauge에서 알람이 발생하면 Mail 또는 SMS로 해당 알람을 발송해주는 기능이 있습니다.

최근 들어 SMS(문자)보다 카카X톡, 라X, 위X과 같은 어플리케이션 사용이 늘어나면서,

알람을 어플리케이션으로 받고 싶어하는 고객사가 증가하고 있습니다. 

그래서 고객들의 니즈를 반영하여 카카오톡으로 MaxGauge 알람을 전달받을 수 있는 기능을 구현해보았습니다. 

사용한 기능

1. 카카오 API

카카오에서 제공하는 모든 플랫폼에 대한 API를 제공하고 있습니다.

2. Apache Tomcat

서블릿 컨테이너만 있는 웹 어플리케이션 서버이며 Java 환경을 제공합니다. 

HTTP서버도 자체 내장하기 때문에 아파치 톰캣을 이용하여 사용자가 원하는 환경으로 서버를 구축할 수 있습니다.

이 프로젝트에서는 Apache Tomcat은 MaxGauge의 Jetty와 동일한 역할을 수행하도록 구현했습니다. 

3. HTML

웹페이지를 만들기 위한 언어로 웹브라우저 위에 동작하는 언어입니다. 

제목, 단락, 목록 등과 같은 본문을 위한 구조적 의미 뿐만 아니라 

사진, 링크와 그 밖의 항목을 구조적 문서를 만들 수 있는 방법을 제공합니다. 

이 프로젝트에서는 MaxGauge의 Admin 페이지의 한 부분을 수행하도록 구현했습니다.