Post

Posted
By jfhib 6 min read

목차

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로 따로 빼서 선착순만 처리하는 방법?
1
2
3
4
5

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

1
2
3
4
5
6
7
8
9
10

	- 과연 선착순 모듈하나가 부하분산을 모두 감당할 수 있을까?
	- 확장성도 문제가 있음. (이렇게 개발하면 MSA 사용하는 이유가 없다.)

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

1
2
3
4
5
6

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

1
2
3

- 그럼 redis가 모든 부하를 감당해야 하는데, 이 1대의 redis가 이 부하를 감당할 수 있나?
	- 결국 원점으로 회귀함. redis를 사용해도 선착순 모듈처럼 특정 기능이 모든 부하를 감당해야 한다는 단점.
	- Redis Cluster
  • 낙관적 락 / 비관적 락
    • 낙관적 락
      • 충돌이 거의 발생하지 않을 것이라고 가정하고 충돌이 발생한 경우 조치를 취하는 방식이다.
      • 일반적으로 version의 상태를 보고 충돌을 확인하며, 충돌이 확인된 경우 롤백을 진행한다. (hashcode, timestamp를 이용하여 충돌을 확인하는 경우도 존재.) ``` version = 1, id = 1, name = “hwang”, nick = “qwer” 1 req : id 1 의 name을 “lee”로 바꿔. (version = 1) 2 req : id 1 의 nick을 “asdf” 로 바꿔. (version = 1)

동시성 문제 발생 (1 req와 2 req 가 동시에 발생) 1 req -> version = 2, id = 1, name = “lee”, nick = “qwer” 2 req -> 이미 버전이 2로 바뀌어 처리 불가 ``` - 충돌이 발생할 경우에 대한 책임을 Application 단에서 짐, 따라서 충돌 발생 시 Application 에서 수동 Rollback 해줘야 함. - 장단점 - 장점 - 리소스 발생 적음 - 락으로 인한 성능저하가 적음. - 단점 - 충돌 발생 시 처리해야 할 외부 요인 존재

1
2
3
4
5
6
7
8
9
10
11
12

- 비관적 락
	- 충돌이 발생할 확률이 높다고 가정하여, 데이터 엑세스 전 락을 걸어 충돌을 예방하는 방식이다.
	- 공유 락(shared lock) 과 배타락(exclusive lock)이 존재.
		- 공유락 : 다른 트랜잭션에서 읽기만 가능, 배타락 적용 불가
		- 배타락 : 다른 트랜잭션에서 읽기, 쓰기 모두 불가, 공유락, 배타락 모두 적용 불가
	- 장단점
		- 장점
			- 충돌 발생을 미연에 방지
			- 데이터의 일관성 유지
		- 단점
			- 과도한 리소스 비용 발생
			- 비관적 락이 잘못 걸리거나 서로 자원이 필요한 경우 교착상태의 발생 가능성 존재
category
This post is licensed under CC BY 4.0 by the author.