Stailerにおけるコトを残すデータ設計とイベント駆動アーキテクチャ

by ryota0624

Slide 1

Slide 1 text

Stailer におけるコトを残すデータ設計とイベント駆動アーキテクチャ新しい機能では「" 状態" ではなく" 事実( イベント)" を記録する」ことを選びました 1

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

クライアント・サーバ間通信の設計店舗のネットワーク環境等を考慮したのか、一定時間の操作結果をクライアントに蓄積、まとめてサーバに反映する方式「事実」ではなく「状態（スナップショット）」を送信「りんごを1 つピックした、品切れが1 つ発生した」ではなく「りんごは3 個ピック済み、品切れは1 個である」を送信 Before: 以前の設計 ALL RIGHTS RESERVED BY 10X, INC. 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Order とは「注文にまつわるすべての契約、業務を注文ID で一意にできることすべて詰め込んだモノ」注文確定からお渡し完了まで、あらゆる詳細を扱う Stailer のあらゆるアクター EC 、ピック、配送、請求... のスタッフが関心を持つ抱えていた問題巨大で複雑: あらゆる業務ロジックが混在し、相互に依存変更の影響範囲: ピックパックの変更が、請求や配送に影響するリスクステータスの爆発: 「未ピック」「保留」「品切れ」... 各領域で考慮が必要巨大なOrder （注文）クラス ALL RIGHTS RESERVED BY 10X, INC. 9

Slide 10

Slide 10 text

1 ドキュメントの限界 Order はFirestore 上で1 つのドキュメントとして表現されていたピッキング業務は「商品」ごとに並列で行われるが、更新先は単一のOrder 書き込み競合が頻発 1 ドキュメントあたりの書き込み頻度制限（1 回/ 秒程度）に抵触トランザクションスクリプトの弊害 Order のあらゆるフィールドが公開され、スクリプトが自由に書き換え単体テストが困難 Firestore エミュレータ必須セットアップが重い Order とFirestore 、業務事情の相性問題 ALL RIGHTS RESERVED BY 10X, INC. 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

物理削除 or 論理削除？の議論なしに、しれっと物理削除が横行失われる「事実」しれっと物理削除が起きるのはなぜ？ Order クラスが持っているList をfilter(where) で書き換えるような操作をなんとなく書く Order クラスをほぼそのままJSON に変換してFirestore に保存 filter で除外した要素がFirestore 上から物理削除される横行するしれっと物理削除 ALL RIGHTS RESERVED BY 10X, INC. 14

Slide 15

Slide 15 text

きっかけ: シングルバスケットピックの登場業務の根幹を支える機能の実現新たなピックパック方式（シングルバスケットピック）の要件既存システム（総量ピック）の使い回しが困難「ここでフルスイングしないと一生改善できない」という決意目指した姿「コト（Event ）」をデータとして扱う業務が進捗するタイミングでデータが永続化されるトリガーがあることが自然な状態にする解決への転換点 ALL RIGHTS RESERVED BY 10X, INC. 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

リアルタイム性の向上アプリ上で操作が起きたタイミングでクライアントとサーバが通信データ設計の見直しにより、サーバレスポンスが高速化これにより、都度通信しても業務に支障が出ないパフォーマンスを実現以前の課題の解消複数人での同時作業でも、「コト」単位で処理されるため整合性が保たれる競合の影響を最小限に抑えることができる新しいシステム間のコミュニケーション設計 ALL RIGHTS RESERVED BY 10X, INC. 19

Slide 20

Slide 20 text

状態遷移には必ずイベントが伴うように！ https://zenn.dev/jtechjapan_pub/articles/fc9878ec69b6a1 https://thinkbeforecoding.com/post/2021/12/17/functional-event-sourcing-decider プログラムの書きっぷりの変化 ALL RIGHTS RESERVED BY 10X, INC. 20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Firestore 設計の最適化以前: 注文（Order ）単位の巨大なドキュメント改善後: 「注文に含まれる1 商品」単位のドキュメント同一注文でも、別商品の操作であれば完全に並列処理が可能に即時フィードバックスタッフの操作は速やかにサーバへ送信「ピックしすぎ」などのエラーを即座にフィードバック可能に改善の成果: 並列性と整合性 ALL RIGHTS RESERVED BY 10X, INC. 22

Slide 23

Slide 23 text

責務の分離 Picking: 注文の「1 商品」を扱うピック操作や品切れ操作は商品単位で発生するため Packing: 「注文単位」で商品を扱う全ての商品が揃ってから箱詰め・確定を行うため非同期連携 Picking での操作（ピック）をトリガーに、Packing へ「パック予定」として計上結果整合性を受け入れることで、Picking 操作時のレスポンスを高速に維持注文単位で整合性を保つ必要があるPacking の操作でレスポンスをブロックしない業務工程が分かれているため、即時の整合性は必須ではない Picking とPacking のモデル設計 ALL RIGHTS RESERVED BY 10X, INC. 23

Slide 24

Slide 24 text

ピックパック業務領域から見た役割の再定義 Order: ピックパック業務領域外への参照用のデータ（Read Model に近い） Picking/Packing モデル: ピックパック業務の更新系操作を主に受け持つ、新しい系統の読み込み用にも使う結果整合性への移行 Picking/Packing モデルで業務の整合性を担保発生した Event をトリガーに、Order へ状態を反映 Order への反映は遅延しても良い（結果整合性） Order との関係性 ALL RIGHTS RESERVED BY 10X, INC. 24

Slide 25

Slide 25 text

Phase 1: 同期実行ユースケースからイベントハンドラを明示的に呼び出し同一DB トランザクションで実行（まだ密結合） Phase 2: プログラム的非同期イベントハンドラを非同期処理で実行別のDB トランザクションに分離（レスポンス速度向上） Phase 3: システム的非同期 Eventarc を利用し非同期処理、内部的にはPub/Sub が使われるシステム的に分離され、可能な限りのリトライが可能に Order への書き込み競合で失敗しても、ひたすらリトライして最終的に整合させる Order への反映: 3 つのフェーズ ALL RIGHTS RESERVED BY 10X, INC. 25

Slide 26

Slide 26 text

Future executeUseCase(Transaction tx, PickingId pickingId) async { // 1. リポジトリから対象の集約を取得 final picking = await repository.get(tx, pickingId); // 2. ドメインロジックの実行（状態遷移） final updated = picking.pick(); // 3. イベント、状態の保存 await repository.store(tx, updated); // 4. 発生したドメインイベントを順次処理 for (final evt in updated.occurredEvents) { await eventHandler.execute(evt, transaction: tx); } } Order への反映: (Phase 1: 同期実行) ALL RIGHTS RESERVED BY 10X, INC. 26

Slide 27

Slide 27 text

Future executeUseCase(Transaction tx, PickingId pickingId) async { // 1. 集約の取得 final picking = await repository.get(tx, pickingId); // 2. 状態遷移（ドメインイベントの発生） final updated = picking.pick(); // 3. イベント、状態の保存 await repository.store(tx, updated); // 4. プログラミング的な非同期処理 // 別トランザクション内でイベントを処理 for (final evt in updated.occurredEvents) { unawaited(() async { await eventHandler.execute(evt); }()); } } Order への反映: (Phase 2: プログラム的非同期) ALL RIGHTS RESERVED BY 10X, INC. 27

Slide 28

Slide 28 text

Future executeUseCase(Transaction tx, PickingId pickingId) async { final picking = await repository.get(tx, pickingId); final updated = picking.pick(); // 1. イベント、状態の保存 // 2. イベントはトリガーの仕組みで別のサーバへ送られる await repository.store(tx, updated); } /// 3. 別のサーバにてイベントを処理 Future receiveEvent(evt) { await eventHandler.execute(evt); } Order への反映: (Phase 3: システム的非同期) ALL RIGHTS RESERVED BY 10X, INC. 28

Slide 29

Slide 29 text

Slide 30

Slide 30 text

以前の課題「箱決定」のロジック内で、各配送システムへ直接連携メッセージを送信連携先が増えるたびにロジック変更が必要（密結合）サーバダウン時にメッセージが送られないリスク改善後「箱決定イベント」を連携コンポーネントが拾う形に変更連携先の追加は、イベント購読者を追加するだけ（疎結合）イベントさえ永続化されていれば、リトライにより確実に連携実行（耐障害性向上）導入効果事例: 配送連携ロジックの疎結合化 ALL RIGHTS RESERVED BY 10X, INC. 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

「時間」と「空間」の分離ピックパック業務は日中がピークだが、夜間は停止する連携先やOrder への反映が遅延しても、夜間に追いつけば問題ないケースが明確に「何かあっても慌てなくていい」運用が可能にメンテナンス性の向上ピックパック領域のデータマイグレーションやインデックス作成影響範囲が限定されたため、夜間であれば他業務（注文受付など）に影響を与えずに実施可能導入効果事例: 疎結合が生んだ運用上のメリット ALL RIGHTS RESERVED BY 10X, INC. 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

実装のアプローチ CQRS 的なRead Model Updater イベントをトリガーに「品切れ状態」を集計・更新画面表示時（RPC 呼び出し内）の集計は高コストなため回避一貫したアーキテクチャ表示のための集計が書き込み系ロジックに混在しない、パフォーマンスの足を引っ張らない「この機能のために」場当たり的な実装をするのではなく、イベント駆動の仕組みに乗っかりながら実現新機能への展開: 品切れ報告 ALL RIGHTS RESERVED BY 10X, INC. 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

反省点集約ルートの設計: ピッキング中のちょっとした別業務もPicking に押し込んでしまった。別の集約ルートに切り出さなかったゆえに、その後違和感が残ることに。常に最適な境界を見つけるのは難しい（が、イベントがあれば後からでも分割できる）得られたもの「コト」をデータとして扱えるようになった問い合わせや異常時の調査のしやすさ分析基盤への信頼性の高いデータの提供まとめ(2/2) ALL RIGHTS RESERVED BY 10X, INC. 39

Slide 40

Slide 40 text

業務の「コト（イベント）」を扱う設計の重要性事実が永続化されることで、分析や問い合わせ対応が容易に業務の進捗が明確になり、信頼性の高いデータ基盤を構築可能にという効果もあるが！アプリケーションがコトを扱う設計になることで、開発者が業務と目線を合わしながら設計をしやすくなる。と自分は思っている。そしてそれはCQRS+ES に限らないよね。今日伝えたいこと ALL RIGHTS RESERVED BY 10X, INC. 40