본 포스팅은 인프런 Dowon Lee님의
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) 강의를 토대로 작성되었습니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4
Monolithic vs MSA
- Monolithic Architecture
애플리케이션을 개발함에 있어서
모든 요소를 하나의 커다란 소프트웨어 안에 포함시켜 개발하는 방식.
DB나 비지니스로직, 화면을 구성하는 요소까지 하나의 애플리케이션에서 유기적으로 동작하여 서로 의존성을 가지고 패키징되고 서버에 배포.
문제점
시스템의 일부사항만 변경이 된다 하더라도 전체 애플리케이션을 전체를 다시 테스트-빌드-패키징하여 서버에 다시 배포하여야 하므로
배포하는 단위가 커지게 되며, 서비스 다운 시간이 길어진다.
- MSA
애플리케이션을 구성하는 각각의 요쇼 및 서비스의 내용을 분리하여 개발하고 운영하는 방식.
한 요소에 변경점을 반영하거나 유지보수에 있어서 단일 서비스만 바라볼 수 있기 때문에 다른서비스에 영향을 주지 않거나, 최소한의 영향만을 주면서 독립적인 배포가 가능.
이로인해 배포시점에 서버가 다운되는 시간을 최소로 할 수 있으며, 전체 애플리케이션 서버를 down 하는것이 아닌, 해당 서비스만을 다시 배포하기 때문에
사용자 입장에선 해당 서비스만 잠시 이용이 불가능 해질 뿐, 다른 서비스를 사용하는데 있어서는 아무런 문제가 없다.
또한 서비스별로 특색에 맞는 최적화된 언어와 DB사용을 권장하고 있는데,
서비스별로 기능에 맞춰서 개발을 하고, 각각의 서비스들은 API를 통해 기능 제공이 가능해진다.
서비스를 분리하고, 각 서비스는 최적화된 환경에서 기능을 수행하며,
API를 통해 서로의 데이터를 사용할 수 있다.
MircoService Architecture
마이크로서비스 아키텍쳐의 창시자 Martin Fowler가 정의한 내용이다.
What is the MicroService?
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. —- James Lewis and Martin Fowler
간단히 말해 마이크로서비스 아키텍처 스타일은 단일 애플리케이션을 자체 프로세스에서 실행되고 경량 메커니즘(종종 HTTP 리소스 API)과 통신하는 소규모 서비스 모음으로 개발하는 접근 방식입니다.
이러한 서비스는 비즈니스 기능을 기반으로 구축되며 완전 자동화된 배포 기계에 의해 독립적으로 배포할 수 있습니다.
최소한의 중심적인 관리 체계가 있고, 각 시스템들은 다른 프로그래밍 언어, 다른 데이터 스토리지 기술로 작성하는 것이 가능합니다.
MicroService의 특징
1) Challenges
: 기존의 개발방식이나, 패러다임을 상당수 바꾸어야만 한다.
2) Small Well Chosen Deployable Units
: 독립적으로 개발 가능한 작은 서비스로 이루어진다.
3) Bounded Context
: 각각의 서비스들은 애플리케이션이 구성하고 있는 전체 도메인에 따라서 경계를 잘 구분해야 하고, 이러한 경계구분을 통해서 하나의 서비스가 여러개가 되기도 하고, 여러개의 서비스가 단일화된 형태로 만들어지기도 한다.
4) Restful
: 각각의 서비스들은 RestfulAPI 방식으로 통신하는것을 권장한다.
5) Configuration Management
: 서비스에 대한 설정이나 환경정보는 코드내에 존재하는것이 아니라, 외부 시스템을 통해서 관리한다.
6) Cloud Enabled
: CloudNative기술을 최대한 활용해서 서비스를 제공한다.
7) Dynamic Scale Up And Scale Down
: 클라우드 시스템을 통해 전체 애플리케이션을 구성하는 서비스들은 상황에 맞게 스케일 조정이 가능하다.
8) CI/CD
: 작은 서비스를 일일히 다 패키징 하고 배포하는것이 아니라, 파이프라인을 통해서 이를 자동화한다.
9) Visibility
: 서비스들은 시각화된 관리도구를 가지고 있어야 한다.
MSA가 좋으니까 무조건 MSA로 개발하면 되는거 아니야? -> NO!
- 1. MSA로 전환시 비용이 얼마나 들어가는가
- 2. 독립된 라이프사이클을 가지게 할 수 있는가
- 3. 유지보수가 용이한가
- 4. 오류가 격리될 수 있는가
- 5. 외부 종속성과 상호 작용을 단순화 할 수 있는가
- 6. 여러 프로그래밍언어, DB등의 기술을 자유롭게 선택할 수 있고 지원할 수 있는가
MSA 도입은 분명 기술장벽이 있고, 비용이 드는 작업이다.
이로인해 개발일정이 늦어지고 애플리케이션의 규모가 그렇게 크지 않다면
배보다 배꼽이 더 큰 상황이 발생할 수 있음을 염두해야 한다.
