최신 애플리케이션에서 마이크로서비스의 이점과 과제

웹 개발 초기에는 소프트웨어 애플리케이션을 구축하는 것이 간단했습니다. 코드를 작성하고 이를 단일 실행 가능 또는 배포 가능한 아카이브로 패키지한 다음 서버에서 실행했습니다. 모놀리식 아키텍처라고 알려진 이 접근 방식은 수십 년 동안 업계에서 잘 활용되었습니다.

그러나 애플리케이션이 수백 명의 개발자와 수백만 명의 동시 사용자를 갖춘 대규모 엔터프라이즈 플랫폼으로 성장하면서 모놀리스는 한계를 보이기 시작했습니다. 배포는 느리고 위험해졌으며, 데이터베이스는 병목 현상을 일으키고, 코드베이스는 단일 개발자가 이해하기에는 너무 복잡해졌습니다.

이러한 확장성 병목 현상을 해결하기 위해 업계는 마이크로서비스 아키텍처로 전환했습니다. 개발자는 하나의 거대한 애플리케이션을 구축하는 대신 시스템을 HTTP/REST, gRPC 또는 메시지 브로커와 같은 경량 프로토콜을 통해 통신하는 작고 독립적이며 느슨하게 연결된 서비스 모음으로 나눕니다.

이 기사에서는 마이크로서비스가 최신 애플리케이션에 제공하는 주요 이점, 이로 인해 발생하는 심각한 과제, 이 아키텍처가 다음 프로젝트에 적합한지 결정하는 방법을 분석합니다.

1. 모놀리식 아키텍처와 마이크로서비스 아키텍처

세부 사항을 살펴보기 전에 이 두 가지 디자인 패러다임 간의 근본적인 차이점을 시각화해 보겠습니다.

모놀리스에서는 모든 모듈(예: 사용자 관리, 제품 카탈로그, 주문 처리)이 동일한 실행 공간을 공유하고 단일 공유 데이터베이스에 기록합니다. 마이크로서비스 설정에서 각 서비스는 자체 프로세스에서 실행되고, 자체 비공개 데이터베이스를 관리하며, 깔끔한 API를 노출합니다. API 게이트웨이는 클라이언트의 단일 진입점 역할을 하며 요청을 적절한 백엔드 서비스로 라우팅합니다.

2. 마이크로서비스의 이점

마이크로서비스 아키텍처를 채택하면 대규모 현대 시스템에서 선호되는 여러 가지 강력한 이점이 제공됩니다.

A. 독립적 배포 가능성 및 릴리스 속도

모놀리스에서는 결제 시스템에 작은 변경 사항을 배포하려면 전체 애플리케이션을 다시 구축하고 재배포해야 합니다. 한 팀의 기능이 중단되면 전체 릴리스가 차단됩니다. 마이크로서비스를 사용하면 각 서비스에는 자체적인 독립적인 CI/CD 파이프라인이 있습니다. 배송 서비스 팀은 재고 또는 결제 팀과의 조정 없이 하루에 10번 업데이트를 배포할 수 있어 기능 제공 속도가 대폭 향상됩니다.

B. 세분화된 확장성

모놀리식 애플리케이션에서 블랙 프라이데이 동안 결제 프로세스에 대규모 트래픽 급증이 발생하는 경우 전체 애플리케이션을 수평으로 확장해야 합니다. 이는 유휴 모듈에 불필요한 CPU와 메모리를 소비합니다. 마이크로서비스는 타겟 확장을 허용합니다. 주문 및 결제 서비스의 인스턴스 50개를 가동하여 로드를 처리하는 동시에 사용자 또는 알림 서비스를 최소한의 리소스로 실행하여 상당한 클라우드 호스팅 비용을 절약할 수 있습니다.

C. 기술 유연성(다언어 프로그래밍)

마이크로서비스는 표준화된 API 프로토콜(REST, gRPC)을 통해 통신하므로 팀이 단일 기술 스택에 얽매이지 않습니다.

• User Service는 고성능 메모리 관리를 위해 Go로 작성할 수 있습니다.
• 추천 엔진은 풍부한 기계 학습 라이브러리를 위해 Python을 사용할 수 있습니다.
• Payment Gateway는 기업 안정성을 위해 Java로 작성할 수 있습니다. 각 팀은 특정 문제에 가장 적합한 도구를 선택할 수 있습니다.

D. 장애 격리 및 시스템 복원력

모놀리식 애플리케이션에서 메모리 누수가 발생하면 전체 프로세스가 중단되어 전체 시스템이 중단됩니다. 마이크로서비스 아키텍처에서는 버그로 인해 권장 사항 서비스가 중단되는 경우 애플리케이션의 나머지 부분은 완전히 작동합니다. 사용자는 계속해서 제품을 찾아보고, 장바구니에 항목을 추가하고, 결제를 완료할 수 있습니다. 실패는 격리됩니다.

E. 팀 정렬 및 자율성(콘웨이의 법칙)

콘웨이의 법칙에 따르면 조직은 커뮤니케이션 구조를 모방한 시스템을 설계합니다. 대규모 단일체로 인해 서로 협력하는 대규모 다기능 팀이 탄생하는 경우가 많습니다. 마이크로서비스를 사용하면 조직은 엔지니어링 부서를 소규모의 자율적인 “피자 두 개 팀"으로 나눌 수 있습니다. 각 팀은 설계 및 코드 작성부터 배포 및 데이터베이스 유지 관리에 이르기까지 엔드투엔드 단일 서비스를 소유합니다.

3. 마이크로서비스의 과제

이점은 매력적이지만 마이크로서비스는 공짜 점심이 아닙니다. 이로 인해 상당한 복잡성과 운영상의 어려움이 발생합니다.

A. 분산 시스템 복잡성 및 지연 시간

메모리 내 함수 호출에서 네트워크 호출로 이동하면 두 가지 주요 과제가 발생합니다.

1. 네트워크 대기 시간: 단일 사용자 작업으로 인해 서비스 간 요청 체인이 트리거되어 네트워크 대기 시간이 늘어나고 응답 시간이 느려질 수 있습니다.
2. 네트워크 오류: 네트워크가 불안정합니다. 서비스는 지수 백오프를 사용한 재시도, 시간 초과, 회로 차단기(Resilience4j와 같은 도구 또는 Istio와 같은 서비스 메시 사용)와 같은 탄력적인 통신 패턴을 구현해야 합니다.

B. 데이터 일관성과 ACID 거래의 종말

모놀리스에서는 데이터 무결성을 유지하는 것이 쉽습니다. 단일 데이터베이스 트랜잭션으로 작업을 래핑합니다.

BEGIN TRANSACTION;
  UPDATE inventory SET stock = stock - 1 WHERE item_id = 101;
  INSERT INTO orders (user_id, item_id) VALUES (1, 101);
COMMIT; -- If either fails, the database rolls back automatically

마이크로서비스에서는 재고 데이터베이스와 주문 데이터베이스가 완전히 별개입니다. 실제 네트워크 경계를 넘어 로컬 데이터베이스 트랜잭션을 사용할 수 없습니다.

대신 개발자는 서비스가 브로커(Apache Kafka 또는 RabbitMQ 등)에 메시지를 게시하고 체인의 한 단계 아래 단계가 실패할 경우 보상 트랜잭션을 실행하여 상태를 롤백하는 이벤트 기반 워크플로를 사용하여 사가 패턴을 구현해야 합니다. 이로 인해 최종 일관성이 도입되어 설계 및 디버깅이 훨씬 더 어려워졌습니다.

C. 운영 및 인프라 오버헤드

마이크로서비스 생태계를 관리하려면 강력한 인프라 플랫폼이 필요합니다. 조직은 다음을 채택해야 합니다.

• 컨테이너화: Docker 컨테이너에 서비스를 래핑합니다.
• 조정: Kubernetes를 사용하여 수백 개의 컨테이너를 관리합니다.
• 서비스 검색: 서비스가 서로의 IP 주소를 동적으로 찾도록 합니다(Consul, Eureka).
• API 게이트웨이: 엣지(Kong, AWS API 게이트웨이)에서 보안, 속도 제한 및 요청 라우팅을 관리합니다.

D. 분산 관찰 가능성 및 디버깅

사용자가 모놀리스에서 오류를 발견하면 서버 로그를 확인하는 것은 간단합니다. 마이크로서비스 시스템에서 요청은 10개의 서로 다른 서비스를 통과할 수 있습니다. 오류가 발생한 위치나 요청이 느린 이유를 찾으려면 들어오는 모든 요청에 ​​고유한 Correlation ID을 첨부하는 분산 추적 도구(예: Jaeger, OpenTelemetry 또는 Zipkin)가 필요합니다.

4. 모놀리스와 마이크로서비스: 한눈에 비교

결론: 어떻게 선택해야 할까요?

마이크로서비스는 기능적 문제가 아닌 조직 및 확장 문제에 대한 아키텍처 솔루션입니다.

MVP(최소 실행 가능 제품)를 구축하는 스타트업의 경우 마이크로서비스로 시작하는 것은 거의 항상 실수입니다. 운영 오버헤드와 분산된 복잡성으로 인해 개발 속도가 느려집니다. 깔끔한 모듈식 모놀리스가 최고의 출발점입니다.

그러나 팀이 서로의 배포를 차단할 정도로 애플리케이션이 성장했거나, 확장 비용이 급증하거나, 데이터베이스 병목 현상이 불가피한 경우, 마이크로서비스 아키텍처로 마이그레이션하는 것은 다음 단계의 성장과 제공 속도를 실현할 수 있는 강력한 방법입니다.

Ghaznix 블로그에서 더 많은 소프트웨어 아키텍처, 디자인 패턴 및 엔지니어링 통찰력을 살펴보세요 →