실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기(1) - MSA 개념
해당 글은 인프런에서의 실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 강의를 보고 간략하게나마 정리한 글입니다.
실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 - 인프런 | 강의
클라우드 분야에서 가장 Hot한 키워드인 Microservice Architecture (MSA)의 전반적인 배경, 다양한 아키텍처 패턴,애플리케이션 유형 , 레거시 전환방법 등을 현장의 목소리로 전달합니다., 클라우드 인
www.inflearn.com
1. 마이크로서비스의 정의
1-1. 모노리스 시스템
- 애플리케이션이 한 덩어리(서버)로 구성.
- 단일 프로세스 실행.
- 전체 수정, 배포가 되어야 함.(간단한 수정 1건 이어도, 전체 테스트가 필요하고 배포가 이루어져야 함.)
- 하나가 실패하면 전체가 실패됨을 의미.
- 모노리스 형태의 인프라를 구축 시에 스케일 아웃(확장)의 대상은 모노리스(서버) 전체가 된다.
- 스케일 아웃 시 확장성, 탄력성이 보장이 가능하나 비용 효율적이지 않음.
1-2. 마이크로서비스 시스템
- 각 서비스는 독립적인 기능을 제공.
- 서비스가 사용하는 저장소는 다른 서비스와 완전히 격리됨.
- 독립적으로 수정이 가능하게 되며 별도 배포, 확장이 가능.
- 하나의 서비스가 실패해도 전체 실패가 아니라 부분적인 실패를 의미.
1-3. 마이크로서비스 개념 정의
- 각각의 서비스는 개별 프로세스로 실행되고, Restful API 처럼 가벼운 수단을 사용해서 통신.
- Polyglot(폴리그럿)이 한 서비스 단위를 의미하고, 각 폴리그럿은 각각 다른 언어와 다른 DB를 사용할 수 있다.
폴리글랏(polyglot)은 여러 언어를 구사하는 것을 말한다. 즉, 폴리글랏 프로그래밍은 ‘패러다임을 달리 하는 여러 개발 언어를 자유롭게 구사하는 것’이라고 할 수 있다.
2. 마이크로서비스 성공을 위한 조건
- 서비스에 클라우드를 적용 시 가장 이상적인 어플리케이션 유형은 마이크로서비스 이다.
- 마이크로서비스를 통해 비지니스 민첩성을 높이기 위해서는 기술 아키텍처 변화에 국한되지 않은 개발프로세스,조직,개발 문화의 동반 적인 변화가 필요함.(그렇기에 마이크로서비스를 적용하는 것은 쉽지 않다.)
2-1. 조직
- 자율적이고 독립적인 팀 하나하나가 독립적인 서비스를 개발하고 운영함.
- 이러한 경우 각 서비스는 타 서비스와의 의존성이 낮음.
2-2. 자동화(CI/CD)
- 빠른 소프트웨어 개발을 위해 개발 지원용 자동화 도구가 필요.
- 형상 관리, 빌드/테스트/배포에 대한 자동화가 필요.
2-3. 인프라
- 유연하게 제공되는 가변적인 인프라가 필요.
- Infra As Code(프로비저닝을 할 때 코드로 관리)
2-4. 개발 프로세스
- 반복/점진적인 피드백 기반의 개발 프로세스로 변화가 필요.
2-5. 개발 문화
- DevOps 개발 문화 : 신뢰와 협업의 개발 문화
- 개발에서 운영까지의 신속한 가치 흐름 생성(가시화, 작업 간격 축소)
- Jira, Confluence 와 같은 협업 도구를 통해서 시각 가시화
- 지속적인 피드백 제공, 빠른 문제 감지 및 복구
- 자동화 테스트, 피어 리뷰
- 피드백을 통한 개선
- 생산적인 신뢰/협업 문화 생성
- 실험/위험 감수, 조직 합습
- 비난하지 않는 포스트 모텀(post-mortems)
- 내부 기술 콘퍼런스
- 끈임없는 학습
2-6. 어플리케이션 설계 방식
- 아키텍처, 개발 문화, 조직 등의 변화 뿐만 아니라 어플리케이션 설계 방식 또한 변화가 필요하다.
- 서비스 별 데이터베이스 설계
- 각 저장소 분산 필수
- 다른 서비스 저장소 호출 불가능
- API 만을 통해서 접근 가능
- 데이터 일관성의 문제가 발생할 수 있다, 하지만 과정이 아닌 결과적인 측면에서만 데이터 일관성이 보장되면 된다.
- 모든 과정을 API 기반으로 설계가 되면 항상 단계별 실패에 대한 고민이 필요하고 대응할 수 있도록 설계가 되야 한다.
- 다양한 실패를 대비하여, 자동으로 테스트를 할 수 있는 환경이 필요하고 실패 감지 및 대응울 위한 반드시 실시간 모니터링 체계가 필요.
2-7. 결론
3. 마이크로서비스가 만병통치약인가?
- MSA 는 마이크로서비스 기반 아키텍처(즉, 마이크로서비스는 MSA의 구성요소 중 하나).
- MSA 에 대한 오해들
- 컨테이너, 쿠버네티스를 사용하면 MSA를 하는 것이라는 생각.
- 클라우드 인프라 위에는 무조건 마이크로서비스가 올라가야 함.
- 마이크로서비스로 구축하면 시스템이 유연해지고, 확장성이 높아지고 비지니스도 민첩해진다.
- 빅테크 기업으로 가려면 마이크로서비스가 필수다.
- MSA를 하는 것에 아키텍처는 정답이 없다.
3-1. 마이크로서비스 성숙도
- 클라우드 어플리케이션 전환은 좌측의 유형부터 우측의 유형으로 점진적 변화하는 과정이며, 많은 시간이 소요되며 급격한 변화는 리스크가 높다.
- 매크로 서비스
- 모놀리스 시스템 안에 각각의 영역을 API화 하여 언제든 서비스별 분리가 가능한 구조.
- 미니 서비스
- 영역별로 서비스는 분리하였으나 일부는 DB 까지 분리된 하이브리드형 구조.
- 마이크로서비스
- 영역별 서비스와 디비모두 분리된 구조.
3-2. 마이크로서비스 구축의 난이도, 복잡성
- 잦은 네트워크 호출이 필요하므로 성능면에서는 다소 부정적이고 보안처리, 분산트랜잭션 등 난이도와 복잡도가 높아진다.
- 저장소(데이터)의 완벽한 격리가 필요하고, 통합 데이터 모델링 사상과 상충되며 데이터 중복, 복제가 고려되어야만 한다.
참고
- https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard