마이크로서비스 또는 마이크로서비스 아키텍처는 하나의 애플리케이션이 느슨하게 결합되고 독립적으로 배포 가능한 여러 개의 작은 구성 요소 또는 서비스로 구성된 클라우드 네이티브 아키텍처 방식입니다.
마이크로 서비스는 일반적으로 다음과 같습니다.
- 데이터베이스 및 데이터 관리 모델을 포함하는 자체 기술 스택을 보유합니다.
- 표현 상태 전송(REST) API, 이벤트 스트리밍 및 메시지 브로커의 조합을 통해 서로 통신합니다.
- 비즈니스 기능에 따라 구성되며, 종종 경계가 있는 컨텍스트라고 하는 서비스를 구분하는 선이 있습니다.
마이크로서비스에 대한 많은 논의가 아키텍처 정의와 특성을 중심으로 이루어졌지만, 마이크로서비스의 가치는 매우 간단한 비즈니스 및 조직적 이점을 통해 더 일반적으로 이해할 수 있습니다.
- 전체 애플리케이션을 건드리지 않고도 새로운 기능이나 능력을 추가할 수 있어 코드 업데이트가 더욱 쉬워집니다.
- 팀은 서로 다른 구성 요소에 대해 서로 다른 스택과 서로 다른 프로그래밍 언어를 사용할 수 있습니다.
- 구성 요소를 서로 독립적으로 확장할 수 있으므로 단일 기능에 너무 많은 부하가 걸려 전체 애플리케이션을 확장해야 하는 데 따르는 낭비와 비용을 줄일 수 있습니다.
마이크로서비스가 아닌 것
마이크로서비스는 이전의 두 가지 애플리케이션 아키텍처인 모놀리식 아키텍처와 서비스 지향 아키텍처(SOA)와 대비하여 이해할 수도 있습니다.
마이크로서비스와 모놀리식 아키텍처의 차이점은 마이크로서비스는 긴밀하게 결합된 대규모 애플리케이션의 모놀리식 접근 방식과 달리 여러 개의 작고 느슨하게 결합된 서비스로 하나의 애플리케이션을 구성한다는 점입니다.
마이크로서비스와 SOA의 차이점은 다소 명확하지 않을 수 있습니다. 특히 엔터프라이즈 서비스 버스의 역할과 관련하여 마이크로서비스와 SOA를 기술적으로 대조할 수 있지만, 그 차이를 범위의 차이로 간주하는 것이 더 쉽습니다. SOA는 조직의 모든 웹 서비스가 서로 통신하고 통합하는 방식을 표준화하기 위한 전사적인 노력인 반면, 마이크로서비스 아키텍처는 애플리케이션별로 다릅니다.
마이크로서비스는 적어도 개발자만큼이나 경영진과 프로젝트 리더들에게도 인기가 있을 가능성이 높습니다. 아키텍처에 대한 열정은 일반적으로 소프트웨어 개발 팀에 국한되어 있기 때문에 이는 마이크로서비스의 보다 특이한 특성 중 하나입니다. 그 이유는 마이크로서비스가 많은 비즈니스 리더가 팀과 개발 프로세스를 구성하고 운영하고자 하는 방식을 더 잘 반영하기 때문입니다.
다시 말해, 마이크로서비스는 원하는 운영 모델을 더 잘 구현할 수 있는 아키텍처 모델입니다. 2021년 IBM이 1,200명 이상의 개발자와 IT 임원을 대상으로 실시한 설문조사에 따르면, 마이크로서비스 사용자의 87%가 마이크로서비스 도입이 비용과 노력을 들일 만한 가치가 있다고 동의했습니다.
다음은 마이크로서비스의 몇 가지 엔터프라이즈 이점입니다.
독립적으로 배포 가능
마이크로서비스의 가장 중요한 특징은 서비스가 더 작고 독립적으로 배포할 수 있기 때문에 코드 한 줄을 변경하거나 애플리케이션에 새로운 기능을 추가하는 데 더 이상 의회의 동의가 필요하지 않다는 점입니다.
마이크로서비스는 작은 변화에도 엄청난 시간이 소요되는 조직의 본능적인 불만을 해소할 수 있는 해결책을 제공합니다. 컴퓨터 공학 박사 학위가 없어도 속도와 민첩성을 향상시키는 접근 방식의 가치를 보거나 이해할 수 있습니다.
그러나 이러한 방식으로 서비스를 설계하는 데 필요한 가치는 속도뿐만이 아닙니다. 최근 떠오르는 일반적인 조직 모델의 목적은 비즈니스 문제, 서비스 또는 제품을 중심으로 여러 기능의 팀을 하나로 모으는 것입니다. 마이크로서비스 모델은 조직이 하나의 서비스 또는 여러 서비스를 중심으로 소규모의 교차 기능 팀을 만들어 민첩한 방식으로 운영할 수 있기 때문에 이러한 트렌드에 잘 맞습니다.
마이크로서비스의 느슨한 결합은 또한 애플리케이션에 어느 정도의 오류 격리 및 더 나은 복원력을 구축합니다. 또한 서비스의 규모가 작고 경계와 커뮤니케이션 패턴이 명확하기 때문에 새로운 팀원이 코드 기반을 더 쉽게 이해하고 빠르게 기여할 수 있어 속도와 직원 사기 측면에서 분명한 이점이 있습니다.
작업에 적합한 툴
기존의 n계층 아키텍처 패턴에서 애플리케이션은 일반적으로 공통 스택을 공유하고, 대규모 관계형 데이터베이스가 전체 애플리케이션을 지원합니다. 이 접근 방식에는 몇 가지 명백한 단점이 있는데, 그 중 가장 중요한 것은 특정 요소에 대한 작업을 위한 명확하고 더 나은 도구가 있더라도 애플리케이션의 모든 구성 요소가 공통 스택, 데이터 모델 및 데이터베이스를 공유해야 한다는 점입니다. 이는 잘못된 아키텍처를 만들며, 이러한 구성 요소를 구축하는 더 좋고 효율적인 방법이 있다는 것을 항상 알고 있는 개발자에게는 실망스러운 일입니다.
반면 마이크로서비스 모델에서는 구성 요소가 독립적으로 배포되고 REST, 이벤트 스트리밍 및 메시지 브로커의 조합을 통해 통신하므로 모든 개별 서비스의 스택을 해당 서비스에 맞게 최적화할 수 있습니다. 기술은 항상 변화하며, 여러 개의 소규모 서비스로 구성된 애플리케이션은 더 바람직한 기술이 등장할 때 더 나은 기술로 진화하는 것이 훨씬 쉽고 비용도 적게 듭니다.
정밀한 확장
마이크로서비스를 사용하면 개별 서비스를 개별적으로 배포할 수 있을 뿐만 아니라 개별적으로 확장할 수도 있습니다. 그 결과로 얻을 수 있는 이점은 명백합니다. 올바르게 수행된 마이크로서비스는 모놀리식 애플리케이션의 경우 전체 애플리케이션 대신 필요한 구성 요소만 정밀하게 확장할 수 있기 때문에 모놀리식 애플리케이션보다 인프라가 덜 필요합니다.
마이크로서비스에도 다음과 같은 도전 과제가 있습니다.
마이크로서비스의 중요한 이점에는 상당한 도전 과제가 따릅니다. 모놀리스에서 마이크로서비스로 전환하면 훨씬 더 많은 팀이 훨씬 더 많은 서비스를 훨씬 더 많은 장소에 배포하는 등 관리가 훨씬 더 복잡해집니다. 한 서비스에서 발생한 문제가 다른 서비스에서 문제를 일으키거나 원인이 될 수 있습니다. 로깅 데이터(모니터링 및 문제 해결에 사용)는 더 방대하며 서비스 간에 일관성이 없을 수 있습니다. 새 버전에서는 이전 버전과의 호환성 문제가 발생할 수 있습니다. 애플리케이션에는 더 많은 네트워크 연결이 필요하므로 지연 시간 및 연결 문제가 발생할 가능성이 더 커집니다. DevOps 접근 방식은 이러한 많은 문제를 해결할 수 있지만 DevOps 채택에는 나름의 어려움이 있습니다.
그럼에도 불구하고 이러한 문제로 인해 비채택자가 마이크로서비스를 채택하거나 채택자가 마이크로서비스에 대한 노력을 심화하는 것을 막을 수는 없습니다. 앞서 언급한 IBM 설문조사 데이터에 따르면 현재 마이크로서비스를 사용하지 않는 사용자의 56%는 향후 2년 이내에 마이크로서비스를 채택할 가능성이 있거나 매우 높으며, 현재 마이크로서비스 사용자의 78%는 마이크로서비스에 투자한 시간, 비용 및 노력을 늘릴 것으로 보입니다.
마이크로서비스 아키텍처는 종종 DevOps와 지속적 통합 또는 지속적 배포에 최적화된 것으로 설명되며, 자주 배포할 수 있는 소규모 서비스의 맥락에서 보면 그 이유를 쉽게 이해할 수 있습니다.
하지만 마이크로서비스와 DevOps의 관계를 바라보는 또 다른 방법은 마이크로서비스 아키텍처가 성공하기 위해서는 실제로 DevOps가 필요하다는 것입니다. 모놀리식 애플리케이션에는 이 글의 앞부분에서 설명한 다양한 단점이 있지만, 여러 개의 움직이는 부품과 독립적인 기술 스택이 있는 복잡한 분산 시스템이 아니라는 이점이 있습니다. 반대로 마이크로서비스와 함께 제공되는 복잡성, 움직이는 부품 및 종속성의 엄청난 증가를 고려할 때 배포, 모니터링 및 수명 주기 자동화에 대한 상당한 투자 없이 마이크로서비스에 접근하는 것은 현명하지 못합니다.
Rosalind Radcliffe가 동영상에서 DevOps에 대해 자세히 설명합니다.
마이크로서비스 아키텍처에서는 거의 모든 최신 툴이나 언어를 사용할 수 있지만, 마이크로서비스에 필수적이고 경계가 모호해진 몇 가지 핵심 툴이 있습니다.
마이크로서비스의 핵심 요소 중 하나는 일반적으로 규모가 매우 작다는 점입니다. 어떤 것이 마이크로 서비스인지 아닌지를 결정하는 임의의 코드가 있는 것은 아니지만, 이름에 '마이크로'가 바로 들어가 있습니다.
2013년 현대의 컨테이너 시대를 열었던 Docker는 마이크로서비스와 가장 밀접한 관련이 있는 컴퓨팅 모델도 도입했습니다. 개별 컨테이너는 자체 운영 체제의 오버헤드가 없기 때문에 기존 가상 머신보다 작고 가벼우며 더 빠르게 스핀업 및 스핀다운할 수 있어 마이크로서비스 아키텍처에서 볼 수 있는 더 작고 가벼운 서비스와 완벽하게 어울립니다.
서비스와 컨테이너가 확산되면서 대규모 컨테이너 그룹을 오케스트레이션하고 관리하는 것이 중요한 과제 중 하나가 되었습니다. 오픈 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 이러한 작업을 매우 잘 수행하기 때문에 가장 인기 있는 오케스트레이션 솔루션 중 하나로 부상했습니다.
마이크로서비스는 특히 처음 상태를 설정할 때 API를 통해 통신하는 경우가 많습니다. 클라이언트와 서비스가 서로 직접 통신할 수 있는 것도 사실이지만, 특히 애플리케이션의 서비스 수가 시간이 지남에 따라 증가함에 따라 API Gateway는 유용한 중개 계층이 되는 경우가 많습니다. API Gateway는 요청을 라우팅하고 여러 서비스에 걸쳐 요청을 분산하며 추가 보안 및 인증을 제공하여 클라이언트를 위한 역방향 프록시 역할을 합니다.
API 관리 플랫폼을 포함하여 API Gateway를 구현하는 데 사용할 수 있는 여러 기술이 있지만, 마이크로서비스 아키텍처가 컨테이너와 Kubernetes를 사용하여 구현되는 경우 게이트웨이는 일반적으로 인그레스(Ingress) 또는 최근에는 Istio를 사용하여 구현됩니다.
상태 비저장 서비스를 설계하는 것이 가장 좋은 방법일 수 있지만, 그럼에도 불구하고 상태는 존재하며 서비스는 이를 인식해야 합니다. API 호출은 특정 서비스의 상태를 처음에 설정하는 데 효과적인 경우가 많지만, 최신 상태를 유지하는 데는 그다지 효과적이지 않습니다. 서비스를 최신 상태로 유지하기 위해 "아직 멀었나?"라는 식의 지속적인 설문조사 방식은 실용적이지 않습니다.
대신 상태 설정 API 호출을 메시징 또는 이벤트 스트리밍과 결합하여 서비스가 상태 변경 사항을 브로드캐스트하고 다른 이해관계자가 이러한 변경 사항을 수신하여 그에 따라 조정할 수 있도록 해야 합니다. 이 작업은 범용 메시지 브로커가 가장 적합할 수 있지만, Apache Kafka와 같은 이벤트 스트리밍 플랫폼이 적합한 경우도 있습니다. 또한 개발자는 마이크로서비스를 이벤트 기반 아키텍처와 결합하여 대량의 이벤트 또는 정보를 실시간으로 사용하고 처리할 수 있는 확장성이 뛰어나고 내결함성이 뛰어난 분산형 시스템을 구축할 수 있습니다.
서버리스 아키텍처는 몇 가지 핵심 클라우드 및 마이크로서비스 패턴을 기반으로 논리적인 결론을 짓습니다. 서버리스의 경우 실행 단위는 작은 서비스가 아니라 함수로, 코드 몇 줄에 불과한 경우가 많습니다. 서버리스 기능과 마이크로서비스를 구분하는 선은 모호하지만, 일반적으로 기능은 마이크로서비스보다 더 작다고 알려져 있습니다.
서버리스 아키텍처와 서비스형(Funcs-as-a-Service) 플랫폼이 마이크로서비스와 비슷한 점은 둘 다 더 작은 배포 단위를 만들고 수요에 따라 정확하게 확장하는 데 관심이 있다는 것입니다.
마이크로서비스가 반드시 클라우드 컴퓨팅과만 관련이 있는 것은 아니지만, 마이크로서비스가 새로운 애플리케이션의 인기 있는 아키텍처 스타일이고 클라우드가 새로운 애플리케이션의 인기 있는 호스팅 대상이라는 것 외에도 두 서비스가 자주 함께 사용되는 몇 가지 중요한 이유가 있습니다.
마이크로서비스 아키텍처의 주요 이점 중에는 구성 요소를 개별적으로 배포하고 확장하는 것과 관련된 활용도 및 비용 이점이 있습니다. 온프레미스 인프라에서도 이러한 이점을 어느 정도 누릴 수 있지만, 독립적으로 확장 가능한 소규모 구성 요소와 온디맨드 종량제 인프라를 결합하면 실질적인 비용 최적화를 이룰 수 있습니다.
둘째, 더 중요한 마이크로서비스의 또 다른 주요 이점은 각 개별 구성 요소가 특정 업무에 가장 적합한 스택을 채택할 수 있다는 점입니다. 스택이 급증하면 직접 관리할 경우 심각한 복잡성과 오버헤드가 발생할 수 있지만, 클라우드 서비스로서 지원 스택을 소비하면 관리 문제를 크게 최소화할 수 있습니다. 다시 말해, 자체 마이크로서비스 인프라를 구축하는 것이 불가능한 것은 아니지만, 특히 이제 막 시작하는 경우에는 바람직하지 않습니다.
마이크로서비스 아키텍처에는 다음과 같은 몇 가지 일반적인 과제와 기회를 해결하는 데 도움이 되는 일반적이고 유용한 설계, 커뮤니케이션 및 통합 패턴이 많이 있습니다.
Backend-for-frontend(BFF) 패턴
이 패턴은 사용자 경험과 경험이 호출하는 리소스 사이에 계층을 삽입합니다. 예를 들어 데스크톱에서 사용하는 앱은 모바일 디바이스와 화면 크기, 디스플레이 및 성능 제한이 다릅니다. BFF 패턴을 사용하면 개발자는 모든 인터페이스에서 작동하지만 프론트엔드 성능에 부정적인 영향을 미칠 수 있는 일반적인 백엔드를 지원하는 대신 해당 인터페이스에 가장 적합한 옵션을 사용하여 사용자 인터페이스당 하나의 백엔드 유형을 생성하고 지원할 수 있습니다.
엔티티 및 집계 패턴
엔티티는 해당 ID로 구별되는 개체입니다. 예를 들어, 전자 상거래 사이트에서 제품 개체는 제품 이름, 유형 및 가격으로 구별될 수 있습니다. 집계는 하나의 단위로 취급되어야 하는 관련 엔티티의 모음입니다. 따라서 전자 상거래 사이트의 경우 주문은 구매자가 주문한 제품(엔티티)의 모음(집합)입니다. 이러한 패턴은 의미 있는 방식으로 데이터를 분류하는 데 사용됩니다.
서비스 검색 패턴
이는 애플리케이션과 서비스가 서로를 찾는 데 도움이 됩니다. 마이크로서비스 아키텍처에서 서비스 인스턴스는 크기 조정, 업그레이드, 서비스 실패, 심지어 서비스 종료로 인해 동적으로 변경됩니다. 이러한 패턴은 이러한 일시적인 상황에 대처할 수 있는 검색 메커니즘을 제공합니다. 로드 밸런싱은 상태 확인 및 서비스 실패를 트리거로 사용하여 트래픽을 재조정하는 서비스 검색 패턴을 사용할 수 있습니다.
어댑터 마이크로서비스 패턴
다른 나라를 여행할 때 사용하는 플러그 어댑터를 생각하는 방식으로 어댑터 패턴을 생각해 보세요. 어댑터 패턴의 목적은 호환되지 않는 클래스 또는 객체 간의 관계를 변환하는 데 있습니다. 타사 API에 의존하는 애플리케이션은 애플리케이션과 API가 통신할 수 있도록 어댑터 패턴을 사용해야 할 수도 있습니다.
스트랭글러 애플리케이션 패턴
이러한 패턴은 모놀리식 애플리케이션을 마이크로서비스 애플리케이션으로 리팩토링하는 것을 관리하는 데 도움이 됩니다. 이 화려한 이름은 포도나무(마이크로 서비스)가 천천히 시간이 지남에 따라 나무(모놀리식 애플리케이션)를 추월하여 목을 조르는 모습을 비유한 것입니다.
마이크로서비스를 원활하게 수행하기 위한 패턴은 많지만, 개발 팀을 빠르게 곤경에 빠뜨릴 수 있는 패턴도 상당히 많습니다. 마이크로서비스에서 '하지 말아야 할 것'으로 표현되는 몇 가지 사항들을 확인하세요.
마이크로서비스 구축하지 않기
더 정확하게 말하자면, 마이크로서비스부터 시작하지 마세요. 마이크로서비스는 애플리케이션이 너무 커지고 다루기 어려워져 쉽게 업데이트하고 유지 관리할 수 없을 때 복잡성을 관리하는 방법입니다. 모놀리스의 고통과 복잡성이 서서히 드러나기 시작할 때만 해당 애플리케이션을 더 작은 서비스로 리팩토링할 수 있는 방법을 고려할 가치가 있습니다. 그 고통을 느끼기 전까지는 리팩토링이 필요한 모놀리스가 실제로 존재하지도 않습니다.
DevOps 또는 클라우드 서비스 없이는 마이크로서비스 수행하지 않기
마이크로서비스를 구축한다는 것은 분산 시스템을 구축한다는 것을 의미하며, 분산 시스템은 어렵고, 특히 더 어렵게 만드는 선택을 하는 경우 더욱 어렵습니다. 적절한 배포 및 모니터링 자동화 없이 마이크로서비스를 수행하거나, 현재 무분별하게 확장되는 이기종 인프라를 지원하기 위한 관리형 클라우드 서비스를 제공하려고 하면 불필요한 문제가 많이 발생합니다. 번거로움을 덜고 상태를 걱정하는 데 시간을 할애하세요.
마이크로서비스를 너무 작게 만들어 너무 많이 만들지 않기
마이크로서비스에서 "마이크로"를 너무 과도하게 사용하면 마이크로서비스 아키텍처의 전반적인 이점을 능가하는 오버헤드와 복잡성에 쉽게 직면할 수 있습니다. 더 큰 서비스를 지향하다가 마이크로서비스가 해결할 수 있는 특성, 즉 변경 사항을 배포하기가 어렵고 느려지거나 공통 데이터 모델이 지나치게 복잡해지거나 서비스의 각 부분마다 부하/규모 요구 사항이 달라지는 등의 문제가 발생하기 시작할 때만 서비스를 분리하는 것이 좋습니다.
마이크로서비스를 SOA로 전환하지 않기
마이크로서비스와 SOA는 가장 기본적인 수준에서 다른 애플리케이션에서 사용할 수 있는 재사용 가능한 개별 구성 요소를 구축하는 데 관심이 있다는 점에서 서로 혼동되는 경우가 많습니다. 마이크로서비스와 SOA의 차이점은 마이크로서비스 프로젝트는 일반적으로 애플리케이션을 리팩토링하여 관리하기 쉬운 반면, SOA는 전사적으로 IT 서비스가 작동하는 방식을 변경하는 데 중점을 둔다는 점입니다. SOA 프로젝트로 전환되는 마이크로서비스 프로젝트는 그 자체의 부담을 견디지 못할 가능성이 높습니다.
넷플릭스가 되려고 하지 않기
넷플릭스는 마이크로서비스 아키텍처의 초기 개척자 중 하나로, 전체 인터넷 트래픽의 3분의 1을 차지하는 애플리케이션을 구축하고 관리하면서 일반 애플리케이션에는 불필요한 많은 사용자 정의 코드와 서비스를 구축해야 하는 일종의 퍼펙트 스톰을 겪었습니다. 처리할 수 있는 속도로 시작하여 복잡성을 피하고 가능한 한 많은 기성 도구를 사용하는 것이 훨씬 좋습니다.
마이크로서비스 사용 방법에 대해 자세히 알아보고 싶거나 마이크로서비스 기술을 쌓아야 한다면 다음 튜토리얼 중 하나를 참조하세요.
클릭 한 번만으로 컨테이너화된 애플리케이션을 위한 높은 가용성의 완전 관리형 Kubernetes 클러스터를 배포하세요.
모든 공급업체의 온프레미스, 엣지 컴퓨팅 및 퍼블릭 클라우드 환경에서 컨테이너화된 애플리케이션을 일관되게 배포하고 관리하세요.
컨테이너 이미지, 배치 작업 또는 소스 코드를 서버리스 워크로드로 실행하기 때문에 크기 조정, 배포, 네트워킹 또는 확장 필요 없음
DevOps는 소프트웨어 개발 팀과 IT 운영 팀의 작업을 결합하고 자동화하여 고품질 소프트웨어의 제공 속도를 높입니다.
컨테이너는 애플리케이션 코드와 라이브러리 종속성을 함께 패키징하는 실행 가능한 소프트웨어 단위로, 데스크탑, 기존 IT, 클라우드 등 어디서나 실행할 수 있습니다.
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.
과거 소프트웨어 설계 패턴이 마이크로서비스 생성에 미치는 영향을 살펴보세요.
마이크로서비스 사용과 관련된 함정과 도전 과제에 대해 알아보세요.