この記事は、10X 新春ブログリレー 2026の記事です。

鈴木です。2026年1月に開催されたCQRS+ES Conference 2026にて「ネットスーパー事業におけるCQRS+ES的アプローチの取り組み紹介」というタイトルで登壇しました。 cqrs-es-con.jp

CQRS+ES conf 2026の当日は

Stailerにある注文を中心とした業務影響がある課題の共有
共有した課題がCQRSとイベントソーシングにある要素でどう解決できるのか

この2点にフォーカスして話をさせていただきました。

当日使った資料はこちらです。

speakerdeck.com

また、1月中にイベントで話したことについて補足記事を1つ出しています。

product.10x.co.jp

引き続きイベント登壇に便乗して当日話きれなかった具体的な方法を紹介しようと思います。

非同期処理はムズカシイ

イベント駆動な非同期処理自体の紹介はこちら記事で行なっています。

product.10x.co.jp

非同期処理の難しさは様々な要素があります。

非同期処理をトリガーする処理自体の完了から、非同期処理の完了時間はそれを支えるミドルウェアや時前の実装の都合で

処理の順序はトリガーから前後しうる
非同期処理の開始時間はトリガーから保証されないので、完了時間もまた保証できない
結果整合性との付き合い方
リトライと冪等性
流量と適切なリソース配分

などなど

難しさの中でも今回紹介したいのが、「非同期処理の開始時間はトリガーから保証されないので、完了時間もまた保証できない」への付き合い方です。

非同期処理のメトリクス監視

Stailerの中でもCQRS+ES conf 2026で紹介したり、ピックパックモジュールと呼称しているドメインイベント中心で実現されている箇所は Firestoreのドキュメント書き込みをEventarcでリレーして非同期処理を実現しています。 product.10x.co.jp

CQRS+ES conf 2026でも紹介した「ピックが起きればパックが非同期に予定される」というケースにおいては、 Stailerが使われる業務フローでは結果整合性を受け入れてパフォーマンスを優先できる。ということを話しました。

この「結果整合性が受け入れられる。」といっても限度があります。パックの作業が開始されるまでに非同期処理が終わっている必要があるのです。

「非同期処理の開始時間はトリガーから保証されないので、完了時間もまた保証できない」じゃあ処理は20分後になります！ではイベントの発生をトリガーにしたい場合に困ります。遅延が一瞬とかたまたま一回ではなく、継続的であれば何かしら対応が必要になります。

そこでピックパックモジュールといったドメインイベント中心にしている箇所の非同期処理には次の3つの監視構成をしています。

イベント発生から非同期処理の完了までの時間を見て、遅延が大きいケースが増えたとき鳴るアラート
Eventarcの実態として扱っているPub/Subでのメッセージの長期滞留でのアラート
Eventarcの実態として扱っているPub/Subでのメッセージがdead letter用のPub/Sub topicへ送信された際の即時アラート

基本的にはPub/Subのメトリクスに異常が見られるならアラートを流す。というシンプルな整理です。

1.についてはEventarcがPub/Subで成り立っているとはいえFirestoreへ書き込みがあり、Pub/Subへ流されるまでの過程はブラックボックスになっているようなのでそこで異常があったときに気づけるように大体Firestoreへ書き込みがあるタイミングのイベント発生時刻を基準として時間を測っています。

ドメインイベントである以上、このデータを取り出せることを満たしてくれというインターフェースの中にはイベント発生日時が含まれているので、横断的にイベント発生から非同期処理の完了までの時間を計測することができています。

さらに非同期処理でも特に遅延が業務へダイレクトに影響しうる箇所では遅延時間にSLOを設けて運用しています。 product.10x.co.jp

ここ最近閾値の見直しができておらずちゃんと運用できていないのが悲しいのですが、一定の期間においてピークタイムでも95 percentileで1秒程度の遅延であることがキープできています。中長期的に見て徐々にパフォーマンスに悪化がないか見ているのはAPIサーバのエンドポイントと同じですね。