데이터 중심 애플리케이션 설계 : 4장 부호화 발전

LDM 3기 책 스터디 발표 자료이다. 

4장. 부호화 발전

 

한 줄 요약

시스템상 모든 데이터는 하위 호환성과 상위 호환성을 제공하는 방식으로 부호화 해야한다.

---

요약

1. 다양한 데이터 부호화 형식과 호환성 속성

• 프로그래밍 언어에 특화된 부호화는 단일 프로그래밍 언어로 제한되며 상위 호환성과 하위 호환성을 제공하지 못하는 경우가 있음JSON, XML, CSV 같은 텍스트 형식은 널리 사용됨
  • 이들간 호환성은 데이터타입을 사용하는 방법에 달려 있어 스키마가 있으면 유용할 수 있으나 반대로 불편할 수 있음
• 이진 스키마
  • 스리프트, 프로토콜, 아브로 같은 이진 스키마 기반은 짧은 길이로 부호화 되어 효율적
  • 단, 이진 부호화는 사람이 읽을 수 있도록 하기위해 복호화 과정이 필요함

2. 데이터 저장과 전달에 사용되는 데이터플로 모드3

• 데이터베이스에 기록하는 프로세스가 부호화하고 데이터베이스에 읽는 프로세스가 복호화하는 데이터베이스
• 클라이언트가 요청을 부호화하고 서버는 요청을 복호화하고 응답을 부호화하고 최종적으로 응답을 복호화하는 서비스 호출 (RPC와 REST API)
• 송신자가 부호화하고 수신자가 복호화하는 메시지를 서로 전송해서 노드간 통신하는 비동기 메시지전달 (메시지브로커나 액터를 이용)

 

---

요약

배경

시간이 지남에 따라 사용자의 요구사항, 비지니스 환경이 변하면서 애플리케이션의 기능은 추가하거나 변경됨

이 변화에 DB의 변화도 포함됨. 컬러, 필드가 추가되거나 삭제되기도함.

→ DB관점의 변경은 바로 적용가능하나 애플리케이션의 코드는 바로 되지 않는 경우가 많음.

애플리케이션의 코드는 바로 되지 않는 이유 code의 update 방식은 rolling update 방식으로 진행됨 client의 경우 업데이트를 바로 하지 않는 사용자도 있기 때문

 

💡 호환성 하위 호환성 새로운 코드는 이전 코드가 기록한 데이터를 읽을 수 있어야 한다. 새로운 코드는 기존 데이터에 대해 알기에 큰 문제가 없다. 상위 호환성 이전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다. 새 버전에 추가된 것을 무시할 수 있어야 하므로 적용이 어렵다.

 

 

1. 데이터 부호화를 위한 다양한 형식

메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 전홍하고 싶을 때(네트워크를 통한 전송, 파일 기록 등) 바이트열로 부호화해야함.

데이터 부호화 형식

인메모리의 데이터 구조로 데이터 유지됨(object,array, tree.. ) →데이터 전환 메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 보내고 싶을 때는 바이트열로 부호화 필요 → 바이트열 데이터를 파일에 쓰거나 네트워크를 통해 전송할 때 사용되는 데이터 구조

인메모리 표현에서 바이트열로의 전환을 부호화(직렬화 또는 마샬링).

그 반대를 복호화 (파싱, 역직렬화, 언마샬링) 이라고 한다

Ex) Java - Serializable, Ruby - Marshal, Python - pickle 등등

 

부호화 형식

JSON과 XML, 이진 변형

표준화된 부호화로서, JSON과 XML 이 많이 사용됨.(+ CSV)

수의 부호화에는 많은 애매함이 존재. 정수와 부동소수점 수를 구별 X, 정밀도 지정 X.

이 애매함은 큰 수를 다룰때 문제. 2^53보다 큰 정수를 다룰때 부정확해 질 수 있음.

JSON, XML은 유니코드 문자열은 잘 지원, 그러나 이진문자열을 지원하지 않음.

이러한 결점에도 JSON, XML, CSV는 사용하기 충분하고 인기 있음.

특히, 데이터 교환 형식에서 사용하기 매우 좋음.

 

Binary Encoding (이진 부호화)

이진 형식은 json, xml과 비교해 더 적은 공간을 사용함.

→ json(message pack, BSON, BJSON, BISON, smile), XML(WBXML, 패스트인포셋)) 용으로 사용 가능한 이진 부호화 개발이 되었으나 JSON, XML만큼 널리 사용되지는 않음.

이진 부호화 형식

• 프로토콜 버퍼와 스리프트
• 아브로

장점 :

• XML, JSON 스키마보다 간단
• 자세한 유효성 검사 규칙 지원
• 구현과 사용이 간단하여 광범위한 프로그래밍 언어 지원 방향으로 성장중
• 부호화된 데이터에서 필드명 생략가능하므로 당양한 이진 json 변형보다 크기 적을 수 있음.
• 스키마 데이터베이스를 유지하면 스키마 변경이 적용되기 전에 상위 호환성을 확인할 수 있음

 

 

2. 데이터 부호화 형식이 데이터 저장과 통신에 사용되는 방식

데이터플로 모드

프로세스 간 데이터 전달 방법 3

• 데이터베이스를 통해
• 서비스 호출을 통해(REST, RPC)
• 비동기 메세지 전달을 통해

 

 

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

데이터베이스에 기록하는 프로세스는 데이터를 부호화하고, 데이터베이스에서 읽는 프로세스는 데이터를 복호화함

호환성

• 과거에 기록된 데이터 읽어야하므로 하위 호환성 필요.
• 순회적 업그레이드 중 새로운 버전의 코드로 기록되고, 예전 버전의 코드로 그 값을 읽을 수 있으므로 상위 호환도 필요.
• 데이터를 새로운 스키마로 마이그레이션 작업은 가능하지만 많은 리소스필요함. → 대부분 관계형 데이터베이스는 기존 데이터를 다시 기록하지 않고 NULL을 기본값으로 갖는 새로운 칼럼 추가하는 간단한 스키마 변경 허용. → 기본 저장소가 여러 가지 버전의 시키마로 부호화된 레코드를 포함해도 전체 데이터베이스가 단일 스키마로 부호화된 것 처럼 보이게함

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

하나의 프로세스가 네트워크를 통해 다른 프로세스로 요청을 전송, 응답을 기다리는 방식.

가장 일반적인 방법으로는 클라이언트와 서버의 두 역할로 배치.

• 서버가 네트워크를 통해 API를 공개(서비스)하고 클라이언트는 이 API로 요청을 만들어 서버에 연결.

RPC

• 프로그램에서 함수 호출하듯이 데이터를 요청
• 단점
  • 로컬 함수 결과, 예외 문제
  • 실패한 네트워크 재요청시 처리만되고 응답 유실 가능
  • 실행 시간 문제

웹서비스

PRC 아이디어 기반으로 웹 서비스 형상 만들어짐.

• 서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용하는 방식.
• 가장 대중적인 방식 : REST, SOAP

 

서비스와 데이터베이스 차이점

service 는 비즈니스 로직에 기반하여 입출력을 제한하고, 정해진 입출력만 허용해 API를 공개함.

REST

• 예시 : GET http://restapi.test.com/user/1/todo -> 유저 1번의 할 일(todos)를 가져와 주세요. (필요한 데이터를 url로 표현)
• HTTP를 원칙을 토대로 설계한 원칙. 간단한 데이터 타입을 강조
• URL을 사용해 Resource를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상. URL의 구조로 필요한 데이터를 요청

SOAP

• 네트워크 API 요청을 위한 XML 기반 프로토콜
• HTTP 상에서 일반적으로 사용하지만, HTTP와 독립적이며 HTTP 기능을 사용하지 않음.
• 그대신 다양한 기능을 추가한 광범휘하고 복잡한 여러 관련 표준을 제공
• 사람이 읽을 수 없도록 설계되어 도구나 IDE에 크게 의존
• 대부분은 RESTful API 를 통한 간단한 접근 방식을 선호

 

3) 메시지 전달 데이터플로

• RPC와 데이터베이스간 비동기 메시지 전달 시스템.
• 클라이언트 요청을 낮은 지연 시간으로 다른 프로세스에 전달한다는 점에서 RPC와 비슷
• 메세지를 직접 네트워크 연결로 전송하지 않는다는 점에서 데이터베이스와 유사.
  • 임시로 메시지를 저장하는 메세지 브로커를 이용
  • 또는 메시지 지향 미들웨어라는 중간 단계를 거쳐 전송

 

Message broker를 사용했을때 장점

메시지 전달 통신은 일반적으로 단방향이라는 점이 RPC와 다르다. 즉, 송신 프로세스는 대게 메시지에 대한 응답을 기대하지 않음.

• 수신자가 사용 불가능하거나 과부하 상태라면 메시지 브로커가 버퍼처럼 동작할 수 있음.
• 죽었던 프로세스에 메세지를 다시 전달할 수 있기 때문에 메시지 유실을 방지할 수 있음.
• 송신자가 수신자의 IP 주소나 포트 번호를 알 필요가 없음.
• 하나의 메세지를 여러 수신자로 전송할 수 있음.
• 논리적으로 송신자는 수신자와 분리된다할 뿐이고 누가 소비하는지 상관하지 않음.

메시지 브로커

• 최근엔 래빗MQ, 액티브MQ, 호닛Q, 아파치카프카 같은 오픈소스 구현이 대중화 됐다
• 일반적인 메시지브로커 사용 방식
  • 메시지이름이 지정된 큐나 토픽으로 전송
  • 브로커는 해당 큐나 토픽을 이상의 컨슈머 또는 구독자에게 메세지를 전달
  • 동일한 토픽에 여러 생산자와 소비자가 있을 수 있음.
• 토픽은 단방향 데이터플로만 제공

 

감상

REST 방식을 프로젝트나 업무에 많이 사용했지만 주로 데이터 수집하는 입장이어서 버전같은거는 깊게 생각해보적이 없었다. 그리고 데이터 전달/전송 플로우 역시 방법을 정할 때는 어디서 어디에 저장/전달할까 라는 관점으로만 접근했었다. 다음에 아키텍처 설계할 떄는 각 방식의장단점을 좀 더 고려해서 설계해봐야겠다.