거의 모든 최신 툴이나 언어를 마이크로서비스 아키텍처에서 사용할 수 있지만, 마이크로서비스의 정의상 필수적이고 경계를 이루는 몇 가지 핵심 툴이 존재합니다.

이는 컨테이너, Docker 및 Kubernetes입니다.

마이크로서비스의 핵심 요소 중 하나는 대개 매우 작다는 것입니다. (임의의 코드 용량에 따라 마이크로서비스 여부가 결정되는 것은 아니지만, 이름에 포함된 "마이크로"는 적절한 표현입니다.)

2013년의 최신 컨테이너 시대에 Docker가 소개되었을 때, 마이크로서비스와 가장 밀접하게 관련될 컴퓨팅 모델도 함께 소개되었습니다. 개별 컨테이너에 자체 운영체제의 오버헤드가 없으므로, 이는 기존의 가상 머신보다 작고 경량이며 보다 빠른 스핀업과 스핀다운이 가능합니다. 따라서 이는 마이크로서비스 아키텍처 내에서 발견되는 더 작은 경량의 서비스에 완벽히 적합합니다.

서비스와 컨테이너의 급증으로 인해, 대규모 컨테이너 그룹의 신속한 오케스트레이션과 관리는 중요 문제 중 하나가 되었습니다. 개방형 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 해당 작업을 매우 잘 수행하기 때문에 가장 인기 있는 오케스트레이션 솔루션 중 하나로 부상했습니다.

API 게이트웨이

마이크로서비스는, 특히 처음 상태를 설정할 때 종종 API를 통해 통신합니다. 클라이언트와 서비스가 서로 간에 직접 통신할 수 있음은 사실이지만, 특히 애플리케이션에서 서비스의 수가 시간이 지나면서 증가하기 때문에 API 게이트웨이는 종종 유용한 중간 계층입니다. API 게이트웨이는 요청을 라우팅하고 여러 서비스에서 요청을 전개하며 추가로 보안과 인증을 제공함으로써 클라이언트에 대한 리버스 프록시 역할을 수행합니다.

API 관리 플랫폼을 포함하여 API 게이트웨이의 구현에 사용할 수 있는 다수의 기술이 존재하지만, 마이크로서비스 아키텍처가 컨테이너와 Kubernetes를 사용하여 구현 중인 경우 게이트웨이는 일반적으로 Ingress를 사용하여, 혹은 보다 최근에는 Istio를 사용하여 구현됩니다.

메시징 및 이벤트 스트리밍

가장 좋은 방법은 상태 없는 서비스를 설계하는 것일 수 있지만, 그럼에도 불구하고 상태는 존재하며 서비스는 이를 인지해야 합니다. 그리고 API 호출이 종종 해당 서비스의 상태를 초기에 설정하는 효과적인 방법이긴 하지만, 이는 최신 상태를 유지함에 있어서는 그리 효과적인 방법은 아닙니다. “아직 실행 중입니까?”라고 매번 물으면서 시스템을 최신 상태로 유지하는 방식은 현실적이지 않습니다.

그 대신에, 서비스가 상태의 변화를 브로드캐스팅하고 다른 이해 당사자들이 해당 변경사항을 청취하고 적절하게 이를 조정할 수 있도록 상태 설정 API 호출을 메시징 또는 이벤트 스트리밍과 커플링하는 것이 필요합니다. 이 작업은 범용 메시지 브로커에 가장 적합한 것 같지만, Apache Kafka 등의 이벤트 스트리밍 플랫폼이 적합한 경우도 존재합니다. 그리고 마이크로서비스와 이벤트 기반 아키텍처를 결합함으로써 개발자는 대용량의 이벤트 또는 정보를 실시간으로 이용하고 처리할 수 있는 분산된, 고확장성의, 장애 허용 및 확장형 시스템을 구축할 수 있습니다.

서버리스

서버리스 아키텍처는 핵심 클라우드 및 마이크로서비스 패턴 중 일부를 논리적 결론에 적용합니다. 서버리스의 경우 실행 단위는 단순히 작은 서비스가 아닌 함수이며, 이는 종종 몇 줄의 코드에 불과할 수 있습니다. 마이크로서비스와 서버리스 함수의 구분선은 다소 애매할 수 있지만, 함수는 일반적으로 마이크로서비스보다 더 작은 것으로 이해될 수 있습니다.

서버리스 아키텍처와 Functions-as-a-Service (FaaS) 플랫폼이 마이크로서비스와 비슷한 점은, 모두 보다 작은 배치 단위를 작성하며 수요에 맞게 정확하게 스케일링하는 데 관심을 둔다는 것입니다.

마이크로서비스가 반드시 클라우드 컴퓨팅과 배타적 관계에 있는 것은 아니지만, 이들이 자주 함께 사용되는 몇 가지 중요한 이유가 있으며, 이 이유는 신규 애플리케이션의 대중적인 아키텍처 스타일이 되는 마이크로서비스와 신규 애플리케이션의 대중적인 호스팅 대상이 되는 클라우드를 넘어섭니다.

마이크로서비스 아키텍처의 주요 이점 중에는 개별적인 컴포넌트의 배치 및 스케일링과 관련된 활용도와 비용 이점이 있습니다. 이러한 장점은 온프레미스 인프라에서 어느 정도 여전히 존재할 수 있지만, 온디맨드, 종량과금제 인프라와 결합된 소규모의 독립적으로 확장 가능한 컴포넌트의 조합은 실제 비용 최적화가 이루어지는 곳입니다.

두 번째로, 그리고 아마 더 중요한 것은 마이크로서비스의 또 다른 주요 이점이 각각의 개별 컴포넌트가 특정 작업에 가장 적합한 스택을 채택할 수 있다는 점입니다. 클라우드 서비스가 관리 문제를 극적으로 최소화할 수 있으므로, 스택 확장은 자신이 직접 관리하되 지원 스택을 사용하는 경우 심각한 복잡성 및 오버헤드로 이어질 수 있습니다. 달리 말하면, 자체 마이크로서비스 인프라의 롤링이 불가능하지는 않지만, 특히 이제 막 시작하는 경우에는 이를 권장하지 않습니다.

마이크로서비스 아키텍처 내에는, 다음과 같은 몇몇 추가적인 공통 과제와 기회를 해결하는 데 도움이 되는 다수의 일반적이고 유용한 설계, 커뮤니케이션 및 통합 패턴이 있습니다.

BFF(Backend-for-frontend) 패턴. 이 패턴은 사용자 경험 및 해당 경험이 호출되는 리소스 간에 계층을 삽입합니다. 예를 들어, 데스크탑에서 사용되는 앱은 모바일 디바이스와는 다른 화면 크기, 디스플레이 및 성능 한계를 갖습니다. BFF 패턴을 사용함으로써 개발자는 인터페이스에서 작동하지만 프론트엔드 성능에 악영향을 미칠 수 있는 일반 백엔드를 지원하려고 하기보다는, 해당 인터페이스에 대한 최상의 옵션을 사용하여 사용자 인터페이스당 하나의 백엔드 유형을 작성하고 지원할 수 있습니다.

엔터티 및 집계 패턴. 엔티티는 해당 ID로 구별되는 오브젝트입니다. 예를 들어, 전자 상거래 사이트에서 제품 오브젝트는 제품 이름, 유형 및 가격으로 구분될 수 있습니다. 집계는 하나의 단위로 처리되어야 하는 관련 엔티티의 콜렉션입니다. 따라서 전자상거래 사이트의 경우 주문은 구매자가 주문한 상품(엔티티)의 콜렉션 (집계)입니다. 이러한 패턴은 데이터를 의미 있는 방식으로 분류하는 데 사용됩니다.

서비스 검색 패턴. 이러한 지원 애플리케이션과 서비스는 서로를 찾습니다. 마이크로서비스 아키텍처에서 서비스 인스턴스는 스케일링, 업그레이드, 서비스 장애, 심지어는 서비스 종료로 인해 동적으로 변경됩니다. 이 패턴들은 이러한 과도 현상에 대처하기 위한 감지 메커니즘들을 제공합니다. 로드 밸런싱은 트래픽 재조정을 위한 트리거로서 상태 점검과 서비스 실패를 사용하여 서비스 감지 패턴을 사용할 수 있습니다.

어댑터 마이크로서비스 패턴. 다른 국가로 이동할 때 사용하는 플러그 어댑터를 생각하는 방식으로 어댑터 패턴을 생각해 보세요. 어댑터 패턴의 목적은 달리 호환되지 않는 클래스 또는 오브젝트 간의 관계를 변환하는 데 도움을 주는 것입니다. 써드파티 API에 의존하는 애플리케이션은 애플리케이션과 API가 통신할 수 있도록 보장하기 위해 어댑터 패턴을 사용해야 할 수 있습니다.

Strangler 애플리케이션 패턴. 이러한 패턴은 마이크로서비스 애플리케이션으로 모노리스 애플리케이션의 리팩토링을 관리하는 데 도움이 됩니다. 이 이름은 덩굴식물(마이크로서비스)이 천천히 그리고 시간이 지나면서 나무(모놀리식 애플리케이션)를 잠식하고 목을 조이는 방법을 의미합니다.

이 패턴에 관해서는 "마이크로서비스와 개발 패턴을 사용하는 방법(4부)"에서 자세히 알아볼 수 있습니다. IBM Developer 팀에서는 다른 마이크로서비스 코드 패턴에 관해 알아보고 싶은 경우를 위해 다양한 정보도 제공합니다.

마이크로서비스를 잘 수행하기 위한 많은 패턴이 있지만, 개발 팀을 곤경에 빠뜨릴 수 있는 패턴도 꽤 많습니다. 마이크로서비스 "금지사항"이라 할 수 있는 이러한 패턴 중 몇 가지를 소개하면 다음과 같습니다.

마이크로서비스의 제1 원칙은 마이크로서비스를 빌드하지 마십시오. 더 정확히 말하면, 마이크로서비스로 시작하지 마십시오. 마이크로서비스는 일단 애플리케이션이 너무 커져서 이를 손쉽게 업데이트 및 유지보수하기가 곤란한 경우 복잡성을 관리하는 방법입니다. 모놀리스의 고통과 복잡성이 느끼지기 시작하는 경우에만 해당 애플리캐이션을 더 작은 서비스로 리팩토링하는 방법을 고려해 볼 가치가 있습니다. 해당 고통을 느낄 때까지는 리팩토링이 필요한 모놀리스가 존재하지도 않습니다.

DevOps 또는 클라우드 서비스 없이는 마이크로서비스를 하지 마십시오. 마이크로서비스를 구축하는 것은 분산 시스템을 구축하는 것을 의미하며, 분산 시스템은 쉽지 않습니다(이를 더 어렵게 만드는 선택을 하는 경우 특히 어려움). a) 적절한 배치 및 모니터링 자동화 또는 b) 현재 제멋대로의 이질적 인프라를 지원하는 관리형 클라우드 서비스 없이 마이크로서비스를 수행하려고 시도하는 것은 많은 불필요한 문제를 불러일으키는 것입니다. 괜한 수고를 하지 말고, 상태에 관해 생각하는 데 더 많은 시간을 투자하세요. 

너무 작게 만들어 너무 많은 마이크로서비스를 만들지 마십시오. 마이크로서비스의 "마이크로"가 지나치면, 마이크로서비스 아키텍처의 전체 이득을 훨씬 상회하는 오버헤드와 복잡도를 떠안게 됩니다. 더 큰 서비스를 지향하다가 마이크로서비스에 적합한 특성의 개발을 시작할 때 서비스를 분리하는 게 바람직합니다. 이를테면 변경사항 배치의 난이도가 상승하고 속도가 느려지는 경우, 공통 데이터 모델이 지나치게 복잡해지는 경우, 또는 서비스의 각기 다른 부분에서 로드/스케일 요구사항이 달라지는 경우 등입니다.

마이크로서비스를 SOA로 변환하지 마십시오. 마이크로서비스 및 서비스 지향 아키텍처(SOA)는 가장 기본적인 레벨에서 다른 애플리케이션이 사용할 수 있는 재사용 가능한 개별 컴포넌트를 빌드하는 데 모두 관심이 있다는 점에서 종종 서로 간에 혼동됩니다. 마이크로서비스와 SOA간의 차이점은 마이크로서비스 프로젝트는 일반적으로 관리가 쉽도록 애플리케이션의 리팩토링을 포함하는 반면, SOA는 IT 서비스가 전사적으로 작동하는 방식을 변화시키는 데 관련되어 있다는 점입니다. SOA 프로젝트로 변환되는 마이크로서비스 프로젝트는 그 자체의 무게 때문에 어려움에 처할 수 있습니다.

Netflix가 되지 마십시오. Netflix는 모든 인터넷 트래픽의 3분의 1을 차지하는 애플리케이션을 구축하고 관리할 때 마이크로서비스 아키텍처의 초기 개척자 중 하나였으며, 이는 평균적 애플리케이션에는 불필요한 많은 사용자 정의 코드와 서비스를 구축하도록 요구하는 일종의 퍼펙트 스톰이었습니다. 자신이 감당할 있는 페이스로 시작하고, 복잡함을 피하며, 가능한 많은 기성 툴을 사용하는 것이 좋습니다.

마이크로서비스의 사용법에 대해 자세히 알아볼 준비가 되었거나 마이크로서비스 스킬을 구축해야 하는 경우에는 다음 튜토리얼 중 하나를 사용해 보세요.

• 마이크로서비스 입문
  
  
• Quick lab: Node.js를 사용한 고확장성 웹 애플리케이션 마이크로서비스 구축
  
  
• Spring Boot 및 Cloudant를 사용하는 Java 마이크로서비스 시작하기
  
  
• 5분 내에 Spring 마이크로서비스 구축, 실행 및 배치
  
  
• 마이크로서비스, SOA, API는 서로 친구 또는 적?