[MSA] MicroService, SoA

- MSA 공부하면서 인프라적 지식이 부족한 것 같아서 개념 정리를 진행하였다.

- 아마 조금 더 공부하면서 작성해나가야 될 것 같다.

 

---

✔️ SoA (Service Oriented Architecture)

• 서비스 지향 아키텍처
• 애플리케이션 컴포넌트 기반, 각 컴포넌트는 일종의 개별 서비스로 구성
• 애플리케이션을 3개의 레이어로 나누었을 경우
  • 프레젠테이션 레이어
    • 사용자 UI 제공
  • 비즈니스 레이어
    • 비즈니스 로직 구현
  • 데이터 레이어
    • 도메인 모델 관리 및 DB 접근
• 결국, 각 서비스는 일종의 비즈니스 로직의 구현체라고 볼 수 있다.
• 서비스 단위로 개발을 진행하여 개발된 서비스를 공유하여 재가용성을 늘리는 것.

 

--

 

✔️ MicroService with SoA

• 마이크로 서비스에서 각 서비스들은 완전히 분리되어 있기 때문에, 완전히 별도의 모듈로서 동작이 가능하다.
• 마이크로 서비스를 잘 사용하면 서비스 확장의 최적화가 가능하다.
• 주의) 마이크로서비스는 SoA지만, 모든 SoA를 마이크로서비스라고 할 수 없다.
  • SoA에서는 개발한 서비스를 유연하게 사용하기 때문에 재사용할 수 있어 효율성을 따지지만, MSA에서는 비교적 독립성을 더 강하게 띄운다.

--

 

✔️ Enterprice Service Bus (ESB)

• 각 레이어가 분리되면서, ‘관심사의 분리(SoC)’라는 핵심 키워드가 떠오르게 되었다.
• 이때, 단순히 소프트웨어뿐만 아니라 아키텍처 역시 분리해야 하는데, 사용되는 기준으로서 엔터프라이즈 서비스 버스 (ESB)가 사용될 수 있다.
• ESB란 서비스 조정, 매핑, 라우팅을 담당하는 소프트웨어 컴포넌트로, 각 비즈니스 도메인에서 데이터를 가져와서 비즈니스 규칙을 기반으로 하여 새로운 서비스를 생성한다.
  • 즉, 애플리케이션을 통합하는데 쓰이는 일종의 미들웨어라고 할 수 있다.

--

 

✔️ MicroService의 설계 원칙

• 비즈니스 역량 중심 모델
  • 마이크로서비스 업데이트 및 수정 시 기존에 정의했던 개념으로 추상화를 진행해야 된다.
• 느슨한 결합
  • 각 서비스 간의 상호작용을 구현하기 위해서는 느슨하게 결합해야 한다.
  • 마이크로서비스에서는 자신의 도메인 내에 있는 정보만 반환해야 한다.
• 단일 책임
  • 단일한 부분에 대한 책임만 가져야 하며, 마이크로서비스에 의해서 완전히 캡슐화되어야 한다.
• 구현 은닉
  • 내부 세부 사항은 노출되어서는 안 된다.
• 격리
  • 시스템 인프라나 물리적으로 분리되어야 한다.
• 독립적인 배포
  • 각 서비스는 독립적으로 배포가 가능해야 한다.
• 실패를 위한 빌드
  • 장애 발생 시 최대한 매끄럽게 처리하도록 구성해야 하며, 복구 방안을 정의해야 한다.
  • UpStream: 소비자에게 어떻게 오류를 알릴 것인지, 혹은 알리지 않을 것인지 정의
  • DownStream: 타 서비스나 DB 장애 발생 시 어떻게 대응할 것인지 정의
  • Logging: 로그의 빈도, 정보의 양, 액세스 방법 고려
  • Monitoring: 애플리케이션의 요소에서 의미 있는 정보 고려
  • Warning: 이상 현상에 대한 연관 분석 필요
  • Recovery: 장애 발생 시 어떻게 정상 상태로 되돌릴 수 있는가
  • Rollback: 외부 서비스의 장애 상황에 대비한 롤백 매커니즘의 제공
• 확장성

• 왼쪽에서 ‘추천’이라는 기능을 추가한다고 했을 때 전반적인 결합도를 낮추기 위해 인스턴스 수를 늘리고 애플리케이션을 확장한 모습이다.
• 자동화
  • 자동화된 CI/CD 구축 필요

--

 

✔️ DDD (Domain-Driven Design)

• 도메인 주도 설계란, 핵심 도메인으로 경계지어진, 진화하는 복잡한 모델을 다루는 소프트웨어 개발 방안이다.
• 모델이 적용되는 일종의 컨텍스트를 정의하여, 애플리케이션의 특정 부분에서 사용되거나 DB 스키마 같은 명시적인 경계를 설정하여 모델을 일관되게 유지해야 한다.
• 그렇기 때문에, 개발자↔사용자간의 공통적, 엄격한 언어를 구축해야 한다.
  • 도메인 모델뿐만 아니라 도메인 로직, 아키텍처에서도 유비쿼터스 언어가 사용되어야 한다.

---

 

✔️ Bounded Context (경계된 컨텍스트)

• 도메인 주도 설계에서는 모델을 일종의 경계된 컨텍스트로 구분하여, 외부와 분리되어 경계 안의 지식이 일관되게 유지된 형태를 의미한다.
• 각 컨텍스트는 다른 컨텍스트와 직접적으로 연관된 종속성을 가지지 않는다.
  • 물론, 아예 가지지 않는 건 아니더라도 약한 결합 관계를 추구한다.

---

 

✔️ MicroService with DDD

• 마이크로서비스의 각 서비스는 하나 이상의 경계된 컨텍스트를 포함해서는 안 된다.
• 마이크로서비스에서 사용되는 언어는 유비쿼터스 언어여야 하기 때문에, 노출된 오퍼레이션과 인터페이스는 컨텍스트 도메인 언어로 표현이 되어야 한다.
  • 즉, 마이크로서비스가 사용하는 모든 모델은 경계된 컨텍스트 내에서 정의되고, 유비쿼터스 언어를 사용해야 되며, 전체 시스템에서 의존성 / 결합도를 파악하기 위해 매핑 관계를 꼼꼼히 살펴야 한다.

---

 

✔️ Reactive Programming

subscribe(::getData).whenDone(::print)

• 일종의 작업을 구독하고, 작업이 완료되었을 때 그 결과를 다른 작업에 보낸다.
• 이때, 해당 구문 이후에도 블록킹 되지 않고 프로그램이 계속되어 다른 것들을 처리할 수 있기 때문에 논블록킹 작업으로서 동작한다.
• 리액티브 시스템은 비동기 메시징을 활용하기 때문에 느슨하게 연결된 컴포넌트를 통해 격리된 시스템을 상호 연결할 수 있다.
  • 하나의 서비스는 정보를 얻기 위해 다른 서비스를 구독하고, 다른 서비스는 또 달느 서비스를 구독하여 데이터를 결합하고… 원래 서비스로 반환하는 등 그러한 작업을 수행할 수 있다.

---

 

✔️ IaaS vs PaaS vs SaaS

• IaaS (Infrastrcture as a Service)
  • 가장 기본적인 클라우드 서비스 모델
  • 클라우드 사용자가 직접 플랫폼에서 생성된 여러 서버를 유지 및 관리해야 한다.
  • ex) 아마존 웹 서비스, 마이크로소프트 애저 VM…
• PaaS (Platform as a Service)
  • 고객이 유지보수할 필요 없이 애플리케이션 개발 및 실행, 관리가 가능하다.
  • ex) 구글 앱 엔진, IBM 블루믹스, 마이크로소프트 애저 클라우드 서비스…
• SaaS (Software as a Service)
  • 사용자가 애플리케이션 소프트웨어에 액세스할 수 이싿.
  • 소프트웨어 실행에 필요한 모든 요소는 플랫폼 내부에서 관리되며, 사용자는 서비스 제공자가 모든 것을 관리하기 때문에 관리할 필요가 아무것도 없다.
  • ex) 마이크로소프트 오피스 365…