designing-data-intensive-applications

데이터 타입이나 스키마가 변경될 때 애플리케이션 코드에 대한 변경이 종종 발생하는데 대규모 애플리케이션에서 코드 변경은 즉시 반영할 수 없다.

시스템이 원할하게 실행되게 하려면 양방향으로 호환성을 유지해야 한다.

데이터 부호화 형식

데이터를 파일에 쓰거나 네트워크를 통해 전송하려면 바이트열의 형태로 부호화해야 한다.

언어별 형식

많은 프로그래밍 언어는 객체를 바이트열로 부호화하는 기능을 내장한다.

하지만 이런 내장 기능은 문제점이 많다.

JSON, XML, 이진 변형

많은 프로그래밍 언어에서 읽고 쓸 수 있는 표준화된 부호화로서 JSON, XML이 있다.

하지만 이런 표준화된 부호화에도 문제점이 있다.

이진 부호화

JSON은 XML 보다는 덜 장황하지만 이진 형식과 비교하면 훨씬 많은 공간을 사용한다.

메시지 팩

스리프트와 프로토콜 버퍼

스리프트는 페이스북, 프로토콜 버퍼는 구글에서 개발된 이진 부호화 라이브러리다.

스리프트의 바이너리 프로토콜

메시지 팩과 마찬가지로 타입 주석이 있고 길이와 데이터를 표시하는 문자열이 있다.

다른점은 필드 이름 대신 필드 대그를 사용한다.

스리프트 컴팩트 프로토콜

프로토콜 버퍼

필드 태그와 스키마 발전

데이터타입과 스키마 발전

아브로

하둡에서 사용하기 위해 만들어진 부호화 형식

쓰기 스키마와 읽기 스키마

스키마 발전 규칙

아브로에서도 상위 호환성, 하위 호환성을 유지할 수 있고 호환성을 유지하기 위해서는 기본값이 있는 필드만 추가, 삭제 가능하다.

필드에 널을 허용하려면 유니온 타입을 사용해야 한다. union { null, long, string } feild;

쓰기 스키마는 무엇인가?

쓰기 스키마를 알 수 있는 다양한 방법

동적 생성 스키마

아브로는 동적 생성 스키마를 고려해 설계해서 스리프트, 프로토콜 버퍼에 비해 수월하게 스키마 변경에 유연하게 대처 가능하다.

코드 생성과 동적 타입 언어

스리프트와 프로토콜 버퍼는 코드 생성에 의존하는데 아브로는 코드 생성을 선택적으로 제공하고 필요하면 JSON 파일을 열어 데이터를 볼 수 있다.

스키마의 장점

데이터플로 모드

하나의 프로세스에서 다른 프로세스로 데이터를 전달하는 다양한 방법을 알아본다.

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

새로운 버전의 애플리케이션이 기록한 데이터를 예전 버전의 애플리케이션이 갱신하는 경우 주의하지 않으면 데이터가 유실될 수 있다

보관 저장소

백업 목적으로 데이터를 보관할 때는 일관되게 부호화를 하는게 좋다

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

서버 자체가 다른 서비스의 클라이언트일 수 있고 이런 방식을 전통적으로는 서비스 지향 설계라고 불렀으면 최근에는 MSA로 재탄생되었다.

서비스 지향 및 마이크로서비스 아키텍처의 핵심 설계 목표는 서비스를 배포와 변경에 독립적으로 만들어 애플리케이션 변경과 유지보수를 더 쉽게 하는 것이다.

웹 서비스

웹 서비스에는 REST와 SOAP가 있다

원격 프로시저 호출 문제

RPC 모델은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것돠 동일하게 사용 가능하게 해준다.

하지만 로컬 함수 호출과 네트워크 요청은 다르기 때문에 실패한 요청을 다시 보내는 것과 같은 대책을 세워야 한다.

RPC의 현재 방향

차세대 RPC 프레임워크는 하나의 요청과 하나의 응답뿐 아니라 시간에 따른 일련의 요청과 응답으로 구성된 스트림을 지원한다.

메시지 전달 데이터플로

메시지 브로커를 사용하는 방식은 RPC 방식에 비해 여러 장점이 있다.

메시지 브로커

과거에는 상용 소프트웨어가 우위를 차지했지만 최근에는 래빗MQ, 카프카 등 오픈소스가 대중화 됐다.

프로세스 하나가 메시지를 큐나 토픽으로 전송하고 브로커는 소비자 또는 구독자에게 메시지를 전달한다.

분산 액터 프레임워크