Salesforce가 Thunder IoT 클라우드를 위해 오픈 소스로 전환한 방법

  • Oct 23, 2023

Salesforce의 사물 인터넷 클라우드는 4가지 주요 오픈 소스 빅 데이터 플랫폼을 기반으로 구축되었습니다. IoT 클라우드를 뒷받침하는 플랫폼인 Thunder의 백엔드가 제공해야 했던 내용은 다음과 같습니다.

Salesforce의 사물 인터넷(IoT) 클라우드를 뒷받침하는 확장 가능한 처리 엔진인 Thunder는 완료하는 데 약 1년이 걸렸으며 빅 데이터 분석에 사용되는 4개의 오픈 소스 플랫폼으로 구동됩니다.

더 많은 Salesforce

  • 로우 코드 오케스트레이션을 사용하여 '허무한 IoT 프로젝트' 저장
  • Einstein AI 플랫폼은 맞춤형 분석 및 챗봇을 제공합니다.
  • Salesforce, 로우 코드 모바일 앱 개발 도구 출시
  • Lightning 업데이트로 더욱 맞춤화된 앱 개발 가능
  • Quip 협업 플랫폼은 실시간 문서에서 팀워크를 확장합니다.
  • 맞춤형 콘텐츠 및 브랜딩이 Trailhead 기업 학습 플랫폼에 제공됩니다.

Salesforce의 수석 부사장인 Adam Bosworth는 Thunder가 데이터를 처리하는 방법에 대한 개요를 제공했습니다. 여러 장치와 끝점에서 들어오는 데이터를 Salesforce 사용자에게 표시합니다. 상호 작용. Salesforce에 합류하기 전에 Bosworth는 Keas의 창립자이자 CEO였습니다. Google Docs를 구축 및 관리하고 Google Health를 운영한 임원; Access, XML 및 Microsoft 커뮤니티와 같은 프로젝트를 진행하는 Microsoft의 총괄 관리자입니다. 그는 또한 BEA Systems의 수석 소프트웨어 설계자였으며 BEA에 매각된 Crossgain을 공동 창립했습니다.

간단히 말해서 Bosworth는 큰 것을 만드는 데 익숙합니다. Bosworth는 인터뷰에서 "우리는 적극적으로 참여하는 애플리케이션을 구축하기 위한 플랫폼이 필요했습니다."라고 설명했습니다. Bosworth는 IoT로의 전환이 웹과 모바일로의 전환만큼이나 기본적이라고 주장합니다. 사람들은 사물이 모니터링되어 유용하고 관련성 있는 정보를 제공하기를 기대합니다.

고객 측에서는 연결된 장치를 통해 더 나은 서비스를 제공하고 적극적이며 참여도를 높일 수 있습니다. 꿈은 고객이 문제가 있다는 것을 깨닫기도 전에 문제가 해결되는 것입니다."라고 Bosworth는 말했습니다. Salesforce의 기회는 분명합니다. 자동화되고 사전 예방적이며 지능적인 서비스를 실시간으로 제공할 수 있는 기업은 거의 없습니다. Salesforce가 해당 계층을 추상화하여 기존 서비스에 구축할 수 있다면 앞으로 많은 성장이 있을 것입니다.

Bosworth는 IoT가 고객 관계를 어떻게 변화시킬 것인지에 대한 다양한 사례를 제시했지만 그 중 상당수는 이론적인 것이었습니다. 아마존이 아내의 생일 선물이 파손되었을 때 어떻게 처리했는지에 대한 일화만이 오늘날의 실제 사례를 보여줍니다. 간단히 말해서, 보스워스 아내의 생일 선물이 손상되어 아마존은 즉석에서 새 선물을 재배송하고 사과하는 메모를 보냈습니다. "아마존은 방금 문제를 해결했습니다. 인간에게는 그렇게 할 수 없었습니다. 소프트웨어는 고객의 평생 가치를 인식하고 재고를 확인한 후 이를 나에게 전달하는 가장 빠른 방법을 선택했습니다."라고 Bosworth는 말했습니다. "우리 고객은 Amazon처럼 구축할 수 없기 때문에 고객이 해당 애플리케이션을 쉽게 구축할 수 있도록 해야 합니다."

아담 보스워스

IoT 클라우드의 기본 원칙은 개발자와 비즈니스 사용자 모두가 플랫폼에서 가치를 얻을 수 있도록 Salesforce가 백그라운드 기술에 대한 무거운 작업을 수행해야 한다는 것입니다. "비즈니스 사용자는 시스템을 직접 사용자 정의, 확장 및 수정할 수 있습니다. ROI는 비즈니스 사용자가 엔지니어링 팀으로 돌아갈 필요가 없기 때문에 존재합니다."라고 Bosworth는 말했습니다.

Thunder를 구축하기 위해 Bosworth의 계획은 빅 데이터에 사용되는 검증된 오픈 소스 기술을 사용하고 Salesforce를 플랫폼의 사용자 인터페이스로 사용하는 것이었습니다. 사용자 인터페이스 빌드 또는 라스트 마일 배송 문제를 제거함으로써 Salesforce는 Thunder를 더 빠르게 출시할 수 있었습니다. Thunder의 4가지 기본 기술은 다음과 같습니다.

  • 불꽃, Hadoop 및 MapReduce보다 빠르게 설계된 대규모 데이터 처리를 위한 일반 엔진입니다.
  • 폭풍, 데이터 스트림을 처리하는 오픈 소스 분산 실시간 계산 시스템입니다. Storm은 처음에 Twitter에서 기여했습니다.
  • 카프카, 초당 메가바이트의 읽기 및 쓰기를 처리할 수 있는 Apache 프로젝트 및 메시징 브로커입니다. 카프카는 LinkedIn에서 나왔습니다.
  • 카산드라는 Apple, Instagram, Netflix와 같은 기업에 배포되는 확장성이 뛰어난 오픈 소스 데이터베이스입니다. Cassandra는 NoSQL보다 성능이 뛰어난 것으로 알려져 있습니다.
  • Salesforce의 Platform-as-a-Service인 Heroku입니다.

Bosworth는 IoT 데이터가 폭발적으로 증가하고 있다고 말했습니다. IoT 이전에는 활성 고객이 100개의 이벤트를 생성할 수 있지만 "대부분의 회사에는 활성 고객이 그렇게 많지 않습니다." 오늘날 장치는 5초마다, 하루에 20,000번 ping할 수 있습니다. 이전보다 100~1000배 더 많은 흥미로운 것들이 들어오고 있습니다.

이러한 이벤트는 필요한 규모를 강조합니다. IoT 클라우드는 하루에 수십억 개의 이벤트를 수신한 다음 실행 가능한 것이 아닌 것으로 정제해야 합니다. 문제: 빅 데이터 로그는 그 자체로는 실행 가능하지 않지만 신속하게 인텔리전스로 정제되어 고객 프로필을 업데이트할 수 있는 경우에만 유용합니다. 고객이 무엇을 하고 있는지에 대한 실시간 프로필이 있어야 합니다.

모든 것이 순조롭게 진행된다면 Salesforce 플랫폼은 이벤트를 추출하고 중요한 변경 사항을 표시하며 즉각적인 문제에 대한 실시간 응답을 제공할 수 있습니다. 발생한 상황에 따라 Thunder는 실시간 로직을 추가해야 했습니다. Bosworth는 "로직은 애플리케이션의 일부이며 컨텍스트 프로필 데이터와 결합되어 작성하기 쉽습니다."라고 말했습니다.

Thunder는 다음을 수행해야 했습니다.

  1. 듣고 소화하십시오.
  2. 논리를 적용하십시오.
  3. 적극적으로 참여하세요.

확장 가정에서는 고객당 테라바이트의 데이터가 있을 수 있다는 것입니다. CRM은 사람이 아닌 도움을 받는 방식으로 변화하고 있습니다. Bosworth는 "모든 것이 확장되어야 했고 Thunder는 대규모 확장이 가능한 ESB(Enterprise Service Bus)여야 했습니다."라고 말했습니다.

아키텍처에 관한 한 Bosworth는 Thunder가 다음과 같은 방식으로 정보를 처리한다고 말했습니다.

  • 어디에서나 들어오는 이벤트는 Kafka에 덤프됩니다.
  • Spark는 Kafka에서 프로필 데이터를 가져와 몇 분 안에 프로필 업데이트를 위해 Cassandra에 넣습니다.
  • Storm은 Kafka에서 데이터를 가져와 실시간 이벤트를 처리하는 논리를 작성합니다.
  • 모든 기술은 Salesforce의 클라우드 애플리케이션 플랫폼인 Heroku에서 실행됩니다.

IoT 클라우드를 비즈니스 사용자에게 유용하게 만들기 위해 Bosworth 팀은 Storm 위에 또 다른 코드 계층을 작성했습니다. Bosworth는 이러한 코드 계층을 통해 "단순한 인간이 지능적인 논리를 작성하여" 이벤트를 처리할 수 있다고 말했습니다. 이 논리는 처리 가능한 이벤트, 기간, 프로필 변경 사항 및 기타 항목을 중심으로 진행됩니다.

또한 Thunder는 IoT 데이터를 궁극적으로 앱에 추가할 수 있도록 Salesforce의 Heroku 개발자 플랫폼에 연결해야 했습니다.

결국 Bosworth는 Thunder 프로젝트가 "Salesforce를 UI로 사용함으로써 큰 ​​이점"을 얻었다고 말했습니다. "우리는 데이터를 Service Cloud로 가져오기 위해 로직을 작성할 필요가 없었습니다. 우리는 서비스 클라우드 내부에 올바른 개체를 가져와야 했습니다."라고 Bosworth는 말했습니다. "사용자 참여 측면을 작성해야 했다면 프로젝트에 2년이 더 걸렸을 것입니다."