캐모마일 MSA 가이드

전체 구조

1. API Gateway

Authentication

기존 캐모마일에서는 chamomile-security 모듈과 chamomile-sercurity-jwt를 활용해서 각각 세션(stateful) / 토큰(stateless) 방식으로 인증 및 인가 절차를 함께 진행했다.

MSA 환경에서는 각 서비스에서 필요한 모듈만 골라 해당 서비스의 관심사에 집중한다.

모놀리틱 구조로는 각 마이크로 서비스에 해당 관련기능 중복이 발생하여 의존성 복잡도를 증가시킨다.

따라서 인증 과정을 토큰기반(로그인 / 토큰 검증)2개로 분리한다.

Admin에서 로그인 과정을 거친 후, API GATEWAY 에서 공통 토큰 검증 수행 & 마이크로서비스에서 개별 인가 수행 구조로 변경했다.

인가작업을 API Gateway에서 함께 진행하지 않고 각 마이크로서비스에 위임을 한 이유

캐모마일에서 인가 작업은 많은 로직과 데이터베이스 호출을 동반한다. 권한 간 우위 설정, 리소스 접근제어, 유저 및 그룹별 권한 매핑 등 상당히 무거운 비즈니스 로직을 포함하고 있기 때문에 해당 작업을 모두 APIGateway에서 진행하게 된다면 APIGateway에 많은 부하가 발생한다.

RateLimit

API Gateway에서 Rate Limit 기술은 API 남용 방지, 시스템 안정성 확보, 공정한 자원 분배, 비용 절감 등의 이유로 필요하다. Rate Limit은 일정 시간 동안 특정 사용자나 클라이언트가 요청할 수 있는 횟수를 제한하는 방식으로 동작한다. 이를 통해 다양한 문제를 해결할 수 있다.

따라서 캐모마일 ApiGateway에서는 rate limit 기능을 포함하였으며, 자세한 사용법은 샘플코드를 참고하면 된다.

1. API 남용 방지
   Rate Limit 없이 API를 제공하면 악의적이거나 비정상적인 사용자가 과도하게 많은 요청을 보낼 수 있다. 이는 서비스 오버로드를 유발하며, 시스템 성능 저하나 중단을 초래할 수 있다. Rate Limit을 적용하여 이러한 문제를 방지할 수 있다.

2. 시스템 안정성 및 성능 확보
   서버의 자원은 한정적이므로 특정 사용자나 클라이언트가 많은 리소스를 사용하면 다른 사용자에게 영향을 미칠 수 있다. Rate Limit을 통해 과도한 부하를 방지하고 시스템의 안정성을 확보할 수 있다.

3. 공정한 자원 배분
   특정 사용자가 과도하게 자원을 사용할 경우 다른 사용자는 제한된 자원을 이용해야 하는 상황이 발생할 수 있다. Rate Limit을 적용하면 클라이언트별로 요청량을 공정하게 분배할 수 있다.

4. 비용 관리
   API 요청이 많아지면 리소스 사용량이 증가하고, 이는 비용 상승으로 이어질 수 있다. Rate Limit은 클라우드 서비스의 비용을 예측하고 관리할 수 있는 수단이다.

5. 보안 및 DDoS 방어
   Rate Limit은 대규모 요청을 통한 DDoS 공격에 대비하는 데 효과적이다. 공격자가 대량의 요청을 보내더라도 시스템이 안정적으로 동작할 수 있도록 보호할 수 있다.

CircuitBreaker

API Gateway에서 Circuit Breaker가 필요한 이유는 서비스의 장애 전파 방지, 시스템 복구 시간 단축, 성능 최적화, 안정성 확보 등을 통해 분산 시스템의 신뢰성을 높이기 위함이다. 마이크로서비스 아키텍처에서는 여러 개의 독립적인 서비스가 상호작용하므로, 하나의 서비스 장애가 전체 시스템에 악영향을 미칠 수 있다. Circuit Breaker 패턴은 이러한 장애 상황을 효과적으로 관리하고 대응할 수 있도록 도와준다.

1. 서비스 장애 전파 방지
   마이크로서비스 아키텍처에서는 서비스 간의 의존성이 강하다. 하나의 서비스가 장애를 일으키면, 그 서비스에 의존하는 다른 서비스들까지 연쇄적으로 장애가 발생할 수 있다. Circuit Breaker는 특정 서비스가 불안정하거나 장애가 발생했을 때, 이를 감지하여 다른 서비스로의 요청을 차단함으로써 장애의 확산을 방지할 수 있다.

2. 시스템 복구 시간 단축
   서비스가 일시적으로 장애가 발생한 경우, 계속해서 요청을 보내면 복구에 필요한 리소스를 소비하게 된다. Circuit Breaker를 통해 서비스 장애가 감지되면 일정 시간 동안 요청을 차단하고, 일정한 간격으로 서비스가 복구되었는지 확인한 후에만 다시 요청을 재개할 수 있다. 이를 통해 장애 복구 시간을 단축하고, 시스템을 빠르게 정상 상태로 돌릴 수 있다.

3. 성능 최적화
   장애가 발생한 서비스로 계속 요청을 보내는 것은 불필요한 자원 낭비를 초래할 수 있다. Circuit Breaker는 이러한 요청을 미리 차단함으로써 리소스 사용을 줄이고 시스템 성능을 최적화할 수 있다. 이를 통해 서비스의 가용성과 응답 속도를 향상시킬 수 있다.

4. 안정성 확보
   분산 시스템에서 서비스 하나의 문제로 전체 시스템이 불안정해지는 경우가 많다. Circuit Breaker는 문제 발생 시 즉각적인 차단을 통해 시스템 전체의 안정성을 확보할 수 있다. 이를 통해 다른 서비스들이 정상적으로 동작할 수 있도록 보호할 수 있다.

5. 사용자 경험 개선
   Circuit Breaker는 장애 발생 시 빠르게 오류를 감지하고 차단함으로써, 클라이언트가 무한 대기 상태에 빠지거나 시간이 오래 걸리는 응답을 받지 않도록 한다. 이로 인해 사용자 경험이 개선되며, 문제가 발생해도 빠르게 대응할 수 있다.

LoadBalancing

API Gateway에서 로드 밸런싱(load balancing)이 필요한 이유는 서비스 성능 최적화, 시스템 가용성 확보, 확장성 제공, 장애 대응 및 복구 능력 강화 등 때문이다. MSA는 다양한 독립적인 서비스들이 분산된 환경에서 동작하므로, 각 서비스에 적절하게 트래픽을 분산시키는 것이 매우 중요하다. 이를 통해 여러 서비스 인스턴스가 효율적으로 협력하고, 시스템 전체의 성능과 안정성을 향상시킬 수 있다.

1. 성능 최적화
   MSA에서는 각각의 서비스가 여러 개의 인스턴스로 분리되어 동작하며, 각 인스턴스는 특정 요청을 처리한다. 로드 밸런싱은 이러한 요청들을 균등하게 분배하여 한 인스턴스에 과부하가 걸리지 않도록 한다. 만약 로드 밸런싱이 없다면, 특정 서비스 인스턴스에 요청이 몰려 성능 저하나 시스템 다운타임이 발생할 수 있다. 로드 밸런싱은 이처럼 시스템 자원을 고르게 사용하게 하여, 성능을 최적화하는 중요한 역할을 한다.

2. 가용성 및 안정성 확보
   MSA에서는 각 서비스 인스턴스가 분산 환경에서 운영되기 때문에, 일부 인스턴스가 비정상적으로 동작하거나 종료되더라도 시스템 전체가 계속 가용해야 한다. 로드 밸런싱은 헬스 체크(health check) 기능을 통해 비정상 인스턴스를 감지하고, 정상적으로 동작하는 인스턴스에만 트래픽을 분산시킨다. 이를 통해 시스템의 가용성을 보장하고, 장애 상황에서도 서비스가 중단되지 않도록 한다.

3. 확장성 제공
   MSA는 트래픽이 증가하거나 서비스 부하가 커질 때 수평 확장(horizontal scaling)을 통해 새로운 인스턴스를 추가하여 확장할 수 있는 아키텍처이다. 로드 밸런싱은 추가된 인스턴스에 자동으로 트래픽을 분배해 확장된 자원을 최대한 활용할 수 있게 한다. 즉, 수십에서 수백 개의 서비스 인스턴스가 동시에 운영될 때, 로드 밸런싱은 시스템이 확장된 환경에서도 일관된 성능을 제공할 수 있도록 한다.

4. 장애 대응 및 복구 능력 강화
   서비스 인스턴스 중 일부가 다운되거나 장애가 발생하면, 로드 밸런싱은 비정상적인 인스턴스에 요청을 보내지 않고, 나머지 정상 인스턴스에만 요청을 분배한다. 또한, 자동 복구 기능을 통해 인스턴스가 다시 복구되면, 이를 감지해 트래픽을 다시 분배할 수 있다. 이로 인해 무중단 서비스가 가능해지며, 장애 대응 및 복구 능력이 크게 강화된다.

5. 유연한 트래픽 관리
   로드 밸런싱은 다양한 트래픽 관리 전략을 제공한다. 예를 들어, 라운드 로빈, 최소 연결 수, 가중치 기반 등의 방식을 통해 서비스 요청을 효율적으로 분배할 수 있다. 또한, 특정 사용자 그룹이나 요청 유형에 따라 맞춤형 트래픽 분배를 설정할 수도 있어, 다양한 요구 사항에 유연하게 대응할 수 있다.

6. 서비스 디스커버리와의 통합
   MSA에서 각 서비스는 동적으로 생성되고, 종료될 수 있기 때문에 로드 밸런싱은 서비스 디스커버리와 통합되어야 한다. 서비스 인스턴스가 동적으로 변경될 때마다 이를 감지하고, 최신 상태에 맞춰 트래픽을 분배해야 한다. 이를 통해 서비스 인스턴스의 수와 위치가 계속 바뀌는 상황에서도 적절하게 트래픽을 처리할 수 있다.

7. 사용자 경험 향상
   로드 밸런싱은 트래픽을 적절히 분배하여 시스템의 응답 속도를 최적화하고, 사용자가 빠르고 안정적인 서비스를 경험할 수 있도록 한다. 특정 인스턴스에 트래픽이 집중되지 않음으로써 요청 지연을 줄이고, 전반적인 사용자 경험을 향상시킬 수 있다.

2. Admin Server

3. 서비스 디스커버리

Spring Cloud 환경에서 Service Discovery는 마이크로서비스 아키텍처에서 각 서비스들이 동적으로 서로를 찾고 통신할 수 있도록 해주는 핵심적인 역할을 한다. 마이크로서비스 환경에서는 수많은 서비스 인스턴스가 독립적으로 실행되고, 동적으로 생성되거나 종료될 수 있기 때문에, 각 서비스가 서로의 위치(IP 주소, 포트 등)를 알 수 있는 방식으로 자동화된 서비스 검색이 필요하다. 이를 통해 서비스 간의 의존성을 줄이고, 확장성과 유연성을 보장할 수 있다.

따라서 캐모마일에서는 MSA 환경에서 Eureka 서버를 따로 분리하여 운영하며, 각각의 클라이언트에서 유레카 서버를 바라보고 service 등록을 진행한다.

해당 기능 사용을 통해 얻을 수 있는 이점은 다음과 같다.

1. 동적 서비스 관리
   마이크로서비스 환경에서 각 서비스 인스턴스는 동적으로 생성되고 종료되기 때문에 고정된 IP 주소나 포트 번호를 가질 수 없다. Service Discovery는 각 서비스 인스턴스가 생성되거나 종료될 때마다 그 정보를 자동으로 등록하고, 업데이트함으로써 다른 서비스들이 최신 상태의 서비스 위치를 알 수 있도록 한다. 이를 통해 새로운 인스턴스가 생성되거나 기존 인스턴스가 삭제되는 상황에서도 서비스 간의 통신이 원활하게 이루어질 수 있다.

2. 서비스 간 통신의 간소화
   전통적인 시스템에서는 각 서비스가 서로의 IP 주소와 포트를 알고 있어야 통신할 수 있다. 하지만 마이크로서비스 환경에서는 서비스 인스턴스가 수시로 변화하기 때문에, 이러한 방식은 비효율적이다. Service Discovery는 서비스가 고정된 주소 대신 서비스 이름으로 다른 서비스를 찾을 수 있도록 지원한다. 이를 통해 각 서비스는 매번 변경되는 네트워크 위치를 신경 쓰지 않고, 동적으로 할당된 서비스 위치를 쉽게 찾아갈 수 있다.

3. 로드 밸런싱과의 통합
   Service Discovery는 로드 밸런서와 통합되어 여러 서비스 인스턴스에 트래픽을 자동으로 분배할 수 있다. 예를 들어, Spring Cloud LoadBalancer나 Ribbon과 같은 로드 밸런싱 도구는 Service Discovery에서 제공한 서비스 목록을 기반으로 요청을 분산시킬 수 있다. 이를 통해 각 서비스에 과부하가 걸리지 않도록 하고, 가용성과 성능을 최적화할 수 있다.

4. 자동 확장과 유연성
   클라우드 환경에서는 트래픽 증가나 자원 부족에 대응하기 위해 서비스 인스턴스를 자동으로 확장하거나 줄일 수 있다. 이때 Service Discovery는 새로 생성된 인스턴스를 자동으로 등록하고, 기존 인스턴스를 자동으로 제거하여 서비스 간 통신을 자동으로 관리한다. 따라서 수십 개에서 수백 개의 서비스 인스턴스가 동적으로 생성, 종료되는 상황에서도 유연하게 대응할 수 있다.

5. 서비스 복구 및 장애 대응
   서비스가 비정상적으로 종료되거나 장애가 발생했을 때, Service Discovery는 해당 인스턴스를 자동으로 제거하고 요청이 더 이상 해당 인스턴스로 전달되지 않도록 보장한다. 이를 통해 서비스 복구 시간을 줄이고, 장애 상황에서도 시스템의 가용성을 높일 수 있다. 또한, 일부 서비스가 복구되면 이를 자동으로 다시 등록하여 서비스가 정상적으로 동작할 수 있도록 한다.

6. 중앙 집중화된 서비스 등록 관리
   Service Registry는 모든 서비스 인스턴스를 중앙에서 관리하며, 이를 통해 어떤 서비스가 현재 가용한 상태인지 쉽게 파악할 수 있다. 서비스는 Service Registry에 스스로를 등록하고, 정기적으로 자신의 상태를 헬스 체크(health check)로 보고하여, 상태가 비정상일 경우 Service Registry에서 제거되거나 비활성화될 수 있다.

4. 공통 설정 관리

Spring Cloud Config를 사용하는 이유는 분산된 마이크로서비스 환경에서 중앙 집중화된 설정 관리와 동적 구성 업데이트를 통해 시스템의 유연성, 확장성, 그리고 유지보수성을 향상시키기 위함이다. 마이크로서비스 아키텍처에서는 여러 서비스가 각기 다른 환경에서 독립적으로 동작하므로, 각 서비스에 필요한 구성 설정을 일관되게 관리하는 것이 매우 중요하다. Spring Cloud Config는 이러한 구성 설정을 외부 중앙 저장소에 관리하고, 각 서비스가 필요할 때 이를 쉽게 가져올 수 있도록 지원한다.

1. 중앙 집중화된 설정 관리
   마이크로서비스 아키텍처에서는 각 서비스가 개별적인 설정 파일을 가질 수 있으며, 이 설정 파일들은 각기 다른 서버나 환경에서 관리된다. 이 경우 설정을 관리하는 작업이 복잡해지고, 변경 사항을 일일이 모든 서비스에 반영하기 어렵다. Spring Cloud Config를 사용하면 모든 서비스의 설정을 하나의 중앙 저장소(예: Git, SVN)에 저장하고 관리할 수 있다. 이를 통해 모든 서비스가 동일한 설정을 공유하거나, 각 서비스에 맞는 설정을 일관성 있게 관리할 수 있다.

2. 환경별 설정 관리
   마이크로서비스는 개발, 테스트, 프로덕션 등 다양한 환경에서 운영되며, 각 환경에 맞는 다른 설정이 필요하다. 예를 들어, 데이터베이스 연결 정보, API 키, 외부 서비스 URL 등이 환경에 따라 다를 수 있다. Spring Cloud Config는 환경에 따라 다른 설정 파일을 관리할 수 있으며, 서비스가 시작될 때 해당 환경에 맞는 설정을 자동으로 로드할 수 있다. 이를 통해 환경별로 설정 파일을 관리하는 복잡성을 줄이고, 설정 오류로 인한 문제를 방지할 수 있다.

3. 설정의 동적 업데이트
   마이크로서비스 환경에서는 설정 변경이 자주 발생할 수 있다. 특히 시스템 운영 중에 설정을 변경해야 할 경우, 각 서비스의 재시작 없이 설정을 적용할 수 있는 기능이 필요하다. Spring Cloud Config는 설정 변경을 실시간으로 반영할 수 있는 기능을 제공한다. 예를 들어, Spring Cloud Bus와 같은 메시지 브로커를 사용하면 설정 변경을 서비스에 동적으로 전달하고, 서비스는 이를 즉시 적용할 수 있다. 이를 통해 시스템 재시작 없이 설정을 빠르게 반영할 수 있어 무중단 운영이 가능하다.

4. 버전 관리와 추적 가능성
   Spring Cloud Config는 Git과 같은 버전 관리 시스템과 통합될 수 있어, 각 설정 파일의 변경 내역을 추적하고, 이전 버전으로 롤백할 수 있다. 이를 통해 누가 언제 어떤 설정을 변경했는지 추적할 수 있으며, 문제가 발생했을 때 이전 버전으로 쉽게 복구할 수 있다. 이는 특히 대규모 시스템에서 설정 변경으로 인한 오류를 방지하고, 설정 관리의 신뢰성을 높이는 데 유용하다.

5. 다양한 서비스의 설정 일관성 보장
   여러 마이크로서비스가 서로 연관된 설정을 공유하는 경우, 각 서비스에 일관성 있는 설정을 유지하는 것이 중요하다. 설정이 분산되어 있을 경우, 일부 서비스가 최신 설정을 반영하지 못하거나, 일관성이 맞지 않는 설정을 적용할 수 있다. Spring Cloud Config는 모든 서비스가 공통된 설정 파일을 참조하도록 하여 설정의 일관성을 보장한다. 따라서 여러 서비스가 공통된 설정을 사용해야 할 때, 설정의 불일치로 인한 문제를 방지할 수 있다.

6. 보안 설정 관리
   마이크로서비스에서 중요한 정보(예: 데이터베이스 비밀번호, API 키 등)도 설정 파일에 포함될 수 있다. 이와 같은 민감한 정보를 안전하게 관리하는 것이 중요한데, Spring Cloud Config는 암호화 기능을 제공하여 중요한 설정 정보를 안전하게 저장하고, 서비스에서 이를 암호화된 상태로 불러올 수 있도록 지원한다. 또한, 이를 통해 설정 파일에 민감한 정보를 직접 포함하지 않아도 되므로, 보안성이 더욱 강화된다.

7. 마이크로서비스 확장성 및 유지보수 용이성
   마이크로서비스는 필요에 따라 동적으로 확장되거나 축소될 수 있다. 이때 새로운 서비스 인스턴스가 실행될 때마다 설정을 수동으로 복사하거나 적용하는 것은 비효율적이다. Spring Cloud Config는 새로운 서비스 인스턴스가 실행될 때 자동으로 설정을 가져와 적용할 수 있도록 지원한다. 이를 통해 서비스 확장 시에도 설정을 수동으로 관리할 필요가 없어지고, 운영 및 유지보수의 복잡성이 줄어든다.

8. 다양한 형식의 설정 관리
   Spring Cloud Config는 다양한 형식의 설정 파일을 지원한다. JSON, YAML, 프로퍼티 파일 등 다양한 포맷으로 설정 파일을 작성할 수 있으며, 서비스가 이를 파싱하고 적용할 수 있다. 이를 통해 개발자는 자신에게 맞는 형식으로 설정을 관리할 수 있으며, 필요에 따라 손쉽게 변경할 수 있다.

5. 모니터링

MSA 환경에서 모니터링이 필수적인 이유는 시스템의 복잡성 증가로 인해 효율적인 운영과 문제 해결이 더욱 어려워지기 때문이다. MSA에서는 여러 개의 독립적인 서비스가 상호작용하며 하나의 시스템을 구성하므로, 각 서비스의 상태와 성능을 실시간으로 추적하고 관리하는 것이 매우 중요하다. 모니터링을 통해 서비스의 가용성, 성능, 장애 대응 등을 최적화할 수 있으며, 시스템 전반의 운영 안정성을 보장할 수 있다.

1. 복잡성 증가로 인한 문제 감지 및 해결
   MSA 환경에서는 단일 시스템이 아닌 수십 개, 때로는 수백 개의 독립적인 마이크로서비스가 존재하므로, 전체 시스템의 상태를 파악하는 것이 매우 복잡해진다. 서비스 간의 상호작용이 많아지면, 한 서비스의 장애가 다른 서비스에 연쇄적인 문제를 일으킬 수 있다. 모니터링을 통해 각 서비스의 상태를 실시간으로 추적하고, 문제 발생 시 원인을 신속하게 파악하여 복구 시간을 최소화할 수 있다.

2. 가용성 및 안정성 보장
   MSA는 고가용성을 제공하기 위해 설계되었지만, 각 서비스의 상태를 추적하지 않으면 가용성을 보장하기 어렵다. 모니터링을 통해 서비스의 응답 시간, 에러 발생률, 리소스 사용량 등을 주기적으로 확인함으로써 서비스 중단을 예방할 수 있다. 모니터링 시스템은 서비스 헬스 체크 기능을 통해 비정상적인 서비스를 감지하고, 필요 시 자동으로 복구하거나 재시작하는 작업을 수행할 수 있다. 이를 통해 서비스 중단을 최소화하고, 사용자가 안정적인 서비스를 이용할 수 있도록 보장할 수 있다.

3. 서비스 성능 최적화
   각 서비스의 성능은 MSA 전체 시스템의 성능에 큰 영향을 미친다. 모니터링을 통해 서비스의 응답 시간, 처리량 등을 추적하고, 병목 현상이 발생하는 지점을 신속하게 파악할 수 있다. 또한, 모니터링 데이터를 기반으로 서비스 간 로드 밸런싱을 최적화하거나, 필요한 서비스 인스턴스를 확장하여 성능 저하를 방지할 수 있다. 성능이 저하되는 서비스에 대해 즉각적인 조치를 취함으로써 전체 시스템의 성능을 최적화할 수 있다.

4. 장애 대응 및 문제 해결 시간 단축
   MSA 환경에서는 장애가 발생했을 때 그 원인을 신속하게 파악하고 복구하는 것이 중요하다. 서비스가 수십 개로 분산되어 있기 때문에 장애가 발생한 서비스가 어떤 것인지, 그리고 그 원인이 어디에 있는지 찾는 것이 매우 어렵다. 모니터링 시스템을 통해 서비스 장애 발생 시 실시간 알림을 받을 수 있으며, 문제 발생 지점을 신속하게 파악할 수 있다. 또한, 로그나 메트릭을 통해 장애의 원인을 분석하고, 문제 해결 시간을 대폭 단축할 수 있다.

5. 서비스 간 상호 의존성 관리
   MSA에서는 각 서비스가 독립적으로 운영되지만, 많은 경우 서비스 간에 의존 관계가 존재한다. 하나의 서비스 장애가 다른 서비스에 영향을 미칠 수 있으므로, 서비스 간의 상호작용을 모니터링하여 의존성 문제를 사전에 파악하고 조치할 수 있다. 예를 들어, 한 서비스가 느려지면 그 서비스에 의존하는 다른 서비스들도 지연될 수 있는데, 모니터링 시스템을 통해 이러한 의존성 문제를 감지하고 해결 방안을 마련할 수 있다.

6. 자동 확장 및 자원 최적화
   MSA는 자동 확장을 통해 시스템 부하에 대응할 수 있지만, 모니터링이 없다면 언제 확장해야 하는지 정확히 알 수 없다. 모니터링 시스템은 서비스의 CPU, 메모리, 네트워크 사용량 등을 실시간으로 추적하여, 자원이 부족해지면 자동으로 인스턴스를 추가하거나 자원을 확장할 수 있도록 돕는다. 반대로 트래픽이 줄어드는 경우 불필요한 인스턴스를 제거해 자원을 효율적으로 사용할 수 있다.

7. 운영 비용 절감
   모니터링을 통해 서비스의 성능을 최적화하고, 장애 발생 시 빠르게 대응함으로써 운영 비용을 줄일 수 있다. 특히 클라우드 환경에서는 사용한 자원만큼 비용을 지불하는 경우가 많기 때문에, 모니터링을 통해 자원의 과도한 사용을 방지하고 최적화하는 것이 중요하다. 또한, 장애로 인해 발생할 수 있는 서비스 중단이나 성능 저하로 인한 손실을 줄일 수 있다.

8. 규정 준수 및 감사 추적
   특정 산업에서는 시스템의 가용성과 성능을 모니터링하고 보고하는 것이 법적 요구사항일 수 있다. 모니터링 시스템은 각 서비스의 상태와 성능 기록을 보관하고, 이를 통해 시스템의 운영 상황을 투명하게 관리할 수 있다. 또한, 장애나 성능 문제 발생 시 이를 추적할 수 있는 데이터를 제공하여, 규정 준수 여부를 입증할 수 있다.

6. 외부 API 호출

MSA 환경에서는 다양한 방식의 외부 API 호출 방식이 존재한다. 그중에서도 캐모마일이 선택한 방식은 FeignClient 이다. 외부 API 호출 시 FeignClient를 활용해야 하는 이유는 간결한 코드, 가독성, 부가기능 통합 등 여러 이점 때문이다. FeignClient는 외부 서비스와의 RESTful API 통신을 추상화하여 개발자가 복잡한 HTTP 클라이언트 코드를 작성하지 않고도 간편하게 사용할 수 있도록 도와준다. 특히 마이크로서비스 아키텍처(MSA)에서 많은 서비스가 서로 통신할 때 FeignClient는 효율적인 방법을 제공한다.

1. 간결하고 직관적인 인터페이스 제공
   FeignClient는 인터페이스 기반으로 외부 API를 호출할 수 있게 해준다. 개발자는 복잡한 HTTP 요청을 직접 작성할 필요 없이 인터페이스에 메서드만 선언하면 된다. 각 메서드는 해당 API 엔드포인트를 호출하며, 필요한 HTTP 메서드(GET, POST 등)와 매핑된다.

   @FeignClient(name = "exampleClient", url = "https://api.example.com") public interface ExampleClient { @GetMapping("/data") ExampleResponse getData(); }

   이러한 구조는 코드의 간결성과 가독성을 높여주며, 개발자는 비즈니스 로직에만 집중할 수 있다. HTTP 요청 관련 코드가 크게 줄어들기 때문에 유지보수도 더 용이하다.

2. Spring Cloud와의 강력한 통합
   FeignClient는 Spring Cloud의 다른 구성 요소들과 자연스럽게 통합된다. 특히 Load Balancer, Circuit Breaker, Service Discovery(Eureka 등)와의 연동이 뛰어나다. 예를 들어, FeignClient를 사용하면 서비스가 Eureka 같은 서비스 등록 및 발견 시스템에서 자동으로 엔드포인트를 조회할 수 있다. Load Balancing: FeignClient는 Spring Cloud LoadBalancer와 연동되어 여러 서비스 인스턴스에 트래픽을 자동으로 분배할 수 있다. Circuit Breaker: FeignClient는 Resilience4j나 Hystrix 같은 서킷 브레이커 라이브러리와 통합되어, API 호출 시 장애가 발생할 경우 시스템을 보호하는 메커니즘을 제공한다.

3. 부가 기능의 자동 지원
   Feign은 자체적으로 HTTP 요청의 리트라이, 타임아웃 설정, 헤더 관리, 인코딩 및 디코딩 기능을 지원한다. 특히, API 응답을 받았을 때 JSON 형식 데이터를 자동으로 Java 객체로 디코딩할 수 있는 기능은 매우 편리하다.

   @FeignClient(name = "exampleClient", url = "https://api.example.com") public interface ExampleClient { @PostMapping("/data") ExampleResponse postData(@RequestBody ExampleRequest request); }

   복잡한 JSON 파싱 코드나 HTTP 응답 처리 코드를 수동으로 작성할 필요가 없으며, Feign이 이를 자동으로 처리한다.

4. 유연한 확장성과 설정 지원
   FeignClient는 개발자가 필요로 하는 다양한 설정과 요구 사항을 쉽게 반영할 수 있다. 각 API 호출에 대해 커스텀 설정을 적용하거나 Interceptor를 추가할 수 있다. 예를 들어, 인증 토큰을 헤더에 추가하거나, API 호출 로그를 남기는 기능 등을 쉽게 구현할 수 있다.

   @Configuration public class FeignConfig { @Bean public RequestInterceptor requestInterceptor() { return requestTemplate -> requestTemplate.header("Authorization", "Bearer your_token"); } }

   이를 통해 API 호출 시 필요한 추가 설정을 쉽게 적용할 수 있으며, 코드의 재사용성도 높일 수 있다.

5. 서비스 디스커버리(eureka)와의 통합
   FeignClient는 서비스 디스커버리(Eureka)와 통합되어 서비스 간 통신에서 클라이언트 측 로드 밸런싱을 지원한다. 이는 마이크로서비스 아키텍처에서 각 서비스가 다수의 인스턴스로 확장될 때, 클라이언트가 해당 서비스의 인스턴스들 사이에서 적절하게 요청을 분배하는 기능을 제공한다.

6. 테스트 및 모킹 용이
   FeignClient는 인터페이스 기반으로 설계되었기 때문에, 유닛 테스트나 통합 테스트에서 모킹(mocking)을 쉽게 할 수 있다. 이는 API 호출을 테스트할 때 외부 시스템의 의존성을 제거하고, 테스트의 신뢰성을 높여준다.

   @MockBean private ExampleClient exampleClient; @Test public void testGetData() { ExampleResponse mockResponse = new ExampleResponse(); Mockito.when(exampleClient.getData()).thenReturn(mockResponse); // 테스트 코드 작성 }

7. 복잡한 API 호출 관리 FeignClient는 복잡한 API 호출에도 적합하다. 쿼리 파라미터나 경로 변수를 쉽게 처리할 수 있으며, 다양한 요청 유형을 지원한다. 또한 여러 API 호출을 하나의 인터페이스에서 관리할 수 있어, API 호출 구조를 단순화하고 관리 용이성을 높인다.

8. 라이브러리 대체 FeignClient는 RestTemplate이나 WebClient와 같은 HTTP 클라이언트 라이브러리를 대체할 수 있는 경량화된 솔루션이다. RestTemplate을 사용하면 매번 HTTP 요청을 수동으로 작성해야 하지만, FeignClient는 이를 자동화하여 개발 생산성을 크게 높여준다.

FeignClient는 이와 같은 요청을 간단한 인터페이스 정의로 대체할 수 있다.