전통적인 애플리케이션 구축 방식은 모놀리식(Monolithic)에 중점을 두었으며, 애플리케이션에서 구축 가능한 모든 부분이 하나의 애플리케이션에 포함되어 있었다. 이러한 방식의 단점은 애플리케이션이 커질수록 새로운 문제를 해결하고 새로운 기능을 추가하는 것이 어려워진다는 것이었다. 마이크로서비스 기반 애플리케이션 구축 방법은 이러한 문제를 해결하고 개발 및 대응 속도를 가속화할 수 있다.
마이크로서비스(Microservices)란?
마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는, 소규모의 독립적인 서비스로 구성되어있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다. 마이크로서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있게 해준다.
Monolithic vs MSA
모놀리식(monolithic) 아키텍처의 경우, 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야한다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해진다. 또한 이러한 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워진다. 종속 관계를 이루며 긴밀하게 결합된 많은 프로세스로 인해 단일 프로세스의 실패로 인한 영향이 증가함에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.
모놀리식 아키텍처의 장단점을 정리하면 다음과 같다.
장점
- 단순한 구조
- 개발환경과 방법의 통일성
- 배포가 간편
- End to End 테스트가 쉬움
단점
- 작은 문제로부터 시스템 전체로의 문제 : 만약 하나의 서비스 부분에 트래픽 문제로 서버가 다운되면, 모든 서비스 이용이 불가능할 것이다.
- 빌드/테스트 시간의 증가 : 하나를 수정해도 시스템 전체를 빌드해야한다. 즉, 유지보수가 힘들다.
- 확장성의 불리 : 서비스 마다 이용률이 다를 수 있고, 하나의 서비스를 확장하기 위해 전체 프로젝트를 확장해야한다.
마이크로서비스(microservices) 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다. 서비스는 비즈니스 기능을 위해 구축되며, 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 수행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 손쉽게 업데이트, 배포 및 확장할 수 있다.
마이크로서비스의 특징 및 장점과 단점은 뒤에서 더 자세히 살펴보자.
마이크로서비스의 특징
자율성
마이크로서비스 아키텍처의 각 구성 요소 서비스는 다른 서비스에 영향을 주지 않으면서 개발, 배포, 운영하고 확장할 수 있다. 서비스가 해당 코드 또는 구현을 다른 서비스와 공유할 필요는 없다. 개별 구성 요소 간의 통신은 잘 정의된 API를 통해 이루어진다.
전문성
각 서비스는 일련의 기능을 위해 설계되며 특정 문제를 해결하는 데 중점을 둔다. 개발자가 시간이 지남에 따라 서비스에 더 많은 코드를 제공하여 서비스가 복잡해지면, 더 작은 서비스로 분할할 수 있다.
마이크로서비스의 이점
민첩성
마이크로서비스는 해당 서비스를 소유한 독립적인 소규모 팀 조직을 육성하는 역할을 한다. 팀은 충분한 이해를 바탕으로 하는 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있다. 덕분에 개발 주기 시간이 단축되며, 조직의 집계 처리량 측면에서 큰 이점을 누리게 된다.
유연한 확장성
마이크로서비스의 경우 각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있다. 따라서 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있다.
손쉬운 배포
마이크로서비스는 지속적 통합 및 지속적 전달을 통해 새로운 아이디어를 손쉽게 시험하고, 문제가 발생할 경우 간단히 롤백할 수 있게 해준다. 이처럼 저렴한 실패 비용 덕분에 실험을 진행할 수 있어 더 쉽게 코드를 업데이트하고 새로운 기능의 출시 시간을 앞당길 수 있다.
기술적 자유
마이크로서비스 아키텍처는 "모든 규모에 부합하는" 접근 방식을 추구하지 않는다. 팀은 특정한 문제를 해결하는 데 가장 적합한 도구를 자유롭게 선택할 수 있다. 따라서 마이크로 서비스를 구축하는 팀은 작업별로 가장 적합한 도구를 선택할 수 있다.
재사용 가능한 코드
소프트웨어를 잘 정의된 소규모 모듈로 분할하면 팀이 기능을 여러 용도로 사용할 수 있게 된다. 특정 기능을 위해 구축된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있는 것이다. 이를 통해 개발자가 코드를 처음부터 작성하지 않고도 새 기능을 새성할 수 있어 애플리케이션이 자체적으로 부트스트랩 작업을 생성할 수 있다.
복원성
서비스가 독립적으므로 실패에 대한 애플리케이션이 저항성이 증가한다. 모놀리식 아키텍처에서는 단일 구성 요소가 실패하는 경우, 전체 애플리케이션이 실패하게 될 수 있다. 반면에 마이크로서빗에서는 기능을 저하시키고 전체 애플리케이션을 충돌시키지 않는 방식으로 전체 서비스 실패를 처리한다.
앞선 이점들은 상세하게 표현된 것으로, 간단하게 주요 장점을 정리하면 다음과 같다.
- 일부 서비스에 장애가 발생하여도 전체 서비스에 장애가 발생하지 않는다.
- 각각의 서비스들은 서로 다른 언어와 프레임워크로, 각각의 기능에 맞는 가장 적합한 기술로 구성될 수 있다.
- 서비스의 확장이 용이하다.
Why MSA?
최근들어 MSA가 자주 언급되는 이유는 무엇일까?
마이크로서비스 아키텍처가 클라우드 환경과 궁합이 좋기 때문이다. 잠시 모놀리틱 아키텍처를 다시 살펴보면, 각각의 모듈들이 합쳐져 큰 덩어리 형태로 시스템이 구축되어있다. 사용량이 적은 모듈을 삭제한다 하더라도, 전체 시스템의 스펙은 변하지 않는다. 따라서 사용량 단위로 과금을 해야하는 클라우드 환경에서 모놀리틱 아키텍처는 비효율적이다.
반면에 마이크로서비스 아키텍처는 서비스 단위로 기능을 분리해서 구축할 수 있기 때문에, 사용하지 않는 기능 또는 사용량이 적은 기능을 축소해서 효율화시킬 수 있다. 즉, 비용적인 측면으로 볼 때, 클라우드 환경에서 MSA가 선호된다.
다만, MSA를 모든 면에서 완벽하다고 할 수는 없다. MSA로 시스템을 구축하게 되면 관리해야할 포인트들이 증가하게 된다는 단점도 존재하는데, 자세한 사항은 다음을 통해 확인해보자.
마이크로서비스의 고려 사항
복잡성
마이크로서비스 애플리케이션은 동등한 모놀리식 애플리케이션보다 움직이는 부분이 더 많다. 각 서비스는 더 간단하지만, 전체 시스템은 더 복잡하다.
개발 및 테스트
다른 종속 서비스에 의존하는 소규모 서비스를 작성하려면 기존의 모놀리식 또는 계층화된 애플리케이션을 작성하는 것과는 다른 접근 방식이 필요하다. 기존 도구가 항상 서비스 종속성과 함께 작동하도록 설계된 것은 아니다. 서비스 경계를 넘어선 리팩토링은 어려울 수 있다. 특히 애플리케이션이 빠르게 진화하는 경우 서비스 종속성을 테스트하는 것도 어렵다.
거버넌스 부족
마이크로서비스 구축에 대한 접근 방식에는 장점이 있지만, 문제가 발생할 수도 있다. 너무 다양한 언어와 프레임워크로 인해 응용 프로그램을 유지관리하기 어렵게 될 수 있다. 팀의 유연성을 과도하게 제한하지 않고, 프로젝트 전체의 표준을 적용하는 것이 유용할 수도 있다. 이는 특히 로깅과 같은 교차 편집 기능에 해당될 수 있다.
네트워크 정체 및 대기 시간
작고 많게 세분화된 서비스를 사용하면, 서비스 간의 통신이 더 많이 발생할 수 있다. 또한 서비스 종속성 체인이 너무 길어지면(서비스 A가 B를 호출하고 B가 C를 호출...) 추가 대기 시간이 문제가 될 수 있다. 따라서 API를 신중하게 설계해야한다.
데이터 무결성
자체 데이터 지속성을 담당하는 각 마이크로서비스는 결과적으로 데이터 일관성의 문제가 될 수 있다. 가능한 경우 최종 일관성을 수용하는 것이 좋다.
관리
마이크로서비스를 성공시키려면, 성숙한 DevOps 문화가 필요하다. 예로 서비스 간 로깅은 어려울 수 있다. 일반적으로 로깅은 단일 사용자 작업에 대한 여러 서비 호출을 연관시켜야한다.
버전 관리
서비스에 대한 업데이트는, 이에 의존하고 있는 서비스를 손상시키지 않아야한다. 여러 서비스가 언제든지 업데이트 될 수 있으므로 신중하게 설계하지 않으면 이전 버전 또는 이전 버전과의 호환성 문제가 발생할 수 있다.
기술 세트
마이크로서비스는 고도로 분산된 시스템이다. 팀이 성공할 수 있는 기술과 경험을 가지고 있는지 신중하게 평가해야한다.
위의 고려 사항들은 상세하게 설명된 것이고, 간단하게 주요 단점을 정리하면 다음과 같다.
- 일반 개발보다 복잡하다.
- 서비스가 분리되어 있어, 통합 테스트가 어렵다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 한다.
- 버전 관리가 어렵다. 여러 서비스가 언제든지 업데이트 될 수 있으므로 신중하게 설계하지 않으면, 이전 버전 또는 이전 버전과의 호환성 문제가 발생할 수 있다.
- 거버넌스가 부족하다. 너무 다양한 언어와 프레임워크로 인해 응용 프로그램을 유지관리하기 어렵게 될 수 있다. 팀의 유연성을 과도하게 제한하지 않고, 프로젝트 전체의 표준을 적용하는 것이 유용할 수도 있다.
- 서비스 간에 API로 통신하기 때문에 그에 대한 비용이 발생한다.
- 서비스 간의 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.
결론적으로, 마이크로서비스 아키텍처를 통해 서비스를 분리함으로써 얻을 수 있는 장점도 있지만 , 그만큼 체계적으로 준비되어 있지 않으면 MSA로 인해 오히려 프로젝트 성능이 떨어질 수 있다는 점을 알고 있어야한다. 정답이 정해져있는 것이 아니라 프로젝트 목적과 현재 상황에 맞는 아키텍처 방식이 무엇인지 설계할 때부터 잘 고민하여 선택해야한다.
기술 질문/예상 질문
🔎 MSA란 무엇인가요?
하나의 어플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것이다.
API를 통해 통신하는, 소규모의 독립적인 서비스로 구성되어있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다. 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다.
🔎 MSA의 장점에 대해서 설명해주세요
- 일부 서비스에 장애가 발생하여도 전체 서비스에 장애가 발생하지 않는다.
- 각각의 서비스들은 서로 다른 언어와 프레임워크로, 각각의 기능에 맞는 가장 적합한 기술로 구성될 수 있다.
- 서비스의 확장이 용이하다.
🔎 MSA의 단점에는 무엇이 있나요?
- 일반 개발보다 복잡하다.
- 서비스가 분리되어 있어, 통합 테스트가 어렵다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 한다.
- 버전 관리가 어렵다. 여러 서비스가 언제든지 업데이트 될 수 있으므로 신중하게 설계하지 않으면, 이전 버전 또는 이전 버전과의 호환성 문제가 발생할 수 있다.
- 거버넌스 부족. 너무 다양한 언어와 프레임워크로 인해 응용 프로그램을 유지관리하기 어렵게 될 수 있다. 팀의 유연성을 과도하게 제한하지 않고, 프로젝트 전체의 표준을 적용하는 것이 유용할 수도 있다.
- 서비스 간에 API로 통신하기 때문에 그에 대한 비용이 발생한다.
- 서비스 간의 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.
Reference