👨‍👧‍👦 MSA에 대해..

🌍 Monolith vs Microservices

Microservice Architecture는 정반대되는 개념인 Monolith Architecture와 같이 설명할 때 그 이해가 훨씬 빠르다고 할 수 있다.

● monolithic 

• 모든 업무 로직이 하나의 어플리케이션 형태로 패키지 되어 서비스를 진행한다.
• 어플리케이션에서 사용하는 데이터가 한 곳에 모여 참조되어 서비스되는 형태를 뜻한다.
• 데이터 베이스 또한 하나의 데이터베이스에서 모든 데이터를 저장한다.

문제점

서비스들중 하나의 문제만 발생하더라도 그것을 수정하고 전체 어플을 다시 빌드하고 테스트에 패키징까지 하는 데 이는 시간과 비용이 너무 크다는 것이다.

 

● microservice 

• 비즈니스 기능 중심 구축 / 완전히 자동화된 배포 시스템을 갖추고 있다
• 최소한의 중앙집중식 방식이고 각 서비스 별로 최적의 프로그래밍 언어와 DB를 다양하게 사용할 수있다.
• 각 서비스들은 Restful API등을 이용해서 서로의 데이터를 제공한다.

이해하기 쉬운 방식인 그림으로 가져왔다

 

특징

1. 기존의 개발 방식을 바꿔야 한다.
2. 독립적으로 배포 가능한 작은 서비스로 이루어저야 한다
3. 어플리케이션을 구성하고 있는 전체 도메인의 지식에 따라 서비스 경계를 잘 구분해야 한다.
4. 각각의 서비스는 서로의 상태에 대해서 REST API 통신을 해야한다
5. ms가 가지고 있는 환경 정보는 외부에 있는 시스템을 통해 관리한다.
6. Cloud Native기술을 최대한 활용한다
7. 서비스를 제공하는 인스턴스들은 부하 분산 처리나 scale-up, scale-out 등을 동적으로 처리한다
8. 자동화 배포가 중요하다
9. 시각화해서 관리되어야 한다.

도입전 고려 사항

MSA를 도입 할때 어떤 방식으로 도입하는 것이 좋을까?

1. 기존의 개발 대비 어느정도의 변경이 생길 것인가
2. 서비스 경계가 독립적으로 잘 만들어 질 것인가
3. 서비스 유지보수 및 확장성이 잘 될 것인가
4. 한개의 서비스 오류는 다른 서비스에도 영향이 가지 않게 할 수 있을 것인가
5. 서비스 간의 종속성을 최소화하고 각 서비스의 응집력은 높일 수 있는가?
6. 여러가지의 언어와 데이터 기술을 지원하는가

 

 

🌍 SOA 와 MSA 의 차이점

우선 두가지의 공통점은 서비스를 지향한다는 점이다. 하지만 큰 차이점이 바로 목표인데

 

Sevice Oriented Architecture ( SOA ) - 서비스를 재사용하여 비용을 절감한다

• 공통의 서비스를 '서비스 버스(ESB)' 라는 개념을 통해 모아서 하나의 서비스 형태로 만들었다 ( 서비스 공유  최대화 )

Microservice Architecture ( MSA ) - 서비스 간의 결합도를 낮추어 변화에 능동적인 대응을 하였다

• 독립된 서비스가 노출된 REST API를 사용해서 서비스를 공개하는 것이다. ( 서비스 공유 최소화 )

 

REST API 의 성숙도 모델

가장 높은 3단계는 API 서비스의 모든 endPoint를 최초 진입점이 되는 URI를 통해 Hypertext Link 형태로 제공을 한다

3단계는 단순히 API 목록을 제공할 뿐 아니라, 어떤 request의 다음 request에 필요한 endPoint를 제공한다는 것이다

 

※ HATEOAS(하테오스)

REST의 근본적인 아이디어 중 하나로, 클라이언트가 서버로부터 리소스와 함께 관련된 동작을 얻을 수 있도록 하는 것이다. 이를 통해 URI를 하드 코딩하지 않고도 API를 탐색하고 상호작용 할 수 있다.

Level 3의 RESTAPI방식을 사용하는 방법인것이다.

 

🌍 MSA Structure

• 클라이언트(Mobile, Browser 등)는 API Gateway를 통해 필요한 서비스를 요청한다
• API Gateway는 Service Router에서 해당 요청이 어디 서비스에 있는지 묻고 어디에 저장되어 있는지는 Router가 Discovery에 묻는다.
• 향해야하는 방향을 알아낸 Gateway는 해당하는 Instance(진한 남색)에게 정보를 요청하게 된다.
  • 여기서 만약 AInstance안에 여러개로 분산된 형태로 구성이 되어 있다면 Load Balance를 통해 해당 하는 곳으로 이동한다. (일방적으로 Router 와 LoadBalance를 하나로 묶어 사용하는것을 선호한다)
  • 또한 가상화로 구성되어 있는 인스턴스들의 환경설정은 Config.Store라는 외부 시스템에서 일정하게 관리하고 있다
• 완성된 어플리케이션은 CI/CD를 통해 관리되고 이는 Sevice Dev같은 관리자가 관리할 수 있게 만들어진다.
• BackingServices 는 서비스에 저장되어 있는 다양한 스토리지들을 모아서 사용할 수 있다.
• Telemetry 는 모니터링을 할 수 있는 서비스이다.

 

※ Service Mesh

Service Mesh란 MSA 에서 서비스 간의 통신을 관리하기 위한 인프라 계층이다. 

 

• MSA 인프라 ▶ 미들웨어
  • 프록시 역할, 인증, 권한 부여, 암호화, 서비스 검색, 요청 라우팅, 로드 밸런싱 등과 같은 측면에서 관리한다

 

※ CNCF(Cloud Native Computing Foundation) 

• Cloud Native 를 구축할 때 사용되는 서비스들을 명하는 말이다.

 

🌍 Spring Cloud

Java를 주로 사용하는 사람들은 자연스럽게 Spring의 다양한 Framework를 사용하게 된다. Spring Cloud또한 그 중 하나로써 마이크로서비스 아키텍처를 지원하기 위해 등장한 Framework이다

환경 설정 관리, 서비스 검색, 회복성 처리, 라우팅, 프록시 등등 서비스를 사용함에 있어 필요한 분산 시스템을 사용해서 빠르게 어플리케이션을 만드는데 목적을 둔다.

 

 

Spring Cloud를 사용하면 어떤 서비스가 사용될까 ( 사용하고자 하는 사람만 보기..)

• Centralized configuration management ( 환경설정 )
  • Spring Cloud Config Server - 다양한 서비스에서 사용하는 어떠한 정보를 해당 서비스를 통해 외부에 저장소에 환경 설정 정보를 넣을 수 있다. 추후에 다양한 서비스는 해당 서비스를 이용해 데이터를 가져오면 된다.

• Location transparency ( 서비스 등록, 위치 정보 확인 )
  • Netflix Eureka
• Load Distribution ( Load Balancing ) - 서버의 요청을 분산
  • Ribbon ( Client Side )
  • Sprign Cloud Gateway

해당 사진은 Ribbon 이지만 Gateway라고 봐도 무방하다

• Easier REST Clients - 각각의 마이크로 서비스의 데이터 통신을 위해 FeignClient 사용
• Visibility and monitoring - 시각화와 모니터링 서비스
  • Zipkin Distributed Tracing
  • Netflix API gateway
• Fault Tolerance - 장애 복구
  • Hystrix