태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

엑기스 | XAIOps 톺아보기 2 - 엑셈의 기술력이 집대성된 솔루션

기술이야기/엑.기.스 2020. 8. 10. 15:29




지난 ‘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가지 알고리즘 모델을 제시하여 최적의 이상 탐지를 찾아낼 수 있도록 고도화하였다. 


1) Baseline 기준 이상 탐지 모델


2) Autoencoder 모델


3) Robost Autoencoder 모델



이상 트랜잭션 탐지


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


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




근본 원인 분석(Root Cause Analysis)

<XAIOps의 장애 근본 원인 제시 뷰>


시간 부하 예측, 이상 탐지 및 상관관계/인과관계 분석 기능 등을 통해 장애 발생시 근본 원인에 대한 추론을 최대한 빠르게 제시하는 부분이 가장 핵심 기술 중 하나이다. 장애에 대한 빠른 탐지(MTTD: Mean Time To Discovery)와 발생된 장애를 최대한 빠르게 분석하여 복구할 수 있도록 제시(MTTR: Mean Time To Recovery(Repair))할 수 있는 부분이 엑셈만이 제시할 수 있는 IT 운영의 노하우의 집대성이라 할 수 있다. 장애 인지와 동시에 장애 근본 원인을 요약 제공하는 “Summary Information” 부분과 하단에 각 영역별(Transaction, WAS, DB, OS 등) 해당 시점의 문제 포인트를 함께 상세하게 제공하여 빠른 장애 판단이 가능하도록 한다.



AI(인공지능) 특허 취득


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




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









기고 | 신기술본부 류길현

편집 | 사업기획팀 박예영










엑기스 | XAIOps 톺아보기 1 : 원천 데이터 수집의 근간

기술이야기/엑.기.스 2020. 7. 2. 10:24






엑셈의 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 엔진에 이벤트에 관한 정보를 등록하고 후행 이벤트에서 선행 이벤트가 발생했는지 여부를 확인하는 방식으로 활용된다. 


<실시간 이벤트 활용 예시, 출처: 로그프레소>
 
위 그림의 경우 이상거래탐지시스템(FDS : Fraud Detection System)에서 전형적으로 활용되는 방식으로, 보이스 피싱이 발생하는 경우 입금 이벤트에서 의심 계좌로 등록된 계좌에 입금이 발생하면 CEP 엔진에 입금 이벤트 Topic을 생성하게 된다. 그러나 의심 계좌는 그야말로 의심 계좌이기 때문에 이 입금 자체는 문제가 아니지만, 금융사가 보기에 입금되고 나서 10분 이내에 출금이 되는 경우 보이스 피싱이라고 간주할 수 있다. 이러한 이유로 이 입금 이벤트는 한시적인 기한을 두고 CEP 엔진에 머물러야 하며 이벤트 발생 후 주어진 시간(예를 들어 10분)이 되면 자동으로 CEP 엔진에서 삭제되어야 한다. 이 상황에서 해당 계좌로 출금이 발생하면 CEP엔진에 입금 이벤트가 남아 있는 지만 파악하면 보이스 피싱 여부를 확인할 수 있게 된다. 

즉, 출금 이벤트가 발생했을 때 스트림 쿼리에서 CEP 엔진에 입금 이벤트가 있는지 확인하기만 하면 되는데, 입금한 지 10분 내로 출금을 시도하는 경우 당연히 CEP 엔진을 통해 입금 이벤트가 남아 있는 것이 확인되기 때문에 보이스 피싱으로 탐지가 될 것이고, 10분이 지난 후라면 입금 이벤트는 이미 CEP엔진에서 사라졌을 것이기 때문에 의심 계좌이지만 보이스 피싱이 아닌 정상 거래라고 볼 수 있게 되는 것이다. 

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


<고속 연산을 위한 JIT 쿼리 컴파일 기술, 출처: 로그프레소>

 

쿼리를 통해 자유도를 높일 경우 개별 쿼리와 함수들을 순차적으로 처리하는 과정에서 반복된 로직이 최적화되지 않은 상태로 진행될 소지가 다분하다. 이러한 폐단은 어느 시스템에서나 발생할 수 있기 때문에 나열된 쿼리를 기계적으로 순차 수행하도록 놔두어서는 안 된다. 그래서 강구해낸 방안이 JIT 쿼리 컴파일 모델이다. JIT 쿼리 컴파일 기술은 쿼리 실행 시점에 코드를 생성하면서 불필요한 조건 분기와 루프로 인한 오버헤드를 모두 제거함으로써, 빅데이터 쿼리 분석을 실행할 때 최상의 성능을 도출하게 된다. 이를 통해 중첩 join과 같은 복잡한 쿼리를 사용해도 최상의 성능을 나타낼 수 있어 AI로 학습데이터를 가공하는 데이터 탐색의 시간을 최소화할 수 있다. 이 기능은 시스템 전반에 적용되기 때문에 summary, 실시간 처리 등에서도 최적화된 쿼리 성능을 보여주게 된다.


XAIOps는 이러한 다양하고 효과적인 기술이 녹아 있는 빅데이터 엔진을 선택하여 대용량의 데이터, 어떠한 상황이 오더라도 빠르고 정확한 결과를 도출할 수 있도록 한다. XAIOps를 통해 IT업계의 한 전기가 마련될 수 있으리라 기대하고 있다. 



다음 편에는 완성된 솔루션을 확인할 수 있는 'XAIOps 톺아보기 2'가 이어집니다.




기고 | 로그프레소 김한도

편집 | 사업기획팀 박예영










엑기스 | SQL Server) 분할된 테이블에서 효율적으로 통계 관리하기

기술이야기/엑.기.스 2020. 6. 8. 15:55




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

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



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

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

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

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

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


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


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


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


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


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




일반 테이블

1. 효율을 확인하기 위해 테스트용 테이블 TestSalesOrderDetail을 생성하였고, 해당 테이블의 구조입니다.


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의 변화

기술이야기/엑.기.스 2020. 5. 15. 15:58






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

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




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


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


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


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


InterMax 의 관련 처리 개선 내용


- 통계 or 시계열 콜트리를 선택적으로 사용 할 수 있게 개선

  특히 모니터링 대상(Agent) 별로 통계 or 시계열 콜트리를 선택적으로 사용 할 수 있게 함으로써 해당 모니터링 대상 분석에 적합한 것을 선택해서 사용하도록 처리

- 보통 사이트 장애 분석 시 시계열 분석이 필요 없는 Agent는 별도의 설정 없이 Application의 중요 내용을 상세하게 모니터링 할 수 있는 통계 기반 콜트리로 Setting 하고, 장애 분석 시 꼭 시계열 기준의 분석이 필요한 Agent에 대해서는 시계열 콜트리로 설정해서 분석 진행하는 하는 것이 바람직하다고 판단


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



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


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


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


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


▶ InterMax 의 관련 처리 개선 내용


모든 업무별 방문자 수 추이를 볼 수 있는 방문자 통계 화면을 제공

기존 방문자 통계는 업무별 Unique한 방문자 수가 아니었으나, 업무 기준으로 Unique한 데이터를 추출하여 제공하는
  업무별 방문자 수 분석 결과를 제시하도록 개선 
(시간, 일 단위로 업무별 방문자 통계 분석이 가능하도록 추가 개선)


<방문자 통계 - 업무 기준 통계 개선>




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


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


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


InterMax 의 관련 처리 내용


- 이미 Script Manager를 통하여 통계 추출을 위한 사용자 정의형 쿼리를 작성하여 저장하고, 보고서 생성 화면에서 해당 사용자 정의형 쿼리를 선택하여 리포트를 자동 생성할 수 있는 방향으로 기능을 개선

- 기존 보고서는 내부적으로 정형화(고정된) 항목내에서만 보고서 작성이 가능하였으나, 사용자 정의형에서는 작성/등록된 사용자 쿼리를 선택하여 원하는 통계 정보를 리포트로 생성할 수 있게 추가/개선


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




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


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


<가로, 세로 줄서는 패턴이 보이는 CASE에 대한 주요 원인>


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


InterMax 의 관련 처리 내용


- 트랜잭션 모니터의 가로 세로 패턴 감지를 통한 알람 발생 기능 추가


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




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











기고 | 신기술본부 장일홍
편집 | 사업기획팀 박예영


엑기스 | 지능형 전력 빅데이터 예측, AutoML이 답!

기술이야기/엑.기.스 2020. 3. 13. 16:38






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


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


최근 데이터 과학과 데이터 사이언티스트의 부족으로 인해 자동 기계학습(Auto ML) 영역이 급속도로 커지고 있다. Auto Machine Learning이란, 데이터만 있다면 자동으로 분석 모델을 학습하고 갱신하여 최적의 분석 알고리즘을 추천, 업무에 적용하는 것이다. 분석 전문 지식이 없는 일반 사용자도 쉽게 머신 러닝 분석을 자동으로 생성하고 활용 가능하다. Auto ML 소프트웨어 툴의 수는 단 2년 만에 300%가 증가하였는데, 자동화된 데이터 과학 도구에 대한 다양한 정의, 기대 및 회의론과 모델 개발 및 배포에 대한 개선된 접근 방식 등의 변화로 이루어졌다.

전력 분야에서는 자원 및 시설의 효율적인 관리와 함께 문제 및 변칙의 적시 감지, 전력 수요 및 서비스에 대한 효과적인 예측을 위해 빅데이터와 AI 기술을 활용하고 있다. 다수 빅데이터 프로젝트가 진행되고 있으며, 플랫폼 및 인프라, 에너지 대용량 데이터 모니터링 및 분석, 스마트 시티, 스마트 홈 및 전기 자동차의 수요 예측, 새롭고 혁신적인 에너지 서비스 등의 분야를 포함한다.


데이터 분석 기법과 프로세스

데이터 분석의 80%가 머신러닝 기법을 이용하고 있다. 머신러닝은 비지도, 지도, 심층, 강화 학습 등으로 나뉘고, 최근 Gradient Boosting Tree와 Random Forest와 같은 머신러닝 앙상블 모델을 분석에 주로 활용한다. 현재 머신러닝 자동화 제품으로 가능한 분석 기법은 지도학습(Supervised Learning)이다. 예측하고자 하는 변수(목표변수, 결과)를 분석하기 위해서는 결과(정답)가 있는 과거 이력 데이터가 필요하기 때문이다. 일부 상용 머신러닝 플랫폼 중 머신러닝 자동화가 가능한 제품은 비지도학습 기법인 주성분 분석(Principal Component Analysis)과 K-Means 분석을 활용해 결과 예측력을 높이는 기능도 제공한다.


일반적인 데이터 분석 프로세스는 데이터 준비 – 데이터 저장 – 구조화 – 전처리 – 모델 평가 – 모델 학습 – 예측 데이터 수집 – 모델 배포 – 예측과 실제 결과 비교 – 모델 관리 모니터링 – 시각화 – 인사이트 발굴의 12단계이며, 대표적인 전통적 데이터 분석 프로세스는 아래 3가지가 있다.


그렇다면 전통적인 IT 프로젝트와 빅데이터 분석 프로젝트의 차이는 무엇일까? 전통적인 프로젝트는 기존 프로세스를 파악해 개선된 프로세스를 기반으로 시스템과 제품, 생산 등의 효율성과 비용절감을 강조하지만, 빅데이터 분석은 예측을 통해 가치를 창출하는데 초점을 맞춘다.




머신러닝 플랫폼의 종류와 평가 프레임워크



가트너에서 매년 발표하는 Magic Quadrant의 2020년 데이터 과학과 머신러닝 플랫폼 부문을 보자. 2020년으로 넘어가면서 전통적인 머신러닝 플랫폼인 SAS가 다시 리더 포지션으로 올라왔고, KNIME이 작년 리더 그룹에서 비저너리 그룹으로 내려온 점이 주목할 만 하다. 또한 Databricks, Dataiku, DataRobot 등이 새로운 포지션으로 이동했다. 

데이터 사이언티스트들은 오픈소스로 모델을 구현하는 경우가 많지만, 모델 구현 후 모델 배포 관점에서 상용 플랫폼을 선택하는 경우가 많다. 상용 플랫폼의 경우 모델 배포 및 모델 활용을 위해 Rest API 지원이 편리하고 용이하기 때문이다. 또한 다수의 상업 플랫폼이 이용 가능한 머신러닝 플랫폼이 R과 Python을 같이 쓸 수 있도록 지원하고 있다. 외산 Auto ML 제품군에서는 DataRobot과 H2O가 국내 지원을 하고 있다. 


Auto ML 평가를 위한 일관성 기준도 있다.

① 데이터 연결성 

② Summarization, Exploration & Cleansing을 포함한 데이터 처리의 기능 및 자동화

③ 데이터 변환 및 피쳐 선택을 포함한 피쳐 엔지니어링에서의 기능 및 자동화

④ 하이퍼 파라미터 튜닝, 문제 유형 및 앙상블을 포함한 학습 알고리즘의 기능 및 자동화

⑤ 데이터 및 모델 성능 시각화

⑥ 모델 성능 평가 역량

⑦ 제품 GUI, 코드 배포 및 포함을 비롯한 배포 옵션

⑧ 가격 책정


대표적 Auto ML인 데이터로봇의 기능과 특장점을 살펴보자. 

① 데이터 탐색 → 100+여개 기법 중 최적 모델 선택 → 최적의 하이퍼 파라미터 기준으로 모델 구현 → 분석 모델 배포 → 배포된 모델 관리

② 로지스틱 회귀, 랜덤 포레스트, 서포트 벡터머신, Lasso 회귀, 베이지안, 신경망 모델 등 100+여개의 분석 모델 중 최적 모델 선정

③ 사람이 아닌 기계를 통한 최적화로 모델 구현 공수 70% 감소 효과






Auto ML을 통한 전력사용량 예측


1분석 목표와 범위 : 전력 데이터를 활용한 고객 사용량 예측

공개된 임의의 과거 3년의 전력 사용량을 활용하여 전력사용량을 예측하는 분석 수행을 통해 예측 분석 모델링을 하고자 한다. 계약정보 및 사용량 패턴을 통해 고객별 일별 전력사용량을 예측하는 모델을 구축했다.


2. 분석 결과 및 활용 : 전력사용량 예측 모델 활용

분석한 모델을 웹서버에 배포하여 실시간으로 전략 사용량 예측 가능성을 타진하였고, 가상의 임의의 데이터를 평균값으로 입력 후 전략 사용량을 예측했다.



가상환경 환경 시뮬레이션을 통해 전력사용량을 재계산한 결과 전력 사용량이 174601.56kWh로 변경되었다.



3. AI기반 지능형 전력 빅데이터의 활용
향후 전력 사업 분야에서도 새로운 비즈니스와 가치 창출을 위해 Auto ML을 활용할 것으로 예상하며, AI 기반의 전력 분야에서 자원 및 시설의 효율적인 관리, 문제 및 변칙의 적시 감지, 전력 수요 및 서비스에 대한 효과적인 예측을 위해 빅데이터 및 AI 기술을 활용할 수 있는 지능형 빅데이터 분석 플랫폼이 필요할 것이다.









기고 | 빅데이터사업본부 조치선
편집 | 사업기획팀 박예영








엑기스 | MaxGauge와 카카오톡 연동

기술이야기/엑.기.스 2020. 2. 10. 19:15






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

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

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


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




사용한 기능


1. 카카오 API

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


2. Apache Tomcat

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

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

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


3. HTML

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

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

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

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





현재 구조는 위와 같은 구조로, MaxGauge에서 SMS서버 또는 SMTP서버의 Database에
알람 내용을 포맷된 형태로 Database에 Insert를 해주면 해당 서버가 명시된 담당자에게 알람을 전달합니다. 



카카오API를 사용하면 어떤 구조일까요?


MaxGauge에 알람이 발생하면 DB에 Insert부분까지는 동일하지만, 별도의 서버가 필요하지 않은 구조입니다.
알람 발송 시 DB Insert하는 목적지 DB를 수집서버의 DB내로 지정하게 되면 
굳이 다른 서버에 DB를 구축하지 않아도 카카오 API를 통한 메시지 보내기가 가능합니다.



어떤 차이점이 있나요?


1. 문자나 메일은 발송하기 위한 서버가 있어야 합니다. 

   하지만 카카오API를 사용하여 알람을 전송하게 될 경우, 발송전용 서버를 구성할 필요가 없어집니다.


2. 발송된 알람을 확인하기 위한 접근성이 용이합니다. 

   현재 문자보다 카카오톡을 이용하는 사용자가 증가함에 따라 접근성이 문자보다 편리하며, 

   메일로 발송할 경우 즉각적으로 알람 확인이 불가합니다. 




카카오 API를 통한 기대효과

1. 비용 감소
 - 구축 비용 감소
 - 건당 비용 감소

2. 편의성과 확장성 증가
 - 문자나 메일보다 간편하게 빠른 장애 인지 가능
 - 1:1 실시간 상담 지원
 - MaxGauge 관련 정보 전달 및 기술지원을 다양한 방식으로 전달 (ex.챗봇)



구현 화면 소개

1. 카카오 API의 서비스를 사용하기 위해 카카오 계정으로 로그인


2. 로그인 후, 작동하기 버튼을 클릭하면 Insert된 데이터 값을 가져온 후 API를 통해 전송








※ 위 내용은 실제로 MaxGauge에 구성되어 있는 것은 아닙니다.
실제 고객사 중에서 카카오 비즈앱으로 맥스게이지와 카카오톡을 연동하여 사용하는 곳이 있습니다.
비즈앱을 이용하기 위해서는 사업자등록번호를 통한 인증이 필요하며,
본문에서 사용한 카카오 API는 비즈앱에 있는 기능을 개발자API를 이용해 구현한 것임을 알려드립니다.






기고 | 신기술본부 신대원
편집 | 사업기획팀 박예영