티스토리 뷰
클라우드 네이티브 아키텍처의 도입을 위해 애플리케이션은 기본적으로 마이크로서비스 아키텍처의 형태로 개발이 진행되어야 합니다. 그 이유는 클라우드 컴퓨팅 모델의 확장성과 유연함을 잘 살릴 수 있고 유지보수나 변경점을 적용하는 데 있어 훨씬 유리하기 때문입니다. 마이크로서비스 아키텍처가 무엇인지, 해당 아키텍처의 도입이 꼭 필요한지, 필요하다면 어떤 조건을 확인해야 하는지 정리하고자 합니다.
Architecture
Monolith
초기 애플리케이션의 아키텍처 구조는 하나의 커다란 소프트웨어에 애플리케이션에 필요한 모든 요소를 포함했습니다. 클라이언트에게 보여지는 프론트 로직, 데이터를 담당하는 DB 로직, 실질적인 비즈니스 로직 등 모든 요소가 단 하나의 소프트웨어에 존재하였습니다. 사진에서 확인할 수 있듯이 하나의 커다란 건축물과 같았습니다.
모든 것이 하나의 소프트웨어에서 관리되기 때문에 하나의 작은 기능이라도 변경되면 전체 애플리케이션을 다시 패키징하고 배포해야 했고, 개발팀이 개발을 진행하는 데 있어 형상 관리에도 적지 않은 어려움이 존재하였습니다. 작은 실수로 인해 전체 애플리케이션이 무너질 수 있는 상황까지 존재했습니다.
Front & Back
이를 개선해보고자 나온 것이 Front & Back 구조입니다. 클라이언트에게 보여지는 프론트엔드 부분과 비즈니스 로직을 담당하는 백엔드 부분을 분리하여 개발을 진행하는 것을 의미합니다.
대표적으로 모바일 애플리케이션 개발에 많이 사용되는 방식으로 프론트 개발팀과 백엔드 개발팀의 별도 개발 진행이 가능하고, 백엔드 개발팀에서는 프론트 개발팀에서 사용할 수 있도록 인터페이스 형식으로 기능을 제공합니다. 가장 큰 장점은 배포 시 백엔드 로직까지 같이 배포할 필요가 없으므로 클라이언트가 사용하는 애플리케이션이 경량화되었다는 점입니다. 또한 영역이 분리되어 있기에 문제가 발생했을 때 어느 영역에서 발생했는지 쉽게 찾을 수 있고 Monolith에 비해 애플리케이션에 미치는 파급력이 작습니다.
하지만 여전히 프론트엔드, 백엔드라는 테두리 안에서는 각 서비스들이 종속적이기에 유연한 확장에는 어려움이 존재합니다.
Microservice
각 테두리 안에서도 서비스나 기능들을 작은 규모로 만들어 함께 작동할 수 있게 만들고자 나온 아키텍처가 Microservice입니다. 유연함과 확장성을 위해 하나의 서비스는 다른 서비스에 영향을 주지 않거나 영향을 최소화하면서 개발을 진행해야 하며, 각 서비스들 간의 통신은 HTTP를 이용해 API를 제공하는 방식으로 개발되어야 합니다.
서비스들은 자신이 수행하고자 하는 역할에 맞춰 비즈니스 중심으로 개발되어야 하고 서비스가 작은 단위로 구성된 만큼 하나하나의 수동 배포는 어려움이 존재하기에 자동화된 배포 시스템을 구축하고 사용해야 합니다. 또한 서비스들이 중앙 통제에서 완전히 벗어날 수는 없기에 최소한의 중앙 처리가 가능해야 하고 각 서비스는 서로 다른 개발 언어와 서로 다른 기술을 사용할 수 있습니다.
각각의 서비스들을 분리하는 것은 기술적인 비용이 따르겠지만, 그런데도 화제가 되는 이유는 유지보수나 변경점을 적용하는 데 훨씬 유리함에 있습니다. 실제 애플리케이션의 초기 개발 비용보다 유지보수 비용이 더 크다는 것을 고려하면 충분히 고려해볼 만한 투자라 생각합니다.
Microservice는 앞서 말씀드린 유연한 확장성을 가지고 있습니다. 서비스별로 배포가 가능하기에 서비스별 개발 진행이 가능하고 서비스의 새로운 배포나 장애가 발생했을 시 전체 애플리케이션에 영향을 주지 않습니다. 설계 시 서비스 간 종속성을 낮추었고 서비스의 부하 분산이 가능하기 때문입니다.
Microservice Architecture
특징
마이크로서비스의 특징은 다음과 같습니다.
1. 기존의 개발 방식이나 패러다임을 상당수 바꿔야 합니다.
2. 서비스는 작은 배포 단위로 구성되어야 합니다.
3. 서비스는 애플리케이션을 구성하는 전체 도메인에 따라 경계를 잘 구분해야 합니다.
4. 서비스들은 경량화되어 있기에 REST API 방식으로 통신하는 것을 권장합니다.
5. 마이크로서비스 구성 및 관리는 외부 서비스를 통해 이루어져야 합니다.
6. 클라우드 네이티브 기술을 최대한 활용해서 서비스를 제공해야 합니다.
7. 서비스를 제공하는 인스턴스들은 부하 분산 처리를 동적으로 처리해야 합니다.
8. 자동적인 통합과 배포가 이루어져야 합니다.
9. 서비스 지표를 시각화할 수 있는 관리 도구가 필요합니다.
무조건적인 도입이 필요한가?
장점들을 살펴보았을 때 모든 애플리케이션에 마이크로서비스를 도입해야 하느냐는 의문을 가질 수 있습니다. 꼭 그렇지는 않습니다! 해당 애플리케이션을 분석해보았을 때 마이크로서비스를 도입함으로 인해 발생하는 비용이 충분히 가치 있을 때 도입하도록 해야 합니다. 그러기 위해서는 몇 가지 분석이 필요한데 대표적인 분석 지표는 다음과 같습니다.
1. 기존 개발 대비 발생하는 비용이나 시간적인 투자를 받아들일 수 있는가?
2. 애플리케이션을 구성하는 서비스가 독립적으로 운용될 수 있도록 잘 구분되어 있는가?
3. 서비스의 유지보수나 확장이 앞으로 빈번히 발생하는가?
4. 서비스의 오류가 종속적이지 않고 독립적인가?
5. 애플리케이션의 설계가 결합도는 낮추고 응집도는 높이는 방식으로 진행되었는가?
6. 여러 종류의 프로그래밍 언어나 개발 기술이 사용될 수 있는가?
표준 구성요소
마이크로서비스를 구성하는 표준 구성 요소들이 존재하는데 차례대로 알아보면 다음과 같습니다.
1. 클라이언트나 다른 서비스들이 API Gateway를 통해 필요한 서비스를 요청
2. Service Router에게 요청이 전달되고 Service Discovery에게 질문
3. 서비스 탐색이 완료되면 Load Balancing에 의해 서비스 부하를 분산
4. 마이크로서비스 구성 및 관리는 외부 서비스를 이용하는게 일반적
5. 마이크로서비스는 컨테이너 가상화 기술을 통해 구성
6. 완성된 애플리케이션 배포를 위해 CI/CD 기술 사용
MSA 기반 기술
Gateway
다른 서비스 간 통신을 위해 Gateway를 제공해야 합니다. 대표적으로 nginx가 존재합니다.
Service Mesh
마이크로서비스 아키텍처를 적용한 시스템 내부 통신을 의미합니다. Service Router, Service Discovery, Load Balancing을 묶어서 지칭합니다.
Runtime
애플리케이션 운영 환경과 관련 있는 부분입니다. 대표적으로 Docker, Kubernetes가 존재합니다.
Backing Services
작동 중에 네트워크를 통해 연결되는 서비스들을 의미하며 대표적으로 kafka, redis가 존재합니다.
Frameworks
소프트웨어 개발의 뼈대 역할을 해주는 도구를 의미하며 Spring Boot, Spring Cloud 등이 존재합니다.
Automation
애플리케이션 개발, 빌드, 배포에 있어 자동화를 도와주는 도구를 의미합니다. Gradle, Maven, Jenkins 등이 존재합니다.
Telemetry
애플리케이션의 실시간적인 모니터링 관리 도구를 의미합니다.
REST API
REST란 Representational State Transfer의 약자로 리소스의 상태를 표현하고 이를 구분하여 해당 리소스를 주고받는 것을 의미합니다. 이러한 REST를 잘 지키며 만들어진 API를 REST API라고 합니다.
마이크로서비스 아키텍처에서는 서비스 간 통신이 API를 통해 이루어지게 되는데 서비스 간 종속성이 낮은 만큼 올바른 REST API를 개발하기 위해 초기에 많은 노력을 해야 합니다.
REST API 성숙도 모델
REST API의 구현에 따라 단계를 나타내는 성숙도 모델이 존재합니다. 각 단계는 레벨로 나타낼 수 있습니다.
LEVEL 0
리소스를 제공하기 위해 URL만 매핑한 단계를 의미합니다.
LEVEL 1
리소스에 알맞은 의미 있고 적절한 URL을 매핑했지만 HTTP Method는 지정하지 않은 단계를 의미합니다.
LEVEL 2
의미 있고 적절한 URL 매핑과 HTTP Method 지정이 이루어진 단계를 의미합니다.
LEVLE 3
LEVEL 2 단계가 적용되어 있고 해당 리소스로 수행할 수 있는 다음 행동까지 전달해주는 단계를 의미합니다. 최소한의 진입점을 알 수 있게 도와줍니다.
RESTful Web Service
REST를 잘 적용한 웹 서비스를 개발하기 위해서는 아래의 사항들을 잘 지켜 개발하도록 노력해야 합니다.
1. 클라이언트의 입장에서 간단하고 직관적인 API를 설계 및 개발해야 합니다.
2. HTTP Method 특징을 최대한 살려 개발해야 합니다.
- GET
- POST
- PUT
- DELETE
3. 적절한 HTTP 상태 코드를 전달해야 합니다.
- 200
- 300
- 400
- 500
4. URI에 민감한 정보를 담아서는 안 됩니다.
5. 제공하는 리소스에 대해서는 복수 형태로 전달할 수 있도록 해야 합니다.
6. 모든 리소스는 명사로 표현하는 것이 좋습니다.
7. 일관적인 엔드 포인트를 지정하여 진입점을 단일화하는 것이 좋습니다.
'Spring > Spring Cloud' 카테고리의 다른 글
| [MSA] Service Discovery (0) | 2022.07.06 |
|---|---|
| 클라우드 네이티브 아키텍처 (0) | 2022.06.18 |