3월 14일 시스템 설계 스터디

시스템 설계 스터디

오늘은 시스템 스터디 설계가 있는 날이었습니다.
이번 주는 지난 주에 서 좀 파고드는 내용으로, 분산 키-값 저장소와 고유 식별자 발급에 대한 이야기를 나웠습니다.

분산 키-값 저장소

비관계형(non-relational) 데이터베이스에 해당하는 키-값 저장소(key-value store)는 각각 유일한 키에 대한 대응하는 값의 쌍을 저장하는 시스템입니다.

가용성(Availability), 일관성 (Consistency), 파티션 감내(Partition Tolerance) 의 3가지 측면에서 고려를 하여 실질적인 설계를 하게 되는데, 이 중 어느 하나를 희생시키면서 두 가지를 챙기는데, 파티션 감내는 분산 데이터 구조에서 무조건 챙겨야 하므로 실용적으로는 일관성-파티션 감내의 CP 구조 또는 가용성-파티션 감내의 AP 구조를 채택하게 됩니다.
이는 데이터 파티션 상에서 읽기 노드와 쓰기 노드의 비율을 어떻게 두느냐에 따라서 달라지는 식으로 구현합니다.

CP 의 예시로는 일관성 중시의 금융권, AP의 예시로는 실시간성이 중요한 대부분의 케이스에서 이용을 한다고 합니다.

이후 이 저장소에서 충돌이 날 경우를 생각하게 되는데, 이 경우 취할 수 있는 정책은
단순한 덮어쓰기나 복수 저장, 자동 병합 같은 여러 가지를 적용할 수 있지만 각각의 경우 의 제약사항과 사용례가 달랐습니다.

또한 장애를 상정하고 대응하는 정책 역시도 선택을 취할 부분들이 많았습니다.
단순한 서버 장애부터 데이터센터 단위의 문제까지 고려할 부분들이 대규모 시스템에서는 여럿 있었습니다. 일시적으로는, 해당 장애 노드를 비활성화하고 다른 노드에 위탁하는 방법이 있겠지만,
영구적으로 해당 노드에 있던 내용들을 재계산하여 배분할 필요가 있고, 이 때 더 효율적으로 처피하기 위한 처리 관련한 프로토콜들이 있었습니다.

실제 예시로는 Redis, MariaDB 등의 상용 서비스들이 많이 지원해 주니, 일단 있는걸 써야 이해가 잘 될 듯 하네요.

고유 식별자 발급

고유 식별자 (Unique Identifier)는 주로 해시 키 등으로 쓰이기 위해서 유일한 값으로 생성하는 식별자를 말합니다.
이 고유 식별자는 요구 사항들에 따라 여러 사양으로 만들 수 있는데 , 어떤 특성(유일함, 정렬 가능, 길이 등)을 가지고 만들지를 결정할 필요가 있습니다.

하지만 이 책에서 다루는 내용은 대규모 분산 시스템에서의 설계라는 제약이 있습니다.
서버가 한 대라면 그냥 순차적으로 자동 숫자증가로 해결하면 될 이야기지만, 여러 서버에서 동시에 이걸 발급한다면 상황이 달라지고, 경우에 따라 다른 접근이 필요합니다.

책에서 드는 예시는 다중 마스터 복제 (Multi-master Replication)의 기초적인 접근으로 시작하면서 실용적으로 많이 쓰이는 UUID(Universal Unique Idenfier)나 티켓 서버(Ticket Server), 스노플레이크(Snowflake) 방식까지 경우에 따른 4가지 케이스가 있었습니다.

각각이 장단점이 명확하지만, 책의 사례에 맞는 사례는 스노플레이크였습니다.
이 경우 숫자, 정렬 가능, 64비트, 시간순, 고성능, 확장성을 충족시킬 수 있었습니다.

사실 일반적인 서비스 수준에서는 UUID 수준에서 대부분 해결되는 듯 합니다.
대중적이고 충돌 확률도 적고 어쨌든 유일하면 되니까요.
여러 고민이 있긴 하지만 역시 내가 언제까지고 볼 수 없다가 보통은 주안점이 되는 듯 합니다.