Monolith vs Microservices

MSA(MicroService Architecture)는 말 그대로 작은 단위의 경량 application의 모음 군으로 개발하는 접근 방식입니다. 이런 서비스는 비즈니스 function 중심(ex. 결제, 배송 등)으로 구축되며 각각의 application은 독립적으로 구축됩니다. MSA를 설명하기 위해서는 Monolithic application과 비교하는것이 좋습니다.

Monolithic application은 하나의 단일 단위로 개발된 application을 뜻하며, 이 application을 개발하기 위해 개발자는 각각의 기능을 class, namespace, package 등으로 분할하여 개발하게 됩니다. 모놀리식으로 개발하게 되면 하나의 코드 베이스에 기반을 두어서 단순하기 때문에 개발 속도가 빠른 장점이 있지만, 기능이 늘어날 때 마다 각 기능별 모듈을 유지보수하기 쉬운 방향으로 구성하기 어렵게 되는 단점이 있습니다.

Monolithic architecture

Monolithic architecture 모놀리식 아키텍처는 소프트웨어 프로그램의 전통적인 모델로, 자체 포함 방식이며 다른 애플리케이션과 독립적인 통합된 유닛으로 만들어집니다. 모놀리식 아키텍처는 하나의 코드 베이스를 갖춘 대규모 단일 컴퓨팅 네트워크이기에 애플리케이션의 기능을 변경하려면 코드 베이스에 액세스하고 서비스 측 인터페이스의 업데이트된 버전을 구축 및 배포하여 전체 스택을 업데이트 해야 합니다. 이로 인해 업데이트에 제한이 많고 시간이 오래 걸리게 됩니다.

Monolithic architecture의 장점

• 손쉬운 배포 - 실행 파일 또는 디렉토리가 하나여서 배포가 더 쉽습니다.
• 개발 - 하나의 코드 베이스로 애플리케이션을 구축하여 개발이 더 쉽습니다.
• 성능 - 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API만으로 마이크로서비스에서 여러 API가 수행하는 것과 동일한 기능을 수행할 수 있습니다.
• 테스트 간소화 - 모놀리식 애플리케이션은 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행할 수 있습니다.
• 간편한 디버깅 - 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기가 더 쉽습니다.

Monolithic architecture의 단점

• 느린 개발 속도 - 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려집니다.
• 확장성 - 개별 컴포넌트를 확장할 수 없습니다.
• 안정성 - 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 줄 수 있습니다.
• 기술 채택의 장벽 - 프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로 변경 시 비용과 시간이 많이 소요되는 경우가 많습니다.
• 유연성 부족 - 모놀리스의 경우 모놀리스에서 이미 사용한 기술로 제한됩니다.
• 배포 - 모놀리식 애플리케이션을 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야 합니다.

모놀리식 아키텍처는 빠른 개발과, 손쉬운 배포등 이점이 있어 처음 프로젝트에 진행하기에는 빠르게 결과물 만들 수 있는 이점이 있습니다. 하지만 추후 서비스가 커지면서 요구되는 기능들이 많아지면 유지보수는 어려워지며, class들이 늘어남에 따라 개발환경에서 해당 프로젝트를 import할 때는 많은 시간이 소요 될 수 있습니다.

MSA

마이크로서비스 아키텍처는 독립적으로 배포 가능한 일련의 서비스를 이용하는 아키텍처 방법입니다. 이러한 서비스에는 특정한 목표를 가진 자체 비즈니스 로직 및 데이터베이스가 존재하여 업데이트, 테스트, 배포 및 확장은 각 서비스 내에서 이루어집니다. 마이크로서비스는 복잡성을 줄여주지는 않지만, 작업이 서로 독립적으로 작동하고 전체에 기여하는 더 작은 프로세스로 분리하여 복잡성을 눈으로 볼 수 있고 관리하기 쉽도록 만듭니다.

MSA의 장점

• Agility - 배포가 잦은 소규모 팀에서 애자일 작업 방식을 유도합니다.
• 유연한 확장 - 마이크로서비스가 부하 용량에 도달하면 해당 서비스의 새 인스턴스를 포함하는 클러스터에 신속하게 배포하여 부담을 완화할 수 있습니다. 이제 여러 인스턴스에 고객이 분산되어 있는 다중 테넌트 및 상태 비저장(stateless)이 되었으며 훨씬 더 큰 크기의 인스턴스를 지원할 수 있습니다.
• 지속적 배포 - 이제 더 자주 릴리스하고 릴리스 주기가 빨라졌습니다. 이전에는 업데이트를 일주일에 한 번 수행 했다면 나중에는 하루에 두세 번 정도까지도 수행할 수 있게 되었습니다.
• 높은 유지 관리성 및 테스트 편의성 - 팀에서 새로운 기능을 실험해 보고 문제가 발생하면 롤백할 수 있습니다. 따라서 코드를 보다 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있습니다. 또한 개별 서비스의 결함과 버그를 쉽게 격리하고 해결할 수 있습니다.
• 독립적 배포 가능 - 마이크로서비스는 개별적인 유닛이므로 개별 기능을 빠르고 쉽게 독립적으로 배포할 수 있습니다.
• 기술 유연성 - 마이크로서비스는 아키텍처를 사용하면 팀에서 원하는 도구를 자유롭게 선택할 수 있습니다.
• 높은 안정성 - 전체 애플리케이션이 중단될 위험 없이 특정 서비스에 대한 변경 사항을 배포할 수 있습니다.
• 팀의 만족도 향상 - 마이크로서비스를 사용하는 팀은 더 자율적이며 Pull Request가 승인될 때까지 몇 주씩 기다리지 않고도 직접 구축 및 배포할 수 있기 때문에 훨씬 더 만족도가 높습니다.

MSA의 단점

• 무분별한 개발 확산 - 마이크로서비스의 경우 여러 팀이 더 많은 장소에 더 많은 서비스를 만들기 때문에 모놀리스 아키텍처에 비해 더 복잡해집니다. 무분별한 개발 확산이 적절하게 관리되지 않으면 개발 속도가 느려지고 운영 성능이 저하되는 결과가 나타납니다.
• 기하급수적인 인프라 비용 - 각각의 새 마이크로서비스는 테스트 도구, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등에 대한 자체적인 비용이 발생할 수 있습니다.
• 조직 오버헤드 추가 - 팀에서는 업데이트 및 인터페이스를 조정하기 위해 또 다른 커뮤니케이션과 공동 작업이 이루어져야 합니다.
• 디버깅 문제 - 각 마이크로서비스는 자체적인 로그 집합을 가지고 있어 디버깅이 더 복잡합니다. 또한 여러 시스템에서 하나의 비즈니스 프로세스가 실행될 수 있으므로 디버깅이 더욱 복잡해집니다.
• 표준화 부족 - 공통 플랫폼이 없어 여러 언어, 로깅 표준 및 모니터링이 사용될 수 있습니다.
• 명확한 소유권 부족 - 더 많은 서비스가 도입됨에 따라 서비스를 실행하는 팀의 수도 늘어납니다. 시간이 지나면서 팀에서 어떤 서비스를 활용할 수 있는지, 그리고 지원을 받으려면 누구에게 문의해야 하는지 파악하기가 어려워집니다.

Microservice Architecture의 복잡성 MSA 전환하게 되면 도메인별로 개발 및 배포를 할 수 있기에 팀별로 독립적으로 배포 할 수 있고 언어에 종속되지 않아 다양한 기술 및 언어를 선택하여 개발 및 배포할 수 있기에 팀의 만족도를 향상 시킬 수 있습니다. 하지만 MSA 전환하기 이전에 Monolithic 하게 개발했을때는 애플리케이션 계층에 복잡성을 두었다면 MSA 전환하게 되면 네트워크 계층에 복잡성이 요구 되기에 개발 하는데에 있어 많은 혼란을 야기시킬 수 있습니다. 예로 각 서비스를 관리할 수 있는 인프라 환경 및 비용이라든지 각 서비스를 호출하여 요청을 처리할 때 오류가 발생하면 트랜잭션 처리는 어떻게 할 지 등 머리가 아픈문제가 한 두가지가 아닐 수 있습니다.

다음은 MSA로 전환한 서비스 업체의 회고 영상입니다.

• 11번가 Spring Cloud 기반 MSA로의 전환 - 지난 1년간의 이야기
• [2019] PAYCO 쇼핑 마이크로서비스 아키텍처(MSA) 전환기
• [우아콘2020] 배달의민족 마이크로서비스 여행기

Spring Cloud Netflix

이렇게 MSA로 전환한 사례가 있지만 가장 대표적인 사례로는 Netflix를 빼놓지 않을 수 없습니다. Netflix는 기존 Legacy 시스템을 MSA로 전환하였는데 그 계기로는 2007년 심각한 데이터베이스 손상으로 3일간 서비스 장애를 겪게되어 이 이후로 신뢰성 높고 수평 확장이 가능한 클라우드 시스템으로 이전할 필요성을 느끼게 되어 Netflix는 장장 7년간에 거쳐 클라우드 환경으로 이전하였으며 이전하면서 Netflix가 경험한 노하우와 문제 해결 방법을 공유하기 위해 MSA 전환 기술을 오픈소스로 공개했습니다. 이렇게 탄생한 Netflix OSS(Open Source Software)는 MSA를 도입하려는 많은 사람들에게 좋은 선택지가 되고 있습니다.

모든 Netflix 라이브러리 및 시스템은 2012년 오픈 소스로 제공되었으며 현재까지도 커뮤니티에서 여전히 사용되고 있습니다.
(현재는 몇개의 Netflix 오픈소스는 Maintenance Mode로 전환되었으며, 이에 따라 Spring은 다른 모듈을 권장하고 있습니다. 참고: Spring Cloud Greenwich.RC1 available now)

Netflix는 2018년 부터 Spring Cloud Netflix를 통해 커뮤니티의 기여를 활용하여 핵심 Java 프레임 워크로 Spring Boot로 전환하고 있음을 발표하였습니다.

Spring Clouud Architecture

Spring cloud architecture Spring Cloud architecture를 보면 API Gateway, Config Server, Distributed tracing을 볼 수 있으며 이외에도 Circuit breaker, Distributed transaction 등 MSA 인프라 구성을 위한 다양한 서비스들이 있습니다. 우리는 이러한 서비스들의 역할이 무엇이며 MSA 전환하면서 직면할 문제들을 어떻게 해결할 수 있을지 대략적으로 알아보려 합니다.

MSA 전환시 문제점

다수의 필요한 서비스를 어떻게 찾아야 하는가? - Service Discovery

MSA와 같은 분산 환경은 서비스 간의 원격 호출로 구성이 됩니다. 원격 서비스 호출은 IP 주소와 포트를 이용하는 방식으로 구성됩니다. 하지만 클라우드 환경이 되면서 서비스가 오토 스케일링등에 의해서 동적으로 생성되거나 컨테이너 기반의 배포로 인해서, 서비스의 IP가 동적으로 변경되는 일이 잦아지는데 이때 우리는 서비스 클라이언트가 서비스를 호출할때 서비스 위치 (즉 IP 주소와 포트)를 알아낼 수 있는 기능이 필요합니다.

해당 서비스를 Service discovery라 하며 모든 Service에 대한 주소를 Service registry(서비스등록 서버)에 등록합니다. 예로 Service A가 Service B를 호출할때 Service A가 Service registry에 Service B 주소를 요청하고, registry에 등록된 Service B의 주소를 받아 서비스를 호출하게 됩니다.

이러한 Service discovery 기능을 구현하는 방법으로는 크게 Client-side discovery pattern, Server-side discovery pattern 방식이 있습니다. 앞서 설명드린 Service registry에 등록하여 서비스 위치를 요청하는 방식을 Client-side discovery pattern이라고 합니다.

Client-side discovery pattern Server-side discovery pattern의 경우 호출 되는 서비스 앞에 일종의 proxy 서버 (로드밸런서)를 넣는 방식인데, 서비스 클라이언트는 이 로드밸런서를 호출하면 로드밸런서가 Service registry로 부터 등록된 서비스의 위치를 리턴하고, 이를 기반으로 라우팅을 하는 방식입니다.

Server-side discovery pattern 우리는 어떠한 Service discovery를 구현해야 할까요?? 대표적으로 Netflix Eureka, HashiCorp Consul, Zookeper가 있으며 Kubernates 환경을 통해 구성을 한다면 Spring Cloud kubernates를 사용할 수 있을것 같습니다. 설명하는 해당 모듈들은 Spring cloud에서 DiscoveryClient 을 통해 구현을 제공하고 있습니다.

Eureka 서비스 구현 영상

• 스프링 부트 강의 - 4-1강 Service Discovery

혹시 Eureka, Consul, Zookeper 각각에 대한 비교가 궁금하다면 해당 링크를 통해 정보를 얻을 수 있습니다.
Consul vs Eureka vs Zookeeper | What are the differences?

사용하기 위한 다수 서비스의 인스턴스를 어떻게 결정해야 하는가? - Client-side Load balancer

모놀리식 시스템에서는 부하 분산을 위해 L4 스위치 같은 하드웨어 장비를 앞단에 두고 트래픽을 여러 서버로 분산하였습니다. 이렇게 중앙 집중화된 방식은 로드 밸런서에 장애가 발생하면 전체 서비스에 문제가 생기는 위험을 동반합니다. 또한 동적으로 서버가 추가, 삭제되는 환경에서 하드웨어 장비로 대응하는 것도 한계가 있습니다. 그렇기에 넷플릭스는 소프트웨어로 구현한 Client-side Load balancer인 Ribbon을 추가했습니다.

이때 서버 목록은 정적 리스트를 사용하면 되지만 Eureka와 연동할 경우에는 동적 리스트도 가능합니다. 하지만 Ribbon은 2018년 12월 이후 EOS(End of Service) 되었기 때문에 Spring Cloud LoadBalancer를 사용하는 것을 권장합니다.

Ribbon은 Blocking 방식의 HttpClient RestTemplate만 지원하지만 Spring Cloud LoadBalancer 이하 SCL은 Non-blocking 방식을 지원하는 Spring webClient도 지원합니다.

Ribbon의 Load Balancing 정책은 RoundRobin, AvailabilityFilteringRule, WeightedResponseTimeRule 세가지 정책을 지원하며, SCL은 RoundRobin과 Random 정책만 지원합니다.

개별적인 서비스가 응답하지 않을 때 어떤 일이 발생하는가? - Circuit Breaker

MSA도 특정 서비스에 과부하가 걸리거나 어떤 문제로 인해 정상적으로 작동하지 않으면 전체 서비스에 장애를 전파하는 경우가 있습니다. 특정 서비스에 문제가 생기더라도 전체적으로 장애가 확산하지 않도록 차단해주는 기능을 Circuit Breaker라고 합니다.

서비스간에 요청 흐름이 모두 정상이면 위 이미지와 같습니다. 하지만 이 중 하나의 서비스에 장애가 발생한다고 가정하면 다음과 같습니다.

하나의 서비스가 지연 또는 장애가 나면, 모든 서버에서 모든 자원이 몇 초 내에 포화 상태가 될 수 있습니다. 네트워크를 통해 또는 클라이언트 라이브러리에 도달하여 네트워크 요청이 발생할 수 있는 응용 프로그램의 모든 지점은 잠재적인 오류의 원인이 되며, 장애보다 더 나쁜 이러한 응용 프로그램은 서비스 간 대기 시간을 늘려 대기열, 스레드 및 기타 시스템 리소스등 시스템 전체에서 더 많은 계단식 오류를 발생시킵니다.

이러한 계단식 오류를 방지하기 위한 Circuit Breaker 패턴을 구현한 라이브러리가 넷플릭스가 개발한 Hystrix 입니다.

Hystrix 서버는 각 서비스의 오류 상태나 복구 상태 그리고 현재 오류 내용이 무엇인지를 파악합니다. API 호출 통계를 기반으로 상대 서비스에서 이상을 감지하면 즉시 통신을 중단합니다. 그러면 문제가 있던 서비스를 격리(Isolation)하게 되는데 이후에는 문제가 해결될 때까지 별도의 스레드에서 밀린 작업을 수행하거나 호출 수를 제한합니다. 상태가 정상으로 돌아오면 통신을 연결하여 다시 호출을 받도록 합니다.

서킷 브레이커 패턴에서 중요한 기능은 Fallback 입니다. 폴백은 정해진 시간 내에 호출이 실패하면 대신 동작하는 예외처리로 보면 되는데, 개발자가 폴백 메소드를 구현함으로써 시스템 장애로부터 유연하게 복구를 실행할 수 있습니다. 또한 서킷 브레이커의 정보나 각 서버의 상태를 확인할 수 있는 모니터링 서비스까지 제공하여 로그를 중앙 집중형으로 관리하고 검색할 수 있습니다.

Hystrix 역시 EOS 되었으며 Spring에서 권장하는 라이브러리는 Resilience4j 입니다. Resilience4j는 Hystrix에서 제공하는 기능과 크게 다르지 않으며 기본적으로 이름도 동일합니다.

보안, 속도제한과 같은 서비스 접근을 어떻게 제어하는가? - OAuth

MSA 전환하게 되면 각 서비스별로 인증, 인가 처리를 진행해야 하는데 대표적인 방법으로는 3가지 방법이 있습니다.

액세스 토큰 인증

엑세스 토큰은 사용자를 특정하기 위해 인증 서비스가 랜덤하게 생성한 고유 식별자로, 엑세스 토큰 자체로는 어떠한 정보도 담고 있지 않습니다. 그러나 인증 서비스는 토큰 발급 시 생성된 엑세스 토큰과 사용자 인증 정보를 맵핑하여 저장함으로써 엑세스 토큰을 키로하여 사용자의 인증 정보를 확인 할 수 있습니다. 서비스는 요청된 모든 명령 처리를 위해 인증 서비스에 질의 해야 하며 그에 따라 인증 서비스에 강한 의종성을 갖게 됩니다. 이러한 상황에서 인증 서비스에 장애가 발생한다면 전체 서비스로 장애가 전파되는 불상사가 발생하게 됩니다.

JWT 인증

액세스 토큰과 다르게 JWT는 토큰 스스로가 사용자 인증 정보를 가지고 있습니다. 인증 서비스는 JWT를 발급하며, 각 서비스가 JWT 유효성 검사를 통해 인증, 인가를 처리함으로써 인증 서비스에 대한 의존성을 줄일 수 있습니다.

API Gateway 인증 절차

API Gateway는 사용자에게 하나의 엔드 포인트를 제공하기 위해 사용되는 패턴입니다. API Gateway는 서비스 최전방에 위치하며, 모든 사용자 요청은 API Gateway를 통해서만 각 서비스에 접근 가능하게 됩니다. 이러한 API Gateway 특성을 활용하여 인증 절차를 추상화하여 공통 인증 절차를 구현한다면, 각 서비스들은 인증 방식으로부터 완전히 독립되어 인증 서비스와 의존성이 사라지게 됩니다. Spring Cloud에서는 Spring Cloud Security를 통해 클라우드 환경에서의 인증, 인가 서비스를 구현할 수 있습니다.

다수의 서비스는 서로 어떻게 커뮤니케이션 하는가? - HTTP / Messaging

MSA에서는 하나의 기능을 수행하기 위해서 각각의 마이크로서비스 인스턴스들이 유기적으로 상호작용을 해서 적절한 데이터를 사용자에게 내려주는 방식을 취하게 됩니다. 보통의 MSA에서 각각의 서비스는 HTTP를 통해 통신하게 됩니다. Netflix는 서비스간 통신을 위해 Feign을 추가하였습니다. Feign은 선언적 방식으로 REST 기반 호출을 추상화해서 제공합니다.

Interface와 Annotation만으로 간단하게 HTTP API 클라이언트를 구현할 수 있으며 세부적인 내용 없이 사용할 수 있어 코드 복잡도는 낮습니다. 하지만 Feign은 동기 방식이기에 서비스간 호출할때 하나의 서비스에서 문제가 발생할 시 호출된 서비스들의 이벤트와 관련된 데이터가 모두 유실되어 버릴 가능성이 존재합니다. 그렇기 때문에 MSA의 장점을 살리려면 서비스 간 결합이 느슨해질 필요가 있습니다.

서비스 간의 통신 요청 후 응답을 기다리지 않고 다른 작업을 할 수 있는 것이 Kafka, RabbitMQ 같은 메시징 큐 서비스가 있습니다. 메시징 큐 서비스를 통해 다른 서비스를 호출해도 응답을 기다리지 않기에 다른 작업을 진행할 수 있어 호출한 서비스가 문제가 발생하여도 요청한 서비스는 영향을 받지 않고 하던 작업을 진행할 수 있습니다. Spring 에서는 Kafka, RabbitMQ등 메세지브로커를 사용할 수 있는 Spring Cloud Stream이 있습니다.

서비스간 ACID는 어떻게 달성하는가? - Distributed Transaction

마이크로 서비스 아키텍처에서 가장 큰 어려움은 트랜잭션 관리입니다. 기존 모놀로식 아키텍처에서는 DBMS 기능에 의존한 트랜잭션 처리를 통해 데이터의 일관성을 보장하였습니다. 마이크로 서비스 아키텍처의 경우 각 서비스 별로 데이터 베이스를 가지고 있기 때문에 DBMS 기능에 의존한 트랜잭션 처리가 불가능합니다. 그렇기에 필연적으로 분산 트랜잭션 처리가 필연적으로 필요합니다.

분산 트랜잭션에서는 다양한 패턴 방식이 존재합니다. 대표적으로 SAGA, CQRS, CDC, Outbox 등 다양한 패턴이 존재하기에 각각의 패턴이 무엇인지 학습하고 상황에 맞는 패턴을 적용시킬 필요가 있습니다.

모든 요청들은 어디부터 요청받고 처리될까?- API Gateway

MSA 환경에서는 API Gateway를 필연적으로 사용하고 있습니다. API Gateway는 왜 사용되어질까요?

유입되는 모든 요청/응답이 통하기 때문에 인증/보안을 적용하기 좋습니다.

URI에 따라 서비스 엔드포인트를 다르게 가져가는 동적 라우팅이 가능해집니다. 예를 들면 도메인 변경없이 레거시 시스템을 신규 시스템으로 점진적으로 교체해 나가는 작업을 쉽게 진행할 수 있습니다.

모든 트래픽이 통하기 때문에 모니터링 시스템 구성이 단순해집니다. 동적 라우팅이 가능하므로 신규 스팩을 서비스 일부에만 적용하거나 트래픽을 점진적으로 늘려나가는 테스트를 수행하기에 수월해집니다.

Netflix는 API Gateway 패턴을 구현한 Zuul을 추가하였습니다. Zuul은 현재 EOS 상태이며 Spring Cloud Gateway가 대안으로 권장되는 상황입니다.

Spring Cloud Gateway는 API 라우팅 및 보안, 모니터링/메트릭등의 기능을 간단하고 효과적인 방법으로 제공합니다.

Zuul의 경우 서블릿 프레임워크 기반으로 만들어졌기 때문에 동기, 블로킹 방식으로 서비스를 처리하는데 Spring Cloud Gateway의 경우 비동기, 논블로킹 방식을 지원합니다. (Netflix는 비동기, 논블로킹 지원을 위해 Zuul2 추가되었습니다.)

서비스간 환경설정은 어떻게 해야할까? - External Config

각각에 서비스는 서비스 구성을 위해 환경 설정을 위해 코드를 작성할 일이 존재합니다. 이때 같은 환경설정이 필요한 서비스들은 환경설정 구성이 변경될때마다 각각의 서비스에서 수정되어져야 하는 불편함이 있습니다. Configuration Server는 이러한 중복으로 존재하는 환경 설정들을 관리하여 일원화 시킬 수 있으며 환경 구성이 변경될 때 마다 연관된 서비스들을 배포할 필요도 없습니다.

Spring에서는 Spring Cloud Config이 존재합니다.

서비스간 트랜잭션 추적은 어떻게 해야할까? - Distributed Tracing

마이크로서비스에서 분산 트랜잭션을 사용하면서 트랜잭션에 대한 추적을 할 필요가 있습니다. 기존 모놀로식 아키텍처에서는 하나의 애플리케이션 안에서 모든 동작이 이루어졌기 때문에 트랜잭션의 추적이 아주 쉬웠지만 마이크로서비스 아키텍처는 각 서비스가 독립되어있어 모든 서비스의 수 많은 트랜잭션을 로깅한다는 것은 매우 어려운 일입니다.

이때 등장한 개념이 분산추적(Distributed Tracing) 입니다. 분산추적이란 하나의 애플리케이션을 구성하는 모든 MSA 사이에서 발생하는 트랜잭션을 추적하고 분석하는 것입니다.

우리는 분산추적을 통해 애플리케이션을 모니터링할 수 있어 MSA 개발환경에서의 최적화된 기술이라고 할 수 있습니다.

Spring에서는 Spring Cloud Sleuth가 있으며 Zipkin과 함께 사용할 수 있도록 제공되어지고 있습니다.

결론

References

• 마틴파울러의 마이크로서비스의 정의(Micro Service Architecture by Martin folwer)
• 마이크로서비스와 모놀리식 아키텍처 비교 - Atlassian
• The Twelve-Factor App (한국어)
• MSA and Netflix OSS
• Microservices Journey from Netflix OSS to Istio Service Mesh - DZone Microservices
• 스프링 부트 강의 - 3-3강 Spring Cloud의 이해
• 넷플릭스로 알아보는 MSA
• MSA에서 Service discovery 패턴
• Service Discovery in a Microservices Architecture - NGINX
• API Gateway vs Load Balancer - L7 Defense
• [SC14] Spring Cloud LoadBalancer 란 ?
• 마이크로서비스 구조(MSA)의 인증 및 인가(Authorization & Authentication)
• Design Patterns for Distributed Transactions
• Feign 적용
• MSA 서비스간 통신 방법
• 분산 트랜잭션(Distributed transaction)
• Spring Cloud MSA(1) – Configuration server 구성
• Spring Cloud Gateway(SCG)를 활용한 API Gateway 구축