오퍼레이터 패턴 알아보기

1. 개요

쿠버네티스(Kubernetes)에서 데이터베이스 같은 상태 저장 애플리케이션(Stateful Application)을 굴리다 보면 장애 조치(Failover)는 결국 마주치는 문제다. 예를 들어 Galera Cluster는 노드가 죽으면 grastate.dat의 seqno와 safe_to_bootstrap 값을 확인하고 사람이 손으로 복구 절차를 밟아야 한다. 그런데 이런 수동 개입은 쿠버네티스가 지향하는 자동화 철학과 정면으로 부딪힌다.

이 문제를 풀어보려고 오퍼레이터 패턴(Operator Pattern)을 검토했다. 복잡한 애플리케이션의 설치, 업그레이드, 장애 복구까지 수명 주기 전체를 자동화해서 사람 손이 덜 가게 만드는 방식이다.

2. 오퍼레이터 패턴이란?

오퍼레이터는 쿠버네티스의 컨트롤러(Controller)와 사용자 정의 리소스(CRD, Custom Resource Definition)를 엮어 애플리케이션 운영 노하우를 코드로 박아둔 것이다.

CRD: 새로운 리소스 타입을 직접 정의하게 해준다. 예를 들어 MariaDB라는 리소스를 만들고, 버전이나 레플리카 수 같은 속성을 붙일 수 있다.
CR (Custom Resource): CRD로부터 찍어낸 인스턴스다. 사용자는 MariaDB CR을 만들어 원하는 상태를 선언한다.
Controller: CR을 지켜보다가 현재 상태를 선언된 상태에 맞춘다. MariaDB CR에 레플리카 3이 적혀 있는데 실제로는 2개만 돈다면, 컨트롤러가 하나를 더 띄워 3을 맞춘다.

말하자면 오퍼레이터는 특정 앱에 대한 전문 지식을 가진 자동화된 SRE(Site Reliability Engineer)다. “MariaDB 클러스터 하나 만들어줘”라고 CR로 선언하면, PVC 생성부터 StatefulSet 배포, 서비스 생성, 장애 시 자동 복구까지 알아서 한다는 뜻이다.

2.1. 장점

운영 자동화: 설치·확장·업그레이드·백업·복구 같은 번거로운 작업을 대신 해준다.
전문 지식 캡슐화: 운영 노하우가 코드에 담겨 있어, 그 앱을 깊이 모르는 사람도 굴릴 수 있다.
일관성: 어느 환경에서든 같은 방식으로 배포·관리되니 실수가 줄어든다.

2.2. 단점

러닝 커브: 오퍼레이터가 어떻게 동작하는지 이해하고 디버깅하려면 별도 학습이 든다.
개발 복잡성: 직접 만들려면 쿠버네티스 API와 컨트롤러 로직을 깊이 알아야 해서 손이 많이 간다.

3. Operator Hub

OperatorHub.io는 검증된 오퍼레이터를 찾고 공유하는 중앙 저장소다. DB, 모니터링, 네트워킹 등 분야별 오퍼레이터가 올라와 있고, 각각 성숙도에 따라 Capability Level이 매겨진다.

Level 1 (Basic Install): 기본 설치·설정 자동화
Level 2 (Seamless Upgrades): 버전 업그레이드 지원
Level 3 (Full Lifecycle): 백업·복구 등 수명 주기 관리
Level 4 (Deep Insights): 모니터링·로깅·분석 제공
Level 5 (Auto Pilot): 자동 스케일링·자가 치유·이상 탐지

4. 결론

상태 저장 앱을 안정적으로 굴리는 데 오퍼레이터 패턴은 꽤 쓸 만한 답이라고 봤다. 직접 만드는 건 부담이지만, OperatorHub.io처럼 검증된 걸 가져다 쓰면 복잡한 운영을 상당 부분 자동화할 수 있다.

개인적으로는 오퍼레이터에 익숙해져서 관리 방식을 통일해두는 편이 길게 보면 이득이라고 판단했다. 그래서 지금 프로젝트에는 아래 오퍼레이터를 들이기로 했다.

MariaDB: mariadb-operator (Level 4)
Redis: ot-redis-operator (Level 2)
Elasticsearch: eck-operator (Level 4)
RabbitMQ: rabbitmq-cluster-operator (Level 3)

이걸로 DB와 메시징 시스템의 배포·확장·장애 복구를 자동화하면, 개발팀이 비즈니스 로직에 더 집중할 여유가 생긴다. 나중에는 직접 오퍼레이터를 만들어 솔루션에 붙여보는 것도 좋은 경험이 되지 않을까 싶다.

🛖

탐색기