MSA 소개
MSA 란?
하나의 어플리케이션을 다수의 독립적인 서비스들의 집합으로 구성하는 것으로 서비스 지향 아키텍처(SOA) 스타일의 소프트웨어 개발 기법이다
- 각자 별도의 프로세스에서 실행되며, HTTP API 같은 가벼운 매커니즘으로 통신하는 작은 애플리케이션이다.
- 작은 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화 된 절차에 따라 독립적으로 배포된다.
- 각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수 있음
MSA 용어
- Microservice Architecture
- MSA
- Microservices
Microservices 란?
마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다.
- 아마존의 마이크로서비스
- 넷플릭스의 마이크로서비스
Monolithic 소개 및 문제점
Monolithic System 특징
- 전체 기능을 단일 코드베이스로 개발한다
- 대규모 단일 코드 베이스를 빌드 및 배포한다
- 단일 통합 데이터베이스를 사용한다
Monolithic System 장점
- 상대적으로 운영하기 용이하다.
코드 관리, 장애 관리, 로그 관리, 모니터링 - 내부 메소드 호출로 성능 문제 없음 (MSA는 네트워크를 통한 인터페이스 호출한다.)
- 트랜잭션 관리에 용이하다.
Monolithic System 단점
- 기능들 간의 결합도가 일반적으로 높다
다른 기능의 테이블을 직접 접근하기도 한다 - 기능 변경 시 영향도 파악이 어렵다
코드 의존관계, 데이터 의존관계 - 결과적으로 코드가 운영환경에 민첩하게 배포되기 어렵다
빌드도 오래걸린다..
Monolithic System 종류
- Single Monolithic System
- Modular Monolith System
- Distributed Monolithic System
Monolith 에 대한 오해
Monolith는 Legacy 이다?Monolith는 안티 패턴이다?Monolith는 모든 상황에서 Microservice로 분할되어야 한다?- Monolith는 하나의 아키텍쳐 패턴일 뿐이다.
- 많은 상황에서 충분히 좋은 역할을 한다
- 관리 용이성, 트랜잭션, 성능 등 많은 장점이 있다.
Monolith와 MSA는 Trade-off가 존재하니 적절하게 선택하는 것이 필요하다.
MSA 주요 특징
MSA는 API를 통해서만 상호작용을 한다. 마이크로 서비스는 서비스의 end-point (접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
- MSA에서 서비스 단위를 컴포넌트로 정의한다
- 특정 비즈니스 기능을 담당
- 독립적인 프로세스로 실행
- 자율적인 배포 가능
- 서비스는 응집도 높게 설계 되어야한다.
- 서비스 간 명확한 인터페이스를 제공하여 협력한다.
MSA 장단점
MSA 장점
1. 배포
- 각 서비스들은 네트워크를 통한 인터페이스로 느슨히 결합되어 서비스간 자율적인 배포 가능하다.
(배포시 전체 서비스의 중단이 없다.) - 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능하다.
2. 확장
- 각 서비스는 독립적으로 개발되며 느슨하게 결합되어, 특정 서비스에 대한 확장성(scale-out)이 유리하다.
- 클라우드 기반 서비스 사용에 적합하다.
3. 장애
- 일부 장애가 전체 서비스로 확장될 가능성이 적다.
- 부분적으로 발생하는 장애에 대한 격리가 수월하다.
4. 그 외
- 각 서비스는 자신만의 고유한 언어/Framework 선택 가능하여, 새로운 기술을 적용하기 유연하다.
- 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽습니다.
- 강한 결합 때문에 코드 수정이 어려운 모놀리스와 달리 마이크로서비스는 코드 개선 시 영향도가 낮아 지속적인 개선 작업이 가능하다
MSA 단점
1. 설계의 어려움
- MSA는 모놀리식에 비해 상대적으로 많이 복잡하다.
서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야한다.
또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다.
2. 성능
- 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.
- 내부 호출보다 느리다
3. 테스트/데이터 트랜잭션
- 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵다.
- 통합 테스트가 어렵습니다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.
4. 데이터 관리
- 데이터가 여러 서비스에 분산되어 있어 조회하기 어렵다.
- 데이터를 관리하기 어렵다.
- 모니터링 대상이 증가하며 운영관리가 어렵다
5. 기타
- 컴퓨팅 자원의 사용이 모놀리스보다 비효율적이다
- 메모리 - JVM 등 중복적인 자원을 사용한다
MSA 도입 조건
MSA의 도입 조건은 사업/조직적 측면과 기술적 측면 두 가지로 나누어 볼 수 있다.
조건 1. 사업/조직적 측면
- MSA가 중장기적 Business benefit을 올릴 수 있다는 합의
말 그대로 MSA의 도입이 중장기적 Business benefit을 올릴 수 있어야 한다.
MSA 도입 자체가 시간과 비용적으로 오래 걸리는 작업이기 때문에, 기업에 실질적 합의가 있지 않으면 조금 어려울 수 있다. - 고위 경영진의 강력한 Commitment 및 용기
잘 동작하는 시스템을 건드리기 싫은 두려움도 있겠지만, 더 훌륭한 서비스를 만들기 위해서는 용기가 필요하다. - MSA 도입은 단순 기술 도입이 아닌 조직과 프로세스의 개선 작업 필요
조직과 프로세스의 개선 작업 없이 코드 레벨에서만 수정하는 것은 반쪽짜리 도입이다.
프로세스나 방법론의 개선 또한 필요한데, 조직의 구성이 해당 아키텍처에 반영되기 때문이다. - DevOps 문화 정착되어야 함
DevOps와 MSA는 뗄 수 없는 관계로, 빼른 개발/빌드/배포를 위해 정착되어야 한다. - 사내 교육, 학습을 위한 자원 투자
MSA의 도입 과정에서는 여러가지 문제가 발생할 수 있기 때문에, 사내교육과 학습을 위한 자원 투자를 꾸준히 해야 한다.
조건 2. 기술적 측면
- Rapid Provisigning
MSA의 장점을 극대화하기위해서는 Rapid Provisign 환경이 구축되어 있어야 한다. ex)클라우드 환경, 인프라 자동화 환경 - 정교한 모니터링 및 장애관리
인스턴스 개수가 많아지고 서비스간의 커뮤니케이션도 복잡해지면, 문제가 발생했을때 바로 인지하고 파악하는것이 어려워 질 수 있다.
따라서 다양한 레벨의 모니터링과 모든 서비스에 대한 실시간 모니터링이 필요하다. - 자동화된 배포
MSA처럼 서비스가 많아지고 기술이 다변화되면 수동 배포가 힘들수있다.
End to end 배포 파이프라인을 구축해야 한다.
MSA를 언제 시작하는 것이 좋을까?
Monolithic 기술의 단점들이 Business에 미치는 부정적인 영향이 클 때,
혹은 MSA로 얻을 수 있는 Business benefit이 MSA의 단점보다 크다고 판단 되었을 때 적용해야 한다.
이 때 MSA 도입 비용이 크다는 점을 인식해야 한다.
어떤 부분부터 분리해야 할까?
- 비즈니스 변화에 민첩하게 대응해야 하는 기능
- 요구사항이 빈번하여 빌드/배포를 자주 해야하는 기능
- 이벤트 때문에 주기적으로 트래픽이 몰려 빈번한 확장이 필요한 기능
- 처음에는 중요도가 낮고, 작은 모듈부터 분리
결론
Microservice ar not the goal
Microservice는 선택 가능한 대안이며, 그 자체가 목적이 아니다.
Microservice를 통해 이루고자 하는 목적을 확실하게 이해하고 있어야한다.
"MSA가 Netflix에서도 잘 맞았으니, 우리 시스템에도 좋겠지!"라는 생각은 가장 위험한 생각이다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
추천인 코드 : AF8800551
참고
'개발 스터디' 카테고리의 다른 글
[TIL] 파이썬(Python)의 구조 (0) | 2023.01.24 |
---|---|
[Network] CIDR (Classless Inter-Domain Routing) (0) | 2022.12.19 |
댓글