Zulip과 Anytype을 HA로 구성하기 전 생각해야 하는 것
Kubernetes에서 Node Affinity가 있는 Storage를 가진 서비스가 있다고 하자. 여기서의 Storage는 Database와 Filesystem 혹은 Object Storage 전반을 말한다. 해당 노드가 하드웨어 전원 공급 혹은 발열 등의 문제로 꺼진다면 어떻게 될까? 적어도 그 문제를 해결할 때까지, 어쩌면 문제를 파악하기까지도 하루 이상이 걸릴 것이다. 스냅샷을 통해 타 노드에서 복제하더라도 말이다. 그 동안 서비스는 마비될 것이다. 따라서 Storage에 대한 HA 구성이 필수적이라고 할 수 있다. 적어도 그렇게 해야만 하는 하드웨어 환경과 비즈니스적인 상황을 가정하고 있다.
Homelab에서 비즈니스 수준 서버를 구축해야 하는 황당한 문제이긴 하지만, 해볼만한 가치가 있다고 생각한다.
Zulip과 Anytype의 서버를 HA 구성으로 하기 위해선, Persistent Storage의 복제가 필수적이다. 그래야 Node Affinity의 영향을 줄일 수 있다. 이를 위해선 DB Standby 구성, Ceph나 Longhorn, MinIO 등을 Kubernetes 상에서 구동해야 한다. 하나씩 천천히 살펴보도록 하자.
DB는 생각보다 간단하다. 문서를 읽으면 된다. Operator에서 아마 Parameter를 제공할테니, 기존 Helm Chart를 수정해, 사전에 Operator를 통해 생성한 Postgres 혹은 MongoDB Node를 사용하도록 하면 된다. DB에서 보장하는 Durability는 DB마다 다르기야 하겠지만, 적어도 서비스가 알아서 해결 가능한 범위일터다.
Block Storage의 Replication은 좀 더 문제가 복잡한데, Ceph나 Longhorn은 Operator 혹은 Helm을 이용하면 편리하게 설치할 수 있으나, Longhorn이 어떤 정도의 복제를 보장하는지 알 도리가 없고, 무엇보다 레딧 포럼에서는 데이터를 날렸다는 이야기를 가끔 본다. 이전 회사에서도 Longhorn이 설명하기 어려운 동작을 하는 경우를 많이 보았다.
포럼에서 Ceph를 10년이 넘게 잘만 쓴다고 하니 Longhorn을 선택지에 넣고 싶지 않다. 하지만 k8s의 distribution을 k3s로 선택한 이상, rook 등으로 ceph를 구성하는 것이 어려워보인다. distribution을 바꾸는 것은 또 하나의 일이 된다. Talos로 바꿔야 할까? Longhorn을 계속 사용해도 될까?
다행히 MinIO는 이미 만들어진 Block Storage를 기반으로 쌓기만 하면 될 것이다.
요샌 이런 고민을 계속하고 있다. 빠르게 해결할 수 있다면 좋으련만.