어플리케이션은 새로운 기능 추가나 변경에 대응할 수 있도록 설계되어야 한다. 기존의 테이블에 새로운 column을 추가하거나 수정할 수도 있고, 새로운 테이블이 추가되기도 한다. 관계형 데이터베이스의 경우 스키마가 고정되어있는데, 스키마가 변경될 경우 해당 데이터를 처리하는 코드 또한 같이 수정되어야 한다. 하지만 어플리케이션의 규모가 큰 경우, 즉각적인 코드 수정이 어려울 수도 있다.
서버는 downtime을 최소화 하기위해 rolling update(continuous delivery)를 시도해야하고, 클라이언트의 경우에는 사용자가 업데이트를 하지 않는 경우 에러가 발생할 수 있다. 따라서 사용자들이 사용하는 어플리케이션은 신규코드와 과거코드가 조합된 어플리케이션이 상용화 되어있을수도 있다. 따라서, 신규코드와 과거코드는 서로 호환될 수 있도록 작성해야한다.
새로운 코드가 과거 코드의 데이터를 읽어오는 것은 별로 어렵지 않다. 개발자가 본인이 작성한 코드를 기억할 수도 있고, 기억하지 못하면 다시 보면 되기 때문이다. 하지만 과거코드가 신규 코드로부터 데이터를 가져오는 것은 복잡하다. 따라서 이번장에는 다양한 데이터 인코딩 포맷들과 REST, RPC등의 네트워크 통신방식을 통해 스키마 변경에 어떻게 대처하는지 알아보도록 하겠다.
데이터는 일반적으로 2가지로 나타낸다.
따라서 1 <-> 2 형식으로 데이터를 변환하는 절차가 필요하다. 1 -> 2로 데이터를 변경하는 것을 인코딩(또는 serializaion)이라 칭하고, 2 -> 1로 데이터를 변경하는 것을 디코딩(또는 parsing)이라 칭한다.
프로그래밍 언어들이 간단하게 in-memory 객체들을 byte sequence로 변경하기 위한 built-in 기능들을 제공하기도 한다. 하지만 몇몇 문제들도 있는데,
따라서 왠만하면 프로그래밍 언어의 built-in기능을 사용해서 인코딩 하는 것은 피하는 것이 좋다.
JSON과 XML이 가장 많이 사용되는 포맷이다. 이와 동시에 단점도 많은데, XML은 길이가 너무 길도, JSON은 web에서 지원해줘서 유명한 것 뿐이라는 반대의 견들이 있다. CSV도 많이 사용되긴 하는데, 활용할 수 있는 방법이 상대적으로 적다. 그래도 해당 포맷들을 사용하면 사람이 읽을 수 있는 데이터가 된다는 장점이 있는데(컴퓨터는 다 0, 1로만 저장을 하는 것과 비교하자면), 해당 포맷들이 가진 단점들도 상당하다.
이러한 단점들이 있긴 하지만, 아마 왠만하면 이것들을 사용해서 데이터를 처리할 수 있을 것이다.
데이터 사이즈가 커져서 TB단위에 들어가면 인코딩 방식이 중요해진다. JSON은 XML보다 짧지만, 둘 다 binary format과 비교하면 용량이 너무 크다. JSON에 binary encoding을 지원하기 위해 BSON, BJSON 등등이 만들어졌지만, JSON을 활용한 텍스트 인코딩에 비하면 사용율이 훨씬 떨어진다. MessagePack이라는 JSON binary encoding방식을 사용하게 되면, 아래 데이터를 인코딩할 때 15 byte를 아낄 수 있다.
{
"userName": "Martin",
"favoriteNumber": 1337,
"interests": ["daydreaming", "hacking"]
}앞으로 다양한 인코딩 기술을 소개하면서 어떻게 용량을 더 줄일 수 있을지 논할예정이다.
Apache Thrift와 Protocol Buffers(protobuf)는 인코딩 되는 데이터의 schema를 강제하는 binary encoding library이다. 위에서 작성한 JSON데이터를 Thrift를 사용해서 인코딩한다면, 아래와 같은 스키마가 필요하다
struct Person {
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests
}Protobuf도 아래와 같은 스키마를 필요로한다
message Person {
required string user_name = 1;
optional int64 favorite_number = 2;
repeated string interests = 3;
}Thrift와 Protobuf는 위에서 언급한 스키마를 활용해서 데이터를 개발자가 사용하는 프로그래밍 언어의 클래스로 인코딩한다. MessagePack의 인코딩 방식과 가장 큰 차이는, key를 string으로 가지고 있지 않고, 스키마에 선언한 숫자(필드태그)로 관리한다는 점이다. 이에 따라 용량이 감소하고, 필드 타입과, 필드 태그를 하나의 byte에 패킹하면서 용량을 아낀다. Protobuf 또한 이와 유사한 방식으로 binary encoding을 실시하고, 처음에 언급한 데이터를 33byte로 인코딩하면서, MessagePack의 50%의 공간만 사용하게 된다.
스키마는 바뀔수밖에 없다는 것을 이 장의 맨 처음에 언급했고, 이를 schema evolution이라 칭한다. Thrift와 Protobuf는 모두 field tag, 위에 작성된 1, 2, 3과 같은 숫자들을 사용해서 신규코드와 과거코드가 호환될 수 있도록 한다. 신규 클라이언트 코드가 과거 서버 코드에 데이터를 요청할 때, 과거코드에 작성되지 않은 field tag를 요청한다면, 해당 값을 무시해버린다. 이와 유사하게 과거 클라이언트 코드가 신규 서버 코드에게 신규코드에 작성된 field tag를 요청하지 않는다면, 신규 코드에는 해당 값이 작성되어있다고 하더라도, 이를 보내지 않는 식으로 에러를 방지한다.
요청하는 데이터의 타입이 변경된 경우는 어떻게 처리할까? Protobuf는 list 타입을 지원하지 않고 repeated라는 타입을 사용한다. 말 그대로 어떤 값이 반복되어 나타난다는 것이다. 따라서 신규코드나 과거코드는 해당 값이 반복되는 정도에 차이가 있을 뿐, 에러는 발생하지 않는다. Thrift는 list 타입을 지원한다. Protobuf 만큼의 유연성은 없지만 nested list를 사용해서 데이터타입 변경에 대응할 수 있다.
Apache Avro는 Hadoop에서 사용된다. Thrift, Protobuf와 유사하게 스키마를 사용한다.
record Person {
string userName;
union { null, long } favoriteNumber = null;
array<string> interests;
}위 포맷은 Avro IDL인데, JSON형식으로 나타내자면 아래 느낌이다.
{
"type": "record",
"name": "Person",
"fields": [
{"name": "userName", "type": "string"},
{"name": "favoriteNumber", "type": ["null", "long"], "default": null}, {"name": "interests", "type": {"type": "array", "items": "string"}}
]
}Thrift, Protobuf와 비교하자면, field tag라고 칭했던 숫자를 사용하지 않는다. 인코딩할 값이 더 작아지면서 Avro를 사용하면 32byte의 공간만 차지한다. 데이터 타입이나 key를 정의하지 않고, 하나로 concat된 형태이기 때문이다. 따라서 인코딩 된 데이터를 parsing할 때는, 디코딩하면서 선언된 스키마를 보고 데이터타입을 파악하는 과정이 필요하다.
Avro에 대해서는 예전에 Hadoop을 공부하면서 자세하게 작성한 글이 있다.
XML, JSON, CSV와 같은 텍스트 인코딩 방식과 비교했을 때, Thrift, Protobuf, Avro와 같은 바이너리 인코딩은 아래와 같은 장점이 있다.
위에서 언급한것과 같이 메모리를 공유하지 않는 다른 프로세스와 데이터를 주고 받으려면 byte sequence로 인코딩 해야한다. 그리고 신규코드와 과거코드가 서로 데이터를 주고 받을 때 에러가 발생하지 않도록 서비스를 설계해야한다(Compatibility). 데이터를 전달하는 측은 인코딩을 해야하고, 받는 측은 디코딩을 해야한다. 그렇다면 인코딩/디코딩의 주체는 어디인가?
데이터베이스에서 read/write를 하는 경우, read를 하는 프로세스는 디코딩하고, write하는 프로세스는 인코딩한다. 데이터베이스와 연결된 프로세스가 하나이고, 해당 프로세스와 read/write를 모두 실시할수도 있다. 그렇다면 미래의 나에게 전송할 데이터를 저장하는 기능을 구현할수도 있다(cache)
이 경우 신규코드와 과거코드의 호환이 더욱 중요해진다. 해당 프로세스의 과거코드가 cache한 값을 해당 프로세스의 신규코드가 처리할 수 없다면 에러가 발생한다. 또 주목할 점은 신규코드가 write한 값을 과거코드가 read할 수도 있다. 서비스 기획 변경이나 추가로 데이터베이스 스키마가 수정되면, 이런일은 빈번하게 발생할 수 있다.
특히 데이터베이스에서 불러온 값을 프로그래밍 언어의 객체로 디코딩 한 후에, 해당 값을 활용해서 데이터베이스에 write하기 위해 encoding을 실시한다면, 과거코드는 새롭게 추가된 값들을 잃게될 것이다.
백엔드 서버를 신규코드로 배포하면, 짧은 시간안에 과거 코드를 모두 제거하고 새로운 코드로 업데이트 할 수 있다. 하지만 인코딩되어 데이터베이스에 저장된 값들은 서버 업데이트와 관계없이 그대로 유지된다.
서버를 업데이트 할 때마다 데이터베이스도 업데이트 할 수도 있겠지만, 비용이 너무 비싸다. 특히 데이터셋이 크다면 시간이 엄청 오래걸릴 것이다. 따라서 데이터베이스는 null을 할당한다거나 하는 방식으로 스키마 변경시 비어있는 값들을 처리한다.
백업을 위해 데이터베이스의 스냅샷을 떠놓는다고 가정해보자—클라우드들이 이런걸 잘 지원해준다. 그렇다면 데이터베이서 dump는 특정 데이터의 인코딩 방식을 고려하지 않고 가장 최근의 스키마를 사용해서 값들을 인코딩할 것이다. 이럴 경우 Avro를 활용해서 인코딩 변경에 대응하는 것이 좋다.
client와 server의 경계는 명확하지 않다. 마이크로 서비스로 구현되어있다면, 일반적으로 서버 백엔드라고 불리는 서버가 다른 서버의 클라이언트 역할을 할 수도 있다. 마이크로서비스의 목적은 서비스를 분산해서 관리 및 유지보수를 편하게 하는 것에 있다.
HTTP를 사용해서 통신하는 경우 web service라고 부른다. 웹서비스에서는 REST와 SOAP를 주로 사용해서 데이터를 주고받는다.
REST는 프로토콜은 아니고, HTTP의 디자인 원칙에 가깝다.
HTTP는 주로 JSON을 사용해서 데이터를 주고받고, SOAP는 XML 포맷을 사용한다.
RPC는 1970년대에 처음 나왔는데, 서버에 있는 프로세르를 클라이언트가 실행시켜서 데이터를 가져오는 느낌으로 이해하면 된다. HTTP request를 사용해서 데이터를 받아오는 것이 아니라, 실제로 해당 프로세스의 함수를 호출하는 것이다.
아래와 같은 특징이 있다.
RPC가 문제가 많다고 하는데, 위 섹션에서 언급한 것들은 RPC의 장점이 아닌가? 좀 더 찾아보고 자료를 업데이트 해야할 것 같다.
유지보수를 위해서 RPC 클라이언트와 서버는 따로 관리되어야 한다. 데이터가 데이터베이스로부터 오는게 아니라 프로세스에서 오기 때문에, 일반적으로 서버를 먼저 업데이트하고 클라이언트를 업데이트한다. 이에따라 신규코드와 과거코드 호환도 고려해야한다.
비동기 메시징도 데이터를 주고 받는데 많이 사용된다. 특히 마이크로서비스의 경우 많이 사용되는데, 데이터를 어디다가 던져두고, 해당 데이터를 처리해야하는 쪽에서 새로운 데이터가 들어왔는지 안들어왔는지 보고있다가, 새로운 데이터가 들어오면 그 데이터를 처리하는 식이다.