1월 14일(화) 멘토링 질문 사항 수집

[Raemerrr]

질문 사항 있다면 편하게 댓글 남겨주세요.

[GentleDot]

1. SSE 에 대한 궁금증

• 풀링, 웹소켓 방식 과의 차이, 장단점

[InvestLee]

폴링(불필요한 트래픽 발생)
소켓 유지가 기술적으로 힘들 수 있음(브라우저 지원 X, nginx 리버스 프록시에서 지원 안될 수 있음)
=> SSE(부하를 적게 주고, 브라우저 등 지원 가능)

[Raemerrr]

FE의 도전 기술인 SSE 통신을 통한 응답을 주고받기 위해 mult-instance인 Fintech-be에선 어떤 효율적인 구조를 잡을 수 있을까요?

Fintech-FE의 Web SDK에서 QR코드 생성 후 결제 완료에 대한 Callback을 받는 방법으로 SSE를 선택함.

• Kafka 등 메시지 큐를 이용해서 BroadCasting을 한다.

[InvestLee]

SSE로 연결 시 같은 인스턴스에게 요청에 가야됨
=> stickySession(권장된 방법 아님, 특정 클라이언트를 식별할 수 있는 식별자를 리버스 프록시가 받아서 해시 연산 후 서버 지정, 같은 사용자는 같은 서버로만 지정, 특정 서버에 몰릴 위험성이 있고, 인스턴스가 주기적으로 오토스케일링 등 변경되면 대응이 힘듬)
=> 고로 만약 연결이 끊긴 경우 클라이언트 측에서 결제 완료 눌러보게 한다.(API요청으로 대체)

Kafka 등 메세지 큐를 이용해서 브로드캐스팅도 가능
=> 기술적 난이도 상승

[GentleDot]

2. Event Queue 구성을 위한 전략

• Web에서 sdk가 PG 서버와 connection을 유지해야 하는 상황
• 결제 요청 갱신, 결제 완료 상태 확인 등을 이벤트로 발생하고 -> 구독하고 있는 sdk는 이벤트를 지속적으로 확인하도록
• 다중 connection이 예상되므로 이에 대한 대응책도

[InvestLee]

윗 질문과 연계해서 고민 필요

[InvestLee]

웹훅 자체는 서버 TO 서버(서로 END POINT가 있음)
어떤 HTTP 요청이 있으면 덩달아 발생하는 이벤트같은 것
PG쪽에서 상점서버에게 결재 완료되었다는 것을 호출할 때 나의 URL을 호출하도록 콜백 URL을 넣어줬을 것이라 예상