사용 가능 플랜: Enterprise, Enterprise Advanced

고가용성 클러스터 기반 배포를 통해 Mattermost 시스템은 중복 인프라를 활용하여 장애 및 하드웨어 오류 중에도 서비스를 유지할 수 있습니다.

Mattermost의 고가용성은 중복 Mattermost 애플리케이션 서버, 중복 데이터베이스 서버, 중복 로드 밸런서를 실행하는 것으로 구성됩니다. 이 구성 요소 중 하나가 실패해도 시스템 운영이 중단되지 않습니다.

Mattermost Enterprise는 다음을 지원합니다.

1. 클러스터화된 Mattermost 서버: 다음을 통해 지연 시간을 최소화합니다.

• 글로벌 CDN을 통한 정적 에셋 저장.
• 최종 사용자 위치에 더 가까운 곳에서 API 통신을 호스팅하기 위한 여러 Mattermost 서버 배포.

또한 재해 복구 시나리오에서 규모 확장 및 장애 전환 처리에도 사용할 수 있습니다.

2. 데이터베이스 읽기 복제본: 복제본은 다음과 같이 사용할 수 있습니다.

• 활성 데이터베이스 서버에 대한 중복 백업으로 구성.
• 동시 사용자 수를 늘리는 데 사용.
• 최종 사용자 위치에 더 가깝게 배포하여 지연 시간 단축.

또한 검색 쿼리를 처리하기 위한 검색 복제본도 지원됩니다.

준비 사항#

• 해당 사용자 수에 맞게 Mattermost 규모를 조정하는 방법에 대한 지침은 사용 가능한 참조 아키텍처를 검토하세요. 참조 아키텍처 지침에는 예상 사용 패턴에 따른 Mattermost 노드, 데이터베이스 writer 및 reader 노드, Elasticsearch 노드, 프록시 노드 수에 대한 권장 사항과 파일 스토리지 예상치가 포함됩니다.
• Mattermost의 파일 스토리지 구성을 Amazon S3, S3 호환 파일 스토리지 서비스, 또는 각 Mattermost 노드에 마운트된 네트워크 연결 스토리지(NAS) 중 무엇으로 할지 결정하세요. Mattermost 노드가 NAS 위치가 아닌 각 노드의 호스트 파일 시스템에 로컬 파일 시스템 스토리지로 구성된 상태로 남아 있으면 고가용성이 올바르게 작동하지 않고 파일 스토리지가 손상될 수 있습니다.
• 쿠버네티스 배포의 경우 쿠버네티스에 Mattermost 배포를 검토하세요.
• 쿠버네티스를 사용하지 않는 배포의 경우 Mattermost용으로 프로비저닝된 서버 한 대에 원하는 버전의 Mattermost를 설치하거나 업그레이드하세요. 설치에 대한 자세한 내용은 Linux에 Mattermost 배포를 참조하세요. 설치된 노드에 Enterprise 또는 Enterprise Advanced 라이선스 키를 적용하려면 라이선스 키 설치를 진행하세요.
• 권장: Mattermost 구성에 config.json을 사용하는 경우, Mattermost 인스턴스를 데이터베이스 기반 구성으로 마이그레이션하려면 데이터베이스에 구성 저장을 참조하세요. config.json 파일을 계속 사용하는 것도 가능합니다. 그러나 고가용성이 활성화되면 Mattermost 서버의 모든 config.json 파일이 항상 동일하도록 보장하기 위해 시스템 콘솔이 읽기 전용 모드로 설정됩니다.
• 적절한 규모의 Calls 배포 계획을 수립하려면 Calls 셀프 호스팅 배포를 검토하세요.
• Mattermost 서버의 게시물이 250만 건을 초과할 것으로 예상되는 경우, 최적의 검색 성능을 보장하기 위한 옵션은 Enterprise 검색을 검토하세요.
• 사용자 수가 100,000명을 초과하는 Mattermost 배포의 경우 Redis 배포 가이드를 검토하세요.

배포 가이드#

Mattermost 서버에서 고가용성 클러스터 기반 배포를 설정하고 유지 관리하세요.

Mattermost 서버#

1. 권장: 클러스터의 모든 서버에서 구성 관리를 단순화하려면 config.json 대신 데이터베이스에 구성 저장을 사용하세요.

2. 추가 Mattermost 서버 설정: 현재 배포와 동일한 구성을 사용하여 추가 Mattermost 서버를 프로비저닝하세요.

   • 쿠버네티스 배포: mattermost-installation.yaml 파일의 spec 섹션에 있는 replicas 필드를 원하는 서버 수로 업데이트한 다음(예: 서버 2대 클러스터의 경우 replicas: 2), kubectl apply -f mattermost-installation.yaml로 업데이트된 매니페스트를 적용하세요.

   • 쿠버네티스를 사용하지 않는 배포: Linux에 Mattermost 배포 안내에 따라 각 추가 서버에 동일한 버전의 Mattermost를 설치하세요.

   구성을 데이터베이스에 저장하는 경우 각 서버의 MM_CONFIG 환경 변수가 동일한 데이터베이스 연결 문자열을 가리키는지 확인하세요. config.json 파일을 사용하는 경우 각 서버가 동일한 사본을 갖는지 확인하세요.

3. 시스템 제한 구성: 각 Mattermost 서버에서 프로세스 제한을 8192로, 최대 열린 파일 수를 65536으로 설정하세요.

   리소스 제한을 설정하려면 systemd 서비스 파일을 수정하세요.

   sudo sed -i '/\[Service\]/a LimitNOFILE=65536\nLimitNPROC=8192' /etc/systemd/system/mattermost.service
   

   직접 수정하려면 /etc/systemd/system/mattermost.service의 [Service] 섹션에 다음 줄을 추가하세요.

   [Service]
   LimitNOFILE=65536
   LimitNPROC=8192
   

   systemd를 다시 불러오고 서비스를 재시작하여 제한을 적용하세요.

   sudo systemctl daemon-reload
   sudo systemctl restart mattermost
   

   제한이 적용되었는지 확인하세요.

   # Check the actual process limits
   cat /proc/$(pgrep -f mattermost | head -1)/limits | grep -E "Max open files|Max processes"
   

   Max open files가 65536으로 설정된 것을 확인할 수 있습니다.

4. 네트워크 설정 최적화: 각 Mattermost 서버에서 커널 매개변수를 구성하여 WebSocket 연결 제한을 늘리고 TCP 설정을 최적화하세요.

   Mattermost용 sysctl 구성 파일을 생성하세요.

   sudo tee /etc/sysctl.d/mattermost.conf > /dev/null <<EOF
   # Extending default port range to handle lots of concurrent connections.
   net.ipv4.ip_local_port_range = 1025 65000
   
   # Lowering the timeout to faster recycle connections in the FIN-WAIT-2 state.
   net.ipv4.tcp_fin_timeout = 30
   
   # Reuse TIME-WAIT sockets for new outgoing connections.
   net.ipv4.tcp_tw_reuse = 1
   
   # Bumping the limit of a listen() backlog.
   # This is maximum number of established sockets (with an ACK)
   # waiting to be accepted by the listening process.
   net.core.somaxconn = 4096
   
   # Increasing the maximum number of connection requests which have
   # not received an acknowledgment from the client.
   # This is helpful to handle sudden bursts of new incoming connections.
   net.ipv4.tcp_max_syn_backlog = 8192
   
   # This is tuned to be 2% of the available memory.
   vm.min_free_kbytes = 167772
   
   # Disabling slow start helps increasing overall throughput
   # and performance of persistent single connections.
   net.ipv4.tcp_slow_start_after_idle = 0
   
   # These show a good performance improvement over defaults.
   # More info at https://blog.cloudflare.com/http-2-prioritization-with-nginx/
   net.ipv4.tcp_congestion_control = bbr
   net.core.default_qdisc = fq
   net.ipv4.tcp_notsent_lowat = 16384
   
   # TCP buffer sizes are tuned for 10Gbit/s bandwidth and 0.5ms RTT (as measured intra EC2 cluster).
   # This gives a BDP (bandwidth-delay-product) of 625000 bytes.
   # The maximum socket buffer size for kernel autotuning is set to be 4x the BDP (2500000).
   # The default socket buffer size is set to 1/4 BDP (156250).
   net.ipv4.tcp_rmem = 4096 156250 2500000
   net.ipv4.tcp_wmem = 4096 156250 2500000
   
   # Bumping the theoretical maximum buffer size of receiving/sending sockets,
   # either UDP, or TCP not using autotuning (i.e. using SO_RCVBUF)
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   EOF
   

   즉시 설정을 적용하세요.

   sudo sysctl -p /etc/sysctl.d/mattermost.conf
   

5. 시간 동기화 활성화: 메시지가 올바른 순서로 게시되고 클러스터 통신이 제대로 작동하도록 클러스터의 각 서버는 시간이 동기화되어 있어야 합니다.

   Ubuntu/Debian:

   최신 Ubuntu 시스템은 기본적으로 systemd-timesyncd를 사용하며, 일반적으로 이미 활성화되어 있습니다. 시간 동기화가 작동하는지 확인하세요.

   timedatectl status
   

   System clock synchronized: yes가 표시되어야 합니다. 시간 동기화가 활성화되어 있지 않으면 다음 명령어로 활성화하세요.

   sudo timedatectl set-ntp true
   

   RHEL/CentOS/Rocky Linux:

   sudo dnf install chrony
   sudo systemctl enable chronyd
   sudo systemctl start chronyd
   

   시간 동기화가 작동하는지 확인하세요.

   chronyc sources
   

6. 개별 서버 기능 확인: 클러스터링을 활성화하기 전에 각 서버의 프라이빗 IP 주소에 직접 접근하여 서버가 독립적으로 작동하는지 확인하세요.

   각 Mattermost 서버의 프라이빗 IP 주소를 확인하세요.

   # Get all IP addresses for the server
   hostname -I
   
   # Or get the primary network interface IP
   ip addr show | grep "inet " | grep -v 127.0.0.1 | awk '{print $2}' | cut -d/ -f1
   

   프라이빗 IP 주소를 사용하여 각 서버에서 Mattermost에 접근할 수 있는지 테스트하세요.

   # Replace with your server's actual IP address
   curl http://192.168.1.10:8065
   

   Mattermost 애플리케이션의 HTML 출력이 표시되어야 합니다. 클러스터의 각 Mattermost 서버에 대해 이 확인 절차를 반복하세요.

7. 클러스터 설정 구성: ClusterSettings 섹션을 구성하여 고가용성을 활성화하세요. 클러스터 설정을 지정하려면 mmctl을 사용하세요.

   mmctl config set ClusterSettings.Enable true
   mmctl config set ClusterSettings.ClusterName production
   mmctl config set ClusterSettings.UseIPAddress true
   mmctl config set ClusterSettings.GossipPort 8074
   

   구성을 데이터베이스가 아닌 config.json에 저장하는 경우, System Console 변경 사항이 한 노드의 config.json에만 기록되어 다른 노드와 달라지는 것을 방지하기 위해 ClusterSettings.ReadOnlyConfig도 true로 설정하세요.

   mmctl config set ClusterSettings.ReadOnlyConfig true
   

   구성을 데이터베이스에 저장하는 경우(데이터베이스에 구성 저장 참조), 모든 노드가 공유 데이터베이스에서 동일한 구성을 읽으므로 ClusterSettings.ReadOnlyConfig는 무시됩니다.

   비표준 네트워크 구성을 위한 OverrideHostname을 포함하여 사용 가능한 모든 클러스터 설정에 대한 자세한 내용은 고가용성 구성 설정 문서를 참조하세요.

8. Mattermost 서버 재시작: 새 구성을 적용하려면 클러스터의 각 Mattermost 서버를 재시작하세요.

   sudo systemctl restart mattermost
   

9. 클러스터 통신 확인: System Console > Environment > High Availability를 열어 클러스터의 각 서버가 녹색 상태 표시기로 예상대로 통신하고 있는지 확인하세요. 그렇지 않으면 로그 파일에서 추가 정보를 확인하세요.

프록시 서버#

프록시 서버는 Mattermost 서버 클러스터를 외부 클라이언트에 노출합니다. 프록시는 클러스터의 모든 Mattermost 서버에 트래픽을 분산하고, 정상 상태인 서버로만 트래픽을 라우팅하도록 상태 확인을 제공합니다.

Mattermost는 다양한 로드 밸런싱 솔루션과 함께 작동하도록 설계되었습니다.

• 소프트웨어 프록시: NGINX
• 클라우드 로드 밸런서: Amazon Elastic Load Balancer(ELB/ALB), Azure Load Balancer, Google Cloud Load Balancing
• 하드웨어 로드 밸런서: F5 BIG-IP, Citrix NetScaler ADC 및 기타 엔터프라이즈 솔루션

이 섹션에서는 가장 일반적으로 사용되는 솔루션인 NGINX에 대한 구성 지침을 제공합니다. 클라우드 로드 밸런서 또는 하드웨어 로드 밸런서를 사용하는 경우, /api/v4/system/ping 엔드포인트에서 상태 확인을 구성하고 여러 백엔드 서버 간에 로드 밸런싱을 설정하는 방법은 해당 공급업체의 문서를 참조하세요.

1. NGINX 설치: 프록시 서버에 NGINX를 설치하세요.

   Ubuntu/Debian:

   sudo apt update
   sudo apt install nginx
   

   RHEL/CentOS:

   sudo dnf install nginx
   

2. 고가용성 백엔드 구성: 고가용성 배포에 최적화된 고성능 설정으로 클러스터의 모든 Mattermost 서버를 정의하는 NGINX 구성을 생성하세요.

   환경에 맞게 구성 변수를 설정하세요.

   # Ubuntu/Debian: Use sites-available directory
   NGINX_CONF="/etc/nginx/sites-available/mattermost"
   
   # RHEL/CentOS: Use conf.d directory instead
   # NGINX_CONF="/etc/nginx/conf.d/mattermost.conf"
   
   # Set your Mattermost server IP addresses
   MM_SERVER_1="192.168.1.10"
   MM_SERVER_2="192.168.1.11"
   
   # Set your domain name
   MM_DOMAIN="mattermost.example.com"
   

   고성능 설정으로 NGINX 구성 파일을 생성하세요.

   sudo tee "$NGINX_CONF" > /dev/null <<EOF
   upstream backend {
         server ${MM_SERVER_1}:8065 max_fails=0;
         server ${MM_SERVER_2}:8065 max_fails=0;
         keepalive 256;
   }
   
   proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;
   
   server {
     listen 80 reuseport;
     server_name ${MM_DOMAIN};
   
     location ~ /api/v[0-9]+/(users/)?websocket$ {
           proxy_set_header Upgrade \$http_upgrade;
           proxy_set_header Connection "upgrade";
           client_max_body_size 50M;
           proxy_set_header Host \$http_host;
           proxy_set_header X-Real-IP \$remote_addr;
           proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto \$scheme;
           proxy_set_header X-Frame-Options SAMEORIGIN;
           proxy_buffers 256 16k;
           proxy_buffer_size 16k;
           client_body_timeout 60s;
           send_timeout        300s;
           lingering_timeout   5s;
           proxy_connect_timeout   90s;
           proxy_send_timeout      300s;
           proxy_read_timeout      90s;
           proxy_http_version 1.1;
           proxy_pass http://backend;
     }
   
     location ~ /api/v[0-9]+/users/[a-z0-9]+/image\$ {
           proxy_set_header Connection "";
           client_max_body_size 50M;
           proxy_set_header Host \$http_host;
           proxy_set_header X-Real-IP \$remote_addr;
           proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto \$scheme;
           proxy_set_header X-Frame-Options SAMEORIGIN;
           proxy_buffers 256 16k;
           proxy_buffer_size 16k;
           proxy_read_timeout 600s;
           proxy_http_version 1.1;
           proxy_pass http://backend;
           proxy_cache mattermost_cache;
           proxy_cache_revalidate on;
           proxy_cache_min_uses 2;
           proxy_cache_use_stale timeout;
           proxy_cache_lock on;
           proxy_ignore_headers Cache-Control Expires;
           proxy_cache_valid 200 24h;
     }
   
     location / {
           proxy_set_header Connection "";
           client_max_body_size 50M;
           proxy_set_header Host \$http_host;
           proxy_set_header X-Real-IP \$remote_addr;
           proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto \$scheme;
           proxy_set_header X-Frame-Options SAMEORIGIN;
           proxy_buffers 256 16k;
           proxy_buffer_size 16k;
           proxy_read_timeout 600s;
           proxy_http_version 1.1;
           proxy_pass http://backend;
           proxy_cache mattermost_cache;
           proxy_cache_revalidate on;
           proxy_cache_min_uses 2;
           proxy_cache_use_stale timeout;
           proxy_cache_lock on;
     }
   }
   EOF
   

   이 구성에는 서버가 사용 불가능으로 표시되는 것을 방지(max_fails=0), 사용자 이미지를 24시간 동안 캐싱, 장시간 실행되는 작업에 대한 확장된 타임아웃 등의 고성능 최적화가 포함되어 있습니다. 워커 프로세스 최적화 및 고급 버퍼 설정을 포함한 추가 NGINX 성능 튜닝 옵션은 고성능 스케일링 구성 섹션을 참조하세요.

3. 사이트 구성 활성화:

   Ubuntu/Debian:

   sudo ln -sf /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost
   sudo rm -f /etc/nginx/sites-enabled/default
   

   RHEL/CentOS: /etc/nginx/conf.d/에 있는 구성 파일은 자동으로 활성화됩니다.

4. NGINX 구성 테스트 및 적용:

   sudo nginx -t
   sudo systemctl restart nginx
   sudo systemctl enable nginx
   

5. TLS 구성: 프로덕션 배포의 경우 NGINX 프록시에 TLS를 구성하세요. NGINX로 TLS를 구성하는 자세한 방법은 TLS 설정을 참조하세요. 자동 인증서 관리를 위해 Let's Encrypt를 사용하거나 자체 TLS 인증서를 제공할 수 있습니다.

6. 상태 확인 구성: 위의 upstream 블록은 max_fails=0을 설정하여 NGINX의 패시브 격리 기능을 비활성화합니다. 즉, 실패한 요청 수를 기준으로 백엔드가 사용 불가능으로 표시되지 않습니다. 개별 실패 요청은 NGINX의 기본 proxy_next_upstream 동작을 통해 다른 백엔드로 계속 재시도됩니다. 실패한 서버를 감지하여 로테이션에서 제외하려면, 로드 밸런서 또는 모니터링 시스템에서 활성 상태 확인을 사용하여 Mattermost API 엔드포인트 http://SERVER_IP:8065/api/v4/system/ping(정상 서버의 경우 Status 200을 반환)을 모니터링하세요.

7. 프록시 기능 확인: 구성한 도메인 이름을 사용하여 프록시를 통한 접근을 테스트하고, Mattermost 서버 로그를 확인하여 트래픽이 백엔드 서버 간에 분산되는지 확인하세요.

파일 스토리지#

고가용성 배포에서는 클러스터의 모든 Mattermost 서버가 동일한 파일 스토리지에 접근할 수 있어야 합니다. 각 개별 서버의 로컬 파일 시스템 스토리지는 HA에서 올바르게 작동하지 않으며 파일 스토리지가 손상될 수 있습니다.

고가용성에 지원되는 파일 스토리지 옵션:

• Amazon S3 또는 S3 호환 객체 스토리지 (권장)
• NFS 또는 유사 프로토콜을 사용하는 네트워크 연결 스토리지(NAS)

S3 또는 S3 호환 스토리지 구성#

Amazon S3 및 S3 호환 스토리지 솔루션(MinIO, Digital Ocean Spaces 등)은 고가용성 배포에 권장되는 파일 스토리지 옵션입니다.

1. 파일 스토리지 설정 구성: mmctl 또는 시스템 콘솔을 사용하여 S3 스토리지를 구성하세요:

   # Set storage driver to S3
   mmctl config set FileSettings.DriverName amazons3
   
   # Configure S3 bucket and region
   mmctl config set FileSettings.AmazonS3Bucket your-bucket-name
   mmctl config set FileSettings.AmazonS3Region us-east-1
   
   # Configure S3 credentials (if not using IAM roles)
   mmctl config set FileSettings.AmazonS3AccessKeyId your-access-key-id
   mmctl config set FileSettings.AmazonS3SecretAccessKey your-secret-access-key
   

   S3 호환 스토리지(MinIO 등)의 경우 엔드포인트도 구성하세요:

   mmctl config set FileSettings.AmazonS3Endpoint s3.your-domain.com
   

2. 구성 확인: Mattermost를 재시작하고 파일 업로드를 테스트하여 파일이 S3에 올바르게 저장되는지 확인하세요.

   사용 가능한 모든 S3 구성 옵션에 대한 자세한 내용은 파일 스토리지 구성 설정 문서를 참조하세요.

NFS 공유 스토리지 구성#

Amazon S3 또는 S3 호환 스토리지의 대안으로, NFS를 사용하는 네트워크 연결 스토리지(NAS)를 통해 모든 Mattermost 서버가 네트워크를 통해 동일한 파일 디렉터리에 접근할 수 있습니다.

1. 일관된 사용자 ID 확인: mattermost 사용자는 NFS 서버와 모든 Mattermost 서버에서 동일한 UID 및 GID를 가져야 합니다.

   Mattermost 서버에서 UID/GID를 확인하세요:

   id mattermost
   

   출력은 uid=500(mattermost) gid=500(mattermost) 와 같은 형태로 표시됩니다. 이 값을 기록해 두세요.

   NFS 서버에서 일치하는 UID/GID로 mattermost 사용자를 생성하세요(500 을 실제 값으로 대체):

   sudo useradd -r -U -u 500 -M -d /opt/mattermost -s /bin/bash mattermost
   

   사용자가 이미 다른 UID로 존재하는 경우:

   sudo usermod -u 500 mattermost
   sudo groupmod -g 500 mattermost
   

2. NFS 서버 설정: NFS 서버 패키지를 설치하고 공유 디렉터리를 구성하세요.

   Ubuntu/Debian:

   sudo apt update
   sudo apt install nfs-kernel-server
   

   RHEL/CentOS/Rocky Linux:

   sudo dnf install nfs-utils
   

   mattermost 소유권으로 공유 디렉터리를 생성하세요:

   sudo mkdir -p /mnt/mattermost-data
   sudo chown mattermost:mattermost /mnt/mattermost-data
   sudo chmod 755 /mnt/mattermost-data
   

   /etc/exports 에 항목을 추가하세요. NETWORK/CIDR 을 네트워크 범위(예: 192.168.1.0/24)로 대체하고 mattermost UID/GID 값을 사용하세요:

   /mnt/mattermost-data NETWORK/CIDR(rw,sync,anonuid=500,anongid=500)
   

   예시:

   # For subnet 192.168.1.0/24
   /mnt/mattermost-data 192.168.1.0/24(rw,sync,anonuid=500,anongid=500)
   
   # For specific servers only
   /mnt/mattermost-data 192.168.1.10(rw,sync,anonuid=500,anongid=500) 192.168.1.11(rw,sync,anonuid=500,anongid=500)
   

   NFS 서버를 활성화하고 시작하세요:

   Ubuntu/Debian:

   sudo systemctl enable --now nfs-kernel-server
   sudo exportfs -arv
   

   RHEL/CentOS/Rocky Linux:

   sudo systemctl enable --now nfs-server
   sudo exportfs -arv
   

   필요한 경우 방화벽을 구성하세요:

   Ubuntu/Debian:

   sudo ufw allow from NETWORK/CIDR to any port nfs
   

   RHEL/CentOS/Rocky Linux:

   sudo firewall-cmd --permanent --add-service=nfs
   sudo firewall-cmd --permanent --add-service=mountd
   sudo firewall-cmd --permanent --add-service=rpc-bind
   sudo firewall-cmd --reload
   

3. Mattermost 서버에 NFS 마운트: NFS 클라이언트 패키지를 설치하고 각 Mattermost 서버에 공유를 마운트하세요.

   Ubuntu/Debian:

   sudo apt update
   sudo apt install nfs-common
   sudo mkdir -p /opt/mattermost/data
   sudo mount -t nfs -o rw,hard NFS_SERVER_IP:/mnt/mattermost-data /opt/mattermost/data
   

   RHEL/CentOS/Rocky Linux:

   sudo dnf install nfs-utils
   sudo mkdir -p /opt/mattermost/data
   sudo mount -t nfs -o rw,hard NFS_SERVER_IP:/mnt/mattermost-data /opt/mattermost/data
   

   NFS_SERVER_IP 를 NFS 서버의 IP 주소로 대체하세요.

   마운트에 올바른 소유권이 표시되는지 확인하세요:

   df -h /opt/mattermost/data
   ls -ld /opt/mattermost/data
   

4. 자동 마운트 구성: 각 Mattermost 서버의 /etc/fstab 에 추가하세요:

   NFS_SERVER_IP:/mnt/mattermost-data /opt/mattermost/data nfs rw,hard 0 0
   

   예시:

   192.168.1.100:/mnt/mattermost-data /opt/mattermost/data nfs rw,hard 0 0
   

5. 파일 접근 테스트: 각 서버에서 쓰기 권한을 확인하세요:

   sudo -u mattermost touch /opt/mattermost/data/test-$(hostname)
   ls -l /opt/mattermost/data/
   

   모든 서버에서 mattermost:mattermost 소유권으로 파일이 보여야 합니다.

6. Mattermost 구성: 파일 스토리지 디렉터리를 설정하세요:

   sudo -u mattermost /opt/mattermost/bin/mmctl --local config set FileSettings.Directory /opt/mattermost/data
   

7. Mattermost 재시작: 모든 서버에 구성을 적용하세요:

   sudo systemctl restart mattermost
   

8. 확인: Mattermost가 공유 스토리지에 디렉터리를 생성하는지 확인하세요:

   ls -la /opt/mattermost/data/
   

   users, teams 등의 디렉터리가 표시되어야 합니다. 파일 업로드를 테스트하여 모든 서버에서 파일에 접근할 수 있는지 확인하세요.

로컬 스토리지에서 공유 스토리지로 마이그레이션#

기존 파일을 로컬 스토리지에서 S3 또는 NFS로 마이그레이션해야 하는 경우, 마이그레이션 프로세스는 이 문서의 범위를 벗어납니다. 그러나 일반적인 접근 방식은 다음과 같습니다:

1. 새 공유 스토리지(S3 또는 NFS) 설정
2. 로컬 디렉터리(일반적으로 /opt/mattermost/data)의 모든 파일을 새 스토리지 위치로 복사
3. 새 스토리지를 가리키도록 Mattermost 구성 업데이트
4. 모든 파일에 접근할 수 있는지 확인

데이터베이스#

고가용성 배포에서는 최적의 성능과 안정성을 보장하기 위해 데이터베이스를 신중하게 구성해야 합니다. Mattermost는 데이터베이스 부하를 분산하기 위한 읽기 복제본과 검색 쿼리를 분리하기 위한 검색 복제본 사용을 지원합니다.

데이터베이스 쿼리 분산 이해하기#

Mattermost는 다음과 같이 데이터베이스 인프라 전반에 쿼리를 분산합니다:

• 쓰기 요청 과 일부 특정 읽기 요청은 프라이머리 데이터베이스로 전송됩니다
• 읽기 요청 (프라이머리로 전송되어야 하는 요청 제외)은 사용 가능한 읽기 복제본 간에 분산됩니다. 읽기 복제본이 구성되어 있지 않으면 프라이머리로 전송됩니다
• 검색 요청 은 사용 가능한 검색 복제본 간에 분산됩니다. 검색 복제본이 구성되어 있지 않으면 읽기 복제본으로 전송됩니다. 읽기 복제본도 구성되어 있지 않으면 프라이머리로 전송됩니다

모든 데이터베이스 구성 옵션에 대한 자세한 내용은 데이터베이스 구성 설정 문서를 참조하세요.

Amazon RDS Aurora PostgreSQL#

Amazon Aurora PostgreSQL은 내장된 고가용성 및 자동 장애 조치 기능을 갖춘 관리형 데이터베이스 서비스를 제공합니다.

아키텍처 개요:

• Aurora는 여러 가용 영역(Availability Zone)에 걸쳐 여러 복제본을 자동으로 유지합니다
• 클러스터는 현재 프라이머리 인스턴스를 자동으로 가리키는 단일 writer 엔드포인트 를 제공합니다
• 클러스터는 사용 가능한 읽기 복제본 간에 로드 밸런싱하는 reader 엔드포인트 를 제공합니다
• Aurora는 필요할 때 복제본을 프라이머리로 승격하는 자동 장애 조치를 처리합니다

Aurora용 Mattermost 구성:

1. 프라이머리 데이터베이스 연결 구성: DataSource가 (개별 인스턴스 엔드포인트가 아닌) Aurora 클러스터의 writer 엔드포인트를 가리키도록 설정하세요:

   # Use the cluster writer endpoint for the primary connection
   mmctl config set SqlSettings.DataSource "postgres://username:password@your-cluster.cluster-xxxxx.region.rds.amazonaws.com:5432/mattermost?sslmode=require&connect_timeout=10"
   

2. 읽기 복제본 구성: Mattermost는 DataSourceReplicas 가 Aurora reader를 가리키도록 설정하는 두 가지 방법을 지원합니다. 두 방법 모두 사용할 수 있습니다. reader 인스턴스 집합이 얼마나 자주 바뀌는지에 따라 선택하세요.

   옵션 A: Aurora 클러스터 reader 엔드포인트. reader 엔드포인트를 단일 항목으로 추가하고, 읽기 연결이 reader 인스턴스 전반에 계속 분산되도록 연결 수명을 짧게 설정하세요:

   # Create a configuration patch file
   cat > /tmp/replica-config.json <<'EOF'
   {
     "SqlSettings": {
       "DataSourceReplicas": [
         "postgres://username:password@your-cluster.cluster-ro-xxxxx.region.rds.amazonaws.com:5432/mattermost?sslmode=require&connect_timeout=10"
       ],
       "ConnMaxLifetimeMilliseconds": 300000
     }
   }
   EOF
   
   # Apply the configuration
   mmctl config patch /tmp/replica-config.json
   
   # Clean up the temporary file
   rm /tmp/replica-config.json
   

   • 장점: reader 인스턴스를 추가, 제거 또는 교체해도 구성이 바뀌지 않으므로 Aurora Replica Auto Scaling과 함께 사용할 수 있습니다. Aurora는 사용할 수 없는 reader로 새 연결을 보내지 않습니다. 단일 항목은 노드당 하나의 연결 풀을 사용합니다.
   • 단점: Aurora는 쿼리가 아니라 연결을 분산합니다. reader 엔드포인트는 연결이 열릴 때 reader 인스턴스를 선택하며, 해당 연결의 모든 쿼리는 같은 인스턴스로 전송됩니다. 기본 최대 연결 수명 1시간이 적용되면 reader 간 불균형이 최대 1시간 동안 이어질 수 있으며, 새로 추가된 reader는 기존 연결이 만료될 때까지 트래픽을 거의 받지 못합니다. 풀이 하나뿐이므로 같은 읽기 처리 용량을 유지하려면 MaxOpenConns 를 늘려야 할 수도 있습니다. 다음 단계를 참조하세요.

옵션 B: 개별 reader 인스턴스 엔드포인트. 각 reader 인스턴스 엔드포인트를 별도의 항목으로 추가하세요:

# Create a configuration patch file
cat > /tmp/replica-config.json <<'EOF'
{
  "SqlSettings": {
    "DataSourceReplicas": [
      "postgres://username:password@your-cluster-instance-1.xxxxx.region.rds.amazonaws.com:5432/mattermost?sslmode=require&connect_timeout=10",
      "postgres://username:password@your-cluster-instance-2.xxxxx.region.rds.amazonaws.com:5432/mattermost?sslmode=require&connect_timeout=10"
    ]
  }
}
EOF

# Apply the configuration
mmctl config patch /tmp/replica-config.json

# Clean up the temporary file
rm /tmp/replica-config.json

• 장점: Mattermost는 읽기 쿼리를 한 번에 하나씩 항목 간에 순환시키므로, 연결 수명과 관계없이 reader 엔드포인트보다 부하가 더 고르게 분산됩니다.
• 단점: reader 인스턴스를 추가, 제거 또는 교체할 때마다 목록을 업데이트해야 합니다. 새 reader는 목록에 추가되기 전까지 트래픽을 받지 못하므로, 이 옵션은 Aurora Replica Auto Scaling과 함께 사용할 수 없습니다. Mattermost는 시간 초과가 아니라 연결 오류가 발생한 뒤에만 복제본을 오프라인으로 표시하며, 나열된 모든 복제본이 오프라인일 때만 읽기를 프라이머리로 보냅니다. 응답하지 않는 reader는 순환에 그대로 남아 있고, 해당 reader로 전송된 쿼리는 쿼리 시간 제한이 만료될 때까지 대기합니다. 또한 각 항목마다 자체 연결 풀이 생성되므로 연결 수는 reader 수에 따라 늘어납니다.

reader 인스턴스가 시간이 지나면서 바뀌거나 Aurora Replica Auto Scaling을 사용한다면 옵션 A를 사용하세요. reader 인스턴스 집합이 고정되어 있고 가장 고른 읽기 부하가 필요하다면 옵션 B를 사용하세요.

3. 연결 풀 설정 구성:

   # Set connection pool limits (per database connection)
   mmctl config set SqlSettings.MaxOpenConns 100
   mmctl config set SqlSettings.MaxIdleConns 50
   

   권장 비율은 2:1(MaxOpenConns:MaxIdleConns)입니다. 이 설정은 클러스터 전체 총합이 아니라 데이터 소스별, Mattermost 서버 노드별 로 적용됩니다. 각 노드는 프라이머리 데이터베이스와 DataSourceReplicas 및 DataSourceSearchReplicas 의 각 항목에 대해 MaxOpenConns 크기의 자체 연결 풀을 엽니다.

   reader 엔드포인트 항목 하나는 그 뒤에 reader 인스턴스가 몇 개 있든 풀을 하나만 가집니다. 여러 reader 인스턴스 항목을 reader 엔드포인트 항목 하나로 바꾸는 경우, 같은 읽기 처리 용량을 유지하려면 MaxOpenConns 와 MaxIdleConns 를 늘리세요. 예를 들어 MaxOpenConns 100으로 설정된 인스턴스 항목 3개를 바꾸면, 노드당 읽기 연결 300개를 동일하게 허용하기 위해 MaxOpenConns 를 300으로 설정해야 합니다. 프라이머리도 같은 설정을 사용하므로 writer의 max_connections 가 더 높아진 값을 처리할 수 있는지도 확인하세요.

   데이터베이스(또는 그 앞단의 연결 풀링 프록시)에서 max_connections 크기를 정하려면, 먼저 노드당 데이터 소스 수를 계산하세요. 프라이머리를 1로 계산하고, DataSourceReplicas 와 DataSourceSearchReplicas 의 항목 수를 더합니다. 이 수에 MaxOpenConns 를 곱한 다음, 앱 서버 노드 수를 다시 곱합니다:

   MaxOpenConns x (노드당 데이터 소스 수) x (앱 노드 수)

   예를 들어 프라이머리 1개와 reader 인스턴스 항목 2개가 있는 경우 각 노드는 데이터 소스 3개를 가집니다. 3노드 클러스터 전체에서 기본값인 MaxOpenConns 100을 적용하면 3 x 3 x 100 = 900개의 가능한 연결이 됩니다.

4. 데이터베이스 구성 확인: Mattermost를 재시작하고 데이터베이스 연결이 정상인지 확인하세요:

   sudo systemctl restart mattermost
   
   # Check logs for database connection messages
   sudo journalctl -u mattermost -n 100
   

Amazon RDS와 Aurora는 DB 파라미터 그룹(RDS)과 DB 클러스터 파라미터 그룹(Aurora)을 통해 PostgreSQL 구성을 노출하므로 메모리, 복제 및 기타 설정을 조정할 수 있습니다. Aurora의 기본값은 대부분의 워크로드에 일반적으로 잘 최적화되어 있습니다. Amazon CloudWatch와 RDS Performance Insights 기능을 사용하여 성능을 모니터링하세요.

자체 관리형 PostgreSQL#

자체 관리형 PostgreSQL 배포의 경우 데이터베이스 구성을 완전히 제어할 수 있으며, 복제, 백업, PostgreSQL 설정을 직접 구성해야 합니다.

PostgreSQL 복제 설정:

1. postgresql.conf 를 수정하여 복제를 위한 프라이머리 데이터베이스 서버 구성:

   Ubuntu/Debian: /etc/postgresql/{version}/main/postgresql.conf 수정(예: /etc/postgresql/14/main/postgresql.conf)

   RHEL/CentOS: /var/lib/pgsql/{version}/data/postgresql.conf 수정(예: /var/lib/pgsql/14/data/postgresql.conf)

   # Enable replication
   wal_level = replica
   max_wal_senders = 10
   max_replication_slots = 10
   
   # Configure write-ahead log archiving (recommended)
   archive_mode = on
   archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'
   

   수정 후 PostgreSQL을 재시작하세요:

   sudo systemctl restart postgresql
   

2. 프라이머리의 pg_hba.conf 에서 복제 접근 구성:

   Ubuntu/Debian: /etc/postgresql/{version}/main/pg_hba.conf 수정

   RHEL/CentOS: /var/lib/pgsql/{version}/data/pg_hba.conf 수정

   # Allow replication connections from replica servers
   # Replace REPLICA_IP with your replica server IP addresses
   host    replication    replication_user    REPLICA_IP/32    scram-sha-256
   

3. 프라이머리에서 복제 사용자 생성:

   CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'secure_password';
   

4. pg_basebackup 을 사용하여 복제본 생성. 이 명령을 실행하기 전에 복제본에서 PostgreSQL을 중지하고 데이터 디렉터리가 비어 있는지 확인하세요.

   # On the replica server, create base backup from primary.
   # Replace DATA_DIR with the platform-specific data directory:
   #   Ubuntu/Debian: /var/lib/postgresql/{version}/main
   #   RHEL/CentOS: /var/lib/pgsql/{version}/data
   sudo -u postgres pg_basebackup -h PRIMARY_IP -D DATA_DIR -U replication_user -P -v -R -X stream
   

   -R 플래그는 standby.signal 파일을 자동으로 생성하고 복제 설정을 구성합니다.

5. 복제본 서버 시작:

   sudo systemctl start postgresql
   sudo systemctl enable postgresql
   

6. 프라이머리에서 복제 상태 확인:

   SELECT client_addr, state, sync_state FROM pg_stat_replication;
   

자체 관리형 PostgreSQL용 Mattermost 구성:

1. mmctl 또는 환경 변수를 사용하여 데이터베이스 연결 구성:

   # Primary database connection
   mmctl config set SqlSettings.DataSource "postgres://mattermost_user:password@primary-db.example.com:5432/mattermost?sslmode=require&connect_timeout=10"
   
   # Read replica connections - create a configuration patch file
   cat > /tmp/replica-config.json <<'EOF'
   {
     "SqlSettings": {
       "DataSourceReplicas": [
         "postgres://mattermost_user:password@replica1-db.example.com:5432/mattermost?sslmode=require&connect_timeout=10",
         "postgres://mattermost_user:password@replica2-db.example.com:5432/mattermost?sslmode=require&connect_timeout=10"
       ]
     }
   }
   EOF
   
   # Apply the replica configuration
   mmctl config patch /tmp/replica-config.json
   
   # Clean up the temporary file
   rm /tmp/replica-config.json
   
   # Connection pool settings
   mmctl config set SqlSettings.MaxOpenConns 100
   mmctl config set SqlSettings.MaxIdleConns 50
   

2. Mattermost를 재시작하지 않고 (이미 실행 중인 경우) 구성 변경 사항 적용:

   System Console > Environment > Web Server 로 이동한 다음 디스크에서 구성 다시 로드 를 선택하고, 이어서 System Console > Environment > Database 로 이동하여 데이터베이스 연결 재활용 을 선택하세요.

   또는 Mattermost 서비스를 재시작하세요:

   sudo systemctl restart mattermost
   

권장 PostgreSQL 구성 설정:

다음 설정은 프로덕션 배포에 매우 중요합니다. 이 설정은 AWS Aurora r5.xlarge 인스턴스에서 테스트되었지만 유사한 사양을 가진 모든 PostgreSQL 배포에 적용됩니다.

프라이머리/Writer 노드 구성:

프라이머리 데이터베이스 서버에서 postgresql.conf 를 수정하세요:

• Ubuntu/Debian: /etc/postgresql/{version}/main/postgresql.conf
• RHEL/CentOS: /var/lib/pgsql/{version}/data/postgresql.conf

다음 설정을 추가하거나 수정하세요:

# Connection settings
# Adjust based on your hardware - this is for r5.xlarge or equivalent
# Coordinate with Mattermost MaxOpenConns setting
max_connections = 1024

# Random page cost - set to 1.1 for SSD storage
# Use default 4.0 for spinning disks
random_page_cost = 1.1

# Work memory - use 32MB with read replicas, 16MB for single instance
# Adjust downward for smaller instances
work_mem = 32MB

# Cache and buffer settings
# Set to 65% of total memory for dedicated database servers
# For 32GB RAM instance, use 21GB
# For smaller servers (e.g., 4GB RAM), use 20% or less (e.g., 512MB)
effective_cache_size = 21GB
shared_buffers = 21GB

# Maintenance work memory
# Use 1GB for 32GB+ RAM servers, 512MB for smaller servers
maintenance_work_mem = 1GB

# Autovacuum settings
autovacuum_max_workers = 4
autovacuum_vacuum_cost_limit = 500

# Parallel query settings (for servers with 32+ CPUs)
max_worker_processes = 12
max_parallel_workers_per_gather = 4
max_parallel_workers = 12
max_parallel_maintenance_workers = 4

# TCP keepalive settings
# If using pgbouncer or connection pooling proxy, apply these to the proxy
# and revert to defaults on the database
tcp_keepalives_idle = 5
tcp_keepalives_interval = 1
tcp_keepalives_count = 5

읽기 복제본 노드 구성:

각 읽기 복제본 서버에서 postgresql.conf 를 수정하여 위의 모든 프라이머리 설정을 복사한 다음, 다음을 수정하거나 추가하세요:

# Work memory - use 16MB on replicas, 32MB on primary
work_mem = 16MB

# Hot standby settings - CRITICAL FOR PRODUCTION STABILITY
# These settings prevent query cancellations when primary has write activity
# Without these settings, high write traffic can cause read queries to fail
hot_standby = on
hot_standby_feedback = on

프라이머리 또는 복제본에서 구성 파일을 수정한 후 변경 사항을 적용하려면 PostgreSQL을 재시작하세요:

sudo systemctl restart postgresql

Vacuum 및 유지 관리:

PostgreSQL 성능은 정기적인 vacuum에 크게 좌우됩니다. vacuum 활동을 모니터링하세요:

-- Check vacuum status for top 10 tables with most dead tuples
SELECT relname, n_tup_ins as inserts, n_tup_upd as updates, n_tup_del as deletes,
       n_live_tup as live_tuples, n_dead_tup as dead_tuples, n_mod_since_analyze,
       last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count
FROM pg_stat_user_tables
ORDER BY dead_tuples DESC
LIMIT 10;

테이블에 50,000개 이상의 dead 튜플이 있거나 last_autovacuum 이 몇 개월 동안 vacuum되지 않았음을 나타내는 경우, 테이블별 autovacuum 설정을 조정하세요:

-- Example: More aggressive vacuuming for high-activity tables
ALTER TABLE posts SET (
  autovacuum_vacuum_scale_factor = 0.1,    -- default is 0.2
  autovacuum_analyze_scale_factor = 0.05,  -- default is 0.1
  autovacuum_vacuum_cost_limit = 1000      -- default is 200
);

모니터링 데이터를 기반으로 이 값들을 조정하세요. PostgreSQL이 autovacuum 실행 시점을 계산하는 방법에 대한 자세한 내용은 PostgreSQL autovacuum 문서를 참조하세요.

검색 복제본#

대규모 배포의 경우 리소스 집약적인 검색 쿼리를 일반 데이터베이스 작업과 분리하기 위해 전용 검색 복제본을 구성하는 것을 고려하세요.

검색 복제본은 검색 쿼리를 처리하기 위해 Mattermost에서 특별히 구성되는 PostgreSQL 읽기 복제본입니다:

# Configure dedicated search replicas - create a configuration patch file
cat > /tmp/search-replica-config.json <<'EOF'
{
  "SqlSettings": {
    "DataSourceSearchReplicas": [
      "postgres://mattermost_user:password@search-replica1.example.com:5432/mattermost?sslmode=require&connect_timeout=10",
      "postgres://mattermost_user:password@search-replica2.example.com:5432/mattermost?sslmode=require&connect_timeout=10"
    ]
  }
}
EOF

# Apply the search replica configuration
mmctl config patch /tmp/search-replica-config.json

# Clean up the temporary file
rm /tmp/search-replica-config.json

검색 복제본은 일반 읽기 복제본과 동일한 PostgreSQL 구성을 사용합니다. 구성되면 모든 검색 쿼리가 검색 복제본 간에 분산됩니다. 검색 복제본을 사용할 수 없으면 쿼리는 읽기 복제본으로, 최종적으로는 프라이머리 데이터베이스로 대체됩니다.

고급 검색 기능이 필요한 배포의 경우, Elasticsearch 통합에 대한 정보는 Enterprise 검색을 참조하세요.

데이터베이스 크기 조정#

데이터베이스 크기는 예상 사용자 수와 사용 패턴에 따라 달라집니다. 자세한 내용은 Enterprise용 하드웨어 크기 조정 문서를 참조하세요.

주요 고려 사항:

• 장애 조치 시나리오에서 가용성을 보장하기 위해 프라이머리와 복제본 데이터베이스가 각각 독립적으로 전체 부하의 100%를 처리할 수 있도록 크기를 조정하세요
• 추가 읽기 복제본이 필요한 시점을 파악하기 위해 데이터베이스 CPU, 메모리, I/O 지표를 모니터링하세요
• 성장에 대비하세요 - 데이터베이스 스토리지는 메시지 기록, 파일 메타데이터, 보존 정책에 따라 증가합니다

데이터베이스 장애 조치 및 재해 복구#

수동 장애 조치:

읽기 복제본을 수동으로 프라이머리로 승격해야 하는 경우(유지 관리, 재해 복구 또는 기타 운영상의 필요를 위해):

1. 승격하기 전에 복제본이 동기화되었는지 확인하세요. 프라이머리를 따라잡지 못한 복제본을 승격하면 재생되지 않은 WAL 데이터가 손실됩니다.

   복제본 서버에서 복제 상태를 확인하세요:

   SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(),
          pg_last_wal_replay_lsn() = pg_last_wal_receive_lsn() AS synced;
   

   계속하기 전에 synced 가 true 를 반환할 때까지 기다리세요. 프라이머리에 이미 접근할 수 없는 계획되지 않은 장애 조치의 경우, 이 확인은 데이터 손실이 전혀 없음을 보장하는 것이 아니라 프라이머리가 실패하기 전에 무엇이 복제되었는지를 확인하는 것입니다.

2. 복제본을 프라이머리로 승격:

   자체 관리형 PostgreSQL의 경우:

   # On the replica server.
   # Replace DATA_DIR with the platform-specific data directory:
   #   Ubuntu/Debian: /var/lib/postgresql/{version}/main
   #   RHEL/CentOS: /var/lib/pgsql/{version}/data
   sudo -u postgres pg_ctl promote -D DATA_DIR
   

   Amazon RDS의 경우:

   AWS 콘솔 또는 CLI를 사용하여 읽기 복제본을 독립 인스턴스로 승격하세요.

3. 새 프라이머리를 가리키도록 Mattermost 구성 업데이트:

   # Update the DataSource to point to the new primary
   mmctl config set SqlSettings.DataSource "postgres://user:password@new-primary.example.com:5432/mattermost?sslmode=require"
   

4. 다운타임 없이 구성 다시 로드:

   • System Console > Environment > Web Server → 디스크에서 구성 다시 로드 로 이동
   • System Console > Environment > Database → 데이터베이스 연결 재활용 으로 이동

   연결이 재활용되는 동안 사용자는 (네트워크 연결 끊김과 유사한) 짧은 중단을 경험할 수 있습니다.

재해 복구:

포괄적인 재해 복구 계획을 위해:

• pg_dump, pg_basebackup 또는 관리형 백업 서비스를 사용하여 정기적인 데이터베이스 백업을 구현하세요
• 복원 절차를 정기적으로 테스트하세요
• 장애 조치 절차를 문서화하고 연습하세요
• 지리적 중복성을 위한 교차 리전 복제를 고려하세요(참고: 다중 리전 Mattermost 클러스터는 공식적으로 지원되지 않지만 적절한 네트워크 구성으로 작동할 수 있습니다)

자세한 내용은 백업 및 재해 복구 문서를 참조하세요.

다음 단계#

고가용성 클러스터가 배포되어 운영 중이라면, 배포 규모와 요구 사항에 따라 다음과 같은 추가 확장 최적화를 고려하세요:

Calls 배포

음성 및 화면 공유 통신에 Mattermost Calls를 사용하는 경우, HA 배포에 맞는 적절한 규모의 Calls 인프라를 계획하려면 Calls 셀프 호스팅 배포를 검토하세요.

Enterprise 검색

게시물이 250만 건을 초과할 것으로 예상되는 배포의 경우, Elasticsearch를 사용하는 Enterprise 검색 도입을 고려하세요. Elasticsearch는 대규모 배포에 훨씬 빠른 검색 성능과 고급 검색 기능을 제공합니다.

Redis 통합

사용자 수가 100,000명을 초과하는 배포의 경우, 클러스터 전반의 세션 관리, 캐싱, 실시간 통신 성능을 향상하려면 Redis를 도입하세요.

성능 모니터링

고가용성 클러스터의 상태, 성능 지표, 리소스 사용률을 모니터링하려면 Prometheus 및 Grafana를 배포하세요. 포괄적인 모니터링은 병목 현상을 파악하고, 용량을 계획하고, 최적의 성능을 유지하는 데 필수적입니다.

운영 및 유지 관리#

이 섹션에서는 배포 후 고가용성 클러스터를 관리하고 유지 관리하는 운영 측면을 다룹니다.

클러스터 디스커버리#

비표준(복잡한) 네트워크 구성이 있는 경우 호스트명 재정의 설정을 사용하여 클러스터 노드가 서로를 검색하는 데 도움을 줄 수 있습니다. 이 때문에 구성의 클러스터 설정은 구성 파일 해시에서 제거되며, 이는 고가용성 모드에서 클러스터 구성 설정이 약간 다를 수 있음을 의미합니다. 디스커버리를 강제해야 하는 경우 클러스터의 각 노드마다 호스트명 재정의를 다르게 설정하도록 되어 있습니다.

UseIPAddress 가 true 로 설정된 경우, 첫 번째 비로컬 IP 주소(루프백이 아닌, 로컬유니캐스트가 아닌, 로컬멀티캐스트가 아닌 네트워크 인터페이스)를 검색하여 IP 주소를 얻으려고 시도합니다. 내장 go 함수 net.InterfaceAddrs()를 사용하여 네트워크 인터페이스를 열거합니다. 그렇지 않으면 os.Hostname() 내장 go 함수를 사용하여 호스트명을 가져오려고 시도합니다.

또한 데이터베이스에 대해 SELECT * FROM ClusterDiscovery 를 실행하여 Hostname 필드가 어떻게 채워졌는지 확인할 수 있습니다. 해당 필드는 서버가 클러스터의 다른 노드와 연결을 시도하는 데 사용할 호스트명 또는 IP 주소입니다. url Hostname:Port 와 Hostname:PortGossipPort 에 연결을 시도합니다. 클러스터가 올바르게 gossip하기 위해 모든 올바른 포트가 열려 있는지 확인해야 합니다. 이 포트들은 구성의 ClusterSettings 에 있습니다.

요약하면 다음을 사용해야 합니다:

1. 첫 번째 비로컬 주소를 다른 머신에서 볼 수 있는 경우 IP 주소 디스커버리.
2. 클러스터의 다른 노드에서 적절히 검색 가능한 이름이 되도록 운영 체제의 호스트명 재정의.
3. 위 단계가 작동하지 않는 경우 서버 구성의 호스트명 재정의. 필요하면 이 필드에 IP 주소를 넣을 수 있습니다. config.json 파일을 사용하는 경우 이 설정은 각 클러스터 노드마다 다를 수 있습니다.

상태#

Mattermost 서버는 수평적 확장을 허용하기 위해 가능한 한 적은 상태를 유지하도록 설계되었습니다. Mattermost 확장 시 고려해야 할 상태 항목은 다음과 같습니다:

• 빠른 검증 및 채널 접근을 위한 메모리 내 세션 캐시.
• 빠른 응답을 위한 메모리 내 온라인/오프라인 캐시.
• 메모리에 로드되고 저장된 시스템 구성 파일.
• 메시지 전송에 사용되는 클라이언트의 WebSocket 연결.

Mattermost 서버가 고가용성으로 구성되면 서버는 상태를 동기화하기 위해 다른 수신 주소에서 노드 간 통신 프로토콜을 사용합니다. 상태가 변경되면 데이터베이스에 다시 쓰고 다른 서버에 상태 변경을 알리는 노드 간 메시지가 전송됩니다. 항목의 실제 상태는 항상 데이터베이스에서 읽을 수 있습니다. Mattermost는 또한 "[사용자 X]가 입력 중입니다."와 같은 실시간 메시지를 위해 클러스터의 다른 서버로 WebSocket 메시지를 전달하기 위해 노드 간 통신을 사용합니다.

리더 선출#

클러스터 리더 선출 프로세스는 다중 노드 클러스터 환경에서 단일 노드에서 실행되는 LDAP 동기화와 같은 예약된 작업을 할당합니다.

이 프로세스는 장애가 발생하지 않은 프로세스 중에서 가장 낮은 노드 ID 번호를 가진 프로세스가 리더로 선택되는 널리 사용되는 bully 리더 선출 알고리즘을 기반으로 합니다.

작업 서버#

Mattermost는 작업 서버를 통해 주기적인 작업을 실행합니다. 이 작업에는 다음이 포함됩니다:

• LDAP 동기화
• 데이터 보존
• 컴플라이언스 내보내기
• Elasticsearch 인덱싱
• 예약된 게시물
• DND 상태 초기화
• 게시물 알림

클러스터의 모든 앱 및 작업 서버에 대해 JobSettings.RunScheduler 를 true 로 설정했는지 확인하세요. 그러면 클러스터 리더가 반복 작업 예약을 담당하게 됩니다.

mmctl을 사용하여 이 설정을 확인할 수 있습니다:

mmctl config get JobSettings.RunScheduler

설정해야 하는 경우(기본값은 true 입니다):

mmctl config set JobSettings.RunScheduler true

플러그인과 고가용성#

플러그인을 설치하거나 업그레이드하면 클러스터의 서버에 자동으로 전파됩니다. 파일 스토리지는 NAS 또는 Amazon S3와 같은 서비스를 사용하여 모든 서버 간에 공유된다고 가정합니다.

"DriverName": "local" 을 사용하는 경우 "FileSettings": "Directory": "./data/" 의 디렉터리는 로컬 디렉터리로 매핑된 NAS 위치여야 합니다. 그렇지 않으면 고가용성이 올바르게 작동하지 않고 파일 스토리지가 손상될 수 있습니다.

v5.14에서 플러그인을 재설치하면 이전의 활성화 또는 비활성화 상태가 유지됩니다. v5.15부터 재설치된 플러그인의 초기 상태는 비활성화 입니다.

CLI와 고가용성#

CLI는 고가용성 환경이 클러스터의 모든 노드에서 작업을 수행하는 데 사용하는 메커니즘을 우회하는 단일 노드에서 실행됩니다. 따라서 고가용성 환경에서 CLI 명령을 실행할 때 사용자 업데이트/삭제 또는 구성 설정 변경과 같은 작업은 서버 재시작이 필요합니다.

서버 재시작이 필요하지 않으므로 고가용성 환경에서는 대신 mmctl을 사용하는 것을 권장합니다. 이 변경 사항은 API 계층을 통해 이루어지므로 변경 요청을 받는 노드가 클러스터의 다른 모든 노드에 알립니다.

업그레이드 가이드#

업데이트는 버그 또는 성능 문제를 수정하는 Mattermost 서버의 점진적 변경 사항입니다. 업그레이드는 서버에 새롭거나 향상된 기능을 추가합니다.

운영 중 구성 변경 업데이트#

대부분의 구성 업데이트에는 서비스 중단이 필요하지 않습니다. 서비스 중단이 필요한 업그레이드에 대한 자세한 내용은 아래 섹션을 참조하세요. 부하가 낮은 기간에 업데이트를 적용할 수 있지만, 고가용성 클러스터 기반 배포의 크기가 올바르게 조정되어 있다면 언제든지 수행할 수 있습니다. 시스템 다운타임은 짧으며 클러스터의 Mattermost 서버 수에 따라 다릅니다. 머신을 재시작하는 것이 아니라 Mattermost 서버 앱만 재시작합니다. Mattermost 서버 재시작은 일반적으로 약 5초가 걸립니다.

데이터베이스 구성을 사용하는 경우(권장):

mmctl을 사용하여 구성 설정을 업데이트하세요. 변경 사항은 클러스터의 모든 서버에 자동으로 전파됩니다:

mmctl config set <setting> <value>

예를 들어:

mmctl config set TeamSettings.MaxUsersPerTeam 100

config.json 파일을 사용하는 경우:

1. 기존 config.json 파일을 백업하세요.
2. Mattermost 서버 중 하나의 config.json 에 구성 변경을 적용하고 파일을 저장하세요. 아직 파일을 다시 로드하지 마세요.
3. config.json 파일을 다른 서버에 복사하세요.
4. 실행 중인 서버 하나를 제외하고 모든 Mattermost를 종료하세요.
5. 여전히 실행 중인 서버에서 구성 파일을 다시 로드하세요. System Console > Environment > Web Server 로 이동한 다음 디스크에서 구성 다시 로드 를 선택하세요.
6. 다른 서버를 시작하세요.

운영 중 서버 버전 업데이트#

Mattermost 서버의 보안 패치 닷 릴리즈에는 서비스 중단이 필요하지 않습니다. 한 서버가 업데이트 중에 시스템 전체 부하를 감당할 수 있을 만큼 예상 부하가 충분히 작은 기간에 업데이트를 적용할 수 있습니다.

재시작 시 머신을 재시작하는 것이 아니라 Mattermost 서버 앱만 재시작합니다. Mattermost 서버 재시작은 일반적으로 약 5초가 걸립니다.

1. Mattermost 서버 업그레이드의 Enterprise Edition 업그레이드 섹션에서 업그레이드 절차를 검토하세요.
2. Mattermost 데이터베이스를 백업하세요. 구성에 config.json 파일을 사용하는 경우 구성 파일도 백업하세요.
3. 프록시를 설정하여 모든 새 요청을 단일 서버로 이동하세요. NGINX를 사용하고 있고 /etc/nginx/sites-available/mattermost 의 업스트림 백엔드 섹션으로 구성된 경우 먼저 업데이트하려는 서버 하나를 제외하고 모두 주석 처리한 다음 NGINX를 다시 로드하세요.
4. 먼저 업데이트하는 서버를 제외한 각 서버에서 Mattermost를 종료하세요.
5. 종료된 각 Mattermost 인스턴스를 업데이트하세요.
6. config.json 파일을 사용하는 경우, 각 서버에서 새 config.json 파일을 백업한 복사본으로 교체하세요.
7. Mattermost 서버를 시작하세요.
8. 실행 상태로 남겨둔 서버에 대해 업데이트 절차를 반복하세요.

서비스 중단이 필요한 서버 업그레이드#

업그레이드에 데이터베이스 스키마 변경이 포함되거나 서버 구성 변경이 서버 재시작을 필요로 하는 경우 서비스 중단이 필요합니다. 예를 들어:

• 기본 서버 언어
• 속도 제한
• 웹서버 모드
• 데이터베이스
• 고가용성

업그레이드에 데이터베이스 스키마 변경이 포함된 경우 먼저 시작하는 서버가 데이터베이스를 업그레이드합니다.

부하가 낮은 기간에 업그레이드를 적용하세요. 시스템 다운타임은 짧으며 클러스터의 Mattermost 서버 수에 따라 다릅니다. 머신을 재시작하는 것이 아니라 Mattermost 서버 앱만 재시작합니다.

1. Mattermost 서버 업그레이드의 Enterprise Edition 업그레이드 섹션에서 업그레이드 절차를 검토하세요.
2. Mattermost 데이터베이스를 백업하세요. 구성에 config.json 파일을 사용하는 경우 구성 파일도 백업하세요.
3. NGINX를 중지하세요.
4. 각 Mattermost 인스턴스를 업그레이드하세요.
5. config.json 파일을 사용하는 경우, 각 서버에서 새 config.json 파일을 백업한 복사본으로 교체하세요.
6. Mattermost 서버 중 하나를 시작하세요.
7. 서버가 실행되면 다른 서버를 시작하세요.
8. NGINX를 재시작하세요.

모든 클러스터 노드는 단일 프로토콜을 사용해야 합니다#

모든 클러스터 트래픽은 gossip 프로토콜을 사용합니다. Gossip 클러스터링은 더 이상 비활성화할 수 없습니다.

고가용성 클러스터 기반 배포를 업그레이드할 때 하나의 노드가 gossip 프로토콜을 사용하지 않는 경우 클러스터의 다른 노드를 업그레이드할 수 없습니다. 이 유형의 업그레이드를 완료하려면 gossip을 사용해야 합니다. 또는 모든 노드를 종료하고 업그레이드 후 개별적으로 다시 시작할 수 있습니다.

지속적 운영 요구사항#

서버 업데이트 및 업그레이드 중에도 항상 지속적인 운영을 가능하게 하려면 중복 구성 요소가 적절한 크기로 조정되어 있고 시스템의 각 구성 요소를 업데이트하는 올바른 순서를 따르는지 확인해야 합니다.

예상 규모에서의 중복
하나의 구성 요소가 실패하면 나머지 앱 서버, 데이터베이스 서버, 로드 밸런서가 시스템의 전체 부하를 감당할 수 있도록 크기와 구성이 지정되어야 합니다. 이 요구 사항이 충족되지 않으면 하나의 구성 요소 중단으로 인해 나머지 구성 요소에 과부하가 걸려 전체 시스템 중단이 발생할 수 있습니다.

지속적 운영을 위한 업데이트 순서
올바른 순서로 시스템 구성 요소를 업데이트하면 서비스를 중단하지 않고 대부분의 구성 변경 및 닷 릴리즈 보안 업데이트를 적용할 수 있습니다. 방법은 업그레이드 가이드를 참조하세요.

예외: 서버 재시작이 필요한 구성 설정 변경 및 데이터베이스 스키마 변경이 포함된 서버 버전 업그레이드는 짧은 다운타임이 필요합니다. 서버 재시작을 위한 다운타임은 약 5초입니다. 데이터베이스 스키마 업데이트의 경우 다운타임은 최대 30초일 수 있습니다.

자주 묻는 질문(FAQ)#

Mattermost는 다중 지역 고가용성 클러스터 기반 배포를 지원합니까?#

예. 공식적으로 테스트되지는 않았지만, 예를 들어 AWS 리전 간에 클러스터를 설정할 수 있으며 문제 없이 작동합니다.

데이터베이스 재해 복구를 위해 Mattermost는 무엇을 권장합니까?#

고가용성 구성으로 Mattermost를 배포할 때 Mattermost와 데이터베이스 사이에 데이터베이스 로드 밸런서를 사용하는 것을 권장합니다. 배포에 따라 더 많거나 적은 고려가 필요합니다.

예를 들어, Amazon Aurora로 AWS에 Mattermost를 배포하는 경우 여러 가용성 영역을 활용하는 것을 권장합니다. 자체 클러스터에 Mattermost를 배포하는 경우 기존 아키텍처에 가장 적합한 솔루션을 위해 IT 팀과 상의하세요.

연결된 WebSocket의 호스트명을 찾는 방법은?#

Mattermost v10.4부터 셀프 호스팅 배포를 실행하는 Enterprise 고객은 제품 메뉴 로 이동하여 Mattermost 정보 를 선택하면 Mattermost를 실행 중인 클러스터 노드의 호스트명을 확인할 수 있습니다.

문제 해결#

고가용성 문제 해결 데이터 수집#

고가용성 구성으로 Mattermost를 배포할 때 Prometheus 및 Grafana 지표와 클러스터 서버 로그를 가능한 한 오래(최소 2주) 유지하는 것을 권장합니다.

Mattermost에서 분석 및 문제 해결 목적으로 이 데이터를 요청할 수 있습니다.

빨간색 서버 상태#

고가용성 모드가 활성화되면 시스템 콘솔은 서버가 클러스터와 올바르게 통신하고 있는지 여부를 나타내는 빨간색 또는 녹색으로 서버 상태를 표시합니다. 서버는 노드 간 통신을 사용하여 클러스터의 다른 머신에 핑을 보내고, 핑이 설정되면 서버는 서버 버전 및 구성 파일과 같은 정보를 교환합니다.

다음과 같은 이유로 서버 상태가 빨간색으로 나타날 수 있습니다:

• 구성 파일 불일치: Mattermost는 여전히 노드 간 통신을 시도하지만, 고가용성 모드 기능이 제대로 작동하기 위해 동일한 구성 파일을 가정하기 때문에 시스템 콘솔에서 서버의 빨간색 상태를 표시합니다.
• 서버 버전 불일치: Mattermost는 여전히 노드 간 통신을 시도하지만, 고가용성 모드 기능이 클러스터의 각 서버에 동일한 버전의 Mattermost가 설치되어 있다고 가정하기 때문에 시스템 콘솔에서 서버의 빨간색 상태를 표시합니다. 모든 서버에서 최신 버전의 Mattermost를 사용하는 것을 권장합니다. 업그레이드가 필요한 서버에 대해 Mattermost 서버 업그레이드의 업그레이드 절차를 따르세요.
• 서버 다운: 노드 간 통신이 메시지 전송에 실패하면 15초 후에 다시 시도합니다. 두 번째 시도도 실패하면 서버가 다운된 것으로 간주합니다. 오류 메시지가 로그에 기록되고 시스템 콘솔은 해당 서버에 대한 빨간색 상태를 표시합니다. 노드 간 통신은 15초 간격으로 다운된 서버에 핑을 계속합니다. 서버가 다시 시작되면 새 메시지가 전송됩니다.

WebSocket 연결 끊김#

클라이언트 WebSocket이 연결 끊김을 받으면 백오프와 함께 3초마다 자동으로 재연결을 시도합니다. 연결이 설정되면 클라이언트는 연결이 끊어진 동안 전송된 메시지를 수신하려고 시도합니다.

앱이 지속적으로 새로 고침됨#

config.json 파일을 구성에 사용하는 경우, 시스템 콘솔을 통해 구성 설정을 수정하면 사용자가 다른 앱 서버에 연결할 때마다 클라이언트가 새로 고쳐집니다. 이는 고가용성 클러스터 기반 배포에서 서버들이 서로 다른 구성 파일을 갖고 있기 때문에 발생합니다.

해결 방법:

• 데이터베이스 구성을 사용하는 경우(권장), 시스템 콘솔 또는 mmctl을 통해 설정을 수정하세요. 변경 사항은 모든 서버에 자동으로 동기화됩니다.
• config.json 파일을 사용하는 경우, 다음 단계를 따라 파일에서 직접 구성 설정을 수정하세요.

재로드 후에야 메시지가 게시됨#

고가용성 모드에서 실행할 때 모든 Mattermost 앱 서버가 동일한 버전의 Mattermost를 실행하고 있는지 확인하세요. 다른 버전을 실행하면 하위 버전 앱 서버가 요청을 처리하지 못하고 프런트엔드 앱이 새로 고침되어 유효한 Mattermost 버전을 가진 서버로 전송될 때까지 요청이 전송되지 않는 상태가 발생할 수 있습니다. 확인할 증상으로는 요청이 무작위로 실패하거나 단일 앱 서버의 고루틴과 API 오류가 급격히 증가하는 것이 있습니다.