[Resilience4J] MSA 환경에서의 장애 방어 전략

1. CircuitBreaker가 필요한 이유개발을 하다 보면 외부 API를 호출해야 하는 경우가 있다. 특히나 전체적인 시스템 구성이 MSA(Microservice Architecture)로 되어 있다면 다른 서비스를 호출하는 경우가 매우 빈번하다.  문제는 서버들에 장애가 발생할 수 있다는 점인데, 호출한 다른 서비스에 장애가 발생했다면 장애가 전파되어, 해당 서비스까지 문제가 발생할 수 있다. 또한 장애가 발생한 서버에 계속 요청을 보내는 것은 장애 복구를 힘들게 만든다.   예를 들어, 사용자의 대시보드에서 한 번의 요청으로 사용자의 여러 정보를 조회해 한 화면에 보여주어야 하는 상황을 생각해보자. 이 대시보드는 아래와 같이 각기 다른 서비스에서 데이터를 가져와야 한다.사용자 정보 서비스: 사용자..

• format_list_bulleted MSA 🧩
• · 2024. 11. 12.
• textsms

MSA 환경에서 인증, 인가는 어디서 처리하는 게 옳을까?

1. 개요MSA를 도입하면서, 혹은 고려하면서 대부분의 사람들이 인증 인가에 대한 고민을 하게 될거라 생각한다.  나도 Spring Cloud를 사용한 MSA 아키텍처 구조로 개발을 진행하면서 인증, 인가에 대한 고민을 하게 됐다. 구글링 해보면 크게 2가지 방법으로 나뉘었다.  1. Gateway에서 모든 인증, 인가 처리 2. 각 Micro Service 에서 인증, 인가 처리    이 두 가지 방법 중 어떤걸 선택해야 할 지에 대해 많은 고민을 했다. 결론부터 얘기하면 현재는 Gateway에서 인증 처리, 각 Micro Service에서 인가 처리를 하는 것으로 결정했다. 하지만, 서비스를 운영해본게 아니고 학습하는 단계이기 때문에 내 생각이 틀릴 수도 있다. 그리고 각자 개발하는 서비스의 도메인,..

• format_list_bulleted MSA 🧩
• · 2024. 11. 11.
• textsms

[멀티 모듈] Spring Boot Multi Module로 MSA 환경 구성하기

1. 개요예전에 봤던 Spring Cloud 강의를 복습하며 이벤트 스트리밍, SAGA 패턴, CQRS 등 MSA에 사용되는 여러 기술들에 익히기 위해 간단한 프로젝트를 만들고 학습하고 있었다.  처음 multi module을 공부해야겠다 했던 건 kafka 관련 설정과 이벤트 통신을 위한 dto들의 코드 중복 때문이었다. MSA 환경을 구성하면서도 코드가 중복된다는게 많이 느껴졌고 공통 모듈로 빼고 싶다는 생각이 들었다. 또한 JWT 토큰을 사용하여 인증, 인가 처리를 하고 있었기 때문에 위 로직도 어디로 빼야할 지 고민이 되었다.   정말 예전에 multi module에 대해서 강의를 본 적이 있는데, 그 땐 이런게 있구나 하고 넘어갔지만 이번엔 제대로 알아보고 multi module로 msa 환경을..

• format_list_bulleted MSA 🧩
• · 2024. 11. 11.
• textsms

헥사고날 아키텍처(Hexagonal Architecture) : 지속 가능한 소프트웨어 설계

포트와 어댑터 아키텍처 라고도 불리는 헥사고날 아키텍처(Hexagonal Architecture)는 인터페이스나 기반 요소(infrastructure)의 변경에 영향을 받지 않는 핵심 코드를 만들고 이를 견고하게 관리할 수 있도록 해준다.  헥사고날 아키텍처를 설명하기전에 계층형 아키텍처와 클린 아키텍처, 그리고 도메인 주도 설계(DDD)에 대해서도 언급이 필요하다.  헥사고날 아키텍처는 전통 방식인 계층형 아키텍처의 단점을 보완하기 위해 설계되었다.      기존 계층형 아키텍처의 문제점은 무엇일까?1. 데이터베이스, 영속성에 대한 의존성 도메인 계층이 데이터베이스에 의존하게 되어 데이터베이스에 변화가 일어나면 도메인 계층에도 변화가 생긴다. 서비스 계층에서도 영속성 모델을 도메인 모델처럼 사용하게 된..

• format_list_bulleted 아키텍처, 디자인패턴 ⚙️
• · 2024. 10. 19.
• textsms

객체 지향 설계의 5가지 원칙 SOLID 제대로 짚고 넘어가기 - SRP, OCP, LSP, ISP, DIP

1. SRP (Single Responsibility Principal)SRP는 단일 책임 원칙으로 객체는 단 하나의 책임만 가져야 한다는 원칙을 말한다.  여기서 책임은 하나의 기능 담당이다. 즉, 하나의 클래스는 하나의 기능을 담당하여 하나의 책임을 수행해야한다.  여러 개의 기능이 하나에 담겨있다면 더 효율적이고 좋다고 생각할 수도 있다. 하지만 이건 사용자의 입장이다. 사용자가 아닌 코드를 설계하는 개발자 입장에선 마이너스 적인 요소로 작용하게 된다.   하나의 클래스에 여러 기능(책임)을 넣느냐, 따로따로 클래스를 분리하여 기능(책임)을 분산시키느냐 설계는 프로그램의 유지보수와 밀접한 관련이 있다.  하나의 클래스에 여러 책임이 포함되어 있다면 한 책임의 변경에서 다른 책임의 변경을 야기할 수 ..

• format_list_bulleted 아키텍처, 디자인패턴 ⚙️
• · 2024. 10. 9.
• textsms

Spring Security RBAC 설정, @PreAuthorize 로 쌈@뽕하게 관리하기

1. 개요진행 중인 프로젝트의 api 개수가 어느새 90개가 다되간다. Spring Security를 사용하여 RBAC(Role-Based Access Control)을 구현 하고있고, 이 설정은 Security Config에서 관리하고 있다. 새로운 엔드포인트를 개발할 때마다 기존의 설정과 잘 매칭되는지 확인해야 했고, 그렇지 않다면 추가적인 설정이 필요했다. 이러한 과정 때문에 지금까지 개발된 API들에 RBAC이 제대로 적용되었는지 확인하기 어렵고, 놓친 부분을 점검하는 것도 번거로운 작업이 필요했다.  URL에 prefix로 ROLE을 추가하여 일괄적으로 관리하는 방법을 고려해 보았지만, 보안상 좋은 방법이 아니라는 피드백을 여러 차례 받았다.    다른 방법은 없을까 알아보다, 어노테이션으로써 ..

• format_list_bulleted Spring Boot, JAVA 🌱
• · 2024. 8. 27.
• textsms