01 MSA

1. Note

• 개념 관련 내용들!
• 주요 개념을
  • 상대적인거고 상황에 따라서 다르게 판단해야함.
  • 그렇기 때문에 각기 아키텍처에 대한 이해가 필요한 부분.
  • 개발을 할때, 운영할때, 전반적으로 염두하고 판단해야하는 부분들

2. MSA

1. 모놀리틱 아키텍쳐

1. 구성도

• 모든 기능(비즈니스 로직, 데이터베이스 액세스, UI 등)이 하나의 거대한 코드베이스에 통합되어 있는 전통적인 방식
• 구성도

2. 특징

• 주요 특징
  • 단일 코드베이스 / 모든 서비스 로직이 하나의 프로젝트 안에 묶여 있음
  • 단일 배포 단위 / 수정 사항이 생기면 전체 시스템을 다시 빌드하고 통째로 배포해야 함
  • 강한 결합도(Tight Coupling) / 구성 요소들이 서로 밀접하게 연결되어 있어, 한 곳의 변경이 다른 곳에 영향을 주기 쉬움
• 구조적 특징
  • 회원, 주문, 결제, 상품 기능이 하나의 프로젝트 내부에 존재
  • 모든 기능이 하나의 프로세스에서 실행되며, 하나의 애플리케이션으로 운영
  • 대부분 단일 데이터베이스를 사용하여 데이터를 통합 관리
• 통신 방식 특징
  • 서비스 간 통신이 네트워크 API 호출이 아닌 내부 메서드 호출 방식으로 이루어짐
  • 네트워크 오버헤드가 없어 처리 속도가 빠른 편
  • 구현 구조가 단순하여 개발 복잡도가 비교적 낮음
• 배포 특징
  • 특정 기능만 수정하더라도 전체 애플리케이션을 다시 배포해야 함
  • 배포 단위가 하나이기 때문에 운영 구조가 단순함
  • 작은 변경 사항도 전체 서비스 영향 범위 안에서 관리됨
• 운영 특징
  • 초기 개발 속도가 빠르고 환경 구성이 단순함
  • 서비스 규모가 커질수록 코드 의존성과 복잡도가 증가할 수 있음
  • 일부 기능 장애가 전체 서비스에 영향을 줄 가능성이 존재함

3. 장단점

• 장점

  장점	설명
  단순한 개발 및 배포	초기 구조가 단순하여 프로젝트 설정과 개발이 쉬움. 하나의 애플리케이션만 빌드 및 배포하면 되므로 배포 파이프라인 구성도 비교적 단순
  빠른 초기 개발	서비스 초기 단계에서 기능 구현 속도가 빠름. 서비스 분리나 복잡한 통신 구조 설계가 필요하지 않아 빠른 개발 및 출시(Time-to-Market)에 유리
  쉬운 디버깅 및 테스트	하나의 프로젝트에서 전체 시스템이 동작하여 로컬 실행과 테스트가 쉬움. 문제 발생 시 로그 추적 및 디버깅이 비교적 직관적
  트랜잭션 처리 용이	하나의 DB를 사용하는 경우가 많아 데이터 정합성 관리가 쉬움. @Transactional 기반의 트랜잭션 처리에 유리
  성능상 유리	서비스 간 통신이 내부 메서드 호출 방식으로 이루어짐. 네트워크 통신 비용이 없어 응답 속도가 빠른 편

• 단점

  단점	설명
  확장성의 한계	특정 기능(예: 주문 기능)에만 트래픽이 몰려도 전체 시스템을 함께 확장해야 함. 필요한 기능만 독립적으로 확장하기 어려워 자원 낭비 가능
  배포 부담 증가	작은 코드 수정에도 전체 애플리케이션 재배포 필요. 시스템 규모가 커질수록 빌드 및 배포 시간이 증가
  기술 부채 및 종속성	초기 기술 스택에 강하게 의존하게 됨. 일부 기능만 새로운 언어 또는 프레임워크 적용이 어려움
  유지보수 복잡도 증가	서비스 규모가 커질수록 코드 의존성이 증가함. 구조가 복잡해지며 스파게티 코드 발생 가능성 존재
  장애 영향 범위 큼	일부 기능 장애가 전체 서비스에 영향을 줄 가능성 존재. 하나의 프로세스로 동작하여 장애 전파 위험이 있음

2. MSA

1. 구성도

• 거대한 애플리케이션을 비즈니스 기능 단위로 쪼개어, 독립적으로 운영되는 작은 서비스(Microservice)들의 집합
• 구성도

2. 특징

• 주요 특징
  • 독립된 서비스 운영 / 각 서비스는 자체 데이터베이스를 가지며 완전히 독립적으로 구동
  • 폴리글랏(Polyglot) 구조 / 서비스 특성에 맞게 서로 다른 언어, 프레임워크, DB를 선택할 수 있음
  • API 기반 통신 / 서비스 간의 호출은 가벼운 네트워크 프로토콜(HTTP/REST, gRPC, 메시지 큐 등)을 통해 이루어짐
• 구조적 특징
  • 회원, 주문, 결제, 상품과 같은 기능을 각각 독립된 서비스로 분리하여 구성함. 각 서비스는 개별 프로젝트 및 개별 프로세스로 동작
  • 서비스별 독립적인 서버 환경과 배포 단위를 가질 수 있음. 특정 서비스 수정 시 해당 서비스만 변경 가능
  • 기능 단위로 서비스를 분리하여 개발 및 유지보수 효율 향상 가능
• 데이터베이스 특징
  • 서비스별 독립적인 데이터베이스(DB)를 사용하는 경우가 많음. 회원, 주문, 결제 데이터가 각각 분리되어 관리 가능
  • 특정 서비스의 데이터 변경이 다른 서비스에 직접적인 영향을 주지 않음. 서비스 간 결합도를 낮추는 데 유리
  • 데이터 정합성 처리를 위해 이벤트 기반 통신 또는 분산 트랜잭션 패턴 활용 가능
• 통신 방식 특징
  • 서비스 간 통신은 HTTP REST API, gRPC, Message Queue 등을 사용함. 내부 메서드 호출이 아닌 네트워크 기반 통신 구조
  • 서비스 간 의존성을 낮추고 독립적인 서비스 운영 가능. 특정 서비스 수정 시 다른 서비스 영향 최소화 가능
  • 네트워크 통신 비용 및 장애 대응 고려 필요
• 배포 특징
  • 특정 서비스만 독립적으로 수정 및 배포 가능. 전체 애플리케이션 재배포가 필요하지 않음
  • 서비스 단위 배포가 가능하여 운영 유연성 증가. 배포 시간 단축 및 영향 범위 최소화 가능
  • CI/CD 자동화 환경 구성에 유리
• 운영 특징
  • 특정 서비스에 트래픽이 몰릴 경우 해당 서비스만 확장 가능. 불필요한 서버 증설을 줄여 자원 효율 향상 가능
  • 일부 서비스 장애 발생 시 전체 서비스 영향 최소화 가능. 장애 범위를 특정 서비스로 제한 가능
  • 서비스 수 증가에 따라 모니터링, 배포, 장애 관리 복잡도 증가 가능

3. 장단점

• 장점

  장점	설명
  독립적 배포 및 확장	특정 서비스만 독립적으로 배포 가능. 주문 서비스에만 트래픽이 증가할 경우 해당 서비스만 서버 증설(Scale-Out) 가능하여 자원 효율 향상
  장애 격리(Fault Isolation)	특정 서비스 장애가 전체 시스템으로 확산될 가능성이 낮음. 예를 들어 추천 서비스 장애가 발생해도 로그인, 주문, 결제 서비스는 정상 동작 가능
  조직의 유연성	서비스 단위로 팀을 구성하여 독립적인 개발 가능. 팀별 책임 범위가 명확해지고 대규모 협업 환경에 유리
  기술 스택 다양성	서비스별로 서로 다른 기술 스택 적용 가능. 예를 들어 주문 서비스는 Java/Spring, 추천 서비스는 Python 기반 AI 모델 적용 가능
  빠른 배포 및 유지보수	특정 서비스만 수정 후 배포 가능. 전체 시스템 영향 최소화 및 배포 시간 단축 가능

• 단점

  단점	설명
  복잡한 시스템 관리	서비스 수 증가에 따라 모니터링, 로깅, 장애 추적 난이도 증가. 중앙 로그 관리 및 Distributed Tracing 환경 구축 필요
  데이터 일관성 확보 어려움	서비스별 DB 분리로 인해 전통적인 ACID 트랜잭션 사용이 어려움. 데이터 정합성 유지를 위해 Saga Pattern, Event 기반 처리 등 추가 설계 필요
  네트워크 오버헤드	내부 메서드 호출이 API 또는 메시지 기반 통신으로 변경됨. 네트워크 지연(Latency) 및 장애 발생 가능성 존재
  운영 비용 증가	서비스별 서버, 배포 환경, 모니터링 도구 구성이 필요함. 인프라 및 운영 비용 증가 가능
  개발 복잡도 증가	서비스 간 통신, 인증, 장애 복구, 데이터 동기화 등 고려 요소 증가. 초기 설계 난이도가 높고 개발 복잡성이 커질 수 있음

3. 비교

비교 항목	모놀리틱 아키텍처	MSA
구조	모든 기능이 하나의 애플리케이션 내부에 통합됨	기능별로 서비스를 분리하여 독립적으로 구성
배포 방식	전체 애플리케이션 단위 배포 작은 수정도 전체 재배포 필요	서비스 단위 독립 배포 가능 변경된 서비스만 배포 가능
확장성	특정 기능 부하 발생 시 전체 시스템 확장 필요	필요한 서비스만 독립적 확장(Scale-Out) 가능
장애 영향 범위	일부 기능 장애가 전체 서비스에 영향 가능	특정 서비스 장애가 전체 시스템으로 확산될 가능성 낮음
통신 방식	내부 메서드 호출 방식 사용 속도가 빠르고 단순	REST API, gRPC, MQ 기반 통신 네트워크 비용 발생
데이터베이스	하나의 DB를 공유하는 경우가 많음	서비스별 독립 DB 구성 가능
트랜잭션 처리	단일 DB 기반으로 ACID 처리 용이	분산 환경으로 데이터 정합성 관리 필요
개발 속도	초기 개발 속도가 빠름 구조가 단순	초기 설계 복잡도 높음 서비스 분리 설계 필요
유지보수	규모가 커질수록 의존성 증가	서비스별 관리 가능하여 유지보수 유리
기술 스택	하나의 기술 스택에 종속적	서비스별 다른 기술 스택 사용 가능
운영 복잡도	상대적으로 단순	모니터링, 로깅, 장애 대응 복잡도 증가
적합한 환경	소규모 서비스, 빠른 MVP 개발	대규모 서비스, 높은 트래픽 환경

3. 아키텍처 관점

1. 확장성 (Scalability) 관점

• 모놀리틱: 수직적 확장(Scale-up) 중심
  • 작동 방식
    • 트래픽 증가 시 서버의 CPU, RAM 성능을 높이는 수직적 확장(Vertical Scaling) 방식 사용함.
    • 필요 시 애플리케이션 전체 인스턴스를 복제하여 확장함.
  • 한계점
    • 특정 기능에만 트래픽이 집중되어도 애플리케이션 전체를 함께 증설해야 하는 구조임.
      • 쇼핑몰에서 이벤트 알림 기능에만 부하가 발생해도
      • 결제, 회원관리 기능까지 포함된 전체 애플리케이션을 동일하게 확장해야 함.
      • 이로 인해 자원 낭비 및 인프라 비용 증가 발생함.
• MSA: 수평적 확장(Scale-out) 중심
  • 작동 방식
    • 서비스가 기능 단위로 분리되어 있음
    • 필요한 서비스만 독립적으로 서버 수를 늘리는 수평적 확장(Horizontal Scaling) 방식 사용
  • 장점
    • 특정 서비스에만 트래픽이 몰릴 경우 해당 서비스만 선택적으로 확장 가능함.
      • 블랙프라이데이 상황에서 주문/결제 서비스만 오토스케일링 적용하고 회원관리, 리뷰 서비스는 기존 상태 유지함.
      • 이를 통해 자원 사용 최적화 및 비용 절감 효과 기대 가능함.

2. 유지보수성 (Maintainability) 관점

• 모놀리틱(거대해지는 코드베이스와 높은 결합도)
  • 복잡한 코드베이스
    • 시간이 지날수록 다양한 개발자의 수정이 누적되면서 코드 구조가 복잡해지는 경향이 있음.
    • 모듈 간 경계가 모호해지고, 전체 시스템을 완전히 이해하는 개발자가 줄어드는 문제 발생함.
  • 변경 영향 범위 증가
    • 특정 기능 수정 시 관련 없어 보이는 다른 기능에도 사이드 이펙트(Side Effect)나 버그 발생 가능성 높아짐.
    • 이로 인해 작은 수정에도 전체 시스템에 대한 회귀 테스트(Regression Test) 수행 필요성이 커짐
    • 배포 주기가 길어지는 경향 있음.
• MSA(느슨한 결합과 독립적인 서비스 구조)
  • 독립적인 서비스 환경
    • 각 마이크로서비스는 역할이 명확하고 코드 범위가 상대적으로 작음.
    • 서비스 간 통신은 정의된 API 기반으로 이루어짐
    • 내부 구현 변경 시 다른 서비스에 직접적인 영향 최소화됨(느슨한 결합).
  • 빠른 기능 수정 및 배포
    • 특정 서비스의 버그 수정 또는 기능 추가 시 전체 시스템 재배포 없이
    • 해당 서비스만 개별적으로 빌드 및 배포 가능함.
    • 변경 사항 반영 속도 향상 및 지속적 제공(Continuous Delivery) 환경 구성에 유리함.

3. 복잡성 (Complexity) 관점

• 모놀리틱(초기 단순성, 성장 이후 복잡성 증가)
  • 초기 단순성
    • 프로젝트 초기에는 하나의 애플리케이션 구조만 관리하면 되므로 설계와 개발 방식이 비교적 단순함.
    • 인프라 구성 요소가 적어 초기 운영 비용 부담도 낮은 편임.
  • 복잡성 증가
    • 서비스 규모 확장과 기능 추가가 반복될수록 내부 의존성과 코드 복잡도 증가함.
    • 애플리케이션이 거대해질 경우 개발 속도 저하, 유지보수 난이도 상승 등의 문제 발생 가능성 높아짐.
• MSA(초기 복잡성, 운영 안정성 중심 구조)
  • 초기 구축 복잡성
    • 서비스 간 통신 방식, 데이터베이스 분리 전략, CI/CD 파이프라인 구성 등 고려해야 할 요소가 많음
    • 초기 설계와 구축 난이도 높음.
  • 운영 및 관리 복잡성
    • 하나의 요청이 여러 서비스 간 호출을 거치는 구조이므로 네트워크 지연(Latency) 발생 가능성 존재함.
    • 장애 발생 시 원인 추적 범위가 넓어져 문제 분석 난이도 증가함.
    • 중앙 집중형 로깅(예: ELK Stack) 및 분산 트레이싱(예: Jaeger, Zipkin) 도입 필요성 높아짐.

4. MSA 도입 시 필수 고려사항

1. 조직 문화와 역량 (Conway’s Law & DevOps)

• DevOps 및 CI/CD 체계 필요성
  • MSA 환경에서는 여러 서비스가 독립적으로 자주 배포되는 구조임.
  • 따라서 빌드, 테스트, 배포 과정을 자동화하는 CI/CD 파이프라인 구축 필요성 높음.
  • 자동화 체계가 부족할 경우 서비스별 버전 관리 및 장애 대응 복잡도 증가함.
• 교차 기능 팀(Cross-functional Team) 구성
  • 하나의 마이크로서비스를 중심으로 기획, 프론트엔드, 백엔드, 인프라 인력이 함께 책임지는 협업 구조 요구됨.
  • 서비스 단위의 독립적인 의사결정과 빠른 개선 사이클 운영에 적합한 조직 형태임.

2. 서비스 경계 정의 (Bounded Context)

• 도메인 주도 설계(DDD) 기반 서비스 분리
  • MSA에서는 서비스 간 결합도 감소를 위해 DDD의 Bounded Context(제한된 맥락) 개념 활용함.
  • 업무 경계가 명확한 단위 기준으로 서비스 분리 필요함.
• 잘못된 서비스 분리의 위험성
  • 서비스 경계가 모호하면 기능 수정 시 여러 서비스를 함께 수정·배포해야 하는 문제 발생함.
  • 이는 분산 모놀리틱(Distributed Monolithic) 구조로 이어질 수 있으며 운영 복잡도 증가 원인 됨.

3. 분산 데이터 관리와 데이터 일관성

• Database-per-service 원칙
  • 각 마이크로서비스는 전용 데이터베이스를 가지는 구조 권장됨.
  • 다른 서비스 DB 직접 조회 또는 Join 사용 지양함.
• 분산 트랜잭션 처리 방식
  • 2PC(Two-Phase Commit)는 분산 환경에서 성능 저하와 데드락 문제 발생 가능성 존재함.
  • 따라서 Saga 패턴 또는 이벤트 소싱(Event Sourcing) 기반 방식 활용하여 최종 데이터 일관성 유지함.

4. 관찰 가능성 (Monitoring & Logging)

• 분산 트레이싱(Distributed Tracing) 필요성
  • 하나의 요청이 여러 서비스를 거치는 구조이므로 병목 구간과 오류 위치 추적 필요함.
  • Trace ID 기반 도구(예: Zipkin, Jaeger) 활용함.
• 중앙 집중형 로깅 및 메트릭 관리
  • 서비스별 로그를 한곳으로 수집하는 통합 로깅 환경 필요함.
  • ELK Stack, Grafana Loki 기반 로그 관리 활용함.
  • Prometheus + Grafana 기반 실시간 모니터링 구성 가능함.

5. 네트워크 인프라와 통신 복잡성

• 서비스 디스커버리 및 라우팅
  • 동적으로 변경되는 서비스 IP를 자동 관리하는 Service Discovery 필요함.
  • 외부 요청 분산 및 라우팅을 위한 API Gateway 구성 중요함.
• 장애 전파 방지(Circuit Breaker)
  • 특정 서비스 장애가 전체 시스템 장애로 확산되는 상황 방지 필요함.
  • Circuit Breaker 패턴 적용하여 장애 서비스 호출 차단 및 시스템 안정성 유지함.

6. 서비스 간 통신 보안 (Security)

• 종단 간 보안(End-to-End Security)
  • 외부 요청은 API Gateway에서 JWT(JSON Web Token), OAuth2.0 기반 인증·인가 처리함.
  • 인증 체계 중앙화로 보안 관리 효율 향상 가능함.
• 내부 통신 보안
  • 서비스 간 통신에도 mTLS(mutual TLS) 적용하여 상호 인증 수행함.
  • 제로 트러스트(Zero Trust) 기반 내부 침투 및 데이터 탈취 방지 고려 필요함.