ranlog

마이크로서비스 아키텍처 구축, Building Microservices (한빛미디어)

20 Jun 2020 | book

마이크로서비스란?

로버트 C. 마틴에 따르면 단일 책임 원칙에 따라 같은 이유로 변경되는 것들은 한데 모으고, 서로 다른 이유로 변경되는 것들은 분리해야 한다고 했다.

마이크로서비스는 서비스간의 분산도를 높이고 서비스간에 밀접하게 연결되어 생기는 문제점을 줄이기 위해 서비스 사이의 모든 통신을 네트워크 호출을 통해 이루어지게 한다.

서비스들은 서로 독립적 으로 변경될 수 있어야 하고, 독립적으로 배포될 수 있어야 한다.

SOA란?

서비스 지향 아키텍쳐(Service Oriented Architecture)란 서비스의 최종 능력 집합을 제공하는 여러 서비스가 서로 협업하도록 하는 설계 접근 방식이다.

대규모 모놀리식 애플리케이션의 도전으로 SOA가 출현하였다.
이는 소프트웨어 유지보수와 재작성을 더 쉽게 했다. SOA는 훌륭한 아이디어지만 SOA를 잘하는 방법에 대한 합의는 부족하여 대안들이 나오게 되었는데 그중 하나가 마이크로서비스이다.

무엇이 좋은 서비스를 만드는가?

  • 느슨한 결합
    • 경계가 있는 콘텍스트를 찾는것이 중요하다
  • 강한 응집력

어떻게 통합하는가?

  • 기술 중립적인 API 생성
  • 소비자를 위한 서비스 단순화
  • 내부 구현 상세 감추기
  • 동기와 비동기 통신중 선택하기
    • 요청/응답 또는 이벤트 기반중의 협력 방식 택하기
  • 오케스트레이션과 코레오그래피 중 선택하기
    • 오케스트레이션이란 오케스트라 지휘자처럼 프로세스를 안내하고 구동하는 하나의 중앙 두뇌에 의존
    • 코레오그래피 방식이란 이벤트 기반의 비동기 방식으로 작업을 수행하여 느슨한 결합을 이끌어냄

RPC와 REST중 선택하기

RPC의 장점

RPC란 지역 호출을 통해 원격 서비스를 실행하는 기술이다. 일부 기술은 SOAP나 쓰리프트, 프로토콜 버퍼와 같은 인터페이스 정의에 의존함. 쉽게 만들고 빠르게 실행한다는 장점이 있음

RPC의 단점

서버 스텁이 변경되었다면 클라이언트 스텁도 다시 생성해야 한다. 객체의 필드를 삭제하거나 객체를 리팩토링할 때도 유사한 문제가 발생한다. 자바 RMI의 경우는 이러한 문제가 생길 수 있지만 프로토콜 버퍼나 쓰리프트같은 현대적 메커니즘은 클라이언트와 서버 간 릴리스 보조가 필요 없도록 RPC의 단점을 보완하고 있다.

REST의 장점

리처드슨의 성숙 모델에서 다양한 REST 방식의 비교를 확인해보라.

https://martinfowler.com/articles/richardsonMaturityModel.html

RSET는 웹에서 영감을 얻은 아키텍쳐 방식이고, 자원의 개념이 가장 중요하다. (POST/GET/PUT..)

HATEOS란 무엇인가

하이퍼미디어란 하나의 콘텐트가 텍스트나 이미지, 사운드와 같은 다양한 포맷의 다양한 콘텐트를 링크하는 개념이다. HATEOAS는 클라이언트가 다른 자원에 대한 링크를 서버와 상호작용을 한다는 것이다. 어떤 URI를 요청했는지 알고 있으므로 서버 내 고객의 정확한 위치를 알 필요는 없다.

REST의 단점

쓰리프트와 같은 파이너리 프로토콜에 비하면 HTTP 기반의 REST 페이로드는 부하 면에서 단점이 될 수 있다. HTTP는 대규모 트래픽에는 적합할 수 있지만 TCP 또는 다른 네트워킹 기술 기반의 대체 프로토콜과 비교하면 낮은 지연시간이 필요한 통신에는 좋은 선택이라 할 수 없다. 예를 들어 웹소켓의 경우에는 클라리언트와 서버 간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때는 훨씬 효율적이다.

서버 대 서버 통신에서 극도로 낮은 지연시간 또는 작은 메시지 크기가 중요하다면 HTTP 통신이 좋은 생각이 아닐 수도 있다. 페이로드의 소비(해석) 자체가 더 많은 작업을 필요로 하기 때문이다.

이벤트 기반의 협업 구현

이벤트 기반 아키텍쳐는 분리되고 확장 가능한 시스템으로 우리를 인도하지만, 프로그램의 복잡성을 더하는 것도 사실이다. 적재적소에서 모니터링하고 프로세스 경계요청을 추적할 수 있도록 상관관계 ID의 사용도 검토해야 한다.

반응형 확장

흔히 Rx로 알려진 반응형 확장은 다수의 호출 결과를 조합하여 그 결과에 따라 연산을 실행하는 매커니즘이다. 이들 호출은 블로킹 또는 논블로킹이 될 수 있다. 분산 시스템은 Rx 구현체와 아주 잘 어울린다.

호스트당 몇개의 서비스가 있어야 하는가?

가능하다면 호스트 및 컨테이너당 단일 서비스를 사용하는 것이 좋다. 변경되는 부분을 더 쉽고 저비용으로 관리하기 위해선 LXC나 도커를 사용하는것이 좋다. 또한 자동화 문화는 모든 것을 관리하는 핵심이다. 모든 것을 자동화하라. 또한 배포 기술의 선택은 개발자에게 영향을 준다.

테스팅 및 모니터링

  • 소비자 주도 계약을 이용하여 엔드 투 엔드 테스트의 필요성을 줄여라
  • 최소한의 필수 사항으로 응답시간을 추적하고 그다음에 에러율을 추적하라
  • 모든 하위 응답 상태를 추적하라. 최소한 하위 호출의 응답시간을 포함하고, 에러율을 추적하라. (히스트릭스와 같은 라이브러리)

보안

브라우저 기반의 애플리케이션 보안에 대한 일반적인 개요를 원한다면 공개 웹 어플리케이션 보안 프로젝트 (OWASP) 가 좋은 출발점이다.

콘웨이의 법칙

콘웨이의 법칙은 시스템을 조직 구조와 다르게 설계할 때의 위험을 강조한다.

언제 마이크로서비스를 쓰지 않아야 하는가?

해당 분야를 제대로 이해하지 못할수록 서비스에 대한 적절한 경계가 있는 콘텍스트를 찾는 것이 힘들어지기 때문에, 우선 모놀리식으로 시작하고 안정화되면 분해하는게 좋다.