앱 노드 중단 시에도 Semaphore 가용성 유지
활성 Semaphore 노드를 하나의 서비스 주소 뒤에 배치하세요. 공유 데이터베이스와 Redis 조정으로 애플리케이션 노드 유지보수 중에도 UI와 API 접근을 유지합니다.
인프라는 자동화의 가용성에 의존합니다
인시던트 중에는 팀이 Semaphore로 복구 작업과 인프라 변경을 실행할 수 있어야 합니다. 앱 노드 하나를 사용할 수 없다는 이유로 그 접근을 잃어서는 안 됩니다.
앱 노드 하나 오프라인
UI 열기
API 사용
작업 시작
Enterprise HA로 Semaphore 가용성 유지
Enterprise HA는 다른 노드가 중단되어도 정상 앱 노드를 통해 UI와 API를 계속 제공합니다.
다른 앱 노드가 서비스 계속 제공
UI 열기
API 사용
작업 시작
Semaphore HA에 필요한 것
01
두 개 이상의 Semaphore 노드
동등한 Semaphore 인스턴스를 최소 두 개 실행하세요. 공유 설정을 일치시키고 각 노드에 고유한 값을 지정합니다: ha.node_id.
02
HTTP 및 WebSocket 부하 분산
비정상 노드를 풀에서 제외할 수 있는 로드 밸런서로 HTTP와 WebSocket 연결을 모두 라우팅하세요.
03
공유 SQL 데이터베이스 및 Redis
모든 노드를 같은 PostgreSQL 또는 MySQL 데이터베이스와 Redis 백엔드에 연결하세요. 이 공유 서비스도 장애로부터 보호하세요. SQLite는 HA에서 지원되지 않습니다.
나머지 프로덕션 배포 계획
팀에 필요한 접근 제공
접근 제어전체 배포의 가용성 계획
아키텍처에서 공유 상태를 명확히 표시
문서화된 토폴로지는 액티브-액티브입니다. 동등한 Semaphore 노드가 하나의 공유 PostgreSQL 또는 MySQL 데이터베이스와 Redis 조정을 사용합니다. 데이터베이스는 애플리케이션 상태를, Redis는 분산 잠금, 큐 상태, 노드 간 업데이트를 지원합니다. SQLite와 BoltDB는 이 HA 설계에서 지원되는 데이터베이스가 아닙니다.
요청 및 실시간 업데이트 모두 지원
로드 밸런서는 클라이언트가 정상 애플리케이션 노드에 접근하고 실시간 업데이트를 받도록 HTTP 및 WebSocket 트래픽을 처리해야 합니다. 자체 이중화, TLS 설정, 상태 점검, 운영 동작은 배포의 일부입니다. 애플리케이션 노드 추가가 이를 자동 설정하지는 않습니다.
애플리케이션 경로와 실행 경로를 별도 확장
애플리케이션 노드는 웹/API 및 조정 계층을 제공합니다. 러너는 독립적으로 작업 실행 위치와 용량을 확장할 수 있습니다. 따라서 애플리케이션 노드를 추가할 때마다 세 문제가 모두 해결된다고 가정하지 않고, 용량 변경이 사용자/API 부하, 작업 동시 실행, 다른 네트워크 접근 중 무엇에 관한 것인지 판단할 수 있습니다.
장애 영역마다 별도 복구 계획 마련
애플리케이션 노드 가용성, 데이터베이스 복구, Redis 가용성, 사이트 수준 재해 복구는 각각 다른 책임 영역입니다. 백업, 복원 테스트, 복구 목표, 버전 호환 업그레이드 절차는 계속 필요합니다. 어떤 장애를 견디는 토폴로지도 다른 장애에는 취약할 수 있습니다.
Redis Sentinel로 조정 가용성 유지
조정에도 장애 조치가 필요하면 Redis Sentinel 백엔드를 사용하세요. 각 Semaphore 노드는 Sentinel로 활성 Redis 마스터를 검색하고 재시작 없이 승격된 복제본을 따릅니다. 공유 데이터베이스와 로드 밸런서 가용성 계획과 함께 앱 노드 전반에 같은 Sentinel 배포를 설정하세요.
가용성 계획에 공유 의존 서비스 포함
SQL 데이터베이스, Redis, 로드 밸런서는 모든 애플리케이션 노드에 서비스를 제공합니다. Semaphore 노드와 함께 이 서비스의 이중화 및 복구를 설정하세요.
데이터 복구 경로 유지
애플리케이션 이중화와 데이터 복구는 서로 다른 문제를 해결합니다. 자동화가 의존하는 데이터베이스와 설정의 백업을 유지하고 복원을 테스트하세요.
문서 및 관련 기능
FAQ
Semaphore 고가용성에 어떤 구성 요소가 필요한가요?
문서화된 액티브-액티브 아키텍처는 여러 Semaphore 애플리케이션 노드, 공유 PostgreSQL 또는 MySQL 데이터베이스, Redis 조정, HTTP 및 WebSocket 지원 로드 밸런서를 사용합니다. 각 노드에는 적절한 공유 설정과 고유 HA 식별자가 필요합니다. 애플리케이션 노드와 함께 의존 요소의 가용성을 계획하세요. 두 번째 프로세스만으로는 전체 토폴로지에 필요한 공유 상태와 조정이 제공되지 않습니다.
Semaphore HA는 액티브-액티브인가요, 액티브-패시브인가요?
여기서 설명하는 아키텍처는 동등한 애플리케이션 노드가 서비스에 참여하는 액티브-액티브입니다. 전용 주 애플리케이션 노드와 수동 대기에 의존하지 않습니다. 현재 HA 가이드로 지원되는 설계를 설정하고 일반적인 가용성 문구에서 별도의 액티브-패시브 참조 아키텍처를 추론하지 마세요. 다른 토폴로지가 필요하다면 배포 전에 상태 및 장애 조치 동작을 해결하세요.
HA 배포에 SQLite나 BoltDB를 사용할 수 있나요?
아니요. 문서화된 HA 설계에는 공유 PostgreSQL 또는 MySQL 데이터베이스와 Redis가 필요합니다. 데이터베이스는 참여 노드들의 공통 애플리케이션 상태 소스입니다. 다른 저장소를 쓰는 단일 노드 설정에서 이동한다면 마이그레이션, 백업, 검증을 별도 작업으로 계획하세요. 애플리케이션 노드를 추가하는 시점이 의도한 공유 데이터베이스가 필요한 데이터를 보유하고 제공하는지 처음 테스트하는 때가 되어서는 안 됩니다.
애플리케이션 HA가 데이터베이스, Redis, 로드 밸런서도 보호하나요?
해당 구성 요소에는 자체 복원력 전략이 필요합니다. Semaphore 다중 노드 애플리케이션 설계가 데이터베이스 장애 조치, 이중화된 부하 분산, 가용한 Redis 서비스를 자동 생성하지는 않습니다. 각 의존 요소의 장애 영역, 복구 절차, 용량 요구 사항을 파악하세요. 클라이언트 요청부터 작업 결과까지 전체 경로를 테스트하여 실행 중인 앱 노드 수뿐 아니라 사람이 사용하는 서비스를 가용성 계획에 포함하세요.
실행 중 작업은 애플리케이션 노드 장애나 업그레이드 중에도 계속되나요?
애플리케이션 노드가 여러 개라는 이유로 진행 중 실행이 중단되지 않는다고 가정하지 마세요. 동작은 실행 경로, 실패한 구성 요소, 운영 중인 릴리스에 따라 달라집니다. 상태 보고와 러너 참여를 포함해 의존하는 작업 수명 주기를 테스트하세요. 마찬가지로 모든 버전 변경을 무중단 롤링 작업이 보장된다고 여기지 말고 업그레이드 호환성과 마이그레이션을 의도적으로 계획하세요. UI 가용성과 작업 연속성은 다른 요구 사항입니다.
어떤 플랜에 HA가 포함되고 어떻게 평가해야 하나요?
고가용성은 Enterprise 기능입니다. 필요한 운영 시간, 유지보수 프로세스, 복구 목표, 기존 데이터베이스 및 로드 밸런서 서비스부터 검토하세요. 문서화된 토폴로지로 부족한 부분을 찾은 다음 대표적인 환경에서 노드 제거, 의존 서비스 복구, 백업을 테스트하세요. 이러한 요구 사항이 비즈니스에 중요하다면 아키텍처 논의가 유용합니다. 단일 기능 스위치가 아니라 전체 배포가 결과를 결정하기 때문입니다.
애플리케이션 노드가 오프라인이 되어도 사용자는 같은 URL을 유지할 수 있나요?
그것이 활성 앱 노드를 하나의 부하 분산 서비스 주소 뒤에 두는 목적입니다. 로드 밸런서는 사용할 수 없는 노드로 요청을 보내지 않아야 하며 HTTP 및 WebSocket 트래픽을 모두 지원해야 합니다. 살아남은 노드도 프로젝트를 제공하려면 공유 데이터베이스, Redis, 일치하는 애플리케이션 설정에 접근해야 합니다.
여러 프라이빗 네트워크에서 작업을 실행하려면 HA가 필요한가요?
아니요. 여러 실행 위치는 러너가 처리합니다. 고가용성은 Semaphore 애플리케이션 계층을, 러너는 작업 실행 위치와 도달 가능한 시스템을 다룹니다. 프로덕션 배포는 공유 UI와 API용 HA 앱 노드 및 프라이빗 인프라 가까이의 프로젝트 러너를 함께 사용할 수 있습니다.