🔍 Deployment vs StatefulSet

일반적인 웹 애플리케이션을 생각해봐. 프론트엔드 서버 3대가 있다면, 이 서버들은 서로 구별할 필요가 없어. 어떤 서버로 요청이 가든 같은 결과를 내놓으니까. 이런 경우엔 Deployment가 완벽해.

하지만 데이터베이스는 달라! MySQL 클러스터를 예로 들면:
• Master DB는 쓰기 작업을 담당
• Replica DB들은 읽기 작업을 담당
• 각 DB 인스턴스는 고유한 데이터 디렉토리를 가져야 함
• 복제 순서가 중요함 (Master → Replica1 → Replica2)

이런 요구사항을 충족시키려면 StatefulSet이 필요해! ✨

StatefulSet으로 생성된 각 Pod는 {statefulset-name}-{ordinal} 형식의 이름을 가져. 예를 들어:

mysql-0
mysql-1
mysql-2

이 이름들은 Pod가 재시작되거나 재스케줄링되어도 절대 바뀌지 않아. 그리고 각 Pod는 다음과 같은 DNS 이름을 자동으로 얻게 돼:

{pod-name}.{service-name}.{namespace}.svc.cluster.local

예시: mysql-0.mysql-service.default.svc.cluster.local

이게 왜 중요하냐고? 데이터베이스 복제 설정을 생각해봐. Master DB의 주소를 Replica에 설정해야 하는데, 이 주소가 계속 바뀌면 복제가 깨지잖아! StatefulSet은 이런 문제를 원천적으로 해결해줘. 🎯

volumeClaimTemplates를 사용하면:

volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: [ "ReadWriteOnce" ]
    resources:
      requests:
        storage: 100Gi

이렇게 설정하면 각 Pod마다:

• mysql-0 → data-mysql-0 (100GB)
• mysql-1 → data-mysql-1 (100GB)
• mysql-2 → data-mysql-2 (100GB)

이런 식으로 독립적인 스토리지가 할당돼. 그리고 Pod가 삭제되어도 PVC는 남아있어서 데이터가 보존되지! 🛡️

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config
  namespace: database
data:
  master.cnf: |
    [mysqld]
    log-bin=mysql-bin
    server-id=1
    binlog-format=ROW
    
  slave.cnf: |
    [mysqld]
    server-id=2
    relay-log=relay-bin
    read-only=1

여기서 log-bin은 바이너리 로그를 활성화하는 설정이고, server-id는 각 MySQL 인스턴스를 구별하는 고유 ID야. Master는 쓰기가 가능하고, Slave는 read-only=1로 읽기 전용으로 설정했어. ⚙️

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
  namespace: database
type: Opaque
data:
  root-password: bXlzcWxyb290cGFzc3dvcmQ=  # base64 encoded
  replication-password: cmVwbGljYXRpb25wYXNz  # base64 encoded

비밀번호를 base64로 인코딩하려면 터미널에서:

echo -n "mysqlrootpassword" | base64

이렇게 실행하면 돼. 🔒

apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
  namespace: database
spec:
  clusterIP: None  # Headless Service의 핵심!
  selector:
    app: mysql
  ports:
  - name: mysql
    port: 3306
    targetPort: 3306

clusterIP: None이 핵심이야. 이렇게 하면 Service가 로드밸런싱을 하지 않고, 각 Pod의 IP를 직접 DNS로 반환해줘. 그래서 mysql-0.mysql-headless.database.svc.cluster.local 같은 주소로 특정 Pod에 직접 접근할 수 있지! 🎯

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: database
spec:
  serviceName: mysql-headless
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:8.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          # Pod 순서 번호 추출
          [[ $(hostname) =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          
          # Master(0번)와 Slave 구분
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/master.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/slave.cnf /mnt/conf.d/
            # Slave의 server-id는 순서번호 + 100
            sed -i "s/server-id=2/server-id=$((100 + $ordinal))/" /mnt/conf.d/slave.cnf
          fi
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
          
      - name: clone-mysql
        image: gcr.io/google-samples/xtrabackup:1.0
        command:
        - bash
        - "-c"
        - |
          set -ex
          [[ $(hostname) =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          
          # Master는 복제할 필요 없음
          [[ $ordinal -eq 0 ]] && exit 0
          
          # 이전 Pod에서 데이터 복제
          ncat --recv-only mysql-$(($ordinal-1)).mysql-headless 3307 | xbstream -x -C /var/lib/mysql
          xtrabackup --prepare --target-dir=/var/lib/mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
          
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        ports:
        - name: mysql
          containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
          limits:
            cpu: 1000m
            memory: 2Gi
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
          timeoutSeconds: 1
          
      - name: xtrabackup
        image: gcr.io/google-samples/xtrabackup:1.0
        ports:
        - name: xtrabackup
          containerPort: 3307
        command:
        - bash
        - "-c"
        - |
          set -ex
          cd /var/lib/mysql
          
          # 복제 요청 대기
          if [[ -f xtrabackup_slave_info ]]; then
            mv xtrabackup_slave_info change_master_to.sql.in
            rm -f xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
            [[ $(cat xtrabackup_binlog_info) =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi
          
          # 복제 데이터 전송
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
          subPath: mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
          
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql-config
          
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: standard
      resources:
        requests:
          storage: 100Gi

# 네임스페이스 생성
kubectl create namespace database

# ConfigMap, Secret 적용
kubectl apply -f mysql-configmap.yaml
kubectl apply -f mysql-secret.yaml

# Service 생성
kubectl apply -f mysql-service.yaml

# StatefulSet 배포
kubectl apply -f mysql-statefulset.yaml

# 배포 상태 확인
kubectl get statefulset -n database
kubectl get pods -n database -w

Pod가 순차적으로 생성되는 걸 볼 수 있을 거야:
mysql-0 → Running → Ready
mysql-1 → Running → Ready
mysql-2 → Running → Ready

각 단계가 완료되어야 다음 Pod가 생성되는 거 보이지? 이게 바로 StatefulSet의 순차 배포야! 🎯

# Master Pod에 접속
kubectl exec -it mysql-0 -n database -- mysql -uroot -p

# 복제 사용자 생성
CREATE USER 'replicator'@'%' IDENTIFIED BY 'replication_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';
FLUSH PRIVILEGES;

# Master 상태 확인
SHOW MASTER STATUS;

출력 결과에서 File과 Position 값을 기억해둬. 이게 복제 시작점이야! 📍

# Slave Pod에 접속 (mysql-1)
kubectl exec -it mysql-1 -n database -- mysql -uroot -p

# Master 연결 설정
CHANGE MASTER TO
  MASTER_HOST='mysql-0.mysql-headless.database.svc.cluster.local',
  MASTER_USER='replicator',
  MASTER_PASSWORD='replication_password',
  MASTER_LOG_FILE='mysql-bin.000001',  # SHOW MASTER STATUS에서 확인한 값
  MASTER_LOG_POS=154;                   # SHOW MASTER STATUS에서 확인한 값

# 복제 시작
START SLAVE;

# 복제 상태 확인
SHOW SLAVE STATUS\G

Slave_IO_Running: Yes와 Slave_SQL_Running: Yes가 보이면 성공이야! ✅

mysql-2도 똑같이 설정해주면 돼. 여기서 중요한 건 Master 호스트를 mysql-0.mysql-headless.database.svc.cluster.local로 지정했다는 거야. StatefulSet 덕분에 이 DNS 이름이 절대 바뀌지 않거든! 🎯

# Master에서 테스트 데이터 생성
kubectl exec -it mysql-0 -n database -- mysql -uroot -p

CREATE DATABASE testdb;
USE testdb;
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (name) VALUES ('Alice'), ('Bob'), ('Charlie');

# Slave에서 확인 (mysql-1)
kubectl exec -it mysql-1 -n database -- mysql -uroot -p

USE testdb;
SELECT * FROM users;

Master에서 입력한 데이터가 Slave에도 똑같이 보이면 복제가 정상 작동하는 거야! 🎉

# StatefulSet 전체 상태
kubectl get statefulset mysql -n database

# 출력 예시:
# NAME    READY   AGE
# mysql   3/3     2h

# 각 Pod 상세 정보
kubectl get pods -n database -l app=mysql -o wide

# 특정 Pod의 로그 확인
kubectl logs mysql-0 -n database -c mysql --tail=100

# 복제 지연 확인 (Slave에서)
kubectl exec mysql-1 -n database -- mysql -uroot -p -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master

Seconds_Behind_Master가 0이면 복제가 실시간으로 잘 되고 있는 거야. 숫자가 크면 복제 지연이 발생하고 있다는 뜻이지. ⏱️

StatefulSet의 containers 섹션에 추가:

- name: mysql-exporter
  image: prom/mysqld-exporter:latest
  env:
  - name: DATA_SOURCE_NAME
    value: "root:$(MYSQL_ROOT_PASSWORD)@(localhost:3306)/"
  ports:
  - name: metrics
    containerPort: 9104
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi

그리고 Service에 metrics 포트 추가:

- name: metrics
  port: 9104
  targetPort: 9104

이제 Prometheus가 각 MySQL 인스턴스의 메트릭을 수집할 수 있어. Grafana 대시보드로 시각화하면 완벽하지! 📊

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mysql-backup
  namespace: database
spec:
  schedule: "0 2 * * *"  # 매일 새벽 2시
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: mysql:8.0
            command:
            - /bin/bash
            - -c
            - |
              BACKUP_DATE=$(date +%Y%m%d_%H%M%S)
              mysqldump -h mysql-0.mysql-headless \
                -uroot -p${MYSQL_ROOT_PASSWORD} \
                --all-databases \
                --single-transaction \
                --quick \
                --lock-tables=false \
                > /backup/mysql_backup_${BACKUP_DATE}.sql
              
              # S3나 다른 스토리지로 업로드
              aws s3 cp /backup/mysql_backup_${BACKUP_DATE}.sql \
                s3://my-backup-bucket/mysql/
              
              # 30일 이상 된 백업 삭제
              find /backup -name "mysql_backup_*.sql" -mtime +30 -delete
            env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-secret
                  key: root-password
            - name: AWS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  name: aws-credentials
                  key: access-key
            - name: AWS_SECRET_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  name: aws-credentials
                  key: secret-key
            volumeMounts:
            - name: backup
              mountPath: /backup
          restartPolicy: OnFailure
          volumes:
          - name: backup
            persistentVolumeClaim:
              claimName: mysql-backup-pvc

이렇게 하면 매일 자동으로 백업이 생성되고 S3에 저장돼. 30일 이상 된 백업은 자동으로 삭제되니까 스토리지 관리도 편해! 🗄️

# Replica 개수 늘리기 (3 → 5)
kubectl scale statefulset mysql --replicas=5 -n database

# 상태 확인
kubectl get pods -n database -l app=mysql -w

mysql-3과 mysql-4가 순차적으로 생성될 거야. 그리고 자동으로 mysql-2에서 데이터를 복제해서 클러스터에 합류하지!

반대로 줄일 때는:

kubectl scale statefulset mysql --replicas=3 -n database

mysql-4부터 역순으로 삭제돼. Master(mysql-0)는 항상 마지막까지 보호되니까 안심해도 돼! 🛡️

자동 복구 프로세스:

1. Kubernetes가 Pod 장애를 감지 (livenessProbe 실패)
2. 같은 이름(mysql-1)으로 새 Pod 생성
3. 같은 PVC(data-mysql-1)를 마운트
4. 데이터는 그대로 유지되므로 복제 재개
5. readinessProbe 통과 후 서비스 재개

이 모든 과정이 자동으로 진행돼! StatefulSet의 자가 치유 능력이지. 🔄

수동 페일오버 절차:

# 1. 가장 최신 Replica 선택 (복제 지연이 가장 적은)
kubectl exec mysql-1 -n database -- mysql -uroot -p -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master

# 2. 선택한 Replica를 Master로 승격
kubectl exec mysql-1 -n database -- mysql -uroot -p

STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only = OFF;

# 3. 다른 Replica들을 새 Master로 재설정
kubectl exec mysql-2 -n database -- mysql -uroot -p

STOP SLAVE;
CHANGE MASTER TO
  MASTER_HOST='mysql-1.mysql-headless.database.svc.cluster.local',
  MASTER_USER='replicator',
  MASTER_PASSWORD='replication_password',
  MASTER_AUTO_POSITION=1;
START SLAVE;

# 4. 애플리케이션의 쓰기 엔드포인트를 mysql-1로 변경

이 과정을 자동화하려면 Orchestrator나 ProxySQL 같은 도구를 사용할 수 있어. 🤖

백업에서 복구하기:

# 1. 문제가 있는 Pod 중지
kubectl scale statefulset mysql --replicas=0 -n database

# 2. 백업 파일 다운로드
aws s3 cp s3://my-backup-bucket/mysql/mysql_backup_20240115_020000.sql /tmp/

# 3. 새로운 Pod로 복구
kubectl scale statefulset mysql --replicas=1 -n database
kubectl wait --for=condition=ready pod/mysql-0 -n database

# 4. 백업 복원
kubectl cp /tmp/mysql_backup_20240115_020000.sql mysql-0:/tmp/ -n database
kubectl exec mysql-0 -n database -- mysql -uroot -p < /tmp/mysql_backup_20240115_020000.sql

# 5. 나머지 Replica 재시작
kubectl scale statefulset mysql --replicas=3 -n database

Point-in-Time Recovery(PITR)가 필요하면 바이너리 로그를 함께 백업해야 해. ⏰

복제 재시작 방법:

# Slave에서
STOP SLAVE;

# 에러 확인
SHOW SLAVE STATUS\G

# 특정 에러 건너뛰기 (주의해서 사용!)
SET GLOBAL sql_slave_skip_counter = 1;

# 복제 재시작
START SLAVE;

# 상태 재확인
SHOW SLAVE STATUS\G

apiVersion: v1
kind: ConfigMap
metadata:
  name: mysql-config-optimized
  namespace: database
data:
  master.cnf: |
    [mysqld]
    # 기본 설정
    log-bin=mysql-bin
    server-id=1
    binlog-format=ROW
    
    # 성능 튜닝
    innodb_buffer_pool_size=4G          # 전체 메모리의 70-80%
    innodb_log_file_size=512M
    innodb_flush_log_at_trx_commit=2    # 성능 vs 안정성 트레이드오프
    innodb_flush_method=O_DIRECT
    
    # 연결 설정
    max_connections=500
    max_connect_errors=100000
    
    # 쿼리 캐시 (MySQL 8.0에서는 제거됨)
    # query_cache_type=1
    # query_cache_size=256M
    
    # 스레드 풀
    thread_cache_size=100
    
    # 테이블 캐시
    table_open_cache=4000
    table_definition_cache=2000
    
    # 임시 테이블
    tmp_table_size=256M
    max_heap_table_size=256M
    
    # 바이너리 로그
    expire_logs_days=7
    max_binlog_size=100M
    binlog_cache_size=1M
    
    # 복제 최적화
    slave_parallel_workers=4
    slave_parallel_type=LOGICAL_CLOCK

이 설정들은 8GB 메모리 기준이야. 실제 환경에 맞게 조정해야 해! 🎛️

resources:
  requests:
    cpu: 2000m      # 2 CPU cores
    memory: 4Gi     # 4GB RAM
  limits:
    cpu: 4000m      # 최대 4 CPU cores
    memory: 8Gi     # 최대 8GB RAM

requests vs limits:
• requests: Pod가 보장받는 최소 리소스. 스케줄링 시 이 값을 기준으로 노드를 선택해.
• limits: Pod가 사용할 수 있는 최대 리소스. 이를 초과하면 throttling(CPU) 또는 OOM kill(메모리)이 발생해.

프로덕션에서는 requests와 limits를 같게 설정하는 게 좋아. 이렇게 하면 Guaranteed QoS 클래스를 받아서 가장 안정적으로 운영할 수 있거든! 🎯

StorageClass 선택:

volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: ["ReadWriteOnce"]
    storageClassName: fast-ssd  # SSD 기반 스토리지 사용
    resources:
      requests:
        storage: 100Gi

클라우드 환경별 권장 스토리지:

• AWS: gp3 (범용 SSD) 또는 io2 (프로비저닝된 IOPS)
• GCP: pd-ssd (SSD 영구 디스크)
• Azure: Premium SSD 또는 Ultra Disk

HDD는 절대 사용하지 마! 데이터베이스에는 IOPS가 생명이야. ⚡

Service 분리:

# 쓰기용 Service (Master만)
apiVersion: v1
kind: Service
metadata:
  name: mysql-write
  namespace: database
spec:
  selector:
    app: mysql
    statefulset.kubernetes.io/pod-name: mysql-0
  ports:
  - port: 3306
    targetPort: 3306

---
# 읽기용 Service (모든 Replica)
apiVersion: v1
kind: Service
metadata:
  name: mysql-read
  namespace: database
spec:
  selector:
    app: mysql
  ports:
  - port: 3306
    targetPort: 3306

애플리케이션에서:

// 쓰기 작업
writeDB = mysql.connect("mysql-write.database.svc.cluster.local")
writeDB.execute("INSERT INTO users ...")

// 읽기 작업
readDB = mysql.connect("mysql-read.database.svc.cluster.local")
readDB.query("SELECT * FROM users ...")

이렇게 하면 읽기 부하가 모든 Replica에 분산돼서 Master의 부담이 줄어들어! 📈

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mysql-network-policy
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: mysql
  policyTypes:
  - Ingress
  - Egress
  ingress:
  # 같은 네임스페이스의 애플리케이션만 허용
  - from:
    - namespaceSelector:
        matchLabels:
          name: application
    ports:
    - protocol: TCP
      port: 3306
  # 모니터링 시스템 허용
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9104
  egress:
  # DNS 조회 허용
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53
  # 같은 네임스페이스 내부 통신 (복제)
  - to:
    - podSelector:
        matchLabels:
          app: mysql
    ports:
    - protocol: TCP
      port: 3306
    - protocol: TCP
      port: 3307

이렇게 하면 허가된 네임스페이스에서만 DB에 접근할 수 있어. 외부에서 직접 접근은 완전히 차단되지! 🚫

1. 전송 중 암호화 (TLS/SSL):

[mysqld]
require_secure_transport=ON
ssl-ca=/etc/mysql/certs/ca.pem
ssl-cert=/etc/mysql/certs/server-cert.pem
ssl-key=/etc/mysql/certs/server-key.pem

2. 저장 데이터 암호화:

[mysqld]
early-plugin-load=keyring_file.so
keyring_file_data=/var/lib/mysql-keyring/keyring

# 테이블 생성 시
CREATE TABLE sensitive_data (
  id INT PRIMARY KEY,
  data VARCHAR(255)
) ENCRYPTION='Y';

3. 백업 암호화:

# mysqldump 시 암호화
mysqldump --all-databases | \
  openssl enc -aes-256-cbc -salt -out backup.sql.enc

# 복원 시
openssl enc -d -aes-256-cbc -in backup.sql.enc | \
  mysql -uroot -p

# 애플리케이션용 사용자 (읽기/쓰기)
CREATE USER 'app_user'@'%' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'app_user'@'%';

# 읽기 전용 사용자 (분석, 리포팅)
CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'another_password';
GRANT SELECT ON myapp.* TO 'readonly_user'@'%';

# 백업용 사용자
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'backup_password';
GRANT SELECT, LOCK TABLES, SHOW VIEW, RELOAD, REPLICATION CLIENT ON *.* TO 'backup_user'@'localhost';

# 모니터링용 사용자
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'exporter_password';
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

FLUSH PRIVILEGES;

절대로 root 계정을 애플리케이션에서 사용하지 마! ❌

[mysqld]
# Group Replication 설정
plugin-load-add=group_replication.so
group_replication_group_name="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
group_replication_start_on_boot=off
group_replication_local_address="mysql-0.mysql-headless:33061"
group_replication_group_seeds="mysql-0.mysql-headless:33061,mysql-1.mysql-headless:33061,mysql-2.mysql-headless:33061"
group_replication_bootstrap_group=off
group_replication_single_primary_mode=OFF  # Multi-Primary 모드
group_replication_enforce_update_everywhere_checks=ON

이렇게 하면 모든 노드가 쓰기를 받을 수 있어. 하지만 충돌 해결이 복잡해지니까 신중하게 사용해야 해! ⚖️

시나리오: 서울 클러스터(Primary)와 도쿄 클러스터(DR)

# 서울 클러스터의 Master를 외부로 노출
apiVersion: v1
kind: Service
metadata:
  name: mysql-external
  namespace: database
spec:
  type: LoadBalancer
  selector:
    app: mysql
    statefulset.kubernetes.io/pod-name: mysql-0
  ports:
  - port: 3306
    targetPort: 3306

# 도쿄 클러스터에서 서울 Master로 복제 설정
CHANGE MASTER TO
  MASTER_HOST='seoul-mysql-lb.example.com',
  MASTER_USER='replicator',
  MASTER_PASSWORD='password',
  MASTER_AUTO_POSITION=1;
START SLAVE;

이렇게 하면 재해 복구(DR) 환경을 구축할 수 있어. 서울 데이터센터가 통째로 날아가도 도쿄에서 서비스를 계속할 수 있지! 🌏

인기 있는 MySQL Operator들:

• Oracle MySQL Operator: 공식 Operator, InnoDB Cluster 지원
• Percona XtraDB Cluster Operator: Percona의 MySQL 클러스터
• Vitess Operator: 대규모 환경에 최적화

Operator를 사용하면:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mycluster
spec:
  secretName: mysql-secret
  instances: 3
  router:
    instances: 2
  version: "8.0.32"
  storage:
    size: 100Gi
    storageClassName: fast-ssd

이렇게 간단한 YAML로 전체 클러스터를 관리할 수 있어. 자동 페일오버, 백업, 업그레이드까지 모두 자동화되지! ✨

수평 샤딩 전략:

사용자 ID 기반으로 3개 샤드로 분할:

# Shard 0: user_id % 3 == 0
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-shard-0
spec:
  replicas: 3
  ...

# Shard 1: user_id % 3 == 1
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-shard-1
spec:
  replicas: 3
  ...

# Shard 2: user_id % 3 == 2
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-shard-2
spec:
  replicas: 3
  ...

애플리케이션에서 샤드 선택:

def get_shard(user_id):
    shard_num = user_id % 3
    return f"mysql-shard-{shard_num}.database.svc.cluster.local"

# 사용
db = connect(get_shard(user_id))
db.query("SELECT * FROM users WHERE id = ?", user_id)

이렇게 하면 데이터를 여러 클러스터에 분산시켜서 무한히 확장할 수 있어! ♾️

요구사항:

• 주문 데이터 (높은 쓰기 부하)
• 상품 카탈로그 (높은 읽기 부하)
• 99.9% 가용성
• 피크 시간 대응

아키텍처:

# 주문 DB (쓰기 집중)
- Master: 1대 (고성능 인스턴스)
- Replica: 2대 (읽기 부하 분산)
- 리소스: 8 CPU, 16GB RAM
- 스토리지: 500GB SSD (io2, 10000 IOPS)

# 상품 DB (읽기 집중)
- Master: 1대
- Replica: 5대 (읽기 부하 분산)
- 리소스: 4 CPU, 8GB RAM
- 스토리지: 200GB SSD (gp3)

# 캐싱 레이어
- Redis Cluster (상품 정보 캐싱)
- 캐시 히트율: 95%

결과:
• 평균 응답 시간: 50ms → 15ms
• 피크 시간 처리량: 10,000 TPS
• 연간 다운타임: 8시간 → 30분
• 인프라 비용: 30% 절감 (오토스케일링)

요구사항:

• 사용자 프로필 (10억+ 레코드)
• 타임라인 피드 (실시간 업데이트)
• 글로벌 서비스 (지역별 레이턴시 최소화)
• 무중단 배포

아키텍처:

# 지역별 클러스터
- 서울: 1 Master + 3 Replicas
- 도쿄: 1 Master + 3 Replicas
- 싱가포르: 1 Master + 3 Replicas

# 샤딩 전략
- 사용자 ID 기반 16개 샤드
- 각 샤드: 1 Master + 2 Replicas

# 데이터 분리
- 핫 데이터: MySQL (최근 30일)
- 콜드 데이터: S3 + Athena (30일 이상)

# 캐싱
- Redis: 사용자 세션, 프로필
- Memcached: 타임라인 피드

결과:
• 글로벌 평균 레이턴시: 100ms
• 일일 활성 사용자: 5천만명
• 데이터베이스 노드: 192개
• 총 데이터: 500TB

요구사항:

• 트랜잭션 무결성 (ACID 보장)
• 감사 로그 (모든 변경 추적)
• 규제 준수 (데이터 보존 7년)
• 제로 데이터 손실

아키텍처:

# 고가용성 설정
- Primary: 1대 (동기 복제)
- Standby: 1대 (동기 복제, 자동 페일오버)
- Replica: 2대 (비동기 복제, 읽기 전용)

# 백업 전략
- 전체 백업: 매일 새벽 2시
- 증분 백업: 매시간
- 바이너리 로그: 실시간 아카이빙
- 보관 기간: 7년 (S3 Glacier)

# 보안
- TLS 1.3 강제
- 데이터 암호화 (AES-256)
- 접근 제어: RBAC + MFA
- 감사 로그: 모든 쿼리 기록

# 재해 복구
- RTO: 5분
- RPO: 0 (동기 복제)
- DR 사이트: 다른 리전

결과:
• 연간 가용성: 99.99%
• 데이터 손실: 0건
• 평균 페일오버 시간: 30초
• 규제 감사: 통과

📝 핵심 요약

1. StatefulSet의 특별함
• 안정적인 네트워크 식별자
• 순서가 보장되는 배포/스케일링
• 영구 볼륨 자동 관리
• 상태 유지 애플리케이션에 최적화

2. 실전 구축 단계
• ConfigMap으로 설정 관리
• Secret으로 비밀번호 보호
• Headless Service로 DNS 제공
• volumeClaimTemplates로 스토리지 자동 프로비저닝

3. 운영 관리
• 모니터링 (Prometheus + Grafana)
• 자동 백업 (CronJob)
• 장애 대응 (자동 복구 + 수동 페일오버)
• 성능 최적화 (튜닝 + 리소스 관리)

4. 보안
• NetworkPolicy로 접근 제한
• TLS/SSL 암호화
• 최소 권한 원칙
• 정기적인 보안 패치

5. 고급 주제
• Multi-Master 구성
• 지역 간 복제
• Operator 패턴
• 샤딩