Fleet Engine 및 Fleet 이벤트 참조 솔루션으로 실시간에 가까운 이벤트 생성

지상에서 작동하는 차량의 실시간에 가까운 신호는 여러 가지 면에서 비즈니스에 유용합니다. 예를 들어 비즈니스는 이러한 정보를 사용하여 다음과 같은 작업을 할 수 있습니다.

  • Fleet의 성능을 모니터링하고 잠재적 문제를 조기에 식별
  • 정확한 도착예정시간 및 추적 정보를 제공하여 고객 서비스 개선
  • 비효율성 파악 및 해결을 통한 비용 절감
  • 운전자 행동을 모니터링하고 잠재적 위험을 식별하여 안전을 개선합니다.
  • 운전자 경로 및 일정을 최적화하여 효율성 향상
  • 차량 위치 및 서비스 시간을 추적하여 규정을 준수하세요

이 문서에서는 개발자가 Google Maps Platform의 '모빌리티 서비스'('라스트 마일 차량 솔루션'(LMFS) 또는 '주문형 차량 공유 서비스 솔루션'(ODRD)의 신호를 실행 가능한 맞춤 이벤트로 전환하는 방법을 설명합니다. GitHub에서 제공하는 Fleet 이벤트 참조 솔루션의 주요 개념과 설계 결정도 다룹니다.

이 문서는 다음과 관련이 있습니다.

  • Google Maps Platform의 '모빌리티 서비스' 및 핵심 구성요소 중 하나인 'Fleet Engine'에 익숙한 설계자. '모빌리티 서비스'를 처음 사용하는 경우 필요에 따라 라스트 마일 Fleet 솔루션 또는 주문형 차량 및 배송 솔루션을 숙지하는 것이 좋습니다.
  • Google Cloud에 익숙한 설계자 Google Cloud를 처음 사용하는 경우 Google Cloud에서 스트리밍 데이터 파이프라인 빌드를 미리 읽어보는 것이 좋습니다.
  • 다른 환경 또는 소프트웨어 스택을 대상으로 하는 경우 Fleet Engine의 통합 지점과 주요 고려사항을 이해하는 데 집중하세요. 여전히 적용 가능합니다.
  • Fleet에서 이벤트를 생성하고 활용하는 방법을 살펴보는 데 일반적인 관심이 있는 사용자

이 문서를 마치면 스트리밍 시스템의 주요 요소, 고려사항, Fleet Events 참조 솔루션을 구성하는 Google Maps Platform 및 Google Cloud의 구성요소를 기본적으로 이해할 수 있습니다.

Fleet 이벤트 참조 솔루션 개요

Fleet 이벤트 참조 솔루션은 이동성 고객과 파트너가 Fleet Engine 및 Google Cloud 구성요소를 기반으로 주요 이벤트를 생성할 수 있는 오픈소스 솔루션입니다. 현재 참조 솔루션은 라스트 마일 Fleet 솔루션을 사용하는 고객에게 주문형 탑승 및 배달을 지원합니다.

이 솔루션은 작업 또는 이동과 관련된 특정 데이터의 변경사항을 기반으로 이벤트를 자동으로 생성합니다. 이러한 이벤트를 사용하여 다음과 같은 알림을 이해관계자에게 전송하거나 Fleet에 대한 다른 작업을 트리거할 수 있습니다.

  • 작업 도착 예정 시간 변경사항
  • 작업 도착의 상대적 ETA 변경
  • 작업 도착까지 남은 시간
  • 작업 도착까지 남은 거리
  • TaskOutcome 상태 변경

참조 솔루션의 각 구성요소는 비즈니스 요구에 맞게 맞춤설정할 수 있습니다.

논리 구성요소

다이어그램 : 다음 다이어그램은 Fleet 이벤트 참조 솔루션을 구성하는 대략적인 구성 요소를 보여줍니다.

Fleet 이벤트 개요 및 논리적 구성요소

참조 솔루션에는 다음과 같은 구성요소가 포함됩니다.

  • 이벤트 소스: 기존 이벤트 스트림의 출처입니다. '마지막 마일 Fleet 솔루션' 또는 '주문형 차량 및 배송 솔루션' 모두 Cloud Logging과 통합되어 Fleet Engine RPC 호출 로그를 개발자에게 제공되는 이벤트 스트림으로 전환하는 데 도움이 됩니다. 이것이 소비하는 핵심 소스입니다.
  • 처리: 원시 RPC 호출 로그는 로그 이벤트 스트림을 통해 계산하는 이 블록 내의 상태 변경 이벤트로 변환됩니다. 이러한 변경사항을 감지하려면 이 구성요소에 상태 저장소가 필요합니다. 그러면 새로운 수신 이벤트를 이전 이벤트와 비교하여 변경사항을 감지할 수 있습니다. 이벤트에 관심 있는 모든 정보가 항상 포함되는 것은 아닙니다. 이러한 경우 이 블록은 필요에 따라 백엔드 호출을 조회할 수 있습니다.
    • 상태 저장소: 일부 처리 프레임워크는 자체적으로 중간 데이터를 영구 제공합니다. 하지만 그렇지 않은 경우 상태를 자체적으로 저장하려면 차량 및 이벤트 유형에 고유해야 하므로 K-V 유형 데이터 지속성 서비스가 적합합니다.
  • 싱크 (커스텀 이벤트): 감지된 상태 변경을 활용할 수 있는 모든 애플리케이션이나 서비스에서 사용할 수 있어야 합니다. 따라서 다운스트림 소비를 위해 이 맞춤 이벤트를 이벤트 전송 시스템에 게시하는 것이 당연합니다.
  • 다운스트림 서비스: 생성된 이벤트를 소비하고 사용 사례에 고유한 작업을 수행하는 코드입니다.

서비스 선택

'Last Mile Fleet 솔루션' 또는 '주문형 차량 및 배송 솔루션'(2023년 3분기 말 출시 예정)의 참조 솔루션을 구현하는 경우 '소스'와 '싱크'를 위한 기술 선택은 간단합니다. 반면 '처리'에는 다양한 옵션이 있습니다. 참조 솔루션에서 선택한 Google 서비스는 다음과 같습니다.

다이어그램 : 다음 다이어그램은 참조 솔루션을 구현하는 Google Cloud 서비스를 보여줍니다.

Fleet 이벤트 참조 솔루션 구성요소는

Cloud 프로젝트 레이아웃

기본적으로 다중 프로젝트를 배포하는 것이 좋습니다. 이렇게 하면 Google Maps Platform과 Google Cloud 사용량이 명확하게 구분되고 선택한 결제 방식에 연결될 수 있습니다.

이벤트 소스

'Last Mile Fleet 솔루션' 및 '주문형 차량 공유 및 전송 솔루션'은 API 요청 및 응답 페이로드를 Cloud Logging에 씁니다. Cloud Logging은 선택한 하나 이상의 서비스에 로그를 전송합니다. Cloud Pub/Sub로 라우팅하는 것이 가장 좋은 방법이며 코딩 없이 로그를 이벤트 스트림으로 변환할 수 있습니다.

싱크

Google Cloud에서 Cloud Pub/Sub는 실시간에 가까운 메시지 전달 시스템입니다. 소스의 이벤트가 Pub/Sub에 전달된 방식과 마찬가지로 커스텀 이벤트도 다운스트림 소비를 위해 Pub/Sub에 게시됩니다.

처리

다음 구성요소는 이벤트 처리에서 역할을 합니다. 다른 구성 요소와 마찬가지로 처리 구성요소는 완전한 서버리스 방식이며 확장 및 축소가 원활합니다.

  • 초기 출시용 컴퓨팅 플랫폼으로서의 Cloud Functions (*)
    • 서버리스, 확장 제어로 확장 및 축소하여 비용 관리
    • 프로그래밍 언어로서의 Java
  • 상태 저장소로서의 Cloud Firestore
    • 서버리스 키-값 저장소
  • 업스트림 및 다운스트림 구성요소와의 통합 지점인 Cloud Pub/Sub
    • 느슨하게 결합된 거의 실시간 통합

함수는 기본 설정에서 그대로 사용할 수 있지만 재구성할 수도 있습니다. 구성 매개변수는 배포 스크립트를 통해 설정되며 해당 terraform 모듈 리드미에 자세히 설명되어 있습니다.

*참고: 이 참조 솔루션에서는 다양한 요구사항을 충족하는 데 도움이 되는 대체 구현을 출시할 계획입니다.

Deployment

참조 솔루션 배포 프로세스를 반복 가능하고, 맞춤설정 가능하며, 소스 코드를 제어 가능하고, 안전하게 만들기 위해 Terraform이 자동화 도구로 선택됩니다. Terraform은 널리 사용되는 IaC (코드형 인프라) 도구로, Google Cloud를 풍부하게 지원합니다.

Terraform 모듈

하나의 대규모 모놀리식 참조 솔루션 배포 모듈을 만드는 대신 재사용 가능한 자동화 블록이 독립적으로 사용할 수 있는 Terraform 모듈로 구현됩니다. 모듈은 구성 가능한 다양한 변수를 제공합니다. 대부분의 변수에 기본값이 있으므로 빠르게 시작할 수 있을 뿐만 아니라 요구사항과 환경설정에 따라 유연하게 맞춤설정할 수 있습니다.

참조 솔루션에 포함된 모듈:

  • Fleet Engine 로깅 구성: Fleet Engine과 함께 사용하도록 Cloud Logging 관련 구성을 자동화합니다. 참조 솔루션에서는 Fleet Engine 관련 로그를 지정된 Pub/Sub 주제로 라우팅하는 데 사용됩니다.
  • Fleet 이벤트 클라우드 함수 배포: 샘플 함수 코드 배포를 포함하며 안전한 프로젝트 간 통합에 필요한 권한 설정 자동화도 처리합니다.
  • 전체 참조 솔루션 배포: 앞의 두 모듈을 호출하고 전체 솔루션을 래핑합니다.

보안

IAM은 서비스 계정 가장과 같은 Google Cloud의 보안 권장사항과 함께 최소 권한 원칙을 적용하기 위해 채택되었습니다. 보안을 보다 효과적으로 제어할 수 있도록 Google Cloud가 제공하는 기능을 자세히 이해하려면 다음 문서를 참조하세요.

다음 작업

이제 Fleet 이벤트 참조 솔루션에 액세스하여 자세히 살펴볼 준비가 되었습니다. 시작하려면 GitHub로 이동하세요.

부록

요구사항 수집

프로세스 초기에 요구사항을 수집하는 것이 좋습니다.

먼저 관심이 있거나 실시간에 가까운 이벤트를 사용해야 하는 이유에 대한 세부정보를 캡처하세요. 다음은 니즈를 확인하는 데 도움이 되는 몇 가지 질문입니다.

  • 이벤트 스트림이 유용하려면 어떤 정보가 필요한가요?
    • Google 서비스에서 캡처되거나 생성된 데이터만 결과를 도출할 수 있나요? 또는 통합된 외부 시스템을 통한 데이터 보강이 필요한가요? 그렇다면 이러한 시스템은 무엇이며 어떤 통합 인터페이스를 제공할까요?
    • 비즈니스로서 측정하고자 하는 측정항목은 무엇인가요? 어떻게 정의되나요?
    • 여러 이벤트에서 측정항목을 계산해야 한다면 어떤 종류의 집계가 필요한가요? 논리적인 단계의 레이아웃을 설정합니다. (예: 사용량이 많은 시간에 Fleet의 하위 부문에 걸쳐 SLO와 ETA/ATA를 비교하여 리소스 제약조건 하에서 성능을 계산합니다.)
  • 배치보다는 이벤트 기반 모델에 관심이 있는 이유는 무엇인가요? 짧은 지연 시간 (작업 시간)을 위한 것인가요, 아니면 느슨하게 결합된 통합(민첩성)을 위한 것인가요?
    • 지연 시간이 짧은 경우 '낮음'으로 정의합니다. 몇 분인가요? 초? 1초 미만인가요? 지연 시간은 어느 정도인가?
  • 이미 팀으로 기술 스택 및 관련 기술에 투자한 적이 있나요? 그렇다면 그것은 무엇이며 어떤 통합 지점을 제공합니까?
    • Fleet에서 발생하는 이벤트를 처리할 때 현재 시스템이 충족할 수 없거나 문제가 발생할 수 있는 요구사항이 있나요?

디자인 원칙

따라야 할 사고 과정이 있으면 항상 유용합니다. 이는 특히 다양한 옵션을 선택할 때 일관된 설계 결정을 내리는 데 도움이 됩니다.

  • 기본적으로 더 단순한 옵션으로 설정됩니다.
  • 가치 실현 시간이 더 짧은 것으로 기본 설정됩니다. 코드가 줄어들고 학습 기간이 단축됩니다.
  • 지연 시간과 성능의 경우 최대 최적화가 아니라 설정한 기준을 충족하는 것을 목표로 합니다. 또한 종종 복잡성이 가중되므로 극단적인 최적화는 피해야 합니다.
  • 비용도 마찬가지입니다. 비용을 합리적으로 유지합니다. 가치는 높지만 상대적으로 더 비싼 서비스를 사용하기로 약속한 상태가 아닐 수도 있습니다.
  • 실험 단계에서는 축소가 수직 확장만큼 중요할 수 있습니다. 최대로 수직 확장할 수 있는 유연성을 제공하는 동시에 아무것도 하지 않을 때 비용을 지출하지 않도록 축소 (이상적으로는 0으로)할 수 있는 플랫폼을 생각해 보세요. 상시 사용 설정 인프라를 사용한 고성능은 요구사항 확신이 있을 때 여정의 후반부에 고려할 수 있습니다.
  • 관찰하고 측정하여 나중에 추가 작업을 해야 할 부분을 파악할 수 있습니다.
  • 서비스가 느슨하게 결합된 상태로 유지합니다. 이렇게 하면 나중에 쉽게 조각을 교체할 수 있습니다.
  • 마지막으로, 보안이 느슨해서는 안 됩니다. 퍼블릭 클라우드 환경에서 실행되는 서비스로서, 보안되지 않은 시스템 도어가 존재할 수 없습니다.

스트리밍 개념

이벤트 기반 또는 스트리밍을 비교적 처음 접하는 경우 알아야 할 주요 개념이 있으며 그 중 일부는 일괄 처리와 매우 다를 수 있습니다.

  • 확장 : 일반적으로 처리할 데이터 양을 잘 알고 있는 일괄 처리와 달리 스트리밍에서는 처리할 수 없습니다. 도시의 교통 체증으로 인해 특정 지역에서 갑자기 많은 사건이 발생할 수 있으므로 이를 처리할 수 있어야 합니다.
  • 기간 설정 : 이벤트를 하나씩 처리하는 대신 타임라인에 따라 이벤트를 계산 단위로 더 작은 '기간'으로 그룹화하려는 경우가 많습니다. '고정 기간 (예: 매일)', '슬라이딩 기간 (지난 5분)', '세션 기간 (이 이동 중)'과 같은 다양한 기간 설정 전략 중에서 선택해야 합니다. 이 기간이 길수록 결과 생성이 지연됩니다. 요구사항에 맞는 적절한 모델과 구성을 선택할 수 있습니다.
  • 트리거 : 비교적 긴 기간이 있어야 하는 것 외에 다른 선택의 여지가 없는 경우가 있습니다. 그래도 창 끝에서 이벤트가 생성될 때까지 기다리지 않고 그 사이에 중간 결과를 방출하고 싶을 수 있습니다. 이 개념은 빠른 결과를 먼저 반환한 후 나중에 수정하는 것이 가치 있는 사용 사례에 구현할 수 있습니다. 25%, 50%, 75% 의 전송 완료 시점에 중간 상태를 내보낸다고 가정해 보겠습니다.
  • 순서 지정 : 이벤트가 생성된 순서대로 시스템에 도달하지 않을 수도 있습니다. 특히 모바일 네트워크를 통한 통신과 관련된 사용 사례에 지연과 복잡한 라우팅 경로가 추가됩니다. '이벤트 시간' (이벤트가 실제로 발생한 시간)과 '처리 시간' (이벤트가 시스템에 도달한 시간)의 차이를 알고 적절하게 이벤트를 처리해야 합니다. 일반적으로 이벤트는 '이벤트 시간'을 기준으로 처리하려고 합니다.
  • 메시지 전송 - 최소 1회 및 단 1회: 이벤트 플랫폼마다 지원하는 방식이 다릅니다. 사용 사례에 따라 재시도 또는 중복 삭제 전략을 고려해야 합니다.
  • 완전성 : 순서 변경과 마찬가지로 메시지가 손실될 가능성이 있습니다. 이는 기기의 배터리 수명, 의도치 않은 휴대전화 손상, 터널에서 연결 끊김 또는 수신되었지만 허용 가능한 기간 외에만 발생한 메시지로 인해 애플리케이션 및 기기가 종료되었을 수 있습니다. 불완전성이 결과에 어떤 영향을 미칠까요?

이 목록은 전체 목록이 아닌 소개에 불과합니다. 다음은 각 항목을 더 심층적으로 이해하는 데 도움이 되는 추천 자료입니다.

기여자

이 문서는 Google에서 유지관리합니다. 이 글은 다음 도움을 주신 분들이 처음 작성했습니다.

주요 저자: