Kubernetes·고가용성 환경 업그레이드

이 가이드는 Kubernetes와 Mattermost Operator로 관리되는 Mattermost 배포를 업그레이드하기 위한 견고하고 종합적인 전략을 제공합니다. 고가용성(HA) 구성과 선택적인 Active/Active 장애 조치 구성도 함께 다룹니다. 무중단을 보장하고 서비스 위험을 최소화하며 신뢰할 수 있는 폴백 수단을 갖추기 위한 모범 사례를 설명합니다.

아키텍처 개요

Kubernetes 기반 배포

Mattermost는 컨테이너 오케스트레이션에 Kubernetes를 사용하며, Helm 차트와 Mattermost Operator를 통해 배포하고 관리합니다. 이 모델을 통해 확장성과 고가용성을 갖추고 자동으로 관리되는 애플리케이션 수명 주기를 구현할 수 있습니다.

Mattermost Operator는 업그레이드 절차를 자동으로 처리하여, 파드가 점진적으로 갱신되고 업그레이드 내내 트래픽이 올바르게 라우팅되도록 합니다. 업그레이드 중 오류가 발생하면 Operator는 어떤 변경도 적용하지 않으므로, 운영 환경에 영향을 주지 않고 문제를 조사·해결하거나 수동으로 롤백할 수 있습니다. 롤백에 대한 자세한 내용은 Mattermost 서버 다운그레이드 문서를 참고하세요.

상태 모니터링을 통해 정상 상태의 파드만 교체되며, 새 파드는 상태 점검을 통과한 뒤에야 온라인 상태가 됩니다. 새 파드는 갱신된 버전으로 배포되고 기존 파드는 정상적으로 종료됩니다.

고가용성

고가용성(HA) 클러스터 기반 배포에서는 Mattermost가 클러스터 내에서 여러 애플리케이션 서버를 실행합니다. 이 구성 덕분에 서버 하나에 장애가 발생하더라도 나머지 서버가 중단 없이 요청을 계속 처리할 수 있습니다. 사용자 트래픽 부하 분산은 NGINX Ingress나 HAProxy 같은 서비스로 관리합니다. PostgreSQL과 파일 스토리지는 이중화와 장애 조치를 위해 복제 구성으로 배포합니다.

Active/Active 배포

Active/Active 구성은 선택 사항으로, 지리적으로 분산된 여러 리전이나 가용 영역에서 두 개 이상의 Mattermost 클러스터를 동시에 실행하는 형태입니다. 각 클러스터는 데이터베이스와 파일 스토리지 같은 공유 백엔드 구성 요소와 동기화를 유지하면서, 독립적으로 실시간 사용자 트래픽을 처리하고 요청을 수행할 수 있습니다.

엔터프라이즈 고객이 얻는 주요 이점은 다음과 같습니다.

• 복원력과 가동률: 유지 보수나 장애로 한 사이트를 사용할 수 없게 되더라도 다른 사이트가 최소한의 영향만으로 사용자에게 서비스를 계속 제공할 수 있습니다.
• 지리적 분산: 사용자는 가장 가까운 클러스터에 연결하므로 지연 시간이 줄고 응답이 빨라집니다.
• 부하 분산: 클러스터 간에 워크로드를 분산해 성능과 시스템 확장성을 높일 수 있습니다.

이러한 배포에서는 데이터 일관성, 업그레이드 안전성, 매끄러운 트래픽 장애 조치를 보장하기 위해 세심한 설정 관리와 조율이 필요합니다. 각 클러스터는 설정과 데이터의 일관성을 유지해야 하며, 업그레이드도 서로 조율해서 진행해야 합니다. 권장 사항은 Active/Active 업그레이드 고려 사항 절을 참고하세요.

1단계: 준비

이 단계에서는 환경이 정상 상태이고 백업되어 있으며 업그레이드할 준비가 되었는지 확인합니다. 서비스 중단을 피하고 롤백 준비를 갖출 수 있도록 각 단계를 꼼꼼히 따르세요.

업그레이드 전 체크리스트

1. 클러스터 상태: 모든 노드가 준비(ready) 상태이고 모든 파드가 오류 없이 실행 중인지 확인합니다. 업그레이드 과정에서 문제가 발생하지 않도록 하려면 반드시 필요한 단계입니다. 다음 명령으로 클러스터 상태를 확인하세요.

   kubectl get nodes
   kubectl get pods --all-namespaces

2. Helm 설정: Kubernetes 클러스터에 Helm이 올바르게 설치·설정되어 있는지 확인합니다. Mattermost Operator Helm 차트가 최신 버전인지도 확인하세요. 다음 명령으로 Helm 설정을 점검할 수 있습니다.

   helm repo update
   helm upgrade mattermost-operator mattermost/mattermost-operator -n <OPERATOR_NAMESPACE_HERE> -f <OPTIONAL_CUSTOM_VALUES_HERE>

3. Mattermost Operator 버전 확인: 이미지 버전이 Helm 저장소의 최신 지원 릴리스와 일치하는지 확인합니다. 다음 명령으로 Mattermost Operator의 현재 이미지 버전을 확인할 수 있습니다.

   kubectl get deployment mattermost-operator -n mattermost -o=jsonpath='{.spec.template.spec.containers[0].image}'

4. 가용 리소스 확인: Kubernetes 클러스터에 업그레이드 과정을 감당할 만한 CPU와 메모리 리소스가 충분한지 확인합니다. 다음 명령으로 리소스 가용량을 확인하세요.

   kubectl top nodes
   kubectl describe node | grep Allocatable

5. 데이터베이스와 파일 스토리지를 백업합니다.

   pg_dump나 볼륨 스냅숏을 사용해 안전한 외부 위치(예: S3 또는 NFS)에 전체 백업을 생성하세요. 백업이 복원 가능한지도 검증하세요. 자세한 내용은 백업 및 재해 복구 문서를 참고하세요.

6. 설정 일관성 확보: values.yaml, 시크릿, 그 밖의 설정 파일이 버전 관리되고 있으며 모든 클러스터에서 일관된지 검증합니다(Active/Active 배포에서는 필수입니다). GitOps나 설정 관리 시스템 같은 도구를 사용해 모든 클러스터가 동일한 설정을 갖도록 하세요.

7. 운영 환경을 그대로 반영한 스테이징 환경에서 업그레이드를 시험해 잘못된 설정을 미리 찾아낼 것을 강력히 권장합니다.

2단계: 업그레이드 수행

이 단계에서는 Mattermost Operator와 Mattermost 서버를 새 버전으로 갱신합니다. Operator가 업그레이드 절차를 관리하여, 파드가 점진적으로 갱신되고 업그레이드 내내 트래픽이 올바르게 라우팅되도록 합니다.

별도의 Mattermost 커스텀 리소스를 두는 것을 권장합니다. 자세한 내용은 Kubernetes에 Mattermost 배포 문서를 참고하세요.

1. 별도의 리소스에서 mattermost-installation.yaml 파일의 version 필드를 업그레이드하려는 버전으로 바꿉니다. <new-version-tag>를 해당 버전으로 교체하세요.

   apiVersion: installation.mattermost.com/v1beta1
   kind: Mattermost
   metadata:
     name: <INSTALLATION_NAME_HERE>
   spec:
     version: <new-version-tag>  # Update this field

   또는 Helm values.yaml을 직접 사용하고 있다면 원하는 Mattermost 버전으로 갱신합니다.

   image:
     repository: mattermost/mattermost-enterprise-edition
     tag: <new-version-tag>

2. 갱신한 설정을 적용합니다.

   Mattermost 커스텀 리소스 배포의 경우:

   kubectl apply -f mattermost-installation.yaml

   Helm values 배포의 경우:

   helm upgrade mattermost mattermost/mattermost-operator -f values.yaml

3. 다음 명령으로 업그레이드 진행 상황과 로그를 추적해 롤아웃을 모니터링합니다.

   kubectl get pods -n mattermost
   kubectl logs -f <pod-name> -n mattermost

새 파드는 갱신된 버전으로 시작됩니다. 기존 파드는 상태 점검을 통과한 뒤 정상적으로 종료되며, 롤링 업그레이드 방식 덕분에 트래픽은 중단되지 않습니다. NGINX, HAProxy, Ingress 설정은 업그레이드 과정 내내 트래픽을 매끄럽게 라우팅합니다.

3단계: Active/Active 업그레이드 고려 사항

배포에 다중 클러스터 또는 다중 리전 형태의 Active/Active 구성이 포함되어 있다면, 데이터 일관성과 서비스 가용성을 유지할 수 있도록 모든 클러스터를 조율된 방식으로 업그레이드해야 합니다.

사이트 업그레이드를 조율하기 위해 다음 절차를 권장합니다.

• 글로벌 로드 밸런서나 DNS를 사용해 업그레이드 중인 사이트에서 트래픽을 우회시킵니다.
• 한 번에 한 사이트씩 업그레이드하고 트래픽은 다른 사이트로 보냅니다. 이렇게 하면 중단 시간을 최소화하고 업그레이드 절차를 검증할 수 있습니다.
• 다음 사이트로 넘어가기 전에 데이터베이스와 스토리지의 복제 상태를 확인합니다.
• 업그레이드한 사이트로 트래픽을 되돌리기 전에 성능과 로그를 모니터링합니다.

업그레이드 중 스플릿 브레인 상황을 방지하고 데이터 일관성을 보장하려면 다음을 수행하세요.

• 글로벌 로드 밸런서나 DNS를 사용해 활성 사이트로만 트래픽을 보냅니다.
• 업그레이드가 완료되고 검증될 때까지 업그레이드 중인 사이트의 쓰기를 비활성화합니다.
• 어느 시점에도 한 사이트에서만 데이터를 쓰고 있는지 확인합니다.
• 복제 지연, 파일 동기화 문제, 데이터 불일치 징후가 있는지 로그를 모니터링합니다.
• 각 사이트를 업그레이드하기 전과 후에 데이터 복제 채널의 상태를 검증합니다.

4단계: 검증

업그레이드 후:

1. 다음 명령으로 모든 파드가 정상 상태이며 예상한 버전으로 실행 중인지 확인합니다.

   kubectl get pods -n mattermost -o=jsonpath='{.items[*].spec.containers[*].image}'

3. 제품 스모크 테스트를 수행합니다.

   • Mattermost 웹 인터페이스에 로그인해 팀과 채널을 오가며 확인합니다.
   • 메시지 게시, 파일 업로드 같은 핵심 기능을 테스트합니다.
   • 모든 연동, 웹훅, 플러그인이 정상 동작하는지 확인합니다.
   • 로그에 오류 메시지가 있는지 확인합니다.

4. 모니터링 도구를 사용해 애플리케이션 상태와 성능을 확인합니다. 성능 지표를 수집하고 검토하는 방법은 Prometheus 및 Grafana를 활용한 성능 모니터링 문서나 메트릭 플러그인 문서를 참고하세요.

롤백 전략

업그레이드에 문제가 발생한 경우, 커스텀 리소스를 수정해 Mattermost 버전을 원래 값으로 되돌리는 방식으로 롤백해야 합니다.

Mattermost 커스텀 리소스 배포의 경우, mattermost-installation.yaml 파일의 version 필드를 이전 버전으로 갱신합니다.

apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
metadata:
  name: <INSTALLATION_NAME_HERE>
spec:
  version: <previous-version-tag>  # Set back to previous version

그런 다음 롤백을 적용합니다.

kubectl apply -f mattermost-installation.yaml

또는 Helm values 배포라면 Helm의 롤백 명령을 사용합니다.

helm rollback mattermost <revision_number>

필요하다면 PostgreSQL 데이터베이스와 파일 저장소 백업을 복원하세요. 자세한 안내는 백업 및 재해 복구 문서를 참고하세요.

자주 묻는 질문

업그레이드가 성공했는지 어떻게 확인하나요?

다음과 같은 상태라면 업그레이드가 성공한 것입니다.

• 모든 파드가 예상한 이미지 버전으로 실행 중
• 파드 로그에 오류 없음
• 기능 스모크 테스트 통과(로그인, 메시지 전송, 파일 업로드 등)
• 모니터링 대시보드에 이상 징후 없음

업그레이드 후 무엇을 모니터링해야 하나요?

업그레이드 후에는 다음 핵심 지표를 모니터링할 것을 권장합니다.

• 파드 상태와 재시작 횟수
• 애플리케이션 로그의 오류와 경고
• 데이터베이스 복제 상태(HA 또는 Active/Active인 경우)
• Prometheus/Grafana를 통한 성능 지표(지연 시간, 오류율)

운영 환경에 영향을 주지 않고 업그레이드를 테스트하려면 어떻게 하나요?

운영 환경을 그대로 반영한 별도의 스테이징 환경을 구축하고, 실제 운영 클러스터를 업그레이드하기 전에 종단 간 업그레이드 시뮬레이션을 완전히 수행할 것을 강력히 권장합니다.

Operator와 Mattermost 서버를 동시에 업그레이드할 수 있나요?

Operator를 먼저 업그레이드하세요. Operator가 안정적으로 동작하는지 검증한 뒤 Mattermost 서버 버전을 업그레이드합니다.

데이터베이스는 별도로 업그레이드해야 하나요?

Mattermost는 기본적으로 데이터베이스 스키마를 업그레이드하지 않습니다. 새 Mattermost 버전에서 필요로 하는 경우 데이터베이스 스키마 갱신을 직접 적용해야 합니다. 마이그레이션 단계가 있는지 Mattermost 서버 변경 로그를 검토하세요.

업그레이드 후 파드가 준비 상태가 되지 않으면 어떻게 하나요?

kubectl로 Operator 로그와 파드 이벤트를 확인해 문제를 파악하고 해결하세요. 리소스 부족, 설정 오류, 네트워크 연결 문제 같은 흔한 원인을 살펴보세요.

Mattermost Operator와 애플리케이션 서버 간 버전 호환성에서 무엇을 유의해야 하나요?

오래된 Operator 버전은 새로운 Mattermost 기능이나 업그레이드 흐름을 지원하지 않을 수 있습니다. Operator와 Mattermost 서버 간 버전 호환성은 항상 Helm 차트 릴리스 노트에서 확인하세요.

GitOps나 CI/CD로 이 업그레이드 절차를 자동화할 수 있나요?

가능합니다. ArgoCD나 FluxCD 같은 도구로 버전 관리되는 values.yaml 파일의 Helm 변경 사항을 적용해 업그레이드를 관리할 수 있습니다. 변경 사항은 반드시 동료 검토를 거치고 스테이징에서 검증한 뒤 반영하세요.