MSA(Micro Service Architecture)

merong·2024년 3월 2일

BACK-END

목록 보기

2/4

🔬 마이크로서비스(microservice)란 한 가지 일만 수행하는 작은 애플리케이션의 모임으로 구조화하는 개발 기법이다. 이로써, 지속적 통합과 배포를 가능하게 한다.

필요성

기존의 애플리케이션 구축 방식 “모놀리식(Monolithic)”

기존 시스템들은 하나의 시스템 자원을 공유하며, 하나의 덩어리 안에서 서비스를 제공하고자 하였습니다. 이와 같은 서비스는 개발이 쉽고, 운영 비용이 적게 든다는 장점을 가지고 있지만, 개발하고자 하는 서비스 규모가 점점 커질 경우, 다음과 같은 단점들이 보이기 시작합니다.

개발이 느리고 어렵다.

기능이 다른 코드 간에 불필요하게 의존성이 늘어나게 되기 때문에, 코드 수정을 마음대로 하기가 쉽지 않아집니다. 이로써 개발 생산성 또한 떨어지게 됩니다.
배포가 자유롭지 못하다.

위에서 언급하였듯이, 코드 간의 연관성이 복잡해져서 배포 소스의 안정성을 보장하기 쉽지 않아집니다. 적은 코드 수정이 이루어졌다고 해도, 관련된 부분에 대해서는 항상 영향도 테스트를 해 보아야 하는 번거로움이 생깁니다.
기술 스택에 한계가 있다.

하나의 서비스에 하나의 언어, 정해진 데이터베이스만을 사용하기에, 만약 최근의 새로운 언어 또는 기술을 도입하고 싶다면 이를 수정하기가 까다로워집니다.

따라서, 이와 같은 모놀리식 아키텍처를 개선하고자 서비스를 작은 단위로 쪼개서 관리하는 “마이크로 서비스 아키텍처”가 등장하게 되었습니다.

➕CI/CD란?

계속 리서치를 하던 도중, CI/CD라는 용어가 많이 보여 이에 대한 개념을 잡고 가면 좋을 것 같아 찾아보게 되었습니다.
- CI (Continuous Integration, 지속적 통합)
  지속적으로 서비스해야 하는 어플리케이션에서 다수의 개발자가 Git과 같은 협업 툴을 공유하는 경우, 수많은 commit들을 어떻게 서로 충돌하지 않게 합쳐야 할까?
  1. 새로운 코드 변경 사항이 여러 군데 생긴다.
  2. 이러한 코드를 서로 기능이 겹치지 않게 잘.. 합쳐본다.
  3. 코드를 빌드하여 실행해본다.
  4. 테스트해서 잘 실행되는지 따져본다.
  5. 잘 되는 듯하면 그대로 공유 레포지토리에 merge한 코드 적용시킨다.
  이러한 과정들을 CI라고 하는 듯한데, 이것의 목표는 다음과 같습니다.
  
  🐛 버그를 신속하게 찾았는지
  
  🆙 소프트웨어의 품질이 개선되었는지
  
  🗡️ 새로운 업데이트 검증&릴리즈의 시간이 단축되었는지
- CD (Continuous Delivery / Deployment, 지속적인 배포, 배치)
  
  CD는 두 가지로 나뉩니다. 배포를 수동으로 하는 Delivery와 자동으로 하는 Deployment로..
  
  그렇다면… 배포는 무엇일까요?
  
  최최최종_수정파일을 예쁘게 포장해서 고객의 식탁(환경)에 나의 프로그램을 올려야 하는 것…입니다.
  1. 이 과정을 수동으로 한다는 건… 다음의 과정을 거친다는 것과 같습니다.
    
    불량인지 아닌지 판별 → 포장 → 고객의 집에 방문하여 설치 까지 해준다는 것.. 친절한 사장님이죠..
  2. 이 과정을 자동으로 한다는 건..
    
    공장에서 불량 판별 시스템과 자동 포장 시스템을 도입하고, 이를 알아서 배송까지 해주는 것이겠죠.. 정은 없지만 왠지 빠를 것만 같네요…
  이를 수동으로 할지, 자동으로 할지는 서비스 제공자에게 달려있다고 합니다.
  
  ⇒ DevOps 엔지니어는 CI/CD를 자동화하는 업무를 주로 하게 됩니다. 새로운 기능을 구현한다기 보단, 고객에게 안정감 있는 서비스를 배포하여 운영하는 중대한 일을 하는 셈입니다…

기능적 특징

(장점)

클라우드 환경에 친화적

마이크로서비스 구조는 서비스단위로 기능을 분리해서 구축할 수 있기 때문에, 사용하지 않는 기능 또는 사용량이 적은 기능을 축소해서 효율화시킬 수 있습니다. 이로써 사용량 단위로 과금을 해야 하는 클라우드 환경에서 비용면으로 이득을 얻을 수 있습니다.
확장성

각각의 마이크로서비스는 독립적으로 배포되고 실행되기 때문에 필요에 따라 개별적으로 확장이 가능합니다. 이는 전체 시스템의 확장성을 향상시킵니다.
유연성과 빠른 배포

각 마이크로서비스는 독립적으로 배포될 수 있으므로 특정 서비스의 변경이나 업데이트가 전체 시스템에 미치는 영향이 적습니다. 이는 개발자가 빠르게 새로운 기능을 배포하고 유연하게 개발할 수 있게 합니다.
기술 다양성

자체적인 기술 스택을 선택할 수 있습니다. 이는 다양한 기술을 혼합하여 사용할 수 있고, 최신 기술로의 전환도 용이하게 합니다.
독립적인 개발 및 배포 가능

각 마이크로서비스는 독립적으로 개발되고 배포되므로, 하나의 서비스에 문제가 발생해도 전체 시스템이 영향을 받지 않는다는 장점을 가지고 있습니다.

(단점)

운영 복잡성

여러 서비스를 관리하고 운영하는 것은 복잡성을 증가시킬 수 있습니다. 서비스 간 통신, 모니터링, 로깅 등 관리해야 하는 포인트가 증가하게 됩니다.
개발자 및 팀 간 협업의 어려움

각 서비스가 독립적으로 개발되므로, 팀 간의 협업이 중요하며, 일관된 API 및 커뮤니케이션 규약이 필요합니다.

시스템 다이어그램

마이크로서비스의 구성요소 : API 게이트웨이를 통해 액세스하는 다양한 마이크로 서비스의 모습

주요 구성 요소 설명

Client🙋‍♀️ : 조회, 생성, 삭제 등 다양한 수행 요청, 내부 마이크로서비스도 클라이언트에 해당.
API Gateway🚪 : 클라이언트가 보낸 요청에 대해 적절한 서비스로 안내하는 진입점 역할.
메세지 포맷 ✉️ : 마이크로서비스의 상호 간 통신 비결 → 동기 / 비동기
데이터베이스🛢️ : 각 마이크로서비스 별로 자신만의 데이터베이스를 가짐. A 서비스에서 B 서비스의 DB를 직접 접근하지는 않고, API를 통해 다른 서비스의 DB에 접근.

Reference

merong

매일매일이 새로운 시작점

이전 포스트

[FastAPI] FastAPI과 Uvicorn

다음 포스트