MSA 개발 가이드(1) - MSA란 무엇인가

지금까지 개발했던 프로젝트들은 모두 모놀로식 아키텍처였는데, 신입으로 입사 이후 마이크로서비스 아키텍처라는 것을 접하게 되었다. MSA는 민첩성과 유연성을 장점으로 하는 클라우드 플랫폼에서 개발, 실행, 운영, 관리될 수 있도록 분산환경을 구성하는 아키텍처이다. 사용자 관점을 유지하면서도, 안정적이도 탄력적으로 운영할 수 있다는 장점도 있다.

MSA 개발 가이드는 가벼운 구조로 클라우드 환경에 적용하기 적합한 스프링부트를 사용하여 작성할 것이다. 

 

그래서 앞으로는 MSA로 웹사이트를 개발해 볼 예정이다. MSA로 개발하려면 많은 개발지식이 요구되는데, 하나하나 정리하면서 가이드를 작성해보려 한다. 

 

MSA 개발 가이드 목차

1. MSA의 정의와 사용하는 이유
2. 12-Factor-App 방법론
3. Service Mesh
4. MSA 적용 시 고려사항

 

---

 

MSA의 정의

마이크로서비스를 위키백과에서는 아래와 같이 정의하였다. 

마이크로서비스는 소프트웨어 개발 기법으로, 애플리케이션을 세분화된 서비스들의 모임으로 구조화하는 방법이다. 이러한 아키텍처 스타일은 모듈성을 높이며 애플리케이션의 이해, 개발, 테스트를 용이하게 하고, 변화에 대응하는 능력을 향상시킨다. 각 팀은 독립적으로 서비스를 개발하고 배포하며 규모를 확장할 수 있어 병렬 개발이 가능하게 된다. 마이크로서비스 기반의 아키텍처는 지속적인 리팩토링을 통해 개별 서비스 아키텍처를 통합하는 것을 허용하며, 지속적인 배포와 전개를 가능하게 한다.

 

즉, 전통적인 애플리케이션은 여러 서비스를 모두 한데 묶어서 모놀리식 아키텍처로 배포한다. 예컨대, UI, 비즈니스 로직, 데이터베이스 액세스 로직 등이 모두 하나로 뭉쳐져 애플리케이션 서버에 배포된다. 그런데 이런 방식으로는 고객의 요구에 따른 확장성이나 성능 조절이 쉽지 않다. 그래서 이런 문제를 해결하기 위해 마이크로서비스 아키텍처를 사용한다. 이 방법은 큰 애플리케이션을 여러 독립적인 작은 시스템으로 쪼개는 데 도움을 준다.

 

<그림1> 모놀리식 아키텍처와 MSA 비교

 

위 그림은 마이크로 서비스 아키텍처에서 볼 수 있듯이, 각각의 마이크로서비스는 자체 비즈니스 계층과 데이터베이스를 가지고 있다. 그렇게 함으로써, 하나의 마이크로 서비스를  수정한다고 해서 다른 마이크로 서비스에 영향을 주지 않는다. 일반적으로 마이크로 서비스는 HTTP, REST같은 널리 채택된 lightweight 프로토콜 또는 JMS 또는 AMQP와 같은 메시징 프로토콜을 사용하여 서로 통신한다. 특정 시나리오에서는 더 전문화된 프로토콜을 사용할 수도 있다.

 

마이크로서비스 아키텍처의 특징은 다음과 같다:

• 애플리케이션 로직은 각각의 책임이 명확한 작은 부품들로 나눠져 있고, 이들을 합치면 솔루션을 제공한다.
• 각 부품은 작은 책임 영역을 맡고, 완전히 독립적으로 배포된다. 마이크로서비스는 비즈니스 영역의 한 부분에서만 책임을 진다. 그리고 애플리케이션에서 재사용 가능하다.
• 마이크로서비스는 몇 가지 기본 원칙에 근거하고, 서비스 이용자와 서비스 제공자 사이의 데이터 교환을 위해 HTTP와 JSON 같은 경량 통신 프로토콜을 쓴다.
• 애플리케이션은 항상 기술 중립적 프로토콜을 써서 통신하기 때문에 서비스 구현 기술과는 상관 없다. 그래서 마이크로서비스 기반의 애플리케이션은 다양한 언어와 기술로 만들 수 있다는 의미다.
• 작고 독립적이며 분산된 마이크로서비스를 이용하면, 조직은 명확히 정의된 책임 영역을 맡는 작은 팀을 둘 수 있다. 이 팀들은 애플리케이션 출시처럼 하나의 목표를 향해 일하지만, 자기가 개발하는 서비스만 책임진다.

마이크로서비스 아키텍처의 목적은 시스템에 대한 개발 및 운영 복잡성을 효율적으로 줄이는 데 있다. 이런 장점들을 통해 복잡성을 줄일 수 있다:

Microservice는 독립적으로 구성될 수 있고, 상호 독립적으로 만들어지고 운영될 수 있다. 특정 서비스만 집중하면 되고, 코드 규모가 작아서 효율적인 유지보수가 가능하다. Restful API와 같이 경량한 통신을 통해 효과적인 상호 연계가 가능하다. 독립적인 서비스 단위 확장(scale-out)을 지원하기 때문에 시스템 자원을 효율적으로 활용할 수 있다.

 

서비스의 규모가 커지고 복잡도가 증가할수록 마이크로서비스 아키텍처는 여러 가지 장점을 제공한다. 서비스가 독립적으로 구성되어 있기 때문에 변경이 쉽고 그 변경이 서비스 간 영향이 적다. 또한, 개별로 서비스 배포가 가능하기 때문에 수시로 필요에 따라 배포할 수 있다.

 

비용적인 측면에서도 부하가 많은 서비스만 확장할 수 있어 불필요한 자원의 낭비를 줄일 수 있다. 특히, 서비스의 특성에 따라서 자원(Memory,CPU)을 할당할 수 있으며, 특정 서비스에 대한 집중적으로 요청되는 시기에 따라 가변적으로 리소스를 운영할 수 있다.

 

---

12-factor-app 방법론

12-Factor App 방법론은 클라우드-네이티브 애플리케이션을 구축하고 실행하는 데 사용되는 모범 사례 집합이다. 2011년 Heroku의 엔지니어들에 의해 개발되었으며, 이들은 이 방법론을 사용해 대규모 웹 애플리케이션을 개발하고 유지보수하는데 큰 성공을 거두었다.

12-Factor App 방법론은 다음의 12가지 원칙을 포함한다:

<그림2> 12-factor-app 방법론

1. 코드베이스: 하나의 코드베이스는 다양한 배포를 지원해야 한다(스테이징, 프로덕션 등).
2. 의존성: 명시적으로 선언하고 격리하여 의존성을 관리한다.
3. 설정: 환경 설정은 코드에서 분리되어야 한다.
4. 백엔드 서비스: 백엔드 서비스는 연결된 리소스로 취급해야 한다.
5. 빌드, 릴리즈, 실행: 빌드와 실행은 엄격하게 분리되어야 한다.
6. 프로세스: 애플리케이션을 하나 또는 여러 개의 독립적인 프로세스로 실행한다.
7. 포트 바인딩: 서비스는 포트 바인딩을 통해 외부로 노출된다.
8. 동시성: 애플리케이션을 프로세스 모델로 수평적 확장한다.
9. 폐기 용이성: 애플리케이션은 시작과 종료가 빠르고 Graceful Shutdow시 서비스에 영향을 미치지 않도록 하여 안정성을 극대화하여야 한다.
10. 개발/프로덕션 환경 일치: 개발, 스테이징, 프로덕션 환경을 최대한 유사하게 유지한다.
11. 로그: 로그는 이벤트 스트림으로 취급한다.
12. 관리자 프로세스: 관리/관리 작업을 일회성 프로세스로 실행한다.

이 원칙들은 시스템이 확장성, 이식성, 그리고 서비스간의 독립성을 보장하는 데 도움을 준다. 12-Factor App 방법론은 다른 현대적인 개발 방법론, 특히 마이크로서비스 아키텍처와 자연스럽게 연결된다.

 

---

Service Mesh

MSA를 적용한 시스템이 커지면 마이크로서비스의 인스턴스 수가 증가함에 따라 시스템 런타임 복잡성 문제가 발생한다. 보안, 로드 밸런싱, 모니터링 등 동적으로 수많은 마이크로서비스의 인스턴스간 통신이 유발하는 관심사들을 내부 내트워크에서 안정적으로 다루기 위해 새로운 기능들이 필요하다. 각 서비스 마이크로서비스 간 통신을 최적화 하고 다운 타임을 방지하며 전체 서비스를 관리하기 위한 이러한 Outer Architecture를 Service Mesh라고 한다.

 

Service Mesh는 복잡한 내부 네트워크를 추상화를 통해 서비스간의 통신이 빠르고 안정적이며 신뢰성을 보장한다.

 

Service Mesh의 주요 기능

MSA가 갖추어야 하는 Service Mesh의 주요 기능은 다음과 같다.

주요 기능	특징
Configuration Management	설정변경 시 서비스의 재빌드와 재부팅 없이 즉시 반영
Service Discovery	API Gateway가 서비스를 검색하는 매커니즘
Load Balancing	서비스간 부하 분산
API Gateway	API 서버 앞단에서 API 엔드포인트 단일화 및 인증, 인가, 라우팅 기능 담당
Centralized Logging	서비스별 로그의 중앙집중화
Centralized Metrics	서비스별 메트릭 정보의 중앙집중화
Distributed Tracing	서비스간 호출 누적과 성능, 분석 관리
Resilience & Fault Tolerance	서비스간 장애 전파 차단
Auto Scaling & Self Healing	자동 스케일아웃과 복구 자동화
Packaging, Deployment & Scheduling	패키징, 빌드 및 배포 자동화
Test Automation	서비스 테스트 자동화

 

Service Mesh 사용 방안

본 가이드에서는  Spring Cloud기반의 Service Mesh를 직접 구축하는 방법을 작성한다.

 

Spring Cloud와 Spring Boot를 결합하여 사용하면, 분산 처리 환경에서 안정적인 Service Mesh를 개인적으로 만들 수 있다.

Spring Cloud는 애플리케이션 플랫폼의 일부로, 다양한 통합된 자바 라이브러리 집합으로 MSA에 대한 모든 이슈를 처리하는 데 도움이 된다.

이는 개발자가 분산 시스템에서 자주 볼 수 있는 구성 관리, 서비스 탐색, Circuit Breakers, 지능형 라우팅, 프록시, 분산 세션, 클러스터 상태 등의 공통 패턴을 빠르게 구축할 수 있는 도구를 제공하고, 개발자의 개인 컴퓨터 또는 노트북에서, 그리고 Cloud Foundary와 같은 PaaS-TA 형식의 클라우드 플랫폼에서도 원활하게 실행할 수 있다.

 

---

MSA 적용 시 고려사항

디자인 패턴으로 유명한 Martin Fowler는 시스템이 특별히 복잡하지 않을 경우, 모놀리식으로 관리하는 것이 마이크로서비스 도입을 고려하지 말아야 한다고 강조하고 있다. 이는 시스템의 복잡도 수준에 따라 아키텍처 선택이 개발 생산성에 큰 영향을 미칠 수 있기 때문이다.

특히 소프트웨어 엔지니어는 개발과 운영에 관련된 다양한 스킬셋과 해결 방안뿐만 아니라 전체 시스템 동작에 대한 이해도를 요구받을 수 있으므로, 아키텍처를 선택할 때 신중해야 한다.

 

마이크로서비스 기반 애플리케이션 도입 시 다음 사항을 고려해야 한다.

1. MSA 도입으로 얼마나 비용을 절감할 수 있는지 검토한다.
2. 시스템이 마이크로서비스를 필요로 할 정도로 복잡한지, 또는 마이크로서비스를 지나치게 복잡하게 구성하여 생산성이 저하되지는 않는지 평가한다.
3. 개발팀이 개발과 운영을 동시에 수행할 수 있는 인프라 준비 여부를 고려한다.

 

 

 

참고자료 : 표준프레임워크 포털 MSA 적용 개발 가이드

https://www.egovframe.go.kr/home/ntt/nttRead.do?menuNo=76&bbsId=171&nttId=1809 

관련참고문서 | 표준프레임워크 포털 eGovFrame

AWS Twelve Factor

https://aws.amazon.com/ko/blogs/korea/twelve-factor-app-on-cloud-native/

AWS 클라이드 네이티브 기반 Twelve Factor 앱 개발 방법 | Amazon Web Services