[사례 연구, Insite360] SingleStore 내장 파이프라인을 사용하여 클라우드에서 IoT 서비스 제공

Insite360은 연료 관리과 환경 서비스를 위한 완벽한 솔루션입니다. 주유소, 석유 제품/에너지 상품 공급 업체, 유통 업체와 구매자가 사용을 합니다. Insite360은 SaaS (Software as a Service)로 제공되며 전세계 시장의 리더입니다.

---

Insite360은 관련 프로세스 자동화와 지속적인 모니터링을 통해 운영 효율성을 향상시키고 있습니다. Insite360에 내장된 리포팅, 고급 분석과 의사 결정 지원 도구를 사용하여 비용을 절감하고 매출을 늘리며 위험을 줄일 수 있습니다.

​

IT 아키텍처 측면에서 Insite360은 최적 아키텍처를 향한 3 단계 프로세스의 중간에 있습니다. 첫 번째 단계에서는 운영을 클라우드로 옮겼습니다. 두 번째 단계에서는 SingleStore로 분석 속도를 높였습니다. 곧 구현 될 세 번째 단계에서는 기존 분석 작업에 수집과 트랜잭션 처리를 추가하였습니다.

​

Jay Dave는 Insite360 혁신을 위한 비즈니스 인텔리전스(BI) 팀장입니다. 그는 그의 팀이 높은 수준의 혁신을 수행 할 수 있는 기회를 제공하고 SingleStore는 그를 지원하고 있습니다.

​

빠른 연료 이동

​

Insite360은 휘발유와 기타 연료에 대한 연료관리, 관련 비즈니스와 운영 서비스 측면에서 시장의 리더입니다. 미국에서만도 매일 약 4 억 갤런의 휘발유가 일반적인 소매가격으로 판매(매일 10 억 달러)되며 그 가치가 연간 약 4 천억 달러에 이릅니다.

​

Insite360은 휘발유와 관련 연료의 대부분의 주문과 배송을 지원하고, 주유소 편의점에서의 소매업, 백엔드 비즈니스 운영, 배송 예약 등의 연료 공급과 급유를 지원하는 데 사용됩니다.

​

Jay의 설명에 따르면, “연료 라인과 디스펜서에서 센서 데이터를 수집합니다. 데이터는 자동 탱크 게이지(ATG)에 의해 수집되어 클라우드를 통해 Insite360으로 전송됩니다.”

센서 / IoT 데이터는 그림의 유일한 부분이 아닙니다. 석유와 가솔린의 끊임없이 가격 변화와 가용성은 세계에서 가장 중요한 숫자 중 하나입니다. 주유소에 연결된 소매업은 전 세계적으로 식품과 다양한 매출의 큰 부분을 차지하고 있으며 점점 커지고 있습니다. 특히 밀레니얼 세대는 식료품을 구매하기 위해 식료품점보다 주유소를 선호한다고합니다.

​

주유소는 수익성이 낮은 사업이므로 비용을 엄격히 통제해야합니다. 그러나 취급되는 모든 현금과 주요 제품의 변동성은 보안이 강도, 절도, 조직 범죄, 테러와 관련된 지속적인 우려라는 것을 의미합니다.

​

Insite360에는 ATG 경보 관리 팀이 있습니다. 그들은 낮은 비용으로 ATG 장비를 원격으로 모니터링하고 준수 상태를 모니터링하여 현지, 주와 연방 환경 규정을 준수하기 위해 규정 준수 상태를 모니터링합니다. 이 팀의 도움으로 회사는 규제와 관련 비즈니스 문제를 보다 효과적으로 관리 할 수 ​​있습니다. 기술자들은 원격으로 빠르게 많은 경보들을 고칠 수 있고, 다른 경보들에 대해 현장에 기술자를 파견할 수 있습니다.

​

Insite360 경보 관리는 연료 탱크, 디스펜서, 라인 및 기타 소스와 관련된 수천 가지 이상의 경보를 처리합니다. 제어실에 있는 수십 명의 분석가가 모든 경보를 보고 원격으로 문제를 해결하려고 합니다. 그렇지 않은 경우 기술자를 파견하여 문제를 찾아 해결합니다.

​

그래서 Insite360은 항상 모든 소스로부터 즉시 처리되는 모든 데이터를 필요로 합니다. 그리고 그들의 인프라는 빠르게 발전하여 그들이 서비스하는 까다로운 거래에 더 나은 서비스를 제공할 수 있도록 하고 있습니다.

​

단계 1 : PostgreSQL와 Redshift를 통한 클라우드 운영

​

Insite360은 클라우드를 통해 서비스를 제공하는 것이 타당합니다. 고객과 운전자들이 매일 사용하는 연료 펌프와 같은 고객의 IoT "사물"은 전세계에서 가장 멀리 떨어진 곳에 분포되어 있습니다. Insite360은 클라우드를 통해서만 분산된 전 세계 컴퓨팅 인프라에서 필요에 따라 저렴하게 액세스 할 수 있습니다.

​

InSite360을 위한 최초의 클라우드 아키텍처는 클라우드와 사내 데이터 소스를 결합하고 모든 데이터를 AWS에서 호스팅되는 로우(Row) 지향 오픈 소스 데이터베이스인 PostgreSQL로 전송하는 회사가 제공하는 고객 데이터베이스 였습니다. 그런 다음 분석을 위해 데이터를 칼럼 지향적인 AWS Redshift 데이터 웨어하우스로 이동시켰습니다. 마이크로소프트의 Power BI 도구는 Insite360의 최종 고객에게 데이터 시각화를 제공했습니다.

​

기존 아키텍처에는 빅 데이터를 위한 AWS Elastic MapReduce 배치 처리가 포함되었습니다.

 

이 구성은 많은 이점을 제공했습니다. 클라우드 서비스 프로바이더를 위한 데이터베이스 오퍼링은 수십 년 동안 기존의 단일 노드 데이터베이스를 괴롭혔던 확장성 문제를 해결하여 SaaS 오퍼링을 훨씬 더 실용적으로 만들었습니다. 재 프로비저닝이 빠르고 쉽기 때문에 PoC로 부터 클라우드 구축으로의 이동은 매끄럽고 간단했습니다. Insite360처럼 야심찬 제품을 위한 실행 가능한 인프라를 구축하는 것은 상당한 성과였습니다

​

기존 아키텍처는 Insite360이 클라우드에서 효과적으로 작동할 수 있다는 것을 보여주었습니다. 그러나 기존 구성에는 다음과 같은 5가지 주요 문제가 있었습니다.

​

1. 속도

기존 아키텍처는 고객의 기대를 충족 시키기에는 너무 느렸습니다.

​

2. 비용

기존 인프라는 운영 비용도 많이 들었습니다. PostgreSQL에 대한 데이터를 준비하기 위해 일반적인 IoT 빅 데이터에 대해 EMC Elastic MapReduce (EMR)를 실행하는 것은 운영이 복잡하며 한 달에 수 만 달러가 소요될 수 있었습니다. AWS 비용은 최종 고객이 동일한 수준으로 지불액을 증가시키려 하지 않더라도 처리된 데이터 볼륨에 따라 증가가 되었습니다.​

3. 복잡성

Insite360의 기존 클라우드 아키텍처는 변동성이 있는 부분을 가지고 있었는데, 계약 관리자와 회계 담당자는 말할 것도 없고, 각각 다양한 설계자, 개발자, 운영자로부터 전문화된 기술을 필요로 했습니다. 오라클, 온사이트 실행 과 클라우드 내 Postgres 간의 연결과 같은 인터페이스는 DevOps 직원의 지속적인 관리와 공급이 필요했습니다.

​

4. 경직성(Rigidity)

기존 인프라에서 Power BI는 RedShift에 직접 연결되었습니다. 이런 연결 작업은 복잡한 일이었습니다. RedShift는 항상 Column 기반이며 디스크 기반이므로 일부 분석 작업은 Row 기반 테이블에 대해 실행하거나 메모리에 더 많은 데이터를 저장하는 것은 불가능했습니다.

​

5. 거짓 확장성

클라우드 데이터베이스는 실제로 확장 가능한 SQL을 제공하는 것이 아니라 SQL 제품에 내재된 확장성 부족을 다소 원활하게 관리할 뿐이 었습니다. Insite360의 완전한 글로벌 IoT 아키텍처와 같은 진정한 대규모 운영은 설계하기 어렵거나 불가능한 한계와 장애물에 부딪힐 수 있었습니다.

​

6. 클라우드 사업자에 종속

오늘날, 클라우드는 멀티 클라우드를 의미합니다. AWS 서비스에 참여한다는 것은 데이터를 단일 클라우드에 위임하고 직원의 기술을 단일 클라우드에 최적화한다는 것을 의미합니다. Insite360은 시장의 선두주자로서 AWS 서비스에 대한 깊은 의존도를 앗아가는 유연성을 필요로 했습니다.

​

단계 2 : 속도와 단순성을 위한 Kafka 메시징과 SingleStore 기반 분석 활용

​

많은 사용자가 분석에 대해 확장 가능한 컴퓨팅 기능을 위해 SingleStore로 이동했습니다. Insite360도 예외가 아니였습니다. 이들의 현재 아키텍처는 계속 클라우드에서 실행되고 있습니다. 그러나 그것은 새로운 기술을 이용하여 기존 설계에서 2가지를 변경을 했습니다.

​

• 전체적으로 Kafka를 활용

현재의 아키텍처에서 Kafka는 NoSQL과 대부분의 SQL 데이터베이스에서 데이터를 전송하는 메시징 버스로 사용이 됩니다. Python의 배치 프로세싱은 데이터를 새로운 데이터 웨어하우스(DW)에 저장을합니다.

​

• Oracle 데이터용 AWS 데이터베이스 마이그레이션 서비스 활용

3 년 전에 소개된 이 서비스는 원본 데이터베이스에 대한 과도한 운영 부담 없이 원본 데이터베이스를 복제합니다.

​

• ETL과 분석 처리를 SingleStore로 전환

PostgreSQL에서 데이터를 통합하고 ETL 프로세스를 실행하여 이를 RedShift로 가져온 다음 Power BI를 Redshift에 대해 실행하는 대신 새로운 아키텍처는 SingleStore에서 데이터를 통합한 다음 SingleStore에서 Power BI를 직접 실행합니다.

​

새로운 아키텍처는 무거운 짐을 짊어지고 있습니다. SingleStore 데이터베이스는 센서로 부터 Kafka 이벤트로 도착하는 모든 데이터를 수용하고 수백 개의 테이블을 실행합니다. 파이선(Python)은 Kafka 메시지를 처리하고 데이터를 정재해서 새로운 테이블에 넣습니다.

​

새로운 아키텍처는 PCI DSS (Payment Card Industry Data Security Standard)와 기타 데이터 보안 요구 사항을 포함하여 광범위한 요구 사항을 충족해야 합니다.

새로운 아키텍처는 기존 아키텍처에서 발견 된 모든 문제를 해결했습니다.

현재 아키텍처는 Kafka, Python과 SingleStore 파이프라인을 사용하여보다 쉽게 ​​처리 할 수 ​​있습니다.

 

​

새로운 아키텍처는 기존 아키텍처에서 발견 된 모든 문제를 해결했습니다.

​

1. 비용 절감

AWS EMR(Elastic MapReduce)을 24x7로 실행할 필요가 없어져 비용 절감 효과를 크게 얻었습니다.새로운 아키텍처는 SingleStore의 내장 Kafka 파이프라인과 Python을 배치 처리를 위해 사용하며, 처리 비용은 거의 들지 않았습니다.

​

2. 복잡성 감소

PostgreSQL + Redshift의 두 개의 엔진 대신에 SingleStore는 핵심 분석 처리를 하고, 관리와 유지 관리를 단순화시켰습니다.

​

3. 낮은 경직성

Python을 통해 처리 된 대부분의 데이터 소스를 모두 단일 스트림 Kafka 메시지로 가져 오는 동시에 아키텍처를 보다 유연하고 간단하게 만들었습니다.

​

4. 더 빠른 속도

현재의 아키텍처가 훨씬 더 빠릅니다. 이동하는 부분이 적어서 병목 현상을 발견하고 해결하는 것이 훨씬 쉬워졌으며, SingleStore는 매우 빠른 분석 엔진으로서의 역할을 훌륭히 해냈습니다.

​

5. 높은 확장성

Kafka와 SingleStore는 둘 다 완벽하게 확장이 가능합니다. Oracle 구성 요소는 스케일 아웃이 불가능했습니다.

​

6. 클라우드 사업자에 낮은 종속도

현재 아키텍처에서 많이 사용되는 AWS 전용 서비스는 AWS 데이터베이스 마이그레이션 서비스뿐입니다. 이와 같이, 새로운 아키텍처는 다른 클라우드, 온프라미스나 혼합 아키텍처로 옮겨져서, Insite360에 훨씬 더 많은 유연성과 모든 클라우드 제공자와의 협상력을 제공할 수 있게 되었습니다.

​

SingleStore의 이점 외에도 Kafka는 전체 아키텍처의 중요한 부분입니다. Jay가 말하길 "모든 센서와 IoT 데이터는 ATG에서 Kafka를 사용하여 전송됩니다,그러니까 Kafka 파이프라인은 SingleStore의 아주 반가운 기능이야. 그것은 우리가 AWS EMR 관리에서 벗어나는 것은 쉬운 일이 아닙니다. AWS EMR을 실행하지 않으면 한 달에 수만 달러를 절약할 수 있습니다."

몇 달 전, Insite360은 S3 데이터베이스를 SingleStore로 백업할 수 있는 기능이라는 새로운 기능을 활용하기 시작했습니다. 이 회사는 이미 여러 번의 백업과 복구 작업을 수행했으며, 데이터베이스와 Kafka 이벤트에도 "훌륭하게 작동합니다"라고고 말하고 있습니다.

​

클라우드 애플리케이션은 마이크로 서비스 아키텍처(MSA)를 기반으로하며 각 마이크로 서비스는 자체 데이터 저장소를 사용합니다. 모든 데이터는 Kafka를 통해 라우팅되어 SingleStore의 테이블로 이동 한 다음 고객은 Power BI를 통해 데이터 시각화를 위한 분석을 실행합니다. Insite360은 경보와 규정 준수 데이터에 대한 경보 관리와 NLP(자연 언어 처리)를 위해 SingleStore 데이터에서 머신러닝을 수행합니다.

​

내부 고객에는 상품팀, 마케팅, 영업과 회사 내의 다른 그룹이 포함이 됩니다. 외부 고객은 주유소입니다. Power BI의 최신 정보를 사용하여 스테이션 운영과 유지 관리에 대한 정보에 근거한 결정을 내릴 수 있습니다.

​

단계 3 : 최고의 단순성을 위해 SingleStore 파이프라인 활용

​

트랜잭션과 분석을 분리해야 하는 필요성은 SingleStore와 같은 NewSQL 데이터베이스에 비해 Oracle과 같은 기존 SQL 데이터베이스의 프로세싱 제한으로 부터 기인된 잘못된 부산물에 불과합니다. 그러나 우리는 수십 년에 걸쳐 생각과 기대는 기존 아키텍처에 길들어졌습니다. OLTP 데이터베이스를 가지고 ETL 프로세스를 거쳐 OLAP 데이터베이스를 공급하는 모델은 표준으로 채택되어 왔습니다.

​

결과적으로, SingleStore 구현은 보통 두 단계를 거칩니다. 첫 번째 단계에서 OLTP나 OLAP 중 하나가 문제가 되기 시작했거나 이미 문제가 된 곳에 높은 성능과 확장성을 제공하는 SingleStore가 기존 시스템을 보강하거나 교체하는 데 사용됩니다.

​

그 후, 조직은 SingleStore의 강점에 더 익숙해집니다. 특히, 그것은 SingleStore와 그것의 파이프라인 기능이 OLTP와 OLAP 사이의 장벽을 무너뜨릴 수 있다는 것을 깨닫습니다. SingleStore는 동시에 트랜잭션을 처리하고 데이터를 변환하며 쿼리에 응답할 수 있습니다.

​

일단 이 깨달음이 자리잡게 되면, 근본적으로 단순한 아키텍처은 스스로를 제한하게됩니다. 기존의 ETL 구조 전체를 SingleStore로 옮길 수 있으며, ETL은 다음과 같은 3단계로 작동이 됩니다.

​

• Extract

SingleStore 파이프라인(Pipeline)의 원래 목적은 데이터를 빠르게 추출하고 소스 데이터베이스에 최소한의 로드로 처리하는 것입니다.

• Transform

단순 변환은 SingleStore 파이프라인 내에서 처리할 수 있습니다. 새로운 SingleStoreL 기능인 "Pipeline to Stored Procedures"는 더욱 복잡한 변환 단계를 가능하게 합니다.

• Load

파이프라인의 데이터는 SingleStore에 직접 로드되며 업데이트된 데이터에 대한 분석 쿼리는 지속적으로 실행됩니다.

차세대 아키텍처는 훨씬 더 간단하고 빠르며 관리하기 쉽습니다

 

​

Insite360은 획기적으로 단순한 아키텍처를 구현하여 이점을 얻을 준비를 하고 있으며, 여기에는 다음과 같은 7가지 매우 바람직한 특성이 포함이 됩니다.

​

• 최신 데이터

새로운 아키텍처에서는 배치 처리가 배제됩니다. 배치 처리를 중단하고 통합된 트랜잭션과 분석을 활용하면 분석이 항상 현재 데이터에 대해 실행된다는 것을 의미합니다.

​

• 속도 조절

트랜잭션 처리와 분석 속도는 SingleStore용 프로세서를 더 많이 사용하여 필요에 따라 쉽게 조절 할 수 있습니다.

​

• 최저 비용

SingleStore 가격 대비 성능은 트랜잭션이나 분석에 있어 탁월합니다. 단일 SingleStore 데이터베이스에 트랜잭션과 분석을 결합하면 비용이 더욱 절감이 됩니다.

​

• 궁극의 단순성

단일 데이터베이스에서 표준화하고 데이터를 가져오고 변환하기 위한 일관된 프로세스에 따라 아키텍처가 매우 단순해지고 운영 인력의 부담이 감소됩니다.

​

• 최고의 유연성

모든 데이터 소스는 SingleStore Pipeline의 유연성과 스토어드 프로시저의 처리 능력 때문에 핵심 프로세싱과 분석 아키텍처를 변경하지 않고도 추가할 수 있습니다. 또한 SingleStore의 SQL 지원으로 인해 분석 툴을 사용할 수 있습니다.

​

• 완벽한 확장성

완전히 확장 가능한 동일한 엔진에서 트랜잭션 처리와 분석 지원을 실행하면, 확장의 문제는 오직 하드웨어 이슈로 남게 됩니다.

​

• 클라우드 벤더에 No 종속성

모든 클라우드나 온프라미스에 SingleStore를 설치하고 언제든지 호스팅 업체를 변경할 수 있습니다. 클라우드 벤더별 서비스를 데이터 소스나 분석 측면으로 사용할 경우, 핵심에 유연성이 있기 때문에 종속성은 전략적이라기보다는 전술적인 것될 것입니다.

​

• 머신러닝과 AI 친화적

데이터는 최신이고 하드웨어를 추가하면 병목 현상을 제거할 수 있으며, 필요에 따라 더 많은 데이터 소스를 추가할 수 있기 때문에, 머신러닝 프로그램과 AI는 항상 필요한 최신의 모든 데이터를 확보할 수 있습니다.

​

Insite360의 다음 단계

​

Insite360은 앞으로 몇 달 안에 획기적으로 간소화된 새로운 아키텍처로 옮겨갈 것입니다. 기존 클라우드 인프라와 비교하면 비용은 대략 반으로 줄어들 것으로 예상이 됩니다. 시스템을 운용하는 데 필요한 인원도 대략 절반으로 줄여서 기존보다 훨씬 더 기능적인 시스템을 운영하게 될 것입니다.

​

이 새로운 기능들이 이점을 가져다 줄 한 가지 분야는 머신러닝과 AI의 능력을 향상시키는 것입니다. "머신 러닝과 AI는 더 많은 데이터를 통합하는데 더 효과적입니다,"라고 Jay는 말합니다. Insite360은 연료 손실과 같은 문제를 해결하기 위해 고급 분산 분석을 사용합니다. 예를 들어, 만약 50갤런의 연료가 수천 갤런의 연료 중 누락된 경우, 그것은 도난, 오버 펌핑이나 누출과 같은 다양한 원인에 기인할 수 있으며, 이는 몇 개의 다른 위치에서 발생할 수 있습니다. 일단 데이터가 SingleStore에 있으면, Insite360은 머신러닝과 AI를 사용하여 운영자가 어디에서 먼저 문제를 찾을 것인지 우선순위를 정할 수 있습니다.

​

기본 아키텍처를 개선하는 것은 최종 고객에게도 긍정적인 일입니다. 그들은 더 빨리 더 나은 결과를 얻습니다. 또한, 그들은 데이터가 어떻게 시스템에 들어오고, 통과하고, 어떻게 밖으로 나오는지 쉽게 이해할 수 있습니다. 이는 결과에 대한 신뢰도와 시스템을 효과적으로 사용할 수 있는 능력을 높입니다.

​

관련된 모든 사람들은 이러한 혜택과 더 많은 것을 기대하고 있습니다. 이 조직은 정말로 "하나의 돌로 세마리의 새를 잡는 효과를 보고 있습니다."-SingleStore.

​

 

December 17, 2018

​

Floyd Smith

 

---

출처: ttps://www.singlestore.com/blog/case-study-insite360-memsql-iot-cloud/

Case Study-Insite360 Uses SingleStore Pipelines to Deliver IoT in the Cloud

​

​

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