운영 분석(Operational Analytics)의 필요성

예측 분석, 머신 러닝 및 운영 인공 지능의 증가뿐만 아니라 실시간 응용 프로그램을 강화하기 위한 스트리밍 분석과 즉각적인 의사 결정의 확산으로 인해 새로운 유형의 데이터베이스 워크로드에 대한 요구 사항 인 운영 분석(Operational analytics)이 도입되었습니다.

​

​

서로 분리된 트랜잭션과 분석의 두 세계는 데이터가 조직의 가장 귀중한 자산이 되기 전의 유물이다. 운영 분석은 최신 기업의 경쟁 우위를 확보하는 데 필수적인 새로운 데이터베이스 요구사항 및 시스템 요구사항입니다.

​

이 새로운 접근법은 "지속적인 분석"이라는 이름으로 2019 년, Top 10 기술로 Gartner에 의해 요구되었습니다 . 운영 분석을 대규모로 제공하는 것은 실시간 대시 보드, 예측 분석, 기계 학습 및 차별화 된 고객 경험의 핵심입니다.

​

그러나 기업들은 기존의 레거시 데이터베이스 아키텍처가 이러한 요구를 충족시키지 못하기 때문에 이러한 새로운 솔루션을 구축하기 위해 애쓰고 있습니다. 기존의 데이터 인프라 스트럭처는 워크로드에 맞게 확장 할 수 없으며 모든 새로운 데이터 소스를 기본적으로 처리하지 않습니다.

​

트랜잭션 기술과 분석 기술 사이의 기술 분리는 운영 능력, 분석 성능 또는 이 둘 모두 결여된 솔루션을 남기는 단점이 있습니다. 이런 가견을 메우기 위해 NoSQL영역에서 많은 시도가 있었지만, 모두 이 새로운 워크로드의 요구를 충족시키지는 못했습니다.

​

운영 분석 기능을 통해 기업은 데이터를 활용하여 생산성을 높이고, 고객과 파트너 참여를 확장하며, 더 많은 동시 사용자 주문을 지원할 수 있습니다. 그러나 이러한 요구사항은 기존 아키텍처를 뛰어넘는 새로운 종류의 데이터베이스 소프트웨어를 필요로 합니다.

​

업계에서는 이러한 시스템을 여러 가지 이름으로 부릅니다. (hybrid transaction and analytics processing (HTAP) from Gartner; hybrid operational/analytics processing (HOAP) from 451 Research; and translytical from Forrester.)

​

컨설팅 회사는 일반적으로 운영 분석이라는 용어를 사용하고, 캡게미니(CapGemini)는 심지어 그 주위에 완전한 운영 분석 컨설팅 프렉티스를 설립하기까지 했습니다.

​

​

운영 분석의 등장

​

운영분석(Operational Analytics)는 기존 OLTP (Online Transaction Processing)과 OLAP (Online Analytical Processing) 워크로드와 함께 등장했습니다. 이전 블로그 항목에서 이러한 워크로드의 요구 사항을 간략히 설명했습니다 .

​

요약하자면, OLTP는 데이터 조회, 트랜잭션성, 가용성, 신뢰성 및 확장성을 필요로 합니다. OLAP에서는 복잡한 쿼리를 매우 빠르게 실행하고 대용량 데이터 셋을 지원하고 대용량 데이터를 배치 수집을 할 수 있도록 지원해야 합니다. OLTP와 OLAP 기반 시스템은 오랜 시간동안 우리에게 좋은 서비스를 제공했습니다. 그러나 지난 몇 년간 상황은 바뀌었습니다.

​

의사 결정에 데이터를 기다릴 필요가 없습니다.

​

비즈니스 결정에 필요한 자료를 얻기 위해 더 이상 다음 분기나 주, 심지어 하루라도 기다리는 것은 용납될 수 없습니다. 기업들은 점점 더 온라인에 접속하고 있습니다; "정비를 위한 시스템 다운"과 "영업 시간"의 구분은 빠르게 과거의 일이 되어가고 있습니다. 실시간 스트리밍 데이터 흐름을 가진 기업은 경쟁사보다 상당한 우위를 점하고 있습니다. 기존의 레거시 분석 시스템은 단순히 이렇게 작동하도록 설계되지 않았습니다.

​

기업은 통찰력 중심이 되어야 합니다.

​

이는 소수의 분석가가 데이터를 쿼리하는 대신 수백 또는 수천 명의 직원이 비즈니스에 대한 정보에 근거한 결정을 내리기 위해 매일 분석 시스템을 접속한다는 것을 의미합니다. 또한, ML/AI 등 자동화된 시스템도 있을 것이며, 현재 세계의 상태가 알고리즘을 공급하도록 쿼리를 실행할 것입니다. 기존의 레거시 분석 시스템은 단순히 이러한 종류의 사용을 위해 설계되지 않았습니다.

​

기업은 통찰력을 바탕으로 고객 경험을 개선해야합니다.

​

기업들은 그들의 데이터를 고객과 파트너에게 공개하기를 원합니다. 이는 고객 경험을 향상시키고 잠재적으로 새로운 기능을 추가 할 수 있습니다. 예를 들어, 한 케이블 회사는 케이블 모뎀에 문제가 있다고 판단을 위해 사용자를 추적해서 선제적으로 케이블 모뎀을 설치합니다. 이를 위해서는 실시간으로 분석하고 대응할 수 있는 시스템이 필요합니다.

​

또 다른 예로는 스마트 TV를 판매하고 있으며 고객들이 어떤 프로그램을 시청하는지 광고주들에게 노출시키고 싶어하는 전자 회사가 있습니다. 이것은 그것의 분석 시스템에 접속하려는 사용자 수를 극적으로 증가시킵니다.

​

또한 고객과 파트너의 경우 가용성과 신뢰성에 대한 기대치가 훨씬 높습니다. 따라서 운영 서비스 수준 계약(SLA)을 이행할 수 있는 시스템이 필요합니다. 파트너는 기업 내부에서 근무하지 않기 때문에 기업 방화벽 외부에 콘텐츠를 노출하고 있으므로 강력한 보안은 필수 사항입니다. 기존의 레거시 분석 시스템은 단순히 이러한 종류의 사용을 위해 설계되지 않았습니다.

​

데이터는 많은 새로운 소스와 다양한 유형 및 형식으로 제공됩니다.

​

수집되는 데이터의 양이 엄청나게 증가하고 있습니다. 기업 내의 운영 시스템에서 수집되는 것일 뿐만 아니라, 엣지 장치에서도 데이터가 수집되고 있습니다. 석유 드릴, 스마트 계량기, 가전 제품, 공장 기계 등의 IoT 장치가 폭발적으로 증가하고 있는 것이 성장의 핵심 요인입니다.

​

이 모든 데이터는 분석 시스템에 입력되어야 한다. 이는 데이터 타입과 포멧(지형공간, JSON, AVRO, Parquet, raw text 등)뿐만 아니라 데이터 소스 유형(Kafka, Spark 등)과 데이터 수집 처리량 요구로 복잡성의 증가로 이어집니다. 다시 말하면, 기존의 레거시 분석 시스템은 단순히 이런 종류의 사용을 위해 설계되지 않았습니다.

​

​

운영 분석의 대두

​

이러한 변화로 인해 새로운 데이터베이스 워크로드인 운영 분석 기능이 생겨났습니다. 운영 분석의 간단한 설명은 운영 SLA가 필요한 분석 워크로드입니다. 이제 어떻게 생겼는지 포장을 풀어보고자 합니다.

​

​

데이터베이스 워크로드로서의 운영 분석

​

운영 분석은 주로 분석 워크로드를 설명합니다. 따라서 쿼리 형태와 복잡성은 OLAP 퀴리와 유사합니다. 또한 운영 분석을 위한 데이터 셋은 OLAP 데이터 셋만큼 크지만, 종종 가장 중요한 최신 데이터기도 합니다. (일반적으로 전체 데이터 집합의 일부분임) 데이터 로딩은 OLAP 워크로드와 유사하며, 외부 소스에서 데이터를 가져와 쿼리를 실행하는 애플리케이션이나 대시보드와 독립적으로 로드된다는 점에서 유사합니다.

​

그러나 운영 분석에는 순수 OLAP 워크로드와 차별화되는 몇 가지 특성이 있습니다. 구체적으로는 데이터 수집 속도, 동시성을 위한 확장성, 가용성, 신뢰성, 쿼리 응답 속도 등을 들 수 있습니다.

​

운영 분석 워크로드에는 데이터 가용 속도에 대한 SLA가 필요합니다. 때로는 이 값이 초 또는 분 단위로 측정되기도 하는데, 이는 데이터 인프라가 쿼리를 실행하는 동안에도 데이터를 지속적으로 스트리밍할 수 있어야 함을 의미합니다.

​

때때로 이것은 모든 데이터를 수집해야 하는 동안 시간의 윈도우(약 한자리 시간)이 있다는 것을 의미합니다. 데이터 셋이 증가함에 따라 기존 데이터 웨어하우스(DW) 기술은 시간 내에 데이터를 로드하는 데 어려움을 겪었습니다( 스트리밍을 허용하지 않습니다). 데이터 엔지니어는 기존 DW 기술로 데이터 로딩 SLA를 지속적으로 충족하기 위해 복잡한 기술을 수행해야 하는 경우가 많습니다.

​

또한 데이터는 과거보다 더 큰 데이터 소스 집합에서 로드되어야 합니다. 과거에는 업무 외 시간에 운영시스템에서 데이터가 배치로 로드 했었습니다. 이제 데이터는 다양한 다른 시스템에서제공이 됩니다.

​

또한, 데이터는 기업 데이터 센터에서 멀리 떨어진 다양한 IoT 장치에서 전송될 수 있습니다. 데이터는 다양한 유형의 기술(Kafka와 같은 인 메모리 큐, Spark 같은 프로세싱 엔진 등)을 통해 라우팅됩니다. 운영 분석 워크로드는 이러한 상이한 데이터 소스의 수집을 쉽게 처리해야 합니다.

​

운영 분석 워크로드도 많은 수의 동시 쿼리로 확장해야 합니다. 데이터 중심으로 고객과 파트너에게 데이터를 노출시키면서 시스템의 동시 사용자 수와 쿼리 수가 급격히 증가했습니다. OLAP 워크로드에서는 한 번에 5~10개의 쿼리가 표준이었습니다. 운영 분석 워크로드는 종종 수십, 수백 또는 수천 개의 동시 쿼리를 처리할 수 있어야 합니다.

​

OLTP 워크로드에서와 마찬가지로 가용성과 안정성 또한 핵심 요구사항입니다. 이러한 시스템은 현재 고객이나 파트너에게 노출되어 있기 때문에 필요한 SLA는 내부 직원보다 훨씬 엄격합니다.

​

고객은 99.9% 이상의 가동 시간과 시스템이 안정적으로 작동할 것으로 기대를 합니다. 또한 계획된 유지 보수 시간에 대한 관대하지 않습니다. 따라서 이러한 시스템을 지원하는 데이터 인프라는 하드웨어와 기타 유형의 장애를 처리할 수 있는 기능을 갖춘 고가용성을 지원할 필요가 있습니다.

​

유지보수 작업(시스템 소프트웨어 업그레이드 또는 데이터 재조정 등)은 시스템 사용자에게 눈에 띄지 않는 투명한 온라인 작업이 필요합니다. 또한, 시스템은 운영자가 문제에 대한 경고를 받고 응답하기를 기다리지 말고 문제가 발생했을 때 스스로 복구해야 합니다.

​

강력한 내구성도 중요합니다. 손실된 데이터는 재로드될 수 있지만, 재로드로 인해 시스템이 가용성 SLA를 위반할 수 있기 때문입니다.

​

찾고있는 데이터를 매우 빠르게 검색할 수있는 능력은 데이터베이스 시스템의 특징입니다. 올바른 데이터에 신속하게 액세스하는 것은 큰 경쟁 우위를 확보하는데 큰 도움이 됩니다. 비즈니스에 대한 통찰력을 얻으려는 내부 사용자이든, 고객에게 분석 결과를 제공하든 관계없이 필요한 데이터를 즉시 사용할 수 있어야 합니다.

​

시스템의 부하에 관계없이 쿼리 속도를 유지할 필요가 있습니다. 온라인에서 사용자 수가 가장 많거나, 데이터 크기가 확대됐거나, 시스템에 장애가 발생했는지는 중요하지 않습니다. 고객들은 모든 퀴리에 대한 그들의 기대를 변명의 여지 없이 충족시키기를 기대합니다.

​

이를 위해서는 어떤 쿼리에 대해서도 적절한 계획을 선택하여 매번 정확하게 파악할 수 있는 견고한 분산 쿼리 프로세서가 필요합니다. 이는 사용되는 알고리즘이 모든 차원에서 증가함에 따라 시스템에 따라 원활하게 확장되어야 함을 의미합니다.

​

​

SingleStore를 통한 운영 분석 활용 사례 지원

​

SingleStore는 단일 통합 시스템에서 이러한 요구 사항을 해결하기 위해 개발되었습니다. SingleStore는 ANSI SQL을 지원하는 분산 관계형 데이터베이스입니다. 그것은 업계 표준 하드웨어에서 잘 작동하는 비공유, 확장형 아키텍처입니다.

​

이를 통해 SingleStore는 머신을 클러스터에 추가하는 것만으로 선형적으로 확장할 수 있습니다. SingleStore는 조인, 그룹화, 집계 등과 같은 표준 OLAP 시스템에서 찾을 수있는 모든 분석 SQL 언어 기능을 지원합니다.

​

자체 확장 메커니즘이있어서 응용 프로그램 요구 사항에 맞는 스토어드프로시저와 함수를 추가 할 수 있습니다. SingleStore는 OLTP 시스템의 핵심 기능인 트랜잭션, 고 가용성, 자가 치유, 온라인 운영 및 강력한 보안을 지원합니다.

​

여기에는 압축 기능과 매우 빠른 집계 쿼리뿐만 아니라 빠른 포인트 쿼리, 집계, 인덱스 등을 지원하는 인 메모리(in-memory) 로우 스토어라는 두 가지 스토리지 하위 시스템이 있습니다. 두 테이블 유형을 하나의 데이터베이스에서 혼합하여 작업 부하에 맞는 최적의 디자인을 얻을 수 있습니다.

​

마지막으로 SingleStore에는 Pipelines라는 네이티브 데이터 처리 기능이있어 다양한 데이터 소스(예 : Kafka, AWS S3, Azure Blob 및 HDFS)에서 데이터를 쉽고 빠르게 가져올 수 있습니다. 단일 통합 시스템에서 제공되는 이러한 모든 기능이 추가되어 운영 분석 워크로드에 대한 최상의 데이터 인프라를 제공합니다.

​

일반적인 용어로 워크로드를 기술하는 것은 약간 추상적이므로 운영 분석이 가장 유용한 특정 사용 사례를 살펴 보겠습니다.

​

포트폴리오 분석

​

금융 서비스에서 가장 많이 사용되는 사례 중 하나는 포트폴리오 분석 입니다. 여러 SingleStore 고객은 엘리트 사용자에게 프리미엄 서비스를 제공하도록 설계된 재무 포트폴리오 관리 및 분석 시스템을 작성했습니다.

​

이러한 엘리트 사용자는 많은 자산을 관리하는 자산 가치가 높은 개인 은행 고객이나 펀드 매니저가 될 수 있습니다. 그들은 수백 또는 수천 개의 포지션을 가진 커다란 포트폴리오를 가질 것입니다. 그들은 애플리케이션의 뷰를 필터링, 정렬 또는 변경하는 순간 순간적으로 새로 고쳐지는 그래픽 디스플레이를 통해 실시간으로 포트폴리오를 분석 할 수 있기를 원합니다. SingleStore의 탁월한 성능 덕분에 대형 포트폴리오의 경우에도 여러 테이블과 차트를 포함하여 실시간 데이터로 전체 화면을 초 단위로 새로 고칠 수 있습니다.

​

이러한 시스템은 특히 시장이 불안정 할 때 시스템을 동시에 공격하는 수백 또는 수천 명의 사용자까지 확장해야합니다. 마지막으로 쿼리 응답 시간에 엄격한 대기 시간 SLA를 제공하는 기능을 손상시키지 않으면서 가장 새로운 시장 데이터를 가져와야합니다.

​

이들은 관련 규정 준수 요구 사항이나 사용자의 신뢰를 위반하지 않고 이 모든 작업을 안전하게 수행해야 합니다. 시장이 기다릴 필요가 없으므로 고 가용성 및 안정성이 핵심 요구 사항입니다. SingleStore는 빠른 데이터 수집, 대규모 동시 사용자 액세스 및 신속한 쿼리 응답의 핵심 요구 사항을 해결하므로 운영 분석의 사용 사례에 이상적인 데이터 인프라입니다.

​

예지 정비

​

우리가 볼 수있는 또 다른 일반적인 사용 사례는 예지 정비입니다. 지속적으로 실행중인 서비스 나 장치를 가지고있는 고객은 문제가있는 경우 최대한 빨리 알기를 원합니다.

​

이것은 비디오를 스트리밍하는 미디어 회사의 일반적인 시나리오입니다. 스트리밍의 품질에 문제가 있는지 파악하여 사용자가 스트리밍을 고칠 수 있기를 원합니다.

이 활용 사례는 에너지 산업에도 있습니다. 에너지 회사는 원격 위치에 장치 (예 : 석유 드릴, 풍력 터빈 등)를 갖추고 있습니다. 이러한 장치의 상태를 추적하고 조정을하면 평생을 연장하고 수백만 달러의 인건비와 장비를 교체하여 장비를 교체할 수 있습니다.

​

핵심 요구 사항은 장치 또는 서비스에 대한 데이터를 스트리밍하고 복잡한 쿼리를 활용하는 ML 형식을 사용하여 데이터를 분석한 다음 해결해야 할 문제가 결과에 표시되면 경고를 보낼 수 있는 기능입니다. 이러한 문제를 파악하는 데 지체가 없다는 것을 확인하기 위해 데이터 인프라는 연중 무휴로 온라인 상태여야 합니다.

​

개인화

​

세 번째 사용 사례는 개인화입니다. 개인화는 고객을 위한 경험을 사용자 정의하는 것입니다. 이 유스 케이스는 소매 웹 사이트를 방문하는 사용자, 온라인 아케이드에서 게임을 하는 사용자 또는 벽돌과 박격포(mortar) 상점을 방문하는 사용자와 같은 여러 가지 카테고리에서 나타납니다.

​

사용자의 활동을 보고 더 중요한 것은 자신에게 매력적인 것을 배우는 능력은 자신의 요구를보다 효율적이고 효과적으로 충족시킬 수있는 정보를 제공합니다. SingleStore 고객 중 하나는 게임 회사입니다. 게임에서 사용자의 활동에 대한 정보를 스트리밍하고, SingleStore의 모델에 대해 결과를 처리하며, 결과를 사용하여 새로운 게임 및 기타 인앱 구매에 대한 사용자 할인을 제공합니다.

​

또 다른 예로는 SingleStore를 사용하여 광고 사용을 최적화하기 위해 서비스 사용을 분석하는 인기있는 음악 배달 서비스가 있습니다. 시스템을 사용하는 데이터의 크기와 직원 수는 조직에 적시에 데이터를 전달하고 데이터를 대화식으로 쿼리할 수있게 하는 것이 어려웠습니다. SingleStore는 데이터를 처리하고 처리하는 능력을 크게 향상시켰으며 사용자가 쿼리 응답 시간을 획기적으로 단축할 수있었습니다.

​

요약

​

운영 분석은 데이터 조회, 트랜잭션성, 가용성, 안정성 및 확장성뿐만 아니라 대규모 데이터 세트 및 빠른 쿼리와 같은 OLAP 워크로드의 분석 요구 사항과 같은 OLTP 워크로드의 운영 요구 사항을 포괄하는 새로운 워크로드입니다.

​

높은 사용자 동시성 및 신속한 처리라는 새로운 요구 사항과 함께 운영 분석 워크로드는 기존 데이터베이스 아키텍처를 지원하거나 일련의 서로 다른 도구를 함께 사용하기가 어렵습니다. 비즈니스가 디지털 변환 과정을 계속 진행함에 따라 점점 더 많은 작업 부하가 이러한 패턴에 부합하고 있으며이를 처리 할 수있는 성능 및 확장 기능을 갖춘 새로운 최신 데이터 인프라 (예 : SingleStore)를 찾고 있습니다.

​

2019 년 4 월 25 일에 게시 됨

---

​

​

​

참고사이트:

- 원문

https://www.singlestore.com/blog/the-need-for-operational-analytics/

The Need for Operational Analytics - SingleStore Blog - MemSQL is Now SingleStore

Operational analytics is a new kind of database workload that has been recognized as a top requirement for IT as a whole. It combines transactional and analytics requirements to meet new demands around streaming, scale, predictions, ML, AI, and more.

www.singlestore.com

​

​

​※ www.a-platform.biz | info@a-platform.biz