EventSourcingDB 1.3.0 が利用可能になりました

EventSourcingDB 1.3.0 が利用可能になりました

EventSourcingDB 1.3.0 がリリースされ、これまでのどのバージョンよりも高速かつ安定しています。 書き込みと EventQL クエリは大幅に高速化され、読み取りも高速化され、すべてのリクエストは時間制限があり、60以上の修正が行われました。さらに、受け入れたすべてリクエストの結果を返す新しい API が導入され、すべてエラーに独自のコードが付与されています。

この記事では、変更点とアップグレード時に注意すべき点について説明します。v1 API は 2027 年 1 月 31 日までサポートされており、それ以降のリリースで削除されるため、自分のペースで新しい API に移行できます。そして本日より、EventSourcingDB のドキュメントは eventfoundation.io に掲載されます。古いリンクはすべてそこに誘導されます。

新しい、永続的な API #

新しい v2 API は、同じデータ上で v1 API と並行して実行されます。その中心的な考え方はシンプルです：サーバーがリクエストを受け付けたら、その結果はボディに含まれます。リクエストは、認証され、ボディがそのルートが期待する形状を持ち、制限内に収まっている場合に受け付けられたとみなされます。前提条件が満たされない場合、イベントタイプが不明な場合、データベースが読み取り専用モードの場合 — これらすべては、クライアントが解釈する必要のあるステータスコードではなく、読み取れる回答として返されます。

すべてエラーには、その原因と修正方法を説明する独自のページへのリンクとなるコードが付与されます。それらはすべて Errors の下にあります。ストリームされた回答（イベントの読み取りなど）が終わるときは、明示的な end アイテムで閉じられるため、クライアントは完全な回答と途中でカットされた回答を区別できます。ストリームが待機している間、サーバーはハートビートを送信し、プロキシがその間に接続を閉じるのを防ぎます。

v2 API はまた、再帰的な 前提条件 をもたらします：isSubjectPristine、isSubjectPopulated、isSubjectOnEventId は、単一のサブジェクトではなくツリー全体の部分に依存する決定に役立つように、サブジェクトとその下のすべてのサブジェクトに同時に適用できるようになりました。

現在提供されている 8 つのクライアント SDK すべてが両方の API をサポートしており、サーバーが v2 API を提供している場合はどこでも v2 API を使用します。したがって、SDK を更新する以外は、プロキシが v2 API が読み取りに使用する HTTP メソッド QUERY を通過させる限り、コードを変更する必要はありません。HTTP API を直接呼び出す場合は、Migrating to v2 にルートごとの変更点が示されています。

データの移動とバックアップ #

エクスポートとインポート により、イベントを新しいデータベースに簡単に移動できるようになります。どちらも、ID とタイムスタンプを含む、1 行あたり 1 つのプレーンな CloudEvent で動作するため、エクスポートは変換なしでインポートできます。インポートはハッシュを自分で計算するため、履歴をエクスポートして個人データを削除し、手動でハッシュを計算することなく結果をインポートすることもできます。

増分バックアップ は、以前のバックアップ以降に書き込まれたイベントのみを保持します。復元は、フルバックアップとその増分を順番に行います。これにより、大規模データベースの定期的なバックアップを小さく保つことができます。復元自体も、イベントをバッチで書き込むようになったため、大幅に高速化されました。

より高速に、負荷下でもより堅牢に #

書き込みは大幅に高速化され、単一クライアントでも複数クライアントでも、ストアが成長しても遅くならなくなりました。EventQL クエリの実行も大幅に高速化され、特に多くのイベントを読み取るクエリ、グループ化、ソート、または複数のソースを結合するクエリで顕著です。イベントの読み取りも同様です。インデックスははるかに少ないファイルを使用するため、大規模データベースでのサブジェクトのイベントの読み取りが高速になり、ストアの整合性チェックは、最初の1つだけでなく、最大100個の一貫性のないものをすべて報告します。

1.3 の他の多くの作業は、必要になるまで目に見えません。すべてリクエスト、すべて回答、およびすべてアイドル接続には時間制限があります。これにより、遅いまたはスタックしたクライアントがリソースを永久に保持できなくなります。EventQL クエリには、ネストの深さやメモリ使用量に関する制限があり、単一のクエリがスタックをオーバーフローしたり、好きなだけメモリを使用したりするのを防ぎます。

サーバーは定数時間で API トークンを比較し、推測可能なものでは起動を拒否します。ディスクがいっぱいなどの理由で書き込みを保存できなかった場合、再起動されるまで読み取り専用モードに切り替わり、読み取りを提供し続け、ヘルスエンドポイントを通じてこれを報告し、ログで原因を特定します。Limits に制限がリストされています。

本番環境での実行 #

本番環境で EventSourcingDB を実行するためのいくつかの追加機能があります。レート制限 はデフォルトで有効になっており、マシンのサイズに合わせてスケーリングされるため、過剰なリクエストを送信する単一クライアントがデータベースを圧倒することはありません。v2 API のヘルスエンドポイントは OpenMetrics を話すため、Prometheus や類似のツールで直接スクレイピングでき、メモリやファイルディスクリプタなど、プロセスに関する詳細情報を報告します。Logging and Monitoring に報告される内容がリストされています。

既知のイベントタイプのみが書き込まれるようにしたい場合は、新しいフラグ --require-event-schemas が、登録済みのスキーマを持たないイベントタイプの書き込みと復元を拒否します。これはデフォルトではオフになっています。また、/.well-known/api-catalog にある API カタログは、両方の API の OpenAPI ドキュメントをツールに指し示します。

アップグレード前 #

このリリースでは、アップグレード時に注意が必要です。開始する前に、Upgrading EventSourcingDB をお読みください。最も重要な点は以下の通りです。

• まずデータをバックアップしてください。 1.3 が開いたデータディレクトリは、以前のバージョンでは開けなくなるため、バックアップが唯一の戻り道です。
• 1.3 を起動する前に古いサーバーを停止してください。 1.2 までのバージョンはデータディレクトリをロックしないため、新しいサーバーを先に起動するロールアウト（例：Kubernetes Deployment の RollingUpdate）は、同じデータで 2 つのサーバーを実行することになり、破損の原因となります。
• Docker イメージは別のユーザー（UID 65532、以前は 100）として実行されます。 以前のイメージが書き込んだデータディレクトリは、一度新しいユーザーに引き渡す必要があります。そうしないと、コンテナは古いユーザーのまま実行されます。ガイドには Docker と Kubernetes の両方について説明があります。
• API トークンは、サーバーが一時的なデータディレクトリで実行されている場合を除き、少なくとも 32 文字必要です。 また、先頭または末尾に空白のない印刷可能な ASCII 文字である必要があります。そうでない場合、サーバーは起動を拒否します。
• イベントハッシュを検証するアプリケーションを使用している場合は、まずクライアント SDK を更新してください。 1.3 は新しいバージョンのイベントハッシュを書き込むため、古い SDK はアップグレード後に書き込まれたすべてのイベントを改ざんされたものとして報告します。
• --ai-model および --ai-option フラグは削除されました。 EventAI は管理 UI を離れるため、これらのフラグがまだ設定されているサーバーは起動しません。
• EventQL クエリと前提条件を確認してください： 1.3 は、他のことの中でも、異なる型の値の比較方法、イベント ID を文字列として扱う方法、および日付と時刻を UTC で扱う方法を変更します。これにより、結果が変わったり、失敗したりする可能性があります。
• 最初の起動時にインデックスが再構築されます： 1.3 はすぐに起動し、読み取りと書き込みを提供しますが、完了するまで（数分かかる場合があります）EventQL クエリやその他のいくつかのリクエストは拒否されます。

アップグレードガイドと変更ログには、イベントの source やイベントスキーマに対するより厳格なルールなど、注意が必要なその他のすべての事項が記載されています。

アップグレード、または開始の時期 #

重要な部分がより高速になり、問題が発生した場合により堅牢になり、使い慣れた API と並行して新しい API が提供される — それが 1.3 です。すでに EventSourcingDB を実行している場合は、アップグレードガイド で安全に移行できます。

そして、まだ EventSourcingDB を試したことがない場合 — Event Sourcing 用に構築されたデータベース — 今が始めるのに良い時期です。Installing EventSourcingDB でバイナリと Docker イメージを入手でき、Quickstart では、サーバーの起動から最初のイベントの書き込みと読み取りまでを数分で行えます。それを使って何を作るか、ぜひお聞かせください。