마이크로서비스 아키텍처 구축 CH.5 마이크로서비스의 통신 구현

5.1 이상적인 기술을 찾아서

• 여러 서비스가 얽힌 만큼 하위 호환성을 쉽게 해야 함.
• 명시적인 인터페이스를 사용해야
  • 명시적 스키마를 사용하면, 노출하는 인터페이스가 명시적임을 보장한다.
• 가능성을 열어 두되, API를 기술 중립적으로 유지하자
  • “마이크로서비스를 구현하는 데 사용될 기술스택을 강요하는 통합기술은 피해야 한다” ⇒ 이해가 안됨.
• 내부 구현 및 세부 사항을 은닉하라
  • 내부 구현 사항을 알게 되면 결합도가 증가함
  • 내부 구현 사항 변경 시, 소비자도 변경을 해야하게 됨. → 기술 부채 증가

5.2 기술 선택

• RPC (Remote Procedure Call)
  • 원격 서비스를 로컬에서 호출한다.
  • 같은 네트워크 상에서만 가능
  • 클라이어느 측 코드를 쉽게 생성 가능하므로, 메서드 호출하듯이 사용 가능한 것이 가장 큰 이점이다.
  • 기술 결합의 발생
    • gRPC 는 대체 언어에 대한 지원을 하지만, 상호 운용성에 제약이 따른다.
    • 이러한 기술 결합은 내부 기술의 구현 상세 정보를 노출하는 형태가 된다.
  • 결국 원격 호출이다.
    • 네트워크를 통한 전송 시간이 많이 걸릴 수 있다.
    • 네트워크를 신뢰할 수 없다.
      • 서버가 정상이라도 네트워크는 실패할 수 있다.
      • 패킷 변조의 위험성도 충분히 고려해라
  • RPC 의 적용 대상
    • 네트워크가 완전히 숨겨져 있을 정도로 원격 호출을 추상화하지 말자
    • 클라이언트에 상관 없이 인터페이스 개선 여부를 고려해라
    • 동기식 요청 및 응답 모델에 적합
      • 반응형 확장 (reactive extension) 에도 적합
• REST (Representational State Transfer)
  • 리소스 (Resource) → 가장 중요
    • 리차드슨 성숙도 모델
    • https://brunch.co.kr/@pubjinson/12
  • HATEOAS
    • 다양한 포맷으로 된 여러 다양한 컨텐츠에 대한 링크가 컨텐츠에 포함된 개념
    • 일반 웹페이지에서 쉽게 볼 수 있는 개념이다.
      • 아마존 쇼핑 사이트 생각.
  • 성능 문제
    • HTTP 요청마다 발생하는 오버헤드
    • 대부분 TCP 지만, RPC 에서는 UDP 를 사용할 수 있다.
  • 적용 대상
    • 다양한 클라이언트의 액세스를 허용 → 동기식 요청 및 응답 인터페이스를 위한 확실한 선택
    • 가장 넓게 사용되는 인터페이스 방식
      • 다양한 기술 간의 상호 운용성
• 그래프QL (GraphQL)
  • 모바일 장치에서 필요한 정보를 조회하기 위해 여러 호출이 필요하지만, 한번에 가져오는 단일 쿼리를 실행할 수 있다.
    • ^ 엔드포인트를 클라이언트 장치에 노출하는 마이크로서비스가 필요하다.
  • 문제점
    • 클라이언트 장치는 동적으로 변경되는 쿼리를 실행 가능
      • 서버 측에 상당한 부하를 준 사례
      • SQL 과 달리 쿼리 플래너가 없어서 문제 추적에 어려움이 있다.
    • 캐싱이 어렵다.
      • 반환한 모든 리소스에 대해 ID 연관관계를 생성 후 ID 에 대한 요청을 클라이언트 장치가 캐싱하는 방법으로 개선
    • 쓰기에 적합하지 않아보인다.
  • 적용 대상
    • 외부 클라이언트에 기능을 노출하는 시스템의 경계에서 사용
      • 모바일 장치
    • 호출 집계 및 필터링 매커니즘
      • 하위 마이크로서비스에 대한 호출을 집계하는 데 사용
    • BFF (Backend For Frontend) 패턴이 대안
• 메시지 브로커 (Message Broker)
  • 미들웨어
    • 프로세스 간 통신을 관리
  • 메시지
    • 요청 및 응답 또는 이벤트가 포함
  • 토픽과 큐
    • 큐
      • 두 지점 간 (point to point)
      • 부하 분산 매커니즘으로 작동함 (경쟁 소비자 패턴)
      • 하나의 소비자만 메시지를 받음
      • 요청 및 응답에 적합
    • 토픽
      • 여러 소비자가 토픽을 구독하여 해당 메시지의 복사본을 받음
      • 이벤트 기반 협업 방식에 적합
        • 이벤트 브로드캐스트에 유용
  • 전달 보장과 신뢰
    • 정확히 한 번 (exactly once)
      • 구현하기 어렵겠지만, 정말 신뢰가 깊은 메시지 전달 방식인 것 같다.
      • 보통 메시지에 ID 값을 포함하여 구현

5.4 스키마

• 구조적 계약 위반
  • 소비자가 더 이상 호환되지 않는 방식으로 엔드포인트 구조가 변경
    • 필드, 메서드 제거, 새로운 필드 추가되는 것 등등
  • 그나마 발견하기 쉬움
• 의미적 계약 위반
  • 내부 동작이 변경됨
  • 메서드의 의미가 소비자의 기대와 다르게 체계가 변경되는 경우
• 소통과 문서화
  • 지속적인 방식으로 운영 및 해결해야.

5.6 중단 변경 피하기

• 관대한 독자
• 당신이 하는 일에는 엄격하고, 남에게서 받아들일 때는 너그럽게 하라
• 명시적 인터페이스
  • 숨겨진 정보의 경계를 명확하게 한다.
• 결국 테스트를 해보자