[요저개 1편] 마이크로서비스 아키텍처(MSA)

👋🏻  Introduction

요저개는 요것저것 개발 지식 쌓기의 준말입니다.

요즘 핫하거나 중요한 키워드에 대해 하나씩 정리해보고 실제 적용 사례도 살펴보려 합니다.

오늘은 요저개 1편으로 마이크로서비스 아키텍처에 대해 정리해보려고 합니다!

 

오늘의 내용은 아래 순서로 정리해보고자 합니다.

 

1. 마이크로서비스 아키텍처에 대해 알아보기

2. 마이크로서비스 아키텍처를 실제로 적용한 기술 블로그 읽어보기.

 

---

 

🤔 MSA란 무엇인가?

MSA란 마이크로서비스 아키텍처의 약자로 단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법을 말합니다.

MSA는 복잡한 웹 시스템에 맟춰 개발된 API 기반의 서비스 지향적 아키텍처 스타일입니다.

MSA는 서비스의 재사용성, 유연한 아키텍처 구조, 대용량 웹 서비스에 적합한 구조의 서비스를 위한 아키텍처입니다.

 

 

• API를 통해 통신하기 때문에 실질적인 세부 사항은 모두 추상화하고 서비스의 접근점을 API 형태로 외부에 노출하는 형태입니다.
• 제대로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰서 만들어지므로 하나의 기능만 수행하게 됩니다.
• 어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 다양한 언어와 기술로 구축이 가능합니다.
• 마이크로서비스의 공통적인 특징 중 하나는 REST와 같은 가벼운 통신 아키텍처 또는 Kafka 등을 이용한 메세지 스트림을 이용한다는 점입니다.
• 마이크로 서비스는 설계가 어렵습니다. 서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템 통신을 어떻게 가져가야 할 지, 통신의 장애와 서버의 부하가 있을 경우 어떻게 트랜잭션을 유지할 지 결정하고 구현해야 합니다.

 

<온라인 쇼핑몰에서 MSA 적용 예시> - 출처:&nbsp;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/

 

위 그림에서 볼 수 있듯이, 회원, 상품, 주문 등 각 컴포넌트가 각각의 서비스로 구현되고 API를 통해 타 서비스와 통신하게 됩니다.

각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기에 독립 배포가 가능해집니다. 그리고 각 서버에 있기 때문에 부분적인 확장도 가능해집니다. 만약, 주문 서비스에 트래픽이 늘어난다면, 회원이나 상품 서비스는 신경을 쓰지 않아도 되고 주문 서비스 관련 서버만 확장하면 되겠죠?

 

MSA는 다음과 같은 특징을 가지고 있습니다.

 

1. 데이터 분리

데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않아도 되고, 서비스별 별도의 DB를 사용합니다.

DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 됩니다.

데이터가 분산되어 있기 때문에 다른 서비스 컴포넌트에 대한 의존성 없이 서비스를 독립적으로 개발 및 배포 운영 할 수 있지만,

다른 컴포넌트의 데이터를 API 통신을 통해 가져와야 하기 때문에 성능 상의 문제가 발생할 수 있고, 트랜잭션으로 묶을 수 없는 문제가 발생하기도 합니다.

 

2. API Gateway 

MSA의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어 있기 때문에 서버 URL이 각기 다를 수 밖에 없습니다.

이때 API Gateway는 API서버 앞 단에서 모든 API 서버들의 End-Point(접근점)를 단일화하여 묶어주는 역할을 합니다.

또한, 거미줄처럼 복잡한 서비스간의 API 호출 구조도 단순화 시킵니다. 그외에도 라우팅, 로드밸런싱, 인증 역할등을 수행합니다.

 

api-gateway 관련 내용: https://www.tibco.com/ko/reference-center/what-is-an-api-gateway

API 게이트웨이란 무엇입니까?

 

🤔 MSA 말고 전통적인 방식인 Monolithic Architecture!

기존에 주로 사용되는 개발 아키텍처는 모노리틱 아키텍처 입니다.

 

<온라인 쇼핑몰 Monolithic Architecture 예시> 출처 -&nbsp;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/

 

전체 어플리케이션이 하나로 되어있으며, 보통 동일한 개발 툴로 개발되고 배포 및 테스트도 하나의 어플리케이션만 수행하면 되기 때문에 개발 및 환경 설정이 간단합니다. 

또한, 각 컴포넌트들이 함수로 호출되기 때문에 성능 제약이 덜하고 운영 관리가 용이합니다.

이러한 특징으로 작은 볼륨의 시스템 개발에는 매우 유용하지만, 시스템이 커지면서 여러 컴포넌트가 더해지고 문제가 발생하기 시작합니다.

 

<문제점>

 

1. 빌드/테스트 시간이 길어짐.

2. Scale Out이 불가.

- 이벤트 서비스에 트래픽이 많이 와서 서버를 확장하고 싶다면 전체 서버를 확장해야 함.

3. 하나의 서비스가 모든 서비스에 영향을 준다.

-이벤트 서비스에 트래픽이 많이 와서 서버가 다운되면다면, 전체 기능이 마비.

 

 

---

🧐 실제 적용 사례  - 카카오톡 이모티콘 서비스는 왜 MSA를 선택했나? 

https://tech.kakao.com/2021/09/14/msa/

이모티콘 서비스는 왜 MSA를 선택했나?

위 기술 블로그에 정리된 내용은 집을 지는 것과 비유해 재미있게 정리되어 있습니다.

 

1. 현장조사

2. 설계

3. 시공

4. 감리

 

한 단계식 정리해보도록 하겠습니다.

 

✔️ 현장조사

 

현재 카카오톡의 이모티콘 시스템은 크게 4가지 서비스로 구성되어 있다고 합니다.

1. 이모티콘 서비스 2. 이모티콘 스튜디오 서비스 3. 이모티콘 서비스 admin 4. 이모티콘 스튜디오 서비스 admin

 

이 중 1번 이모티콘 서비스는 오래되었고 성숙한 서비스라고 합니다. 그렇기에 많은 기술 부채가 적재되어 있었다고 합니다. 이를 위해 유지보수가 주요 관심사가 되었다고 합니다.

 

이를 위해 현재 팀이 마주하고 있는 이슈를 크게 운영적 관점과 기술적 관점으로 나누어 보셨다고 합니다.

 

운영 이슈

• 배포
• 코드 버전 관리의 높은 복잡도 (여러 개의 브랜치 생성으로 merge시 이슈 발생)
• 메인 DB에서의 트래픽 증가

 

기술 이슈

• 서비스 거대화로 인한 설계의 어려움 (신기술 적용 어려움, coupling 증가)
• 버전 호환 불가와 같은 문제점

 

이 같은 문제들을 해결하고자 하셨고, 배포 단위를 줄이고 담당 영역 분산 그리고 기술 적용에 자유도를 높여 다양한 기술을 사용하고자 하는 것이 목표라고 합니다.

 

✔️설계

 

이 같은 문제를 해결하기 위해 채택한 방식이 MSA라고 합니다.

 

MSA를 활용해 얻을 수 있는 장점으로는

 

운영 측면

• 작아지는 배포 단위
• 배포 영향 범위 축소
• 독립적 배포 버전 관리
• 덜 복잡해지는 브랜치

기술 측면

• 서비스가 작아져 역할 명확해짐, 디버깅 포인트 고립
• 설계 변경에 대한 부담이 낮아짐.
• 각 서비스별 최적 기술 선택 가능.

 

해당 카카오 기술 블로그 내용에는 왜 MSA가 핫해졌는지 이유에 대한 의견도 작성되어 있습니다.

그 이유로 클라우드 환경 보편화가 있다고 합니다.

클라우드 환경이 보편화 되며 물리적 이슈가 해결되었고 MSA와 Cloud 인프라 환경이 서로의 장점을 크로스하고 있기 때문이라고 합니다.

MSA와 클라우드는 찰떡궁합 - 출처:&nbsp;https://tech.kakao.com/2021/09/14/msa/

 

MSA를 적용하며 걱정되는 부분도 있었다고 합니다.

 

기술 측면

• 함수 호출이 Network I/O 호출로 바뀌게 된다. (서비스간 상태 동기화가 어려워진다.)
• DB 분리 시에 Join이 어려워진다.

서비스 간 네트워크 호출이 추가되어 네트워크 오류에 대한 고민들이 추가되고, DB도 분리하게 되면서 편하게 join할 수 있었던 것들이 그러지 못하게 되어 성능이나 설계 상 손해를 보는 점도 존재..

 

운영 측면

• 관리해야할 서비스가 늘어남

 

>>결론>>

MSA 구현을 위해 클라우드 환경을 지원하는 쿠버네티스를 선택하였다고 합니다. 그리고 개발 프레임워크는 Spring으로 선택하였다고 합니다. 

해당 선택은 팀원 간의 기술 관심사와 상황을 고려하여 선택되었다고 합니다.

 

 

✔️시공

 

MSA 적용을 위해 해야할 일

• 서비스 배포 환경 통합 및 리소스 설정 간단화
• 서비스 간 연결 관계와 모니터링 쉽게 하기
• 서비스 나누기

 

서비스 배포 환경 통합 및 리소스 설정 간단화

 

MSA 적용을 위해 쿠버네티스를 활용하였고 yaml을 관리하기 위해 kustomize를 활용하였다고 합니다.

kustomize는 yaml 설정을 디렉토리를 이용해서 구조화하고 각 설정을 재사용할 수 있게 되어 있어 설정의 관리가 간편해집니다. 

이후 더 편한 사용을 위해 argoCD를 활용하였다고 합니다. argoCD는 WebUI를 제공하고 github 저장소와 연동이 가능하다고 합니다. 

 

서비스 간 연결 관계와 모니터링 쉽게 하기

 

Istio는 쿠버네티스에 올려진 서비스들 간의 연결 구조를 볼 수 있는 서비스 매쉬 계층을 두고 그것을 관리할 수 있는 기능을 제공합니다.

VirualService, ServiceEntry, Proxy등 다양한 기능을 제공하여 연결 관리를 좀 더 유연하게 하고 이스티오에서 제공하는 메쉬 걸정 정보들을 통해 서비스 상태나 연결 흐름을 kiali를 설치해 눈으로 확인가능하다고 합니다.

 

서비스를 나누기

 

api gateway를 기존 레거시 앞에 두어 기존 서버를 하나씩 분리해가는 방법을 선택하였다고 합니다.

서비스 분리 시에도 path 기준으로 하나씩 라우팅 전환하며 분리하였다고 합니다.

api gateway로 spring cloud gateway를 선택하였다고 합니다.

 

 

MSA 단위 정의

 

마이크로서비스의 기준이 무엇인가에 대한 논의로 이모티콘 팀은 아래와 같은 기준을 선택했다고 합니다.

 

• 기능 목적이 2개 이상 되지 않아야 함.
• 여러 기능에서 사용하는 단위 리소스의 경우 서비스로 분리하여 공동 사용.
• 사내 통제 대상인 admin의 경우, 최소한으로 통제 클러스터에 넣도록 서비스를 분리.
• 개인 정보 대상으로 분류된 데이터를 관리하는 서비스는 해당 데이터 관리에 필요한 기능을 최소화하여 분리.
• 서버 렌더링을 배제하기 위해 front와 backend 서비스는 서로 분리.

이 같이 MSA 단위에 대한 정의가 되어야 지 제대로된 MSA 서비스를 만들 수 있다고 합니다.

 

✔️감리

 

장점

• 업무 분담이 명확
• 배포 부담 축소
• 신규 서비스 추가 용이

 

단점

• 설계 제약 사항과 고민이 증가.
  • 트랜잭션 이슈 및 서비스간 동기화 문제, 설계 시 DB가 분리되는 것을 고려해서 서비스 구현
• 개인 담당 서비스 증가
• 도메인 지식 공유 어려움

 

그래서 MSA가 답인가?

 

꼭 그렇지만은 않다! 결국 현장 조사를 명확히 해봐라!!

 

현장 조사를 통해 문제 확인 후,

• 팀의 서비스 하나에 너무 많은 사람이 같이 붙어 관리가 어려워 나누고 싶거나
• 기술 부채가 누적되어 일부를 조금씩 뜯어 고치고 싶거나
• 서비스 모듈 간 기술 스택의 자유도를 부여하고 싶다면

MSA 도입을 추천한다고 합니다.

 

---

제가 정리한 내용은 위 링크의 카카오 기술 블로그를 읽으며 간단히 정리한 내용입니다.

더 구체적인 내용은 기술 블로그를 확인하세요!😃