[데이터 중심 애플리케이션 설계] 4장

khj2872·2022년 3월 16일
1

📖 오늘 읽은 범위

4장. 부호화와 발전

만물은 변한다. 그대로 있는 것은 아무것도 없다.

  • 대부분 애플리케이션 기능을 변경하려면 저장하는 데이터도 변경 해야 함
  • 데이터 타입이나 스키마가 변경될 때 애플리케이션 코드에 대한 변경이 발생함. 하지만 대규모 애플리케이션에서 코드 변경은 보통 즉시 반영이 힘듬
  • 이것은 예전 버전의 코드와 새로운 버전의 코드, 이전의 데이터 타입과 새로운 데이터 타입이 동시에 공존할 수 있다는 뜻
  • 시스템이 원활하게 실행되려면 양방향으로 호환성 유지 필요
    • 하위 호환성: 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.
    • 상위 호환성: 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다.
  • 하위 호환성을 일반적으로 어렵지 않지만 상위 호환성은 예전 버전의 코드가 새 버전의 코드에 의해 추가된 것을 부시할 수 있어야 하므로 어려움

데이터 부호화 형식

  • 프로그램은 보통 두 가 지 형태로 표현된 데이터를 사용
    • 메모리에 객체, 구조체, 배열, 해시 테이블 등으로 데이터를 유지
    • 데이터를 파일에 쓰거나 네트워크를 통해 전송하기 위해서는 바이트열의 형태로 부호화 필요
  • 인메모리 표현에서 바이트열로의 전환을 부호화(직렬화 또는 마샬링)라고 함

언어별 형식

  • 프로그래밍 언어에 내장된 부호화 라이브러리는 편리하지만 문제점도 많음
    • 부호화는 보통 특정 프로그래밍 언어와 묶여 있어 다른 언어에서 데이터를 읽기가 매우 어려움
    • 동일한 객체 유형의 데이터를 복원하려면 복호화 과정이 임의의 클래스를 인스턴스화 할 수 있어야 함
      • 보안문제 발생 원인
      • 공격자가 임의의 바이트열을 복호화할 수 있는 애플리케이션을 확보하게 되면 클래스를 인스턴스화 할 수 있고 공격자가 원격으로 임의 코드를 실행할 수 있게 됨
    • 데이터의 버전 관리의 어려움
    • 효율성 문제
      • 부호화나 복호화에 소요되는 CPU시간과 부호화된 구조체 크기 등이 문제가 될 수 있음
      • 자바의 내장 직렬화는 성능이 좋지 않음

JSON과 XML, 이진 변형

  • XML과 CSV는 수와 숫자로 구성된 문자열을 구분할 수 없음
  • JSON은 문자열과 수를 구분하지만 정수와 부동소수점을 구별하지 않고 정밀도를 지정하지 않음
  • 이 문제는 큰 수를 다룰 때 문제가 됨
  • JSON, XML은 유니코드 문자열을 지원하지만, 이진 문자열을 지원하지 않기 때문에 Base64를 사용해 텍스트로 부호화 가능
  • CSV는 스키마가 없으므로 칼럼의 의미를 애플리케이션에서 직접 처리해야 함

스리프트와 프로토콜 버퍼

  • 아파치 스리프트(Apache Thrift)와 프로토콜 버퍼(Protocol Buffers)는 이진 부호화 라이브러리
  • 두 라이브러리 모두 부호화할 데이터를 위한 스키마가 필요
  • 스리프트는 바이너리 프로토콜과 컴팩트 프로토콜 방식으로 이진 부호화를 진행함

아브로(Avro)

  • 2009년 하둡의 하위 프로젝트로 시작
  • 부호화할 데이터 구조를 지정하기 위해 스키마를 사용
  • 두개의 스키마 언어가 존재
    • 아브로 IDL(Avro IDL): 사람이 편집할 수 있음
    • JSON 기반 언어: 기계가 더 쉽게 읽을 수 있음
  • 이진 데이터를 파싱하려면 스키마에 나타난 순서대로 필드를 살펴보고 스키마를 이용해 각 필드의 데이터타입을 미리 파악해야 함

스키마의 장점

  • 프로토콜 버퍼, 스리프트, 아브로는 XML, JSON 스크마에 비해 훨씬 간단하고 더 자세한 유효성 검사 규칙을 지원
  • 이진 부호화에는 좋은 속석이 많음
    • 부호화된 데이터에서 필드 이름을 생략이 가능해서 이진JSON 변형보다 크기가 훨씬 작음
    • 복호화를 할 때 스키마가 필요하기 때문에 스키마가 최신 상태인지를 확인 가능
    • 스키마 데이터베이스를 유지하면 스키마 변경이 적용되기 전에 상위 호환성과 하위 호환성을 확인 가능
    • 정적 타입 프로그래밍 언어에서 컴파일 시점에 타입체크를 할 수 있기 때문에 스키마에서 코드를 생성하는 기능은 유용

데이터플로 모드

  • 하나의 프로세스에서 다른 프로세스로 데이터를 전달하는 여러가지 방법
    • 데이터베이스
    • 서비스 호출
    • 비동기 메시지 전달

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

  • 데이터를 부호화하고 데이터베이스에서 읽는 프로세스는 데이터를 복호화함
  • 대용량 데이터를 마이그레이션 하는 작업은 비싼 비용의 작업이기 때문에 대부분의 관계형 데이터베이스는 기존 데이터를 다시 기록하지 않고 null을 기본값으로 갖는 새로운 칼럼을 추가함
  • 백업 목적이나 데이터 웨어하우스 저장 목적의 데이터 덤프는 복사본을 일관되게 부호화 하는 편이 나음

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

  • 일반적인 방법으로는 서버-클라이언트 방식
  • 서버가 공개한 API를 서비스 라고 부름
  • 웹 브라우저만 클라이언트가 아니라 서버 자체가 다른 서비스의 클라이언트 일 수 있음
  • 이러한 애플리케이션 개발 방식을 마이크로서비스 설계(microservices architecture, MSA)라고 부름
    • MSA의 핵심 설계 목표는 서비스를 배포와 변경에 독립적으로 만들어 애플리케이션의 변경과 유지보수를 더욱 쉽게 만드는 것
  • REST란?
    • REST는 프로토콜이 아니라 HTTP의 원칙을 토대로 한 설계 철학
    • 간단한 데이터 타입을 강조하며 URL을 사용해 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP 기능을 사용
    • REST 원칙에 따라 설계된 API를 RESTful 이라고 부름

원격 프로시저 호출(RPC)

  • RPC(remote procedure call) 모델은 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수나 메서드를 호출하는 것과 동일하게 사용 가능
  • 편리한 것 같지만 근본적인 결함이 존재
    • 로컬 함수 호출은 결과를 반환하거나 예외를 내거나 반환하지 않을 수 있음
      • 하지만 네트워크 요청은 타임아웃으로 결과 없이 반환될 수 있음
    • 실패한 요청을 retry 할때 실제로는 처리되고 응답만 유실 될 가능성 존재
      • 이 경우 프로토콜에 멱등성을 적용하지 않으면 retry가 여러 번 수행될 수 있음
    • 네트워크 요청은 로컬 함수 호출에 비해 훨씬 느림
    • 로컬 함수 호출의 경우 포인터를 로컬 메모리 객체에 효율적으로 전달 가능한 반면 네트워크 요청은 모든 매개변수는 네트워크를 통해 전송해야 하기 때문에 바이트열로 부호화를 해야함
      • 성능 이슈 존재 가능성
    • 클라이언트와 서비스는 다른 프로그래밍 언어로 구현 가능하므로 RPC 프로임워크는 하나의 언어에서 다른 언어로 데이터타입을 변환해야 함
    • RPC 프레임워크의 주요 목적은 같은 데이터센터 내의 같은 조직이 소유한 서비스 간 요청

비동기 메시지 전달 시스템

  • 수신자가 사용 불가능하거나 과부하 상태일 경우 메시지 브로커가 버퍼처럼 동작할 수 있기 때문에 시스템 안정성이 향상
  • 장애가 발생했던 수신자에 다시 메시지를 전달함으로써 메시지 유실 방지
  • 송신자가 수신자의 IP나 포트를 몰라도 됨
    • 가상 장비를 이용하는 클라우드 시스템에서 유용)
  • 하나의 메시지를 여러 수신자로 전송 가능
  • 논리적으로 송신자와 수신자는 분리됨
    • 송신자는 메시지를 게시(publish)할 뿐이고 누가 소비(consume)하는지 상관하지 않음
  • 일반적으로 단방향이라는 점이 RPC와의 차이점
  • 메시지 브로커는 보통 특정 데이터 모델을 강요하지 않음

분산 액터 프레임워크

  • 액터 모델(actor model)은 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델
  • 스레드(경쟁 조건, locking, deadlock과 연관된 문제들)를 직접 처리하는 대신 로직이 액터에 캡슐화 됨
  • 보통 각 액터는 하나의 클러이언트나 엔티티를 뜻함
  • 액터는 로컬 상태를 가질 수 있고 비동기 메시지의 송수신으로 다른 액터와 통신
  • 각 액터 프로세스는 한번에 하나의 메시지만 처리하기 때문에 thread-safe함
  • 분산 액터 프레임워크는 메시지 브로커와 액터 프로그래밍 모델을 단일 프레임워크에 통합
  • 단, 액터 기반 애플리케이션의 rolling-upgrade 를 수행하려면 메시지가 새로운 버전을 수행하는 노드에서 예전 버전을 수행하는 노드로 전송할 수 있으므로 상하위 호환성에 주의해야 함
  • 분산 액터 프레임워크의 예로는 Akka, Orleans, erlang 이 존재

0개의 댓글