그냥 이해를 위한 발번역임.. 필요한 내용만 작성
http://floatingsun.net/articles/thrift-vs-protocol-buffers/
여러분이 어느 정도 규모 있는(non-trivial) 소프트웨어 시스템--특별히 분산 시스템같은 것--을 개발했을때, 아마도 포팅이 잘되게 만들거나 데이터를 효율적으로 저장하고 교환하는 니드(need)가 있다는 것을 여러분 스스로가 잘 발견했을 것이다.
이것은 Apache Thrift와 Google Protocol buffer가 제공하는 것에 대한 글이다. 통신 프로토콜이나 데이터를 저장에 사용하는 구조적인 데이터를 serialization할 수 있는 언어와 플렛폼을 제공하는 두 플랫폼에 대한 내용이다.
thrift와 google protocol buffer는 가장 인기있고, 사람들로부터 어느것을 써야 합니까라고 물어는 경우가 많다. 또한 많은 토론고, 성능에 대한 이야기가 많다. 나는 이 두개의 솔루션을 여러분이 필요를 위해서 어느 것이 가장 괜찮은지 평가해서 좀더 사람들에게 밝혀 주고 싶다. (그러나 걱정도 좀 든다.)
<특징>
Thrift의 가장 큰 매력 요소중의 하나는 protocol buffer 보다 더 많은 특징들과 지원을 한다는 점이다.
1. protocol buffer는 C++, java, python을 제공한다. 다른 3rd party 코드 생성기가 있지만 공식적으로 발표한 것은 아니다. 반면, Thrift는 C++, java, python, php, ruby, erlang, perl, haskell, c#, cocoa, javascript, node.js, smalltalk, OCaml등을 지원한다.
2. protocol buffer runtime은 serialization과 deserialization 모두를 제공한다. 이것은 RPC stub을 생성할 수 있겠지만, runtime에서는 RPC 구현체를 같이 넣을 수 없다. (번역자: RPC 스택을 protocol buffer가 제공하지 않는다.따라서 알아서 구현해야 한다. ) 반면, Thrift는 RPC 구현을 (client, server) 다양한 언어에서 구현할 수 있으며, 비동기적인 구현이 가능하다.
3. thrift 의 문법은 protocol buffer보다 훨씬 많다. typedef, constants, unions, list, sets, map 같은 것은 thrift에만 있다.
요점) Thrift가 좀 더 많은 언어에 대한 특징과 지원을 가진데 반해 protocol buffer는 좀더 robust하고 consistent한 구현을 가지고 있다.
<성능>
RPC network stack이 있는 thrift와 RPC network stack이 없는 protocol buffer는 비교자체가 어렵다.
이에 대한 성능 자료는 아래 벤치 마크 싸이트를 확인하면 된다.
https://github.com/eishay/jvm-serializers/wiki/
요점) serializaion/deserialization 성능은 솔루션을 결정하는 factor는 아닐 수 있다.
추가 ) Python으로 구현한 Thrift serializaion/deserializaion은 protocol buffer 디플트 구현보다 훨씬 빠르다.
<Code Quality 와 Design>
Thrift는 facebook으로 이직한 前 구글 직원들이 개발한 코드이다. 그러나 protocol buffer의 코드는 thrift 코드에 비해서 좀 더 괜찮고(mature), 튼튼하다(robust). 이것은 thrift의 폭풍우과 같은 진화때문인데. 알려다시피 2007년에 facebook에 의해서 오픈 소스화 되었고, 최근에 apache 재단의 top level project가 되었다.
오픈소스화되면서 메일링, 홈페이지가 계속 바뀌면서 불명확한 스타일 가이드와 우선순위의 충돌등이 생겼다. 어떠한 사람과 조직이 오너쉽을 가지고 개발이 되지 못했다. 이런 변화들이 코드에 반영되었다.
(번역자 : 코드에는 역사가 담겨있다. 사람이 코딩하는 거라, 불명확한 가이드라인과 서로간의 의견충돌은 예쁘지 않은 코드로 나올 수 밖에 없다. )
반면, protocol buffer는 2008년에 오픈할 때까지 구글에서 이미 많이 사용했었다. 코딩 스타일, 일관성, 테스트 코드 모두에 구글이 신경쓰고 있던 상태였다.
이런 부분을 잘 이해하려면 다음의 코드를 확인하면 알 수 있다.
1. definition 비교
protocol buffer 의 message definition
thrift의 struct definition
2. java generator 비교
protocol buffer 의 java generator
thrift의 java generator
여기 protocol buffer의 디지안이 좀더 좋은 예제를 들고자 한다.
1. protocol buffer 컴파일러는 기본적으로 "Descriptor" 객체의 tree를 생성한다. 다양한 "Code Generator"는 이 Descriptor tree를 가지고 언어별 코드로 만들어낸다.이 것은 code 생성 과정으로부터 파싱 하는 것을 decouple하기 위함이다. 이렇게 독립적으로 만들어진 코드는 사람들이 새로운 언어를 쉽게 추가할 수 있도록 할 수 있다. 또한 runtiime시 컴파일러가 "plugin"을 호출할 수 있을 것이다.
반면 thrift 컴파일러는 코드 생성기에 매우 couple 되어 있다. 이것은 결국은 새로운 언어를 추가할 때마다 코드의 중복을 계속 만들어낼 수 밖에 없게 된다. thrift는 새로운 코드 생성기를 만들어야 할 수 밖에 없다.
2. protocol buffer에 의해서 빌더 패턴으로 만들어진 자바 클래스는 코드 생성 시점에 'required' 필드에 값이 지정되지 않은 것들에 대해서 문제를 빨리 찾기 쉽다. 반면, thrift는 닥치는 대로 자바 객체를 생성하고 serialized/deserialized될 때까지 에러를 발견하기 어렵다.
코드를 쭉 따라가다 보면 이런 예제들은 많이다.
요점 : protocol buffer는 좋은 디자인과 code quality 을 thrift에 비해서 잘 가지고 있다.
<개발 프로세스 와 오픈정도>
Thrift는 아파치 프로젝트이다. 따라서 open issue tracker를 통해서 개발이 이루어진다. 이 tracker는 누구나 접속할 수 있고, 아무나 패치를 공헌할 수 있다. 프로젝트 방향에 대해서 강한 콘트롤할 개인이나 조직이 없다.
apache 프로젝트 특성상, 실력주의를 기본으로 하고 있고, 여러개의 높은 성공 프로젝트가 있을 정도로 잘 관리되고 있다. 그러나 프로젝트가 생성하고 진화하는 프로세스는 결정이다. 리뷰 프로세스는 주로 자기네들끼리 하며 어떤 특정 로드맵이나 제품 출시 예측이나 누군가가 강하게 리드하지 못한다.
(번역자: 꼭 그런 것만은 아닌 것 같음. 예를 tomcat 같은 경우는 spring에서 tc server와 잘 구축할 수 있도록 code commitor를 잘 붙이지 않았는가? tomcat의 리딩은 실제로 spring에서 하는 듯.. 그러나 다른 프로젝트의 경우는 code commitor가 된다면 대부분 민주적으로 하는 것 같았음.)
Protocol buffer의 경우는 개발 프로세스를 오픈하지 않는다. 구글에 의해서 통째로 콘트롤 되고 있다. 강한 오너쉽을 가지고 개발되고 있다는 사실을 느낄 수 있었다.
요점 : Thrift는 많이 오픈되어 있지만, protocol buffer는 잘 하고 있다.
<누가 사용하고 있는가?>
Facebook은 Thrift를 사용하고 있지만, Google은 protocol buffer를 사용하고 있다. 그러나
위키에 나와 있듯이 많은 회사들은 빠르게 Thrift 채택을 하고 있다.
Hadoop 의 에코시스템 프로젝트가 Thrift를 사용하고 있으며 공헌을 하고 있다. (cassandra, scribe)
나는 protocol buffer의 경우에 대해서는 어떠한 사람으로부터 채택되었는지 잘 모른다.
요점 : protocol buffer보다 thrift가 더 크고 사용자 가 많다.
<문서>
요점 : protocol buffer는 문서가 좋다. 그러나 Thrift는 조만간 잡을 듯
Thrift:
The Missing Guide.