Eventarc 및 Datastore 모드의 Firestore를 사용하여 이벤트 기반 아키텍처를 빌드할 수 있습니다.
Datastore 모드의 Firestore는 데이터베이스의 특정 항목이 변경될 때 이벤트를 생성하는 Eventarc 트리거를 제공합니다. 트리거는 이벤트를 지원되는 대상으로 라우팅할 수 있습니다.
Eventarc는 분리된 마이크로서비스 간에 상태 변경 흐름(이벤트라고 함)을 관리하는 표준화된 솔루션을 제공합니다. 트리거된 Eventarc는 전송, 보안, 승인, 관측 가능성, 오류 처리를 관리하면서 이러한 이벤트를 다양한 대상으로 라우팅합니다.
사용 사례 예시
이벤트 기반 아키텍처는 서비스가 이벤트로 알려진 상태의 변경사항에 대응하는 시스템 설계 패턴입니다. Firestore 확장성과 함께 이 패턴을 사용해서 앱에 더 많은 기능을 추가할 수 있습니다. 예를 들어 다음 기능을 추가해야 합니다.
서로 다른 기술 스택 간의 상호 운용성
데이터를 복제하고 분석 시스템으로 전송하기 전에 변환
병렬 처리
병렬 처리를 위한 팬아웃 작업. 항목 변경사항을 기반으로 작동하는 여러 시스템이 있는 경우 각 소비자의 내보내기 기반 스트림을 사용하고 이벤트를 여러 소비자에게 라우팅할 수 있습니다.
푸시 기반 이벤트 스트림
내보내기 기반 메시징 설계를 빌드합니다. 클라이언트는 원격 서비스를 폴링하지 않아도 알림을 받을 수 있습니다. 폴링 지연 시간이 없으면 즉시 데이터 처리 및 실시간 분석을 더 잘 수행할 수 있습니다.
상태 모니터링 및 알림
이벤트 기반 아키텍처를 사용하여 데이터베이스 작업에 커스텀 측정항목을 추가합니다. 변경사항 및 업데이트를 모니터링하고 알림을 받습니다. 이상치를 감지합니다.
제한사항
Eventarc용 Datastore 모드 트리거에 대해 다음 제한사항에 유의하세요.
순서는 보장되지 않습니다. 급격하게 변경하면 예기치 않은 순서로 이벤트가 트리거될 수 있습니다.
이벤트는 최소 1회 이상 전송됩니다.
이벤트 핸들러가 멱등성을 갖는지 확인하고 이벤트가 두 번 이상 전송될 때 예기치 않은 결과 또는 부작용이 발생하지 않도록 합니다. 자세한 내용은 멱등 함수 빌드를 참조하세요.
트리거는 단일 데이터베이스와 연결됩니다. 여러 데이터베이스와 일치하는 트리거를 만들 수 없습니다.
데이터베이스를 삭제해도 해당 데이터베이스의 트리거가 자동으로 삭제되지 않습니다. 트리거가 이벤트 제공을 중지하지만 트리거를 삭제하기 전까지 계속 존재합니다.
Datastore 모드의 Eventarc 및 Firestore 위치
Eventarc는 Firestore 이벤트 트리거에서 멀티 리전을 지원하지 않지만 멀티 리전 위치에서 Firestore 데이터베이스에 대한 트리거를 만들 수 있습니다. Eventarc는 Firestore 멀티 리전 위치를 다음 Eventarc 리전에 매핑합니다.
Firestore 멀티 리전
Eventarc 리전
nam5
us-central1
eur3
europe-west4
Datastore 모드 및 Native 모드 이벤트 상호 운용성
Eventarc는 Datastore 모드와 Native 모드의 이벤트 트리거를 지원합니다. 이러한 이벤트 트리거를 두 데이터베이스 유형과 상호 운용할 수 있습니다.
Native 모드 데이터베이스의 Firestore는 Datastore 이벤트를 수신하고 Datastore 모드의 Firestore 데이터베이스는 Native 모드 이벤트를 수신할 수 있습니다.
이벤트 상호 운용성을 사용하면 서로 다른 유형의 Firestore 데이터베이스에서 Eventarc 코드를 공유할 수 있습니다.
이벤트 전환
Datastore 모드 데이터베이스에 Native 모드 이벤트 트리거를 적용하면 Eventarc에서 다음과 같은 변환을 수행합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[[["\u003cp\u003eEventarc and Firestore in Datastore mode enable the creation of event-driven architectures by generating events from database entity changes.\u003c/p\u003e\n"],["\u003cp\u003eEventarc routes events triggered by Firestore changes to various destinations, including Cloud Run, Cloud Run functions (2nd gen), Google Kubernetes Engine, and Workflows.\u003c/p\u003e\n"],["\u003cp\u003eEvent-driven architectures with Eventarc and Firestore offer benefits like interoperability, parallel processing, push-based event streams, and state monitoring with custom alerts.\u003c/p\u003e\n"],["\u003cp\u003eLimitations of Datastore mode triggers for Eventarc include non-guaranteed ordering, at-least-once delivery of events, and triggers being tied to a single database.\u003c/p\u003e\n"],["\u003cp\u003eEventarc supports event triggers for both Datastore mode and Native mode in Firestore, allowing interoperability and code sharing between different database types.\u003c/p\u003e\n"]]],[],null,["# Overview of event-driven architectures with Eventarc\n\nYou can use [Eventarc](/eventarc/docs/overview) and\nFirestore in Datastore mode to build\nevent-driven architectures.\nFirestore in Datastore mode provides triggers for\nEventarc that generate events from changes\nto a particular entity in your database. The trigger can route events to a\n[supported destination](/eventarc/docs/event-providers-targets):\n\n- [Cloud Run functions (2nd gen)](/datastore/docs/extend-with-functions-2nd-gen)\n- [Cloud Run](/eventarc/docs/run/route-trigger-cloud-firestore)\n- [Google Kubernetes Engine](/eventarc/docs/gke/route-trigger-cloud-firestore)\n- [Workflows](/eventarc/docs/workflows/route-trigger-cloud-firestore)\n\nEventarc offers a standardized solution to manage the flow of\nstate changes, called *events*, between decoupled microservices. When triggered,\nEventarc routes these events to\nvarious destinations while managing delivery, security, authorization,\nobservability, and error-handling for you.\n| **Note:** Eventarc events use the [`CloudEvents`](https://cloudevents.io/) specification.\n\nExample use cases\n-----------------\n\nAn event-driven architecture is a system design pattern where services react\nto changes in state known as events. You can use this pattern alongside the\nscalability of Firestore to add more features to your app.\nFor example, you might add the following capabilities:\n\n- Interoperability between different technology stacks\n\n Replicate your data and transform it before sending it to an\n analytics system.\n- Parallel processing\n\n Fan out operations for parallel processing. If you have multiple systems that\n operate based on entity changes, you can use the push-based streams in each\n consumer and route the event to multiple consumers.\n- Push-based event streams\n\n Build push-based messaging designs. Clients can receive notifications without needing to poll remote services. Without the polling latency,\n you can better perform on-the-fly data processing and real-time analysis.\n- State monitoring and alerting\n\n Use an event-driven architecture to add custom\n metrics to your database operations. Monitor and receive alerts on changes and updates. Detect anomalies.\n\nLimitations\n-----------\n\nNote the following limitations for Datastore mode triggers for\nEventarc:\n\n- Ordering is not guaranteed. Rapid changes can trigger events in an unexpected order.\n- Events are delivered *at least* once.\n\n Make sure your event handler is idempotent and avoid producing unexpected results\n or side effects when an event is delivered more than once. Refer to\n [Building idempotent functions](https://cloud.google.com/blog/products/serverless/cloud-functions-pro-tips-building-idempotent-functions) to learn more.\n- A trigger is associated with a single database. You cannot create a trigger that matches multiple databases.\n\n- Deleting a database does not automatically delete any triggers for that database. The\n trigger stops delivering events but continues to exist until you [delete the trigger](/eventarc/docs/managing-triggers#trigger-delete).\n\nEventarc and Firestore in Datastore mode locations\n--------------------------------------------------\n\nEventarc does not support multi-regions for Firestore event\ntriggers, but you can still create triggers for Firestore databases\nin multi-region locations. Eventarc maps Firestore\nmulti-region locations to the following Eventarc regions:\n\nDatastore mode and Native mode event interoperability\n-----------------------------------------------------\n\nEventarc supports event triggers for both Datastore mode and Native\nmode. These event triggers are interoperable with both database types.\nA Firestore in Native mode database can receive Datastore\nevents, and a Firestore in Datastore mode database can receive\nNative mode events.\n\nEvent interoperability lets you share Eventarc code across\nFirestore databases of different types.\n\n### Event conversions\n\nIf you apply a Native mode event trigger to a Datastore\nmode database, Eventarc makes the following conversions:\n\n- The namespace of the entity is stored in the event's `PartitionId` attribute.\n- Embedded entities are converted to Native mode `map` types.\n\nWhat's next\n-----------\n\n- Learn about [event-driven architectures](/eventarc/docs/event-driven-architectures)."]]
