Microservice Architecture Structures
MSA 표준 구성 요소
마이크로 서비스는 독립적으로 배포되고 확장될 수 있는 서비스들을 조합해서 하나의 거대한 어플리케이션을 구성하는 아키텍처 패턴이다.
이런 마이크로 서비스를 지원하고 관리하기 위해서 일반적으로 여러 서비스 디스커버리, api gateway, 오케스트레이션, context boundary 등의 서비스를 연계해 사용하게 된다.
위 사진은 2018년도 가트너라는 시장조사 기관에서 발표한 내용인데, 넷플릭스, 트위터, 나이키, 아마존 등의 회사에서 채택한 아키텍처이다.
위 사진에 대해 분석해보자면,
- 왼쪽에 클라이언트(Mobile App, Brower App)가 있고, 다른 서비스들(Other Services)도 있다.
- 그리고 이런 클라이언트들과 다른 마이크로 서비스들이 “API 게이트웨이” 라는 진입점을 통해 필요한 서비스에 요청을 하게 될 것이다.
- API 게이트웨이에서 수집된 클라이언트들의 요청은 “서비스 라우터”에게 어디로 가야할 지 질문한다.
- 필요한 마이크로 서비스가 어디에 저장되어있는지 “서비스 디스커버리”에 물어본다.
- 중간 쯤 보이는 남색 직사각형이 마이크로 서비스들인데, (A와 B라는 마이크로 서비스는 모두 2개의 인스턴스로 나뉘어져 있다.)
이러한 마이크로 서비스들이 어디에 존재하는지 “서비스 디스커버리”가 위치를 검색했다고 하면,
그 다음으로, “로드 밸런서”가 어떠한 서비스로 보내줄 것인지 결정한다. (일반적으로 “서비스 라우터”와 “로드 밸런서”를 하나의 시스템으로 묶어서 사용하는 경우도 있다.)
- 마이크로 서비스 안에 있는 “환경설정(Config Store) 정보”는 외부 시스템에 저장하여 사용하는게 일반적이다.
- 마이크로 서비스는 컨테이너 가상화 기술을 통해 구성되어있다.
- 완성되어진 어플리케이션을 배포를 하기 위해 CI/CD 라는 Authmation 기술을 사용할 수 있다.
- CI/CD를 통해 배포를 하고자 할 때에는 관리자 혹은 DevOps 관련 사용자가 사용할 수 있도록 API가 공개되어 있어야 한다.
- Backing Service는 마이크로 서비스에 저장되어있는 다양한 스토리지들을 모아서 사용할 수 있는 방법이며, 메시징 처리 시스템(MOM)을 통해 하나의 서비스와 다른 서비스가 연결될 수도 있다.
- Telemetry는 마이크로 서비스의 모니터링 기능과 진단기능을 가지고 있다.
위 사진의 상단 부분을 보면, “Service Mesh”라는게 있다.
Service Mesh는 Servie Discover, Service Router, Load Balancer 등을 가지고 있는데, 아래에서 더 자세히 보도록 하자.
Service Mesh Capabilities
Service Mesh는 마이크로 서비스 아키텍처를 적용한 시스템의 “내부 통신”을 말한다.
Service Mesh를 통해 서비스 간의 통신을 추상화하고, 안전하고 빠르게 만들어주는 infra structure의 layer라고 볼 수 있다.
이런 추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고,
내부 네트워크와 관련된 로직을 추가함으로써 안전성, 신뢰성, 탄력성, 표준성, 가시성, 보안성 등을 확보할 수 있게 된다.
Service Mesh는 uri 경로라던가 호스트의 헤더, api 버전 혹은 기타 응용 프로그램의 규칙을 기반으로 하는 “네트워크 레이어” 이고,
Service Mesh의 구체적인 경량화 프록시를 통해 다양한 라우팅 기능이라던가 서킷 브레이커(Circuit breaker) 같은 공통 기능을 설정할 수 있다.
이것은 서비스 간 통신에 연관된 기능 뿐만 아니라, 서비스의 배포 전략에도 도움을 줄 수 있다.
위 사진에서처럼 Service Mesh에는 설정 정보(Configuration), 라우팅(Routing), 인증 관련 정보(AuthN/AuthZ), 로드 밸런싱 기능(Load Balancing), 탄력성(Resiliency), 서비스에 대한 검색(Discovery), 암호화(Encryption) 등의 서비스를 통해,
마이크로 서비스의 개발과 응용을 지원하고 있다.
Service Mesh는 하나의 제품이라던가 서비스를 지칭하는 것이 아니라, 추상적인 개념인 것이다.
Service Mesh라는 계층에서 위에서 설명한 다양한 기능(서비스)를 제공해줌으로써, 안정적이고 효율적인 마이크로 서비스를 지원하는데 그 목적이 있다.
CNCF (Cloud Native Compouting Foundation)
마이크로 서비스는 독립적으로 배포되고 확장할 수 있다고 했다.
CNCF를 통해 각각의 독립적인 구성 요소가 어떻게 구성되었는지 살펴볼 수 있다.
위 사이트에서, 클라우드 네이티브를 구축함에 있어서 서로 interactive 하게 상호 연관될 수 있는 서비스들이 어떤게 있는지 확인할 수 있다.
큰 네모는 CNC에서 자체적으로 가지고 있는 프로젝트이고, 그 외적으로 작게 보이는 네모는 타사 제품의 서비스들이다.
유료 서비스와 무료 서비스가 포함되어있고, 이러한 클라우드 관련된 기술들을 각각 잘 조합하게 되면,
서비스를 개발, 운영, 배포 하는데 있어서 조화롭게 쓸 수 있는 일종의 가이드이다.
MSA 기반 기술
MSA를 개발하는데 사용되는 기술에 대해 알아보자.
위 사진에서 보이는 것 처럼,
크게 분류하자면 Gateway, Service Mesh, Runtime, Backing Services, Frameworks, Automation, Telemetry로 구분 지을 수 있다.
아래는 각각의 분류에서 많이 사용되는 기술들을 정리한 것이다.
- Gateway
- Nginx, Kong, apigee, Netflix OSS Zuul - Service Mesh
- Istio, Zookeeper, Netflix OSS - Runtime
- Docker, Kubernetes - Frameworks
- Spring Boot, Spring Cloud - Backing Services
- database, NoSQL, Messaging Service, Kafka, Redis, MongoDB - Automation (배포)
- Gradle, Maven, Jenkins - Telemetry (시각화)
- ELK, DataDog
💛 개인 공부 기록용 블로그입니다. 👻