MSA >
2017-09-21
샘 뉴먼 지음
마이크로서비스 #
- 마이크로서비스의 크기 : 충분히 작아서 더 이상 작아질 수 없는 크기
- 자율성 : 독립적 변경 가능, 독립적 배포 가능
- 혜택 : 기술 이기종성, 회복성(격벽, 장애 전파 차단), 확장 용이(필요한 서비스만), 배포 용이, 조직 부합성, 조합성(재사용가능성), 대체가능성을 위한 최적화(서비스 재작성 용이)
진화적 아키텍트 #
- 소프트웨어는 고객의 요구에 맞게 반응하고 적응해야 함, 지속 성장가능한 프레임워크를 만드는데 보탬이 되도록..
- 도시 설계자의 역할
- 구역화 : 구역 사이의 일 걱정, 서비스간 통신방법이나 시스템 전반 상태 모니터링에 시간 할애
- 전략적 목표
- 원칙(principle) : 목표를 위해 해야할 일을 정렬하는 규칙, 변경될수 있다.(ex: 신제품 출시기간 단축이라는 전략목표를 위해 SW수명주기 전반에 대한 통제권을 가지고, 제품준비완료시마다 타팀과 독록적으로 출시하는 원칙을 정하기) ref. https://www.12factor.net/
- 실천사항 : 자세한 실질적 지침(ex:코딩지침, 로그는 중앙수집, HTTP/REST가 표준 통합 스타일), 조직규모에 따라 팀별로 다를 수 있음
- 필수 기준 : 모니터링, 인터페이스, 아키텍처 안정성
서비스 모델링하기 #
- 좋은 서비스를 만드는 요소
- 느슨한 결합 - 강한 응집력
- 경계가 있는 콘텍스트("세포가 존재할 수 있는 이유는 세포막이 세포 내외부를 구분하고, 어떤 것을 통과시킬지 결정하기 때문이다.")
- business capability
- '이 컨택스트는 무슨일을 하는가?', '그 일을 하기 위해 어떤 데이터가 필요한가?'를 먼저 물어보라. - 이 capability가 서비스로 모델링 될때 다른 서비스에 노출될 주요 행위(operation)가 된다.
- 경계가있는 컨텍스트는 더 많은 '경계가 있는 컨텍스트들'을 내포할수 있다. : ex. 동일팀이 운영하는 '주문조달', '제품인수', '재고품목' 서비스는 '창고'라는 컨텍스트에 내포되는게 선호됨
통합 #
- 이상적인 통합 기술 모색
- 호환성을 깨는 변경(breaking change) 피하기 - 기술중립적인 API 생성 - 소비자(사용자)를 위한 서비스 단순화 - 내부구현 감추기
- 공유 DB : 단순하고 빠르지만 많은 문제점(구조가 외부에 공개됨, 서비스들의 기술 선택범위가 제한됨, 로직이 흩어짐(응집력이 낮아지고 결합도가 올라감)
- 동기/비동기
- Request/Response 기반 협업 : 동기 or 비동기(with callback) - Event 기반 협업 : 비동기, 지능이 고르게 분산되어 있음, 결합도 낮은 방식
- 오케스트레이션 / 코레오그래피
- Orchestration : 오케스트라 지휘자처럼 프로세스를 안내하고 구동하는 하나의 중앙두뇌에 의존(ex: '고객서비스'가 1.'적립포인트' 호출하고 2.'우편서비스'를 호출하고 3.'이메일서비스'를 순차적으로 호출)-- 중앙 관리권한의 편중된다는 단점- Choreography : 무용수들이 자신의 역할을 알고 주변의 무용수에 반응(ex: '고객생성됨' 메시지가 발산되고 이메시지를 각 서비스가 받아서 '포인트','우편','이메일' 서비스가 행동)-- 전체적인 완결여부의 모니터링 및 추적을 위한 추가 작업 필요 -- 결합도 낮춤, 유연하고 , 변경 용이
- RPC
- 특정 기술 결합도 높다, 원격호출에 대한 지나친 추상화는 개발자가 지역호출과 동일하게 사용할 가능성 있음, java RMI는 취성(쉽게 부서)이 약하다.
- REST
- HTTP: REST와 궁합이 잘맞음, 자원과 함께 사용되는 HTTP 동사들, HTTP는 풍부한 지원도구와 거대한 기술 생태계 존재 - HATEOAS : Hypermedia As The Engine Of Application State-- Server/client 결합도 낮아짐 (client는 액션별 URI scheme를 몰라도 됨)- JSON : HATEOAS를 위해 HAL 적용 (Hypertext Application Language) - MSA에서 코드 재사용 위험 : 공유 코드를 서비스 경계를 넘어 사용하는 경우 잠재적인 결합의 문제를 안고 있는 셈 (ex: realestate.com.au의 경우 새로운 서비스 생성시 부트스트래핑을 도와주는 템플릿 서비스를 사용한다. 코드 공유보다는 템플릿을 서비스마다 복사하여 결합도를 낮춤)-- Micro Service 내의 DRY는 반드시 지켜야하지만 전체 서비스 간의 DRY위반은 너무 걱정하지 않아도 됨(강결합 해악이 코드 중복 문제보다 더 심각)
대규모 마이크로서비스 #
- 안티프래질 조직 : 카오스 몽키, 카오스 고릴라, 레이턴시 몽키
- 타임아웃 : 모든 프로세스 경계외부 호출에 타임아웃을 설정
- Circuit Breaker
- 격벽(bulkhead) : Circuit Breaker는 격벽 자동 차단기, Netflix의 Hystrix
- 격리도 높이기
- 멱등(idempotent)적으로 만들기
- ex : addPoint(amount(100), forAccount(1234)) ===> addPoint(amount(100), forAccount(1234), reason(forPurchase(4567)))
- CQRS(Command-Query Responsibility Segregation) Pattern, Event Sourcing
- Service Discovery
- 동적 서비스 레지스트리 : Zookeeper, Consul, Eureka
- Documentation Service
- Swagger
- HAL(Hypertext Application Language), HAL Browser
종합 정리 #
- 마이크로서비스의 원칙
- 비지니스 개념에 따른 모델 : 비지니스 경계로 나눠진 컨텍스트
- 자동화 문화의 적용 : 자동화 테스팅, 지속적 배포, 환경 정의, 커스텀 이미지, 완전자동화된 불변서버
- 내부 세부 구현의 은폐 : DB, 기술중립적 API 선택
- 모든 것을 분권화 : 서비스 소유팀에게 의사결정, 통제를 위임할 기회를 꾸준히 찾아야 함, 언제든 배포, 개발, 테스팅을 직접 쉽게 수행할수 있어야함, 팀이 변경에 대해 책임을 지고 변경의 릴리즈 시점까지도 스스로 결정하면서 팀이 그들의 서비스를 소유하도록 보장하기
-- 내부 오픈 소스를 이용 타팀 소유 서비스의 변경에 참여- 독립적 배포
-- 콘웨이법칙이 효과가 있도록 팀을 조직에 맞춰 조정
-- shared governance model 시도 : 대단히 중요한 지침이 필요한 곳이라면 각 팀의 사람들이 시스템의 기술비전을 진화시킬 책임을 집단으로 공유하는 개념
-- 오케스트레이션과 더미 미들웨어 보다는 '코레오그래피'(서비스 경계 내에서 로직과 데이터 연관성을 보장하는 스마트 엔드포인트로 응집력을 유지시키게 해 줌)
- 장애 격리 : 타임아웃,격벽,회로차단기
- 식별가능성 높이기
-- 가상트랜잭션 주입으로 실사용자 행위를 모의하는 '유의적 모니터링' 사용
-- correlation id 사용
last modified 2023-09-05 10:00:48
Processing time 0.2025 sec