®ストリーミングとイベント
注文、機械の状態、在庫の変化をきっかけに、後続の処理を動かす必要があります。イベント契約を設計し、プラットフォームと連携部分を実装することで、負荷が急増した場合や一時的な障害が発生した場合でも、受信側が確実に反応できるようにします。
OTOKO®へのご依頼内容
イベントは発生した変化を記述するものであり、コマンドは実行すべき操作を要求するものです。この区別は、責任範囲の混同を防ぐのに役立ちます。識別子、発生時刻、スキーマ、必要なコンテキストを定義します。順序は、例えば1件の注文のように業務上意味のある単位ごとに考慮するのであって、グローバルな順序を一律に保証するわけではありません。機械との連携では、プロトコル、ネットワーク境界、許可される操作範囲を設備運用の責任者とすり合わせます。
具体的な範囲、貴社の関与、検収基準は、開始前に取り決めます。
技術を分かりやすく解説
障害の後には、メッセージが繰り返し配信されることがあります。そのため利用側には、すでに処理済みのイベントを検知する、あるいは業務上問題のない形で再処理するためのルールを提供します。遅延して届いたイベントと事後的な修正は、それぞれ別に考慮します。保持期間、リプレイ、アクセス保護を計画します。イベントプラットフォームは自動的に不変のアーカイブになるわけではなく、保持および削除の要件は意図的に実装する必要があります。スキーマの変更は、既存の利用側との互換性を確認したうえで行います。
検収には、利用側の障害、増大するバックログ、制御された再起動のテストが含まれます。ダッシュボードには、受信したメッセージ数だけでなく、遅延とエラーも表示します。開始にあたっては、イベントの種類、想定される件数、許容できる最大の遅延、順序や重複処理に対する業務上の扱い方についての情報が必要です。
検証可能な成果
引き継ぎでは、実装とドキュメントを一体的に扱います。合意したケースを共に確認し、残る課題を記録します。
貴社の取り組みの詳細
変化に反応する必要があるプロセスのために、イベント駆動型の連携を構築します。その際、伝送方法だけでなく、イベントの意味、順序、そして再処理のあり方も計画します。
イベントとは、たとえば確定した注文のように、何かが発生したことを表すものです。識別子、発生時刻、業務上の関連情報、そしてバージョンに関するルールを取り決めます。利用側は、同じメッセージを既に処理済みかどうか、そしてそのイベントが自らの目的にとって十分な情報を含んでいるかどうかを判断できなければなりません。
順序性は、多くの場合、特定の業務オブジェクトの範囲内でのみ求められます。この要件は、パーティショニングと並列性に影響します。全体での順序性や、業務処理が厳密に一度だけ行われることを一律に約束することは避け、その代わりに連携先システムを含めたチェーン全体の保証内容を検証します。
処理の遅い利用側システムが、気づかれないまま際限なく遅れていくようなことがあってはなりません。遅延を監視し、処理能力の増強や処理の優先順位付けをどのように行うかを計画します。エラーとなったメッセージには解決手順が用意され、問題のある一件のデータが処理全体を恒常的に止めてしまうことを防ぎます。
イベント処理を繰り返し実行できることは、データの修復や新しい利用側システムの追加にとって有用ですが、データ保持とデータ保護に関するルールが必要です。どの過去のイベントを利用可能な状態で残すか、そして対象データセットをどのように再構築するかを定めます。検収では、処理の中断、重複配信、そして利用側システムの再起動について明示的に確認します。
プロジェクトシナリオの例
例：確定した注文が、出荷準備と顧客への通知を起動するとします。二つの利用側システムはそれぞれ独立して処理を行います。通知処理が失敗しても注文情報は保持され、処理の再開後はトランザクションIDに基づいて、同じ通知が制御されないまま何度も送信されることを防ぎます。
この例は想定される進め方を説明するものであり、顧客事例ではありません。
最初の一歩の前に
それだけでは保証されません。プラットフォームの保証は、一定の範囲内でのみ有効です。外部システムに変更が加わる時点からは、アプリケーション側で重複処理や再試行を適切に扱う必要があります。
多くの場合、ゲートウェイや既存のエクスポート経路を利用できます。具体的な方法は、生産設備の責任者とともに検証し、承認を得ます。
