데이터 중심 어플리케이션 설계 - 4. 부호화와 발전

애플리케이션은 필연적으로 시간이 지남에 따라 변한다. 애플리케이션의 기능을 변경하려면 저장하는 데이터(타입이나 스키마)도 변경해야 한다. 그런데 대규모 애플리케이션에선 데이터 타입이나 스키마의 변경을 즉시 반영할 순 없다. 그래서 데이터를 변경 할 때 하위 호환성과 상위 호환성을 지켜줘야 한다.

데이터 부호화 형식

데이터를 파일에 쓰거나 네트워크를 통해 전송하려면 바이트열의 형태로 부호화(직렬화, 마샬링)해야함. 반대는 복호화(파싱, 역직렬화, 언마샬링)

언어별 형식

프로그래밍 언어에는 객체를 부호화 하는 자체 라이브러리가 있지만 문제점들이 많아서 일반적으로 사용하지 않는것이 좋다.

Json과 XML 이진 변형

xml 은 장황하다. json 은 xml 대비 단순하고 csv도 어느 정도 인기 있는 언어 독립적 형식이다.

몇가지 문제점들이 더 있지만

• xml, csv 는 수와 숫자로 구성된 문자열을 구분할 수 없음. json 은 정수와 부동소수점 수를 구분하지 않음.
• json 에서 큰 수를 다룰 때 문제가됨
• 이진문자열을 지원하지 않는다. Base64를 쓰긴 하지만 base64로 인코딩 하면 크기가 33% 증가함.
• json, xml 모두 스키마를 지원하지만 번거롭고
• csv는 스키마가 없다.

다양한 용도로 사용하기 좋으며 데이터 교환형식으로 사용하기에 매우 좋다.

이진부호화를 할 수도 있긴 하지만 작은 공간절약과 파싱속도의 향상이 가독성을 해칠 만큼 가치가 있는지는 의문

스리프트와 프로토콜 버퍼

스리프트와 프로토콜 버퍼 모두 부호화할 데이터를 위한 스키마가 필요

• 스리프트 - 바이너리프로토콜
  • 타입주석(문자열, 정수 등등)
  • 필드 태그 → 필드명을 대신함
  • 길이
  • 값
• 스리프트 - 컴팩트프로토콜
  • 필드 태그 + 타입
  • 길이 + 값(숫자는 길이 없음)
• 프로토콜버퍼
  • 필드 태그 + 타입
  • 길이 + 값(숫자는 길이 없음)
  • 부호화한 값에 나타나진 않지만 필드별 required / optional 을 설정 가능
• 필드의 추가/제거에 따른 호환성
  • 필드 태그는 상위 호환성을 유지하게 한다.
    • 모르는 태그가 있는 경우 무시하면 되므로
  • 신규 추가 필드는 optional 하거나 기본값을 가져야 하위 호환성이 유지됨
• 데이터 타입 변경에 따른 호환성
  • 불가능하진 않지만 값이 정확하지 않거나 잘릴 수 있음.
  • 프로토콜 버퍼에선 optional → required 로 변경해도 문제 없음.
  • 스리프트 에선 목록 데이터 타입은 다중값으로의 변경은 허용하지 않지만 중첩된 목록 지원

아브로

• 앞선 경우완 다르게 스키마에 태그 번호가 없다.
  • 정확히 같은 스키마를 사용하는 경우에만 이진 데이터를 올바르게 복호화 할 수 있음.
• 그래도 스키마 발전(상위, 하위 호환성) 을 제공할 수 있는데
  • 부호화, 복호화 할 때 사용할 스키마의 버전을 알고 있다면
  • 복호화 할 땐 쓰기 스키마와의 비교를 통해서 어떤 값을 읽어야 할 지 알 수 있다.
  • 쓰기 스키마의 버전은
    • 대용량 파일의 쓰기 스키마가 모두 같은 경우 - 파일 앞단에 쓰기 스키마 포함
    • 쓰기 스키마가 다른 경우 - 버전을 명시 하고 디비같은곳에 버전에 해당하는 스키마 포함
    • 네트워크 연결을 통해 버전 합의 하고 연결 유지하는 동안 합의 된 버전의 스키마 사용
• 이렇게 될 수 있는 이유는 스키마 발전 규칙이 있기 때문.
  • 필드의 추가/삭제는 기본값이 있을때만
  • 필드명 변경은 하위호환성만 있음
  • 유니온 타입에 엘리먼트를 추가하는 것은 하위호환성만
• 동적 생성 스키마에 더 친숙함
  • 스키마가 json 형태여서 아브로 스키마를 상당히 쉽게 생성할 수 있음.

스키마의 장점

• xml, json 스키마보다 훨씬 간단, 더 자세한 유효성 검사 규칙 지원
• 부호화된 데이터의 크기가 json, 이진 json 보다 작음
• 스키마는 유용한 문서화 형식
• 스키마 데이터베이스 유지시, 스키마 변경에 따른 상/하위 호환성 확인 가능
• 정적 타입 프로그래밍 언어에서 스키마로 부터 코드 생성을 하는 것은 유용하다. 컴파일 시점 타입 체크를 할 수 있기 때문

데이터플로 모드

하나의 프로세스 에서 다른 프로세스로 데이터를 전달하는 방법!

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

• 데이터베이스에 값을 쓰고 / 읽으면서 다른 프로세스 간 데이터를 전달할 수 있다.
• 기존 데이터를 다시 기록하지 않고 널을 기본값으로 갖는 새로운 칼럼을 추가하는 간단한 스키마 변경을 허용
  • 전체 데이터베이스가 단일 스키마로 부호화된 것처럼 보임

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

• 서버 - 클라이언트간 데이터 전달 방법
• 서버가 클라이언트가 될 수도 있음 → 대용량 애플리케이션을 소규모 서비스로 나눠서 사용
  • SOA라고 불렸으며 최근엔 MSA 라 불림
• 각 서비스가 독립적으로 발전할 수 있기 위해서 API 간 호환이 가능해야함
• 웹 서비스는 대중적으로 REST와 SOAP 방식이 있음
• RPC-원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능하게 해줌.
  • 네트워크를 통한 서비스 호출 이라는 근본적인 결함이 있다.
  • 이러한 결함을 개선하기 위한 방법이 나오고 있음(grpc의 스트림)
  • 주로 같은 데이터센터 내의 같은 조직의 소유한 서비스 간 요청에 사용
• RPC가 같은 조직의 소유한 서비스 간 요청에 사용된다면 버전간 호환성은 지키기 쉽다.
  • 그렇지 않은 경우는 어려움

메시지 전달 데이터플로

• acl / 메시지 큐
• 메시지 지향 미들웨어
• 메시지 전달은 일반적으로 단방향이라는 점에서 RPC와 다름.
  • 응답 큐를 사용 하면 양방향 흉내를
• 메시지 부호화의 상하위 호환성을 보장한다면 메시지 브로커에게서 게시자와 소비자를 독립적으로 변경해 임의 순서로 배포할 수 있는 유연성을 얻을 수 있음
• 분산 액터 프레임워크
  • 액터는 하나의 클라이언트나 엔티티를 나타냄.
  • 비동기 메시지 송수신으로 다른 액터와 통신
  • 위치 투명성은 rpc 보다 더 잘 동작 → 단일 프로세스 안에서도 메시지가 유실 될 수 있다고 가정하기 때문
  • 롤링업데이트를 한다면 메시지의 상하위 호환성에 주의해야함.

---

궁금한점?

• api 버저닝