MSA 발표할때 작성했던 내용들이다..
MSA는 보통 모노로틱 아키텍처로 시작한 서비스가
너무나도 거대해졌을때 서비스를 경량화하고자 할때 도입되는 아키텍처이다.
모노로틱 아키텍처는 뭐고 MSA는 뭔지
왜 생겨났는지, MSA를 하려면 어떤 것들을 고려해야하는지
MSA 할때 꼭 나오는 개념인 디스커버리 서버 및 API gateway는 뭔지 정리해두었다.
모노로틱 아키텍처
- 대부분의 기업용 애플리케이션은 하나의 거대한 서비스 형태로 개발됨
- 하나의 애플리케이션 내에 모든 로직이 들어가 있는 ‘통짜 구조’
- 하나의 WAR 파일에(웹 앱 패키징파일) 관리,상품,주문 관리 모든 컴포넌트가 들어가있음.
장점
- 개발환경이 같아 서버 복제가 쉬움
- 고가용성 서버 환경을 쉽게 만듬
- 작은 규모의 서비스에서부터 개발하기가 쉬움
문제점
- 하나의 기능 업데이트시 모든 기능을 반복적으로 재구성하고 배포/테스트 해야함
- 하나의 소스 레포에서 다수의 개발자가 각각 버그 수정하기가 점점 힘듬
- 새로운 기능을 전세계적으로 동시에 적용해야하는데 그에 따른 인프라 성능 확장이 매우 힘듬
MSA의 등장
- API gateway, discovery server, 메시지 버스등의 등장
- 각각의 기능을 독립적으로 적용 및 확장 가능
- 서비스마다 각 DB를 참조함
- 경량화되고 독립적인 여러 개의 서비스를 조합하여 애플리케이션 구현 → 빌드/배포가 효율적으로 수행됨
- 나누어진 서비스, 인스턴스 수만큼 관리 대상이 늘어남
- 서비스간 복잡한 연결 구조 때문에 장애 추적이 어렵고 타 서비스를 호출하는 로직에 장애가 전파될 수 있음 → 서비스 메시를 사용하여 마이크로서비스간에는 직접 통신을 안해도 되게 함.
서비스 경량화 고려사항
MSA를 보통 도입한다고 했을때에는 해당 서비스가 아주 아주 큰 서비스일 경우이다.
무작정 쪼갠다고 MSA가 될 수는 없다. 그래서 존재하는 고려사항들을 알아보자.
1) 단위 서비스로 쪼개기
- 도메인 주도 설계 (Domain Driven Design)
- 객체지향설계와 기본 사상은 비슷하지만 객체와 달리 ‘업무’의 범위
- 도메인은 행위를 포함하며 SW 이용자가 다루는 모든 것을 의미함
2) 분리된 서비스의 통합 관리
- 업무 단위로 분리된 경량화된 서비스들간의 통신은 어렵다.
- 전체 서비스를 관리하는 서비스 메시 기반의 아우터 아키텍처가 필요함
- 서비스 메시란?
Configuration Management
|
서비스 디스커버리 서버(Service Discovery Server) - Eureka
- 클라우드 환경이 되면서 서비스가 오토 스케일링에 의해 동적으로 생성되거나 컨테이너 기반의 배포로 인해 IP가 동적으로 변경되는 일이 잦아짐
- 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치(ip 주소와 포트)를 알아낼 수 있는 기능이 필요한데 이를 서비스
- 서비스 인스턴스들이 생성이 될때, 서비스에 대한 주소를 서비스 레지스토리에 등록해놓는다(서비스 등록 서버)
- 서비스 A를 호출하고자하는 클라이언트는 서비스 레지스트리에 서비스 A의 주소를 물어보고 등록된 주소를 받아서 그 주소로 서비스를 호출함
클라이언트 사이드 디스커버리 vs 서버 사이드 디스커버리
- 클라이언트 사이드 디스커버리 : service registry에서 서비스의 위치를 찾아 호출하는 방식
- 다른 방법 : 서비스 앞에 proxy 서버 (로드밸런서)를 넣는 방식. 서비스 클라이언트는 이 로드밸런스를 호출하면 로드밸런서가 서비스 레지스트리로부터 등록된 서비스의 위치를 리턴하고 이를 기반으로 라우팅함
Service Registry 구현 방식
- 가장 쉬운 방법으로 DNS 레코드에 하나의 호스트명에 여러개의 IP를 등록하는 방식으로 구현 가능함 → DNS는 레코드 삭제시 업데이트 되는 시간이 소요됨
- 솔루션 → ZooKeeper, etcd 서비스 / 서비스 디스커버리에 전문화된 솔루션 : 넷플릭스의 Eureka, Hashcorp의 Consul
서비스 메시
- SOA의 ESB와 유사함
- 서비스가 애플리케이션 수명 주기 전반에 걸쳐 데이터와 일관성을 공유하며 서로 통신할 수 있도록 지원하는 사전 구성된 애플리케이션 서비스
- 보통 서비스 앞단에 경량화 프록시를 사이드카 패턴으로 배치
- 프록시에 Routing rules, retry, timeout 등을 설정
사이드카 패턴
- 모든 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포함
- 서비스에 들어오거나 나가는 모든 트래픽을 처리함
- 병렬로 배치되어 타 서비스를 직접 호출하는 것이 아니라 프록시를 통해 호출함
- 별도의 작업 없이 서비스 간의 연결 및 로깅/모니터링/보안/트래픽 제어가 가능
클라우드 네이티브와 쿠버네티스의 등장
- 기존 시스템을 클라우드 환경으로 이전하는 추세 → 클라우드 네이티브(클라우드 기반 개발)
- 쿠버네티스 : 다수의 컨테이너에 애플리케이션 서비스를 올려 수많은 서비스를 운영함. 컨테이너 관리 및 서비스간 통신의 필요성
장점
- 기능을 애플리케이션 외부에 구현하며 재사용 가능
- MSA를 도입하며 발생한 런타임 복잡성 이슈를 해결
- 어플 개발시 언어와 미들웨어 등에 종속성 제거
- polyglot 프로그래밍 보장
단점
- 시스템의 런타임 인스턴스 수가 크게 증가함
- 서비스 간의 통신에 네트워크 레이어가 추가됨 → 오버헤드 발생 가능, 리소스 소모
Service Mesh를 적용하는 이유?
- 모놀리틱 → MSA로 전환하면서 단점도 많이 생김 (런타임 복잡성)
- 분리되어있는 서비스간의 통신에 대한 어려움. 데이터 통합도 복잡함
- 인스턴스의 증가
- 운영환경에 따라 수백~수천개의 서비스 인스턴스가 동작함. 각 서비스들의 인스턴스를 오토 스케일링하며 동적으로 띄우고 내림. 각 인스턴스를 모니터링, 로깅을 처리하고 관리해야한다.
- 서비스간 통신
- 수많은 인스턴스의 동적인 관리를 안정적으로 하기 위해 서비스 메시가 필요함
서비스 메시의 기능
- Service Discovery
- Load Balancing
- Dynamic Request Routing
- Circuit Breaking
- Retry and Timeout
- TLS
- Distributed Tracing
- metrics 수집
API Gateway
- API 간의 보안 연결을 유지 , 회사 내외부에서 로드 밸런싱을 포함한 API 트래픽 관리
- 여러 백엔드 서비스를 호출하고 결과를 집계
- 고객은 각 개별 서비스에 요청을 보내는 대신 API 게이트웨이로 보내면 됨
API Gateway 사용이유?
- MSA의 증가로 API Gateway의 사용도 증가
- 고객이 애플리케이션에 빠르고 안전하게 액세스하기가 어려움
- 고객이 마이크로서비스에 대한 액세스를 개별적으로 요청하는 대신 게이트웨이는 요청에 대한 단일 진입점이 된다.
- 해당 요청을 적절한 서비스에 보내고 결과를 수집하여 사용자에게 전달 (라우팅) → 트래픽 관리의 용이
API Gateway 기능
- 인증
- 고객이 여러 서비스의 데이터에 접근할때도 게이트웨이에서 한번만 인증하면 됨 → 대기시간이 줄고 애플리케이션 전체에서 인증가능
- 메트릭 수집
- 모든 요청이 게이트웨이를 통과하므로 데이터 수집에 용이. 트래픽 관리의 용이, 너무 많은 요청 전송시 거부
- 입력 유효성 검사
- 요청시 필요한 필수정보 및 형식 확인
- 응답 전환
- 요청에 대한 올바른 응답으로 전환함. (정보를 응답할때 서비스는 xml을 제공하는데 요청자는 JSON을 원할때 변경 가능. )
장점
- 단일 인터페이스 접근 방식 → API 시스템 안전 보장
- 보안, 접근 제어, 라우팅 관리 가능
참고
https://www.samsungsds.com/kr/insights/service_mesh.html
'Computer Engineering' 카테고리의 다른 글
| Sentry Slack에 붙여서 에러 로깅하기 (1) | 2022.10.31 |
|---|---|
| Nginx를 이용한 무중단 배포 시스템은 진짜 무중단일까? (2) | 2022.08.08 |
