책너두 (데이터 중심 애플리케이션 설계) 12일차 (~147p)

요약

• REST 와 RPC를 이용한 서비스 데이터 플로를 알게 됨.
  • SOA, 마이크로서비스 설계와 서비스 API 간 버전 호환이 가능 해야 함.
  • REST 를 이용하여 간단하게 접근하면서, 조직간 서비스 통합을 가능하게 함.
  • 원격 프로시저 호출에는 여러 문제가 있고, 원격과 내 로컬이 같게끔 만드는 노력과 대책이 필요함.
    • ex) 네트워크 문제로 인한 호환성 불일치
  • RPC 의 주요 초점은 같은 데이터센터 내의 같은 조직이 소유한 서비스 간 요청에 있음.
  • RPC를 이용하여 데이터 부호화를 할 때, 서비스 호환성을 유지해야 함. ex) API 버전
• 메시지 전달 데이터플로를 알게 됨.
  • 비동기 메시지 전달 시스템을 사용함.
    • 메시지 브로커
    • 분산 액터 프레임워크

메모

서비스를 통한 데이터플로: REST와 RPC

• 네트워크를 통해 통신해야 하는 프로세스가 있을 때, 해당 통신을 배치하는 방법으로 가장 일반적인 방법으로 클라이언트와 서버를 배치한다.
  • 서버는 네트워크를 통해 API를 공개하고, 클라이언트는 이 API로 요청을 만들어 서버에 연결할 수 있음.
  • 서버가 공개한 API 를 서비스라고 함.
• 하나의 서비스가 다른 서비스의 일부 기능이나 데이터가 필요하다면, 해당 서비스에 요청을 보낸다.
  • 이런 애플리케이션 개발 방식을 전통적으로 서비스 지향 설계(service-oriented architecture, SOA) 라고 부름
  • 최근에는 이를 더욱 개선해 마이크로서비스 설계(microservices architecture) 이름으로 재탄생함.
• 서비스 지향 & 마이크로서비스 아키텍처 핵심 설계 목표는 서비스를 배포와 변경에 독립적으로 만들어서 애플리케이션 변경과 유지보수를 더 쉽게 만들기 위함이다.
  • ex) 각 서비스는 한 팀이 소유해야함.
  • 해당 팀은 다른 팀과 조정 없이 자주 서비스의 새로운 버전을 출시할 수 있음.
  • 즉, 예전 버전과 새로운 버전의 서버와 클라이언트가 동시에 실행되야 함.
  • 따라서, 서버와 클라이언트가 사용하는 데이터 부호화는 서비스 API 의 버전 간 호환이 가능해야 함.

웹 서비스

• 서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용할 때 웹 서비스라 함.
  • 웹 서비스 뿐만 아니라 다양한 상황에서도 사용됨.
    • 사용자 디바이스에서 HTTP를 통해 서비스에 요청하는 클라이언트 애플리케이션 (ex: 모바일 디바이스)
    • 서비스 지향/마이크로서비스 아키텍처에서 데이터센터에 위치한 같은 조직의 다른 서비스에 요청하는 서비스
    • 인터넷을 통해, 다른 조직의 서비스에 요청하는 서비스
• 웹 서비스에는 대중적으로 두 가지 방법이 있음.
  • REST
    • 프로토콜이 아니라 HTTP의 원칙을 토대로 한 설계 철학임.
    • 간단한 데이터 타입을 강조함.
    • URL을 사용하여 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP 기능을 사용함.
    • 조직 간 서비스 통합과 관련해서는 SOAP에 비해 인기를 얻고 있음.
    • 마이크로서비스와 연관되기도 함.
    • REST 원칙에 따라 설계된 API 를 RESTful 이라고 함.
  • SOAP
    • 네트워크 API 요청을 위한 XML 기반 프로토콜임.
    • SOAP는 HTTP 상에서 가장 일반적으로 사용되지만, HTTP와 독립적이며, 대부분의 HTTP 기능을 사용하지 않음.
      • 대신, 다양한 기능을 추가하고 광범위하고 복잡한 여러 표준을 제공함(ex: 웹 서비스 프레임워크)
    • SOAP 웹 서비스의 API는 웹 서비스 기술 언어(Web Services Description Language), WSDL 이라고 부르는 XML 기반 언어를 사용하여 기술함.
    • WSDL은 클라이언트가 로컬 클래스와 메서드 호출을 사용해 원격 서비스에 접근하는 코드 생성이 가능함.
      • XML 메시지로 부호화하고 프레임 워크가 복호화 한다.
    • WSDL은 사람이 읽을 수 있게 설계되지 않음.
    • 대부분 SOAP 메시지를 수동으로 구성하기에는 복잡하기에 SOAP 사용자는 도구 지원과 코드 생성과 IDE에 크게 의존할 수밖에 없음.
• RESTful API는 간단한 접근 방식을 선호함.
  • 스웨거(Swagger)로 알려진 오픈API 같은 정의 형식을 사용하여 RESTful API와 제품 문서를 기술할 수 있음.

원격 프로시저 호출(RPC)문제

• 웹 서비스는 네트워크 상에서 API 요청을 하기 위한 여러 기술 중 가장 최신 형상일 뿐..
  • 웹 서비스는 여러 심각한 문제가 있음.
    • 엔터프라이즈 자바진(EJB), 자바 원격 메서드 호출(RMI)과 같은 것은 자바로 제한됨.
    • 분산 컴포넌트 객체모델(DCOM)은 마이크로소프트 플랫폼으로 제한됨.
    • 공통 객체 요청 브로커 설계(CORBRA)는 지나치게 복잡하고, 상,하위 호환성을 제공하지 않음.
      • 이러한 웹 서비스는 1970년대부터 사용한 원격 프로시저 호출(remote procedure call, RPC)의 아이디어를 기반으로 함.
      • RPC 모델은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능하게 해줌 → 위치 투명성(location transparency) 이라고 함.
      • RPC는 접근 방식에 근본적 결함이 있음. → 네트워크 요청은 로컬 함수 호출과 매우 다름.
        • 로컬 함수 호출은 예측 가능함.
          • 제어 가능한 매개변수에 따라 성공 or 실패함.
        • 네트워크 요청은 예측이 어려움.
          • 네트워크 문제로 요청, 응답이 유실 될 수 있음.
          • 원격 장비가 느려지거나 요청에 응답하지 않을 수 있음.
          • → 전혀 제어할 수 없음.
        • 네트워크 문제는 일상적이므로 항상 대책을 세워야 함.
          • 네트워크 요청은 타임 아웃으로 결과 없이 반환될 수 있다.
          • 실패한 네트워크 요청을 다시 시도해도, 요청은 처리되더라도 응답만 유실될 수 있음. (프로토콜에 중복 제거 기법, 멱등성을 적용 해야 함.)
          • 함수 호출보다 훨씬 느리고 지연 시간이 매우 다양함.
          • 모든 매개변수는 네트워크를 통해 전송할 수 있게끔 바이트열로 부호화 해야 함. (큰 객체라면 즉시 문제가 될 수 있음.)
          • 클라이언트와 서비스가 다른 프로그래밍 언어로 구현된 경우, RPC 프레임워크는 하나의 언어에서 다른 언어로 데이터타입을 변환해야 함.
• 근본적으로 로컬와 원격 서비스가 다르기에, 원격 서비스의 프로그래밍 언어를 내 로컬 객체처럼 보이게끔 노력하는 자체는 중요함.
  • REST의 장점 중 하나는 REST가 네트워크 프로토콜이라는 사실을 숨기려 하지 않는 것임. (다름을 인정한다.)

RPC의 현재 방향

• 위와 같은 RPC 문제에도, RPC는 사라지지 않음.
• 앞서 설명한 모든 부호화 위에는 다양한 RPC 프레임워크가 개발되었음.
  • ex) 스리프트와 아브로는 RPC 지원 기능을 내장하고 있음.
  • gRPC는 프로토콜 버퍼를 이용한 RPC 구현임.
  • 피네글(Finagle)은 스리프트를 사용하고 Rest.li는 HTTP위에 JSON을 사용함.
• 차세대 RPC 프레임워크는 원격 요청이 로컬 함수 호출과 다르다는 사실을 더욱 분명히 함.
  • ex) 피네글과 Rest.li는 실패할지도 모를 비동기 작업을 캡슐화하기 위해 퓨처(future), 프라미스(promise)를 사용함.
    • 퓨처는 병렬로 여러 서비스에 요청을 보내야 하는 상황을 간소화하고, 요청 결과를 취합함.
    • gRPC는 하나의 요청과 하나의 응답뿐만 아니라 시간에 따른 일련의 요청과 응답으로 구성된 스트림을 지원함.
• 위 프레임워크 중 일부는 서비스 찾기(service discovery)를 제공함.
  • 즉, 클라이언트가 특정 서비스를 찾을 수 있는 IP 주소와 포트 번호를 제공함.
  • p214 요청 라우팅에서 다시 다룸
• REST 상에서 JSON과 같은 부류의 프로토콜보다 이진 부호화 형식을 사용하는 사용자 정의 RPC 프로토콜이 우수한 성능을 제공할지도 모름.
  • 하지만 RESTful API는 다른 중요 이점이 있음.
    • 실험과 디버깅에 적합하고, 모든 주요 프로그래밍 언어와 플랫폼을 지원하고, 사용 가능한 다양한 도구 생태계가 있음. (p138 참고)
    • 이러한 이유로 REST는 공개 API의 주요한 방식임.
    • RPC 프레임워크에서 주요 초점은, 같은 데이터센터 내의 같은 조직이 소유한 서비스 간 요청에 있음.

데이터 부호화와 RPC의 발전

• 발전성이 있으려면 RPC 클라이언트와 서버를 독립적으로 변경 & 배포할 수 있어야 함.
• RPC 스키마의 상하위 호환 속성은 사용된 모든 부호화로부터 상속됨.
• RPC가 조직의 경계를 넘나드는 통신에 사용된다면, 서비스 호환성을 유지하기 어려움.
  • 호환성을 깨는 변경이 필요하면, 서비스 제공자는 보통 여러 버전의 서비스 API를 함께 유지함.
    • API 버전 관리에 대한 합의는 사실 없음.
    • RESTful API는 URL 이나 HTTP Accept 헤더에 버전 번호를 사용하는 방식이 일반적임.
    • 특정 클라이언트를 식별하는 데는 API 키를 사용할 수 있다.

메시지 전달 데이터플로

• RPC와 데이터베이스 간 비동기 메시지 전달 시스템을 살펴본다.
  • 이 시스템은 클라이언트 요청을 낮은 지연 시간으로 다른 프로세스에 전달한다는 점에서 RPC와 비슷함.
  • 메시지를 직접 전송하지 않고 임의 메시지를 저장하는 메시지 브로커(message broker), 또는 메시지 큐(message queue)나, 메시지 지향 미들웨어(message-oriented middleware)라는 중간 단계를 거쳐 전송한다는 점은 데이터베이스와 유사함.
  • 메시지 브로커를 사용하는 방식은 직접 RPC를 사용하는 방식과 비교하여 여러 장점이 있음.
    • 수신자가 사용 불가능하거나 과부하 상태라면 메시지 브로커가 버퍼 처럼 동작할 수 있음.
    • 죽었던 프로세스에 메시지를 다시 전달할 수 있어 메시지 유실을 방지함.
    • 송신자가 수신자의 IP 주소나 포트 번호를 알 필요가 없음.
    • 하나의 메시지를 여러 수신자로 전송할 수 있음.
    • 논리적으로 송신자는 수신자와 분리됨.
  • 메시지 전달 통신은 단뱡향 이라는 점에서 RPC와 다름.
    • 즉, 송신 프로세스는 메시지에 대한 응답을 기대하지 않음.

메시지 브로커

• 과거의 메시지 브로커
  • 팁코
  • IBM 웹스피어
  • 웹메소즈
• 최근 메시지 브로커
  • 래빗MQ
  • 액티브MQ
  • 호닛Q
  • 나츠
  • 아파치 카프카
• 세부적인 전달 시맨틱은 구현과 설정에 따라 다양하지만, 일반적으로 메시지 브로커는 다음과 같이 사용함.
  • 프로세스 하나가 메시지를 이름이 지정된 큐나 토픽으로 전송함.
  • 브로커는 해당 큐나 토픽 하나 이상의 소비자(consumer) 또는 구독자(subscriber)에게 메시지를 전달함.
  • 동일한 토픽에 여러 생산자(producer)와 소비자가 있을 수 있음.
  • 토픽은 단방향 데이터플로만 제공함.
• 메시지 브로커는 특정 데이터 모델을 강요하지 않음.
  • 메시지는 일부 메타데이터를 가진 바이트열이므로 모든 부호화 형식을 사용할 수 있음.

분산 액터 프레임워크

• 액터 모델(actor model)은 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델임
  • 스레드(경쟁 조건, 잠금, 교착상태와 연관된 문제들)를 직접 처리하는 대신, 로직이 액터에 캡슐화됨.
  • 각 액터는 하나의 클라이언트나 엔티티를 나타냄
  • 액터는 로컬 상태를 가질 수 있고, (다른 액터와 공유 X) 비동기 메시지의 송수신으로 다른 액터와 통신함.
  • 액터는 메시지 전달을 보장하지 않음.
    • 에러 상황에서 메시지 유실될 수 있음.
  • 액터 프로세스는 한 번에 하나의 메시지만 처리하기에 스레드에 대해 걱정할 필요 없음.
  • 각 액터는 프레임워크와 독립적으로 실행 가능함.
• 분산 액터 프레임워크에서는 이 프로그래밍 모델은 여러 노드 간의 애플리케이션 확장에 사용됨.
  • 송신자와 수신자의 노드가 같은지 여부와 상관없이 동일한 메시지 전달 구조를 사용함.
    • 만약 다른 노드에 있는 경우, 메시지는 명백하게 바이트열로 부호화되고 네트워크를 통해 전송되며, 다른 쪽에서 복호화함.
  • 액터 모델은 단일 프로세스 안에서 메시지가 유실될 수 있기에 위치 투명성은 RPC보다 액터 모델에서 더 잘 동작함.
  • 네트워크 지연은 동일한 프로세스 안에서 더 높을 수 있지만, 액터 모델을 사용한 경우, 로컬과 원격 통신 간 근본적인 불일치가 적음.
• 분산 액터 프레임워크는 메시지 브로커와 액터 프로그래밍 모델을 단일 프레임워크에 통합함.
  • 액터 기반 애플리케이션 순회식 업그레이드시, 새노드 ↔ 예전 노드 간의 통신이 있을 수 있기에 상하위 호환성을 주의해야 함.
• p142 에 인기있는 분산 액터 프레임워크에 대한 메시지 부호화 처리를 설명함.