KubeCon 2022 NA - How to build a Distributed System

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
  • 버전 충돌이 있을 때: Bilateral Anti-Entropy 알고리즘 을 사용한다고 함.

Lesson Learned

kubernetes에서도 활용되는 DevOps 개념인 Cattle, Not Pets 전략을 적용하기 어려웠다.

• 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' 정보가 저장되어 있음.

 

 

• 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를 세팅하고 운영할 수 있도록.