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

기술노트
(CS 용어 정리 - 마이크로서비스 아키텍처(MSA) 추가)
 
편집 요약 없음
 
(같은 사용자의 중간 판 6개는 보이지 않습니다)
1번째 줄: 1번째 줄:
== 마이크로서비스 아키텍처(MSA) ==
⚡ '''마이크로서비스 아키텍처(MSA, Microservices Architecture)란?'''


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


<syntaxhighlight>
각 서비스는 '''독립적으로 배포·확장·관리'''할 수 있고, 서비스 간에는 '''API'''를 통해 통신합니다.
MSA는 소프트웨어 개발 기법 중 하나로, 어플리케이션 단위를 '목적'으로 나누는 것이 핵심
</syntaxhighlight>


<br>
예시: 넷플릭스, 아마존, 쿠팡 등 대규모 서비스들이 MSA 방식을 사용하고 있습니다.
----🧩 '''MSA의 주요 개념'''


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


MSA가 도입되기 전, Monolithic 아키텍처 방식으로 개발이 이루어졌다. Monolithic의 사전적 정의에 맞게 '한 덩어리'에 해당하는 구조로 이루어져 있다. 모든 기능을 하나의 어플리케이션에서 비즈니스 로직을 구성해 운영한다. 따라서 개발을 하거나 환경설정에 있어서 간단한 장점이 있어 작은 사이즈의 프로젝트에서는 유리하지만, 시스템이 점점 확장되거나 큰 프로젝트에서는 단점들이 존재한다.
----📊 '''MSA vs 모놀리식 아키텍처 비교'''
{| class="wikitable"
!구분
!모놀리식(Monolithic)
!MSA(Microservices)
|-
|애플리케이션 구조
|하나의 큰 애플리케이션
|여러 개의 독립된 작은 서비스
|-
|배포 방식
|전체 애플리케이션 한번에 배포
|개별 서비스 단위로 독립 배포
|-
|장애 발생 영향
|장애 시 전체 서비스가 영향
|특정 서비스만 제한적 영향
|-
|기술 스택
|하나의 기술로 통일
|서비스마다 다양한 기술 선택 가능
|-
|확장성
|전체 서비스 확장 (비효율적)
|특정 서비스만 개별 확장
|}
----📦 '''MSA의 구조 예시'''


* 빌드/테스트 시간의 증가 : 하나를 수정해도 시스템 전체를 빌드해야 함. 즉, 유지보수가 힘들다
서비스 간 통신은 API를 통해 이루어지고, 각 서비스는 독립된 데이터베이스를 사용합니다.
* 작은 문제가 시스템 전체에 문제를 일으킴 : 만약 하나의 서비스 부분에 트래픽 문제로 서버가 다운되면, 모든 서비스 이용이 불가능할 것이다.
* 확장성에 불리 : 서비스 마다 이용률이 다를 수 있다. 하나의 서비스를 확장하기 위해 전체 프로젝트를 확장해야 한다.


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


MSA는 좀 더 세분화 시킨 아키텍처라고 말할 수 있다. 한꺼번에 비즈니스 로직을 구성하던 Monolithic 방식과는 다르게 기능(목적)별로 컴포넌트를 나누고 조합할 수 있도록 구축한다.
* 서비스가 빠르게 변화하고 자주 업데이트가 필요한 경우
* 독립된 개발팀이 각각의 서비스를 맡아 개발·운영하는 경우
* 대규모 트래픽 처리를 위해 서비스별로 수평적 확장이 필요한 경우


<img src="https://www.redhat.com/cms/managed-files/monolithic-vs-microservices.png">
⚠️ '''MSA가 부적합한 상황'''


<img src="https://miro.medium.com/max/1250/1*V_mvV0mbfcBoCcirDgsvZw.png">
* 규모가 작고 단순한 서비스로 복잡성만 증가할 경우
* 자동화 및 DevOps 역량이 부족한 팀이나 조직의 경우


<br>
----🔑 '''실전에서 꼭 고려할 사항'''


MSA에서 각 컴포넌트는 API를 통해 다른 서비스와 통신을 하는데, 모든 서비스는 각각 독립된 서버로 운영하고 배포하기 때문에 서로 의존성이 없다. 하나의 서비스에 문제가 생겨도 다른 서비스에는 영향을 끼치지 않으며, 서비스 별로 부분적인 확장이 가능한 장점이 있다.
* 서비스의 경계를 명확히 도메인 기준으로 나누세요.
* API Gateway와 서비스 디스커버리를 꼭 도입하세요.
* 통합된 모니터링과 중앙화된 로그 관리가 필수입니다.
* 데이터 정합성을 위해 Event-driven 방식이나 Saga 패턴 등을 고려하세요.


<img src="http://clipsoft.co.kr/wp/wp-content/uploads/2020/06/leh_6.png">
----💡 '''개발자가 꼭 알아야 할 핵심'''


즉, 서비스 별로 개발팀이 꾸려지면 다른 팀과 의존없이 팀 내에서 피드백을 빠르게 할 수 있고, 비교적 유연하게 운영이 가능할 것이다.
* MSA는 독립적인 서비스 단위로 구성된 아키텍처입니다.
* 서비스 간에는 API 기반으로 소통하며, 독립적 배포가 가능합니다.
* 자동화된 배포 및 운영 체계 구축이 필수적입니다.
* 도메인 중심 설계, API 게이트웨이, 모니터링 등의 인프라가 중요합니다.


좋은 점만 있지는 않다. MSA는 서비스 별로 호출할 때 API로 통신하므로 속도가 느리다. 그리고 서비스 별로 통신에 맞는 데이터로 맞추는 과정이 필요하기도 하다. Monolithic 방식은 하나의 프로세스 내에서 진행되기 때문에 속도 면에서는 MSA보다 훨씬 빠를 것이다. 또한, MSA는 DB 또한 개별적으로 운영되기 때문에 트랜잭션으로 묶기 힘든 점도 있다.
----📚 '''참고 링크'''
<embedvideo service="youtube" width="560" height="315">SIe_0G1zbj0</embedvideo>


<br>
== 📚 참고 자료 ==
 
* [https://kmong.com/self-marketing/539751/LUA54VnQsP 💼 IT 면접용 CS PDF]
따라서, 서비스별로 분리를 하면서 얻을 수 있는 장점도 있지만, 그만큼 체계적으로 준비돼 있지 않으면 MSA로 인해 오히려 프로젝트 성능이 떨어질 수도 있다는 점을 알고있어야 한다. 정답이 정해져 있는 것이 아니라, 프로젝트 목적, 현재 상황에 맞는 아키텍처 방식이 무엇인지 설계할 때부터 잘 고민해서 선택하자.
* [https://inf.run/o1NX 📦 AWS 백엔드 강의]
 
* [https://inf.run/rpX4 🤖 ChatGPT 앱 개발 강의]
<br>
* [https://www.yes24.com/Product/Goods/122536127 📘 백엔드 번역서]
 
* [https://kmong.com/self-marketing/660133/0lzAfkXXMc 📕 기술노트with알렉 PDF 도서]
<br>
 
===== [참고 자료] =====
 
* [링크](https://medium.com/@shaul1991/%EC%B4%88%EB%B3%B4%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%BC%EC%A7%80-%EB%8C%80%EC%84%B8-msa-%EB%84%88-%EB%AD%90%EB%8B%88-efba5cfafdeb)
* [링크](http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/)

2025년 7월 5일 (토) 07:18 기준 최신판

⚡ 마이크로서비스 아키텍처(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=702"