day-log

새벽 3시 7분에 진동이 왔다새벽 3시 7분. 폰이 진동했다. etcd_mvcc_db_total_size_in_bytes 가 6GiB를 넘었다는 알람이었다. 우리 클러스터는 컨트롤플레인이 EKS가 아니라 자체 운영이고, etcd quota를 8GiB로 잡아놨다. 8GiB를 넘기는 순간 클러스터가 read-only로 떨어진다. 일어났다.평소에는 etcd db size가 1.2~1.5GiB 사이를 왔다 갔다 한다. 그게 6GiB라는 건 어딘가가 단단히 잘못됐다는 뜻이다. 처음엔 그냥 defrag 한번 돌리면 되겠지 했는데, 이게 그렇게 단순한 얘기가 아니었다.일단 무슨 일이 일어났는지부터 봤다ssh로 컨트롤플레인 노드 3대에 붙어서 etcdctl로 상태를 봤다.ETCDCTL_API=3 etcdctl \ -..

지난 분기에 컨트롤 플레인 한 노드에서 etcd defrag을 잘못 돌리다가 API 서버가 5초간 5xx를 토해낸 적이 있다. 그 뒤로 팀 내부에서 "etcd 만지지 말자"는 분위기가 잠깐 있었는데, 사실 그건 답이 아니다. defrag을 안 돌리면 결국 디스크가 커지고 read latency가 슬금슬금 올라간다. 문제는 동작 원리를 잘 모르는 상태에서 그냥 cron만 돌리는 거였다.이 글에서는 etcd가 MVCC를 어떻게 구현하는지, compaction과 defrag이 정확히 무슨 일을 하는지, 그리고 K8s API 서버 입장에서 그 영향이 어디서 어떻게 보이는지 정리해본다. 운영 가이드 글은 인터넷에 차고 넘치는데, 정작 "왜"가 빠져있어서 매번 어색하게 cron 주기만 조정하게 된다.MVCC, 그러..