How to build a Distributed System
영상: https://youtu.be/39JqNkqxP3M
발표자료: https://static.sched.com/hosted_files/kccncna2022/0e/How%20to%20Build%20a%20Distributed%20System.pdf
Case Study - Global Directory Service
- 지난 몇 년 Crypto 관심이 증가하면서, 정부에서도 crypto Transaction audit하려는 니즈가 증가.
- A Group of Organizations try to form alliances to figure out how to share information to allow governments to allow their citizens.
- 그러나 블록체인은 audit 편의성을 고려한 프로덕트가 아니기 때문에 작업이 쉽진 않음.
- 이 문제를 해결하려고 함.
일종의 Gloabl Yellow Pages 개발하기. (Yellow pages : 알파벳순이 아니라 특정 기준에 따라 분류한 비즈니스 전화번호부)
- Virtaul Asset의 Service Provider가 상대방을 확인할 수 있고
- 정부가 audit할 수 있는 Secure / Private information을 Service Provider끼리 교환할 수 있도록.
- wallet을 보유한 사람의 집주소라거나
- Social Security Number라거나
기능을 대략 정리하면
- 사용자가 Enroll할 수 있는 웹앱
- Approval Process
- identity Certificate (public / private key)를 받은 뒤 mTLS로 CounterParty 간 연결.
- gRPC로 통신 latency 축소
고민이 필요했던 점
- 사용자에게 발급된 public Certificate는 어디에 보관할 것인가?
- Crypto 산업이 가장 활발한 싱가포르에 저장한다? -> 싱가포르에서 먼 지역은 latency가 커지게 됨.
- 분산원장 형태의 distributed System이 필요.
What is a Distributed System?
- 여러 대의 컴퓨터를 하나의 Network로 묶어서 동작시키는 시스템.
- 네트워크에 연결된 각 컴퓨터는 Peer.
- Peer는 서로의 DB Copy본을 가지고 있음.
- peer는 자신에게 들어온 요청에 개별적으로 응답.
네트워크의 Peer 간 통신에는 gRPC를 사용.
peer가 개별적으로 요청에 대응한다면, 예컨대 위와 같은 상황이 발생할 수 있다.
- 동일한 사용자가, 두 개의 다른 Peer에 same key, different value를 저장하려고 시도할 경우.
- 즉 peer간 데이터 sync가 어긋나는 상황을 어떻게 대응할 것인지.
서비스의 비즈니스 목적에 따라 우선순위가 다르겠지만, Consistency와 Availability는 trade off 관계.
- 우리 팀은 Eventual Consistency정도로도 충분할 것이라고 보았다.
Non-profit 프로젝트이므로 오픈소스를 활용해 솔루션을 구축했음. Honu와 Trtl라는 두 개의 패키지로 구성됨.
- Honu: LevelDB와 gRPC protobuf 기반. Metadata Versioning을 LevelDB에 저장하고, Coordinate Sync between peers.
Sync는 주기적으로 동작하며, Object의 Version vector 값을 비교해서 업데이트하는 식.
- alpha와 bravo라는 두 개의 peer가 있다고 할 때
- 예컨대 alpha가 bravo에게 object version vector를 공유하면
- bravo에 값이 없는 key-value pair일 경우: add it locally
- bravo의 버전이 작을 경우: local repair
- 버전 충돌이 있을 때:
을 사용한다고 함.
Lesson Learned
kubernetes에서도 활용되는 DevOps 개념인
전략을 적용하기 어려웠다.
- Replication 동작을 수행하려면, individual pods needs to be addressable.
- Cattle not Pets : 인프라 관리의 개념을 'Manually, carefully takes care'하는 Pet이 아니라 방목해서 관리하는 Cattle처럼 보자는 의미.
- 서버가 절대로 down될 수 없도록 care하는 대신, down된 서버를 자동으로 복구할 수 있도록 하는 데 초점
- StatefulSet 생성에 Configmap 옵션 추가.
- pods which have an Associated Identity and enforce the idea of uniqueness.
- = never start the same pod (same identity) when we have to replay or change configurations.
- configmap에는 'who they are, who else they're allowed to talk to, how to talk to them' 정보가 저장되어 있음.
- pods which have an Associated Identity and enforce the idea of uniqueness.
- Geo-Distributed System을 구축할 때, Google Load balancer로는 한계가 있었음
- gRPC 사용이 쉽지 않음
- mTLS 통신을 하고 싶은데, LB에서 TLS Termination을 수행
Load balancer를 쓰는 대신 DNS Layer에서 Routing할 수 있도록 설정.
- 예시: 디트로이트의 client가 도메인의 DNS resolution 요청 시
- ingress Service에 Region별 IP address 정보를 DNS에 캐시
- gRPC 요청 시 DNS에서 받은, 해당 region의 ingress IP로 Remote Procedure Call.
gRPC 요청을 보낼 수 있도록 ingress IP주소를 DNS에서 확인할 수 있는 방법: GeoPing.
- 예시. geoping으로 요청을 보냈을 때, vpn으로 요청 보내는 클라이언트의 위치를 변경하면 같은 DNS로 ping을 보내도 응답하는 서버의 region이 다른 것을 볼 수 있다.
Google Cloud DNS에 Geo-weighted Routing 로직을 붙여서 사용하고 있음.
Future of Distributed System?
Distributed System의 정의가 조금은 바뀌지 않을까 싶음 : A Flow of events Across time and space.
- Phone으로 접근하는 클라이언트 & 10년 전에는 생각한 적 없던 유형의 클라이언트 유형이 증가했음
- MicroService 형태 / Event-Driven 아키텍처 서비스가 많아짐
- Event 단위로 Created / Ordered / Pushed to microservices.
Distributed System에서 각광받게 될 프로덕트들.
- traditional Database에 데이터를 전송하는 대신, Event 단위로 데이터 전송 / 저장이 활발해짐.
New Features on Distributed System
Persistence by Default
지금까지의 Eventing solutions는 persistence 옵션을 Throughput 증가 / latency 감소 등의 이유로 default false로 설정한 경우가 많음.
- Event를 Distributed System에서의 기본 단위로 설정한다면 persistence는 기본적으로 필요한 옵션이 될 예정
- can Do things like time travel.
- can recover from disaster.
Geographic Event Encoding
더 나은 user experience 제공 / local regulation 이슈 해결 차원에서 중요성이 올라갈 것이라고 예상.
Total Ordering by Default
지금까지 ordering을 보장하는 건 Same Node 내에 있는 broker에 한해서임.
- 여러 노드 간 Ordering은 Consensus가 추가로 필요하므로 Expensive. (Strong consistency is Expensive)
- 오픈소스에서 Total Ordering을 지원한다면, Distributed Application을 global 단위로 서비스하기 용이해질 것
Automatic Configuration
k8s 진영에서 특히 환영할 만한 이슈이고, 이번 컨퍼런스에서도 많이 등장하는 주제
- 한정된 리소스를 가진 작은 규모의 팀에서도 Multi-Cluster를 세팅하고 운영할 수 있도록.