etcd를 사용하는 개발자들은 etcd가 공식적으로 제공해주는 클라이언트를 사용해 서버에 접근하는 것이 일반적이다. Go로 만들어진 클라이언트를 잘 관리해주고 있어서 보통은 이 클라이언트를 쓰는 것 같다. 지금 진행하는 프로젝트 역시 Go 클라이언트를 통해 etcd에 접근한다. 이번 글은 클라이언트가 어떻게 발전해 왔는지를 알려주는 Learning의 글을 번역하고 공부했던 내용을 간단히 정리했다.

etcd 공식 페이지에 가보면 “A distributed, reliable key-value store for the most critical data of a distributed system”라고 설명하고 있다. ZooKeeper와 유사하지만 gRPC를 베이스로 하는 현대적인 코디네이터 역할을 한다. 메타 데이터를 담기 위한 Key-Value 저장소로 사용이 되는 편이고 가장 유명한 활용처는 쿠버네티스가 아닐까 싶다. 최근 사용할 일이 생기고 있어서 깊게 공부해보려고 하나씩 파헤치고 있다. 첫 글은 etcd의 데이터 모델이다.

지난 글에서 DynamoDB를 지탱하는 큰 축인 Dynamo 시스템에 대해서 알아봤다. Dynamo 시스템은 DynamoDB가 등장하기 한참 전에 설계되었지만 이름에서 쉽게 알 수 있듯 굉장히 깊은 부분을 공유하고 있다. 그러나 DynamoDB는 관리형 인프라 서비스로 제공되는 만큼 사람들이 더 쉽고 범용적으로 사용할 수 있게 설계되었다. 구체적으로 어떻게 어떤 점이 다른지 알아보자.

아마존은 지구 규모 스케일 서비스를 운영하면서 자신들의 요구와 가장 잘 들어맞는 범용적인 분산 스토리지 시스템을 만들어냈는데 이 시스템이 바로 Dynamo이다. 시스템을 만들고 운영한 경험을 논문으로 발표했고, 이 논문은 분산 스토리지 시스템 생태계에 큰 영향을 주었다. 이 논문에 영향을 받아 오픈소스에서는 Cassandra가 개발되었고 AWS 서비스의 SimpleDB, DynamoDB를 만드는 기초가 되었다. DynamoDB의 구조가 완전히 Dynamo와 같지는 않지만, 뿌리가 되는 Dynamo 시스템에 대해 먼저 알아보자.

RDB는 흔히 말하길 스케일링 (스케일 아웃) 하기 까다로운 데이터베이스라고들 한다. NoSQL이 등장하며 내세웠던 차별점 역시 이러한 부분(확장성)이 포함되어있다. 하지만 RDB가 스케일 아웃이 불가능하다는 건 절대 아니다. 많은 거대한 서비스들이 RDB를 사용하고 있고, 이 서비스들은 많은 방법으로 스케일 아웃을 구현하고 있다. 이 방법에 대해서 정리한 글이다.