김동욱님의 "마이크로서비스 아키텍처 구축 가이드"를 기반으로 공부한 내용입니다.
📕 목차
1. 우리 시스템에 MSA가 적합한가?
2. 엔터프라이즈 시스템에도 어울리는가?
3. 프로젝트 일정을 어떻게 수립하는가?
4. 프로젝트 비용을 어떻게 산정하는가?
5. 서비스는 분리하고 데이터베이스만 열어주면 안 되는가?
6. 데이터베이스는 어디까지 분리해야 충분한가?
7. 도메인 주도 설계를 배워야 하는가?
8. 우리 시스템은 왜 MSA를 도입했는가?
9. 우리 시스템은 MSA가 맞는가?
1. 우리 시스템에 MSA가 적합한가?
"아키텍처 스타일이 시스템에 적합하다"는 "다른 아키텍처 스타일 보다 시스템의 중요한 비기능 요구 사항을 잘 달성할 수 있다"는 의미다.
마이크로서비스 아키텍처의 3가지 장점으로 시스템의 비기능 요구 사항을 잘 만족시킬 수 있는지 따져보라
- 변경 리드 타임을 개선할 수 있다. → MSA를 도입하는 가장 보편적 이유
- 업무 단위로 장애 영향 차단 → 모놀리식으로도 상당 부분 달성 가능하므로 차이점 구별 필요
- 업무 단위로 시스템 확장 가능
시스템 담당자는 시스템의 딜리버리 퍼포먼스 수준을 인지하고 개선할 수 있는 방법을 이해할 수 있어야 한다.
단순히 젠킨스, 앤서블, 테라폼과 같은 자동화 툴을 도입하는 것으로 만족하지 마라.
2. 엔터프라이즈 시스템에도 어울리는가?
✒️ 엔터프라이즈 시스템 : 기업이나 정부 기관 등의 비지니스를 돕기 위한 IT 시스템
엔터프라이즈 시스템에는 과연 MSA가 어울리지 않을까?
- 엔터프라이즈 시스템은 모든 것을 계획하여 진행한다.
- 직접적으로 경쟁 관계인 시스템이 없다.
- 대상 사용자가 정해져 있고 상대적으로 사용 인원이 적다.
- 도메인이 다양하게 세분화되고, 도메인에 따라 시스템이 만들어진다.
이러한 엔터프라이즈 기업 특징으로 인해, MSA 적용이 불필요하다고 느낄 수 있으나 그렇지 않다.
📌 내부에서는 항상 변경 리드 타임을 중요시하고, 시스템 중요 지표로써 관리하고 있다.
- 기업 내부 시스템을 비교해보면 유독 변경 리드 타임이 저하된 시스템을 찾을 수 있다.
- 규모가 큰 기업이라면 MSA를 도입하여 변경 리드 타임을 단축할 시스템을 어렵지 않게 찾을 수 있다.
- 최근 엔터프라이즈 시스템도 클라우드 인프라 전환하는 사례가 늘고 있다.
3. 프로젝트 일정을 어떻게 수립하는가?
MSA를 적용한다고 프로젝트 진행 방식이 크게 바뀌지는 않으나, 일부 태스크에 차이점이 있다.
- 신규 태스크는 도입 목표를 정하고 서비스 목록을 정하는 것이다. (다른 태스크 입력값이 된다.)
- 기존 태스크도 부분적으로 변경된다.
📌 도입 목표 및 서비스 선정
💡 MSA를 도입할 때는 목표를 명확하게 정의하고 서비스를 선정하라.
- 목표는 시스템 전반적인 방향을 제시한다.
- 시스템을 구성하는 서비스 목록을 선정하고 서비스 간의 관계를 도출하는 과정은 다른 작업의 기준이 되므로 가능한 한 초기에 정해라.
- 이후에도 충분히 바꿀 수 있으므로 부담을 가지지 않아도 된다.
📌 개발팀 구성
💡 개발팀은 앞서 선정한 서비스를 전담할 수 있도록 구성하라.
- 하나의 서비스는 하나의 개발팀이 담당하는 것을 원칙으로 한다.
- 모든 기준은 운영팀이다.
- 독립적인 개발팀이 주체적으로 기술 스택이나 표준을 정하는 경우가 많은데, 운영팀이 감당할 수 없는 기술 스택을 선정하기도 한다.
- 아웃소싱하는 경우, 프로젝트 팀이 시스템을 개발하고 운영팀에 인계하고 철수한다면 운영팀 의견을 반영하라.
- 아키텍처, 프로세스, 개발 문화 변경 등 여러모로 운영팀이 프로젝트에 많이 참여하는 게 좋다.
📌 소프트웨어 미들웨어 설계
💡 도입 목표와 서비스 목록은 소프트웨어 미들웨어를 설계하는 기준이 된다.
- 서비스와 개발 방식에 따라 API 게이트웨이나 서비스 레지스트리/디스커버리를 제공하는 미들웨어 또는 인프라 구축이 필요할 수도 있다.
- 서비스 간에 인터페이스가 많다면 이벤트 통신을 위한 메시지 큐(message queue)나 서비스 메시(service mesh)같은 클라이언트 사이드 라우팅 기술이 필요할 수도 있다.
- 추가적으로 또 필요한 미들웨어가 확인되면, 설계하고 구축하는 세부 태스크 정의를 해야 한다.
📌 하드웨어 인프라 설계
💡 서비스와 미들웨어 구성이 결정되면 필요한 하드웨어 구성과 용량을 결정할 수 있다. 이에 따라 필요한 컴퓨팅 자원과 네트워크 자원을 설계하고 구축하는 태스크를 계획해야 한다.
- 퍼블릭 클라우드 같이 필요에 따라 하드웨어 증설이 가능한 환경이면 복잡한 인프라 사이징 없이 최소 구성으로 시작할 수도 있다.
📌 PoC (Proof of Concept)
💡 검증이 필요한 새로운 기술 요소가 있다면 PoC를 수행할 수 있다.
- 개발팀이 API 중심 아키텍처에 미숙하다면 PoC를 수행하여 동작하는 샘플을 확보하는 것이 좋다.
- 공통 기능을 제공하는 서비스는 정식으로 미리 개발을 시작하는 것이 좋다.
- 실제로 동작하는 시스템이 있으면 개발자가 이해하는 데 큰 도움이 된다.
- 스케일 아웃이나 장애 격리가 시스템의 중요한 목표라면 사전에 PoC를 수행하는 것이 좋다.
- 프로젝트 기획하고 실행하는 프로세스에서 태스크 수행 시점을 보여준다.
- 시스템 개발은 기간이 길고 큰 비용이 투입된다. 기획 단계부터 꼼꼼하게 수립한다.
- 비용과 일정은 MSA 도입 목표, 서비스 목록 등에 영향을 받으므로 기획 단계에서 상당 부분 확정해야 한다.
- 프로젝트 중에도 소프트웨어 미들웨어와 하드웨어 인프라 설꼐를 수행하지만, 이는 보통 기획 단계에서 정의한 아키텍처 구체화 작업에 해당한다.
4. 프로젝트 비용을 어떻게 산정하는가?
3. MSA 구현을 위한 핵심 프레임워크를 알아보자 2
지난 장에서는 Spring Cloud의 개요와 서비스 디스커버리, 클라이언트측 부하 분산을 알아보았습니다. 이번장에서는 API Gateway, 장애 전파방지와 복구, Config Server와 관련된 라이브러리를 알아봄으로
enjoy-dev.tistory.com
참고 사진이 필요해서 검색하다 찾은 블로근데 설명 엄청 잘 해주시고 계신다..
- MSA 도입으로 영향을 받는 것은 소프트웨어/하드웨어 비용과 소프트웨어 개발 비용에 해당한다.
- SW/HW 비용은 서비스 도출 후, 아키텍처가 결정되면 산정할 수 있다.
- 소프트웨어 개발 비용은 딱히 획일화된 계산 방법이 없다.
- 개발 난이도가 높아지거나 신규 개발이 필요한 부분을 식별하는 것으로 MSA 소프트웨어 개발 비용을 산정할 수 있다.
- 위 이미지에서 개발 난이도가 상승하는 영역은 각각의 SPA로 통하는 Portal 화면 조합과 서비스 간 API 호출, 이벤트 스트림으로 향하는 이벤트 호출 영역에 해당한다. (네트워크 통신)
- 모놀리식 아키텍처 구현 비용에 다른 서비스 연계 코드 개발 난이도를 반영하는 것으로 산정할 수 있다.
- 이 외에도 런타임 분리 구조로 인한 사용자 인증, 인가, 통합 로깅이나 참여 인력 러닝 커브 등 비용에 반영할 수도 있다.
5. 서비스는 분리하고 데이터베이스만 열어주면 안 되는가?
- 현장에서 MSA 적용 시 가장 어려워하는 것 중 하나가 서비스별 데이터베이스 분리이다.
- PM은 리스크 헤징(risk hedging) 과정에서 데이터베이스만 공유하는 경우를 떠올린다.
- 서비스 간에 조인을 허용하면, 여러 서비스 코드가 복잡하게 얽힌다.
- 코드를 변경하고 싶어도 다른 서비스에서 참조하지 않는다는 확신을 가질 수 없게 된다.
- 소스 코드가 모두 분리되어있으므로, 모놀리식보다 찾기도 어려워진다.
- 결과적으로 모놀리식과 마이크로서비스의 단점만을 모아놓은 괴물이 탄생하게 된다....
- MSA에서 서비스별 데이터베이스 분리는 피할 수 없다.
- 서비스 개수를 줄이는 것이 구현 부담을 줄일 수 있는 방법이다. (이후 점진적으로 세분화하라)
- 아주 예외적인 구체적 사유가 있다면, 엄격한 관리하에 다른 서비스 데이터베이스 액세스를 허용할 수도 있다.
6. 데이터베이스는 어디까지 분리해야 충분한가?
- 비지니스 민첩성 관점에서는 서비스 데이터베이스가 논리적으로만 차단되면 충분하다. (스키마 단위)
- 즉, 서비스가 다른 서비스 데이터베이스를 직접 참조하지 못하고 제한된 api나 이벤트만 참조하게 하는 것으로 충족될 수 있다.
- 서비스 간 장애 영향 차단 및 확장이 중요하다면 DB Server를 분리해야 할 수도 있다.
7. 도메인 주도 설계를 배워야 하는가?
- 직접적인 연관은 없다. DDD는 MSA 구축 방법 중 하나일 뿐이다.
- DDD의 bounded context는 독립적으로 모델링하는 단위이지, 독립적으로 배포하고 실행하는 서비스 단위가 아니다.
- bounded context에 따라 서비스를 세분화하면 오히려 너무 많아서 유지/보수가 힘들 수도 있다.
- 간혹 도메인 주도 설계의 전술적 설계 요소를 활용해야 한다고 생각하는 경우가 있다.
- DDD는 그 자체만으로도 너무 심오하다. DDD와 MSA를 같이 공부해서 적용하려고 하면, 시작도 못하고 좌초해버릴 수도 있다.
💡 중요한 것은 어떤 방법론으로 서비스를 나누고 개발하는가가 아니라, 어떤 상태가 되도록 서비스를 나누는가이다.
8. 우리 시스템은 왜 MSA를 도입했는가?
- 이런 질문의 원인은 MSA를 도입할 때 구체적 목표를 정하지 않았기 때문이다.
- 얻고자 하는 이익을 명확히 기술했다면 무리한 도입을 사전에 차단했을 수도 있다.
- 시스템 구조만 변경하는 것이 아니라 적절한 조직과 프로세스도 도입되었을 수도 있다.
- 구체적 목표가 없다면 이후 어떤 기준으로 서비스를 도출할 지도 판단할 수가 없다.
- 또한 기술 관점 의사 결정을 적절히 내릴 수가 없다.
- MSA를 어떤 식으로 적용할지 판단해야 하는데, 목적이 없으므로 파악조차 불가능
9. 우리 시스템은 MSA가 맞는가?
- 서비스가 업무 단위로 구성되어야 한다.
- 동일한 구성이지만 독립적 배포가 불가능하면 제대로된 MSA가 아니다.
- 각 서비스는 코드부터 db까지 분리되어야 하며, 운영계에 독립적 배포가 가능해야 한다.
- 서비스 단위 독립적 배포가 가능해도, 요구사항 접수에서 배포까지 시스템 단위 공통 조직에서 통합 관리하고 있다면 본래 목적을 살리지 못하고 있는 것이다.
MSA를 판단하는 데 시스템 구조가 구성 요소가 유사한지는 고려하지 않아도 된다.
클라우드 네이티브 애플리케이션이라 부를 수는 있지만 마이크로서비스 아키텍처라고 하기에는 적합하지 않은 경우도 있다.
왜냐하면, 결국 업무 기능에 따라 서비스를 분할하고, 개별 팀이 서비스를 전담하여 독립적 개발 및 배포를 위한 서비스 코드와 DB 분할을 강요하지 않기 때문이다.
마이크로서비스 아키텍처는 거대한 인터넷 규모 시스템이 늘어나면서 보다 나중에 생긴 아키텍처 스타일이라 봐야 한다.