😊 Go to Learn이란?
K-devcon에서 주최하는 멘토링 프로그래밍으로 각 분야에서 전문가이신 멘토분들의 멘토링을 통하여 약 2-3달간 진행하는 프로그램입니다.
Go to Learn 1기 같은 경우 Flutter, Back-end, Full-stack, Writing 등 여러가지 주제가 담긴 멘토링 프로그램이 있었습니다.
그 중 Back-end를 중심으로 진행하는 DDIA 프로그램 같은 경우 데이터 중심 애플리케이션 설계라는 책을 매주 1장 씩 정독하고 요약하면서 괸련된 이야기를 논의하면서 진행하고 있습니다.
K-devcon 이란? : IT 정보를 공유하거나 위에서 설명한 Go to Learn 스터디 및 밋업을 개최하는 활동을 하고있는 IT 커뮤니티입니다.
K-devcon 홈페이지 바로가기
📖 4장 요약 및 정리
데이터 부호화를 위한 다양한 형식 및 어떻게 스키마를 변경하고 예전 버전과 새로운 버전의 데이터와 코드가 공존하는 시스템을 어떻게 지원하는지 설명한다.
웹 서비스의 다양한 데이터 부호화 형식이 데이터 저장과 통신에 어떻게 사용되는지 알아본다.
호환성
- 상위호환성 : 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.
- 하위호환성 : 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다.
데이터 부호화 형식
언어별 형식
프로그래밍 언어에 내장된 부호화 라이브러리는 최소한의 코드로 객체를 저장하고 복원이 가능하다.
- 매우 편리하지만 문제점도 존재
- 프로그래밍 언어 간 데이터 읽기가 어려움
- 복호화 과정이 임의의 클래스를 인스턴스화 할 수 있어야한다.
- 데이터 버전 관리 및 효율성 등 나중에 생각하게 되는 요소가 있다.
JSON & XML
- JSON, XML, CSV는 텍스트 형식이라서 어느 정도 읽을 수 있다.
- 데이터 교환 형식으로 사용하기에 매우 좋은 언어이다.
이진 부호화
스리프트와 프로토콜 버퍼
스리프트랑 프로토콜 버퍼는 같은 원리를 기반으로 한 이진 부호화이다.
- 부호화할 데이터를 위한 스키마가 필요하다.
- 둘 다 스키마 정의를 사용하여 코드를 생성하는 도구가 있다.
스리프트 : 바이너리프로토콜 / 컴팩트프로토콜
- 컴팩트프로토콜은 타입과 태그를 단일 바이트로 줄이고 가변 길이 정수를 사용한다.
프로토콜 버퍼 : 컴팩트프로토콜과 유사한 방법으로 부호화가 진행 되어진다.
스키마 발전
스키마 발전 (schema evolution) : 스키마는 필연적으로 시간이 지남에 따라 변한다는 것을 정의
- 필드 태그 : 필드에 새로운 태그 번호를 부여하는 방식으로 스키마에 추가가 가능하다.
- 데이터 타입
- 프로토콜 버퍼 : repeated 표시자는 레코드에 단순히 동일한 필드 태그가 여러 번 나타낼 수 있다.
- 스리프트 : 전용 목록 데이터 타입은 중첩된 목록을 지원한다.
아브로
아브로 또한 부호화할 데이터 구조를 지정하기 위해 스키마를 사용한다.
- 아브로 IDL (사람이 편집 가능) / JSON 기반 언어 (기계가 쉽게 읽을 수 있음)
- 스키마에 태그 번호 및 필드나 데이터타입을 식별하기 위한 정보가 없음을 알 수 있다.
- 식별한 정보가 없다는 뜻은 아브로가 동적 생성 스키마에 친숙하다
기록한 코드와 정확히 같은 스키마를 사용하는 경우에만 이진 데이터를 올바르게 복호화 할 수 있다.
스키마
쓰기 스키마와 읽기 스키마
- 쓰기 스키마 : 파일, 데이터베이스에 쓰기 위해 & 네트워크를 통해 전송 등을 목적으로 알고 있는 스키마 버전을 사용하여 데이터를 부호화하는 스키마
- 읽기 스키마 : 수신 등으로 읽은 어떤 데이터를 복호화하길 기대하는 특정 스키마
- 쓰기 스키마와 읽기 스키마가 동일하지 않아도 된다. 호환 가능하면 된다. (아브로)
- 아브로 내 필드에서 널을 허용하려면 유니온 타입을 사용해야한다.
코드 생성과 동적타입 언어
- 스리프트, 프로토콜 버퍼 : 코드 생성에 의존한다.
- 스키마를 정의 후 선택한 프로그래밍 언어로 코드를 생성
- 정적 타입 언어에서 유용하다.
- 아브로 : 코드 생성 없이도 사용할 수 있다.
- 자기 기술적(Self-describing)
장점
- 부호화된 데이터에서도 필드 이름을 생략 할 수 있다.
- 복호화를 할 때 스키마가 필요하기 때문에 최신 상태인지 확신 할 수 있다.
- 적용되기 전에 상위 호환성 및 하위 호환성을 확인 할 수 있다.
- 컴파일 시점에서 타입 체크를 할 수 있기 때문에 스키마로부터 코드를 생성하는 기능은 유용하다.
데이터플로 모드
메모리를 공유하지 않는 다른 프로세스로 일부 데이터를 보내고 싶을 때 바이트열로 부호화 해야하는 작업들을 설명한다.
데이터베이스를 통한 데이터플로
데이터베이스에 뭔가를 저장하는 일을 미래의 자신에게 메시지를 보내는 일처럼 생각
- 하위 호환성은 필요하다. / 상위 호환성도 대개 필요하다.
데이터가 코드보다 더 오래 산다. : 버전은 완전히 대체할 수 있지만 데이터베이스는 그렇지 않다.
- 마이그레이션 작업은 최대한 피하기 때문이다.
보관 저장소 : 데이터 덤프는 데이터를 복사하기 때문에 데이터의 복사본을 일관되게 부호화하는 편이 낫다.
서비스를 통한 데이터플로 → REST, RPC
- 일반적인 방법 : 클라이언트와 서버
- 애플리케이션 개발 방식 : 서비스 지향 설계 / 마이크로서비스 설계
웹 서비스
서비스와 통신하기 위한 기본 프로토콜로 HTTP를 사용
- 대중적인 방법 : REST, SOAP
- REST : HTTP의 원칙을 토대로 한 설계 철학을 기반
- RESTful API
- SOAP : 네트워크 API 요청을 위한 XML 기반 프로토콜 → 웹 서비스 프레임워크
- WSDL 언어를 통하여 기술
원격 프로시저 호출(RPC)
원격 프로시저 호출 : 원격 네트워크 서비스 요청을 같은 프로세스 안에서 특정 프로그래밍 언어의 함수 및 메서드를 호출하는 것과 동일하게 사용 가능하게 해준다.
- 로컬 함수 호출은 예측이 가능하다. 그러나 네트워크 예측은 어렵다.
- 타임아웃 / 멱등성 / 원격 서비스의 과부화 / 큰 객체 / 다른 프로그래밍 언어
차세대 RPC 프레임워크
- 퓨처 (프라미스) : 실패할지도 모를 비동기 작업을 캡슐화하기 위해 사용
- 서비스 찾기 (service discovery): 클라이언트가 특정 서비스를 찾을 수 있는 IP 주소와 포트 번호를 제공
발전성
- RPC 클라이언트와 서버를 독립적으로 변경하고 배포할 수 있어야한다.
- RPC 스키마의 상하위 호환 속성은 사용된 모든 부호화로부터 상속
- 조직 경계를 넘나드는 통신에 사용된다는 사실은 서비스 호환성 유지를 더욱 어렵게 한다.
메시지 전달 데이터플로
-
REST, RPC : 하나의 프로세스가 네트워크를 통해 다른 프로세스로 요청을 전송하고 가능한 빠른 응답을 기대하는 방식
-
비동기 전달 시스템
- 시스템 안정성이 향상
- 메시지 유실을 방지
- IP 주소나 포트 번호를 알 필요 없다.
- 메시지를 여러 수신자를 전송
- 송신자는 수신자와 분리
메시지 브로커
- 프로세스 하나가 메시지를 이름이 지정된 큐나 토픽으로 전송하고 브로커는 해당 큐나 소비자 혹은 구독자에세 메시지를 전달
- 토픽은 단방향 데이터플로만 제공
분산액터 프레임워크
- 액터 모델 : 단일 프로레스 안에서 동시성을 위한 프로그래밍 모델
- 스레드를 직접 처리하는 대신 로직이 액터에 캡슐화
- 분산 액터 프레임워크에서 여러 노드 간의 애플리케이션 확장에 사용 → 동일한 메시지 전달 구조를 사용
- 기본적으로 메시지 보르커와 액터 프로그래밍 모델을 단일 프레임워크에 통합
- ex) 아카, 올리언스, 얼랭
😉 필자의 생각
4장은 여러가지 데이터 부호화와 데이터 베이스 및 서비스 등에서 활용하는 데이터 플로에 대하여 설명하는 장이었다. 특히 서비스에서 데이터 플로는 업무에서 활용하거나 관심이 있었던 분야와 밀접한 관련이 있기 때문에 인상 깊게 읽었었다.
이러한 이유로 웹 서비스 데이터 플로와 관련된 문제에 대해 논의해 보았는데 각 이야기들 중 공통된 의견으로 유지보수에 대한 주제가 많이 나왔었던 것 같다. 아마 사용자 요구사항에 맞는 데이터 설계에 따라서 영향을 많이 받는 분야이지 않을까 생각이 든다.
그 외에로 메시지 큐의 등장 배경 및 연결 방식에 대해 알 수 있었던 것 같다. 스터디 내 한 분 같은 경우 메시지 큐를 서버 내 빌드 컨테이너에 직접 연결하는 대용으로 사용된다고 한다. 나중에 메시지 큐를 사용할 수 있을 상황이 생긴다면 참고해보아도 될 점이 많았었다.
