마이크로서비스 아키텍처(MSA): 두 판 사이의 차이

기술노트
편집 요약 없음
편집 요약 없음
1번째 줄: 1번째 줄:
<nowiki>== ⚡ 마이크로서비스 아키텍처(MSA, Microservices Architecture)란? ==</nowiki>
⚡ '''마이크로서비스 아키텍처(MSA, Microservices Architecture)란?'''


<nowiki>'''마이크로서비스 아키텍처(MSA, Microservices Architecture)'''</nowiki>는
<nowiki>**</nowiki>마이크로서비스 아키텍처(MSA)**는 하나의 큰 애플리케이션을 여러 개의 '''작고 독립적인 서비스'''로 나누어 개발하고 운영하는 소프트웨어 아키텍처입니다.


하나의 큰 애플리케이션을 '''작은 단위의 독립적인 서비스'''로 나누어 개발·운영하는 소프트웨어 설계 방식입니다.
각 서비스는 '''독립적으로 배포·확장·관리'''할 수 있고, 서비스 간에는 '''API'''를 통해 통신합니다.


* 서비스별로 <nowiki>'''독립 배포·확장·관리'''가 가능하며, 서비스끼리는 '''API'''</nowiki>를 통해 통신합니다.
예시: 넷플릭스, 아마존, 쿠팡 등 대규모 서비스들이 MSA 방식을 사용하고 있습니다.
* 넷플릭스, 아마존, 쿠팡과 같은 대규모 플랫폼 기업들이 적극적으로 채택하고 있습니다.
----🧩 '''MSA의 주요 개념'''


----=== 🔧 MSA의 특징 ===
* '''독립된 작은 서비스'''
** 각 서비스는 별도의 팀이 책임지고 독립적으로 관리합니다.
** 개별 프로세스 또는 컨테이너 환경에서 실행됩니다.
* '''API 기반의 통신'''
** 서비스끼리는 주로 HTTP/REST, gRPC, 메시지 큐(Kafka, RabbitMQ 등)로 통신합니다.
* '''서비스별 분산된 데이터 관리'''
** 각 서비스가 별도의 데이터베이스를 관리하여 독립성이 높습니다.
* '''자동화 및 DevOps 문화'''
** CI/CD 파이프라인을 통해 빠르고 지속적인 배포가 가능합니다.
* '''장애 격리'''
** 서비스 하나의 장애가 전체 시스템에 전파되지 않고 격리됩니다.


* '''독립적인 작은 서비스 (Independent Services)'''  : 서비스별로 개별 팀이 책임지고, 독립적인 프로세스/컨테이너에서 동작합니다.
----📊 '''MSA vs 모놀리식 아키텍처 비교'''
* '''API 기반 통신 (Communication via API)'''  : 서비스끼리 HTTP/REST, gRPC, 메시지 큐(카프카, RabbitMQ 등)로 상호작용합니다.
* '''분산 데이터 관리 (Decentralized Data Management)'''  : 서비스별로 별도의 데이터베이스를 관리하여 데이터가 독립적입니다.
* '''자동화 및 DevOps 문화 필수 (Automation & DevOps)'''  : 빠른 배포와 무중단 업데이트를 위해 CI/CD 및 자동화된 배포 환경 구축이 필수입니다.
* '''장애 격리 (Fault Isolation)'''  : 특정 서비스 장애 시 전체 시스템으로 전파되지 않고 해당 서비스만 격리 가능합니다.
 
----=== 📊 MSA vs 모놀리식 아키텍처 ===
 
<nowiki>{| class="wikitable"</nowiki>
{| class="wikitable"
{| class="wikitable"
!<nowiki>! 구분 !! 모놀리식 (Monolithic) !! MSA (Microservices)</nowiki>
!구분
!모놀리식(Monolithic)
!MSA(Microservices)
|-
|-
|애플리케이션 구조
|애플리케이션 구조
|-
|하나의 큰 애플리케이션
| -
|여러 개의 독립된 작은 서비스
|-
|-
|배포 방식
|배포 방식
|전체 애플리케이션 한번에 배포
|개별 서비스 단위로 독립 배포
|-
|-
| -
|장애 발생 영향
|-
|장애 시 전체 서비스가 영향
|장애 영향 범위
|특정 서비스만 제한적 영향
|-
| -
|-
|-
|기술 스택
|기술 스택
|-
|하나의 기술로 통일
| -
|서비스마다 다양한 기술 선택 가능
|-
|-
|확장성
|확장성
|-
|전체 서비스 확장 (비효율적)
| }
|특정 서비스만 개별 확장
|}
|}
----=== 📦 MSA 예시 구조 ===
----📦 '''MSA의 구조 예시'''
 
<nowiki>[[파일:MSA-architecture-example.png|600px|가운데|MSA 구조 예시]]</nowiki>
 
<nowiki>:</nowiki> 각 서비스는 독립 배포, 독립 데이터베이스를 가지며 API로만 통신합니다.
----=== ✅ MSA가 적합한 경우 ===


* 서비스의 <nowiki>'''빠른 개발과 빈번한 변경'''</nowiki>이 필요할 때
서비스 간 통신은 API를 통해 이루어지고, 각 서비스는 독립된 데이터베이스를 사용합니다.
* 서비스별로 독립된 팀 운영이 필요할 때
* <nowiki>'''대규모 트래픽'''을 처리하기 위해 '''수평 확장성'''</nowiki>이 필수적일 때


<nowiki>=== ⚠️ MSA가 부적합한 경우 ===</nowiki>
예를 들어, 쇼핑몰 서비스의 경우 다음과 같이 구성될 수 있습니다:
----✅ '''MSA가 적합한 상황'''


* 소규모 서비스로 관리 복잡성이 과도할 때
* 서비스가 빠르게 변화하고 자주 업데이트가 필요한 경우
* 조직의 DevOps 역량과 경험이 부족할 때
* 독립된 개발팀이 각각의 서비스를 맡아 개발·운영하는 경우
* 대규모 트래픽 처리를 위해 서비스별로 수평적 확장이 필요한 경우


----=== 🔑 실전 운영 시 고려할 사항 ===
⚠️ '''MSA가 부적합한 상황'''


* 서비스 경계는 반드시 <nowiki>'''도메인 중심'''</nowiki>으로 명확히 나눕니다.
* 규모가 작고 단순한 서비스로 복잡성만 증가할 경우
* 서비스 간 통신을 위한 <nowiki>'''API 게이트웨이'''와 '''서비스 디스커버리'''</nowiki>를 반드시 구축합니다.
* 자동화 및 DevOps 역량이 부족한 팀이나 조직의 경우
* 로그 관리와 모니터링 시스템 구축은 필수입니다. (Elastic Stack, Prometheus 등)
* 서비스 간 데이터 일관성은 <nowiki>'''</nowiki>Event-Driven 설계<nowiki>'''</nowiki>나 <nowiki>'''</nowiki>Saga 패턴<nowiki>'''</nowiki>으로 해결합니다.


----=== 💡 개발자가 꼭 알아야 할 MSA 요약 ===
----🔑 '''실전에서 꼭 고려할 사항'''


* MSA는 서비스 단위로 독립된 작은 서비스 아키텍처입니다.
* 서비스의 경계를 명확히 도메인 기준으로 나누세요.
* 서비스끼리 API로 소통하며, 독립 배포 및 확장 가능합니다.
* API Gateway와 서비스 디스커버리를 꼭 도입하세요.
* 운영 복잡도가 높아 자동화, DevOps 역량이 필수입니다.
* 통합된 모니터링과 중앙화된 로그 관리가 필수입니다.
* 도메인 중심 설계, API 게이트웨이, 서비스 디스커버리 구축이 필수입니다.
* 데이터 정합성을 위해 Event-driven 방식이나 Saga 패턴 등을 고려하세요.


----== 📚 참고 자료 ==
----💡 '''개발자가 꼭 알아야 할 핵심'''


* [<nowiki/>[[/technote.wiki/|https://technote.wiki]] technote.wiki - 마이크로서비스 아키텍처]
* MSA는 독립적인 서비스 단위로 구성된 아키텍처입니다.
* [<nowiki/>[[/d2.naver.com/helloworld/4769021|https://d2.naver.com/helloworld/4769021]] 네이버 D2 - MSA 가이드]
* 서비스 간에는 API 기반으로 소통하며, 독립적 배포가 가능합니다.
* [<nowiki/>[[/martinfowler.com/articles/microservices.html|https://martinfowler.com/articles/microservices.html]] Martin Fowler - Microservices]
* 자동화된 배포 및 운영 체계 구축이 필수적입니다.
* 도메인 중심 설계, API 게이트웨이, 모니터링 등의 인프라가 중요합니다.


----
----📚 '''참고 링크'''


== 추가적인 질문이나 수정 요청은 <nowiki>[[토론:MSA]]</nowiki> 문서에 남겨주세요! 😊 ==
* 💼 [[/kmong.com/self-marketing/539751/LUA54VnQsP|IT 면접용 CS PDF]]
* 📦 [[/inf.run/o1NX|AWS 백엔드 강의]]
* 🤖 [[/inf.run/rpX4|ChatGPT 앱 개발 강의]]
* 📘 [[/www.yes24.com/Product/Goods/122536127|백엔드 번역서 (YES24)]]
* 🎬 [[/www.youtube.com/c/기술노트with알렉|기술노트with알렉 유튜브]]
* 📕 [[/kmong.com/self-marketing/660133/0lzAfkXXMc|기술노트with알렉 PDF 도서]]

2025년 7월 4일 (금) 13:56 판

⚡ 마이크로서비스 아키텍처(MSA, Microservices Architecture)란?

**마이크로서비스 아키텍처(MSA)**는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 나누어 개발하고 운영하는 소프트웨어 아키텍처입니다.

각 서비스는 독립적으로 배포·확장·관리할 수 있고, 서비스 간에는 API를 통해 통신합니다.

예시: 넷플릭스, 아마존, 쿠팡 등 대규모 서비스들이 MSA 방식을 사용하고 있습니다.

🧩 MSA의 주요 개념

  • 독립된 작은 서비스
    • 각 서비스는 별도의 팀이 책임지고 독립적으로 관리합니다.
    • 개별 프로세스 또는 컨테이너 환경에서 실행됩니다.
  • API 기반의 통신
    • 서비스끼리는 주로 HTTP/REST, gRPC, 메시지 큐(Kafka, RabbitMQ 등)로 통신합니다.
  • 서비스별 분산된 데이터 관리
    • 각 서비스가 별도의 데이터베이스를 관리하여 독립성이 높습니다.
  • 자동화 및 DevOps 문화
    • CI/CD 파이프라인을 통해 빠르고 지속적인 배포가 가능합니다.
  • 장애 격리
    • 서비스 하나의 장애가 전체 시스템에 전파되지 않고 격리됩니다.

📊 MSA vs 모놀리식 아키텍처 비교

구분 모놀리식(Monolithic) MSA(Microservices)
애플리케이션 구조 하나의 큰 애플리케이션 여러 개의 독립된 작은 서비스
배포 방식 전체 애플리케이션 한번에 배포 개별 서비스 단위로 독립 배포
장애 발생 영향 장애 시 전체 서비스가 영향 특정 서비스만 제한적 영향
기술 스택 하나의 기술로 통일 서비스마다 다양한 기술 선택 가능
확장성 전체 서비스 확장 (비효율적) 특정 서비스만 개별 확장

📦 MSA의 구조 예시

서비스 간 통신은 API를 통해 이루어지고, 각 서비스는 독립된 데이터베이스를 사용합니다.

예를 들어, 쇼핑몰 서비스의 경우 다음과 같이 구성될 수 있습니다:

✅ MSA가 적합한 상황

  • 서비스가 빠르게 변화하고 자주 업데이트가 필요한 경우
  • 독립된 개발팀이 각각의 서비스를 맡아 개발·운영하는 경우
  • 대규모 트래픽 처리를 위해 서비스별로 수평적 확장이 필요한 경우

⚠️ MSA가 부적합한 상황

  • 규모가 작고 단순한 서비스로 복잡성만 증가할 경우
  • 자동화 및 DevOps 역량이 부족한 팀이나 조직의 경우

🔑 실전에서 꼭 고려할 사항

  • 서비스의 경계를 명확히 도메인 기준으로 나누세요.
  • API Gateway와 서비스 디스커버리를 꼭 도입하세요.
  • 통합된 모니터링과 중앙화된 로그 관리가 필수입니다.
  • 데이터 정합성을 위해 Event-driven 방식이나 Saga 패턴 등을 고려하세요.

💡 개발자가 꼭 알아야 할 핵심

  • MSA는 독립적인 서비스 단위로 구성된 아키텍처입니다.
  • 서비스 간에는 API 기반으로 소통하며, 독립적 배포가 가능합니다.
  • 자동화된 배포 및 운영 체계 구축이 필수적입니다.
  • 도메인 중심 설계, API 게이트웨이, 모니터링 등의 인프라가 중요합니다.

📚 참고 링크

원본 주소 "https://technote.wiki/index.php?title=마이크로서비스_아키텍처(MSA)&oldid=693"