21/1/2 TIL

MSA(Micro Service Architecture)

가용성(Availability)

한 서버가 트래픽을 얼만큼 견뎌내는지를 이야기할 때 가용성(Availability)이라는 용어를 쓴다. 기억하도록 하자.

1 Database 1 Microservice

Microservice를 설계할 때는 1 Database 1 Microservice 원칙을 따른다. 이렇게 설계하는데는 크게 두가지 이유가 있다.
1. 예를 들어 주문 데이터 베이스가 있고 주방 서비스와 결제 서비스가 이를 활용한다고 해보자. 여기서 주방 서비스와 결제 서비스가 필요한 데이터의 column은 다를 것이다. 주방 서비스는 해당 주문의 음식종류, 음식점 등의 정보가 필요할 것이고 결제 서비스는 금액, 결제 금액, 결제회사 등의 정보가 필요할 것이다. 이렇게 각각의 서비스가 필요한 column들이 다르기 때문에 하나의 database를 하나의 서비스에 두는 것이다.
2. 다른 하나는 DB의 lock과 연관되어 있다. DB lock이란, 예를 들어 특정 a라는 요소를 1만큼 증가하고 DB에 저장하는 요청이 있다고 가정하자. 만일 연속적으로 2개의 요청이 들어왔다고 하면 더하기 2번한 것이 적용되어 a + 2가 최종 결과가 되어야 한다. 그런데 첫번째 요청이 업데이트 되기 전에 두번째 요청이 데이터를 읽어와 더하기가 한번만 진행될 수 있다. DB에서는 이를 방지하기 위해 자체적으로 어떤 요청이 끝나기 전에 lock을 걸어 특정 작업이 끝날때까지 나머지가 대기하게끔 작업할 수 있다. 여기서 하나의 DB를 공유하고 service A에서 lock을 잡아버리면 나머지 서비스들은 작업을 진행하지 못한채 멈추어 있어야 한다. 이러한 이유로 하나의 마이크로 서비스에 하나의 DB를 두는 방식을 사용한다.

SAGA

SAGA는 분산 transaction문제를 해결하기 위해 고안된 해결책이다. 아래의 그림을 보자.

여기서 t1, t2, t3는 원래 transaction이고 c1, c2, c3는 보상 transaction이다. 만약 t1이 성공하고 t2가 실패하면 c2 -> c1 순서로 보상 transcation이 진행되면서 db가 복구된다. 이렇게 SAGA에서는 보상 transaction을 통해서 분산 transaction 문제를 해결한다. 같은 DB안에서는 transaction 보상되게 할 수 있기에 보상 transaction이 실패하는 것을 걱정할 필요는 없다.

MSA는 만병통치약이 아니다.

요새 MSA가 유행이다보니, 많은 개발회사들이 MSA를 적용하려한다. 하지만 MSA는 회사 사정에 맞게 신중하게 적용해야한다. 대개 비즈니스 모델이 안 바뀌는 경우에 MSA를 적용하는게 좋다. 핵심적인 로직들이 크게 바뀔 필요가 없기 때문이다. 그런데 아직 비즈니스 모델이 안정적이지 못해 계속 바뀐다면 MSA가 오히려 걸림돌로 작용할 수 있다. 핵심 로직이 자주 바뀌어 MSA의 모든 서비스를 손봐야될 수도 있다. 따라서 MSA도 상황에 따라 서비스의 불안요소가 될 수 있으면 오히려 monolithic하게 서버를 구성하는게 더 나을수도 있다.