굉장히 잘 정리된 포스트가 있어서 여기서는 간단하게 몇 가지 기억나는 내용만 복습용으로 짚고 넘깁니다.
아주 간단하게 정리하면, Borg는 Kubernetes의 전신으로 구글 내에서 사용하던 workload deploy 클러스터 매니징 시스템이라고 할 수 있을 것입니다. 거의 모든 서버를 컨테이너로 돌렸고 매주 20억개의 컨테이너가 시작하는데, 그러한 상황에서의 클러스터 매니징을 하면서 쌓여온 노하우들을 정리해 둔 논문이라고 볼 수 있습니다.
실제로 Docker의 그것과 꽤 비슷하게 생겼죠..?
이 시스템을 실제 사용하지는 않을 거라서(어차피 현재의 k8s 구조와도 비슷하게 생기기도 했거니와...) 위 아키텍쳐까지 아주 상세하게 알 필요는 없을 테고, 큰 흐름에서의 Lesson들 위주로만 확인해 두었습니다.
Lessions learned?
- Workload 종류 분리: 신뢰성이 요구되는 long-term 작업과 단기성 batch job 2가지 부류로 나뉘는 상황. 각 상황에 맞도록 실행환경을 갖춰둠
- 스케쥴링: queue에 저장되어 있다가 실행됨. score을 기준으로 적당한 머신을 배정받아서 거기 실행되는 형태. 자원이 부족하다면? Preemption 형태 (자원이 부족할 시 score이 낮은 task를 죽임).
- 성능 관리: compressible resources(kill하지 않고도 자원을 돌려받을 수 있는 경우 e.g. CPU, I/O) 와 non-compressible(e.g. RAM, DISK)로 나눔
- Scalability: Borgmaster가 중앙집중형이지만 sharding 통해서 나름 스케일 확장 가능한 듯 / 이외에도 최적화 수행: 캐싱, 컨테이너 선정에서의 적당한 랜덤화(샘플링?)
- Avabaility: task가 실패하지 않도록 다양한 기교를 사용함(자동 재시도, 실패한 머신과 매칭하지 않기 등). Borgmaster은 replication, 내부적인 reattempt 등으로 99.99%의 availability를 보여줌.
- 마스터의 polling: 주기적으로 child polling, 과도한 poll 통신으로의 리소스 낭비를 회피하기 위함
- (이건 gossip이 낫지 않았을까? 아니면 borglet 자체가 중앙집중형인걸 감안해서 어쩔 수 없는 것일까?)
- IP 주소 세팅: 능동적으로 고를 수 있는 환경의 필요성 (일종의 서비스 라우팅의 필요성?)
- 로그 기록 및 관리는 필수: 리소스 기록 및 확인, 로깅(ElasticSearch) 등
비단 클러스터 매니징을 넘어서 분산시스템, 태스크 매니징과 같은 일반적인 설계사항에도 고려될 점이 많기 때문에 배울 것이 많은 논문이라고 생각됩니다.
참고
'개발 > Engineering' 카테고리의 다른 글
| Unique ID Generator의 설계 (0) | 2022.05.06 |
|---|---|
| 컨테이너 기반 가상화 기술, 그리고 AWS Lambda (0) | 2022.05.06 |
| AWS가 이야기하는 Well-Architected Framework (0) | 2022.05.06 |
| 리눅스 커널 바로 위에 executable 얹기 (0) | 2022.05.04 |
| DynamoDB와 Spanner, 어떻게 다를까? (0) | 2022.05.04 |