2025/03/23 13:27 The Synchrony Budget
ロボ子、今日のITニュースは「同期処理予算」についてじゃ。
同期処理予算、ですか。初めて聞く言葉です。
ふむ。分散サービスシステムで、サービスが他のサービスに同期リクエストする回数を減らすことじゃな。
同期リクエストが多いと、何か問題があるのでしょうか？
もちろんじゃ！同期リクエストが多いほど、サービスがインバウンドリクエストを処理するのに時間がかかる。ユーザーは待つのが嫌いじゃから、ビジネスチャンスを逃すことになるぞ。
なるほど。それに、同期リクエストはサービスの可用性にも影響するんですね。呼び出されたサービスがすべて稼働している必要がある、と。
その通り！同期処理は整合性を保証するのに役立つが、完了するまで進行をブロックする。可能な限り非同期にするのが良いのじゃ。
記事では、Eコマースの例が挙げられていますね。注文処理におけるサービス間の連携について。
そうじゃ。例えば、出荷サービスは、顧客が注文したときに非同期で通知を受け取れば良い。Kafkaトピックにメッセージを送るのが良い例じゃな。
在庫サービスの場合はどうでしょうか？
注文サービスは、在庫があるかどうかを知る必要がある。在庫サービスの変更フィードをサブスクライブして、ローカルデータストアにビューを具体化することで、同期呼び出しを回避できるぞ。
支払いサービスは、顧客のクレジットカードが正常に請求できることを確認する必要があるため、同期呼び出しが正当化される場合がある、と。
じゃな。しかし、記事では、支払いサービスへの同期呼び出しが失敗した場合に、非同期処理にフォールバックすることも可能だと述べているぞ。
Outboxパターンも紹介されていますね。送信するメッセージをサービスのデータストアに格納し、他のデータ変更とトランザクション的に一貫性を持たせるためのアプローチ。
Outboxパターンは便利じゃ。DebeziumなどのCDCツールを使って、Outboxテーブルからメッセージを抽出できる。
現実の世界では、ビジネスは在庫がない商品に対する注文を受け入れるなどの状況に対処する必要がある、というのも興味深いですね。
そうじゃな。完璧なシステムを作るのは難しい。現実世界の非トランザクション性を受け入れることも重要じゃ。
勉強になりました！
ところでロボ子、同期処理を避けるために非同期処理ばかりにすると、いつの間にか全部忘れ去られて、まるで私の誕生日みたいになるかもしれんぞ。
博士…！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。