Event Sourcing: Implementace auditních záznamů pro robustní a sledovatelné systémy

V dnešním komplexním a propojeném digitálním světě je udržování robustního a komplexního auditního záznamu prvořadé. Není to jen často regulatorní požadavek, ale je to také klíčové pro ladění, bezpečnostní analýzu a pochopení vývoje vašeho systému. Event Sourcing, architektonický vzor, který zachycuje všechny změny stavu aplikace jako sekvenci událostí, nabízí elegantní a výkonné řešení pro implementaci auditních záznamů, které jsou spolehlivé, auditovatelné a rozšiřitelné.

Co je Event Sourcing?

Tradiční aplikace obvykle ukládají pouze aktuální stav dat v databázi. Tento přístup ztěžuje rekonstrukci minulých stavů nebo pochopení série událostí, které vedly k současnému stavu. Event Sourcing se naopak zaměřuje na zachycení každé významné změny stavu aplikace jako neměnné události. Tyto události jsou uloženy v úložišti událostí s možností pouze přidávání (append-only), což tvoří kompletní a chronologický záznam všech akcí v systému.

Představte si to jako účetní knihu bankovního účtu. Místo pouhého zaznamenání aktuálního zůstatku je každý vklad, výběr a převod zaznamenán jako samostatná událost. Opětovným přehráním těchto událostí můžete rekonstruovat stav účtu v jakémkoli časovém bodě.

Proč používat Event Sourcing pro auditní záznamy?

Event Sourcing nabízí několik přesvědčivých výhod pro implementaci auditních záznamů:

• Kompletní a neměnná historie: Každá změna je zachycena jako událost, což poskytuje kompletní a neměnný záznam vývoje systému. Tím je zajištěno, že auditní záznam je přesný a odolný proti neoprávněné manipulaci.
• Časové dotazování: Můžete snadno rekonstruovat stav systému v jakémkoli okamžiku přehráním událostí až do daného bodu. To umožňuje výkonné možnosti časového dotazování pro audit a analýzu.
• Auditovatelnost a sledovatelnost: Každá událost obvykle obsahuje metadata, jako je časové razítko, ID uživatele a ID transakce, což usnadňuje sledování původu a dopadu každé změny.
• Oddělení a škálovatelnost: Event Sourcing podporuje oddělení mezi různými částmi systému. Události mohou být konzumovány více odběrateli, což umožňuje škálovatelnost a flexibilitu.
• Znovu přehratelnost pro ladění a obnovu: Události lze znovu přehrát pro obnovení minulých stavů pro účely ladění nebo pro zotavení z chyb.
• Podpora pro CQRS: Event Sourcing se často používá ve spojení se vzorem Command Query Responsibility Segregation (CQRS), který odděluje operace čtení a zápisu, což dále zvyšuje výkon a škálovatelnost.

Implementace Event Sourcing pro auditní záznamy: Průvodce krok za krokem

Zde je praktický průvodce implementací Event Sourcing pro auditní záznamy:

1. Identifikujte klíčové události

Prvním krokem je identifikovat klíčové události, které chcete zachytit ve svém auditním záznamu. Tyto události by měly představovat významné změny stavu aplikace. Zvažte akce jako:

• Ověření uživatele (přihlášení, odhlášení)
• Vytvoření, úprava a smazání dat
• Zahájení a dokončení transakce
• Změny konfigurace
• Události související s bezpečností (např. změny řízení přístupu)

Příklad: Pro e-commerce platformu by klíčové události mohly zahrnovat "OrderCreated" (ObjednávkaVytvořena), "PaymentReceived" (PlatbaPřijata), "OrderShipped" (ObjednávkaOdeslána), "ProductAddedToCart" (ProduktPřidánDoKošíku) a "UserProfileUpdated" (ProfilUživateleAktualizován).

2. Definujte strukturu události

Každá událost by měla mít dobře definovanou strukturu, která zahrnuje následující informace:

• Typ události: Jedinečný identifikátor pro typ události (např. "OrderCreated").
• Data události: Data spojená s událostí, jako je ID objednávky, ID produktu, ID zákazníka a částka platby.
• Časové razítko: Datum a čas, kdy událost nastala. Zvažte použití UTC pro konzistenci napříč různými časovými zónami.
• ID uživatele: ID uživatele, který událost inicioval.
• ID transakce: Jedinečný identifikátor pro transakci, ke které událost patří. To je klíčové pro zajištění atomicity a konzistence napříč více událostmi.
• ID korelace: Identifikátor používaný ke sledování souvisejících událostí napříč různými službami nebo komponentami. To je zvláště užitečné v architekturách mikroslužeb.
• ID příčiny (Causation ID): (Volitelné) ID události, která způsobila tuto událost. To pomáhá sledovat kauzální řetězec událostí.
• Metadata: Další kontextové informace, jako je IP adresa uživatele, typ prohlížeče nebo geografická poloha. Při shromažďování a ukládání metadat mějte na paměti předpisy o ochraně osobních údajů, jako je GDPR.

Příklad: Událost "OrderCreated" by mohla mít následující strukturu:

{
  "eventType": "OrderCreated",
  "eventData": {
    "orderId": "12345",
    "customerId": "67890",
    "orderDate": "2023-10-27T10:00:00Z",
    "totalAmount": 100.00,
    "currency": "USD",
    "shippingAddress": {
      "street": "123 Main St",
      "city": "Anytown",
      "state": "CA",
      "zipCode": "91234",
      "country": "USA"
    }
  },
  "timestamp": "2023-10-27T10:00:00Z",
  "userId": "user123",
  "transactionId": "tx12345",
  "correlationId": "corr123",
  "metadata": {
    "ipAddress": "192.168.1.1",
    "browser": "Chrome",
    "location": {
       "latitude": 34.0522,
       "longitude": -118.2437
    }
  }
}

3. Zvolte úložiště událostí (Event Store)

Úložiště událostí je centrální repozitář pro ukládání událostí. Mělo by se jednat o databázi s možností pouze přidávání (append-only), která je optimalizována pro zápis a čtení sekvencí událostí. K dispozici je několik možností:

• Specializované databáze pro úložiště událostí: Jedná se o databáze speciálně navržené pro Event Sourcing, jako jsou EventStoreDB a AxonDB. Nabízejí funkce jako streamy událostí, projekce a odběry.
• Relační databáze: Můžete použít relační databázi jako PostgreSQL nebo MySQL jako úložiště událostí. Budete však muset sami implementovat sémantiku pouze pro přidávání a správu streamů událostí. Zvažte použití specializované tabulky pro události se sloupci pro ID události, typ události, data události, časové razítko a metadata.
• NoSQL databáze: NoSQL databáze jako MongoDB nebo Cassandra lze také použít jako úložiště událostí. Nabízejí flexibilitu a škálovatelnost, ale mohou vyžadovat více úsilí k implementaci požadovaných funkcí.
• Cloudová řešení: Poskytovatelé cloudu jako AWS, Azure a Google Cloud nabízejí spravované služby pro streamování událostí, jako jsou Kafka, Kinesis a Pub/Sub, které lze použít jako úložiště událostí. Tyto služby poskytují škálovatelnost, spolehlivost a integraci s dalšími cloudovými službami.

Při výběru úložiště událostí zvažte faktory jako:

• Škálovatelnost: Dokáže úložiště událostí zvládnout očekávaný objem událostí?
• Odolnost (Durability): Jak spolehlivé je úložiště událostí z hlediska prevence ztráty dat?
• Možnosti dotazování: Podporuje úložiště událostí typy dotazů, které potřebujete pro audit a analýzu?
• Podpora transakcí: Podporuje úložiště událostí ACID transakce pro zajištění konzistence dat?
• Integrace: Integruje se úložiště událostí dobře s vaší stávající infrastrukturou a nástroji?
• Náklady: Jaké jsou náklady na používání úložiště událostí, včetně nákladů na úložiště, výpočetní výkon a síť?

4. Implementujte publikování událostí

Když dojde k události, vaše aplikace ji musí publikovat do úložiště událostí. To obvykle zahrnuje následující kroky:

• Vytvořte objekt události: Vytvořte objekt události, který obsahuje typ události, data události, časové razítko, ID uživatele a další relevantní metadata.
• Serializujte událost: Serializujte objekt události do formátu, který lze uložit v úložišti událostí, jako je JSON nebo Avro.
• Připojte událost do úložiště událostí: Připojte serializovanou událost do úložiště událostí. Zajistěte, aby tato operace byla atomická, aby se předešlo poškození dat.
• Publikujte událost odběratelům: (Volitelné) Publikujte událost všem odběratelům, kteří mají zájem ji přijímat. To lze provést pomocí fronty zpráv nebo vzoru publikování-odběr (publish-subscribe).

Příklad (s použitím hypotetické služby EventStoreService):

public class OrderService {

  private final EventStoreService eventStoreService;

  public OrderService(EventStoreService eventStoreService) {
    this.eventStoreService = eventStoreService;
  }

  public void createOrder(Order order, String userId) {
    // ... obchodní logika pro vytvoření objednávky ...

    OrderCreatedEvent event = new OrderCreatedEvent(
        order.getOrderId(),
        order.getCustomerId(),
        order.getOrderDate(),
        order.getTotalAmount(),
        order.getCurrency(),
        order.getShippingAddress()
    );

    eventStoreService.appendEvent("order", order.getOrderId(), event, userId);
  }
}

public class EventStoreService {

  public void appendEvent(String streamName, String entityId, Object event, String userId) {
    // Vytvoření objektu události
    EventRecord eventRecord = new EventRecord(
        UUID.randomUUID(), // ID události
        streamName,  // název streamu
        entityId,   // ID entity
        event.getClass().getName(), // typ události
        toJson(event),  // data události
        Instant.now().toString(), // časové razítko
        userId  // ID uživatele
    );

    // Serializace události
    String serializedEvent = toJson(eventRecord);

    // Připojení události do úložiště událostí (implementace specifická pro zvolené úložiště)
    storeEventInDatabase(serializedEvent);

    // Publikování události odběratelům (volitelné)
    publishEventToMessageQueue(serializedEvent);
  }

  // Zástupné metody pro interakci s databází a frontou zpráv
  private void storeEventInDatabase(String serializedEvent) {
    // Implementace pro uložení události do databáze
    System.out.println("Storing event in database: " + serializedEvent);
  }

  private void publishEventToMessageQueue(String serializedEvent) {
    // Implementace pro publikování události do fronty zpráv
    System.out.println("Publishing event to message queue: " + serializedEvent);
  }

  private String toJson(Object obj) {
    // Implementace pro serializaci události do JSON
    try {
      ObjectMapper mapper = new ObjectMapper();
      return mapper.writeValueAsString(obj);
    } catch (Exception e) {
      throw new RuntimeException("Error serializing event to JSON", e);
    }
  }
}


class EventRecord {
  private final UUID eventId;
  private final String streamName;
  private final String entityId;
  private final String eventType;
  private final String eventData;
  private final String timestamp;
  private final String userId;

  public EventRecord(UUID eventId, String streamName, String entityId, String eventType, String eventData, String timestamp, String userId) {
    this.eventId = eventId;
    this.streamName = streamName;
    this.entityId = entityId;
    this.eventType = eventType;
    this.eventData = eventData;
    this.timestamp = timestamp;
    this.userId = userId;
  }

  // Gettery

  @Override
  public String toString() {
    return "EventRecord{"+ "eventId=" + eventId + ", streamName='" + streamName + '\'' + ", entityId='" + entityId + '\'' + ", eventType='" + eventType + '\'' + ", eventData='" + eventData + '\'' + ", timestamp='" + timestamp + '\'' + ", userId='" + userId + '\'' + '}';
  }
}

class OrderCreatedEvent {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;
    private final String shippingAddress;

    public OrderCreatedEvent(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Gettery pro všechna pole

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "OrderCreatedEvent{" + "orderId='" + orderId + '\'' + ", customerId='" + customerId + '\'' + ", orderDate='" + orderDate + '\'' + ", totalAmount=" + totalAmount + ", currency='" + currency + '\'' + ", shippingAddress='" + shippingAddress + '\'' + '}';
    }
}

class Order {
  private final String orderId;
  private final String customerId;
  private final String orderDate;
  private final double totalAmount;
  private final String currency;
  private final String shippingAddress;

  public Order(String orderId, String customerId, String orderDate, double totalAmount, String currency, String shippingAddress) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
        this.shippingAddress = shippingAddress;
    }

    // Gettery pro všechna pole

    public String getOrderId() { return orderId; }
    public String getCustomerId() { return customerId; }
    public String getOrderDate() { return orderDate; }
    public double getTotalAmount() { return totalAmount; }
    public String getCurrency() { return currency; }
    public String getShippingAddress() { return shippingAddress; }

    @Override
    public String toString() {
        return "Order{" + "orderId='" + orderId + '\'' + ", customerId='" + customerId + '\'' + ", orderDate='" + orderDate + '\'' + ", totalAmount=" + totalAmount + ", currency='" + currency + '\'' + ", shippingAddress='" + shippingAddress + '\'' + '}';
    }
}

5. Vytvořte modely pro čtení (projekce)

Zatímco úložiště událostí poskytuje kompletní historii všech změn, často není efektivní dotazovat se na něj přímo pro operace čtení. Místo toho můžete vytvořit modely pro čtení, známé také jako projekce, které jsou optimalizovány pro specifické vzory dotazů. Tyto modely pro čtení jsou odvozeny ze streamu událostí a jsou aktualizovány asynchronně, jakmile jsou publikovány nové události.

Příklad: Můžete vytvořit model pro čtení, který obsahuje seznam všech objednávek pro konkrétního zákazníka, nebo model pro čtení, který shrnuje prodejní data pro určitý produkt.

Chcete-li vytvořit model pro čtení, odebíráte stream událostí a zpracováváte každou událost. Pro každou událost aktualizujete model pro čtení odpovídajícím způsobem.

Příklad:

public class OrderSummaryReadModelUpdater {

    private final OrderSummaryRepository orderSummaryRepository;

    public OrderSummaryReadModelUpdater(OrderSummaryRepository orderSummaryRepository) {
        this.orderSummaryRepository = orderSummaryRepository;
    }

    public void handle(OrderCreatedEvent event) {
        OrderSummary orderSummary = new OrderSummary(
                event.getOrderId(),
                event.getCustomerId(),
                event.getOrderDate(),
                event.getTotalAmount(),
                event.getCurrency()
        );

        orderSummaryRepository.save(orderSummary);
    }

    // Další obslužné rutiny pro události PaymentReceivedEvent, OrderShippedEvent atd.
}

interface OrderSummaryRepository {
    void save(OrderSummary orderSummary);
}

class OrderSummary {
    private final String orderId;
    private final String customerId;
    private final String orderDate;
    private final double totalAmount;
    private final String currency;

    public OrderSummary(String orderId, String customerId, String orderDate, double totalAmount, String currency) {
        this.orderId = orderId;
        this.customerId = customerId;
        this.orderDate = orderDate;
        this.totalAmount = totalAmount;
        this.currency = currency;
    }
    //Gettery
}

6. Zabezpečte úložiště událostí

Úložiště událostí obsahuje citlivá data, proto je klíčové jej řádně zabezpečit. Zvažte následující bezpečnostní opatření:

• Řízení přístupu: Omezte přístup k úložišti událostí pouze na autorizované uživatele a aplikace. Používejte silné mechanismy ověřování a autorizace.
• Šifrování: Šifrujte data v úložišti událostí v klidu i při přenosu, abyste je ochránili před neoprávněným přístupem. Zvažte použití šifrovacích klíčů spravovaných hardwarovým bezpečnostním modulem (HSM) pro zvýšení bezpečnosti.
• Auditování: Auditujte veškerý přístup k úložišti událostí, abyste odhalili a zabránili neoprávněné činnosti.
• Maskování dat: Maskujte citlivá data v úložišti událostí, abyste je ochránili před neoprávněným zveřejněním. Můžete například maskovat osobně identifikovatelné údaje (PII), jako jsou čísla kreditních karet nebo rodná čísla.
• Pravidelné zálohy: Pravidelně zálohujte úložiště událostí, abyste se chránili před ztrátou dat. Ukládejte zálohy na bezpečné místo.
• Obnova po havárii: Implementujte plán obnovy po havárii, abyste zajistili, že budete moci obnovit úložiště událostí v případě katastrofy.

7. Implementujte auditování a reporting

Jakmile implementujete Event Sourcing, můžete použít stream událostí k generování auditních zpráv a provádění bezpečnostní analýzy. Můžete se dotazovat úložiště událostí, abyste našli všechny události související s konkrétním uživatelem, transakcí nebo entitou. Stream událostí můžete také použít k rekonstrukci stavu systému v libovolném časovém bodě.

Příklad: Můžete vygenerovat zprávu, která zobrazuje všechny změny provedené v profilu konkrétního uživatele za určité časové období, nebo zprávu, která zobrazuje všechny transakce iniciované konkrétním uživatelem.

Zvažte následující možnosti reportingu:

• Zprávy o aktivitě uživatelů: Sledujte přihlášení, odhlášení a další aktivity uživatelů.
• Zprávy o změnách dat: Monitorujte změny kritických datových entit.
• Zprávy o bezpečnostních událostech: Upozorňujte na podezřelou aktivitu, jako jsou neúspěšné pokusy o přihlášení nebo pokusy o neoprávněný přístup.
• Zprávy o shodě s předpisy (Compliance): Generujte zprávy požadované pro shodu s regulatorními předpisy (např. GDPR, HIPAA).

Výzvy spojené s Event Sourcing

Ačkoli Event Sourcing nabízí mnoho výhod, představuje také některé výzvy:

• Složitost: Event Sourcing přidává složitost do architektury systému. Musíte navrhnout strukturu událostí, zvolit úložiště událostí a implementovat publikování a konzumaci událostí.
• Konečná konzistence (Eventual Consistency): Modely pro čtení jsou s streamem událostí konečně konzistentní. To znamená, že může existovat zpoždění mezi tím, kdy událost nastane, a kdy je aktualizován model pro čtení. To může vést k nekonzistencím v uživatelském rozhraní.
• Verzování událostí: Jak se vaše aplikace vyvíjí, možná budete muset změnit strukturu svých událostí. To může být náročné, protože musíte zajistit, aby stávající události mohly být stále správně zpracovány. Zvažte použití technik, jako je „event upcasting“, pro zpracování různých verzí událostí.
• Konečná konzistence a distribuované transakce: Implementace distribuovaných transakcí s Event Sourcing může být složitá. Musíte zajistit, aby události byly publikovány a konzumovány konzistentním způsobem napříč více službami.
• Provozní režie: Správa úložiště událostí a související infrastruktury může přidat provozní režii. Musíte monitorovat úložiště událostí, zálohovat ho a zajistit, aby běželo hladce.

Osvědčené postupy pro Event Sourcing

Chcete-li zmírnit výzvy spojené s Event Sourcing, dodržujte tyto osvědčené postupy:

• Začněte v malém: Začněte implementací Event Sourcing v malé části vaší aplikace. To vám umožní naučit se koncepty a získat zkušenosti předtím, než jej aplikujete na složitější oblasti.
• Použijte framework: Použijte framework jako Axon Framework nebo Spring Cloud Stream ke zjednodušení implementace Event Sourcing. Tyto frameworky poskytují abstrakce a nástroje, které vám mohou pomoci spravovat události, projekce a odběry.
• Pečlivě navrhujte události: Navrhujte své události pečlivě, abyste zajistili, že zachytí všechny potřebné informace. Vyhněte se zahrnutí příliš mnoha informací do událostí, protože to může ztížit jejich zpracování.
• Implementujte „Event Upcasting“: Implementujte „event upcasting“ pro zpracování změn ve struktuře vašich událostí. To vám umožní zpracovávat stávající události i po změně struktury události.
• Monitorujte systém: Pečlivě monitorujte systém, abyste odhalili a předešli chybám. Monitorujte úložiště událostí, proces publikování událostí a aktualizace modelů pro čtení.
• Zpracovávejte idempotenci: Zajistěte, aby vaše obslužné rutiny událostí byly idempotentní. To znamená, že mohou zpracovat stejnou událost vícekrát, aniž by způsobily jakoukoli škodu. To je důležité, protože v distribuovaném systému mohou být události doručeny více než jednou.
• Zvažte kompenzační transakce: Pokud operace selže po publikování události, možná budete muset provést kompenzační transakci, abyste změny vrátili zpět. Například pokud je vytvořena objednávka, ale platba selže, možná budete muset objednávku zrušit.

Příklady použití Event Sourcing v reálném světě

Event Sourcing se používá v různých odvětvích a aplikacích, včetně:

• Finanční služby: Banky a finanční instituce používají Event Sourcing ke sledování transakcí, správě účtů a odhalování podvodů.
• E-commerce: E-commerce společnosti používají Event Sourcing ke správě objednávek, sledování zásob a personalizaci zákaznické zkušenosti.
• Hry: Vývojáři her používají Event Sourcing ke sledování stavu hry, správě postupu hráčů a implementaci multiplayerových funkcí.
• Řízení dodavatelského řetězce: Společnosti v dodavatelském řetězci používají Event Sourcing ke sledování zboží, správě zásob a optimalizaci logistiky.
• Zdravotnictví: Poskytovatelé zdravotní péče používají Event Sourcing ke sledování záznamů pacientů, správě schůzek a zlepšování péče o pacienty.
• Globální logistika: Společnosti jako Maersk nebo DHL mohou používat Event Sourcing ke sledování zásilek po celém světě, zachycujíce události jako „ZásilkaOpuštěnaPřístav“, „ZásilkaDoručenaDoPřístavu“, „ZahájenoCelníŘízení“ a „ZásilkaDoručena“. To vytváří kompletní auditní záznam pro každou zásilku.
• Mezinárodní bankovnictví: Banky jako HSBC nebo Standard Chartered mohou používat Event Sourcing ke sledování mezinárodních peněžních převodů, zachycujíce události jako „PřevodZahájen“, „ProvedenaSměnaMěny“, „ProstředkyOdeslányDoBankyPříjemce“ a „ProstředkyPřijatyPříjemcem“. To pomáhá zajistit shodu s předpisy a usnadňuje odhalování podvodů.

Závěr

Event Sourcing je výkonný architektonický vzor, který může radikálně změnit vaši implementaci auditních záznamů. Poskytuje bezkonkurenční sledovatelnost, integritu dat a odolnost systému. Ačkoli představuje některé výzvy, výhody Event Sourcing často převažují nad náklady, zejména u složitých a kritických systémů. Dodržováním osvědčených postupů uvedených v této příručce můžete úspěšně implementovat Event Sourcing a budovat robustní a auditovatelné systémy.

Další literatura

• Event Sourcing by Martin Fowler
• EventStoreDB
• Axon Framework