52 App A 4-1. 分散トレーシングで処理の流れを追う App B App C Request X Log A Log B Log C それぞれのアプリケーションはリクエストに対応するログを出力します。 タイムスタンプを参考にして Log A -> B -> Cの順で見れば 処理の流れを追うことができる。
53 App A 4-1. 分散トレーシングで処理の流れを追う App B App C Request X Log A Log B Log C リクエストが複数になると対応関係を把握することは難しくなります。 Request Y Log A Log B Log C とあるLog Aから どのLog Bにつながっているのか分からない
56 4-1. 分散トレーシングで処理の流れを追う App A App B Spring Cloud SleuthではB3という形式でTraceIDを伝播させています。 Spring Cloud Sleuthを適切に設定することで、 RestTemplateやRabbitTemplate、KafkaTemplateなど 様々なプロトコルに対応したB3ヘッダを付与してくれます。 これによってSpring Cloud Sleuthを採用したアプリケーション間では 実装者が意識することなくTraceIDを引き継ぐことができます。 TraceID Spring Cloud Sleuth Spring Cloud Sleuth RestTemplate, RabbitTemplate, etc...
75 5. 後回しでいいものは非同期にする 性能が安定しない場合にも非同期を活用できます。 決済機関 ECサイトA 通知システム 1000 ms ECサイトB ECサイトC 1500 ms 3000 ms 3500 ms 60000 ms 60500 ms 複数の加盟店様がいるため 決済機関に対して性能を保証できない エンドユーザーの処理完了が通知される。
通知受信 システム 76 5. 後回しでいいものは非同期にする MQに格納することで決済機関に素早くレスポンスを返却できます。 決済機関 ECサイトA 通知 システム 1000 ms ECサイトB ECサイトC 50 ms 3000 ms 60000 ms 50 ms 50 ms 加盟店様によっては 流量や性能をコントロールできる 決済機関には常に一定の性能で レスポンスを返却できる