데이터플로(REST, RPC, Message)

데이터 플로

• 추상화된 개념으로 하나의 프로세스에서 다른 프로세스로 데이터를 전달하는 것

• 메모리를 공유하지 않는 프로세스 간의 데이터 전달을 위해서는 부호화/복호화 과정이 필수

• 그렇다면, 누가 부호화/복호화를 수행할까?

  • 데이터 베이스

  • 서비스 호출(REST, RPC)

  • 비동기 메시지

데이터베이스를 통한 데이터플로

• 데이터베이스에 기록하는 프로세스가 부호화하며, 데이터베이스에서 읽는 프로세스가 복호화하는 방식

• 상위/하위 호환성이 모두 필요

• 애플리케이션의 새로운 버전은 배포할 때 이전 버전을 온전히 대체할 수 있지만, 이전에 삽입된 데이터는 그 이후 명시적으로 다시 기록하지 않는 한 원래의 부호화 상태 그대로 있음. 이 상태를 데이터가 코드보다 더 오래 산다라고 함

• 이 경우, 데이터를 새로운 스키마로 다시 기록하는 마이그레이션을 할 수 있지만, 대용량 데이터셋을 마이그레이션하는 것은 값비싼 작업이기 때문에 기존 데이터를 다시 기록하지 않고 Null을 기본값으로 갖는 새로운 칼럼을 추가하는 식으로 스키마를 변경함(MySQL의 ALTER TABLE은 모든 데이터를 다시 기록하므로 예외임)

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

• 가장 일반적인 방식은 클라이언트와 서버로 역할을 분리하고, 서버가 네트워크를 통해 API를 공개하면, 클라이언트는 이 API로 요청을 만들어 서버에 연결하는 방식임

• 이때의 API를 서비스라고 함

• 이런 접근 방식은 보통 애플리케이션의 기능 영역을 소규모 서비스로 나누는 데 사용. 하나의 서비스가 다른 서비스의 일부 기능이 필요하면 해당 서비스에 요청을 보내는 방식. 이를 마이크로서비스 설계(MicroServices Architecture) 라고 함

• 서비스는 서비스의 비즈니스 로직(애플리케이션 코드)로 미리 정해진 입력과 출력만 허용하는 API를 공개하며, 이러한 제약이 약간의 캡슐화를 제공함

• 서비스 지향 및 MSA의 핵심 목표는 서비스를 배포와 변경에 독립적으로 만들어 애플리케이션 변경과 유지보수를 더 쉽게 할 수 있도록 만드는 것

• 즉, 서버와 클라이언트가 사용하는 데이터 부호화는 서비스 API의 버전 간 호환이 가능해야 함

• 웹 서비스

  • 서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용할 때 이를 웹 서비스라고 함(웹 서비스는 웹뿐만 아니라, 다른 식으로도 사용되기 때문에 완전히 올바른 표현은 아님)

  • REST와 SOAP가 가장 대중적임

  • REST

    • REST는 프로토콜이 아니라 HTTP의 원칙을 토대로 한 설계 철학. 간단한 데이터 타입을 강조하며 URL을 이용해 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP기능을 사용. REST 원칙에 따라 설계된 API를 RESTful이라고 함

  • SOAP

    • SOAP는 네트워크 API 요청을 위한 XML 기반 프로토콜. HTTP와 독립적이며 대부분의 HTTP 기능을 사용하지 않음. 대신 다양한 기능을 추가한 웹 서비스 프레임 워크를 제공

    • SOAP 웹 서비스의 API는 웹 서비스 기술 언어(Web Service Description Language) 또는 WSDL이라고 불리는 XML 기반 언어를 사용해 기술. WSDL은 사람이 읽을 수 없으며 대개 SOAP 메시지를 수동으로 구성하기에는 너무 복잡함

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

  • 웹 서비스는 원격 프로시저 호출(RPC)의 아이디어를 기반으로 함

  • RPC 모델은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능하게 함(이런 추상화를 위치 투명성이라고 함)

  • 하지만, 네트워크 요청이 로컬 함수 호출과는 다르기에 발생하는 근본적인 결함이 존재

    • 로컬 함수 호출은 예측이 가능하지만, 네트워크 호출은 그렇지 않음. 네트워크 문제로 요청과 응답이 유실되거나 원격 장비가 느려지거나 요청에 응답하지 않을 수 있지만, 이런 문제들은 전혀 제어할 수 없음

    • 네트워크 요청의 타임 아웃 등으로 결과 없이 반환된다면, 무슨 일이 있었는지 쉽게 알 수 없음.

    • 실패한 네트워크 요청을 다시 시도할 때 요청이 실제로는 처리되고 응답만 유실될 수 있음. 이 경우 프로토콜에 중복제거 기법(멱등성)을 적용해야 함

    • 로컬 함수를 호출할 때는 보통 거의 같은 실행 시간이 소요되지만, 네트워크 요청은 그렇지 않음

    • 로컬 함수는 포인터를 통해 메모리의 객체에 효율적으로 전달할 수 있지만, 네트워크 요청은 모든 매개변수를 바이트열로 부호화해야함. 만일 매개변수가 큰 객체라면 문제가 될 수 있음

    • 클라이언트와 서비스가 다른 프로그래밍 언어로 구현될 수 있음. 이때 RPC 프레임워크는 하나의 언어에서 다른 언어로 데이터타입을 변환해주어야 함

  • 이러한 단점들에도 불구하고 REST는 중요한 이점이 존재

    • 실험과 디버깅에 적합(curl을 통해 간단히 요청을 보낼 수 있음)

    • 모든 주요 프로그래밍 언어와 플랫폼이 지원

    • 다양한 도구 생태계(서버, 캐시 로드 밸런서, 프록시, 방화벽, 모니터링, 디버깅 도구, 테스팅 도구 등)

  • RPC의 발전

    • 발전성이 있으려면 RPC 클라이언트와 서버가 독립적으로 변경하고 배포할 수 있어야 함

    • 이때 모든 서버를 먼저 갱신하고 나서 모든 클라이언트를 갱신해도 문제가 없다고 가정

    • 즉, 요청은 하위 호환성만 필요하고 응답은 상위 호환성만 필요

    • RESTful API는 응답에 JSON을 가장 일반적으로 사용함. 요청에는 JSON이나 URI 부호화/폼 부호화 요청 매개변수를 사용. 요청 매개변수 추가나 응답 객체의 새로운 필드 추가는 대개 호환성을 유지하는 변경으로 간주함

    • 호환성이 깨지는 변경이 필요하면 서비스 제공자는 보통 여러 버전의 API를 함께 유지

    • 보통 RESTful API는 URL이나 HTTP accept 헤더에 버전 번호를 사용하는 방식으로 버전 선택이 이루어 짐

메시지 전달 데이터플로

• REST, RPC : 하나의 프로세스가 네트워크를 통해 다른 프로세스로 요청을 전송하고 응답을 받는 방식

• 데이터베이스 : 하나의 프로세스가 부호화한 데이터를 기록하고, 다른 프로세스가 언젠가 그 데이터를 다시 읽는 방식

• 비동기 메시지 전달 시스템 : RPC와 비슷하지만, 메시지를 직접 네트워크 연결로 전송하지 않고 임시로 메시지를 저장하는 메시지 브로커(message broker) 혹은 메시지 큐(message queue)라는 중간 단계를 거쳐 전송하는 방식

  • 메시지 브로커를 이용하는 방식이 RPC와 다른 점

    • 수신자가 사용 불가능하거나 과부하 상태라면 메시지 브로커가 버퍼처럼 동작할 수 있기 때문에 안정성이 향상됨

    • 죽었던 프로세스에 메시지를 다시 전달할 수 있기 때문에 메시지 유실을 방지

    • 송신자가 수신자의 IP나 포트 번호를 알 필요가 없음

    • 하나의 메시지를 여러 수신자로 전송 가능

    • 논리적으로 송신자와 수신자는 분리됨(Pub-Sub 모델)

    • 메시지 전달은 일반적으로 단방향임. 즉, 송신 프로세스는 응답을 기대하지 않음(비동기) 프로세스가 응답을 전송할 수는 있지만, 보통 별로 채널에서 수행

  • 메시지 브로커

    • RabbitMQ, Redis, Apache Kafka 같은 오픈소스들이 강세

    • 메시지 브로커는 보통 특정 데이터 모델을 강요하지 않음. 메시지는 일부 메타데이터를 가진 바이트 열이믈 모든 부호화 형식을 사용할 수 있음

    • 부호화가 상하위 호환성을 모두 가진다면 메시지 브로커에서 Pub과 Sub을 독립적으로 변경해 임의 순서로 배포할 수 있는 유연성을 가질 수 있음