- 작은 서비스들의 조합으로 하나의 어플리케이션을 개발하는 방법으로써, 각 서비스들은 별도의 프로세스로 동작하고 경량 메커니즘(REST)을 이용해서 통신한다 by Martin Fowler
- Find-Grained SOA by Adrian Cockcroft(Netflix)
- 하나의 어플리케이션을 작은 서비스들의 조합으로 구성하는 방법(하나의 단일(monolithic) 어플리케이션으로 구성하는 것에 반함)
- 각 서비스들은 독립적인 프로세스로 실행(모듈/컴포넌트 단위로 실행되는 것에 반함)
- 공개 프로토콜을 통해 상호 통신
- 독립적으로 개발, 배포, 스케일 그리고 유지됨(다른 언어를 사용할 수도 있음)
- 서비스는 업무 기능을 캡슐화함(언어 구조물(클래스, 패키지)를 통한 캐슐화에 반함)
- 서비스들은 독립적으로 교체/업그레이드될 수 있다.
- SOA랑 같다
- SOA는 다양한 기업용 어플리케이션의 통합에 대한것
- MS는 하나의 어플리케이션을 분해하는 것에 대한 것
- 은탄환
- MS는 단점, 위험도 갖는다.
기능 단위로 구분되어 있지 않고, 기술(controller, service, persistence) 단위로 구분되어 있음. 목적 조직보다 기능 조직으로 관리됨. by 콘에이의 법칙
새로운 타입의 디바이스(모바일, TV 등)나 persistence가 추가되면 아래와 같은 구조로 변경된다.
controller는 웹에 적합하도록 설계되었지 모바일이나 TV 등을 고려하여 설계되지 않았다. 또 모바일의 경우는 controller를 여러번 호출하는 것이 성능에 문제를 일으킬 수도 있다.
persistence나 백엔드 기술이 변경된다면 어떻께 될까 ?
예전엔 모든 정보를 하나의 RDB에 저장했었다. 하지만 현재는 특정 유스케이스에 대해서 RDB에 비해 월등한 성능을 제공하는 특별한 기술들을 사용해야 한다.
- 상품검색(Search)는 RDB보다는 ElasticSearch를 사용하는 것이 훨씬 빠르고 안정적이다.
- 상품리뷰(Reviews)는 document DB은 mongoDB에서 처리하는 것이 훨씬 수월하다. 스키마 변경에도 영향을 받지 않고.
- 쇼핑카트(Cart)는 key-value store인 redis를 이용하는 것이 쉽고, 빠르다.
- legacy backend(SAP) 접근해야 할 필요도 있다.
팀의 크기도 적고, Single codebase에서 deploy, versioning 등이 쉽다.
그런데 아래와 같이 시스템이 커지고, 복잡해지면서 문제가 발생한다.
빠르게 구현해야 하는 피쳐들이 많다. 이를 해결하기 위해 팀을 크게 한다. 이로 인해 codebase가 거대해 진다. 큰 팀과 거대한 codebase는 관리하기 어렵다.
해결책으로 팀을 나눠서 피쳐들을 부분집합을 구현하도록 한다. 각 팀은 분리된 전용 codebase를 사용하거나 jar 같은 단일 모듈을 사용한다.
이 경우 개별 모듈을 조립하는 별도의 조립팀(assembling team)이 필요하다.
여기서 문제(user acceptance test 같은)는 결함이 파이프라인(CD)의 후반에서 발견되면 어떻게 할것인가 이다. 이 경우 결함을 해결할 때까지 배포를 할 수 없다.
그 다음 문제는 조립팀이 각 팀에서 만든 컴포넌트 중에서 가장 퀄리티가 높으면서 최대한 많은 피쳐를 제공하는 버전을 찾는데 시간을 보내야 한다는 것이다.
이들은 각 개발팀에게 특정 모듈의 특정 버전에 존재하는 특정 이슈를 전달하여 압박한다. 빠르게 큰 혼란이 발생한다. 이 문제의 대부분은 코딩과 관련된 것이 아니라 거대한 어플리케이션을 조립/배포한는데서 발생한다.
- 실행 가능한 단일 어플리케이션
- 이해(comprehend)하기 쉽지만, 개별 개발자과 전체를 완전히 소화(digest)해내기는 어렵다.
- 하나의 언어로 구현되어야 한다.
- 프로그래밍 언어에 기반한 모듈화
- 언어에 가용한 구조체(package, class, function, namespace, framework 등)을 이용
- 다양한 스토리지 / 서비스 기슬이 사용됨
-
- RDBMS, Messaging, eMail, ...
- 이해하기 쉽다(하지만 완전히 소화하긴 어렵다)
- 싱글 유닛으로 테스트하기 쉽다(일정 크기까지는)
- 싱글 유닛으로 배포하기 쉽다
- 관리하기 쉽다(일정 크기까지는)
- 변경을 관리하기 쉽다(일정 수준까지는)
- 확장(scale)하기 쉽다(주의를 기울인다면)
- 복잡성은 언의 구조체에 의해 관리된다.
- 언어 / 프레임워크에 종속적(lock)
- 전체 어플리케이션이 단일 기술 스택으로 개발됨.
- 실험을 할 수 없다. 신기술의 장점을 채택하기 어렵다.
- 소화
- 단일 개발자가 거대한 코드 베이스를 소화할 수 없다.
- 하나의 팀이 하나의 거대한 어플리케이션을 관리할 수 없다.
- 아마존의 "2 피자" 규칙
- 싱글 유닛으로 배포
- 하나의 컴포넌트에 대한 하나의 변경에 대해서 독립적으로 배포할 수 없다.
- 변경은 다른 변경들이 배포 준비될 때까지 기다려야 한다.
- MS는 작기 때문에 하나 혹은 둘 정도의 persistence를 사용
- 업무 환경에 가장 적합한 기술 스택을 사용
- 클라이언트가 서비스를 직접 호출할 때 발생하는 이슈(서로 다른 데이터를 사용. 모바일의 빈번한 호출로 인한 성능 저하)를 해결하기 위해 API Gateway 도입
- API GW
- 클라이언트에서 사용하기 편리한 인터페이스 제공
- 개별 서비스들 접근해야 하는 복잡성을 해결
- 캐싱, 인증 등도 처리
- API GW
- 언어의 구조체(package, class 등)에 의하지 않음
- 작고, 독립적으로 배포 가능한 서비스를 통해 컴포넌트화함
- SRP를 준수하는 서비스를 통해 명확한 인터페이스를 통한 설계 가능
- 변경은 영향을 받는 서비스들로 제한됨
Review와 Payment에 변경을 가한다고 가정해 보자. 각 서비스들의 변경이 준비가 되면 서로 다른 시점에 배포할 수 있다. 다른 변화셋이 준비되었는지에 대한 걱정없이. SCC에 브랜치를 만들지 않고도.
- 서비스들은 작고, 독립적으로 배포 가능한 어플리케이션이다.
- 단일 코드베이스가 아니다
- 하나의 언어/프레임워크를 써야만 하는 것은 아니다
- 언아/프레임워크의 구조체에 기반한 모듈화가 아니다.
- HTTP, TCP, UDP, Messaging, ETC
- payloads: json, bson, xml, protocol buffers, etc.
- 명확한 인터페이스 설계가 됨
- Netflix의 Cloud Native Architecture
- Common DB가 아니라 API를 통한 통신
하나의 공통 DB를 사용하는 것이 처음엔 쉽지만 불필요한 의존성(모델의 변화가 다른 여러 서비스에도 영향을 미치는) 유발
- 기술 스택에 기반하지 않음
- 업무 기능에 의한 수직적 분리(ex. cart, catalog, checkout)
- 물론 기술 기반 분리도 또한 실용적임(ex email service)
- crosss-functional team에 적합
- 이해, 수정, 테스트, 버전닝, 배포, 관리, 점검(overhaul), 교체가 쉽다.
- 작은 cross-functional teams에 의해서
- 업무에 적합한 툴(언어, 프레임워크) 사용
- 서비스들은 서로 다른 요구에 의해 서로 다른 속도로 발전, 배포, 관리된다
- 서비스들은 "Tolerant Readers"로 만들 수 있다
- 소비자 주도 계약(consumer-driven contract)
- ESB의 대조(Antithesis)
- 서비스는 orchestrated되는 것이 아니라 choreographed된다.
- 왼쪽의 차들을 조정(coordinate)하기 위해 얼마나 많은 통제(orchestration)가 필요할까 ? 포장된 도로, 신호등, 차선 등
- 오른쪽의 보행자들은 어디로 가라고 알려주거나 충돌을 방지하기 위한 차선, 신호등 등이 필요치 않다. 그들은 자연스럽게 자신들의 행위를 규제하여 다른 보행자들과 부드럽게 상호작용을 한다. 보행자들은 자신들의 속도를 자연적으로 조절하여 충돌을 자연적으로 피한다. 누가 뭐라고 안해도 거리를 자연적으로 유지한다. 이게 우리가 원하는 시스템이다. 이게 개별 MS와 유사하다.
- 서비스는 orchestrated되는 것이 아니라 choreographed된다.
- 업무에 최적인 기술을 사용할 수 있는 자유
- 싱글 RDBMS가 항상 최선이라고 가정하지 말라
- 논란의 여지가 많다. 많은 DBA들이 싫어할 것이다.
- 범기업(pan-enterprise) 데이터 모델은 존재하지 않는다.
- 트랜잭션이 없다.
- 개별 서비스 소화가 쉽다(전체를 이해하기는 어렵다)
- 하나의 서비스를 테스트, 배포, 관리, 버전닝, 확장하기 쉽다.
- 변경 싸이클이 분리(decouple)된다.
- staff들을 확장하기 쉽다.
- 언어/프레임워크 락인이 없다.
- 복잡도가 어플리케이션에서 운영단으로 이동
- 분산 컴퓨팅의 환상
- 서비스는 가용하지 않을 수 있다.
- 단일 구조에서는 걱정할 필요가 없었던...
- 실패를 고려한 설계 필요(circuit breaker)
- "Everything fails all the time" - Werner Vogels
- 더 많은 모니터링이 필요
- 원격 호출은 in-process 호출에 보다 비용이 크다.
- 트랜잭션: ACID를 통한 eventual consistency에 의존해야만 함
- 기능이 여러 서비스에 걸쳐 제공된다.
- 변경 관리가 다른 어려움이 된다.
- 서비스 간의 상호작용을 고려해야 한다.
- 의존성 관리 / 버전닝
- 모듈 경계 리팩토링
- 개별 서비스의 리팩토링은 쉽다.
- 모듈을 넘어서는 리팩토링은 어렵다.
- NW은 신뢰할만하다
- latency는 0이다.
- bandwidth는 무한한다
- NW은 안전하다
- 토폴로지는 변한지 않는다.
- 한명의 운영자만 있다.
- 트랜스포트 비용은 0이다.
- NW는 한종류(homogeneous)이다.
- 주요 고려사항: 업무 기능
- 명사 기반(catalog, cart, customer)
- 동사 기반(search, checkout, shipping)
- SRP
- Bounded Context
- 크기가 중요한 것은 아니다
- 개별 개발자가 소화하기에 충분히 작아야
- 작은 팀에 의해 관리, 구현될 수 있을만큼 충분히 작아야
- 읽고, 이해할 만큼 충분히 작은 문서화
- 수백이 아니라 수십 비밀
- 본래 개발자들만 아는 비밀
- 예상 가능해야. 실험하기 쉬워야
- SOA는 시스템 간의 통합을 언급
- MS는 개별 어플리케이션을 언급
- SOA는 orchestration에 의존
- MS는 choreography에 의존
- SOA는 스마트한 통합 기술에 의존하고 멍청한 서비스(dumb service)를 이용
- MS는 스마트한 서비스, 멍청한 통합 기술에 의존
- 고려: 리눅스 명령어. 파이프. 필터
- etsy.com을 고려해보자
- 2013년 2월 기준으로 14억 PV, 4.2백만 판매, 9천4백만 달러의 상품이 판매. 2천2백만 이상의 사용자.
- 150명의 개발자들은 하나의 WAR를 하루에 60번씩 배포
- Practices: CI, push button deployment, good monitoring, 개발자들은 첫날 배포 가능, 개발자당 VM 사용. github, chef, 릴리즈 제어를 위해 IRC 사용, 대시보드, 소스 제어를 위한 브랜치 사용 안함.
- MS는 아키텍쳐 스타일
- 하나의 시스템을 독립적으로 수행되고, 상호 통신하는 서비스로 분화
- 단일 어플리케이션에 대한 대안
- MS는 장점과 단점이 있음.
- 단일 구조도 동일