3.5. 이벤트 기반 Ansible API 스케일링 고려 사항
이벤트 기반 Ansible 확장에는 각 서비스 유형에 대한 고려 사항이 포함됩니다.
- API 및 WebSocket 서비스
- EventStream 서비스
/api/eda 및 / 으로 라우팅되는 API 요청은 두 개의 별도의 api/eda -event-streamGunicorn 배포에 의해 처리됩니다. OpenShift Container Platform에서는 이러한 서비스를 독립적으로 스케일링해야 합니다. VM 기반 설치 및 컨테이너 기반 설치의 경우 하이브리드 노드 수를 늘림으로써 이러한 서비스를 함께 확장할 수 있습니다.
3.5.1. 이벤트 기반 Ansible API 및 WebSocket 서비스 링크 복사링크가 클립보드에 복사되었습니다!
이벤트 기반 Ansible API 서비스는 이벤트 기반 Ansible의 사용자 역할 정보, 프로젝트 생성, 활성화 및 결과 확인 등 애플리케이션에 대한 HTTP 요청을 처리합니다. API 서비스의 주요 성능 지표에는 다음이 포함됩니다.
-
/api/eda아래의 요청에 대한 높은 API 대기 시간 - API Pod/노드에서 CPU 사용률이 높습니다.
-
서비스가 상태 점검에 너무 사용 중이므로 플랫폼 게이트웨이에서
503오류를 반환합니다.
WebSocket 서비스는 API 서비스와 함께 배포하여 룰북 활성화의 출력을 관리합니다. 각 활성화는 이 서비스에 대한 지속적인 WebSocket 연결을 유지 관리하여 상태를 전달하고 지침을 수신합니다. 많은 수의 활성화 또는 활성화의 많은 양의 출력이 WebSocket 서버를 압도하여 실패로 이어질 수 있습니다.
이벤트 기반 Ansible API 및 WebSocket 서비스를 확장하려면 다음 전략을 고려하십시오.
-
OpenShift Container Platform: WebSocket 서버(Daphne)는
eda-apiPod 내에서 실행됩니다.eda-api배포를 수평으로 확장하여 이 서비스를 확장합니다.
실행 중인 활성화 수에 따라 eda-api 배포를 스케일링해야 합니다.
- VM 기반 설치 또는 컨테이너 기반 설치: 하이브리드 노드를 추가하여 API 서비스와 함께 WebSocket 서비스를 수평적으로 확장합니다. 이렇게 하면 모든 이벤트 기반 Ansible 구성 요소의 용량이 동시에 증가합니다.
WebSocket 서비스에서 배포에 병목 현상이 발생했는지 여부를 확인하려면 활성화 로그에 다음 오류가 있는지 확인합니다.
ansible_rulebook.websocket - WARNING - websocket aborted by <class 'websockets.exceptions.InvalidMessage'>: did not receive a valid HTTP response
ansible_rulebook.cli - ERROR - Terminating: did not receive a valid HTTP response
3.5.2. 이벤트 기반 Ansible EventStream 서비스 링크 복사링크가 클립보드에 복사되었습니다!
/api/eda-event-stream 에 대한 POST 요청을 처리하는 Event Stream API는 외부 소스에서 이벤트를 가져오도록 설계된 별도의 Gunicorn 서비스입니다. 대기 시간이 길거나 처리량이 낮거나 가용성 문제가 있는 이 서비스의 성능이 저하되는 경우 이를 확장해야 합니다. Pod가 너무 바빠서 상태 점검에 응답하기 위해 플랫폼 게이트웨이에서 이 서비스에 대한 503 오류를 반환합니다.
Event-Driven Ansible EventStream 서비스를 확장하려면 다음 전략을 고려하십시오.
-
OpenShift Container Platform: 기본 eda-
api 배포에서 별도로 관리되므로 전용Horizontally 확장합니다.eda-event-stream작업자 배포를 - VM 기반 설치 또는 컨테이너 기반 설치: 하이브리드 노드를 더 추가하여 이 서비스를 Horizontally 확장하여 모든 이벤트 기반 Ansible 구성 요소에 대한 용량을 동시에 늘립니다.