티스토리

성장하는 성하 Blog

검색하기

블로그 홈

성장하는 성하 Blog

ksh-coding.tistory.com/m

BE_성하 님의 블로그입니다.

구독자: 60

방명록 방문하기

주요 글 목록

[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (10) MSA 전환 후 비교 및 회고 + 마무리 앞선 챕터까지해서 Monolithic 구조였던 개인 프로젝트를 MSA 구조로 전환해보는 전환기의 기술적인 부분은 마치고, 이번 챕터에서 MSA 전환 후 비교 및 느낀점을 통해 전환기 기록을 마무리하려고 합니다! 🙃🙃 최종적으로 마무리한 제 개인 프로젝트의 MSA Flow는 다음과 같습니다! 😁 Eureka Server에 API Gateway, Config Server를 포함한 모든 마이크로 서비스 등록 후 관리 Config Server에 각 마이크로 서비스의 프로필별 설정 파일 등록 (Github Private Repository에 등록 후 Load) API 요청 시 API Gateway가 라우팅할 마이크로 서비스 판단 후 Eureka Server에 등록된 마이크로 서비스로 요청 마이크로 서비스 간의 통.. 공감수 0 댓글수 4 2024. 3. 11.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (9) OpenFeign 테스트 하기 (feat. Spring Cloud Contract WireMock Test) 이전 챕터까지 해서 로컬 환경에서 여러 Spring Cloud 기술을 사용해서 실행 환경은 구축했습니다. 그러나 MSA 구조로 전환하면서 마이크로 서비스 간의 통신을 OpenFeign을 통해 하기 때문에 테스트들을 리팩토링해야 했습니다. 이번 챕터에서는 OpenFeign을 테스트하는 방법을 간략하게 알아보도록 하겠습니다. 1. OpenFeign 테스트 2가지 방법 OpenFeign를 테스트하는 방법으로는 크게 다음과 같은 2가지 방법이 존재할 것 같습니다. 실제 OpenFeign 통신을 거친 테스트 OpenFeign 통신만 Mocking(Stubing)하여 테스트 2가지 방법에는 장단점이 각각 존재합니다. 1-1. 실제 OpenFeign 통신을 거치는 테스트 실제로 프로덕션 환경과 동일하게 테스트 환경에.. 공감수 0 댓글수 0 2024. 3. 8.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (8) 분산 트랜잭션 환경에서 트랜잭션 처리하기(feat. 2PC, Saga 패턴, Choreographed Saga) 0. 들어가기 전 이번에는 MSA 환경에서의 트랜잭션에 대해서 생각해보겠습니다. 기존의 모놀리식 구조에서는 각 도메인 뿐만 아니라 도메인을 영속화하는 DB까지 하나의 애플리케이션에 존재했습니다. 따라서, 별도의 설정을 하지 않으면 하나의 요청을 처리할 때 하나의 트랜잭션으로 묶여서 처리가 되게 됩니다. Member DB Write -> Board DB Write가 발생하는 비즈니스 로직 실행 시 Board DB Write에 장애가 발생하면 어떻게 될까요? 일반적으로 하나의 트랜잭션으로 묶이기 때문에 Member DB의 Write도 커밋이 아닌 롤백이 될 것입니다. 그렇다면, 분산 환경인 MSA 환경에서 위와 같은 상황이 발생하면 어떻게 될까요? DB가 분리되어 있기 때문에 물리적 트랜잭션이 Member .. 공감수 1 댓글수 0 2024. 2. 12.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (7) 서비스 장애 대응 Circuit Breaker 구현(feat. Resilience4J) 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 결과로 응답받은 멤버 정보를 통.. 공감수 0 댓글수 0 2024. 2. 10.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (6) 각 서비스의 설정 파일 관리하기(feat. Spring Cloud Config) 이번 챕터에서는 각 서비스의 설정 파일들을 관리하는 부분에 대해서 살펴보겠습니다. 1. 설정 파일 관리의 필요성 현재 MSA의 각 마이크로 서비스들의 설정 파일들은 서버 내부에 존재합니다. 이렇게 설정 파일들이 각 마이크로 서비스 내부에 존재할 때는 생산성, 운영 측면에서의 문제가 발생합니다. 여러 상황을 가정해봅시다. 1. 서버 성능 테스트를 위해 설정 파일에서 어떤 설정의 수치를 조절해가며 테스트하는 상황 이 상황에서 서버 내부에 설정 파일들이 존재하면 어떻게 될까요? 수치를 하나씩 조절할 때마다 애플리케이션을 새로 빌드 및 배포해야하는 과정이 필요합니다. 단지 설정 값을 조절하는 작업 하나 때문에 애플리케이션을 다시 빌드하고, 다시 배포해야 하는 것입니다. 2. 여러 설정 파일에 공통으로 있는 어떤.. 공감수 0 댓글수 1 2024. 2. 7.
[MSA] MSA에서 JPA Entity의 연관관계를 어떻게 설정할까? 모놀리식 구조의 애플리케이션을 MSA로 전환하는 과정에서, 연관관계가 존재했던 Entity의 관계를 끊어야 했습니다. 그래서 현재 개인 프로젝트의 애플리케이션 구조에서 MSA 환경에서의 적절한 Entity 연관관계는 무엇인지 고민하게 되었습니다. 그 과정에서 생각해봤던 방안으로 2가지 방안이 떠올랐었는데, 생각했던 2가지 방안을 설명하고 개인 프로젝트에는 어떤 방안을 적용했는지 살펴보도록 하겠습니다. 0. 모놀리식 구조에서의 JPA Entity 연관관계 & 프로젝트 비즈니스 로직 기존 모놀리식 구조에서 제 개인 프로젝트의 Entity 연관관계는 다음과 같이 Member-Board가 1:N 관계였었습니다. 0-1. Board Entity @Entity @NoArgsConstructor(access = Ac.. 공감수 1 댓글수 4 2024. 2. 6.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (5) 서비스 간 통신하기 (feat. Spring Cloud OpenFeign) 이번 챕터에서는 각 마이크로 서비스 간의 통신을 어떻게 할지에 대해서 알아보고 적용해보도록 하겠습니다. 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.. 공감수 1 댓글수 1 2024. 2. 6.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (4) API Gateway 구현(feat. Spring Cloud Gateway) 앞서 Eureka로 Client-Side Discovery를 구현해서 각 서비스들의 정보를 관리하는 체계를 만들었습니다. 이번에는, 여러 마이크로 서비스들을 사용하기 위해서 외부에서 애플리케이션에 진입하는 API Gateway를 구현해보겠습니다. 1. API Gateway란? 해당 개념은 Chapter 1에서 다음과 같이 소개했었습니다. API Gateway는 쉽게 말하면 외부의 요청을 받아서 알맞는 도메인 Application에게 요청을 보내는 MSA 구성 요소입니다. 모놀리식 아키텍쳐에서는 Application이 하나였기 때문에 외부의 요청을 하나의 Application에서 처리하면 됐었습니다. 하지만 MSA에서는 Application이 도메인별로 나뉘기 때문에 외부의 요청이 어떤 도메인 관련 요청인.. 공감수 1 댓글수 0 2024. 2. 5.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (3) Service Discovery 패턴 적용하기(feat. Spring Cloud Eureka) 앞서 Chapter 1에서 MSA 도입 시 고려할 점에서 'Service Discovery 패턴'이라는 개념이 등장했었습니다. 이번 챕터에서는 Service Discovery 패턴에 대해 알아보고 해당 패턴을 구현한 Spring Cloud Netflix의 Eureka를 제 개인 프로젝트에 적용한 과정을 담아보도록 하겠습니다. 1. Service Discovery 패턴이란? Service Discovery 패턴은 MSA를 도입하면서 불편한 점을 해결하는 패턴입니다. 어떠한 패턴인지를 알아보기 위해서는 MSA 도입 시 어떠한 점이 불편한지를 알아보면 됩니다. 이 부분은 Chapter 1에서 다뤘던 부분이므로 해당 부분을 인용하겠습니다. 앞서 MSA에서는 외부에서 오는 요청은 API Gateway를 통해서 전.. 공감수 0 댓글수 2 2024. 2. 3.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (2) 멀티 모듈 구성하기 이제 본격적으로 모놀리식 아키텍쳐 프로젝트를 MSA 아키텍쳐로 전환해보고자 합니다! 이번 포스팅에서는 단일 모듈로 구성되어 있는 프로젝트를 멀티 모듈로 구성하는 과정을 담아보겠습니다. 그 전에 간단하게 멀티 모듈이 무엇인지 살펴보고 적용 과정을 담아보겠습니다! 1. 멀티 모듈이란? Oracle의 Java Document에서는 모듈을 다음과 같이 정의합니다. 패키지의 한 단계 위의 집합체로, 관련된 패키지와 리소스들을 재사용할 수 있는 그룹 간단히 말하면 모듈은 패키지의 집합을 의미합니다. 일반적으로 간단한 프로젝트는 여러 패키지를 그룹화한 단일의 모듈로 구성되는 경우가 많습니다. 제 개인 프로젝트도 하나의 단일 모듈로, 모든 소스 코드가 하나의 단일 모듈에 존재하는 경우입니다. 멀티 모듈이란, 말그대로 .. 공감수 2 댓글수 3 2024. 2. 2.
[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (1) MSA란? 저는 현재 진행중인 간단한 게시판 도메인 개인 프로젝트가 있습니다. 현재의 프로젝트 아키텍쳐는 Monolithic 아키텍쳐입니다. Monolithic 아키텍쳐에서 MSA로의 전환을 경험해보고 싶어서 개인 프로젝트에 적용하고자 합니다! 개인 프로젝트인만큼 엄~청나게 규모가 작지만 작은 상태에서 전환해보고 그 이후 MSA에서 확장도 시간이 되면 경험해보려고 합니다! 실전에 들어가기 전에, 간략하게 Monolithic 아키텍쳐와 MSA 아키텍쳐가 무엇인지 이론적으로 먼저 알아보겠습니다. 개인 프로젝트에 적용하는 만큼 제 개인 프로젝트에 빗대어서 설명을 해보겠습니다! 개인 프로젝트 ERD는 다음과 같습니다. 정말 단순한 게시판 서비스로, Member 서비스와 Board 서비스 2가지 도메인의 서비스만 존재합니다.. 공감수 2 댓글수 0 2024. 2. 1.
Controller와 Service 레이어 간 요청 & 응답 Dto 사용에 관하여 🌈 0. 들어가기 전 이번에 Controller와 Service 레이어에서 Dto를 주고받는 과정에 대해 생각해보게 되었다. 이전에는 관성적으로 Controller와 Service 간의 요청, 응답 Dto 각각 하나로 관리했었다. 이때, Layered Architecture와 유지보수성의 관점에서 두 레이어 간의 Dto 사용을 다시 생각해보게 되었다. Web 요청 & 응답 시에 Controller와 Service 간의 Dto 사용에 대해 개인적인 생각을 기록하고자 한다. 🎯 1. Web 응답 : Service에서 Response Dto 생성 후 Controller에서 반환? 일반적으로, Web 응답에 Service가 Response Dto를 Controller에 반환하는 경우가 대부분일 것이다. ✅ Se.. 공감수 11 댓글수 2 2023. 6. 19.
[아키텍쳐] 패키지 구조 : 계층형 VS 도메인형 어떤 것을 선택할까? 🎯 0. 들어가기 전 MVC 패턴 & 자바 기반의 콘솔 애플리케이션에서는 관성적으로 model(domain) & controller & view 패키지를 만들고 시작하는 경우가 대부분이었다. 웹 애플리케이션을 구현하면서, 설계 단계에서 관성을 버리고 패키지 구조에 대해서 고민하기로 했다. 그리고 설계하면서 설계 단계에서 패키지 구조에 대한 고민을 겪었다. 늘 하던 것처럼 '계층형'으로 패키지 구조를 만드는 것이 좋을까? '도메인형' 구조가 있다는데 이 구조를 적용해볼까? 계층형과 도메인형 둘 중 하나를 선택하기 위해, 두 구조의 장단점을 비교해보자. 장바구니 애플리케이션이라고 가정하고, 도메인이 'Member', 'Product', 'Cart'가 있다고 하고 비교해보자. 🎯 1. 계층형 구조 contr.. 공감수 5 댓글수 4 2023. 5. 6.
[아키텍쳐] Service, Repository가 왜 필요할까? 🎯 0. 주제 선정 이유 하나의 애플리케이션을 만들 때 자연스럽게 Controller, Service, Repository, Dao를 나누고 시작하는 경우가 많았다. Controller는 HTTP 요청 및 응답을 처리하는 가장 앞 단이기 때문에 자연스럽게 존재해야했고 Dao는 DB와 연결해서 데이터를 영속화하기 위해 필요한 것이 자연스러워보였다. 하지만, Service와 Repository는 왜 필요한지 이유를 정확히 알지 않고 관성적으로 쓰는 경우가 많았다. 그래서 Layered Architecture를 공부한 지금, 왜 Service, Repository가 필요한지 내 생각을 정리해보려고 한다. 우테코 미션에서 경험해보면서 생긴 나의 생각을 정리해보겠다! (주관적인 내용이라 틀린 부분이 있을 수 있다.. 공감수 3 댓글수 0 2023. 4. 24.
[아키텍쳐] Layered Architecture란? (feat. 자동차 경주 미션 예시) 🎯 1. Layered Architecture란? Layered Architecture : 계층화 아키텍쳐 Layered Architecture는 어느 하나의 프레임워크에 종속적인 개념이 아니라 소프트웨어 개발에서 일반적으로 흔히 사용되는 아키텍쳐의 개념이다. Layered Architecture는 각 구성 요소들이 '관심사의 분리(Separation of Concerns)'를 달성하기 위해 '책임'을 가진 계층으로 분리한 아키텍쳐이다. 관심사의 분리 : 책임(관심사)을 기준으로 다른 책임(관심사)를 분리하는 것 ※ 그렇다면, 관심사의 분리를 왜 할까? 하나의 계층에 관심사가 여러개가 존재한다면 해당 계층의 응집도가 떨어지고 결합도가 높아진다. 각 계층들을 관심사 기준으로 분리함으로써 계층의 응집도를 .. 공감수 2 댓글수 7 2023. 4. 21.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.