ETCD3
Before etcd
etcd 이름의 유래
etcd라는 이름은 유닉스 /etc폴더와 distributed 시스템이라는 아이디어에서 유래했습니다. (/etc폴더는 단일 시스템에 대한 구성 데이터를 저장하는 곳이고 따라서 etcd는 대규모 분산 시스템에 대한 구성 정보를 저장하는 곳입니다.) 즉, distributed /etc 가 etcd 입니다.
CAP & PACELC theorem
사실, CAP과 PACELC 모두 증명이 완료된 이론입니다.
다만, CAP에 대해 일부 논란(정상상황일때 설명이 어려움) 있었고, 이를 보완한 PACELC이 등장하였다라고 이해하셔도 무방합니다.
애초에 CAP Theorem이 의도했던바는 명확합니다. 분산시스템에서 장애가 없는 네트워크는 절대로 존재하지 않기에, 따라서 분산시스템에서 P는 무조건 인정하고 들어가야 한다는 것입니다. 따라서 네트워크가 단절되었을 때 시스템이 어떻게 동작할지 결정해야 하며, 이 때 C와 A를 모두 만족시키는건 불가능하기에, 둘 중에 하나를 선택해야합니다.
CAP는 분산시스템에 대한 명확한 표현이 힘들기에, PACELC를 이용하면 문제를 좀 더 명확하게 이해할 수 있으며 시스템에 대해서도 깔끔하게 표현할 수 있습니다.
CAP
The CAP theorem states that distributed systems can have at most two out of three of the following properties: high levels of data consistency, high availability of access to the data, and tolerance of network partitions. Networks cannot be assumed to be reliable, so distributed
CAP 정리에 따르면 분산 시스템은 높은 수준의 데이터 일관성, 데이터 액세스의 고 가용성, 네트워크 파티션의 허용 오차 3 가지 속성 중 최대 2 가지를 가질 수 있습니다. 분산 시스템은 네트워크는 신뢰할 수 있다고 가정 할 수 없으므로 네트워크 파티션을 고려해야합니다.
그래서 보통 CAP theorem에서 분산 시스템은 AP 또는 CP 를 선택합니다. 즉, 네트워크 파티션 동안 데이터 불일치 위험을 감수하면서 고 가용성 을 선택 하거나 가용성을 희생하면서 데이터 일관성에 집중할 수 있습니다.
결국, CAP Theorem이 내포하고 있는 의미는 분산시스템에서 네트워크 장애 상황일 때 consistency과 Availability중 하나만 선택할 수 있다는 것입니다. 정상 상황일 때의 분산시스템 동작을 서술해주지 못는 문제점을 해결하기 위해 Daniel Abadi가 PACELC이라는 theorem을 제시하였습니다.
PACELC
if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?
- HBase는 CP/EC 형태로 디자인 되었습니다. 장애 상황일때 C를 위해 A를 희생합니다. 그렇지 않은 경우에도 C를 위해 L을 희생합니다.
- Cassandra는 AP/EL이 가능하도록 디자인 되었습니다. 설정에 따라 Eventual Consistency의 특성을 가지게 되는데, 이 경우 AP/EL이 됩니다. 장애 상황인 경우에는 가능한 노드에만 데이터를 반영하고 정상으로 복구되면 필요한 노드에 데이터를 모두 반영합니다. 정상상황일때도 Latency를 위해 모든 노드에 데이터를 반영하지 않습니다.
- Brewer가 제시한 가상의 분산시스템은 AP/EC 입니다. 정상적인 경우에는 모든 노드에서 같은 메세지를 볼 수 있도록 쓰기 연산이 일어나는데 P 상황인 경우, 이를 판단하여 일단 접근 가능한 만큼만 데이터를 반영합니다. 결과적으로 시스템은 다운되지 않지만 절단된 노드들끼리는 데이터를 주고 받지 못하게 됩니다. 장애상황이 복구되면 이를 감지하여 전달하지 못한 데이터를 반영합니다. 장애상황일때에만 C를 포기하고 보통의 상황에서는 강력한 C를 가져가는 것입니다.
- PNUTS는 CP/EL 형태로 디자인 되었습니다. 장애상황일 때는 C를 위해 A를 희생하지만, 평소에는 L을 위해 C를 희생합니다. 시스템이 정상일 때에도 C를 충족시키지 못하는데 네트워크 장애일 때 C를 위해 A를 포기한다니 말이 안 되는 것 같지만, 여기서 CP의 의미는 평소만큼의 C를 보장하기 위해 A를 희생시킨다는 의미로 받아들이면 됩니다. PNUTS의 Consistency Level은 Timeline Consistency이다. 일반적으로 생각하는 Consistency보다는 약하지만, 장애상황일 때에도 정상상황일 때와 같은 Consistency Level을 보장하기 위해 요청 자체를 실패시킵니다.
그래서 PACELC에서 etcd는 어디에 속하는가?
etcd는 CP/EC에 속합니다.
그러므로, Etcd는 강력한 consistency를 가진 시스템입니다. = 장애 상황일때 C를 위해 A를 희생합니다. 그렇지 않은 경우에도 C를 위해 L을 희생합니다. 정상적인 상황에서는 지연 시간에 대한 일관성과 network partition의 경우 가용성에 대한 일관성을 최적화합니다.
그럼 newsql은?
사실 C와 A를 '거의' 모두 만족한 newsql 이란것이 있는데 밑에서 좀 더 다루겠습니다.
Distributed Concensus
distributed environment에서는 컴퓨팅에 참여하는 모든 노드가 현재 상태를 동일하게 유지하는 것이 중요한(어렵지만) 이슈입니다. 분산 환경에서 합의를 위한 프로토콜로 가장 오래 사용되었던 것은 Paxos였지만, Paxos 알고리즘은 높은 복잡도로 이해가 어렵고, 이로 인해 안정성이 검증되고 널리 사용되는 구현체도 제대로 존재하지 않습니다.
따라서 Paxos와 동일한 안정성을 가지면서도 이해하기 쉽고, 구현하고 관리하기 쉬운 합의 알고리즘을 개발하고자 하는 목적으로 Raft 합의 알고리즘이 개발되었습니다.
CFT, BFT, PBFT
CFT는 어떠한 노드가 충돌(Crash)이 발생한 경우에도, 서비스 제공을 위해 시스템이 동작하게 하는 충돌 장애 허용 기법이며, BFT는 잘못된 데이터를 전달하는 배신자 노드(악의적 뿐만 아니라 단순 장애도 포함)가 존재하는 경우에도 서비스가 동작하는 형태 정도로만 정리하고 넘어가겠습니다.
BFT(Byzantine Fault Tolerance) & PBFT(Practical Byzantine Fault Tolerance)
여기서 기존 BFT는 동기적으로 해결하는 consensus 알고리즘인 반면, PBFT는 비동기적으로 네트워크에서 합의를 이룰 수 있게 합니다. 비동기로 합의를 이루기 위해서 노드 간에 리더로부터 받은 상태를 두 번 브로드 캐스팅하여 얻은 메시지들 중 정족 수 이상의 메시지로 합의합니다.
Paxos
가장 유명한 합의 알고리즘 중 하나입니다. 데이터베이스를 복제할 때는 동일한 서버를 하나 더 만들어 데이터를 복제하는 것이 일반적입니다(Replication System). Paxos의 코어는 매우 단순합니다. 하지만 이 알고리즘은 합의 형성에만 특화됐기 때문에 프로그램으로 구현하기 위해서는 시스템적으로 검토해야 할 점이 많습니다.
Paxos의 특징은 과반수의 동의를 얻었다면 그 동의 내용이 나중에 변경되지 않는다는 점입니다. 리더를 중심으로 합의 형성을 수행하지만 Byzantine Fault 모델이 아니기 때문에 리더가 부정을 저지르는 경우 동기화되지 않습니다. 그리고 멤버가 거짓으로 신고한 경우에도 동기화가 되지 않기 때문에 악의를 가진 참가자가 있는 환경에서는 운영하기에는 적절하지 않습니다.
Raft
"Reliable, Replicated, Redundant and Fault-Tolerant"
Paxos알고리즘을 쉽게 변형하고 구현하기 위해서 타 합의 알고리즘에 비해 리더의 역할을 더 강하게 합니다. 리더를 통해 메시지를 전파함으로써 합의를 도출하고, 난수화된 타임아웃을 이용해서 리더를 선출합니다. 선출된 리더가 로그 복제의 역할을 수행하고 다른 노드들에 메시지를 전달하며 해당 메시지의 응답자 수가 정족 수를 넘으면 이를 최종 합의로 반영한다.
They ensure safety (never returning an incorrect result) under all non-Byzantine conditions, including network delays, partitions, and packet loss, duplication, and reordering
Raft는 CFT(crash fault tolerance)를 보장합니다. 클러스터의 전체 노드 중 과반수 (n/2) 노드에 장애가 발생하기 전까지 클러스터는 정상적으로 동작함을 보장합니다. 다만 Raft는 모든 노드가 정직하다는 가정하에 동작합니다. 즉, Byzantine Fault Tolerant 하지 않습니다. 따라서 Raft는 private한 네트워크 환경에 적합한 합의 알고리즘이라고 할 수 있습니다.
raft의 자세한 내용은 etcd를 설명할때 함께 설명하도록 하겠습니다.
raft가 사용되는곳
- cockroachdb A Scalable, Survivable, Strongly-Consistent SQL Database
- dgraph A Scalable, Distributed, Low Latency, High Throughput Graph Database
- etcd A distributed reliable key-value store
- tikv A Distributed transactional key value database powered by Rust and Raft
- swarmkit A toolkit for orchestrating distributed systems at any scale.
- chain core Software for operating permissioned, multi-asset blockchain networks
Etcd에서의 raft
- Raft 노드는 Leader, Follower, Candidate 세 가지 상태 중 한가지 상태로 존재합니다.
- Raft는 한 번에 한 명의 Leader만 activate 되도록하고, append-only replicated log 형태를 유지합니다.
따라서, 모든 write는 Leader에게 전송되고, Leader가 이를 Follower 노드에 복제합니다. (노드 쿼럼이 write를 확인한 경우에만, Raft가 클라이언트에 확인을 반환합니다.)
- Term number(1씩 증가하는 s)는 성공적인 Leader 선거를 정의합니다.
- replicated Log의 각 entry는 Term과 Log의 위치로 식별됩니다.
Raft는 몇 가지 주요 safety properties를 보장하여 Log의 정확성을 보장합니다.
- 이는 두 Log에 동일한 Index와 Term를 가진 entries가 포함되어 있으면, 주어진 Index까지 모든 entries에서 동일하다는 것을 나타냅니다. (Log Matching property)
- 새 Term의 리더는 항상 이전 Term에서 커밋 된 모든 Log 항목을 보유하고 있습니다(Leader Completeness property)
- Raft의 마지막 safety property는 서버가 지정된 index의 Log entry를 state machine에 적용한 경우, index에 대해 다른 서버도 같은 index에 다른 Log entry를 적용하지 않도록 규정합니다.
일단 entry가 replicated log에 커밋되고 노드 쿼럼에 의해 수락되면, Leader는 commited Index property를 업데이트 합니다. 그러면 클러스터의 모든 노드가 커밋된 index 위치까지 모든 entry들을 local state machines에 비동기식으로 적용합니다.
client가 꼭 etcd 리더에게 요청을 보내야하는가?
Raft 는 Leader 기반입니다. Leader는 클러스터 합의가 필요한 모든 client 요청을 처리합니다. 그러나 client는 어떤 노드가 Leader인지 알 필요가 없습니다. Follower에게 전송된 합의가 필요한 모든 요청은 자동으로 리더에게 전달됩니다. 합의가 필요하지 않은 요청(e.g. serialized reads)은 모든 클러스터 구성원이 처리 할 수 있습니다.
왜 클러스터 멤버가 홀수가 좋을까?
etcd 클러스터는 클러스터 상태 업데이트에 동의하기 위해 대부분의 노드인 쿼럼이 필요합니다. n 구성원이있는 클러스터의 경우 쿼럼은 (n / 2) +1입니다. 크기가 홀수 인 클러스터의 경우 하나의 노드를 추가하면 항상 쿼럼에 필요한 노드 수가 증가합니다. 시스템이 더 많기 때문에 홀수 크기의 클러스터에 노드를 추가하는 것이 더 좋아 보이지만 정확히 동일한 수의 노드가 쿼럼을 잃지 않고 실패 할 수 있지만 실패 할 수있는 노드가 더 많기 때문에 내결함성이 더 나쁩니다. 클러스터가 더 이상 오류를 허용 할 수없는 상태에있는 경우 새 노드가 클러스터에 등록되지 않으면 (예 : 주소가 잘못 구성됨) 쿼럼이 영구적으로 손실되므로 노드를 제거하기 전에 노드를 추가하는 것은 위험합니다. .
최대 클러스터 크기가 있을까?
이론적으로는 엄격한 제한이 없습니다. 그러나 etcd 클러스터에는 7 개 이하의 노드가 있어야합니다. etcd와 유사하며 수년 동안 Google 내에 널리 배포된 Google Chubby lock service는 5 개의 노드를 실행할 것을 제안합니다. 5멤버의 etcd 클러스터는 대부분의 경우 2개의 멤버 failures를 충분히 허용 할 수 있습니다. 더 큰 클러스터는 더 나은 내결함성을 제공하지만 데이터를 더 많은 시스템에 복제해야하므로 쓰기 성능이 저하됩니다.
내결함성(failure tolerance)은 무엇일까?
etcd 클러스터는 구성원 쿼럼이 설정 될 수있는 한 작동합니다. 일시적인 네트워크 장애 (e.g. partition)로 인해 쿼럼이 손실 된 경우, etcd는 네트워크가 복구되고 쿼럼이 복원되면 자동으로 안전하게 재개됩니다. Raft는 클러스터 consistency을 보장합니다. 전력 손실의 경우 etcd는 Raft Log를 디스크에 유지하고 있습니다. etcd는 실패 지점까지 Log를 재생하고 클러스터 참여를 재개합니다.
클러스터에 홀수의 구성원이 있는 것이 더 좋습니다. 홀수 크기 클러스터는 짝수 크기 클러스터와 동일한 수의 오류를 허용하지만 노드 수가 더 적습니다.
System Limits
크기 제한 요청
etcd는 metadata에 작은 key-value pair를 처리하도록 설계되었습니다. Key 또는 Value 크기에는 제한이없는 것 같지만 기본적으로 Raft 요청 payload 크기는 1.5MB입니다. (더 큰 요청은 작동하지만 지연 시간이 늘어날 수 있습니다.) (이 제한은 서버에 대한 --max-request-bytesetcd 플래그를 통해 조절 가능합니다.)
저장 크기 제한
기본 저장소 크기 제한은 2GB이며 --quota-backend-bytes플래그로 조절할 수 있습니다. (8GB는 일반 환경에 권장되는 최대 크기이며 구성된 값이 이를 초과하면 시작시 etcd가 경고합니다.)
MVCC(multi-version-concurrency-control)
etcd는 동시 access 및 versioning을 지원하기 위해 Boltdb 위에 MVCC를 구현합니다. 모든 단일 상태 변형 (예 : Put, Delete, Txn 등)은 데이터베이스에서 global revision number를 증가시킵니다. 읽기 트랜잭션은 특정 revision number 이하에 있는 레코드를 대상으로 할 수 있습니다. key-value 쌍의 key 부분은 데이터베이스에서 기본키로 사용되는건 아닙니다. 대신 Etcd는 revision을 기본 키로 사용합니다. (revision은 [1] 현재 major revision number, [2] 현재 minor sub-version number로 구성된 복합 키입니다.) 데이터베이스에 저장된 값에는 메타데이터가 key-value 쌍으로 포함됩니다. Boltdb는 여러 동시 읽기(multiple concurrent read) 트랜잭션과 단일 read-write 트랜잭션을 지원합니다. (이것은 Raft 기반 state machine의 제약 조건과 잘 맞습니다.)
gRPC 서비스
etcd 서버로 전송되는 모든 API 요청은 gRPC remote procedure call입니다. etcd3의 RPC는 기능에 따라 서비스로 분류됩니다.
etcd의 key space을 처리하는 데 중요한 서비스는 다음과 같습니다.
K/VKey/Value pair를 Creates, updates, fetches, delete 합니다
Watch키 변경 사항을 모니터링합니다.
Leaseclient 연결 유지 message를 사용하기위한 기본 요소입니다
클러스터 자체를 관리하는 서비스는 다음과 같습니다.
Auth사용자 인증을 위한 Role based authentication 메커니즘입니다.
Clustermembership 정보 및 configuration기능을 제공합니다.
Maintenance복구 스냅 샷을 만들고, 저장소 조각 모음을 수행하고, member별 상태 정보를 반환합니다.
Revisions
revision은 key space가 수정될때마다 증가하는 카운터입니다.
revision은 global logical clock역할을 하며, 저장소에 대한 모든 업데이트를 순차적으로 정렬합니다.
Key ranges
etcd3 데이터 모델은 플랫 이진(flat binary) key space에있는 모든 키를 인덱싱합니다. 이는 키를 디렉토리로 구성하는 계층적 시스템을 사용하는 다른 key-value store 시스템과 다릅니다. (디렉토리별로 키를 나열하는게 아니라, 키 간격별(key intervals) [a,b) 로 키를 나열합니다)
range
key는 Range API call로 key-value store에서 가져옵니다.
RangeRequest
message RangeRequest {
enum SortOrder {
NONE = 0; // default, no sorting
ASCEND = 1; // lowest target value first
DESCEND = 2; // highest target value first
}
enum SortTarget {
KEY = 0;
VERSION = 1;
CREATE = 2;
MOD = 3;
VALUE = 4;
}
bytes key = 1;
bytes range_end = 2;
int64 limit = 3;
int64 revision = 4;
SortOrder sort_order = 5;
SortTarget sort_target = 6;
bool serializable = 7;
bool keys_only = 8;
bool count_only = 9;
int64 min_mod_revision = 10;
int64 max_mod_revision = 11;
int64 min_create_revision = 12;
int64 max_create_revision = 13;
}client는 Range call의 응답으로 RangeResponse message를 받습니다
message RangeResponse {
ResponseHeader header = 1;
repeated mvccpb.KeyValue kvs = 2;
bool more = 3;
int64 count = 4;
}gRPC Gateway
etcd v3는 메시징 프로토콜에 gRPC 를 사용 합니다. etcd 프로젝트는 gRPC 기반 포함 이동 클라이언트 와 명령 행 유틸리티, etcdctl gRPC 통해 etcd 클러스터와 통신을. gRPC가 지원되지 않는 언어의 경우 etcd는 JSON gRPC 게이트웨이를 제공 합니다 . 이 게이트웨이는 HTTP / JSON 요청을 gRPC 메시지로 변환하는 RESTful 프록시를 제공합니다
Transactions API
Etcd 3에는 Transactions API가 도입되었습니다. 트랜잭션을 사용하면 일련의 작업 (GET, PUT, DELETE)을 구성하고 key-value store의 현재 상태를 atomic하게 실행할 수 있습니다. 트랜잭션은 Raft Log에 적용되고 state machine에 대해 순차적으로 실행되기 때문에 엄격한 직렬화 격리 수준(Serializability isolation level)을 제공합니다. 아마도 Etcd API에 가장 강력한 추가 기능 중 하나일 것입니다. Etcd의 MVCC 데이터 모델과 함께 사용하면보다 정교한 추상화를 위한 빌딩 블록으로 사용할 수 있으며 클라이언트 애플리케이션에서 concurrent operations의 코드 복잡성을 크게 줄일 수 있습니다.
Lease API
Lease는 client 연결 유지 message를 사용하기위한 기본 요소입니다.
- Etcd의 Lease API를 사용하면 클라이언트가 명시적 TTL (Time-to-Live)로 Lease를 생성할 수 있습니다.
- 이후, client는 Etcd key-value store의 key를 lease에 연결할 수 있습니다.
- lease가 만료되면 Etcd는 lease와 관련된 모든 key를 삭제합니다. client는 TTL이 만료되기 전에 lease를 취소하거나 갱신 할 수도 있습니다. lease 선언(declaration) 및 삭제(deletion)는 Raft message로 구현됩니다.
- replicated Log에 커밋되게되면, Etcd 클러스터의 모든 state machines에 적용됩니다.
- Leader는 모든 활성(active) lease들을 모니터링하지만, Lease가 state machine/데이터베이스에서 유지(persisted)되기 때문에 리더 선택시 새 노드에 Lease를 복원할 수 있습니다. 또한 Raft Log는 serial하기때문에, Lease 생성 후 모든 노드에서 Lease와 관련된 모든 key를 추적할 수 있습니다.
LeaseGrant
message LeaseGrantRequest {
int64 TTL = 1;
int64 ID = 2;
}Watch API
Watch는 키 변경 사항을 모니터링합니다.
Watch API는 client가 다양한 key에 watches를 설정하면, 해당 key의 어떤 변경사항에 대한 업데이트를 받을 수 있습니다. Client는 key monitoring을 시작할 revision을 지정할 수 있습니다. Latest revsision number를 추적해서, (clinet 연결 해제 또는 Etcd 서버 충돌이 발생할 때) 누락된 revision을 선택할 수 있습니다. Lease와 달리 Watch는 좀 더 임시적이며 client 연결이 끊어지는 경우 복원해야합니다. 데이터베이스의 key/value에 대한 기본 key로 revision을 사용하는 Etcd 스키마의 설계를 통해 서버는 random-access reads 대신 데이터베이스 스캔을 사용하여 watches를 구현합니다.
WatchCreateRequest
message WatchCreateRequest {
bytes key = 1;
bytes range_end = 2;
int64 start_revision = 3;
bool progress_notify = 4;
enum FilterType {
NOPUT = 0;
NODELETE = 1;
}
repeated FilterType filters = 5;
bool prev_kv = 6;
}Etcd vs other key-value stores
비교 chart의 사본
| 속성 | etcd | ZooKeeper | Consul | NewSQL |
|---|---|---|---|---|
| Concurrency Primitives | Lock RPCs, Election RPCs, command line locks, command line elections, recipes in go | External curator recipes in Java | Native lock API | Rare, if any |
| Linearizable Reads | Yes | No | Yes | Sometimes |
| Multi-version Concurrency Control | Yes | No | No | Sometimes |
| Transactions | Field compares, Read, Write | Version checks, Write | Field compare, Lock, Read, Write | SQL-style |
| Change Notification | Historical and current key intervals | Current keys and directories | Current keys and prefixes | Triggers (sometimes) |
| User permissions | Role based | ACLs | ACLs | Varies (per-table GRANT, per-database roles) |
| HTTP/JSON API | Yes | No | Yes | Rarely |
| Membership Reconfiguration | Yes | >3.5.0 | Yes | Yes |
| Maximum reliable database size | 수 GB | 수백 MB (때때로 수 GB) | 수백 MB | TB 이상 |
| Minimum read linearization latency | Network RTT | No read linearization | RTT + fsync | Clock barriers (atomic, NTP) |
Etcd vs NewSQL
etcd 및 NewSQL DB (Cockroach , TiDB , Google Spanner 등)는 고가용성과 함께 강력한 데이터 일관성을 보장합니다.
NewSQL 데이터베이스는 데이터 센터에서 수평적으로 확장 할 수 있습니다. 이러한 시스템은 일반적으로 여러 개의 replication group(샤드)에 걸쳐 데이터를 분할하고, 보통 TB 이상의 단위로 data set을 저장합니다. 이러한 종류의 확장은 인한 (1) latency가 길고 (2)대부분 업데이트 하던곳으로 계속 데이터를 업데이트합니다.(자세한 사항은 localized dependency graph를 참고하시면 좋을것같습니다) 데이터는 테이블로 구성 (SQL style Query 기능을 포함하기에)되기에 장점도 있지만, query process, planning, optimizing 작업이 필요하기에 추가적인 복잡성이 발생합니다. (사실 이건 일부 newsql에만 해당...)
metadata 저장소
1~2개의 replication을 위한 metadata 저장소로 etcd는 괜찮은 선택지로 보입니다.(그 이상의 경우, 혹은 global 환경에서는 newsql로...)
etcd는 replication group내의 모든 데이터를 복제하는데, GB정도의 크기 내에서는 가장 효율적인 선택지 입니다. consensus를 하나의 복제그룹으로 제한하면, etcd는 낮은 latency과 높은 처리량(throughput)을 달성하면서 간단한 프로토콜로 분산 일관성(distributed consistency)을 얻습니다
distributed coordination을 위한 Etcd
etcd는 event watches, leases, elections, and distributed shared lock과 같은 기능을 기본 요소로 가지고 있습니다. zookeeper 같은 경우에는 별도의 독립적인 coordination 라이브러리를 사용하고, Consul은 자체 Lock API를 제공하지만 스스로도 "not a bulletproof method"라고 말할 정도이니, 개인적인 생각으로는 newsql과 Etcd 중에 상황에 맞게 사용하면 될듯합니다.
etcd를 선택, GB 이상의 데이터를 저장하거나 전체 SQL 쿼리가 필요한 경우 NewSQL DB를 선택 하시는걸 추천드립니다.보안
통신 수준 암호화
TLS로 (참고 : https://etcd.io/docs/v3.4.0/op-guide/security/)
저장
일반적으로는 그냥 raw data로 저장. (민감한 정보만 Vault로)
- nonce를 reuse하는 등의 실수, key management 등의 issue때문에 보통 Vault 같은것을 많이 사용 (참고 : nonce reuse의 위험성)
혹시나 직접 저장할때 어떤 알고리즘을 사용할지는 상황에 맞춰서...
| 이름 | 암호화 | 속도 | 강도 |
|---|---|---|---|
| aescbc | AES256 암호화, CBC 운영모드 | 빠름 | 아주 높음 |
| secretbox | XSalsa20 암호화 | 아주 빠름 | 높음 |
| aesgcm | AES암호화, GCM 운영모드 | 아주 빠름 | 높음 |
기존에 운영중인 etcd에 암호화를 적용할 수 있을까?
암호화 방식은 provider 설정을 위에서 아래로 내려오며 적용합니다. 기존 데이터에 적용할 경우
- 상단에 암호화 알고리즘
- 하단에 identity
를 적용하면 read 시에 최초 plain데이터를 읽을 때는 암호화 알고리즘으로 복호화가 안되니 identity로 raw 데이터를 읽어오고 write 시에 상단의 암호화 알고리즘으로 write가 됩니다.
이미 암호화 된 데이터를 복호화할 경우엔 어떻게 해야하나?
- 상단에 identity
- 하단에 암호화 알고리즘
을 적용하면 read 할 때 상단 identity로 read가 안 되니 하단의 암호화 알고리즘으로 read하고 write 할 때 상단의 identity 알고리즘으로 plain data를 쓰게됩니다.
Ref.
raft algorithm
- wiki,
etcd