イベント駆動カーネル

イベント駆動カーネルとは

Event-Driven Core （EDC）はアーキテクチャの「背骨」であり、ビジネスの事実は不変イベントとしてキャプチャされ配布され、残りの機能（読み取り、統合、分析、キャッシュ、通知）はこれらのイベントのフローの上に構築されます。カーネルはイベントコントラクト、配信ルール、およびorder/idempotency不変量を設定し、弱い接続性とスケーラビリティを提供します。

主なアイデア：最初に事実（コア）を書き留めてから、独立して豊かにし、希望するモデルに投影します。これにより、接続性が低下し、部分的な障害に対する回復力が向上します。

EDCの目標とプロパティ

事実の真実：それぞれの出来事は「何が起こったか」の不変の記録です。
弱い接続性：生産者は消費者を知らない。システム拡張-加入者を追加することによって。
スケーリング：パーティー/トピック、独立した消費者による水平成長。
オブザビリティと監査：エンドツーエンドの識別子、再現性、リテンションおよびリプレイ。
管理された進化：スキーマバージョン、互換性、非推奨。

建築部品

1.バス/イベントブローカー：Kafka/NATS/Pulsar/SNS+SQS-チャネル、パーティー、リテンション。
2.スキーマレジストリ：互換性と進化のためのJSON スキーマ/Avro/Protobuf。
3.Outbox/CDC contour：「double write」なしでatomic fact fixing+publishing。
4.投影/読み取り（CQRS）：クイッククエリの実体化ビュー。
5.Sagas/Orchestration：イベント/チームを通じた長期にわたるプロセスの調整。
6.エンリッチメント：クリティカルパスに影響を与える個々のトピック'。enriched'/'。derived'。
7.オブザビリティ：トレース、ロギング、イベントやラグによるメトリクス。

イベントモデル

イベントタイプ

ドメインイベント：ビジネス事実（'支払い。認可された'、'kyc。「承認されました」）。
統合イベント：外部システムに焦点を当てています（安定していて、ゆっくりと変化しています）。
変更データキャプチャ（CDC）：レコードの技術的な変更（移行/統合に使用）。
監査/テレメトリー：アクターアクション、セキュリティ、SLA。

必須属性（コア）

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

推奨事項：'event_id'はグローバルに一意であり、'partition_key'はエンティティの順序を設定し、'trace_id'は相関を提供します。

配信セマンティクスとidempotency

少なくとも1回（多くのブローカーのデフォルト）：消費者は独自性が必要です。
At-most-once：セカンダリ・テレメトリーでのみ使用できます。
正確に一度：トランザクション/idempotentキー/ウォータリング缶を介してフローとストレージレベルで達成（より高価で、十分な理由が必要）。

消費者の独自性パターン

「event_id」/「（event_id、 consumer_id）」でTTL ≥トピックを保持するテーブルをデダップします。
挿入の代わりにUpsert；'sequence'/'occuled_at'によるプロジェクションのバージョン管理。
トランザクション内のトランザクション：マーク「saw」+状態の変更。

注文とパーティショニング

パーティー内の保証注文。
同じ集計エンティティのすべてのイベントが同じバッチ（'user_id'、 'payment_id'）になるように'partition_key'を選択します。
「ホットキー」を避ける：負荷を分散する必要がある場合は、塩/サブキーでハッシュします。

スキームと進化

Additive-first：新しいオプションフィールド、メジャーバージョンなしでのタイプ/セマンティクスの変更の禁止。
互換性：スキーマレジストリのBACKWARD/FORWARD；CIは互換性のない変更をブロックします。
名前：'ドメイン。アクション。v {major}'（'支払い。承認されました。v1'）。
マイグレーション：ペア'v1'と'v2'を並列にパブリッシュし、出力ボックスを介してデュアル書き込みを提供し、遷移後に'v1'を撮影します。

CDCアウトボックス

アウトボックス（トランザクションサービスに推奨）

1.1つのデータベーストランザクションで、ドメインレコードとイベントをアウトボックスに保存します。
2.バックグラウンドパブリッシャーはアウトボックスを読み取り、ブローカーに公開し、「送信」をマークします。
3.保証：落下の事実の「損失」、非同期。

CDC（変更データキャプチャ）

既存のシステム/移行に適しています。source-DBレプリケーション・ログ。
ドメインイベントへのフィルタリング/トランスコードが必要です（rawテーブルを外部に変換しないでください）。

CQRSと投影

コマンドは（しばしば同期的に）状態を変更し、イベントは（非同期に）投影を形成します。
投影は、契約者によって更新されたクエリ（検索、リスト、レポート）のために設計されています。
一時的な非同期は標準です：安定したUXを表示します（「データは数秒で更新されます」）。

Sagas： プロセスコーディネート

オーケストレーション：1人のコーディネーターがコマンドを送信し、イベントを待ちます。
振り付け：参加者はお互いのイベントに反応します（シンプルですが、契約には規律が必要です）。
ルール：明確な補償とタイムアウト、繰り返し可能なステップ、idempotentハンドラ。

観測可能性

Trace/Span：イベントを生成するときにヘッダーから'trace_id'/'span_id'をトレースします。
メトリクス：消費者の遅延、パブリッシング/消費レート、デッドレターレート、重複排除シェア。
DLQ/駐車場：失敗したメッセージ-アラート付きの別のトピックへ；再処理を提供して下さい。

セキュリティとコンプライアンス

データ分類：コアには、必要最小限のPII/財務データ（リバースピラミッドモデル）、詳細のみが含まれます。
重要な属性の署名/ハッシュ、整合性制御。
topic/consummer （IAM/ACL）による機内および休止中の暗号化の権利。
保持ポリシーと忘れられる権利：トピックごとに明確に定義されています。

性能と安定性

Backpressure：消費者は限られた競争を持っています、ブローカーはクォータ/制限を持っています。
オーバーヘッドを低減するバッチおよび圧縮グループのレコード。
無限の試みの代わりにジッタとDLQでレトライ。
リバランス抵抗：オフセットをトランザクション/外部に保存し、スナップショットでコールドスタートを高速化します。

典型的なイベントテンプレート

ペイメントコア

支払いだよ。開始されました。v1'→'支払い。承認されました。v1'→'支払い。キャプチャされた。v1'→'支払い。落ち着いた。v1'

拒否： "支払い。拒否されました。v1'、'支払い。返金されます。v1'

パーティショニング： 'payment_id'

SLA：中心の遅れ≤ 2c p95；消費者のアイデンポテンスは必須です。

CCM/検証

'kyc。開始しました。v1'→'kyc。ドキュメント。受信しました。v1'→'kyc。承認されました。v1'/'kyc。拒否されました。v1'

PII-最小；ドキュメントの詳細-'kyc。豊かになりました。アクセス制限付きのv1'。

監査/セキュリティ

「オーディット」記録されています。属性'actor'、 'subject'、 'action'、 'overced_at'、 'trace_id'を持つv1'。

継続的な保存/アーカイブ；高められた完全性（WORM）

アンチパターン

脂肪のでき事：不必要に積み過ぎられたペイロード、PIIの漏出。
イベントを介して隠されたRPC：同期の「ここと今」応答を待っています。
Raw CDC外向き：DBスキーマへの接続を閉じます。
消費者の独自性はありません：2倍の副作用につながります。
一つの共通のトピック「すべてのために」：利益の対立、問題の秩序、複雑な進化。

EDCのステップバイステップの実装

1.ドメインマッピング：キーアグリゲートとライフサイクルを強調表示します。
2.イベントのカタログ：名前、意味、不変量、必須フィールド。
3.スキーマとレジストリ-フォーマットを選択し、互換性ルールを有効にします。
4.Outbox/CDC：プロデューサーごとに、事実を公開するメカニズムを定義します。
5.パーティショニング：キーを選択し、ホットキー/再パーティションを評価します。
6.Idempotency：重複除外パターン+消費者トランザクション性。
7.投影-実体化モデルを定義し、SLAを更新します。
8.観測性：トレース、ラグ、DLQ、アラート。
9.セキュリティ/PII：データ分類、暗号化、ACL。
10.進化へのガイド：移行のためのバージョンポリシー、非推奨、デュアルライト。

生産チェックリスト

各イベントには'event_id'、 'trace_id'、 'overced_at'、 'partition_key'があります。
レジストリ内のスキーム、互換性チェックが有効になっています。
コンシューマーアイデンティティの実装とテスト。
DLQ/駐車場とアラートは、パブリッシュ/消費エラー用に設定されています。
投影は、ログ（リプレイ）から許容時間で再作成されます。
PIIへのアクセスが制限されています。カーネルの最小ペイロードです。
lags/deliveryによるSLAが測定され、ダッシュボードに表示されます。
イベントバージョンと非推奨ウィンドウを移行する計画があります。

よくあるご質問

EDCと「バスだけ」の違いは？
コアは、ブローカーだけでなく、イベント契約、注文/特権ルール、進化プロセス、および観測可能性でもあります。

CDCだけで構築できますか？
CDCは統合/移行に適していますが、ドメインイベントはより明確に表現し、データベースの変更をより安定的に体験します。

一貫性についてはどうですか？
最終的な一貫性を受け入れ、UX/プロセス（アップデート、リトレイ、補償の指標）を設計します。

正確に一度必要なのはいつですか？
まれ：倍増が厳密に受け入れられず、補償することが不可能な場合。より頻繁に、少なくとも一度+idempotencyは十分です。

合計

イベント駆動カーネルは、ビジネス事実の流れをシステムの信頼できる基盤に変えます。イベント契約、配信規律、観察可能性を明確にすることで、スケーラビリティ、回復力、進化率が向上します。

イベント駆動カーネル