앞선 챕터까지해서 Monolithic 구조였던 개인 프로젝트를 MSA 구조로 전환해보는 전환기의 기술적인 부분은 마치고, 이번 챕터에서 MSA 전환 후 비교 및 느낀점을 통해 전환기 기록을 마무리하려고 합니다! 🙃🙃 최종적으로 마무리한 제 개인 프로젝트의 MSA Flow는 다음과 같습니다! 😁 Eureka Server에 API Gateway, Config Server를 포함한 모든 마이크로 서비스 등록 후 관리 Config Server에 각 마이크로 서비스의 프로필별 설정 파일 등록 (Github Private Repository에 등록 후 Load) API 요청 시 API Gateway가 라우팅할 마이크로 서비스 판단 후 Eureka Server에 등록된 마이크로 서비스로 요청 마이크로 서비스 간의 통..
이전 챕터까지 해서 로컬 환경에서 여러 Spring Cloud 기술을 사용해서 실행 환경은 구축했습니다. 그러나 MSA 구조로 전환하면서 마이크로 서비스 간의 통신을 OpenFeign을 통해 하기 때문에 테스트들을 리팩토링해야 했습니다. 이번 챕터에서는 OpenFeign을 테스트하는 방법을 간략하게 알아보도록 하겠습니다. 1. OpenFeign 테스트 2가지 방법 OpenFeign를 테스트하는 방법으로는 크게 다음과 같은 2가지 방법이 존재할 것 같습니다. 실제 OpenFeign 통신을 거친 테스트 OpenFeign 통신만 Mocking(Stubing)하여 테스트 2가지 방법에는 장단점이 각각 존재합니다. 1-1. 실제 OpenFeign 통신을 거치는 테스트 실제로 프로덕션 환경과 동일하게 테스트 환경에..
0. 들어가기 전 이번에는 MSA 환경에서의 트랜잭션에 대해서 생각해보겠습니다. 기존의 모놀리식 구조에서는 각 도메인 뿐만 아니라 도메인을 영속화하는 DB까지 하나의 애플리케이션에 존재했습니다. 따라서, 별도의 설정을 하지 않으면 하나의 요청을 처리할 때 하나의 트랜잭션으로 묶여서 처리가 되게 됩니다. Member DB Write -> Board DB Write가 발생하는 비즈니스 로직 실행 시 Board DB Write에 장애가 발생하면 어떻게 될까요? 일반적으로 하나의 트랜잭션으로 묶이기 때문에 Member DB의 Write도 커밋이 아닌 롤백이 될 것입니다. 그렇다면, 분산 환경인 MSA 환경에서 위와 같은 상황이 발생하면 어떻게 될까요? DB가 분리되어 있기 때문에 물리적 트랜잭션이 Member ..
1. 서비스 장애 대응(Circuit Breaker)의 필요성 현재 구성한 MSA의 구조는 다음과 같습니다. Member-Service, Board-Service가 존재하고 Board 로직에서 Member-Service를 호출하는 구조입니다. 게시글 작성 요청 예시 이러한 상황에서, '게시글 작성' 요청 Flow를 살펴봅시다. 외부에서 게시글 작성 API 요청(Request#1) API Gateway에서 Board-Service로 요청 라우팅 Board-Service에서 멤버 정보를 가져오기 위해 Member-Service로 OpenFeign 요청 Member-Service의 Member DB에서 멤버 정보를 Read해서 Board-Service에게 응답 OpenFeign 결과로 응답받은 멤버 정보를 통..
이번 챕터에서는 각 서비스의 설정 파일들을 관리하는 부분에 대해서 살펴보겠습니다. 1. 설정 파일 관리의 필요성 현재 MSA의 각 마이크로 서비스들의 설정 파일들은 서버 내부에 존재합니다. 이렇게 설정 파일들이 각 마이크로 서비스 내부에 존재할 때는 생산성, 운영 측면에서의 문제가 발생합니다. 여러 상황을 가정해봅시다. 1. 서버 성능 테스트를 위해 설정 파일에서 어떤 설정의 수치를 조절해가며 테스트하는 상황 이 상황에서 서버 내부에 설정 파일들이 존재하면 어떻게 될까요? 수치를 하나씩 조절할 때마다 애플리케이션을 새로 빌드 및 배포해야하는 과정이 필요합니다. 단지 설정 값을 조절하는 작업 하나 때문에 애플리케이션을 다시 빌드하고, 다시 배포해야 하는 것입니다. 2. 여러 설정 파일에 공통으로 있는 어떤..
모놀리식 구조의 애플리케이션을 MSA로 전환하는 과정에서, 연관관계가 존재했던 Entity의 관계를 끊어야 했습니다. 그래서 현재 개인 프로젝트의 애플리케이션 구조에서 MSA 환경에서의 적절한 Entity 연관관계는 무엇인지 고민하게 되었습니다. 그 과정에서 생각해봤던 방안으로 2가지 방안이 떠올랐었는데, 생각했던 2가지 방안을 설명하고 개인 프로젝트에는 어떤 방안을 적용했는지 살펴보도록 하겠습니다. 0. 모놀리식 구조에서의 JPA Entity 연관관계 & 프로젝트 비즈니스 로직 기존 모놀리식 구조에서 제 개인 프로젝트의 Entity 연관관계는 다음과 같이 Member-Board가 1:N 관계였었습니다. 0-1. Board Entity @Entity @NoArgsConstructor(access = Ac..
이번 챕터에서는 각 마이크로 서비스 간의 통신을 어떻게 할지에 대해서 알아보고 적용해보도록 하겠습니다. 0. 기존 Board-Service 리팩토링(Member 의존성 제거) 제 프로젝트에서는 다음과 같이 Member-Board가 1:N 관계였었습니다. 이전 멀티 모듈 구성 시에는 편의를 위해 이러한 의존성을 제거하지 않고 board-service 모듈이 member-service 모듈을 import 했었습니다. MSA 구조에서는 Board-Service Application은 Member-Service 모듈을 참조하는 소스코드가 없어야 합니다. 이제 완벽한 의존성 제거를 위해 member-service 모듈의 import도 제거하고 공통 모듈만 import하도록 리팩토링했습니다. member-servi..
앞서 Eureka로 Client-Side Discovery를 구현해서 각 서비스들의 정보를 관리하는 체계를 만들었습니다. 이번에는, 여러 마이크로 서비스들을 사용하기 위해서 외부에서 애플리케이션에 진입하는 API Gateway를 구현해보겠습니다. 1. API Gateway란? 해당 개념은 Chapter 1에서 다음과 같이 소개했었습니다. API Gateway는 쉽게 말하면 외부의 요청을 받아서 알맞는 도메인 Application에게 요청을 보내는 MSA 구성 요소입니다. 모놀리식 아키텍쳐에서는 Application이 하나였기 때문에 외부의 요청을 하나의 Application에서 처리하면 됐었습니다. 하지만 MSA에서는 Application이 도메인별로 나뉘기 때문에 외부의 요청이 어떤 도메인 관련 요청인..
앞서 Chapter 1에서 MSA 도입 시 고려할 점에서 'Service Discovery 패턴'이라는 개념이 등장했었습니다. 이번 챕터에서는 Service Discovery 패턴에 대해 알아보고 해당 패턴을 구현한 Spring Cloud Netflix의 Eureka를 제 개인 프로젝트에 적용한 과정을 담아보도록 하겠습니다. 1. Service Discovery 패턴이란? Service Discovery 패턴은 MSA를 도입하면서 불편한 점을 해결하는 패턴입니다. 어떠한 패턴인지를 알아보기 위해서는 MSA 도입 시 어떠한 점이 불편한지를 알아보면 됩니다. 이 부분은 Chapter 1에서 다뤘던 부분이므로 해당 부분을 인용하겠습니다. 앞서 MSA에서는 외부에서 오는 요청은 API Gateway를 통해서 전..
이제 본격적으로 모놀리식 아키텍쳐 프로젝트를 MSA 아키텍쳐로 전환해보고자 합니다! 이번 포스팅에서는 단일 모듈로 구성되어 있는 프로젝트를 멀티 모듈로 구성하는 과정을 담아보겠습니다. 그 전에 간단하게 멀티 모듈이 무엇인지 살펴보고 적용 과정을 담아보겠습니다! 1. 멀티 모듈이란? Oracle의 Java Document에서는 모듈을 다음과 같이 정의합니다. 패키지의 한 단계 위의 집합체로, 관련된 패키지와 리소스들을 재사용할 수 있는 그룹 간단히 말하면 모듈은 패키지의 집합을 의미합니다. 일반적으로 간단한 프로젝트는 여러 패키지를 그룹화한 단일의 모듈로 구성되는 경우가 많습니다. 제 개인 프로젝트도 하나의 단일 모듈로, 모든 소스 코드가 하나의 단일 모듈에 존재하는 경우입니다. 멀티 모듈이란, 말그대로 ..
