Microservice Architecture

index

1. MSA가 무엇인가? 왜 핫해졌을까?
2. MSA사례
   1. 넷플릭스
   2. 배달의 민족
   3. 그 외
3. MSA 개념
4. MSA 무조건 좋은가?

 

1. MSA가 무엇인가?

Monolithic Architecture

소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태

Monolithic Architecture의 단점

1. 하나의 수정사항이 있어도 모든 코드를 다시 빌드하고 배포를 해야한다.
   • 구글 같은 회사는 하루 커밋 수가 45,000건에 달하는데 이 모든걸 빌드하고 배포할 수 있는가?
2. 애플리케이션이 너무 크고 복잡해져서 개발자들도 코드를 이해할 수 없어졌다
3. 계속해서 기능을 붙이고 수정해나가다 보면 애플리케이션은 큰 진흙 공(BIG BALL OF MUD, BBOM)이 되어 간다
4. 부분 장애가 전체 서비스의 장애로 확대될 수 있다
5. 오버헤드가 커져서 테스트도 어렵다... 그렇다면 production 환경에서 버그가 없을 수 있을까? 😱

이러한 Monolithic Architecture의 한계로 인해 Microservice Architecture가 등장했다.

Microservice Architecture가 뭐지?

마이크로서비스 아키텍처란 애플리케이션 개발을 위한 아키텍처 스타일을 의미합니다. 마이크로서비스를 사용하면 대규모 애플리케이션을 각각 담당 영역을 가진 소규모의 독립적인 구성요소로 구분할 수 있습니다. 마이크로서비스 기반 애플리케이션은 단일 사용자 요청을 처리하기 위해 여러 내부 마이크로서비스를 호출하여 응답을 작성할 수 있습니다. (google cloud)

마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식입니다. 이러한 서비스는 독립적인 소규모 팀에서 보유합니다. 마이크로서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있게 해 줍니다. (Amazon AWS)

마이크로 서비스 아키텍처 스타일은 단일 애플리케이션을 작은 서비스 제품군으로 개발하는 접근 방식이며, 각각은 자체 프로세스에서 실행되며 종종 HTTP 리소스 API와 같은 경량 메커니즘과 통신한다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전히 자동화된 배치 시스템에 의해 독립적으로 배포될 수 있습니다. 이러한 서비스에 대한 중앙 집중식 관리는 최소한으로 이루어지며, 이러한 서비스는 서로 다른 프로그래밍 언어로 작성되고 서로 다른 데이터 스토리지 기술을 사용할 수 있습니다. (마틴 파울러)

중요한 키워드!

1. 각각 담당 영역을 가진 소규모의 독립적인 구성요소로 구분
2. 잘 정의된 HTTP 리소스 API를 통해 통신하는 소규모의 독립적인 서비스로 구성
3. 완전히 자동화된 배치 시스템에 의해 독립적으로 배포

MSA의 특징은 다음과 같다

1. API를 통해서만 통신한다
2. 집중화된 관리체계를 사용하지 않고, REST와 같이 가벼운 통신을 이용한다
3. 하나의 비즈니스 범위에 맞춰서 하나의 기능만 수행한다

MSA의 장점

1. 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게할 수 있도록 한다.
2. 팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다.
3. 마이크로서비스는 서비스별로 독립적 배포가 가능하다. 따라서 지속적인 배포 CD도 모놀로식에 비해서 가볍게 할 수 있다.
   • 배포 시 전체 서비스의 중단이 없고 요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
4. 마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 메모리, CPU적으로 상당부분 이득이 된다.
   • 특정 서비스에 대한 확장성이 용이함
5. 일부분에 장애가 발생해도 전체 서비스에는 영향을 끼치지 않음

2. MSA 사례

a. 넷플릭스

• 2007년 심각한 데이터베이스 손상으로 3일간 서비스 장애를 겪음
  • 넷플릭스는 모놀리식에서 MSA로의 전환을 생존 문제였다고 말한다
• 2008년부터 7년 동안 MSA 전환
• 넷플릭스가 경험한 노하우와 문제해결 방법을 공유하기 위해 MSA 전환 기술을 오픈소스로 공개 ⇒ 넷플릭스 OSS(Open Source Software)
• https://netflixtechblog.com/search?q=NetflixOSS
• MSA를 통해 고화질의 영상 스트리밍을 전세계로 가용성 높게 송출

b. 배달의 민족

• 폭발적인 주문수 증가로 MSA 전환
  •  
• 2016년부터 4년 동안 MSA 전환
• https://youtu.be/BnS6343GTkY

c. 그 외

• 11번가 : https://www.youtube.com/watch?v=J-VP0WFEQsY&feature=emb_title
• 카카오톡 이모티콘 : https://tech.kakao.com/2021/09/14/msa/

3. MSA 개념

3-1. Inner Architecture

• 서비스를 어떻게 설계할 것인가?
• DB 구조를 어떻게 설계할 것인가?
• 등등..

정해진 사항이 아니며 비즈니스마다 알맞게 설계하면 된다

3-2. Outer Architecture

가트너 사에서 분류한 MSA의 Outer Architecture의 구조이다

1. External Gateway
   • API Gateway
2. Service Mesh
3. Container Management
4. Backing Services
   • 어플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스
   • Message Queue
5. Telemetry
6. CI/CD Automation

+) RESTful API

핵심 기술 세 가지 설명

1. API Gateway

• Client - Service의 직접적인 통신
  • 경우에 따라 각 마이크로 서비스에 대해 다른 TCP 포트가 있다.
  • 여러 마이크로서비스를 호출해야하는 번거로움
  • 내부가 노출되어 보안이 취약함
  • API Gateway를 고려하는 이유
    • 클라이언트 앱은 일반적으로 둘 이상의 마이크로 서비스에서 제공하는 기능을 사용해야 합니다
    • 직접 실행되는 경우 클라이언트는 마이크로 서비스 엔드포인트에 대한 여러 호출을 처리해야 합니다

• API Gateway
  • 단일 진입점을 제공하는 서비스
  • 인증 및 인가 : 인증서 관리, SSL, 프로토콜 변환 등
  • 요청 절차 단순화 : 클라이언트와의 한 번의 통신으로 간소화
  • 라우팅 및 로드밸런싱 : 부하분산
  • 서비스 오케스트레이션 : 여러 마이크로서비스를 묶어 새로운 서비스를 만드는 개념
  • 서비스 디스커버리 : 마이크로서비스의 주소를 찾는 것

2. Container

• 가상머신 : Hypervisor 위에서 각각 독립적인 OS를 설치하고 사용
• 컨테이너 : 하나의 Host OS 위에서 독립적으로 프로그램처럼 실행
  • 빠른 속도와 효율성
  • 여러 개의 컨테이너를 만들어도 하나의 OS 위에서 만들기 때문에 고밀도 가능
  • 모든 컨테이너는 독자적인 실행환경을 가지고 있음, 컨테이너 실행환경을 쉽게 공유하고 이식 가능
• Docker

3. Message Queue

• 서비스와 서비스간에 '비동기 방식'을 통해 통신을 하는 형태, 비동기 메시지를 사용하는 서비스들 사이에서 데이터를 교환해 주는 역할을 하는 것
• 동기방식으로 많은 데이터 통신을 하게 되면 병목현상이 생기게괴고 서버의 성능이 저하 된다. 이러한 현상을 막고자 중간에 미들웨어에 메시지를 위임하여 순차적으로 처리하게끔 한다.
• Kafka, RabbitMQ, GCP Cloud Pub/Sub

4. MSA 무조건 좋은가? 🤔

“Don't even consider microservices unless you have a system that's too complex to manage as a monolith.”
(마틴 파울러)

모놀리식으로 관리하기에 특별히 복잡한 시스템을 운영할 상황이 아니면 마이크로서비스는 고려할 필요조차 없다

복잡도가 낮고 개발 인원이 적으면 MSA보다 모놀리식 아키텍처의 생산성이 훨씬 높다

왜냐하면...

모놀리식 장점

1. 개발이 간단하고 복잡하지 않다
2. 쉽게 고가용성 서버 환경을 만들 수 있다.
3. 테스트가 용이하다.

MSA 단점

1. 작은 여러 서비스들이 분산되어있기 때문에 모니터링이 힘들다.
2. 서로를 호출하여 전체 서비스가 이루어지기 모놀리식 아키텍쳐의 개발보다 조금 까다롭다.
3. 통신관련 오류가 잦을 수 있다.
4. 테스트가 불편하다.

제가 만들어써여

절대적으로 좋고 절대적으로 나쁜 기술은 없다

내 애플리케이션에 맞는 기술이 어떤 건지 고민하고 선택하는 건 개발자의 몫!

MSA를 이용하는게 비용, 생산, 인원 등등 많은 면을 고려해서 도입하는 것이 좋을지 잘 판단하자

 

참고문헌

• https://cloud.google.com/learn/what-is-microservices-architecture#section-1
• https://www.samsungsds.com/kr/insights/msa.html
• https://www.samsungsds.com/kr/insights/msa_and_netflix.html
• https://aws.amazon.com/ko/microservices/
• https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
• https://martinfowler.com/
• https://wooaoe.tistory.com/57
• https://velog.io/@tedigom/MSA-제대로-이해하기-1-MSA의-기본-개념-3sk28yrv0e