데이터 중심 애플리케이션 설계 - 4. 4장 요약

부호화

애플리케이션은 시간이 지남에 따라 변한다. 기능이 변화함에 따라 데이터 역시 변경해야 하는 경우가 생긴다. 새로운 코드가 예전 코드의 데이터를 읽을 수 있는 하위 호환성은 일반적으로 어렵지 않다. 하지만 예전 코드가 새로운 코드로 기록한 데이터를 읽는 경우 다루기 어려울 수 있다.

부호화는 JSON, XML, 프토토콜 버퍼, 스리프트 등 다양한 형식 이 있다. 이런 부호화를 통해 예전 버전과 새로운 버전이 공존할 수 있는 환경을 만들 수 있다.

데이터 부호화 형식

데이터를 파일에 쓰거나 네트워크로 전송하기 위해서는 일련의 바이트열로 부호화해야 한다. 반대의 과정은 복호화라고 한다. 부호화에는 다양한 라이브러리와 형식이 존재한다.

언어별 형식

JAVA의 java.io.Serializable, 파이썬의 pickle등 내장 부호화 형식은 편리하지만 여러가지 문제가 있다.

1. 언어와 묶여있어 다른 언어에서 데이터를 읽기 어렵다.
2. 동일한 객체 유형 데이터 복원을 위해서 임의의 클래스를 인스턴스화 할 수 있어야 하며, 공격자가 임의의 바이트열을 복호화할 수 있는 애플리케이션을 얻을 수 있으면 보안 문제가 발생한다.
3. 효율성과 버전 관리를 등한시하게 된다.

JSON과 XML

표준부호화로서 JSON과 XML은 널리 알려져있고 많이 지원한다. XML은 너무 장황하다고 비판받기도 하며 그 때문에 JSON의 인기가 더 많다.

이진 부호화

JSON과 XML은 이진 형식에 비해서 많은 공간을 차지한다. 이 때문에 JSON용으로 사용 가능한 다양한 이진 부호화 개발이 이루어졌지만, JSON과 XML의 텍스트버전처럼 널리 채택되진 않았다.

스리프트와 프로토콜 버퍼

스리프트는 페이스북에서 프로토콜 버퍼는 구글에서 개발한 이진 부호화 라이브러리이다. 두 형식 모두 부호화할 데이터를 위한 스키마가 필요하다.

아브로

아파치 아브로는 프로토콜 버퍼와 스리프트와는 다르지만 둘과 대적할 새로운 이진 부호화 형식이다. 아브로 역시 스키마를 사용한다.

스키마의 장점

스리프트와 프로토콜 버퍼, 아브로 모두 스키마를 사용해서 이진 부호화 형식을 기술한다. 이 스키마는 XML스키마나 JSON스키마보다 더 간단하며 자세하게 유효성 검사를 진행한다.

데이터 플로 모드

부호화된 데이터를 다른 프로세스에서 복호화하고 하는 관계가 호환성이다. 데이터 플로는 추상적인 개념이며, 한 프로세스에서 다른 프로세스로 데이터를 전달하는 방법은 매우 많다. 그 중 보편적으로 많이 사용하는 방법은 다음과 같다

1. 데이터베이스를 통한 방법
2. 서비스 호출을 통한 방법
3. 비동기 메세지 전달을 통한 방법

데이터베이스를 통한 방법

데이터베이스는 언제난 값을 갱신할 수 있다. 애플리케이션은 일반적으로 새 버전이 옛 버전을 완전히 대체할 수 있지만, 데이터베이스는 그렇지 않다. 5년된 데이터는 다시 기록하지 않는 이상 이전 부호화 상태 그대로 있다.

이를 새로운 스키마로 기록하는(마이그레이션)하는 작업은 분명 가능하지만 대용량 데이터셋을 대상으로는 값비싼 작업이라 대부분 피한다. 대부분의 관계형 데이터베이스는 기존 데이터를 새로 기록하지 않고 널을 기본값으로 갖는 새로운 칼럼을 추가하는 간단한 스키마 변경을 허용한다.

서비스를 통한 방법 : REST와 RPC

네트워크를 통한 프로세스에서 일반적으로 클라이언트와 서버라는 두 역할을 배치한다. 서버는 네트워크를 통해 API를 공개하고 클라이언트는 이 API로 요청을 만들어 서버에 연결할 수 있다. 이 때 서버가 공개한 API를 서비스라고 한다.

서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용하면 웹서비스라고 한다. 웹서비스에는 두 가지 대중적인 방법이 있는데 REST와 SOAP이다.

REST는 간단한 데이터 타입을 강조하며, URL을 이용해 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP를 이용한다.

SOAP은 네트워크 API요청을 위한 XML기반 프로토콜이다. SOAP은 WSDL이라고 부르는 XML기반 언어로 기술하는데, WDSL은 사람이 읽을 수 있게 설꼐되지 않았고 대개 SOAP메세지를 수동으로 구성하기엔 복잡하다. 따라서 SOAP벤더를 지원하지 않는 프로그래밍 언어 사용자의 경우 SOAP서비와 통합은 어렵다.

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

웹 서비스는 1970년대부터 사용한 RPC의 아이디어를 기반으로 한다. RPC모델은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능하게 해준다. RPC는 편리해보이지만 근본적인 결함이 있다.

1. 로컬 함수 호출과 다르게 네트워크 요청은 타임아웃으로 결과 없이 반환이 될 수 있고, 이 경우 무슨 일이 있는지 알 수 없다.
2. 실패한 네트워크 요청을 다시 시도할 때 응답만 유실되는 경우가 있을 수 있다. 이 경우 재시도 작업이 여러번 시행될 수 있다.
3. 네트워크는 로컬 함수호출보다 훨씬 느리고 지연 시간은 다양하다.
4. 네트워크 요청은 모든 매개변수를 바이트열로 부호화해야 하는데 큰 객체를 사용시 문제가 있을 수 있다.

RPC의 방향

차세대 RPC는 원격 요청이 로컬 함수 호출과 다르다는 사실을 더욱 분명히 한다. 예를 들어 피네글과 Rest.li는 실패할지도 모를 비동기 작업을 캡슐화하기 위해 퓨쳐를 사용하는데, 퓨처는 병렬로 여러 서비스에 요청을 보내야 하는 상황을 간소화하고 요청 결과를 취합한다.