마이크로서비스의 장단점

마이크로서비스 아키텍처는 조직이 소프트웨어 애플리케이션을 구축하고 배포하는 방식을 변화시켰습니다. 마이크로서비스는 모든 구성 요소가 긴밀하게 연결된 하나의 큰 애플리케이션을 만드는 대신 애플리케이션을 더 작고 독립적인 서비스로 세분화합니다. 각 서비스는 특정 비즈니스 기능을 처리하며 독립적으로 개발, 배포 및 확장할 수 있습니다.

Netflix, Uber, Amazon, Spotify, Airbnb 같은 기업들은 모두 마이크로서비스를 사용하여 매일 수백만 명의 사용자와 트랜잭션을 처리하고 있습니다.

조직이 기존 애플리케이션 설계에서 직면하는 문제를 해결하면서 마이크로서비스 아키텍처의 중요성이 점점 더 커지고 있습니다. 기업은 유연한 전체 시스템을 구축하고 장애를 쉽게 복구하며 새로운 기능을 더 빠르게 시장에 출시할 수 있습니다.

마이크로서비스는 이제 새로운 트렌드에서 엔터프라이즈 IT 전략의 핵심 요소로 자리 잡았습니다. Gartner에 따르면 설문조사에 참여한 조직의 74%가 현재 마이크로서비스 아키텍처를 사용하고 있으며, 23%는 마이크로서비스 아키텍처를 사용할 계획이라고 답했습니다.¹

마이크로서비스는 복잡성을 증가시키지만, 마이크로서비스의 이점으로 인해 산업 전반에 걸쳐 광범위한 채택이 이루어지고 있습니다. 마이크로서비스의 장단점을 이해하는 것은 정보에 입각한 도입 결정을 내리는 데 필수적입니다.

마이크로서비스 아키텍처는 애플리케이션의 설계 및 구축 방식이 긴밀하게 결합된 시스템에서 분산 아키텍처로 전환되는 근본적인 변화를 의미합니다. 개발자는 모든 것을 상호 연결된 하나의 시스템으로 구축하는 대신 기능을 느슨하게 결합된 별도의 서비스로 분리합니다. 독립적으로 배포 가능한 각 모듈은 특정 비즈니스 기능에 초점을 맞추고 자체 데이터 스토리지, 비즈니스 로직 및 통신 인터페이스를 통해 작동합니다.

마이크로서비스의 개념은 2010년대부터 시작되었으며, 비즈니스 애플리케이션을 서비스라고 하는 재사용 가능한 소프트웨어 구성 요소로 구축하는 접근 방식인 서비스 지향 아키텍처(SOA)로부터의 전환으로 거슬러 올라갑니다.

마이크로서비스는 SOA의 원칙을 기반으로 구축됩니다. 서비스는 규모가 작아지고 팀은 더 많은 자율성을 가지며 중앙 집중식 제어는 최소화됩니다. 이 아키텍처는 클라우드 컴퓨팅 및 클라우드 네이티브 개발의 부상과 함께 주목을 받았습니다. Amazon과 Netflix와 같은 대형 기술 기업은 애플리케이션의 여러 부분을 독립적으로 확장할 수 있는 유연성과 기능이 필요했기 때문에 이 접근 방식을 개척했습니다.

오늘날 마이크로서비스는 모든 규모의 조직에서 액세스할 수 있는 강력한 도구 및 플랫폼 에코시스템과 함께 주류로 자리 잡았습니다. 2023년 전 세계 마이크로서비스 아키텍처 시장의 가치는 3,760억 8,000만 달러에 달했습니다. 2024년부터 2030년까지 4.9%의 연평균 성장률로 성장하여 2030년에는 5,232억 2,000만 달러에 이를 것으로 예상됩니다.²

마이크로서비스와 모놀리식 애플리케이션 간의 차이점을 이해하면 많은 조직이 전환에 나서는 이유를 알 수 있습니다. 모놀리식 애플리케이션에서는 모든 것이 단일 코드베이스를 사용하여 하나의 단위로 구축됩니다. 예를 들어, 고객 주문, 재고 관리 및 청구를 처리하는 애플리케이션에는 이러한 모든 기능이 긴밀하게 통합되어 있을 것입니다. 한 부분을 변경하려면 다른 모든 부분에 어떤 영향을 미치는지 이해해야 합니다.

이러한 단순성으로 인해 초기 소프트웨어 개발은 더 간단해지지만 애플리케이션이 성장함에 따라 문제가 발생할 수 있습니다. 변경 사항이 발생하면 전체 애플리케이션을 다시 빌드하고 다시 배포해야 합니다. 모놀리식 아키텍처에서 더 많은 용량이 필요한 경우, 성능 용량을 늘릴 필요가 없는 부분까지 전체 애플리케이션을 확장해야 합니다.

마이크로서비스는 애플리케이션을 애플리케이션 프로그래밍 인터페이스(API)를 통해 서로 통신하는 별도의 서비스로 분할하여 이러한 문제를 해결합니다. 각 서비스에는 자체 코드베이스와 데이터베이스가 있으며 독립적으로 배포할 수 있습니다.

전 세계적으로 수억 명의 사용자를 보유한 음악 플랫폼 Spotify를 예로 들어 보겠습니다. 주요 앨범 발매 기간 동안 음악 스트리밍 수요가 급증하면 Spotify는 사용자 인증이나 결제 처리에 영향을 주지 않으면서 오디오 전송 및 재생 목록 서비스를 확장합니다. 이러한 접근 방식을 통해 여러 팀이 충돌 없이 개별 서비스를 동시에 작업할 수 있습니다.

마이크로서비스 아키텍처는 분산 시스템을 관리하는 데 있어 복잡성을 증가시킵니다. 많은 조직에서는 특정 사용 사례에 가장 적합한 것이 무엇인지에 따라 마이크로서비스와 모놀리식 시스템, 서버리스 기능 및 기타 아키텍처 패턴을 결합하는 하이브리드 접근 방식을 취합니다.

마이크로서비스는 아키텍처 패턴, 통신 방법 및 지원 기술의 조합을 통해 작동합니다. 각 마이크로서비스는 자체 프로세스로 실행되며 REST API, 메시지 대기열 또는 이벤트 스트림을 통해 해당 기능을 제공합니다. 서비스는 네트워크를 통해 통신하여 데이터를 공유하고 작업을 트리거합니다.

예를 들어, 고객이 Uber Eats를 통해 음식을 주문하면 여러 서비스가 순차적으로 함께 작동합니다. 시스템은 레스토랑 이용 가능 여부를 확인하고, 결제를 처리하고, 배달 드라이버를 배정하고, 고객에게 업데이트를 보냅니다. API 게이트웨이는 일반적으로 이러한 통신을 관리하여 요청을 적절한 마이크로서비스로 라우팅하는 단일 진입점 역할을 합니다.

마이크로서비스에는 Docker와 같은 컨테이너화 기술이 필수적입니다 컨테이너는 각 마이크로서비스를 실행하는 데 필요한 모든 것을 패키지화하여, 서로 다른 환경에서 동일한 방식으로 작동하는 표준화된 단위를 만듭니다.

Kubernetes와 유사한 클라우드 플랫폼은 이러한 컨테이너의 배포, 확장 및 관리를 자동화하여 이러한 발전을 더욱 발전시킵니다. 서비스 검색, 로드 밸런싱, 상태 모니터링, 장애 발생 시 자동 복구를 처리합니다.

Microsoft Azure, IBM Cloud 및 Google Cloud Platform과 같은 주요 클라우드 제공업체는 모두 마이크로서비스를 배포하고 오케스트레이션하기 위한 포괄적인 도구와 관리형 서비스를 제공합니다.

마이크로서비스는 컨테이너 외에도 서비스 간의 통신을 관리하는 서비스 메시, 요청 모니터링을 위한 분산 추적, 액세스 제어를 위한 API 관리 도구와 같은 다른 기술을 사용합니다. 구성 관리 시스템을 통해 서비스는 동적으로 설정을 검색하고 분산 로깅 플랫폼은 모든 서비스의 로그를 한곳으로 모을 수 있습니다.

마이크로서비스 아키텍처 통합의 이점은 광범위합니다. 가장 주목할 만한 주요 이점은 다음과 같습니다.

• 확장성 향상

• 민첩성 향상 및 시장 출시 시간 단축

• 장애 격리 및 시스템 복원력

• 비용 효과성

• DevOps 통합 및 지속적 제공

• 기술 유연성 및 혁신 

조직은 마이크로서비스를 통해 필요한 만큼만 정확하게 확장할 수 있습니다. 예를 들어 여행 숙박 플랫폼 기업인 Airbnb는 성수기가 되면 검색 및 예약 서비스를 확장하면서 호스트 메시지 및 리뷰 시스템과 같은 다른 서비스는 평상시 용량으로 유지합니다.

서비스마다 요구 사항에 따라 각기 다른 확장 전략을 사용합니다. 이러한 모듈식 접근 방식은 전체 모놀리식 애플리케이션을 확장하는 것에 비해 인프라 비용을 절감하고 리소스 효율성을 개선합니다.

소규모의 자율적인 팀이 특정 서비스를 엔드투엔드로 소유합니다. 각 팀은 서비스에 가장 적합한 기술을 선택하고 조직 전체의 조정이나 재배포 주기를 기다릴 필요 없이 각자의 속도에 맞춰 움직입니다.

기업은 기존 서비스에 연결되는 새로운 서비스와 같은 기능을 구축하여 아이디어를 빠르게 테스트하고, 빠르게 반복하며, 시장 변화에 더 빠르게 대응할 수 있습니다.

추천 엔진에 오류가 발생하더라도 사용자는 여전히 제품을 둘러보고 장바구니에 담아 결제할 수 있습니다. 회로 차단기 및 유사한 패턴을 사용하면 종속 서비스가 응답하지 않을 때에도 서비스가 원활하게 장애를 처리할 수 있습니다.

이러한 복원력은 다운타임 비용이 분당 수천 달러에 달하는 기업에게 매우 중요합니다. 개별 구성 요소에 장애가 발생하더라도 장애가 격리된 상태로 유지되므로 전체 애플리케이션이 다운되는 경우는 거의 없습니다.

기업은 효율적인 리소스 관리를 통해 전체 애플리케이션이 아닌 더 큰 용량이 필요한 서비스만 확장하여 비용을 절감할 수 있습니다. 개발팀은 각 서비스의 특정 요구사항에 가장 적합한 기술 스택을 선택하여 비용을 최적화할 수 있으므로 과도한 엔지니어링이나 엔터프라이즈급 솔루션을 일률적으로 적용하는 데 드는 비용을 피할 수 있습니다. 클라우드 기반 마이크로서비스의 종량제 모델은 실제 사용량에 따라 비용을 직접 조정합니다.

IBM의 설문조사 '2021년 기업 내 마이크로서비스'에 따르면 1,200명 이상의 IT 임원, 개발자 임원, 개발자 중 87%가 마이크로서비스 도입이 비용과 노력을 들일 만한 가치가 있다는 데 동의했습니다.

DevOps 팀은 각 서비스의 독립적인 운영으로 인해 다운타임 없이 새로운 구성 요소를 원활하게 도입할 수 있습니다.

자동화된 테스트, 배포 파이프라인 및 코드형 인프라(IaC)는 마이크로서비스와 잘 작동하여 신속하고 안정적인 릴리스 문화를 조성합니다.

각 마이크로서비스는 특정 기능에 가장 적합한 프로그래밍 언어(예: Java, Python), 프레임워크 및 데이터베이스를 비롯한 다양한 기술을 사용할 수 있습니다. 팀은 전체 애플리케이션에 대한 단일 기술 스택에 구속되지 않습니다.

조직은 새로운 기술을 점진적으로 도입하고, 새로운 도구를 실험하고, 가장 큰 가치를 제공하는 전문 솔루션을 활용할 수 있습니다.  

마이크로서비스는 상당한 이점을 제공하지만, 조직이 해결해야 하는 몇 가지 단점도 있습니다.

• 테스트 복잡성

• 보안 고려 사항

• 커뮤니케이션 조정

• 데이터 관리

마이크로 서비스 기반 애플리케이션을 테스트하려면 모놀리식 애플리케이션과는 다른 접근 방식이 필요합니다. 모든 종속성, 캐싱 및 데이터 접근은 적절한 성능을 위해 검증이 필요합니다. 테스트 환경에는 적절한 구성 및 데이터로 동시에 실행되는 여러 서비스가 포함됩니다.

서비스가 성장함에 따라 테스트 시나리오도 확장됩니다. 서비스 전반에서 테스트 데이터 일관성과 데이터 무결성을 유지하려면 전략적 계획이 필요합니다.

마이크로서비스 간의 네트워크 통신으로 인해 보안 요구 사항이 강화됩니다. API 게이트웨이에는 적절한 인증과 암호화가 필요합니다.

여러 마이크로서비스에서 자격 증명과 액세스 토큰을 관리하려면 신중한 조정이 필요하며, 보안팀은 분산 아키텍처 전반의 활동을 모니터링할 수 있는 강력한 가시성 도구가 필요합니다.

서비스 간 커뮤니케이션을 조정할 때는 설계 고려 사항이 필수적입니다. 서비스 간 호출은 처리 중인 함수 호출에 비해 네트워크 지연 시간이 길어지며, 요청이 여러 서비스를 거치면서 이러한 지연 시간은 누적됩니다.

재시도 로직, 시간 초과 및 장애 처리와 같은 네트워크 복원력 기능은 표준 관행이 되었습니다. 또한 서비스가 독립적으로 발전함에 따라 API 버전을 관리하려면 신중한 계획이 필요합니다.

각 마이크로서비스가 자체 데이터베이스를 관리하면 데이터 관리 문제가 발생합니다. 트랜잭션이 여러 데이터베이스에 걸쳐 있을 때 일관성을 유지하려면 특정 패턴이 필요하며, 데이터가 중앙 집중화되지 않고 분산된 경우 보고에 다른 접근 방식이 필요합니다.

마이크로서비스 아키텍처는 신중한 계획과 신중한 실행이 필요합니다. 모범 사례에는 다음과 같은 핵심 전략이 포함됩니다.

• 명확한 서비스 경계 정의

• 포괄적인 관측 가능성 구현

• 복원력을 위한 계획 수립

• 인프라 관리 자동화