글 주소

• https://tech.kakao.com/2021/12/20/kubernetes-etcd/

해당 포스트는 Kubernates플랫폼의 etcd의 원리에 대해 설명해 주고 있습니다.
Kubernates와 etcd모두 처음 들어본 기술이였고, 이제 막 Java와 서버를 공부하기 시작한 제가 이 글을 이해하기는 힘들었습니다.
그래도 끝까지 글을 정독했고, 기술적인 지식을 습득하지는 못했지만 다른 관점에서 많은 걸 느낄 수 있었습니다.

글을 읽고 알게된 지식

• 컨테이너 생태계에서는 Kubernetes를 가장 많이 사용하고 있습니다.
• Kubernetes는 데이터 저장 방법으로etcd를 사용하고 있습니다. (모든 데이터를 etcd에 보관한다)
• 카카오는 DKOS라는 Kubernetes클라우드 플랫폼을 개발해 사내 서비스에 이용하고 있으며, API로도 이를 제공하고 있습니다.

etcd

• etcd는 RSM(Replicated state Machine)입니다.
  • 분산 컴퓨팅 환경에서 서버가 몇 개 다운되어도 잘 동작하는 시스템을 만들기 위한 방법 중 하나인 State Machine Replication(똑같은 데이터를 여러 서버에 계속해서 복제)를 사용하는 머신을 RSM이라고 합니다.
• RSM의 데이터 복제 과정에서의 문제를 해결하기 위해 Consensus를 확보해야 합니다.
  • Consensus를 확보하는 것은 Safety,Available,Independent from timing,Reactivity를 만족하는 것입니다.
  • etcd는 이러한 Consensus를 확보하기 위해 Raft알고리즘을 사용했습니다.

Raft알고리즘

• 정의
  • Raft: 땟목
  • 여러 서버들 중 일부에 장애가 발생하더라도 제 기능을 유지하도록 하는 합의 알고리즘
• 주요 용어
  • 쿼럼(Quorum): 의사결정에 필요한 최소한의 서버 수
  • 상태(State): Etcd 서버의 State는 Leader, Follower, Candidate 중 하나 입니다.
  • 타이머(Timer): Leader는 주기적으로 heatbeat을 날려 Leader가 존재한다는 걸 알립니다. heatbeat을 일정 시간 받지 못하면 Leader가 없어졌다는 걸 알게 되고, 그에 맞는 행동을 진행합니다.

리더선출

• 최초에 모든 서버가 heatbeat을 받지 못하기 때문에 timeout이 발생한 누군가가 자신을 candidate로 변경합니다.
• 거절할 이유가 없으므로 해당 서버가 Leader로 선택됩니다.

로그복제

• 사용자로부터 요청을 받은 Leader는 이를 수행합니다.

• 그리고 follower에게 heatbeat을 보낼 때 해당 데이터를 같이 보냅니다.

• 이렇게 follower에게 데이터를 보내다가 쿼럼 숫자만큼의 log 복제가 일어나면 commit을 진행합니다.

• follower는 commit이 일어났다는 사실을 알게 되면 자신이 보관하던 log를 commit 합니다.

• 만약 리더가 다운되면?

  • 리더가 다운되면 일정기간동안 heatbeat을 받지 못한 follower는 자신을 candidate로 변경합니다.
  • 나머지 서버에게 자신이 리더가 되어도 괜찮은지 요청을 보내고 이를 각 서버에서 이를 응답 또는 거절합니다.
  • 그렇게 가장 최신의 log를 보유한 follower가 새롭게 Leader가 됩니다.
  • 새로운 리더가 선출된 후 기존의 리더가 다시 복구되면 요건에 미달하기 때문에 자신을 follower로 변경합니다.

런타임 재구성

• etcd 클러스터가 동작 중인 가운데 etcd 서버를 추가,삭제하는 행동을 runtime reconfiguration이라고 합니다.

etcd 멤버 추가

• snapshot: 서버가 현재까지 받아들인 모든 log를 파일시스템에 백업해 놓는 것
• 기본적으로 새로운 멤버를 추가할 때에도 로그복제의 방식을 그대로 활용합니다.
  • 단, config가 commit 된 이후에 효력을 발휘하는 게 아니라 entry에 쓰이자마자 효력을 발휘한다는 차이가 있습니다.
• leader는 추가된 멤버에게 snapshot을 보내줘 추가된 멤버가 최대한 빨리 동일한 log를 보유할 수 있도록 돕습니다.
• 하지만 snapshot을 catch up 하는 동안에 write 요청이 들어오면 문제가 생길 수 있습니다.
  • 이러한 문제를 해결하기 위해 leader,candidate,follower외에 learner상태가 존재합니다.
  • Learner가 아직 log를 모두 따라잡지 못한 경우에는 요청이 거절됩니다.
• Raft알고리즘은 한꺼번에 여러 멤버를 추가하는 걸 지양합니다. - restriction

etcd 제거

• 멤버 추가와 마찬가지로 로그복제방식으로 진행됩니다.
• leader가 leader를 제거하라는 요청을 받았을 때는 조금 다르게 동작합니다.

etcd 유지보수 방법

로그 리텐션

• 주기적으로 log entry를 파일시스템에 저장(snapshot) 하고, memory를 비우는 작업(truncate).

리비전 및 컴팩션

• Revision: 클러스터가 생성된 이후 key의 모든 변경사항을 파일시스템에 기록하는 것
• Compaction: 불필요한 revision을 삭제하는 것

자동 컴팩션

• 운영자가 별도로 조치하지 않아도 주기를 가지고 자동으로 revision을 정리하는 것
• Revision모드와 Periodic모드가 존재합니다.

단편화 제거

• revision 삭제로 인해 etcd 데이터베이스에 발생한 fragmentation을 정리해 실질적으로 디스크 공간을 확보하는 행위

백업 및 복구

• 카카오에서는 Kubernetes 클러스터 생성 시 etcd 백업을 위한 크론잡(CronJob)을 함께 배포하는 방식으로 백업을 진행하고 있습니다.

느낀점

개발의 모든 분야를 알고 있을 수는 없다 새로운 기술을 끊임 없이 공부하고 적용하려고 해야 한다는 말이 이런걸까? 라는 생각이 들었습니다.

• '이건 기존에 하던거와 달라서 나는 못하겠어'라는 말은 개발자에게 허용되지 않습니다. 처음 보는 기술이라도 그것이 우리에게 도움이 된다면 이를 공부해서 적용해야 하는 것이 바로 개발자의 역할인 거 같습니다.

• 그렇기 때문에 한 분야에 대한 깊이 있는 이해와 CS기초 지식이 중요한 것 같습니다. 지금의 제가 Kubernetes와 etcd를 봐도 이해하지 못하는 것처럼 기본지식이 없으면 새로운 기술은 그림의 떡과 같은 허상에 불과할 겁니다.

• 동시에 오랜기간 이유 없이 얕은 지식의Python'만' 고집했던 이전의 자신이 매우 어리석었음을 깨달았고, 지금이라도 Java를 시작하고 다른 기술들을 써보려고 해서 다행이라고 생각합니다.

이론적인 지식은 필수라는 생각이 들었습니다.

• 저는 개발을 혼자 공부했던 시간이 길었고, 만들었던 시스템도 대부분 혼자서 사용하는 시스템이 대부분이었습니다. 그러한 과정에서 완벽히 설계하고 작업하기 보다는 대충 만들어보고 원하는 결과를 위해 끼워맞추는 방식으로 코드를 많이 설계했었습니다. Tensorflow를 사용하기 위해 Tensorflow의 구성 방법이나 작동법을 이해하려 하지 않고, 예시를 가져와서 적당히 입력과 출력 Dimension만 바꿔서쓰곤 했습니다.

• 좋게 말해 Agile하다고 포장할 수 있겠지만 이는 명백히 잘못된 작업 방식입니다. 자신의 코드를 이해하지 못하는 순간 확장과 유지보수는 꿈도 꿀 수 없게 됩니다. Agile도 이해를 바탕으로 작업을 유동적으로 가져갈 수 있을 때 적용되는 용어라고 생각합니다.

• 최근 Java를 공부하면서 코드 설계의 중요성을 계속 느끼고 있습니다. 처음 자바를 공부하면서 했던 불편하게 변수의 타입을 왜 정하고 쓰는거지라는 생각이 타입을 정하는 것도 나쁘지 않구나로 변한 것에 스스로 만족하고 있으며, 계속해서 이전의 나쁜 코딩습관을 없애려고 노력중입니다.

끝으로

• 처음에는 글을 내용이 하나도 이해가지 않아 설명을 공백으로 나뒀었습니다.
• 나중에 다시 글을 읽어보니 얕게나마 내용을 이해할 수 있어서 즐거운 마음으로 글을 수정했습니다.