52편 · 약 17분

Percona Operator for MySQL 1.2.0: PerconaServerMySQLClusterSet·암호화 백업·자동 스토리지 확장으로 K8s MySQL 운영을 강화하는 방법

왜 지금 봐야 하나

2026년 7월 3일 Percona가 Percona Operator for MySQL 1.2.0을 출시했다. 이 릴리스의 세 가지 핵심 기능은 순서대로 운영 비용이 높은 문제를 다룬다.

첫째, 지역 재해복구(DR)를 선언적으로 관리하는 새로운 Custom Resource가 생겼다. PerconaServerMySQLClusterSet은 여러 Group Replication 클러스터를 하나의 InnoDB ClusterSet 토폴로지로 묶고, MySQL Shell과의 연동을 Operator가 자동화한다. 이전에는 재해복구 사이트를 추가하려면 MySQL Shell 명령을 수동으로 실행해야 했다.

둘째, 백업을 클라우드 스토리지에 올리기 전에 XtraBackup이 암호화한다. AES256이 기본이며 스토리지별로 알고리즘을 달리 설정할 수 있다. Vault 연동 유효성 검증도 추가됐다.

셋째, 디스크 사용량을 Operator가 감시하다가 PVC를 자동으로 확장한다. "디스크 꽉 참" 장애는 DBA 야간 알림의 단골 원인이다. 임계값 기반 자동 확장은 이 문제를 대응에서 예방으로 바꾼다.

이 글은 세 기능의 작동 방식과 도입 전 확인해야 할 운영 기준점을 다룬다.

주의: Percona Operator for MySQL은 두 종류가 있다. 이 글은 Percona Server for MySQL(Group Replication 기반) Operator 1.2.0을 다룬다. Percona XtraDB Cluster(PXC) Operator는 별도 제품(현재 1.20.x)이다.

릴리스 전체 변경 요약

기능 범주	변경 사항
복제 토폴로지	`PerconaServerMySQLClusterSet` CRD 추가 (InnoDB ClusterSet 선언적 관리)
백업 보안	백업 암호화 지원 (XtraBackup xbcrypt, AES256 기본)
스토리지	PVC 자동 확장 (임계값 기반); 외부 Autoscaler 위임 옵션 추가
보안 강화	Orchestrator API 인증 추가; Vault 암호화 시크릿 유효성 검증
접속 정보	루트 사용자 시크릿에 호스트·포트·URI 통합
PITR	복원 오브젝트에서 binlog 설정 직접 지정 가능
네트워크	LoadBalancer Service에서 NodePort 할당 비활성화 옵션
HAProxy	사이드카 컨테이너 독립적 리소스 설정 지원

핵심 기능 1: PerconaServerMySQLClusterSet

InnoDB ClusterSet의 구조

MySQL InnoDB ClusterSet은 여러 InnoDB Cluster를 하나의 재해복구 토폴로지로 연결하는 개념이다. 하나의 클러스터가 Primary(쓰기 담당)이고, 나머지 클러스터는 Replica(읽기 전용)가 된다. 사이트 간 복제는 비동기 방식으로 작동하기 때문에 지리적으로 먼 거리의 네트워크 지연이 Primary의 쓰기 성능에 영향을 주지 않는다.

이전에는 이 구조를 구성하고 관리하려면 MySQL Shell에서 직접 명령을 실행해야 했다.

-- MySQL Shell에서 수동으로 ClusterSet 구성 (이전 방식)
var clusterset = cluster.createClusterSet("MyClusterSet");
clusterset.addReplicaCluster("replica-host:3306", "ReplicaCluster");

1.2.0부터는 PerconaServerMySQLClusterSet 커스텀 리소스를 선언하면 Operator가 MySQL Shell 연동을 자동화한다.

PerconaServerMySQLClusterSet CRD

apiVersion: ps.percona.com/v1
kind: PerconaServerMySQLClusterSet
metadata:
  name: my-clusterset
spec:
  primaryCluster:
    name: mysql-primary     # Primary PerconaServerMySQL 리소스 이름
    namespace: db-prod
  replicaClusters:
    - name: mysql-dr        # Replica PerconaServerMySQL 리소스 이름
      namespace: db-dr-site # 같은 K8s 클러스터, 또는 다른 클러스터

Operator는 이 스펙을 읽고:

MySQL Shell로 ClusterSet을 부트스트랩하고
Replica 클러스터를 Primary에 연결하고
status 필드에 현재 토폴로지 상태를 기록한다.

Primary 변경도 선언적으로 처리된다. spec.primaryCluster를 바꾸면 Operator가 Switchover 또는 Failover를 실행한다.

InnoDB ClusterSet 토폴로지 — Percona Operator 관리

Switchover vs Failover

Operator가 처리하는 두 가지 전환 시나리오:

Switchover (계획적 전환, 데이터 손실 없음)

사용 시점: 계획된 유지보수, 부하 분산, 리전 이동
방법: spec.primaryCluster를 Replica 클러스터로 변경
Operator 동작: MySQL Shell의 clusterset.setPrimaryCluster() 실행 → Primary 역할 안전 이관
이전 Primary는 자동으로 Replica가 됨

Failover (강제 전환, 데이터 손실 가능)

사용 시점: Primary 사이트 전체 장애
방법: spec.primaryCluster를 생존한 Replica로 변경 + 강제 플래그 설정
Operator 동작: clusterset.forcePrimaryCluster() 실행
아직 복제되지 않은 쓰기는 손실될 수 있음 (비동기 복제의 특성)
복구 후 원래 Primary를 다시 Replica로 재참여시키는 rejoin 절차 필요

핵심 기능 2: 백업 암호화

XtraBackup 1.2.0부터 백업 스트림을 클라우드 스토리지에 업로드하기 전에 암호화할 수 있다. XtraBackup의 xbcrypt 컴포넌트가 스트림을 처리한다.

설정 구조

암호화는 PerconaServerMySQL 리소스의 backup 섹션에서 설정한다.

spec:
  backup:
    storages:
      s3-main:
        type: s3
        s3:
          bucket: my-mysql-backups
          region: ap-northeast-2
        encryption:
          enabled: true
          # 키를 Vault에서 가져오는 경우
          vaultSecretName: mysql-backup-vault-secret
          # 또는 K8s Secret 직접 사용
          secretName: mysql-backup-encryption-key

      s3-cold:           # 다른 스토리지는 다른 설정 가능
        type: s3
        s3:
          bucket: my-mysql-backups-cold
        encryption:
          enabled: true
          # 알고리즘 기본값: AES256

전역 설정 vs 스토리지별 설정

전역 암호화를 켜면 모든 스토리지에 적용되고, 스토리지별로 오버라이드할 수 있다. 예를 들어 프로덕션 버킷은 암호화하고 개발 버킷은 건너뛰는 구성이 가능하다.

Vault 유효성 검증 (1.2.0 신규)

Vault에서 암호화 키를 가져오는 경우, 1.2.0부터 Operator가 시작 시 Vault 연결과 키 접근 권한을 미리 검증한다. 백업이 실행될 때까지 Vault 문제를 모르고 있다가 실패하는 상황을 방지한다.

핵심 기능 3: 자동 스토리지 확장

작동 방식

Operator가 MySQL Pod의 PVC 디스크 사용량을 주기적으로 모니터링한다. 사용량이 설정한 임계값을 초과하면 PVC 크기를 자동으로 늘린다.

spec:
  storageScaling:
    enabled: true
    threshold: 80        # 사용량이 80% 초과 시 확장 시작
    increasePercent: 25  # 현재 크기의 25%씩 증가
    maxSize: 500Gi       # 최대 크기 상한

이 설정으로 100Gi PVC는 80% 사용 시 125Gi로 늘어나고, 다시 80%에 도달하면 156Gi로 늘어나는 식이다. StorageClass가 동적 확장(allowVolumeExpansion: true)을 지원해야 한다.

외부 Autoscaler 위임

자체 스토리지 자동화 솔루션을 이미 운영 중인 경우:

spec:
  storageScaling:
    enableExternalAutoscaling: true  # Operator의 내장 확장 비활성화

이 경우 Operator는 PVC 크기를 직접 건드리지 않고, 외부 시스템이 담당한다.

운영 주의사항

자동 확장에는 세 가지 전제 조건이 있다.

StorageClass 지원: allowVolumeExpansion: true가 설정된 StorageClass 필요. AWS EBS gp3, GCP Persistent Disk, Azure Managed Disk는 기본 지원. 일부 온프레미스 스토리지는 확인 필요.

축소 불가: PVC 자동 확장은 단방향이다. 한번 늘어난 PVC는 Operator가 줄이지 않는다. 과도하게 늘어난 PVC를 줄이려면 별도 마이그레이션 작업이 필요하다.

maxSize 설정 권장: 상한 없이 두면 디스크 증가 이상 장애(급격한 테이블 성장, 로그 폭증)가 스토리지 비용 폭증으로 이어질 수 있다.

기타 운영 개선사항

루트 사용자 시크릿에 접속 URI 통합

1.2.0 이전에는 MySQL 접속 정보(호스트, 포트, 비밀번호)가 각각 다른 곳에 흩어져 있거나, 애플리케이션이 직접 조합해야 했다.

1.2.0부터 <cluster-name>-psuser-root 시크릿에 host, port, URI(직접 접속과 프록시 접속 모두)가 통합된다.

kubectl get secret mysql-cluster-psuser-root -o jsonpath='{.data}' | \
  base64 -d  # host, port, uri 필드 포함

Orchestrator API 인증

Orchestrator는 MySQL 토폴로지를 관리하는 컴포넌트다. 1.2.0부터 Orchestrator HTTP API에 인증이 추가됐다. 이전에는 클러스터 내부에서 Orchestrator API가 인증 없이 접근 가능했다.

이 변화는 기존 배포에서 Orchestrator API를 직접 호출하는 스크립트나 모니터링 도구가 있다면 인증 헤더 추가가 필요하다. 1.2.0으로 업그레이드 전 확인할 것.

PITR 복원 오브젝트에 binlog 설정

Point-in-time Recovery 실행 시 바이너리 로그 시작점과 대상 시간을 복원 오브젝트에 직접 지정할 수 있다. 별도 구성 파일 없이 복원 리소스 하나로 PITR을 완전히 선언할 수 있게 됐다.

apiVersion: ps.percona.com/v1
kind: PerconaServerMySQLRestore
metadata:
  name: restore-pitr-20260703
spec:
  clusterName: mysql-cluster
  backupName: full-backup-20260703
  pitr:
    type: date
    date: "2026-07-03 14:30:00"
    binlogSourceName: mysql-cluster-binlog  # 1.2.0 신규: 복원 오브젝트에서 직접 지정

도입 전 체크리스트

ClusterSet 도입 전

[ ] DR 사이트의 네트워크 레이턴시 측정 (비동기 복제이므로 Primary 성능에 직접 영향 없음, 단 복제 지연 모니터링 필요)
[ ] 각 사이트의 K8s 클러스터에 Percona Operator 1.2.0 배포 확인
[ ] MySQL Shell이 Primary → Replica 방향으로 접근 가능한 네트워크 정책 확인
[ ] Switchover vs Failover 시 RTO/RPO 요구사항과 비동기 복제 지연 허용 범위 검토

백업 암호화 도입 전

[ ] 암호화 키 관리 방식 결정 (K8s Secret vs Vault)
[ ] 기존 암호화되지 않은 백업의 보존 정책 확인 (새 백업부터 암호화됨)
[ ] 복원 테스트: 암호화 키가 있는 환경에서 복원이 작동하는지 검증
[ ] Vault 사용 시 Operator의 Vault 접근 권한 사전 검증 확인

자동 스토리지 확장 도입 전

[ ] StorageClass의 allowVolumeExpansion: true 여부 확인
[ ] maxSize 설정으로 비용 상한 지정
[ ] 확장 이벤트에 대한 알림/모니터링 설정 (Operator가 확장하면 이벤트 기록)
[ ] 비용 예산 검토: 스토리지 자동 확장은 비용 자동 증가를 의미

1.1.x → 1.2.0 업그레이드 전

[ ] Orchestrator API를 직접 호출하는 내부 스크립트나 도구 파악 → 인증 헤더 추가 준비
[ ] 업그레이드 전 전체 백업 실행
[ ] 스테이징 환경에서 1.2.0 Operator 테스트 후 프로덕션 적용

Open question

InnoDB ClusterSet의 자동 Failover(사람이 개입 없이 Operator가 Primary 장애를 감지해 자동 전환하는 기능)는 1.2.0에 포함되지 않았다. 강제 Failover는 여전히 수동 트리거다.
ClusterSet을 구성한 후 두 K8s 클러스터 간 네트워크 파티션(split-brain)이 발생했을 때 Operator의 동작 방식은 아직 문서화가 부족하다.
자동 스토리지 확장과 클러스터 레벨 스토리지 쿼터(LimitRange, ResourceQuota)의 상호작용은 StorageClass와 클라우드 프로바이더에 따라 다르다.