[MSA-초기세팅]🏗️ MSA 환경 구성 (1)

지난 글 [기획/설계] DDD 기반 설계와 EventStorming 도입하기에서
도메인을 기능 단위로 나누고, 각 서비스의 역할과 경계를 정리했습니다.

 

이번에는 그 설계를 실제로 구현할 MSA 개발 환경을 세팅해보려 합니다.
여기서 말하는 ‘환경 세팅’은 단순히 프로젝트를 여러 개로 나누는 걸 넘어,
각 서비스가 독립적으로 실행되고 서로 통신하며, 배포 가능한 상태로 만드는 것을 의미합니다.

📚 시리즈 구성

이 시리즈는 다음 순서로 진행됩니다.

1. MSA 환경 구성 – 각 서비스의 공통 환경과 인프라 구조 설정 (현재 글)
2. 멀티모듈 구성 – 공통 모듈, Proto 공유, Gradle 설정
3. Spring Cloud Config (Private Repo) – 설정 중앙화 및 비공개 레포지토리 관리
4. Eureka (Server/Client) – 서비스 등록과 통신 구조
5. Docker & Dockerfile, docker-compose 로컬 통합 – 로컬 테스트 및 컨테이너 환경 구성

이후 시리즈에서는 gRPC 통신, 배포, CI/CD까지 확장해나갑니다.

 

⚙️ 아키텍처 개요

 

사용자 요청은 API Gateway를 거쳐
각 마이크로서비스(user, product, community, notification)로 전달됩니다.
내부 통신은 gRPC로 처리하며, 각 서비스는 Spring Cloud Config를 통해 설정을 관리하고
Eureka + AWS Cloud Map으로 서비스 디스커버리를 수행합니다.
모든 서비스는 ECS Fargate 환경에서 컨테이너로 독립 배포됩니다.

 

🧱 멀티모듈 구조와 gRPC 통신 흐름

MSA 환경의 기본 단위는 각 서비스(user,product,community,notification)입니다.

이 서비스들은 공통된 .proto 파일을 통해 gRPC 기반으로 통신합니다.

프로젝트는 다음과 같이 멀티모듈 구조로 구성되어 있습니다.

📦 msa-server
 ┣ 📂 common   → 공통 모듈 (proto, CustomException, ErrorCode, GrpcUtil)
 ┃ ┗ 📂 proto
 ┃   ┗ 📄 community.proto
 ┣ 📂 apigateway-service → 외부 요청 진입점 (REST → gRPC 변환)
 ┣ 📂 community-service   → 실제 비즈니스 로직 담당 서비스
 ┗ 📄 settings.gradle

🔄 gRPC 통신 구조 (요약)

프로젝트 gRPC 통신 전체 구조 그림

위 그림처럼

 

common/proto/community.proto 파일에는 서비스 인터페이스를 정의한 후 

gradle 빌드 시 stub 코드가 자동 생성됩니다.

 

🪨gRPC 통신 흐름(요약)

 

1. 클라이언트가 apigateway-service에게 REST API 요청을 보냅니다.

2. apigateway-service

• CommunityController에서 요청을 받습니다.
• 내부에서 CommunityGrpcClient를 통해 gRPC 호출을 수행합니다.
• @GrpcClient("community-service")로 Eureka에 등록된 서비스를 참조합니다.

3. Community Service

• CommunityGrpcService에서 실제 비스니스 로직을 처리합니다.
• 응답을 gRPC를 통해 apigateway-service에게 반환합니다.

즉, apigateway는 외부 요청을 REST로 받고, 내부는 grpc Stub을 통해 각 마이크로서비스를 호출하고 통신합니다.

모든 서비스는 proto라는 공통 파일을 공유하므로, 타입 안전성과 명세 일관성을 유지할 수 있습니다.

 

✨ 이 구조의 장점

• 타입 안정성 : proto 기반으로 컴파일 단게에서 오류를 잡을 수 있습니다.
• 성능 향상: JSON보다 빠른 바이너리 직렬화를 사용하므로 네트워크 트래픽과 처리 시간이 줄어듭니다.
• 유지보수 용이성: 인터페이스 명세(.proto)를 변경하면 공통 모듈만 재배포하면 됩니다.
• 확장성: 새로운 서비스 추가 시 proto만 확장해도 통신 구조 유지 가능합니다.

 

🧱Spring Cloud Config와 Eureka 연동 구조

 

🪨흐름 (요약)

• Config Service가 Private 저장소(msa-config-repo)에서 설정을 가져와 각 서비스에 제공합니다.
• 각 서비스는 부팅 시 원격 설정을 받아 프로파일(dev/test/prod)별 환경을 적용합니다.
• 서비스가 기동되면 Eureka Service에 등록이 되고, apigateway 및 다른 서비스는 서비스명으로 서로를 조회합니다.

Config Service (application-dev.yml)

server:
  port: 8888

eureka:
  client:
    service-url:
      defaultZone: http://eureka-server:8761/eureka
    fetch-registry: true
    register-with-eureka: true

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/Hanium2025/msa-config-repo.git
          default-label: main
          username: ${GIT_USERNAME}
          password: ${GIT_TOKEN}

management:
  endpoints:
    web:
      exposure:
        include: "*"

위 코드로 원격 레포에 접근을 합니다.

 

각 서비스 공통 설정 (application.yml)

spring:
  config:
    import: configserver:http://config-service:8888

 

 

여기까지 멀티모듈 + gRPC + Config + Eureka로 운영 가능한 기본 골격을 만들었습니다.
다음 글에서는 멀티모듈 실제 구성과 Gradle 설정, 공통 모듈 구설을 구체적으로 다루겠습니다.