최신 애플리케이션에서는 지속적인 연결이 핵심이며, 특히 백엔드 서비스에 의존하는 모바일 앱의 경우 더욱 그렇습니다. 이 블로그에서는 앱 서비스 서버의 상태를 모니터링하고 필요한 경우 보조 서버로 자동 페일오버하는 Python 기반 솔루션을 살펴보겠습니다. 이 샘플 코드는 HTTP 상태 확인과 WebSocket 연결 엔드포인트를 사용하여 애플리케이션이 항상 정상 서비스에 연결되도록 합니다.
개요
이 솔루션에는 두 가지 유형의 엔드포인트가 포함됩니다:
-
- 상태 확인 URL
- 이러한 엔드포인트(예,
https://.../_ping
)를 사용하여 폴링합니다. HTTP HEAD 요청. - 앱 서비스 서버가 정상인지 확인합니다.
- 이러한 엔드포인트(예,
- 연결 엔드포인트
- 웹소켓 URL(예,
wss://.../primary
)를 사용하여 애플리케이션이 백엔드와 상호 작용하는 데 사용합니다. - 활성 연결 엔드포인트는 상태 확인 결과에 따라 업데이트됩니다.
- 웹소켓 URL(예,
- 상태 확인 URL
기본 서버의 상태 확인에 연속적으로 실패하면 장애 조치 로직이 애플리케이션의 연결을 보조 서버로 전환합니다.
코드 상세 정보
아래는 인라인 주석과 자세한 설명이 포함된 전체 코드입니다:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 |
가져오기 로깅 가져오기 스레딩 가져오기 요청 에서 시간 가져오기 수면 # 정보 수준에서 타임스탬프가 찍힌 메시지를 표시하도록 로깅을 구성합니다. 로깅.기본 구성(레벨=로깅.정보, 형식='%(asctime)s %(levelname)s: %(메시지)s') # -------------------------------------- # 상태 확인 URL(앱 서비스 서버) # -------------------------------------- # 이 URL은 HEAD 요청을 전송하여 서버의 상태를 확인하는 데 사용됩니다. health_check_urls = { "primary": "https://XXXXXXXXXXXXXX.apps.cloud.couchbase.com:4984/_ping", "secondary": "https://XXXXXXXXXXXXXX.apps.cloud.couchbase.com:4984/_ping" } # ------------------------------------- # 연결 엔드포인트(웹소켓 URL) # ------------------------------------- # 이러한 엔드포인트는 애플리케이션이 실제로 연결에 사용하는 것입니다. connection_urls = { "primary": "wss://XXXXXXXXXXXX.apps.couchbase.com:4984/primary", "secondary": "wss://XXXXXXXXXXXX.apps.cloud.ucouchbase.com:4984/secondary" } # 변수 `active_cluster`는 현재 활성화된 서버를 추적합니다. active_cluster = "primary" # 이 변수에는 애플리케이션에서 사용하는 실제 웹소켓 URL이 저장됩니다. 활성_연결_URL = connection_urls[active_cluster] def is_cluster_healthy(URL): """ 제공된 URL에 대해 HEAD 요청을 사용하여 상태 확인을 수행합니다. 응답 상태가 200이면 True를 반환하고, 그렇지 않으면 False를 반환합니다. 문제 해결을 위한 상태 코드와 헤더를 기록합니다. """ 시도: 응답 = 요청.head(URL, 시간 초과=5) 로깅.정보(f"{url}에 대한 상태 확인 응답") 로깅.정보(f" 상태 코드: {response.status_code}") 로깅.정보(" 헤더:") 에 대한 헤더, 값 in 응답.헤더.항목(): 로깅.정보(f" {header}: {값}") 만약 응답.상태_코드 == 200: 로깅.정보(f"{URL}은 건강합니다!") 반환 True else: 로깅.경고(f"{URL}이(가) 건강하지 않거나 연결할 수 없습니다.") 반환 False 예외 요청.예외.요청 예외 as e: 로깅.오류(f"{url}에 대한 상태 확인에 실패했습니다: {e}") 반환 False def 건강_체크_근로자(): """ 3초마다 활성 서버의 상태를 확인하는 백그라운드 워커입니다. 활성 서버가 9회 이상 연속으로 상태 확인에 실패하는 경우, 작업자가 다른 서버로 전환을 시도합니다. """ 글로벌 활성_클러스터 글로벌 활성 연결_URL 연속_실패 = 0 동안 True: 수면(3) # 확인 사이에 3초간 기다립니다. # 활성 클러스터에 대해 HTTP 상태 확인 엔드포인트를 사용합니다. 현재_건강_URL = health_check_urls[active_cluster] 로깅.정보(f"상태 확인 중입니다: 현재_건강_URL}에서 {active_cluster} 확인 중...") 만약 is_cluster_healthy(현재_건강_URL): 연속_실패 = 0 # 건강한 경우 카운터를 초기화합니다. else: 연속_실패 += 1 로깅.경고(f"{active_cluster} 상태 확인에 {연속_실패} 횟수만큼 실패했습니다.") # 실패 시도가 연속 9회를 초과하면 장애 조치를 시도합니다. 만약 연속_실패 > 9: 로깅.오류(f"{active_cluster}가 다운된 것으로 간주됩니다. 장애 조치를 시도하는 중입니다...") # 새 활성 클러스터를 결정합니다. new_cluster = "secondary" 만약 active_cluster == "primary" else "primary" new_health_url = health_check_urls[new_cluster] # 새 클러스터가 정상인지 확인합니다. 만약 is_cluster_healthy(new_health_url): active_cluster = new_클러스터 # 연결 엔드포인트를 업데이트합니다. 활성_연결_URL = connection_urls[new_cluster] 로깅.경고(f"활성 클러스터를 {new_cluster}로 전환했습니다.") 로깅.경고(f"새 웹소켓 연결 엔드포인트: {active_connection_url}") else: 로깅.중요("두 클러스터가 모두 다운된 것 같습니다!") 연속_실패 = 0 # 시도 후 실패 카운터를 초기화합니다. def 메인(): """ 백그라운드 스레드에서 상태 확인 워커를 시작하는 주요 기능입니다. 중단될 때까지 스크립트를 무기한 실행합니다. """ 스레드 = 스레딩.스레드(대상=건강_체크_근로자, daemon=True) 스레드.시작() 로깅.정보("상태 확인 작업자가 시작되었습니다. 종료하려면 Ctrl+C를 누르세요.") 로깅.정보(f"애플리케이션이 처음에 연결됩니다: {active_connection_url}") 시도: 동안 True: 수면(1) # 메인 스레드가 살아 있습니다. 예외 키보드 인터럽트: 로깅.정보("상태 확인 스크립트 종료 중") 만약 __이름__ == "__main__": 메인() |
주요 기술 포인트
-
- 앱 서비스 서버의 상태 확인:
이 코드는 상태 확인 엔드포인트 (모니터링에 사용됨)에서 연결 엔드포인트 (애플리케이션에서 사용). 이를 통해 안정적인 연결 엔드포인트를 유지하면서 서버 상태를 독립적으로 확인할 수 있습니다. - HTTP 헤드 요청:
사용 HEAD 요청에 대한/_ping
엔드포인트는 데이터 전송을 최소화하는 동시에 진단을 위한 상태 코드와 헤더를 제공합니다. - 백그라운드 스레드:
그리고건강_체크_근로자
는 자체 데몬 스레드에서 실행되므로 메인 애플리케이션 스레드를 차단하지 않고도 지속적인 상태 모니터링이 가능합니다. - 장애 조치 로직:
- 카운터(
연속_실패
)는 연속적인 실패를 추적합니다. - 횟수가 설정된 임계값(9회 실패)을 초과하면 스크립트에서 대체 서버의 상태를 확인하여 장애 조치를 시도합니다.
- 보조 서버에서 상태 확인에 성공하면 활성 연결 엔드포인트가 업데이트됩니다.
- 카운터(
- 로깅:
상세 로깅은 HTTP 응답 상태, 헤더, 장애 조치 이벤트 등 상태 확인 프로세스에 대한 인사이트를 제공합니다. 이는 문제 해결 및 모니터링에 도움이 됩니다.
- 앱 서비스 서버의 상태 확인:
애플리케이션에 맞게 조정하기
-
- 이 코드를 애플리케이션의 요구 사항에 맞게 Swift, Kotlin 등 원하는 프로그래밍 언어로 쉽게 번역하고 조정할 수 있습니다.
- 이 스크립트나 로직을 다음과 같이 통합할 수 있습니다. 모바일 코드 (iOS/안드로이드) 또는 백엔드 서비스 를 업데이트하는 활성 엔드포인트.
- iOS 또는 Android를 사용하는 경우 이 코드를 실행하는 빈도와 위치를 고려하세요. 예를 들어 백그라운드 작업이나 푸시 알림은 모바일 컨텍스트에서 상태 확인을 트리거할 수 있습니다.
- 마이크로서비스 아키텍처를 사용하는 경우, 이 장애 조치 로직을 소규모 서비스에서 실행할 수 있습니다. 현재 활성 URL 를 모바일 앱에 추가하여 항상 올바른 WSS 엔드포인트에 연결되도록 합니다.
결론
이 샘플 코드는 기본 서버에 연결할 수 없게 되면 자동으로 백업 서버로 장애 조치하여 애플리케이션의 고가용성을 보장하는 간단하면서도 강력한 메커니즘을 제공합니다. 연결 엔드포인트에서 상태 검사를 분리함으로써 애플리케이션이 항상 WebSocket을 통해 정상 서버에 연결되도록 보장합니다.
프로덕션 환경에서는 특정 요구 사항, 네트워크 조건 및 보안 정책에 맞게 로직을 조정하고 확장해야 할 수 있습니다.
모바일 애플리케이션이나 백엔드 서비스에 이 로직을 구현하면 가동 시간과 복원력을 크게 개선하여 예기치 않은 서비스 중단 중에도 사용자가 계속 연결 상태를 유지할 수 있습니다.