Chaos Mesh vs Litmus, 1년 둘 다 굴려보고 내린 결론

 

작년 이맘때쯤 우리 팀에 Chaos Engineering 도입 미션이 떨어졌다. SRE 본부에서 "장애 대응 훈련을 코드로 돌릴 수 있게 만들자"라는 좀 추상적인 OKR이 내려왔고, 첫 분기는 Chaos Mesh, 두 번째 분기부터는 Litmus로 갈아탔다가, 결국 둘을 섞어서 쓰고 있다. 1년이 지나서 다시 정리해보니 둘 중 뭘 골라야 하느냐는 질문이 잘못된 질문이었다는 결론이 났다. 어느 팀이 어느 부분을 책임지냐에 따라 답이 달라진다.

Litmus는 작년 가을 3.0으로 메이저 버전이 올라가면서 UI가 Harness UIcore 기반으로 싹 바뀌었고, Chaos Workflow가 Chaos Experiments로, Chaos Experiments가 Chaos Faults로 용어가 재정의됐다. 올해 1월에 CNCF가 공개한 Q4 업데이트를 보면 Litmus Cloud가 Harness Enterprise SaaS로 흡수되면서 무료 플랜에 엔터프라이즈 기능이 풀려 있는 상태다. Chaos Mesh는 그동안 큰 메이저 점프 없이 2.7대로 패치 위주로 굴러왔고, kubectl 친화적인 CRD 모델이라는 기조는 그대로다. 1년 사이에 둘의 포지셔닝이 더 갈렸다고 보면 된다.

처음 도입했을 때 Chaos Mesh가 편했던 이유

처음 PoC를 Chaos Mesh로 시작한 건 정말 단순한 이유였다. helm install 한 번, kubectl로 yaml 하나 던지면 실험이 돌았다. 학습 곡선이 거의 없었다. 우리 팀이 GitOps 기반으로 ArgoCD를 쓰고 있어서 실험 자체도 그냥 Application으로 묶어버릴 수 있다는 점이 매력적이었다.

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: order-svc-latency
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  selector:
    namespaces: [order]
    labelSelectors:
      app: order-svc
  delay:
    latency: "200ms"
    jitter: "50ms"
  duration: "5m"

이게 끝이다. 플랫폼팀이 보기에 이상적이다. 우리 팀은 처음 3개월 동안 30개 정도 시나리오를 만들어서 nightly로 돌렸다. 네트워크 지연, pod kill, CPU stress 같은 단골 시나리오는 다 잘 잡혔다.

근데 시간이 지나면서 문제가 생겼다. 개발자들이 직접 자기 서비스 실험을 짜고 싶어 하기 시작했다. yaml 만들어서 PR 올리고 머지하고 ArgoCD 동기화 기다리는 과정이 너무 무거웠다. "내가 만든 결제 서비스에 30초만 latency 줘봐도 되냐"는 요청이 슬랙으로 자꾸 들어왔다. 사실 Chaos Mesh도 dashboard가 있긴 한데, 권한 관리가 좀 거칠다. RBAC를 namespace 단위로 묶긴 해도, 실험 결과를 정리해서 보여주거나 여러 시나리오를 묶어서 워크플로우로 돌리는 기능은 약했다.

Litmus로 갈아탔을 때 좋았던 것과 짜증났던 것

그래서 2분기에 Litmus를 도입했다. 결정타는 ChaosHub였다. AWS 관련 fault가 다양했고(EC2 stop, EBS detach, ELB latency 같은), Workflow로 여러 fault를 순차/병렬로 묶어서 한 번에 돌릴 수 있었다. 개발자들이 자기 서비스에 대한 시나리오를 ChaosCenter UI에서 클릭으로 짜고 결과를 본다는 그림이 그려졌다.

근데 막상 설치하니까 컴포넌트가 너무 많았다. ChaosCenter, MongoDB, Subscriber agent, 그리고 각 클러스터마다 Chaos Infrastructure(예전 Chaos Delegate). 멀티클러스터 환경에서 Subscriber가 ChaosCenter랑 통신할 수 있게 outbound를 뚫는 작업이 의외로 귀찮았다. 우리는 prod 클러스터의 egress가 엄격하게 잠겨 있어서, 결국 ChaosCenter도 같은 VPC에 두는 식으로 타협했다.

3.0으로 올라간 이후 용어 정리는 깔끔해지긴 했는데, 기존 2.x 시절 문서랑 블로그 글이 다 옛날 이름을 쓰고 있어서 트러블슈팅할 때 검색 키워드가 꼬였다. "Chaos Workflow"로 검색하면 옛날 자료, "Chaos Experiment"로 검색하면 또 옛날 의미의 자료가 섞여서 나왔다. 이건 곧 정리되겠지만 한동안 좀 헤맸다.

성능적으로는, 같은 pod kill 시나리오를 돌렸을 때 Chaos Mesh가 명령이 떨어지고 실제로 pod이 죽기까지가 더 빨랐다. Litmus는 experiment runner pod이 새로 떠서 ChaosEngine을 읽고 실행하는 구조라 콜드 스타트 비슷한 게 있다. 1초 단위로 정밀하게 시간을 맞춰야 하는 시나리오에서는 좀 거슬렸다.

1년 지나고 우리가 정착한 구조

결국 우리는 둘을 같이 쓴다. 책임 경계를 이렇게 그었다.

플랫폼팀이 GitOps로 관리하는 "표준 시나리오"는 Chaos Mesh에 둔다. 매주 nightly로 모든 서비스에 공통적으로 도는 시나리오들이다. 노드 한 대 down, 특정 zone의 네트워크 단절, kubelet 일시 정지 같은 인프라 레벨 fault. 이건 SRE가 책임지고 코드로 관리한다.

개발팀이 자기 서비스 단위로 짜는 "실험적 시나리오"는 Litmus의 ChaosCenter UI에서 한다. 결제팀이 "환불 API에 latency 200ms 줘봤더니 주문 서비스 timeout이 100ms로 잡혀있어서 줄줄이 5xx가 났다" 같은 발견을 자기들이 직접 한다. 결과는 ChaosCenter dashboard에 쌓이고, 월말에 한 번 모아서 SRE 리뷰한다.

둘이 충돌 안 나게 namespace를 분리하고, label selector도 명시적으로 다르게 줬다. Chaos Mesh는 chaos-testing namespace, Litmus는 litmus namespace. cluster-wide로 도는 fault가 동시에 안 걸리도록 PriorityClass로 우선순위만 정리했다.

여기서 한 가지 솔직하게 말하면, Litmus 3.0의 Chaos Studio는 아직 우리 팀에서 활발히 쓰이지는 않는다. 개발자들이 UI에서 fault를 튜닝하는 그림이 이상적이긴 한데, 막상 실무에서는 기존 fault를 약간만 손봐서 쓰는 경우가 대부분이라 Studio까지 안 갔다. 이 부분은 좀 더 써봐야 평가가 가능할 것 같다.

그래서 뭘 골라야 하나

플랫폼팀 1-2명이 SRE 영역 안에서 GitOps로 다 관리할 거면 Chaos Mesh로 충분하다. CRD 모델이 명료하고, 운영 부하가 거의 없고, 결과를 Prometheus + Grafana로 보면 된다. 굳이 무거운 ChaosCenter를 띄울 이유가 없다.

여러 개발팀이 셀프서비스로 자기 서비스 chaos 시나리오를 짜는 그림이 필요하면 Litmus 쪽이 맞다. ChaosHub의 fault 라이브러리 양이 압도적이고, 멀티팀 권한 분리가 RBAC 위에 한 층 더 얹혀 있다. 어차피 Harness 생태계랑 엮을 거면 자연스럽다.

그리고 우리처럼 어중간한 규모(클러스터 5-6개, 개발팀 10여 개)면 그냥 둘 다 굴리는 게 답일 수도 있다. 둘이 서로 발 안 밟게만 잘 분리하면 운영 부담은 생각보다 안 늘었다. 단, 이 구조는 SRE 한 명은 두 도구를 다 잘 알고 있어야 한다. 그게 비용이라면 비용이다.

혹시 다른 회사는 어떻게 정착했는지 궁금하다. 우리는 결국 두 도구를 책임 경계로 분리해서 정착했지만, 한쪽으로 통일하고도 잘 굴러가는 케이스가 있다면 그 경험이 더 듣고 싶다.