MicroService Architecture Style
- 예시를 통한 마이크로 서비스 아키텍처
- 전자상거래 웹 스토어 운영 회사
- 전자상거래 웹 어플은 주문처리, 사용자 등록 관리, 제품 검색 및 주문과 같은 다양한 기능을 제공
- 어플이 초기와 달리 점점 복잡해짐
- 복잡한 아키텍처로 인해 새로운 서비스의 배포가 늦어짐
- 이러한 문제로 인해 서비스 제공 능력이 저하될 수 있다
마이크로 서비스 아키텍처의 도입
- 위에서의 문제
- 한 팀의 변경 사항이 다른 팀들에도 영향을 미침
- 모든 팀은 한번에 테스트를 진행해 서비스를 업데이트 해야했음
- 마이크로 서비스 아키텍처 도입
- 개요
- 간접적으로 결합된 바운드 컨텍스트를 가진 서비스 지향 아키텍처
- 서비스 간에 느슨한 결합을 가지고 각 서비스가 자체적인 컨텍스트나 범위를 가짐
- 큰 응용 프로그램을 작은 서비스로 분해하고 각 서비스를 독집적으로 실행
- 시스템을 관리 가능하고 독립적으로 배포 가능한 구성 요소로 기능 분해
- 각 서비스는 비즈니스 능력을 중심으로 설계, 자동화된 배포 프로그램을 통해 각 서비스가 독립적으로 배포 및 확장
- 간접적으로 결합된 바운드 컨텍스트를 가진 서비스 지향 아키텍처
- 구조
- 비즈니스 도메인의 기능적 분해
도메인 주도 설계(Domain-driven design)
- 비즈니스 도메인의 개념과 로직을 도메인 모델로 추상화하고 이를 소프트웨어 개발의 기반으로 활용
- 좋은 소프트웨어 개발을 위해 그 소프트웨어가 어떤 것에 관한지를 알아야 함
- 은행 소프트웨어 시스템 개발이라면 은행이 어떤 것에 관한 것인지 은행의 도메인을 이해해야함
- 도메인 주도 설계는 크고 복잡한 모델을 서로 다른 기능적으로 분리된 서브 도메인으로 나누고 서브 도메인 간 상호 관련을 명시적으로 설명
MicroService Example 1
- 온라인 상점의 기능 분해
- 바운디드 컨텍스트 적용(컨텍스트 내에서는 독립적)
- Behavior Example
Conways Law
- 어떤 조직이 시스템을 설계하면 그 설계 구조는 조직의 의사 소통 구조와 유사한 형태를 가질 것이다
- 즉 조직의 구조와 소프트웨어 시스템의 구조 간에 상호 의존성을 강조
- 특정 부서 간의 의사 소통이 많이 발생하면 해당 부서 간의 소프트웨어 시스템 설계에서 상호 의존성이 강하게 나타날 것이라는 것
- 조직 내의 의사소통 및 협업을 고려해 효과적인 소프트웨어 개발과 효율적인 의사 소통 달성에 콘웨이의 법칙이 사용될 수 있다
MicroService Example 2
- API 게이트웨이 사용
- API 게이트웨이는 백엔드 서비스의 오류를 숨기기 위해 캐시된 데이터 또는 기본 데이터를 반환할 수도 있음
- API 게이트웨이는 통신하는 각 마이크로서비스의 위치를 알아야 함
마이크로서비스 간의 상호 통신
- 일반적으로 표준화 되어있음
- HTTP(S)
- 널리 사용되고 검증된 전송 프로토콜, 마이크로 서비스에 사용하면 신뢰성 보장
- REST (Representational State Transfer)
- REST는 데이터를 자원으로 표현, 표준화된 인터페이스 제공
- 마이크로서비스 간 데이터를 일관된 방식으로 다루고 인터페이스를 정의함
- JSON (JavaScript Object Notation)
- 간단하고 가벼운 데이터 표현 형식
- 마이크로서비스 간 데이터 교환의 간소화
- HTTP(S)
마이크로서비스의 특징
- 마이크로는 크기를 나타냄
- 단일 개발 팀으로 관리 가능하 정도의 크지 않은 크기
- 기능 시스템 분해 분해는 수직 슬라이싱이다 레이어를 통한 수평 슬라이싱과 대조
- 각 마이크로 서비스가 특정 기능 또는 비즈니스 모델을 수직으로 포함, 레이어를 기반으로 하는 전통적인 수평 분해와 대조
- 독립 배포는 공유 상태 및 프로세스 간 통신이 없음
- 마이크로서비스 간 독립적인 배포가 가능해야하고 이를 위해서는 공유 상태와 프로세스 간 통신이 없어야 함
- 작고 특정 작업 또는 기능을 명확하게 수행하는 것에 집중
- 명확한 책임을 가져 복잡성을 줄이고 유지보수성을 향상
- 각 마이크로 서비스는 독립적으로 확장 가능, 다른 서비스에 영향을 미치지 않고 확장
Classic SOA vs Microservices
- SOA
- 다양한 애플리케이션을 일련의 서비스로 통합
- 다른 애플리케이션 간에 데이터 및 기능을 공유하고 상호 작용
- Microservices
- 하나의 애플리케이션을 일련의 서비스로 아키텍처화
- 애플리케이션 자체를 여러 개의 작은 서비스로 분해, 각 서비스는 특정 기능 수행
The three aspects of Microservices Architecture
- Architectural aspect
- Technical aspect
- Organizational aspect
- Architectural aspect
Challenges of Microservices
- 성능
- 네트워크를 통해 통신하기 때문에
- 코드 중복
- 각 서비스 간 코드 중복은 유지보수 및 개발 과정에서 추가 복잡성을 초래할 수 있음
- 트랜잭션
- REST서비스는 상태를 유지하지 않는 특성을 가짐, 여러 서비스에 걸쳐있는 트랜잭션 경계를 관리 하는데 어려움이 있을 수 있음
- 인프라 이상의 요소
- 마이크로서비스는 스프링 클라우드 + 스프링 부트와 같은 chassis를 필요로 함
- 프레임워크 및 도구(인프라 이사으이 요소)를 사용하여 새로운 서비스를 만들 수 있게 해줌
고려 사항
- 올바른 기능 분해
- 올바른 기능 분해는 애플리케이션의 모듀롸를 지원
- 모듈화는 각 마이크로서비스가 명확하게 정의된 기능 또는 업무를 담당할 수 있게 해줌
- 기능 분해는 또한 조직 구조와도 연결되어 있어야 함(conways Law)
- 모듈 시스템은 마이크로서비스로 진화할 수 있다
- 초기에 모듈화된 시스템을 구축하고 나중에 마이크로아키텍처로 전환할 수 있다
- 모듈은 초기에 개발 및 유지보수를 용이하게 하지만 나중에 시스템이 성장하고 더 많은 독립적인 관리와 배포가 필요할때 마이크로서비스로 전환
트레이드 오프 가능한 항목들
- 모듈화
- 더 작은 마이크로서비스는 유지보수 측면에서 이점이 있음
- 분산 통신
- 더 큰 마이크로서비스는 통신 오버헤드를 줄일 수 있어서 효율적
- 팀 규모
- 애자일 팀 규모는 마이크로서비스의 최대 큭에 영향
- 적절한 팀 크기에 맞게 마이크로 서비스를 설계하고 전체 마이크로 서비스 크기를 조절해야함
- 인프라스트럭처
- 더 큰 마이크로서비스는 인프라스트럭처 요구사항이 커질 수 있어서 DevOps인프라 운영에는 유리
- 대체 가능성
- 더 작은 마이크로서비스는 대체가 더 쉬울 수 있지만 특정 제한을 초과하지 않는 한에서 큰 마이크로서비스도 대체 가능성을 유지해야 함
- 트랜잭션
- 모든 동일한 DB에 대한 트랜잭션은 하나의 마이크로서비스에 속해야 함
- 데이터베이스의 제한은 마이크로 서비스의 최소 크기를 제한할 수 있음
KMU SW