새로운 포맷을 만들기보다 W3C EXI(Binary XML) 같은 기존 기술의 툴링을 개선하는 데 집중했으면 좋겠음
단순히 빠르기만 해서는 부족하고, Aeron/SBT처럼 생태계가 없는 포맷은 확산이 어려움. XML은 이미 그 생태계를 갖추고 있음
Binary XML 인코딩은 특정 상황에서는 유용하지만, 최신 바이너리 직렬화 포맷들보다 효율적이지 않음
또한 공유 참조나 순환 참조 같은 복잡한 객체 그래프를 자연스럽게 표현하지 못함
Fory 포맷은 이런 문제를 해결하면서도 언어 간 호환성과 스키마 진화를 지원하도록 처음부터 설계되었음
W3C EXI나 ASN.1 BER 중 어느 것이 더 나은지는 모르겠지만, DOP(데이터 중심 설계) 접근이 맞다고 생각함
즉, 인코딩을 먼저 설계하고 언어나 클라이언트로 거꾸로 확장하는 방식이 바람직함
벤치마크가 공정한지 의문이 듦 코드 링크를 보면, Fory 구조체가 아닌 경우 직렬화 과정에서 to/from 변환이 포함되어 있음
이 변환 과정에서 문자열 복제나 배열 재할당이 발생함
실제 시스템에서는 tonic이 8KB 버퍼를 제공하므로, 단순 Vec::default()보다 효율적일 것임
이 벤치마크는 공정하지 않음
Xeon Gold 6136 CPU 기준으로 10배 향상처럼 보이지만, to/from 변환과 Vec 복제를 제거하고 8KB 버퍼를 미리 할당하면 실제로는 3배 수준임
벤치마크는 Fory 관련 코드가 전혀 없는 tower service/codec 스타일로 다시 작성되어야 함
Fory는 테스트 중 writer pool을 사용하고 있음 관련 코드 참고
장기적으로 언어 간 호환성을 유지하려면 IDL 기반의 명세화된 계약이 필요하다고 생각함
언어에서 직렬화로 출발하는 접근은 초기엔 편하지만, 시간이 지나면 언어 런타임 변화에 취약해짐
언어가 많아질수록 공식 스키마가 중요해짐
단일 언어 프로젝트는 IDL 없이도 단순하게 유지 가능하지만, 세 언어 이상부터는 IDL이 단일 진실의 원천 역할을 함
Apache Fory는 선택적으로 IDL 지원을 추가할 예정이며, 팀 상황에 맞게 언어 우선 혹은 스키마 우선 방식을 선택할 수 있게 할 계획임
스키마 없이 언어 간 공유 타입을 어떻게 유지하는지 궁금함
타입 매핑 표가 존재함
타입 언어에서는 클래스 정의에서 스키마를 유추하고, 비타입 언어에서는 코드에 직접 주석을 다는 방식임
Python 예시는 여기에서 확인 가능함
다국어(polyglot) 팀을 주요 사용 사례로 내세우면서도 스키마 파일이 필요 없다고 하는 점이 혼란스러움 관련 블로그 글 참고
이런 접근이 장기적으로 잘 작동할지 회의적임
실제 프로덕션에서 얼마나 쓰이는지 설명이 부족해 신뢰가 가지 않음
CapnProto나 Flatbuffers 같은 직렬화 없는 포맷 대신 Fory를 써야 하는 이유가 궁금함
압축이 필요하면 zstd를 쓰면 됨
그래도 Fory의 광범위한 언어 지원과 사용 편의성은 인상적임
Python에서는 여전히 dill을 선호함 — 코드 객체까지 직렬화 가능하기 때문임 dill 링크
dill과 비교한 벤치마크 결과, Fory가 20~40배 빠르고 최대 7배 높은 압축률을 보였음 벤치마크 코드 참고
Apache Fory는 pickle/cloudpickle 대체재로도 사용 가능하며, 로컬 함수나 클래스 같은 코드 객체 직렬화도 지원함 예시 링크
pyfory는 cloudpickle 대비 3배 높은 압축률을 보이고, 보안 감사 기능으로 악성 역직렬화 공격을 방지함
Hacker News 의견
새로운 포맷을 만들기보다 W3C EXI(Binary XML) 같은 기존 기술의 툴링을 개선하는 데 집중했으면 좋겠음
단순히 빠르기만 해서는 부족하고, Aeron/SBT처럼 생태계가 없는 포맷은 확산이 어려움. XML은 이미 그 생태계를 갖추고 있음
또한 공유 참조나 순환 참조 같은 복잡한 객체 그래프를 자연스럽게 표현하지 못함
Fory 포맷은 이런 문제를 해결하면서도 언어 간 호환성과 스키마 진화를 지원하도록 처음부터 설계되었음
즉, 인코딩을 먼저 설계하고 언어나 클라이언트로 거꾸로 확장하는 방식이 바람직함
벤치마크가 공정한지 의문이 듦
코드 링크를 보면, Fory 구조체가 아닌 경우 직렬화 과정에서 to/from 변환이 포함되어 있음
이 변환 과정에서 문자열 복제나 배열 재할당이 발생함
실제 시스템에서는 tonic이 8KB 버퍼를 제공하므로, 단순 Vec::default()보다 효율적일 것임
Xeon Gold 6136 CPU 기준으로 10배 향상처럼 보이지만, to/from 변환과 Vec 복제를 제거하고 8KB 버퍼를 미리 할당하면 실제로는 3배 수준임
벤치마크는 Fory 관련 코드가 전혀 없는 tower service/codec 스타일로 다시 작성되어야 함
Fory는 테스트 중 writer pool을 사용하고 있음
관련 코드 참고
장기적으로 언어 간 호환성을 유지하려면 IDL 기반의 명세화된 계약이 필요하다고 생각함
언어에서 직렬화로 출발하는 접근은 초기엔 편하지만, 시간이 지나면 언어 런타임 변화에 취약해짐
단일 언어 프로젝트는 IDL 없이도 단순하게 유지 가능하지만, 세 언어 이상부터는 IDL이 단일 진실의 원천 역할을 함
Apache Fory는 선택적으로 IDL 지원을 추가할 예정이며, 팀 상황에 맞게 언어 우선 혹은 스키마 우선 방식을 선택할 수 있게 할 계획임
스키마 없이 언어 간 공유 타입을 어떻게 유지하는지 궁금함
타입 언어에서는 클래스 정의에서 스키마를 유추하고, 비타입 언어에서는 코드에 직접 주석을 다는 방식임
Python 예시는 여기에서 확인 가능함
관련 블로그 글 참고
CapnProto나 Flatbuffers 같은 직렬화 없는 포맷 대신 Fory를 써야 하는 이유가 궁금함
압축이 필요하면 zstd를 쓰면 됨
그래도 Fory의 광범위한 언어 지원과 사용 편의성은 인상적임
Python에서는 여전히 dill을 선호함 — 코드 객체까지 직렬화 가능하기 때문임
dill 링크
벤치마크 코드 참고
예시 링크
pyfory는 cloudpickle 대비 3배 높은 압축률을 보이고, 보안 감사 기능으로 악성 역직렬화 공격을 방지함
벤치마크 링크가 404였지만, 정상 링크를 찾았음
이름을 “Fury”에서 “Fory”로 바꾼 게 아쉬움
Fury는 빠른 직렬화 프레임워크에 딱 맞는 이름이었음
대부분의 바이너리 프로토콜은 데이터 크기를 줄이려 함
Protobuf는 정수 압축(varint, zigzag)을 사용함
단순 TPS만 비교하면 C 구조체를 그대로 전송하는 “do nothing” 방식이 항상 이길 수밖에 없음
다양한 데이터셋에서의 비교표를 제시함
Fory의 4096 타입 제한이 충분한지 궁금함
관련 코드 참고
실제로 4096개 이상의 프로토콜 메시지를 정의한 사례는 거의 보지 못했음
Rust 벤치마크 링크가 404 오류를 냄
문서 루트에서는 벤치마크 디렉터리를 찾을 수 없었음