4. 부호화와 발전

하위호환성 / 상위호환성을 반드시 챙겨야 한다.
- 예시
  - int32 → int64 업그레이드 할 경우, 기존 클라이언트는 새로운 64bit 데이터 못 받을 가능성 있음

프로그래밍 언어 내장 부호화 라이브러리는 문제가 많다.

범용성 문제
- 함부로 라이브러리 언어를 바꾸지 못함
성능 문제

보안 문제

import pickle  # Python's serialization module (pickle)

# An example of a vulnerable server that deserializes data
def vulnerable_server(serialized_data):
    data = pickle.loads(serialized_data)  # Deserialize the data
    # Process the data - assuming it's a harmless object

# Malicious serialized data
malicious_data = b'\x80\x04\x95\x1c\x00\x00\x00\x00\x00\x00\x00\x8c\x08__main__\x94\x8c\x04eval\x94\x93\x94.'
# eval 함수가 실행된다.

# Attempt to deserialize the malicious data
try:
    vulnerable_server(malicious_data)
except Exception as e:
    print(f"Error: {e}")
In this example, the pickle module in Python is used for serialization and deserialization. The eval function is invoked when the malicious data is deserialized, which can execute arbitrary code provided by the attacker. This can lead to security breaches, data leaks, or other malicious activities.

트랜잭션의 직렬화 ≠ 인코딩에서의 직렬화

텍스트 부호화

JSON/XML

문자 기반 전송
- 이진 데이터 전송은 기본 지원 대상이 아님
  - base64로 문자열로 인코딩해서 전송(많이 사용하는 우회 방식)
- 수와 숫자(digit)을 구분 문제
  - JSON은 구분하지만 부동소수점 수 문제가 있음
약한 스키마 지원
- 스키마 사용을 강제하지 않으므로 부호화/복호화 로직을 직접 하드코딩 해야 할 수 있음
  - (Jackson?)
- 모든 데이터 값에는 필드명이 들어가야함
  - 성능 최적화 한계(JSON → BSON, BJSON, BISON, MessagePack 등)

이진 부호화

Protocal Buffer, Thrift, Avro 등

성능 최적화
강한 스키마 지원
- 필드명 입력 필요 없음
고유의 스키머 정의를 통한 코드 생성 도구 존재
인코딩 방식
- key의 이름을 전송하지 않는 경우
- 스키마에서 key의 이름과 매핑되는 값 사용
  - annotation

스키마 발전

스키마는 시간이 지남에 따라 ‘필연적’으로 변한다.
필드 태그를 새로 부여하면서 상위 호환성 유지
- 하위 버전은 새로운 필드 태그를 읽지 않는다.
하위 호환성
- required 필드는 추가/삭제 불가능 ⇒ optional로 대체

프로세스 간 데이터플로

프로세스 간의 (공유 메모리가 아닌) 네트워크를 통한 데이터 전달

데이터베이스

데이터베이스를 통한 부호화
전송 시점과 읽는 시점의 비연결성
- 같은 프로세스(과거, 미래)끼리 주고 받을 수도 있음
스키마 발전 시 데이터 유실 가능성
- select → insert 하는 애플리케이션이 구버전일 경우 select 할 때 새로 추가된 필드를 변환하지 못해서 insert 시 누락될 수 있음
  - 나: 보통은 select 해온 로우를 update만 하기 때문에 신버전 컬럼이 유실된 경험을 해보지는 않음
코드의 수명 <<<<< 데이터의 수명
- 하나의 데이터에는 여러 버전의 코드 스키마가 적용되어 있다
- 데이터 웨어하우스
  - 스냅숏을 만들 때는 하나의 일관된 스키마로 저장 가능
    - 성능 최적화 가능성

서비스

서비스 = 공개 API
SOA
- 서비스 지향 아키텍처
  - 최근에는 Microservice Architecture로 발전
종류
- 웹 기반
  - 웹으로 전송된다는 것을 인지
  - REST
    - HTTP 프로토콜 응용
      - 캐싱,보안 정책 등
    - 접근성 높은 생태계
      - ex) curl을 통해 간단한 테스트 가능
    - 호환성
      - 추가되는 파라미터에 optional
      - accept 헤더 버전
  - SOAP
    - ≠ SOA
    - HTTP 프로토콜 스펙을 거의 응용 X
    - XML 사용, 작성이 까다로움
      - 부호화된 메시지는 사람이 이해할 수 없음
      - 프레임워크를 통한 XML → 부호화, 인스턴스 적재 및 로직 호출
- RPC
  - 로컬 함수 호출처럼 다룬다.
    - 지역 투명성
  - 네트워크 세부사항 미반영
    - 매개변수로 포인터 사용 불가능 → 전부 부호화 해야 함
      - 거대한 객체일 경우 이슈 가능성
    - 네트워크 이슈로 터지는 문제 상황 해결 로직 없음
      - timeout
      - 요청은 성공했는데 응답이 오지 않은 경우
        
        (실패로 간주하고 재전송할 경우)멱등성 이슈
  - 호환성 이슈
    - 서버/클라이언트의 프로그래밍 언어가 일치하지 않을 경우 부호화 등 이슈
      - Javascript number
  - 최근에는 위 이슈를 보완한 기술들이 나옴(gRPC 등)
    - 웹 기반 구현인 것을 숨기지 않음(REST의 장점 반영)
      - 응답타입 : Future
  - 보통 같은 조직의 데이터 센터에 있는 서비스들 끼리 호출할 때 사용
    - 호환성 / 네트워크 이슈 터질 가능성 적음
  - 장점
    - 이진 부호화를 통한 성능 최적화

비동기 메시징

서비스(낮은 응답 시간) + 데이터베이스(데이터를 직접 대상자에게 전송하지 않음)
fire and forget
- 어떤 프로세스가 언제 처리할 지 클라이언트에서는 관심 없음
publisher가 토픽 / 큐에 전송 → broker가 해당 토픽/큐를 구독하고 있는 subscriber에게 메시지 전송
유연한 설계 가능
- 메시지를 받은 소비자가 송신자가 구독하고 있는 큐에 메시지를 전송해서 서비스 방식과 유사하게 구현 가능
스키마
- 스키마를 강요하지 않음
- 호환성을 챙길 경우, 송신자 / 소비자 독립적인 배포 가능

액터 모델

단일 프로세스 안에서 동시성 위한 프로그래밍
액터
- 스레드, 교착 상태 등을 캡슐화한 엔티티나 클라이언트
- 비동기 메시징 방식으로 다른 액터들과 통신
  - 메시지가 유실될 수 있다고 가정
- 고유의 상태를 가짐
- 한 번에 하나의 메시지만 처리
분산 액터 프레임워크
- 액터 모델 + 비동기 데이터플로
- 액터를 단일 프로세스에 한정짓지 않음
  - 다른 프로세스, 다른 노드에도 존재할 수 있다고 가정
  - RPC 보다 지역 투명성 강함
- 순회식 업그레이드 완전 지원 X
- 예시
  - Akka, Orleans, erlang
  - erlang
    - 동시성 프로그래밍용
      - process들로 구성
    - process
      - 액터의 instance
      - ≠ OS의 process
      - 고유의 id 존재
        
        global process registry에서 해당 process가 어떤 node에 있는지 위치
        
        특정 노드에서 해당 process에 메시지를 보낼 때 local / network 전송 여부 결정

prgrms-web-devcourse / BE-Team-preArmand-Book-study

데이터 중심 애플리케이션 설계 4장 #69

4. 부호화와 발전

텍스트 부호화

이진 부호화

스키마 발전

프로세스 간 데이터플로

데이터베이스

서비스

비동기 메시징

액터 모델