목차

---

content

Micro Service Architecture

• 동시성 처리 (따닥 해결 방법에 대해 고민해 볼 것)

  • 로드밸런싱
    • 로드밸런싱에서 IP 단위로 부하분산을 시도하면 되는 것 아닌가?
      • IP 단위로 로드밸런싱 시도 시 항상 동일한 서버에 요청됨.
      • 네트워크 구축 방식에 따라 특정한 IP 대역으로 몰릴 경우 해당 방법은 사용이 불가할 수도 있음.
        • 모든 요청이 하나의 서버로 몰릴 것이기 때문.
    • 그렇지 못할 경우 (tcp client port 등을 기준으로 로드밸런싱하면?)
      • 분산 락을 사용하여 해결하는 방법
  • 분산 락
    • 따닥
      • 레디스의 분산 락과 GC
        • Java Garbage Collection의 Stop The World
          • GC 종류
            • stop the world
          • GC 튜닝 (stop the world를 최소한으로)
      • 와디즈 사의 분산 락 장애 예시 https://blog.wadiz.kr/%EB%B6%84%EC%82%B0-%ED%99%98%EA%B2%BD-%EC%86%8D%EC%97%90%EC%84%9C-%EB%94%B0%EB%8B%A5%EC%9D%84-%EC%99%B8%EC%B9%98%EB%8B%A4/
      • Redis의 Redisson

• 동시성 처리 (선착순 이벤트(선착순 100명 버튼)을 개발하는 방법)

  • 선착순 기능을 API로 따로 빼서 선착순만 처리하는 방법?

      a b c d (web server)
      \ \ / /
         |
         |
         e    (선착순 기능)
    

    • 과연 선착순 모듈하나가 부하분산을 모두 감당할 수 있을까?
    • 확장성도 문제가 있음. (이렇게 개발하면 MSA 사용하는 이유가 없다.)
  • 이것도 레디스에서 분산 락으로 처리할 수 있을까?
  • 레디스는 원자성을 보장하니 레디스에서 일괄적으로 체크하면 가능은 함.
    • https://dkswnkk.tistory.com/712
  • incr 을 통해서 1씩 증가하게 만들면 될 듯 하다.
    • 만약 선착순을 1인당 1개씩만 가능하도록 막아버린다면, 이 방법을 사용할 수 있을까?
    • key-value를 사용해 사용자가 이미 받았는지 체크하자.
    • 예상 시나리오

      transaction
      -> 사용자가 100을 넘었는가?
          -> yes : return err (101)
      -> <user> key 조회해 이미 받았는지 체크
          -> 있나? -> return err (0 or -1)
      -> incr 이후 return incr된 값
    

  • 그럼 redis가 모든 부하를 감당해야 하는데, 이 1대의 redis가 이 부하를 감당할 수 있나?
    • 결국 원점으로 회귀함. redis를 사용해도 선착순 모듈처럼 특정 기능이 모든 부하를 감당해야 한다는 단점.
    • Redis Cluster