MSA

MSA: Micro Service Architecture

- 단일 작업 단위에 모든 서비스가 있는 모놀리식 아키텍처를 단일 책임을 가지는 적절한 단위의 서비스로 분리한다.

- 분리된 서비스는 UI, 비즈니스 로직, 데이터베이스, 심지어 배포까지 독립적인 구조를 가질 수 있다.

모놀리식 서비스가 왜 문제가 되는가?

- 초기 서비스를 구현할 때에는 빠른 개발 필요성으로 한 서비스에 다수의 비즈니스 모델이 들어간 구조로 개발하기 쉽다.

- 하지만 서비스가 점점 커져가면서 비대해지는 소스코드와 늘어나는 배포 시간이 이슈가 된다.

- 뿐만 아니라 특정 서비스의 성능 이슈가 발생하더라도 전체 서비스의  Scale을 늘려야하는 확장성 이슈가 발생한다.

MS: Micro Service를 구현하기 위해 고려해야할 패턴

1) 핵심 개발 패턴

1-1) 서비스 세분성

- 적정한 크기, 책임을 어느정도로 분리할 것인가?

1-2) 통신프로토콜

- 서버/클라이언트 간의 데이터 교환 방법은 무엇으로 할 것인가?

- 이는 거의 답이 정해진 것이나 다름 없는 JSON을 사용한다.

1-3) 인터페이스 설계

- URL 패턴, 구조는 어떻게 가져갈 것인가?

- 서비스의 인식성을 높이기 위해 URL 네이밍 전략을 어떻게 가져갈 것인가?

1-4) 구성관리

- MS서비스 분리로 인해 분산된 서버환경에서 구성파일을 어떻게 처리할 것인가?

- 보통 외부 Config 서버를 별도로 사용한다.

사용되는 기술: Spring Boot, Spring Cloud Config, Spring Cloud Stream: 비동기 메시징

2) 라우팅 패턴

2-1) 서비스 디스커버리

- 다수의 서버가 구성될 것인데 이를 호출하는 물리적인 IP주소를 추상화한다.

- 다수의 서버가 존재하는 분산환경에서 서비스의 위치를 자동으로 검색할 수 있는가?

- 다수의 서버 중 장애가 발생하는 경우, 가용성 체크는 어떻게 할 것인가?

2-2) 서비스 라우팅

- 단일 진입점을 만들어 표준 서비스 정책(ex 보안, 인가, 인증, 콘텐츠 필터링)을 적용할 수 있다.

- GW역할을 하는 서버를 통해 Load Balancing이 가능해진다.

사용되는 기술: Spring Cloud, Netflix Eureka, Netflix Zuul

3) 회복성 패턴

3-1) 클라이언트측 Load Balancing(부하 분산)

- 별도의 LB 서버가 없어도 클라이언트 측에서 부하 분산을 할 수 있다.

3-2) 회로 차단기 패턴

- 서비스에 장애가 발생시 이후에 들어오는 접근 지연으로 인해 서버 리소스를 모두 사용 되는 현상을 방지한다.

- 따라서, 장애 있는 서비스에 접근을 차단시켜 해당 서버의 리소스를 보호한다.

3-3) 폴백 패턴

- 장애 발생시 대응을 미리 만들어 장애가 발생한 서비스의 접근도 막고, 고객에게 인지할 수 있는 대응도 처리.

3-4) 벌크헤드 패턴

사용되는 기술: Netflix Ribbon, Hystrix

4) 보안 패턴

5) 로깅 및 추적패턴

- 분산된 환경으로 인해 로깅, 서비스 모니터링이 더욱 중요해짐.

6) 빌드&배포 패턴