[데이터 중심 애플리케이션 설계] 04. 부호화와 발전

 

 

 

 

 

 

[데이터 중심 애플리케이션 설계] 04. 부호화와 발전

 

1. 데이터 부호화 형식

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

1.1 언어별 형식

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

1.2 JSON과 XML, 이진 변형

• XML과 CSV는 수와 숫자로 구성된 문자열을 구분할 수 없음
• JSON은 문자열과 수를 구분하지만 정수와 부동소수점을 구별하지 않고 정밀도를 지정하지 않음
• 이 문제는 큰 수를 다룰 때 문제가 됨
• 여러 단점에도 불구하고 특히 데이터 교환 형식으로 사용하기에 매우 좋다.
•  

2. 데이터플로 모드

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

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

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

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

• 일반적으로 클라이언트-서버 방식
• 서버가 공개한 API를 서비스 라고 부름
• 웹 브라우저만 클라이언트가 아니라 서버 자체가 다른 서비스의 클라이언트 일 수 있음
• 이러한 애플리케이션 개발 방식을 마이크로서비스 설계(microservices architecture, MSA)라고 부름
  • MSA의 핵심 설계 목표는 서비스를 배포와 변경에 독립적으로 만들어 애플리케이션의 변경과 유지보수를 더욱 쉽게 만드는 것

2.2.1  웹서비스

• 서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용할 때 이를 웹 서비스라고 한다.
•  REST란?
  • REST는 프로토콜이 아니라 HTTP의 원칙을 토대로 한 설계 철학
  • 간단한 데이터 타입을 강조하며 URL을 사용해 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP 기능을 사용
  • REST 원칙에 따라 설계된 API를 RESTful 이라고 부름
• SOAP이란?
  • 네트워크 API 요청을 위한 XML 기반 프로토콜
  • HTTP 상에서 사용되나, HTTP와 독립적이며 대부분의 HTTP 기능을 사용하지 않는다.
  • SOAP은 사람이 읽을 수 없고, SOAP 메시지를 수동으로 구성하기에는 너무 복잡하기 때문에 도구 지원과 코드 생성과 IDE에 크게 의존한다.

2.2.2 원격 프로시저 호출(RPC)

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

 

3. 비동기 메시지 전달 시스템

3.1 메시지 브로커

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

3.2 분산 액터 프레임워크

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