MSA 와 SOA 비교

MSA와 SOA의 차이점에 대해 알아봅니다. Microservices Architecture From A to Z 를 번역하였습니다.

1. MSA 와 SOA 의 차이점

1) 사이즈

• 어느 범위까지 서비스를 제한할 것인지에 대한 차이가 있다.

• SOA 보다 MSA의 크기가 작다.

• MSA의 경우에는하나의 단일 책임만 가진다.

• SOA는 많은 책임(기능)을 가질 수 있다.

2) 재사용성

• SOA의 목표 중 하나는 결합도에 대한 걱정 없이 컴포넌트들을 재사용하는 것이다.

• MSA의 목표는 의존성을 최대한 줄이는 것이다.

• MSA는 코드를 재사용하더라도 서로 참조하는 경우를 줄이는 것을 지향한다.

3) Communication

• SOA는 Enterprise Service Bus(ESB)를 통해서 서비스 사이 동기화가 일어난다. 이것은 기능 실패나 부하에 좋은 구조는 아니다.

• MSA는 각각의 서비스의 독립성이 보장되기 때문에 fault tolerance에 강하다.

• MSA는 비동기적 communication을 통해 높은 가용성(availability)를 가능하게 한다.

4) Data duplication (데이터 중복)

• SOA는 소스에서 데이터로 동기적이면서도 직접적으로 접근할 수 있게 한다.

• MSA는 지역적으로 접근 가능하기 때문에 민첩하게 해당 기능만을 수행할 수 있으나 duplication(중복성)과 complexity(복잡성)은 증가한다는 단점이 있다.

---

2. MSA 장점

• Independence: Scaling, Failure Tolerance (=Resilience(회복성))

• Small Targeted Team: 개별적으로 개발이 가능하다

• Database의 독립성: 데이터베이스가 독립적으로 운영하기 때문에 하나의 데이터베이스가 불능이 되더라도 다른 데이터베이스는 영향을 적게 받는다.

---

3. MSA 시 고려해야할 점

1) 복잡성 (Complexity)

• 간단한 설계를 할 수 있는 대신, 전체 시스템은 복잡해질 수 있다.

• 분산 시스템이기 때문에 어떻게 세팅을 할지, 데이터베이스는 무엇을 쓸지에 관한 정책적 측면에서 복잡성이 증가한다.

2) 테스팅 (Testing)

• 서비스 사이 의존성이 증가하면 테스팅을 어떻게 해야할지에 관한 고민도 깊어진다.

• 의존 관계 설정 전, 유닛 테스트를 하는 것이 권고된다.

3) 데이터 무결성 (Data Integrity)

• 비즈니스 트랜잭션이 일어날 때, 데이터의 무결성이 보장되어야 한다.

4) 네트워크 부하

• 많은 기능이 서로서로 분리되어 있기 때문에 네트워크 상에서 통신하는 것이 부하를 줄 수 있다.

• 비동기적인 communication이 가능하더라도 이는 시스템의 복잡성을 증가시킬 수도 있다.

---

4. Orchestration vs Choreography

• service들 사이 통신 방법에는 두 가지 종류가 있다 - Orchestration, Choreography

1) 직관적 방법 : REST calls를 통해 메시지 주고 받기

• 서비스 사이 동작하는 직관적 방법에는 서비스들 사이 REST calls 을 통해 message를 주고 받는것이 있다.

• setting 하기는 간편하지만 유지성 측면에서 복잡해진다.
  • 유지성 측면에서 복잡해지는 것은 비즈니스 트랜잭션(일련에 함께 처리되어야 할 일)이 일어날 경우 의존성을 어떻게 처리할 것일까와 관련한 복잡성 증가이다.

2) Orchestration

• 가운데 일을 처리할 순서를 정하고 정리해주는 Orchestrateur 을 두는 것이다.

• Orchestrateur은 다른 서비스에 대한 지식을 가지고 있다.

• fault tolerance 과 동기화된 calls 과 관련된 부하를 여전히 가지고 있다.
  • 순서를 조정하고, 보장한다고 해서 데이터의 동기화까지 보장되는 것은 아니다.

• 시스템이 크게 운영된다면 마치 분산된 monolithic 처럼 운영될 가능성이 있다.

3) Choreography

• 시스템에 의존성이나 latency(부하)가 없다.

• publish-subscribe model 이라고 한다.

• 어떤 action에 필요한 서비스를 구독한다.

• 비동기적으로 작동하기 때문에 서비스의 장애 시, 시스템은 계속 작동하지만 데이터의 일관성은 손실될 수 있다.