데이터중심 애플리케이션 설계 - 데이터플로 모드

데이터 플로란?

• 하나의 프로세스에서 다른 프로세스로 데이터를 전달하는 방법
• 데이터 베이스 호출을 통해, 서비스 호출을 통해, 비동기 메시지 전달을 통해 전할 .. 다양한 방법이 있다.

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

• 데이터베이스에 뭔가를 저장하는 일을 미래의 자신에게 메시지를 보내는 ㅣㅇㄹ처럼 생각할 수 있다.
• 데이터 베이스는 저장 후 미래의 자신에게 메시지를 보내는 일로 생각해보자
  • 여기서 하위호환성이 필요하다. 복호화를 위해서
• 데이터 베이스는 동시에 다양한 프로세스가 접근할 수 잇다.
  • 새로운 버전의 코드가 기록된 다음 현재 수행중인 예전 버전의 코드로 그 값을 읽을 가능성이 있다는 의미이다 따라서 상위 호환성도 필요하다.

⇒ 여기까지 데이터 베이스에서 상위 및 하위 호환성이 필요하다는 말

• 그런데, 새로운 스키마를 추가하고 예전 버전의 코드가 변경된 스키마를 읽는다면?
• 복호화 후 재부호화 하면 되지만 새 필드는 유실될 수 있다.

다양한 시점에 기록된 다양한 값

• 데이터가 코드보다 더 오래산다(data outlives code)
  • 코드는 새롭게 배포된 버전을 보지만, 데이터는 부호화 된 상태 그대로 있기 때문이다.
• 데이터 마이그레이션(migration)
  • 데이터를 새로운 스키마로 다시 기록하는 것(rewriting)
  • 보통 그냥 칼럼만 추가하면 되는데, 예외는 마이sql이다.⇒?? 이거머임 134p

보관 저장소

• 데이터 덤프: 한번 기록하고 변하지 않으므로 avro 같은 형식이 적합하다(컨테이너 파일 형태)

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

• 네트워크를 통해 통신해야하는 프로세스이다.
• 서버와 클라이언트를 배치한다 ⇒ api를 서비스라고 한다.
• 웹의 작동방식
  • 클라이언트 → 서버로 요청전송(get-받기, post-보내기)
• 표준화된 프로토콜과 데이터 타입으로 구성된다
• 웹 브라우저 뿐만 아니라 모바일 디바이스, 컴퓨터에서 실행하는 기본앱도 클라이언트도 될 수 있다.
  • Ajax: 자바스크립트 app은 XMLHttpRequest를 사용해 HTTP 클라이언트가 될 수 있다. 보통 json return
  • Api 마다 세부사항이 다르다.
• 서버 자체가 다른 서비스의 클라이언트일 수 있다. ( 웹앱 서버는 데이터베이스으 ㅣ클라이언ㅌ로 동작)
  • 보통 대용량 애플리케이션의 기능영역을 소규모 서비스로 나누는데 사용한다.
  • 서비스지향설계(SOAP): 하나의 서비스가 다른 서비스의 일부 기능이나 데이터가 필요하다면 해당 서비스에 요청을 보낸다.
    • 얘를 개선하면 마이크로서비스 설계
• 서비스는 여러 면에서 데이터 베이스와 유사하다
  • 데이터를 올리고 받는 것, 그런데 차이는 서비스는 더 엄격한 검색이 적용된다는 것(허용된 것만 검색 가능하다)
• 서비스 지향 및 마이크로서비스 아케텍쳐의 핵심 설계 목표는 서비스를 배포와 변경에 독립적으로 만들어 어플리케이션 변경과 유지보수를 더 쉽게 할 수 있게 만드는 것이다.

웹 서비스

• 서비스와 통신하기 위한 기본 프로토콜로, HTTP를 사용하는 경우이다.
• 대중적인 방법으로 REST와 SOAP이 있다.
  • REST
    • 프로토콜이아니라 HTTP의 원칙을 토대로 한 설계이다.
    • Restful api
  • SOAP
    • 네트워크 api 요청을 위한 XML기반 프로토콜이다.
    • 가장 일반적으로 사용되지만 HTTP와 독립적이며, 대부분의 HTTP기능을 사용하지 않는다. 대신 여러 기능이 추가된 WS(웹 서비스 프레임)을 제공한다.
    • XML 기반 언어를 사용: 웹서비스 기술언어, WSDL
    • 쓰기 어렵당
    • 대기업에서 많이 사용한다.
  • swagger로 알려진 오픈 api를 통해 restful api와 제품 문서를 기술하는데 사용할 수 있다.

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

• 웹서비스는 그냥 api 클라이언트의 가장 최신 형태일 뿐이다. 역시 문제가 있다.
• RPC(remote procedure call): 원격 프로시저 호출은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능하게 해준다.
  • 이를 위치 투명성이라고 핟나 (location transparency)
• 편해보이지만 문제가 있다. 네트워크 요청은 함수 호출과는 매우 다르다.
  • 로컬 함수 호출은 예측 가능하다. 그래서 제어 가능한 매개변수에 따라 성공하거나 실패한다.
  • 넽워크 요청은 예측이 어렵다. 제어 불가능한 외부 문제 등이 있을 수 있다.
    • 그런데 이런 문제들은 일상적이다. 대응 예방책이 필요하다.
• 네트워크 요청의 예외 예시
  • Timeout으로 결과없이 반환
  • 요청이 실제로는 처리되고 응답(requests.status)만 유실되는 경우. 멱등성을 적용하지 않으면 작업이 여러번 수행될 수 있다(idempotence)
  • 실행 속도가 그때그때 다르다
  • Input을 항상 네트워크가 알 수 있도록 바이트열로 부호화 해야한다.
  • 클라이언트와 서비스는 다른 언어로 구현될 수 있기 때문에 데이터 타입을 변환해야한다.

RPC의 현재 방향

• gRPC: 프로토콜 버퍼를 이용한 RPC rngus,
• Finagle(피네글): 스리프트를 사용
• Rest.li: HTTP위에 json 사용

⇒ 차세대 RPC 프레임워크는 원격 요청이 로컬함수호출과 다르다는 사실을 분명히 한다.

• Future, promise: 실패할지도 모를 비동기 작업을 캡슐화
• 프레임워크 중 일부는 서비스 찾기를 제공한다.
• 하지만 이럼에도 불구하고 restful api가 자주 쓰인다. 실험이 가능하고 범용성이 있다.
• RPC는 보통 데이터센터 내의 같은 조직이 소유한 서비스 간 요청에 초점을 맞춘다.

데이터 부호화와 RPC의 발전

• 발전성이 있으려면 서버와 클라이언트는 독립적으로 배포되어야 한다.
• 기본 가정은 모든 서버를 갱신하고 나서 모든 클라이언트를 갱신해도 문제가 없다고 가정한다.
• 조직 외부에도 제공한다는 점에서 호환성 이슈가 있을 수 있으나, 호환성을 깨는 변경이 필요하면 서비스 제공자는 보통 여러버전의 서비스 api를 함께 유지한다.

메시지 전달 데이터플로

• RPC와 데이터베이스간 비동기메시지 전달시스템(asynchronous message-passing system)
  • RCP와 유사한 점: 메시지(cli요청)을 낮은 지연시간으로 다른 프로세스에 전달
  • DB와 유사한 점: 메시지를 직접 네트워크로 전달하지 않고 message broker(queue), message-oriented middleware에 거쳐 전달한다는 점
• 사용시 장점은 아래와 같다
  • 시스템 안정성이 향상된다.
  • 죽었던 프로세스에 메시지를 다시 전달할 수 있다.
  • Ip나 포트를 알 필요가 없다.
  • 하나의 메시지를 여러 수신자로 전송할 수 있다.
• 메시지 전달 통신은 보통 단방향이라는 점이 RPC와 다르다.
• 보통 패턴이 비동기이다.

메시지 브로커

• 최근에는 래빗 mq, 액티브mq, 호닛q, 나츠, 아파치카프카 등이 대중화되었다.
• 전달 시맨틱은 구현과 설정에 따라 다양하다.
  • 프로세스가 메시지를 큐 or 토픽에 전송
  • 브로커가 소비자 혹은 구독자에게 메시지 전달
• 토픽은 단방향 데이터플로만 제공한다.
• 응답큐로도 전송이 되기는 한다.
• 특정 데이터 모델을 강요하지 않는다.

분산 액터 프레임워크

• 액터 모델(actor model): 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델. 스레드를 직접 처리하는 로직이 액터에 캡슐화 된다.

 

출처

데이터 중심 애플리케이션 설계 : 네이버 도서