[MSA] 마이크로 서비스 아키텍처, 설계 전략, 사례

지난 번에 마이크로 서비스 아키텍처(MSA, Micro Service Architecture)가 무엇인지 정의를 정리 해봤습니다.

이번엔 MSA를 활용할 수 있는 전략에 대해 정리 해보려 합니다.
MSA 기반으로 설계하는 이유는 운영을 잘 하기 위해서 라고 생각합니다.
구체적으로 장애에 치명적인 타격을 예방하고, 확장의 유연성을 고려하며, 운영하는데 인력을 효과적으로 분배하기 위함 이라 생각합니다.

이렇게 하려면 어떤 식으로 MSA를 구상해야 할지 한번 고민해보려 합니다.
특히 대규모 서비스를 담당하는데 모노리틱 보단 MSA 기반 설계가 유리했습니다.
대규모 서비스를 제공하는 기업에선 MSA를 어떤 서비스에 적용했는지 AI로 확인해습니다.

1. Amazon:
   • Amazon은 수많은 마이크로 서비스를 사용하여 규모가 큰 e-commerce 플랫폼을 구축했습니다.
   • 주문 처리, 배송 추적, 상품 검색, 고객 리뷰 등 각각의 기능은 독립적인 서비스로 구현되었습니다.
2. Netflix:
   • Netflix는 영상 스트리밍 서비스를 제공하는데, 이를 마이크로 서비스로 구현했습니다.
   • 사용자 관리 서비스, 콘텐츠 관리 서비스, 비디오 스트리밍 서비스 등이 독립적으로 실행됩니다.
3. Uber:
   • Uber는 탑승 고객, 운전자, 지불 처리, 위치 추적 등 다양한 기능을 마이크로 서비스로 분리했습니다.
   • 각 서비스는 독립적으로 확장 가능하며, 전체 시스템이 안정적으로 동작합니다.
4. Etsy:
   • Etsy는 공예품과 수공예품을 판매하는 온라인 마켓플레이스입니다.
   • 마이크로 서비스 아키텍처를 사용하여 상품 관리, 주문 처리, 결제 처리, 검색 기능 등을 분리했습니다.

위의 기업들은 마이크로 서비스를 적용하여 더 빠르게 개발하고 유지보수할 수 있으며, 각 서비스를 독립적으로 확장하고 관리한다고 합니다.

정리해보면, 서비스 단위로 컴포넌트를 나눈 것으로 보입니다.
상세한 기능 단위 보단, 도메인 로직 기준의 서비스 단위로 말입니다.
특히 나눈 서비스 기준을 보면 독립적으로 열어볼 수 있는 단위의 서비스 같습니다.
독립적으로 구현되는(X) 것과는 다른, 독립적으로 서비스 가능한 단위 로 나눈 것 으로 보입니다.

아키텍처를 설계하는데 있어 서비스 단위로 컴포넌트를 구성하고, 프론트 서버에서 동적으로 서비스를 만들어 제공하는데
각각 서비스를 담당하는 백엔드 서버나 CDN 으로 요청하여 값을 불러와 웹에 뿌려주는 식이 되는 것 같습니다.
특히 백이나 프론트가 분리 되는 부분이 기본이 되기도 하는 것 같습니다.
예전엔 이해가 잘 안됬었는데, 지금은 프론트 개발자와 백엔드 개발자가 나뉜 이유도 어느정도 이해가 가네요.

---

그러면 위 업체들 처럼 특정 서비스를 기준으로 컴포넌트를 구분하여 배포하는 식의 아키텍처를 구성한 것으로 확이했는데, 이를 위한 구분 기준이 무엇이 있을까요?
이를 위해 마이크로 서비스를 설계하는데 고려해야 할 사항을 알아 보려 합니다.

다음은 마이크로서비스를 설계하기 전 고려해야 할 주요 내용입니다:

• 개발자가 사업 영역별 기능에 대해 명확히 이해하고 있는가
• 각각의 서비스가 정말로 오직 하나의 서비스에만 집중하고 있는가
• 각각의 서비스가 독립적으로 배포 가능한가
• 각각의 서비스는 스테이트리스 서버(HTTP 웹서버 등)로 통신 가능한가
• 각각의 서비스는 추후 더 작은 서비스로 리펙토링 가능한가

마이크로서비스 설계 시 고려할 사항을 하나씩 작성해가며, 서비스를 나눌 기준을 정의해 보는게 좋을 것 같습니다.
위의 모든 사항을 만족할 수는 없겠지만, 기준점이 될 것 같습니다.
구체적으로 더 분할하여 리펙토링 가능한요소가 있는지, 어디까지 묶어서 컴포넌트 단위로 할지 가 핵심이며
서비스 단위를 그렇게까지 세부적으로 구분 할 필요가 있는지, 독립적으로 배포 해야 하는지, 세세하게 서비스 대로 컴포넌트를 나눠 오히려 비즈니스 구조가 복잡해지고 통신 비용이 늘어 속도가 지연되는 것은 아닌지 고려해 봐야 합니다.

고려해야 할 내용을 기반으로 서비스를 정의하고 분리하는 게 필요합니다.
그럼 이들이 정상적으로 서비스 될 수 있도록 MSA를 구성하는데 필요한 요소들을 정의 해보겠습니다.
해깔릴 수도 있을 것 같아 추가적으로 적어보면, 기존 모노리틱 아키텍처 대신 MSA 로 설계하려면
MSA기반으로 서비스가 정상적으로 작동하기 위한 구성요소가 필요합니다.

모노리틱 아키텍처의 가장 큰 장점인 "다른 어플리케이션과 연동 없이 단독적으로 수행도 가능한 부분"과 비교 되는 부분이기도 합니다.
특히 단일 서비스 단위로 컴포넌트가 나뉘었기 때문에, 각각 통신을 통해 어플리케이션 서비스를 제공하려면 MSA에서 구성요소는 반드시 필요합니다.
모노리틱 아키텍처 에서도 구성요소가 들어갈 수 있으나, MSA에선 필요한 구성요소가 훨씬 많습니다.
나열해 보겠습니다.

마이크로 서비스 아키텍처의 구성요소

마이크로 서비스 아키텍처 구성요소

※ 위 사진은 절대적인 기준이 아닌 예시이며, 더 다양한 구성요소가 들어갈 수 있습니다.
기술은 계속 발전하고 있으니까요. (예를 들어 로드밸런서나 방화벽이나 라우터나 네임서버 등등 상황에 따라 추가되는 구성 요소도 있습니다. AutoScaling을 쓰는 곳은 IP를 고정으로 줄 수 없어 도메인 네임을 설정 해야만 하는 경우도 있습니다.)

1. 클라이언트

다양한 클라이언트에서 아키텍처로 조회, 생성, 삭제 등 다양한 수행을 요청합니다.
내부 마이크로서비스도 클라이언트가 될 수 있습니다.

2. 인증 ID 제공자

클라이언트의 다양한 요청은 인증 ID 제공자(Google, Facebook, 자체 ID/PW, Token 등)에 의해 요청에 대한 권한이 있는지 확인됩니다.
권한이 확인되면 요청은 API 게이트웨이로 넘어갑니다.

3. API 게이트웨이

클라이언트는 서비스에 직접 요청하지 않고, API 게이트웨에 요청을 보냅니다.
해당 요청에 대해 적절한 서비스로 전달하는 진입점 역할을 하게 됩니다.

API 게이트웨이를 사용하게 되면 다음과 같은 장점이 있습니다:
- 클라이언트가 업데이트로 인한 불편함(업데이트로 인한 서비스 중단, 이전 버전 클라이언트 사용 불가 등)을 격지 않고 배포가 가능하게 할 수 있습니다.
- 클라이언트에게 단일 진입점을 제공하게 되므로, 불필요한 서비스의 정보를 노출시키지 않아도 됩니다.
- 서비스 간에 통신이 필요한 경우 직접 통신을 할 수도 있지만, 규모가 커진다면 API Gateway를 통해서 통신하는게 모니터링이나 신뢰성 측면에서 유리해집니다.
- 로드밸런서와 기능이 비슷하나 목적이 다릅니다.
  로드밸런서는 부하 분산이 주 목적, API 게이트웨이는 알맞는 서비스로 라우팅이 주 목적 입니다. (API게이트웨이와 로드밸런서를 같이 쓰기도 합니다.)

 

백엔드 서비스에 대한 API 트래픽을 수락, 변환, 라우팅 및 관리하는 중개자 역할을 하는 서비스, 장치 또는 프록시 입니다.

4. 메시지 포맷

마이크로서비스가 상호 간 통신할 때 사용하는 메시지는 다음의 2가지 타입이 있습니다:
- 동기 메시지: 주로 클라이언트가 서비스로부터 응답을 기다릴 경우 마이크로서비스는
   REST(Representational State Transfer) 방식을 사용해 스테이트리스 HTTP 프로토콜로 응답합니다.
- 비동기 메시지: 클라이언트가 서비스로부터 응답을 기다리지 않을 경우 마이크로서비스는
   Queue(AMQP, STOMP, MQTT 등) 방식을 사용하며 주로 내부 서비스 간 통신에 쓰입니다.

5. 데이터베이스

각각의 마이크로서비스는 사업 영역에 맞게 데이터베이스를 가지고 있습니다.
또한 각각의 데이터베이스에 다른 서비스가 직접 접근 한다면, 동시성 문제가 생길 수 있습니다.
이를 방지하기 위해, 별도로 DB를 설계하는 방식을 알아야 하는데, 
서비스 마다 DB를 가지게끔 설계할 수도 있고, 도메인 별로 DB를 만들어 여러 서비스에서 공유하도록 설계할 수도 있습니다.

이처럼 데이터 동기화에 대한 DB 부분은 내용이 길다보니 별도로 정리하겠습니다.

6. 정적 콘텐츠

마이크로서비스가 요청 처리를 끝낸 후 정적 콘텐츠(HTML 페이지 등)를 CDN(Content Delivery Networks)에 배포하거나, 서비스에서 클라우드 스토리지에 있는 파일을 직접 접근할 수 있는 링크가 필요합니다.
서비스에서 링크로 접근하여 처리의 결과물을 저장하거나, 중간과정을 기록하거나, 로깅을 작성하거나 같은 작업을 할 수 있습니다.

7. 서비스 관리

서비스 간(혹은 서비스 노드 간) 연동으로 작업을 하거나, 서비스에서 오류 발생, 인증에 실패할 경우의 처리를 담당합니다.
클라이언트에 응답을 보내는 것과 별개로 내부적으로 롤백시 다중 트랜잭션을 처리하는데 도움을 줍니다.

8. 서비스 찾기

마이크로서비스 끼리 통신할 때, API gateway 말고 별개로 서비스를 찾아주는 역할을 합니다.
필요한지는 검토후 구성요소로 추가하는게 좋아보입니다.

더 많은 구성요소가 있을 수 있으나 제가 아는 선까지 정리했으며, 찾으면 업데이트 해보겠습니다.
이런 구성요소들을 기반으로 MSA가 이루어 집니다.

구성요소를 정리하니 실제로 서비스를 운영하는데 있어 서비스를 어떤 기준으로 얼마나 분리해야 할지
조금은 감이 잡히기도 합니다.
분리된 기준으로 아키텍처를 따라 운영 될테니까요.

DDD라는게 있는데, 도메인 주도 설계 라는 용어로 MSA를 쓰려면 알아두면 좋은 개념 이라고 합니다.
여기에 대해서는 조금 더 정리해보려 하는데, 다른 포스트에서 이어가겠습니다.
여기선 MSA를 사용하는 사례와 구분기준을 어떻게 나눌 지 고려해야 할 부분, MSA의 구성요소에 대해 정리 해봤습니다.

 

참조한 블로그

https://medium.com/wematch/%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%98-msa-359b7973ba79

마이크로서비스 아키텍처 (MSA)