TIL

04장 부호화의 발전

• 대부분의 경우 애플리케이션 기능을 변경하려면 데이터도 함께 변경해야 한다.
• 관계형 데이터베이스는 모든 데이터가 하나의 스키마를 따른다.
  • ALTER 구문으로 변경될 순 있지만 특정 시점엔 정확히 하나의 스키마가 적용
• NoSQL 등에선 스키마를 강요하지 않아 여러 데이터 타입이 섞여 표현될 수 있다.
• 스키마가 변경될 때 애플리케이션 코드도 변경되는데 시스템이 원활히 실행되려면 양방향으로 호환성을 유지해야 한다.
  • 하위 호완성 - 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.
  • 상위 호환성 - 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다.

데이터 부호화 형식

• 프로그램은 보통 두 가지 형태로 표현된 데이터로 동작된다.
  • object, struct, list, array, hash table, tree 등은 메모리상에서 다루어진다.
  • 보통 CPU에서 효율적으로 다루기 위해 포인터를 이용해 최적화된다.
• 데이터를 파일에 쓰려면 일련의 바이트열 형태로 부호화해야 한다.
  • 이 바이트열은 보통 메모리에서 사용하는 데이터 구조와 상당히 다르다.
• 부호화
  • 직렬화나 마샬링이라고도 함
  • 인메모리 표현에서 바이트열로의 전환
• 복호화
  • 파싱, 역직렬화, 언마샬링이라고도 함
  • 바이트열에서 인메모리 표현으로의 전환

언어별 형식

• 많은 프로그래밍 언어는 객체를 바이트열로 부호화하는 기능을 내장한다.
  • ex) 자바의 - java.io.Serializable
• 하지만 일시적인 목적 외에 언어에 내장된 부호화 방식은 일반적으로 좋지 않다.
  • 해당 프로그래밍 언어와 묶여 있어 다른 언어에서 데이터를 읽기 매우 어려움
  • 동일 객체 유형 데이터를 복원하려면 복호화 과정이 임의 클래스를 인스턴스화할 수 있어야 하는데 이는 종종 보안의 원인이 된다.
  • 데이터 버전 관리는 보통 부호화 라이브러리에선 나중에 생각하게 된다.
  • 효율성도 종종 나중에 생각하게 된다.
    • ex) 자바의 내장 직렬화는 성능이 좋지 않고 비대해지는 부호화로 유명

JSON과 XML, 이진 변형

• 표준화된 부호화로서 JSON과 XML이 있고 강력하진 않지만 CSV도 나름 인기 있다.
• 위 세 부호화는 일부 미묘한 문제가 존지한다.
  • 수(number)의 부호화에 많은 애매함이 존재
    • XML과 CSV에는 수와 숫자로 구성된 문자열을 구분할 수 없다.
    • JSON은 구분하지만 정밀도를 지정하지 못한다.
  • 수에 대한 애매함은 큰 수를 다룰 때 문제가 된다.
  • JSON과 XML은 유니코드 문자열은 잘 지원하지만 이진 문자열을 지원하지 않는다.
  • JSON, XML은 모두 스키마를 지원하지만 익히고 구현하기가 난해하다.
    • 스키마 사용을 강제하지 않기에 데이터를 부호화/복호화할 때 하드코딩이 필요할 수도 있다.
  • CSV는 스키마가 없기에 애플리케이션 로직이 매우 번거로워진다.
• 이러한 결점에도 JSON, XML, CSV는 데이터 교환 형식으로 사용하기 매우 좋다.
  • ex) 한 조직에서 다른 조직으로 데이터를 전송
• JSON, XML과 같은 형식은 이진 형식보다 훨씬 많은 공간을 사용한다.
  • 때문에 JSON, XML 용으로 사용 가능한 다양한 이진 부호화의 개발로 이어졌다.

스리프트와 프로토콜 버퍼

• 아파치 스리프트(Apache Thrift)와 프로토콜 버퍼(Protocol Buffers, protobuf)는 같은 원리를 기반으로 한 이진 부호화 라이브러리이다.
• 두 라이브러리 모두 부호화할 데이터를 위한 스키마가 필요하다.

// 스리프트 스키마의 예
struct Person {
	1: required string username,
	2: optional i64 favoriteNumber,
	3: optional list<string> interests
}

• JSON 부호화와의 큰 차이점으로는 필드 태그를 사용한다는 것이다.
  • 부호화된 데이터에 필드 이름 대신 필드 태그(1, 2, 3)를 포함한다.
  • 필드 이름 철자 없이도 어떤 필드를 다루는지 알려주는 간단한 빙법
  • 필드 타입과 태그 숫자로 단일 바이트로 표현
• 또 하나의 차이점은 required나 optional 표시로 필수 여부를 표현한다.
• 아파치 스리프트는 필드 태그를 통해 뛰어난 호환성을 자랑한다.
  • 각 필드를 이름이 아닌 태그 숫자로만 구분하기에 스키마의 필드 이름을 변경하기 쉽다.
  • 새로운 태그 번호를 부여하며 새로운 필드를 추가할 수 있는데 예전 코드에서 해당 스키마를 읽을 때 인식할 수 없는 태그 번호는 간단히 무시가 가능하다. (상위 호환성)
  • 한 태그 번호는 남아 있는 한 계속 같은 의미를 가지기에 새로운 코드가 예전 데이터를 항상 읽을 수 있다. (하위 호환성)

아브로

• 아브로 또한 이진 부호화 형식이다.
  • 스리프트가 하둡의 사용 사례와 적합하지 않아 하둡의 하위 프로젝트로 시작되었다.
• 아브로에는 두 개의 스키마 언아가 있다.
  • 사람이 편집 가능한 아브로 IDL(Avro IDL)
  • 기계가 더 쉽게 읽을 수 있는 JSON 기반

// 아브로 IDL 스키마 예
record Person {
	string userName;
	union { null, long } favoriteNumber = null;
	arra<string> interests;
}

// 동일한 JSON 표현
{
	"type": "record",
	"name": "Person",
	"fields": [
		{ "name": "userName", "type": "string" },
		{ "name": "favoriteNumber", "type": ["null", "long"], "default": null },
		{ "name": "interests", "type": {"type": "array", "items": "string} }
	]
}

• 아브로 스키마 특징
  • 태그 번호가 없다.
  • 아브로 이진 부호화 길이는 32바이트로 앞선 모든 부호화 중 가장 짧다.
  • 아브로 부호화는 단순히 연결된 값으로 구성되어 필드나 데이터타입을 식별하기 위한 정보가 없다.
  • 데이터를 파싱하려면 스키마의 순서대로 필드를 살펴보고 스키마로 데이터타입을 미리 파악해야 한다.
  • 즉 데이터를 읽는 코드가 데이터를 기록한 코드와 정확히 같은 스키마를 사용하는 경우에만 올바른 복호화가 가능하다.
• 쓰기 스키마와 읽기 스키마
  • 쓰기 스키마 - 데이터를 부호화할 때 사용할 스키마
  • 읽기 스키마 - 데이터를 읽을 때 사용할 특정 스키마
  • 아브로의 핵심 아이디어는 쓰기 스키마와 읽기 쓰키마가 동일하지 않아도 된다는 점이다.
  • 아브로는 쓰기 스키마에서 읽기 스키마로 데이터를 변환해 그 차이를 해소한다.
    • ex) 데이터를 읽는 코드가 읽기 스키마에는 없고 쓰기 스키마에 존재하는 필드를 만나면 이를 무시
    • ex) 데이터를 읽는 코드가 읽으려는 어떤 필드가 쓰기 스키마에는 없는 경우 읽기 스키마의 기본값으로 채운다.
• 스키마 발전 규칙
  • 아브로의 상위 호환성 - 새 버전 쓰기 스키마와 예전 버전 읽기 스키마를 가질 수 있음을 의미
  • 아브로의 하위 호환성 - 새 버전의 읽기 스키마와 예전 버전 쓰기 스키마를 가질 수 있음을 의미
• 아브로가 데이터를 읽을 때 해당 데이터를 부호화한 쓰기 스키마를 알아내는 방법
  • 많은 레코드가 있는 대용량 파일인 경우 (특히 하둡 환경)
    • 모두 동일 스키마로 부호화된 수백만 개 레코드 파일을 저장하는 용도이기에 파일 시작 부분에 한 번만 쓰기 스키마를 포함시키면 된다.
  • 개별적으로 기록된 레코드를 가진 데이터베이스인 경우
    • 모든 레코드가 동일 스키마를 가진다고 가정할 수 없다.
    • 모든 부호화된 레코드 시작 부분에 버전 번호를 포함하고 데이터베이스에는 스키마 버전 목록을 유지
  • 네트워크 연결을 통해 레코드를 보내는 경우
    • 네트워크 통신 시 설정에서 스키마 버전 합의를 할 수 있다.
    • 아브로 RPC 프로토콜의 동작으로 이후 연결 동안 합의된 스키마를 사용
• 스리프트와 프로토콜 버퍼와 달리 아브로는 동적 생성 스키마에 더 친숙하다는 장점을 가진다.
  • 관계형 DB에서 이진 형식을 사용하려는 경우 관계형 스키마에서 아브로 스키마를 상당히 쉽게 생성 가능하다.
  • 관계형 DB 스키마가 변경되어도 새로운 쓰기 스키마를 생성 후 이전 읽기 스키마를 유지하기만 하면 된다.
  • 이에 반해 스리프트나 프로토콜 버퍼는 필드 태그를 수동으로 할당해야만 한다.
• 아브로는 정적 타입 프로그래밍 언어를 위해 코드 생성을 선택적으로 제공하고 코드 생성 없이도 사용할 수 있다.

스키마 기반 이진 부호화의 장점

• 부호화된 데이터에서 필드 이름을 생략 가능해서 크기를 줄일 수 있다.
• 스키마는 유용한 문서 형식이다.
• 스키마 데이터베이스를 유지하면 스키마 변경 적용 전/후로 상위 호환성과 하위 호환성을 확인 가능하다.
• 정적 타입 프로그래밍 언어에서 사용자에게 스키마로부터 코드를 생성하는 기능이 유용하다.
  • 컴파일 타임 타입 체크가 가능

데이터플로 모드

• 데이터가 하나의 프로세스에서 다른 프로세스로 전달되는 방법은 아주 많다.
  • 전달되는 과정에서 부호화가 필요하다.
  • 데이터를 부호화하고 복호화하는 프로세스는 다르기에 호환성도 중요하다.
• 데이터플로는 애플리케이션에서 데이터가 어떻게 흐르고 변환되는지를 다루는 방식

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

• 데이터베이스에 기록하는 프로세스는 데이터를 부호화하고 읽는 프로세스는 데이터를 복호화한다.
• 다양한 시점에 기록된 다양한 값
  • 데이터베이스의 데이터들은 5밀리초 전에 기록됐을 수도 있고 5년 전에 기록됐을 수도 있다.
  • 데이터가 코드보다 더 오래 산다는 말이 있는데 코드는 계속 변하지만 오래된 데이터는 명시적으로 다시 기록하지 않는 한 원래의 부호화 상태로 그대로 존재한다.
  • 오래된 데이터를 마이그레이션하는 것도 가능하지만 값비싼 작업이기에 쉽지 않다.
  • 대부분의 관계형 DB는 다시 기록하지 않고 NULL을 기본값으로 갖는 새 칼럼을 추가하는 간단한 스키마 변경을 허용한다.
• 보관 저장소
  • 백업 목적이나 데이터 웨어하우스로 적재하려면 최신 스키마를 사용해 부호화하여 스냅숏을 만든다.
  • 다양한 시점의 스키마 버전이 섞여있더라도 일관된 부호화를 사용한다.
  • 데이터 덤프는 한 번에 기록하고 이후에 변하지 않기에 아브로 객체 컨테이너 파일 같은 형식이 적합하다.

서비스 통한 데이터플로

• 네트워크 통신이 필요할 때 통신 배치 방식으로 가장 일반적인 방법은 클라이언트와 서버가 API로 주고 받는 방식이다.
• 서버 자체가 또다른 서버의 클라이언트인 애플리케이션 개발 방식도 존재한다.
  • 서비스 지향 설계 (service-oriented architecture, SOA)
  • 마이크로서비스 설계(microservices architectre)
• 서버와 클라이언트가 사용하는 데이터 부호화는 서비스 API의 버전 간 호환이 가능해야 한다.
• 웹 서비스
  • HTTP 프로토콜을 사용하면 이를 웹 서비스라고 한다.
  • 웹 서비스에는 대중적인 두 가지 방법이 존재한다.
    • REST - 프로토콜이 아닌 HTTP 원칙을 토대로 한 설계 철학
    • SOAP - 네트워크 API 요청을 위한 XML 기반 프로토콜

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

• 원격 프로시저 호출(remote procedure call, RPC)
  • 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 언어의 메서드를 호출하는 것과 동일하게 해주는 모델
  • 이러한 추상화를 위치 투명성(location transparency)라 한다.
• RPC 방식은 근본적인 결함이 있는데 네트워크 요청은 로컬 함수 호출과 매우 다르다는 점이다.
  • 로컬 함수 호출은 예측 가능하지만 네트워크 요청은 예측이 어렵다.
  • 네트워크 문제로 실패한 호출에 대책을 세워야 한다.
• 차세대 RPC 프레임워크는 원격 요청이 로컬 함수 호출과 다르다는 사실을 분명히 한다.
  • ex) 피네글과 Rest.li는 퓨쳐(future)(promise)를 사용한다.
  • ex) gRPC는 시간에 따른 일련의 요청과 응답으로 구성된 스트림을 지원한다.
• RESTful API와 다른 RPC의 장점
  • 이진 부호화 형식을 사용하는 RPC가 REST API보다 성능이 우수하다.
  • 실험과 디버깅에 더 적합하다.
    • 웹 브라우저나 커맨드 라인 curl 등을 사용해 간단한 요청이 가능
    • 사용 가능한 다양한 언어, 플랫폼 등이 존재
• REST와 RPC는 각각 적합한 사용처가 존재한다.
  • REST - 공개 API
  • RPC - 데이터센터 내 같은 조직이 서유한 서비스 간 요청
• 데이터 부호화와 RPC의 발전
  • RPC가 조직 경계를 넘나드는 통신에 사용되기에 서비스 호환성 유지가 어려워지는 부분이 있다.
    • 클라이언트를 제어할 수 없기에 호환성은 아마도 무한정 유지되어야 한다.
  • RPC 스키마의 상하위 호환 속성은 사용된 모든 부호화로부터 상속된다.

메시지 전달 데이터 플로

• 비동기 메시지 전달 시스템
  • 클라이언트 요청을 낮은 지연으로 다른 프로세스에 전달한다는 점에선 RPC와 비슷
  • 임시로 메시지를 저장하는 메시지 브로커나 미들웨어라는 중간 단계를 거치는 점은 데이터베이스와 유사
• 메시지 브로커 사용의 장점
  • 메시지 브로커가 버퍼처럼 동작하기에 시스템 안정성이 향상된다.
  • 메시지 유실 방지
  • 송신자가 수신자의 IP나 포트를 알 필요가 없다.
  • 한 메시지를 여러 수신자로 전송 가능
• 메시지 전달 통신은 단방향이다.
  • 송신 프로세스는 응답을 기대하지 않는다.
  • RPC와 다른 점
• 일반적인 메시지 브로커 사용
  • 프로세스 하나가 큐나 토픽으로 메시지를 전송
  • 브로커는 큐나 토픽에서 하나 이사의 컨슈머 또는 구독자에게 메시지 전달
  • 동일 토픽에 여러 프로듀서와 소비자가 있을 수 있다.

분산 액터 프레임워크

• 분산 액터 프레임워크는 동시성과 분산 컴퓨팅을 위한 프로그래밍 모델로 모든 것이 액터라는 철학을 기반으로 한다.
  • 액터들은 메시지 전달을 통해서만 상호작용하는 독립적인 컴퓨팅 단위
  • 스레드, 데드락 등의 문제를 직접 처리하는 대신 로직이 액터에 캡슐화된다.
  • 각 액터는 자신만의 상태를 가지고 있으며 다른 액터와 상태를 공유하지 않음
• 분산 액터 프레임워크 모델은 여러 노드 간 애플리케이션 확장에 사용된다.
  • 송신자 수신자가 같은 노드에 있든 다른 노드에 있든 관계없이 동일 메시지 구조를 사용
  • 액터 모델을 사용하면 로컬과 원격 통신 간 근본적인 불일치가 적다.
  • 다른 노드 간 통신을 하면 메시지는 바이트열로 부호화되고 다른 쪽에서 복호화한다.
• 분산 액터 프레임워크는 메시지 브로커와 액터 프로그래밍 모델을 단일 프레임워크에 통합한다.
• 동기적으로 동작하는 RPC와 달리 비동기, 메시징 통신을 사용