B컷전문 | 개발과 인생의 이야기

JHipster의 마이크로서비스 모드를 기반으로 Gateway와 Service Registry(Eureka)를 설정하고, 실제 서비스 분리를 실습합니다. 도입 배경부터 실전 구성까지 구조적 전환 과정을 단계별로 안내합니다.

왜 마이크로서비스로 전환하는가?

JHipster는 프로젝트 생성 시 모놀리식(monolith) 또는 마이크로서비스(microservice) 중 하나를 선택하게 됩니다.

처음에는 유지보수와 개발 속도를 위해 모놀리식으로 시작하지만, 다음과 같은 시점에 구조 전환이 필요합니다:

• 팀이 늘어나며 기능별 분리 요구 발생
• 특정 기능(API, 배치 등)의 독립 배포 필요
• 트래픽 분산 및 장애 격리 필요
• CI/CD 파이프라인 최적화

JHipster는 이러한 마이크로서비스 요구를 자동화된 구조와 Gateway, Registry 설정을 통해 쉽게 대응할 수 있도록 지원합니다.

---

마이크로서비스 모드의 기본 구성

JHipster 마이크로서비스 구조는 크게 3개 컴포넌트로 나뉩니다.

[Gateway App] ←→ [Service Registry (Eureka)]
                  ↑
         [Microservice App A]
                  ↑
         [Microservice App B]

역할 요약

구성 요소 설명

Gateway App	사용자 요청 수신, 라우팅, 인증 담당
Service Registry	각 서비스의 위치를 추적하는 중앙 디렉토리
Microservice App	비즈니스 로직 개별 수행 (각자 DB 포함)

---

실습 – 마이크로서비스 프로젝트 생성하기

1. Service Registry(Eureka) 생성

jhipster --blueprints microservice --skip-git

설정:

• Application type: Service registry (JHipster Registry)
• Auth: No authentication
• Build tool: Gradle or Maven

이제 Eureka 기반의 서비스 등록 센터가 생성됩니다.

---

2. Gateway App 생성

jhipster --blueprints microservice

설정:

• Application type: Gateway
• Auth: JWT or OAuth2
• Registry: Use JHipster Registry
• UI: React

이 Gateway는 모든 요청의 진입점이며, 사용자 인증/인가, 라우팅을 담당합니다.

---

3. Microservice App 생성 (예: Invoice Service)

jhipster --blueprints microservice

설정:

• Application type: Microservice application
• Name: invoice
• Registry: Use JHipster Registry
• DB: PostgreSQL or H2

이 앱은 자체 도메인을 가진 REST 서비스로 구성됩니다.

---

프로젝트 구조 예시

gateway-app/
microservice-invoice/
microservice-notification/
registry/

Gateway에서 엔티티 연동 방법

1. Gateway 프로젝트에서 jhipster import-jdl entity.jdl 실행
2. JDL 정의 시 microservice invoice with clientRootFolder invoice 구문 포함
3. React 페이지에서 마이크로서비스의 엔티티를 UI로 렌더링 가능

---

실행 순서 및 확인

각 프로젝트 루트에서 Docker Compose 실행:

docker-compose -f src/main/docker/jhipster-registry.yml up
docker-compose -f src/main/docker/app.yml up

1. http://localhost:8761 → Service Registry 확인
2. http://localhost:8080 → Gateway 앱 실행

각 서비스가 Registry에 정상 등록되고, Gateway를 통해 라우팅되는지 확인합니다.

---

통신 구조 흐름

사용자 → Gateway → 인증 → Registry 조회 → 대상 Microservice 호출 → 응답

• Gateway는 Service Registry로부터 매핑 정보를 가져와 적절한 서비스로 라우팅
• API 호출 시에도 Gateway URL(/api/invoices)만 사용

---

실전 적용 시 고려할 요소

항목 고려사항

인증 방식	Gateway에서 일괄 처리 (JWT/OAuth2), 서비스 별 인증 불필요
데이터 분리	각 Microservice는 독립 DB, DB 간 조인 불가능 (API로 해결)
API 호출	내부 호출 시 LoadBalancer → Ribbon or Spring Cloud LoadBalancer
트랜잭션	서비스 간 분산 트랜잭션은 보장되지 않음 (보상 트랜잭션 필요)
배포 전략	각 서비스 별도 배포 가능 (Docker, K8s 기반 구성 권장)

---

실전 사례

한 물류 플랫폼 기업은 다음과 같이 마이크로서비스 구조를 도입했습니다.

• Gateway: 고객 요청, 인증 처리
• Microservice:
  • 주문 서비스
  • 운송 추적 서비스
  • 결제 서비스
• Registry + Config Server로 유연한 설정 관리
• Gateway에서 모든 API 호출 수집 및 로그 수집

그 결과 기능 단위 배포 속도 증가, 장애 격리 능력 강화, 운영 자동화 수준 향상을 달성했습니다.

---

마치며 – 마이크로서비스 전환은 복잡하지만, JHipster는 단순화해준다

JHipster의 마이크로서비스 모드는 초기 진입 장벽을 낮추면서도, 확장성 있는 구조를 제공합니다.

Gateway와 Registry 기반 구조는 운영 환경에서도 검증된 아키텍처이며,
JDL과 생성기 기반으로 빠르게 실전 서비스화가 가능합니다.

---

다음 화 예고

JHipster 시리즈 8화 - 마이크로서비스에서 엔티티 분산 설계 전략

마이크로서비스 구조에서는 각 서비스의 Entity가 독립되어야 합니다. 이번 화에서는 서비스 간 관계 맺기, API 게이트웨이 연계, DTO 설계 전략을 실전 중심으로 다룹니다.