Eventarc는 분리된 마이크로서비스 간에 상태 변경 흐름(이벤트라고 함)을 관리하는 표준화된 솔루션을 제공합니다. 트리거된 Eventarc는 전송, 보안, 승인, 관측 가능성, 오류 처리를 관리하면서 이러한 이벤트를 다양한 대상으로 라우팅합니다.
제한사항
Eventarc용 Firestore 트리거의 다음 제한사항에 유의하세요.
순서는 보장되지 않습니다. 급격하게 변경하면 예기치 않은 순서로 이벤트가 트리거될 수 있습니다.
이벤트는 최소 1회 이상 전송됩니다.
이벤트 핸들러가 멱등성을 갖는지 확인하고 이벤트가 두 번 이상 전송될 때 예기치 않은 결과 또는 부작용이 발생하지 않도록 합니다. 자세한 내용은 멱등 함수 빌드를 참조하세요.
트리거는 단일 데이터베이스와 연결됩니다. 여러 데이터베이스와 일치하는 트리거를 만들 수 없습니다.
데이터베이스를 삭제해도 해당 데이터베이스의 트리거가 자동으로 삭제되지 않습니다. 트리거가 이벤트 제공을 중지하지만 트리거를 삭제하기 전까지 계속 존재합니다. 데이터베이스를 다시 만드는 경우 이벤트 전송을 복원하려면 연결된 트리거도 삭제하고 다시 만들어야 합니다.
Eventarc 및 Firestore 위치
Eventarc는 기본 모드의 Firestore 이벤트 트리거에서 멀티 리전을 지원하지 않지만 멀티 리전 위치에서 Firestore 데이터베이스에 대한 트리거를 만들 수 있습니다. Eventarc는 Firestore 멀티 리전 위치를 다음 Eventarc 리전에 매핑합니다.
Firestore 멀티 리전
Eventarc 리전
nam5
us-central1
eur3
europe-west4
Cloud Run Functions 2세대와 1세대 간의 차이점
Cloud Run Functions (2세대)는 모든 런타임에 Eventarc 이벤트를 사용합니다.
이전에는 Cloud Run Functions (1세대)에서 일부 런타임에만 Eventarc 이벤트를 사용했습니다.
Eventarc 이벤트에는 Cloud Run Functions (1세대)과 다음과 같은 차이점이 있습니다.
Eventarc용 Firestore 트리거는 Cloud Run Functions 외에도 추가 대상을 지원합니다. CloudEvents는 Cloud Run, GKE, Workflows를 포함하되 이에 국한되지 않는 여러 대상으로 라우팅할 수 있습니다.
Eventarc용 Firestore 트리거는 데이터베이스 쓰기 작업이 시작될 때 트리거 정의를 가져오고 이 정의를 사용하여 Firestore에서 이벤트를 내보내야 하는지 결정합니다. 쓰기 작업은 실행 중에 발생할 수 있는 트리거 정의 변경사항을 고려하지 않습니다.
Cloud Run Functions (1세대)는 데이터베이스 쓰기 평가 중에 트리거 정의를 검색하고 평가 중에 트리거 변경사항을 실행하면 Firestore에서 이벤트를 내보낼지 여부에 영향을 줄 수 있습니다.
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-04(UTC)"],[],[],null,["# Create event-driven architectures with Eventarc\n===============================================\n\nYou can use [Eventarc](/eventarc/docs/overview) and\nFirestore to build\n[event-driven architectures](/eventarc/docs/event-driven-architectures).\nFirestore triggers for\nEventarc generate events from changes\nto a particular documents 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) which supports the [Cloud Client Libraries](/firestore/docs/extend-with-functions-2nd-gen) and the [Firebase SDK](https://firebase.google.com/docs/firestore/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\nLimitations\n-----------\n\nNote the following limitations for Firestore 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). If the database is recreated, any associated triggers will also need to be deleted and recreated to restore event delivery.\n\nEventarc and Firestore locations\n--------------------------------\n\nEventarc does not support multi-regions for Firestore in Native Mode 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\nDifferences between Cloud Run functions 2nd gen and 1st gen\n-----------------------------------------------------------\n\nCloud Run functions (2nd gen) uses Eventarc events for all runtimes.\nPreviously, Cloud Run functions (1st gen) used Eventarc events for\n[only some runtimes](/functions/docs/writing/write-event-driven-functions).\nEventarc events introduce the following differences from\n[Cloud Run functions (1st gen)](/firestore/docs/extend-with-functions).\n\n- The Firestore triggers for Eventarc support\n additional destinations besides Cloud Run functions. You can route `CloudEvents`\n to a number of [destinations](/eventarc/docs/event-providers-targets) including,\n but not limited to Cloud Run, GKE, and\n Workflows.\n\n- Firestore triggers for Eventarc retrieve the\n trigger definition at the start of a database write operation and uses\n that definition to decide if Firestore should emit an event. The\n write operation does not take into account any changes to trigger definition\n that might happen as it runs.\n\n Cloud Run functions (1st gen) retrieves the trigger definition during the\n evaluation of the database write, and changes to the trigger during\n evaluation can affect if Firestore emits an event or not.\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)."]]
