엑셈의 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 기술이 근간을 이루면서 학습을 위한 데이터 전처리는 일정 부분 빅데이터 처리 엔진에서 담당해주어야 전체 시스템의 성능을 보장할 수 있게 된다. 이 작업은 앞서 언급한 단순히 저장된 데이터를 빠르게 가져오는 것이 전부가 아니고 디스크나 메모리에서 획득한 데이터의 연산 성능도 영향을 미치게 된다. 가장 좋은 방법은 연산에 필요한 처리 조직을 최적화하여 미리 컴파일해 놓는 방법이지만, 사이트 별로 요구 사항이 다른 상황에서는 각각 자유롭게 대응할 수 있도록 쿼리를 지원하는 것이 좋다. 이는 이미 수십 년 전 데이터베이스가 도입될 때 증명이 된 사실이기도 하다.
<고속 연산을 위한 JIT 쿼리 컴파일 기술, 출처: 로그프레소>
쿼리를 통해 자유도를 높일 경우 개별 쿼리와 함수들을 순차적으로 처리하는 과정에서 반복된 로직이 최적화되지 않은 상태로 진행될 소지가 다분하다. 이러한 폐단은 어느 시스템에서나 발생할 수 있기 때문에 나열된 쿼리를 기계적으로 순차 수행하도록 놔두어서는 안 된다. 그래서 강구해낸 방안이 JIT 쿼리 컴파일 모델이다. JIT 쿼리 컴파일 기술은 쿼리 실행 시점에 코드를 생성하면서 불필요한 조건 분기와 루프로 인한 오버헤드를 모두 제거함으로써, 빅데이터 쿼리 분석을 실행할 때 최상의 성능을 도출하게 된다. 이를 통해 중첩 join과 같은 복잡한 쿼리를 사용해도 최상의 성능을 나타낼 수 있어 AI로 학습데이터를 가공하는 데이터 탐색의 시간을 최소화할 수 있다. 이 기능은 시스템 전반에 적용되기 때문에 summary, 실시간 처리 등에서도 최적화된 쿼리 성능을 보여주게 된다.
XAIOps는 이러한 다양하고 효과적인 기술이 녹아 있는 빅데이터 엔진을 선택하여 대용량의 데이터, 어떠한 상황이 오더라도 빠르고 정확한 결과를 도출할 수 있도록 한다. XAIOps를 통해 IT업계의 한 전기가 마련될 수 있으리라 기대하고 있다.
기고 | 로그프레소 김한도
편집 | 사업기획팀 박예영
'엑셈 경쟁력 > 엑.기.스' 카테고리의 다른 글
| 엑기스 | 엑셈 디자인 가이드 소개 (0) | 2020.11.11 |
|---|---|
| 엑기스 | XAIOps 톺아보기 2 - 엑셈의 기술력이 집대성된 솔루션 (0) | 2020.08.10 |
| 엑기스 | SQL Server) 분할된 테이블에서 효율적으로 통계 관리하기 (0) | 2020.06.08 |
| 엑기스 | InterMax의 변화 (0) | 2020.05.15 |
| 엑기스 | 지능형 전력 빅데이터 예측, AutoML이 답! (0) | 2020.03.13 |
댓글