Page tree
Skip to end of metadata
Go to start of metadata

개요

  • 관계형 데이터베이스는 스키마 형태를 강요하지만 특정 시점에는 정확하게 하나의 스키마만 적용된다.
  • 스키마리스 데이터베이스는 스키마를 강요하지 않기 때문에 다른 시점에 쓰여진 이전 데이터 타입과 새로운 데이터 타입이 섞여 포함될 수 있다.
  • 결국 어느 데이터베이스라도 서로 다른 데이터 타입이 혼용되서 표현될 수 있다.
  • 이 때문에 시스템이 계속 원활하게 실행되려면 하위 호환성, 상위 호환성을 모두 제공해야 한다.
  • 4장은 다양한 데이터 부호화 형식JSON, XML, 프로토콜 버퍼, 스리프트, 아브로)을 살펴보고 각각 상위 호환성, 하위 호환성이 어떻게 지원되는지 알아본다.
    • 이와 더불어 웹 서비스, RPC, 메시지 큐에서 데이터 부호화 형식이 어떻게 사용되는지 알아본다.

데이터 부호화 형식

  • 부호화, 복호화
    • 부호화(마샬링): 인메모리 표현에서 바이트열로의 전환
    • 복호화(언마샬링): 바이트열에서 인메모리 표현으로 전환
  • 데이터를 파일에 쓰거나 네트워크를 통해 전달하려면 부호화, 복호화가 필수다.
  • 내장된 부호화를 사용하는 방식은 일반적으로 좋지 않다.
    • 부호화는 보통 특정 프로그래밍 언어와 묶여 있어 다른 언어에서 데이터를 읽기는 매우 어렵다.ㅇ
    • 동일한 객체 유형의 데이터를 복원하려면 복호화 과정이 임의의 클래스를 인스턴스화할 수 있어야 한다.
    • 데이터 버전 관리는 보통 부호화 라이브러리에서는 나중에 생각하게 된다.
    • 효율성도 종종 나중에 생각하게 된다.
  • JSON, XML, CSV 등 어떤 형식을 사용할지는 생각보다 크게 중요하지 않다.
    • 서로간의 장단점이 있기 때문이다.
    • 이미 사용하고 있는 부호화가 있는 경우에는 특히 다른 사람의 동의를 구하고 형식을 바꾸는 게 불편한 형식을 계속 사용하는 것보다 훨씬 어렵다.
  • 이진 부호화는 JSON 등 읽기 쉬운 부호화보다 공간을 절약해주지만, 이게 가독성을 희생할만큼 가치가 있는지는 확실치 ㅇ낳다.
  • 스리프트와 프로토콜 버퍼
    • 두가지 형식 모두 부호화할 데이터를 위한 스키마가 필요하다.
    • 필드의 별칭 같은 필드 태그로 철자 없이 어떤 필드를 다루는지 알려주는 간단한 방법을 사용한다.
    • 스키마 발전(시간이 지남에 따라 스키마가 필연적으로 변함)에는 어떻게 대응할까?
      • 기본적으로 필드 태그는 기존의 모든 부호화된 데이터를 인식 불가능하게 만들 수 있기 때문에 변경할 수 없다.
      • 이 때문에 필드에 새로운 태그 번호를 부여하는 방식으로 스키마에 새로운 필드를 추가한다.
      • 하위 호환성을 유지하려면 스키마는 초기 배포 후에 추가되는 모든 필드를 선택사항으로 두거나 기본값을 가져야 한다.
      • 데이터타입 변경 또한 값의 유실 가능성이 있기 때문에 하지 않는 게 좋다.
  • 아브로
    • 사람이 편집할 수 있는 아브로 IDL, 기계가 쉽게 읽을 수 있는 JSON 기반 두가지 언어를 사용한다.
    • 쓰기 스키마, 읽기 스키마가 동일하지 않아도 단지 호환 가능하면 된다는 아이디어에서 출발한다.
      • 스리프트, 프로토콜 버퍼와 다르게 필드 태그를 사용하지 않는다.
    • 스키마 발전에는 어떻게 대응할까?
      • 기본값이 있는 필드만 추가하거나 삭제할 수 있다.
      • 필드의 데이터타입 변경이 용이하다.

데이터플로 모드

  • 메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 보내고 싶을 때 부호화와 복호화가 필요하다.
  • 이런 작업은 누가 하는지에 대해 설명한다.
  • 데이터베이스를 통한 데이터플로
    • 데이터베이스에 기록하는 프로세스는 데이터를 부호화하고 데이터베이스에서 읽는 프로세스는 데이터를 복호화한다.
    • 데이터베이스에 뭔가를 저장하는 건 미래의 자신에게 메시지를 보내는일로 생각할 수 있다.
    • 이 때 하위호환성은 반드시 필요하다.
      • 그렇지 않으면 미래의 자신은 과거의 자신을 복호화할 수 없다.
    • 데이터베이스 내 값이 새로운 버전의 코드로 기록된 다음 현재 수행 중인 예전 버전의 코드로 그 값을 읽을 수도 있다.
      • 이 때문에 대개 상위 호환성도 반드시 필요하다.
    • 데이터는 코드보다 오래 산다.
    • 스키마 발전은 기본 저장소가 여러 가지 버전의 스키마로 부호화된 레코드를 포함해도 전체 데이터베이스가 단일 스키마로 부호화된 것처럼 보이게 한다.
  • 서비스를 통한 데이터플로(REST, RPC)
    • 서버와 클라이언트가 사용하는 데이터 부호화는 서비스 API의 버전 간 호환이 가능해야 한다. 반드시.
    • 웹서비스는 REST, SOAP으로 데이터플로를 제공한다.
      • REST는 설계 철학일 뿐 프로토콜은 아니다.
      • SOAP은 XML 기반의 프로토콜이다.
        • 표준으로는 다양한 확장을 정했지만, 벤더의 구현 간 상호운용성은 종종 문제를 일으킨다.
  • RPC의 문제점
    • 네트워크 요청은 로컬 함수 호출과 근본적으로 다르지만, RPC는 같은 것처럼 취급하려 했다.
    • RPC는 반드시 네트워크 문제를 고려해야 한다.
      • 네트워크 요청은 타임아웃으로 결과 없이 반환될 수 있다.
      • 실패한 네트워크 요청을 다시 시도할 때 요청이 실제로는 처리되고 응답만 유실될 수도 있다.
    • REST의 장점 중 하나는 RPC와 다르게 네트워크와 관련 있다는 부분을 숨기지 않는다는 점
  • RPC의 현재 방향
    • 원격 요청이 로컬 함수 호출과 다르다는 걸 더욱 명확하게 나타낸다.
    • 보통 같은 데이터센터 내의 같은 조직이 소유한 서비스 간 요청에 사용된다.
      • 하지만 종종 조직의 경계를 뛰어넘고 호출이 발생하고, 이 부분이 문제가 된다.
  • 메시지 전달 플로우
    • RPC에 비해 다음과 같은 장점이 있다.
      • 수신자가 사용불가능하거나 과부하 상태라면 메시지 브로커가 버퍼처럼 동작할 수 있기 때문에 시스템 안정성이 향상된다.
      • 죽었던 프로세스에 메시지를 다시 전달할 수 있기 때문에 메시지 유실을 방지할 수 있다.
      • 송신자가 수신자의 IP 주소나 포트 번호를 알 필요가 없다.
      • 하나의 메시지를 여러 수신자로 전송할 수 있다.
      • 논리적으로 송신자는 수신자와 분리된다.
    • 보통 단방향 통신이며, 비동기로 수행된다.
  • 분산 액터 프레임워크
    • 액터 모델은 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델이다.
    • 액터 모델은 단일 프로세스 안에서도 메시지가 유실될 수  있다고 이미 가정하기 때문에 위치 투명성은 RPC보다 액터 모델에서 더 잘 동작한다.

요약

  • 많은 서비스가 새로운 버전의 서비스를 동시에 모든 노드에 배포하는 방식보다 한 번에 일부 노드에만 서서히 배포하는 순회식 업그레이드가 필요하다.
  • 시스템을 흐르는 모든 데이터는 하위 호환성과 상위 호환성을 제공하는 방식으로 부호화해야 한다.
  • 여러 제약이 잇지만 약간의 주의를 기울이면 상하위 호환성과 순회식 업그레이드가 가능하다.

결론

  • 어떤 부호화, 복호화 방식으 쓰건 상위 호환성, 하위 호환성에 신경쓰자
  • No labels