dd

Author: 김현수

01.Seminar/SLASH22_애플한주가_고객에게_전달되기까지.md

@@ -0,0 +1,97 @@
+# 해외 주식 아키텍처
+
+- 높은 정합성과 신뢰성
+- Springboot, MSA 기반으로 사용한다. 모듈 장애가 전체 장애로 이어지지 않게 한다.
+
+- 나스닥으로 직접 주문하지않고 중개인(브로커)를 통해서 주문을한다.
+  - 즉 브로커의 주문정합성이 중요하다.
+  - 제출된 주문에 대한 체결결과는 별도의 트랜잭션으로 발생하며, 다수의 이벤트로 발생할수있다.
+
+![image-20230711171916079](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711171916079.png)
+
+- 매매 요청 서버와 체결 수신 서버가 별개 모듈로 나누어져있는 이유는? → 브로커 의존성 격리하기 확인
+
+
+
+# 동시성으로부터 고객의 자산을 안전하게 처리하기
+
+- 매매서버는 고객의 주문을 브로커에게 전달하고 원장에 기록하는 책임을 가지고있다.
+  - **토스증권에서는 WTS,MTS,자동매매 등 다양한곳에서 고객의 잔고를 갱신하는 트랜잭션들이 발생한다. 즉 안전하게 동시성을 제어할 수 있어야한다.**
+
+![image-20230711171938966](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711171938966.png)
+
+- 락으로 동시성 제어? 매매요청은 고객의 잔고, 증거금, 주문 등 여러 테이블에 대한 삽입 및 갱신이 일어나는 트랜잭션으로 대상 테이블에 대해 하나하나 모두 락을 잡아버린다면 성능 저하와 데드락 지옥을 피할 수 없다. 
+  - 보통 이런 경우 락을 위한 테이블을 별도로 두게 되고 타 증권사들은 계좌락 테이블을 통해 트랜잭션 동시성을 제어하고 있다.
+
+![image-20230711172008113](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711172008113.png)
+
+- 하지만 토스는 해외주식 원장은 MSA 구조로 각 작은 모듈들이 독립적인 데이터 베이스를 사용한다.
+
+  - 또 시스템이 발전함에 따라 하나의 서버가 여러개 서버로 분리 될수도 있다.
+  - MSA에서 이와 같은 방식은 서비스간의 높은 결합도를 유지하거나 비효율적인 자원사용을 야기한다.
+
+- 토스증권은 Redis 기반 분산락을 사용해서 해결한다. 
+
+  - 따라서 모듈의 데이터 베이스를 강제하지 않고 서비스간의 결합도도 느슨하게 유지할수있다.
+
+  - 분산락은 여러서버에서 많은 요청이 오는데 Redis는 메모리기반저장소라서 높은 처리량을 제공한다.
+
+  - 주의할부분?
+
+    - **원장내 모든 서버가 공통적으로 사용하기 때문에 하나의 트랜잭션이 무한정 락을 소유하고 있을경우 다른 서버들의 요청이 무한정 대기될 수 있**다. -> 데드락
+
+    - 따라서 적절한 분산락 타임아웃을 설정해야되는데 제대로 동작하지 않을수있다.
+
+    - 타임아웃이 끝났는데 트랜잭션이 끝나지 않은 상태여서 다른트랜잭션과 경합이 일어날수있다.
+
+    - ![image-20230711172721327](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711172721327.png)
+
+    - **갱신 유실 발생**
+
+      - 분산락이 해제되기전 디비 트랜잭션이 커밋이 되거나, 분산락을 해체하고 나서 커밋이 되는 경우 등에 발생한다.  JPA 환경에서는 쿼리 쓰기 지연 등으로 인해 이러한 문제가 발생할확률이 높다. 
+      - 원자적 연산 사용, 명시적 잠금, 갱신 손실 자동감지, compare and set 연산 등 다양한 방법으로 방지가 가능한데 
+        - 명시적 장금은 여러테이블 갱신하는 트랜잭션에서는 비용이 매우 비싸다.
+        - 원자적연산과 갱신손실자동방지는 dbms와 결합이 높기때문에 orm과 궁합이 맞지않는다.
+      - 토스는 CAS연산을 통해서 갱신 유실을 방지하고있다. (@OptimisticLocking)
+
+    - 하지만 분산락이 없다면 동시에 발생하는 트랜잭션들은 대기없이 실패하게 되거나, 별도의 재시도 구현이 필요하다. 트랜잭션 재시도 구현은 재시도 자체의 실패등 여러 케이스들을 고려해야되며 곧 코드의 복잡도 상승으로 이어진다. 
+
+    - 대부분상황에서 **분산락은 정상적으로 동작하기에 토스증권은 분산락으로 동시성을 제어하고, 만약의 상황에서도 OptimisticLocking 어노테이션을 통해 데이터 정합성이 틀어지지 않도록 한다.**
+
+    - 주요 테이블은 하이버네이트 envers를 이용해 변경 히스토리를 저장하여 원할히 데이터 흐름을 파악할 수 있도록 한다. 
+
+      
+
+# 해외구간 네트워크 지연으로부터 안전하게 서비스하기
+
+![image-20230711173401895](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711173401895.png)
+
+- 브로커 요청 자체가 지연이 될경우 매매 서버 스레드까지 함께 브로킹이 걸려 최악의 경우 모든 스레드가 행에 걸려 고객의 요청들을 받을 수 없는 상태가 된다.
+- **따라서 토스증권은 고객의 요청의 요청을 받는 스레드 와 브로커에게 요청하는 스레드를 분리하는 것으로 모든 스레드가 블라킹되는 이슈를 해결한다.** 
+
+- **브로커 통신 구간 구간은 여전히 지연이 빈번**하기 때문에 **하나의 API에서 동기로 처리할 경우 상황에 따라 고객은 이 주문응답을 기다리느라 다른 서비스를 이용할수없다.**  토스증권은 이 구간을 **비동기로 처리**하여 고객 경험을 상승시키고 트랜잭션 시간을 최소화 한다.
+
+![image-20230711173730458](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711173730458.png)
+
+- 브로커 요청이 실패할 수도 있기때문에 브로커 요청 이전에 주문을 반드시 대기 상태로 저장한다. 대기 상태의 주문은 브로커 응답 결과에 따라 접수 성공/실패로 주문상태를 갱신하게 된다.  
+- TCP 기반 통신을 사용하는 이상 타임아웃이 발생할 수 있다. 브로커 응답을 받지 못한채 타임아웃이 나면 해당 주문상태를 임의로 판단할 수 없다. 또한 브로커 측의 식별자를 전달받지 못한 상황이기 때문에 브로커 제약으로 인해 주문 상태를 조회하기도 어렵다.
+  - 토스증권은 이러한 주문을 재시도 대상으로 판단한다.
+- 재시도에서 발생할 수 있는 문제를 멱등한 API 요청으로 해결
+  - 토스 주문 id를 멱등키로 보내서, 하나의 주문 id는 하나의 브로커 주문만 생성하도록 약손한다.
+  - 타임아웃 특성상 짧은주기로 요청보내면 네트워크 지연을 악화시킨다. 따라서 일정 횟수로 재시도를 제한하고, 지수적으로 재시도한다.
+
+# 브로커 의존성 격리하기
+
+- 브로커는 외부 기관으로 비즈니스 결정으로 언제든지 변경되고 추가될수 있다.
+- 토스 증권에서는 브로커 의존성을 가장 강한 격리 수준인 서버 레벨에서 격리시키고 있다.
+- 브로커가 전문 통신을 지원하든 HTTP요청을 지원하든, 매매 서버는 내부 인터페이스만 맞추면된다.
+- 토스증권 식별자로 상태를 조회할수있게 제공하는 브로커가 추가된다면 전혀 다른 방식의 타임아웃 주문처리를 도메인 로직과는 무관하게 확장 가능한다. 브로커 처리량에 따라서 매매요청서버를 스케일아웃할수있다. 또 브로커 장애가 토스증권 전체장애로 부터 격리가능한 구조가 됐다.
+
+![image-20230711174841823](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711174841823.png)
+
+- 체결 수신 서버는 브로커의 이벤트를 받아, 데이터베이스에 적재하고 kafka에 발송하는 책임을 담당한다.
+  - 따라서 매매서버가 바쁜 상황에서도 브로커의 이벤트를 수신하지 못하는 상황을 방지할 수 있다.
+  - kafka업로드 전에 수신내역을 db에 저장하고 있기때문에 kafka가 다운된다고 하더라도 폴링 모드로 전화하는등 다양한 fil over 전략이 메세지 유실 없이 선택 가능해짐
+  - 중복 이벤트도 유니크 아이디 발급해서 처리한다.
+
+![image-20230711174907280](https://raw.githubusercontent.com/hscom96/ImageStore/main/images/2023/07/11/image-20230711174907280.png)