원작자인 Bret Fisher에게 허락을 받고 번역/포스팅 함을 밝힙니다.
의역을 많이 해서 오역이 있을수 있습니다. 제 의견은 역주: 로 표시 하였습니다.
원문 링크 : https://www.bretfisher.com/the-future-of-docker-swarm/
도커 스웜의 미래 (The Future of Docker Swarm)
지금은 2018년 10월입니다. 저는 도커 스웜의 팬 입니다. 저는 스웜을 사용하고, 저의 고객들도 스웜을 사용 합니다. 저는 심지어 스웜에 대한 ** 세계 최고의 온라강좌 ** 그리고 ** 리얼월드 코스 ** 도 만들었습니다.이 글에서는 스웜의 과거와 현재 그리고 미래에 대해 포괄적으로 리뷰 하였습니다.
다섯달 전 쯤에 제가 쓴 ** “2018년도, 스웜은 죽었을까?”(It’s 2018, Is Swarm Dead?)** 를 봤을지는 모르겠지만,
그 글에서 저는 “도커가 쿠버네티스를 스웜으로 대체할 것이다” 라는 [틀린] 추측을 했습니다. 실제로는 도커에서 쿠버네티스를 도커의 growing list에 오케스트레이터로 ** 추가 ** 했습니다.
** 2019 업데이트 **: 도커는 도커콘2018 유럽과 도커콘 2019에서 스웜의 미래에 대해 다시한번 확인시켜 줬습니다. 1. 새로운 스웜의 기능들, 2. 도커의 700+ 스웜을 사용하는 고객들의 규모, 3. 스웜팀은 현재 구인중, 4. 작년동안 본 모든 리포트에서 스웜의 사용이 늘어나고 있다고 함
이제 ** 도커 엔터프라이즈 2.0 with 쿠버네티스 서포트 ** 가 릴리즈 되었고, 제 생각에는 스웜킷(SwarmKit) 과 libnetwork(https://github.com/docker/libnetwork) 프로젝트들을 다시 방문해보고 지난 열두달간 어떤 일이 있었는지 확인 해 볼 시간인것 같습니다.
이 글은 제가 도커 스웜 엔지니어와 Anshul Pundir(https://twitter.com/anshulpundir) 와 인터뷰 하면서 만들었던 도커 스웜의 과거,현재 그리고 미래 유툽 비디오를 바탕으로 작성 하였습니다.
Reminder: “Docker Swarm Mode” 는 우리 모두가 사용하는 Docker CLI 혹은 다양한 GUI’s의 도커 엔진의 기능집합 입니다. 이 기능들은 SwarmKit 과 libnetwork 두 오픈소스 라이브러리에서 만들어 졌다고 볼 수 있습니다. 그렇기 때문에 우리가 “Docker Engine Release 18.XX,” 에서 확인 할 수 있는 새로운 기능들은 때때로 개발자들이 먼저 그 새로운 기능들을 SwarmKit과 libnetwork 에 먼저 올렸다는 뜻이죠. ** 물론 SwarmKit/libnetwork 에 추가된 기능들이 Docker engine 릴리즈에 합쳐지는데는 몇달 이상씩 걸릴수도 있습니다. **
2017년 하반기와 2018년에 완료된 일들
지난 열두달 동안 어떤일들이 끝났는지에 대해 이야기 해 봅시다. 주요 영향들은 버그 픽스들, 확장성(scalability)의 향상, 기술 부채 (Technical debt) 그리고 더 쉬운 트러블슈팅과 모니터링 위주로 이뤄 졌습니다. 아래는 주요 테마 와 관련된 merged 된 pull requests 입니다.
- ** 스웜 서비스들 (Swarm services) 의 진짜 중단시간 없는 순차 업데이트를 가능성을 열어줄 ** 일련의 픽스들 (헬스체크와 적절한 앱간의 연결 관리를 한다는 가정 하에). 대부분 moby#30321 에서 찾을 수 있고 마지막으로 알려진 이슈(내가 알고있는)는 PR moby#36638 로 18.05에 merged 되었습니다.
- 위에 언급한 변경 사항들은 하드웨어의 fault-tolerance 는 필요 하지 않지만 여전히 중단 없는 순차 업데이트를 원하는 사람들이 하나의 노드로 동작하는 스웜을 운영할 수 있게 해 줍니다. ** 저는 항상 docker-compose cli 보다는 하나의 노드로 이루어진 스웜(Swarm for single-node Docker setups) 을 추천 ** 합니다.
- 진단(diagnostic) API 엔드포인트와 cli 클라이언트를 포함한 ** 클라이언트/서버에 네트워크 트러블슈팅을 추가하는 툴 ** 이 추가 되었습니다.
- 스웜킷에 ** 다양한 스웜 객체에 대한 매트릭스가 ** 추가 되었습니다 swarmkit#2673
- moby#37372 를 통한 VIP 로드 밸런싱의 확장성의 향상/발전 이 있었습니다. 이로 인해 유명한 이슈인 50k 이상 서비스를 가진 스웜의 빠른 확장 시도 가 close 되었습니다. 많은 task 배포시의 ** CPU 성능 향상 **을 포함해서 말이죠 swarmkit#2675.
- ** Windows server 1709 와 1803에서 이제 full Swarm networking을 지원 합니다 **. (overlay networks, routing mesh 그리고 VIP 를 포함하여). 여기 관련된 마이크로소프트의 발표를 확인하세요. Server Core 1709 혹은 더 최신버전의 VM이 필요 하고 Docker 18.03 혹은 최신 버전이 필요함을 알 수 있습니다. 또 윈도우 컨테이너의 버전별 제약사항을 꼭 확인하세요. 스웜 또한 docker run, swarm create 그리고 stack deploy를 통해 Hyper-V isolation 혹은 Process isolation을 이용하여 task를 생성할 수 있습니다. moby#34424
- 대규모 스웜의 확장성과 성능을 위해 raft replication에서 streaming snapshot model로의 변경이 있었습니다 swarmkit#2458
- 미국 정부 NIST FIPS 140-2 컴퓨터 보안 표준 은 진행중 이지만 현재의 최선책은 ** FIPS 표준을 지원하는 도커와 스웜, 즉 최신버전의 Docker Enterprise release 18.03.1 을 사용 할 수 있습니다. 관련된 PR은 2018년 SwarmKit 진행상황에서 확인 가능 합니다. 그리고 도커 블로그 포스트에 따르면 Docker Enterprise 에 포함(Management Plane)되는 쿠버네티스도 결국에는 FIPS 140-2이 유효하게 될 것 입니다.
- 스웜킷을 위한 TLA+ 지원 이 됩니다. TLA+는 으로써 기본적으로 코드의 품질을 validate 하기 위해 툴들과 함께 테스트 될 수 있는, 동시(concurrent) 시스템을 위한 디자인 스펙 입니다. 이건 저에게는 너무 똑똑한 것 같지만, 확장성과 품질을 향상시키는 작업의 중요한 역할을 한다고 들었습니다.
- Docker CLI를 스웜/쿠버네티스 스택에서 동일하게 사용 할 수 있도록 (Feature parity) 합니다. Docker CLI를 이용해서 오케스트레이터에서 동일하게 앱 관리를 할 수 있습니다. cli#1031
- 스웜 raft heartbeat와 election waits를 위한 도커 엔진 설정들이 추가 되었습니다; 네트워크 레이턴시가 높은 상황에서의 복원력을 향상 시키고 “매니저가 바뀌어 버리는 현상 (manager flip/flops)” 을 방지 하기 위한것으로 예상 됩니다. moby#36726
- 스웜 오버레이 네트워크를 지원 하기 위해 SCTP 프로토콜 이 추가 되었습니다. 이건 현재도 지원되고 있는 TCP/UDP/ICMP 프로토콜 보다 어려운 프로토콜 입니다. moby#33922
- 스웜 디버그 로그의 디테일이 향상 되었습니다. swarmkit#2486
- 서비스 태스크 (컨테이너)를 만들때 노드의 호스트네임을 기반으로 한 커스텀 호스트네임과 다른 스웜 환경변수들 을 가지고 만들수 있습니다 (템플릿을 사용하여) moby#34686
지금 까지 나열한 것들이 물론 전부 다는 아닙니다. 좀 더 자세한 정보를 원한다면 종료된 전체 관련 PR 리스트를 확인 하세요.
다른 진행중인 일들 Other Works In Progress (WIP)
다음으로, 공개적으로 시작했거나 시작하려고 마음 먹은 일들에 대해서 살펴 보겠습니다.
- 스웜 서비스 안의 sysctl (Linux Kernel parameters) 설정. sysctl 의 파라미터는 네트워크 최적화 등을 이유로 주로 변경 해서 사용 합니다. 현재는
docker run
에서 설정 할 수 있지만 보안/커널 관련된 옵션들을 모두 “run”에서 “services” 로 옮기려는 노력이 진행중에 있습니다.docker run
에서docker service create
로 옮기려는 모든 기능들의 리스트 는 여기에서 확인 하세요. moby#37701 swarmkit#2729 (역주: 확인해 보니 merged 됐네요) - 디바이스 지원: 가장 흔한 유즈 케이스는 GPU 의 지원 일 것 입니다. 이를 통해 여러분은 하나 혹은 이상의 GPU들을 사용하는 서비스를 스케쥴 할 수 있을 것 입니다. 그리고 스웜은 어디에 그 태스크를 스케쥴 해야 하고, 어떻게 그 리소스들을 사용해야 할 지 알게 될 것 입니다. swarmkit#2682 (역주: 이건 오픈 상태인데 커멘트들을 보면 보류 된 상태로 보입니다)
- 스웜 클러스터를 위한 Kubemark와 비슷한 성능 테스트와 검증 툴. 우리는 스웜킷에 약간의 새로운 메트릭 들이 추가된 것을 swarmkit#2673에서 봤었지만 사용자 관점의 테스팅 툴에 관한 움직임을 한동안 보지 못 했습니다. 스웜 클러스터를 위한 벤치마킹과 테스팅 툴이 있으면 좋겠다는 의견이 몇몇의 엔지니어들에 의해 언급 되었지만, 아직 코드는 작성 된게 없어 보입니다.
- 새로운 네트워크와 IP 할당자. 모든 서버들이 각각의 버추얼 네트워크를 만들고 서브넷을 생성하고 출동하지 않는 IP들을 생성하는것은 쉬운 일이 아닙니다. 그리고 여러분의 서버에서 매초마다 새로 생겼다가 없어지는 컨테이너들을 가지고 있다면 앞에서 말한 네트워크관련 된 작업의 정확한 상태를 유지 하는것은 굉장히 어렵 습니다. 지난 몇년간 관련된 다양한 이슈들- 제가본 PR들을 보면- 은 지금 해결 되었습니다. 이건 나중의 기능들과 약간의 엣지 케이스들을 위해서 길을 포장하는것 처럼 들립니다. swarmkit#2686
- 더욱 향상된 로드 밸런싱. 제 생각에는 이게 스웜의 오버레이 네트워크 드라이버 의 라우팅 메시(routing mesh)와 VIP 기능들의 사용할 수 있는 다이얼(knobs)를 뜻하는것 같네요. 관련된 스펙은 없습니다.(역주: 다른것들은 github pr이나 issue 넘버가 있는데 이건 없다는 뜻 입니다.)
- 클러스터 볼륨(Cluster volumes). 도커에는 이제까지 스웜에서 인식할 수 있는 내장된 볼름 드라이버가 없었습니다. 이에 대해서는 2017년 초부터 되어 왔습니다. ** 지금은 REX-Ray ** 를 사용 하거나 다른 써드파티 도커 플러그인 들을 사용할 수 있습니다. 또한 도커의 CloudStor 드라이버도 있지만 이들은 모두 아직 오픈소스가 아니거나 빌트인으로 제공 되지 않습니다. ** 스웜킷 팀에서는 클러스터 볼륨에 다시 관심을 갖게 되었고, 아마도 CSI 를 지원** 할것 같습니다. CSI는 Container Storage Interface 의 약자로 다른 오케스트레이터들도 지원을 합니다.
- 현재는 Custom default IP subnets 이 bridge networks 에 한하지만 overlay 까지 확장되길 기대 합니다. moby#36396
도커 스웜 팀은 지금 구인중 입니다
위에 있는 제 Anshul 과의 인터뷰 비디오를 보면, 그의 팀은 스웜 엔지니어를 구한다고 언급 했습니다. 보다 자세한 정보는 그들의 구인 페이지에서 “Orchestration Engineers” 를 참조하세요. (역주: 현재 2020년 1월에 확인했을 때는 해당 링크는 존재하지 않습니다.)
Thanks To Docker
도커 팀에게 감사의 말씀을 드립니다. 도커 본사에서 저와 함께 시간을 보내면서 도커 캡틴들이 정보를 공유하고 커뮤니티에 도움을 줄 수 있게 도와준 Anshul Pundir 그리고 Mano Marks 특히 더 고맙습니다.
Get More Swarm Education
제 스웜 마스터리 코스는 인터넷상에서 스웜을 배우는 가장 좋은 방법 입니다! 그리고 도커의 기초 훈련도 제 도커 마스터리 코스에서 받을 수 있습니다.