마이크로서비스 아키텍처(MSA) 패턴의 이해

마이크로서비스는 현재 기사, 블로그, 소셜 미디어 토론, 회의 프레젠테이션 등 많은 관심을 받고 있습니다. 그들은 Gartner Hype 주기에서 부풀려진 기대치의 정점을 향해 빠르게 향하고 있습니다. 동시에 소프트웨어 커뮤니티에는 마이크로서비스를 새로운 것이 아니라고 일축하는 회의론자들이 있습니다. 반대론자들은 이 아이디어가 단지 SOA의 브랜드 변경일 뿐이라고 주장합니다. 그러나 과대 광고와 회의론에도 불구하고 마이크로서비스 아키텍처 패턴은 특히 복잡한 엔터프라이즈 애플리케이션의 민첩한 개발 및 제공을 가능하게 하는 경우 상당한 이점이 있습니다.

이 블로그 게시물은 마이크로서비스 설계, 구축 및 배포에 대해서 설명합니다. 접근 방식에 대해 배우고 보다 전통적인 모놀리식 아키텍처 패턴과 비교합니다. 마이크로서비스 아키텍처 패턴의 장점과 단점, 프로젝트에 적합한지, 적용하는 방법에 대해 배우게 됩니다.

마이크로서비스 사용을 고려해야 하는 이유를 먼저 살펴보겠습니다.

목차

1. 모놀리식(Monolithic) 애플리케이션 구축
2. 모놀리식(Monolithic) 지옥을 향한 행진
3. 마이크로서비스(Microservices) – 복잡성 해결
4. 마이크로서비스(Microservices)의 이점
5. 마이크로서비스(Microservices)의 단점
6. 요약

1. 모놀리식(Monolithic) 애플리케이션 구축

Uber 및 Hailo와 경쟁하기 위해 완전히 새로운 택시 호출 애플리케이션을 구축하기 시작했다고 가정해 보겠습니다. 사전 회의 및 요구 사항 수집 후 수동으로 또는 Rails, Spring Boot, Play 또는 Maven과 함께 제공되는 생성기를 사용하여 새 프로젝트를 생성합니다. 이 새로운 애플리케이션은 다음 다이어그램과 같이 모듈식 6각형 아키텍처를 갖습니다.

응용 프로그램의 핵심에는 서비스, 도메인 개체 및 이벤트를 정의하는 모듈에 의해 구현되는 비즈니스 논리가 있습니다. 코어 주변에는 외부 세계와 인터페이스하는 어댑터가 있습니다. 어댑터의 예로는 데이터베이스 액세스 구성 요소, 메시지를 생성하고 소비하는 메시징 구성 요소, API를 노출하거나 UI를 구현하는 웹 구성 요소가 있습니다.

논리적으로 모듈화된 아키텍처를 가지고 있음에도 불구하고 애플리케이션은 단일체로 패키징 및 배포됩니다. 실제 형식은 응용 프로그램의 언어와 프레임워크에 따라 다릅니다. 예를 들어, 많은 Java 응용 프로그램은 WAR 파일로 패키지되어 Tomcat 또는 Jetty와 같은 응용 프로그램 서버에 배포됩니다. 다른 Java 응용 프로그램은 자체 포함 실행 가능한 JAR로 패키지됩니다. 마찬가지로 Rails 및 Node.js 애플리케이션은 디렉토리 계층 구조로 패키징됩니다.

이 스타일로 작성된 응용 프로그램은 매우 일반적입니다. IDE 및 기타 도구가 단일 애플리케이션 구축에 중점을 두고 있기 때문에 개발이 간단합니다. 이러한 종류의 응용 프로그램도 테스트하기 쉽습니다. 애플리케이션을 실행하고 Selenium으로 UI를 테스트하기만 하면 종단 간 테스트를 구현할 수 있습니다. 모놀리식 애플리케이션은 배포도 간단합니다. 패키지된 애플리케이션을 서버에 복사하기만 하면 됩니다. 로드 밸런서 뒤에서 여러 복사본을 실행하여 애플리케이션을 확장할 수도 있습니다. 프로젝트의 초기 단계에서는 잘 작동합니다.

2. 모놀리식(Monolithic) 지옥을 향한 행진

불행히도 이 간단한 접근 방식에는 큰 한계가 있습니다. 성공적인 애플리케이션은 시간이 지남에 따라 성장하고 결국에는 거대해지는 습관이 있습니다. 각 스프린트 동안 개발 팀은 몇 가지 더 많은 이야기를 구현합니다. 물론 이는 많은 코드 줄을 추가하는 것을 의미합니다. 몇 년 후, 당신의 작고 단순한 애플리케이션은 거대한 단일체로 성장할 것입니다. 극단적인 예를 들자면, 저는 최근 수백만 LOC(Line of Code) 응용 프로그램에서 수천 개의 JAR 간의 종속성을 분석하는 도구를 작성하는 개발자와 이야기했습니다. 나는 그러한 짐승을 만드는 데 수년에 걸쳐 많은 개발자의 공동 노력이 필요했다고 확신합니다.

애플리케이션이 크고 복잡한 모놀리스가 되면 개발 조직은 아마도 고통의 세계에 빠져들 것입니다. 애자일 개발 및 제공에 대한 모든 시도는 실패할 것입니다. 한 가지 주요 문제는 애플리케이션이 압도적으로 복잡하다는 것입니다. 단일 개발자가 완전히 이해하기에는 너무 큽니다. 결과적으로 버그를 수정하고 새로운 기능을 올바르게 구현하는 것이 어렵고 시간이 많이 걸립니다. 게다가 이것은 하향 나선형 경향이 있습니다. 코드베이스가 이해하기 어렵다면 변경이 제대로 이루어지지 않을 것입니다. 당신은 무시무시하고 이해할 수 없는 큰 진흙 덩어리로 끝날 것입니다.

응용 프로그램의 크기도 개발 속도를 늦춥니다. 응용 프로그램이 클수록 시작 시간이 길어집니다. 예를 들어, 최근 설문 조사에서 일부 개발자는 시작 시간이 12분에 이른다고 보고했습니다. 응용 프로그램을 시작하는 데 40분 정도 걸린다는 일화도 들었습니다. 개발자가 정기적으로 응용 프로그램 서버를 다시 시작해야 하는 경우 하루 중 많은 시간을 대기하면서 보내게 되며 생산성이 저하됩니다.

크고 복잡한 모놀리식 애플리케이션의 또 다른 문제는 지속적인 배포를 방해한다는 것입니다. 오늘날 SaaS 애플리케이션의 최신 기술은 하루에도 여러 번 변경 사항을 프로덕션에 적용하는 것입니다. 복잡한 모놀리스에서는 애플리케이션의 한 부분을 업데이트하기 위해 전체 애플리케이션을 재배포해야 하므로 이는 매우 어렵습니다. 앞서 언급한 긴 시작 시간도 도움이 되지 않습니다. 또한 변경의 영향은 일반적으로 잘 이해되지 않기 때문에 광범위한 수동 테스트를 수행해야 할 수 있습니다. 결과적으로 지속적인 배포는 거의 불가능합니다.

모놀리식 애플리케이션은 서로 다른 모듈에 충돌하는 리소스 요구 사항이 있는 경우 확장하기 어려울 수도 있습니다. 예를 들어, 한 모듈은 CPU 집약적 이미지 처리 로직을 구현할 수 있으며 이상적으로는 Amazon EC2 Compute Optimized 인스턴스에 배포됩니다. 또 다른 모듈은 인메모리 데이터베이스일 수 있으며 EC2 메모리 최적화 인스턴스에 가장 적합합니다. 그러나 이러한 모듈이 함께 배포되기 때문에 하드웨어 선택에서 타협해야 합니다.

모놀리식 애플리케이션의 또 다른 문제는 안정성입니다. 모든 모듈이 동일한 프로세스 내에서 실행되기 때문에 메모리 누수와 같은 모든 모듈의 버그는 잠재적으로 전체 프로세스를 중단시킬 수 있습니다. 또한 애플리케이션의 모든 인스턴스가 동일하기 때문에 해당 버그는 전체 애플리케이션의 가용성에 영향을 미칩니다.

마지막으로, 모놀리식 애플리케이션은 새로운 프레임워크와 언어를 채택하는 것을 극도로 어렵게 만듭니다. 예를 들어 XYZ 프레임워크를 사용하여 작성된 코드가 200만 줄이라고 가정해 보겠습니다. 새 ABC 프레임워크가 훨씬 더 우수하더라도 전체 애플리케이션을 다시 작성하여 최신 ABC 프레임워크를 사용하는 것은 시간과 비용면에서 매우 비쌉니다. 결과적으로 새로운 기술을 채택하는 데 큰 장벽이 있습니다. 프로젝트를 시작할 때 선택한 기술이 무엇이든 고정되어 있습니다.

요약하자면, 개발자는 극소수의 개발자만 이해할 수 있는 거대한 단일체로 성장한 성공적인 비즈니스 크리티컬 애플리케이션을 보유하고 있습니다. 유능한 개발자를 고용하기 어렵게 만드는 구식의 비생산적인 기술을 사용하여 작성되었습니다. 응용 프로그램은 확장하기 어렵고 신뢰할 수 없습니다. 결과적으로 애자일 개발 및 애플리케이션 제공이 불가능합니다.

그래서 당신은 그것에 대해 무엇을 할 수 있습니까?

3. 마이크로서비스(Microservices) – 복잡성 해결

Amazon, eBay 및 Netflix와 같은 많은 조직은 현재 마이크로서비스 아키텍처 패턴으로 알려진 것을 채택하여 이 문제를 해결했습니다. 하나의 거대하고 모놀리식 애플리케이션을 구축하는 대신, 아이디어는 애플리케이션을 더 작고 상호 연결된 서비스 세트로 분할하는 것입니다.

서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 일련의 고유한 기능을 구현합니다. 각 마이크로 서비스는 다양한 어댑터와 함께 비즈니스 논리로 구성된 고유한 육각형 아키텍처가 있는 미니 애플리케이션입니다. 일부 마이크로 서비스는 다른 마이크로 서비스 또는 애플리케이션의 클라이언트가 사용하는 API를 노출합니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임 시 각 인스턴스는 종종 클라우드 VM 또는 Docker 컨테이너입니다.

예를 들어, 앞에서 설명한 시스템의 가능한 분해가 다음 다이어그램에 나와 있습니다.

애플리케이션의 각 기능 영역은 이제 자체 마이크로서비스로 구현됩니다. 또한 웹 애플리케이션은 더 간단한 웹 애플리케이션 세트로 분할됩니다(예: 택시 호출 예에서 승객용 및 운전자용). 이를 통해 특정 사용자, 장치 또는 특수 사용 사례에 대한 고유한 경험을 더 쉽게 배포할 수 있습니다.

각 백엔드 서비스는 REST API를 노출하고 대부분의 서비스는 다른 서비스에서 제공하는 API를 사용합니다. 예를 들어, 드라이버 관리는 알림 서버를 사용하여 사용 가능한 드라이버에게 잠재적인 여행에 대해 알립니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기식 메시지 기반 통신을 사용할 수도 있습니다. 서비스 간 통신은 이 시리즈의 뒷부분에서 더 자세히 다룰 것입니다.

일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 노출됩니다. 그러나 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신 API Gateway로 알려진 중개자가 통신을 중재합니다. API Gateway는 부하 분산, 캐싱, 접근 제어, API 계량, 모니터링 등의 작업을 담당하며 NGINX를 사용하여 효과적으로 구현할 수 있습니다.

마이크로서비스 아키텍처 패턴은 Scale Cube의 Y축 스케일링에 해당하며, 이는 Art of Scalability라는 책에 나오는 확장성의 3D 모델입니다. 다른 두 가지 조정 축은 로드 밸런서 뒤에서 여러 개의 동일한 애플리케이션 복사본을 실행하는 것으로 구성된 X축 조정과 요청의 속성(예: 기본 키 행 또는 고객의 ID)는 요청을 특정 서버로 라우팅하는 데 사용됩니다.

애플리케이션은 일반적으로 세 가지 유형의 확장을 함께 사용합니다. Y축 스케일링은 이 섹션의 첫 번째 그림에서와 같이 애플리케이션을 마이크로서비스로 분해합니다. 런타임 시 X축 확장은 처리량과 가용성을 위해 로드 밸런서 뒤에서 각 서비스의 여러 인스턴스를 실행합니다. 일부 애플리케이션은 Z축 스케일링을 사용하여 서비스를 분할할 수도 있습니다. 다음 다이어그램은 Amazon EC2에서 실행되는 Docker와 함께 Trip Management 서비스를 배포하는 방법을 보여줍니다.

런타임 시 여행 관리 서비스는 여러 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Docker 컨테이너입니다. 고가용성을 위해 컨테이너는 여러 Cloud VM에서 실행됩니다. 서비스 인스턴스 앞에는 인스턴스 간에 요청을 분산하는 NGINX와 같은 로드 밸런서가 있습니다. 로드 밸런서는 캐싱, 액세스 제어, API 측정 및 모니터링과 같은 다른 문제도 처리할 수 있습니다.

마이크로서비스 아키텍처 패턴은 애플리케이션과 데이터베이스 간의 관계에 상당한 영향을 미칩니다. 단일 데이터베이스 스키마를 다른 서비스와 공유하는 대신 각 서비스에는 자체 데이터베이스 스키마가 있습니다. 한편으로 이 접근 방식은 전사적 데이터 모델이라는 개념과 상충됩니다. 또한 일부 데이터가 중복되는 경우가 많습니다. 그러나 마이크로서비스의 이점을 얻으려면 서비스당 데이터베이스 스키마가 있어야 느슨한 결합이 보장되기 때문입니다. 다음 다이어그램은 예제 애플리케이션의 데이터베이스 아키텍처를 보여줍니다.

각 서비스에는 자체 데이터베이스가 있습니다. 또한 서비스는 요구 사항에 가장 적합한 데이터베이스 유형, 이른바 다중 언어 지속성 아키텍처를 사용할 수 있습니다. 예를 들어, 잠재적 승객과 가까운 운전자를 찾는 운전자 관리는 효율적인 지리 쿼리를 지원하는 데이터베이스를 사용해야 합니다.

표면적으로 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 접근 방식 모두에서 아키텍처는 서비스 세트로 구성됩니다. 그러나 마이크로서비스 아키텍처 패턴에 대해 생각하는 한 가지 방법은 웹 서비스 사양(WS‑) 및 엔터프라이즈 서비스 버스(ESB)의 상업화 및 인식된 수하물이 없는 SOA라는 것입니다. 마이크로서비스 기반 애플리케이션은 WS‑보다 REST와 같은 간단하고 가벼운 프로토콜을 선호합니다. 또한 ESB 사용을 매우 피하고 대신 마이크로서비스 자체에서 ESB와 유사한 기능을 구현합니다. 마이크로서비스 아키텍처 패턴은 표준 스키마 개념과 같은 SOA의 다른 부분도 거부합니다.

4. 마이크로서비스(Microservices)의 이점

마이크로서비스 아키텍처 패턴에는 여러 가지 중요한 이점이 있습니다. 첫째, 복잡성 문제를 다룬다. 그것은 괴물 같은 모놀리식 애플리케이션을 서비스 세트로 분해합니다. 기능의 총량은 변경되지 않았지만 애플리케이션은 관리 가능한 청크 또는 서비스로 나뉩니다. 각 서비스에는 RPC 또는 메시지 기반 API 형태로 잘 정의된 경계가 있습니다. 마이크로서비스 아키텍처 패턴은 실제로 모놀리식 코드 기반으로 달성하기 극히 어려운 수준의 모듈성을 적용합니다. 결과적으로 개별 서비스는 훨씬 더 빠르게 개발할 수 있고 훨씬 더 쉽게 이해하고 유지 관리할 수 있습니다.

둘째, 이 아키텍처를 사용하면 해당 서비스에 중점을 둔 팀에서 각 서비스를 독립적으로 개발할 수 있습니다. 서비스가 API 계약을 준수하는 경우 개발자는 합리적인 기술을 자유롭게 선택할 수 있습니다. 물론 대부분의 조직은 완전한 무정부 상태를 피하고 기술 옵션을 제한하기를 원할 것입니다. 그러나 이러한 자유는 개발자가 더 이상 새 프로젝트를 시작할 때 존재했던 사용되지 않을 가능성이 있는 기술을 사용할 의무가 없음을 의미합니다. 새로운 서비스를 작성할 때 현재 기술을 사용할 수 있는 옵션이 있습니다. 또한 서비스가 상대적으로 작기 때문에 현재 기술을 사용하여 오래된 서비스를 다시 작성하는 것이 가능합니다.

셋째, 마이크로서비스 아키텍처 패턴을 통해 각 마이크로서비스를 독립적으로 배포할 수 있습니다. 개발자는 서비스에 로컬인 변경 배포를 조정할 필요가 없습니다. 이러한 종류의 변경 사항은 테스트를 마치는 즉시 배포할 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적인 배포를 가능하게 합니다.

마지막으로 마이크로서비스 아키텍처 패턴을 사용하면 각 서비스를 독립적으로 확장할 수 있습니다. 용량 및 가용성 제약 조건을 충족하는 각 서비스의 인스턴스 수만큼만 배포할 수 있습니다. 또한 서비스의 리소스 요구 사항에 가장 잘 맞는 하드웨어를 사용할 수 있습니다. 예를 들어, EC2 Compute Optimized 인스턴스에 CPU 집약적 이미지 처리 서비스를 배포하고 EC2 메모리 최적화 인스턴스에 인메모리 데이터베이스 서비스를 배포할 수 있습니다.

5. 마이크로서비스(Microservices)의 단점

거의 30년 전에 Fred Brooks가 썼듯이 은총알은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에도 단점이 있습니다. 한 가지 단점은 이름 자체입니다. 마이크로서비스라는 용어는 서비스 규모를 지나치게 강조합니다. 사실, 극도로 세분화된 10-100 LOC 서비스 구축을 옹호하는 일부 개발자가 있습니다. 소규모 서비스가 바람직하지만 주요 목표가 아니라 목적을 위한 수단이라는 점을 기억하는 것이 중요합니다. 마이크로서비스의 목표는 애자일 애플리케이션 개발 및 배포를 용이하게 하기 위해 애플리케이션을 충분히 분해하는 것입니다.

마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 하는 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 또한 요청 대상이 느리거나 사용할 수 없을 수 있으므로 부분 실패를 처리하는 코드도 작성해야 합니다. 이 중 어느 것도 로켓 과학이 아니지만 모듈이 언어 수준 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션보다 훨씬 더 복잡합니다.

마이크로서비스의 또 다른 과제는 파티션된 데이터베이스 아키텍처입니다. 여러 비즈니스 항목을 업데이트하는 비즈니스 트랜잭션은 상당히 일반적입니다. 이러한 종류의 트랜잭션은 단일 데이터베이스가 있기 때문에 모놀리식 애플리케이션에서 구현하기가 쉽습니다. 그러나 마이크로서비스 기반 애플리케이션에서는 서로 다른 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션을 사용하는 것은 일반적으로 옵션이 아니며 CAP 정리 때문만도 아닙니다. 오늘날의 확장성이 뛰어난 많은 NoSQL 데이터베이스 및 메시징 브로커에서 지원하지 않습니다. 결국 개발자에게 더 어려운 최종 일관성 기반 접근 방식을 사용해야 합니다.

마이크로서비스 애플리케이션을 테스트하는 것도 훨씬 더 복잡합니다. 예를 들어, Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 간단합니다. 대조적으로, 서비스에 대한 유사한 테스트 클래스는 해당 서비스와 해당 서비스가 의존하는 모든 서비스를 시작해야 합니다(또는 최소한 해당 서비스에 대한 스텁을 구성해야 함). 다시 한 번, 이것은 로켓 과학이 아니지만 이 작업의 복잡성을 과소평가하지 않는 것이 중요합니다.

마이크로서비스 아키텍처 패턴의 또 다른 주요 과제는 여러 서비스에 걸쳐 변경을 구현하는 것입니다. 예를 들어 서비스 A, B, C에 대한 변경이 필요한 스토리를 구현한다고 가정해 봅시다. 여기서 A는 B에 의존하고 B는 C에 의존합니다. 모놀리식 애플리케이션에서는 단순히 해당 모듈을 변경하고 변경 사항을 통합하고, 한 번에 배포할 수 있습니다. 대조적으로, 마이크로서비스 아키텍처 패턴에서는 각 서비스에 대한 변경 사항의 롤아웃을 신중하게 계획하고 조정해야 합니다. 예를 들어 서비스 C를 업데이트한 다음 서비스 B를 업데이트한 다음 마지막으로 서비스 A를 업데이트해야 합니다. 다행히도 대부분의 변경 사항은 일반적으로 하나의 서비스에만 영향을 미치며 조정이 필요한 다중 서비스 변경 사항은 비교적 드뭅니다.

마이크로서비스 기반 애플리케이션을 배포하는 것도 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 기존 로드 밸런서 뒤에 있는 동일한 서버 세트에 간단히 배포됩니다. 각 애플리케이션 인스턴스는 데이터베이스 및 메시지 브로커와 같은 인프라 서비스의 위치(호스트 및 포트)로 구성됩니다. 대조적으로 마이크로서비스 애플리케이션은 일반적으로 많은 수의 서비스로 구성됩니다. 예를 들어, Hailo는 160개의 다른 서비스를 가지고 있고 Netflix는 Adrian Cockcroft[편집자 – Hailo는 MyTaxi에 인수되었습니다.]에 따르면 600개 이상의 서비스를 제공합니다. 각 서비스에는 여러 런타임 인스턴스가 있습니다. 구성, 배포, 확장 및 모니터링해야 하는 움직이는 부분이 훨씬 더 많습니다. 또한 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 검색할 수 있도록 하는 서비스 검색 메커니즘(나중 게시물에서 설명)을 구현해야 합니다. 운영에 대한 기존의 문제 티켓 기반 및 수동 접근 방식은 이 수준의 복잡성으로 확장할 수 없습니다. 결과적으로 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방법을 더 잘 제어하고 높은 수준의 자동화가 필요합니다.

자동화에 대한 한 가지 접근 방식은 Cloud Foundry와 같은 기성품 PaaS를 사용하는 것입니다. PaaS는 개발자에게 마이크로서비스를 쉽게 배포하고 관리할 수 있는 방법을 제공합니다. IT 리소스 조달 및 구성과 같은 문제로부터 이들을 보호합니다. 동시에 PaaS를 구성하는 시스템 및 네트워크 전문가는 모범 사례 및 회사 정책을 준수할 수 있습니다. 마이크로서비스 배포를 자동화하는 또 다른 방법은 본질적으로 자체 PaaS를 개발하는 것입니다. 일반적인 출발점 중 하나는 Kubernetes와 같은 클러스터링 솔루션을 Docker와 같은 기술과 함께 사용하는 것입니다. 이 시리즈의 뒷부분에서 마이크로서비스 수준에서 캐싱, 액세스 제어, API 측정 및 모니터링을 쉽게 처리하는 NGINX Plus와 같은 소프트웨어 기반 애플리케이션 제공 접근 방식이 이 문제를 해결하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다.

6. 요약

복잡한 애플리케이션을 구축하는 것은 본질적으로 어렵습니다. 모놀리식 아키텍처는 단순하고 가벼운 애플리케이션에만 적합합니다. 복잡한 응용 프로그램에 사용하면 고통의 세계에 빠지게 됩니다. 마이크로서비스 아키텍처 패턴은 단점과 구현 문제에도 불구하고 복잡하고 진화하는 애플리케이션에 더 나은 선택입니다.