배포 및 유지보수 / 아키텍처, 확장 및 리소스 제한
이 문서에서는 DataFlux Func의 전체 아키텍처와 처리 능력을 높이기 위한 확장 방법을 주로 소개합니다.
1. 아키텍처
시스템 내부는 전형적인 '생산자 -> 소비자' 모델입니다. Python 함수가 실행될 때마다 '작업 생성 -> 대기열에 넣기 -> 대기열에서 꺼내기 -> 실행 -> 결과 반환'의 흐름을 거칩니다.
모든 Python 함수는 실제로 먼저 '작업'으로 래핑되어 해당 '작업 대기열'(#0부터 번호 지정)에 들어간 다음, 해당 '작업 단위'(worker-0부터 번호 지정)가 대기열에서 꺼내 실행합니다.
flowchart TB
USER[사용자]
FUNC_SERVER[Func Server 서비스]
REDIS_QUEUE_N[Redis 대기열 #N]
FUNC_WORKER_N[Func Worker-N 서비스]
FUNC_BEAT[Func Beat 서비스]
USER --HTTP 요청--> FUNC_SERVER
FUNC_SERVER --함수 실행 작업 대기열에 넣기--> REDIS_QUEUE_N
REDIS_QUEUE_N --함수 실행 작업 대기열에서 꺼내기--> FUNC_WORKER_N
FUNC_BEAT --"함수 실행 작업 대기열에 넣기
(예약 작업)"--> REDIS_QUEUE_N1.1 서비스 및 용도
DataFlux Func는 여러 서비스를 포함하며, 각 서비스마다 서로 다른 역할이 있습니다. 구체적인 서비스는 다음과 같습니다:
| 서비스 | 용도 |
|---|---|
| server | 웹 서비스로, 다음 기능을 제공합니다: 1. 웹 인터페이스 2. API 인터페이스 3. 구독자 유지보수 |
| worker-{대기열 번호} | 사용자 스크립트를 실행하는 작업 단위로, 다음을 포함합니다: 1. 함수 API 2. 함수 API 3. 예약 작업 또한 일부 시스템 수준 백그라운드 작업도 처리합니다 자세한 내용은 대기열 설명 참조 |
| beat | 예약 작업 트리거 |
| mysql | 데이터베이스 |
| redis | 캐시 / 함수 실행 작업 대기열 |
1.2 작업 단위와 대기열 수신 관계
서비스 worker-{대기열 번호}(작업 단위)의 경우, 각 Worker 서비스는 특정 여러 대기열만 수신합니다:
대기열과 작업 단위가 반드시 일대일 대응일 필요는 없음
대기열과 작업 단위는 반드시 일대일 대응일 필요는 없습니다. 예를 들어 작업 단위 worker-0은 대기열 #0의 작업만 수신할 수 있는 것이 아니라, 각 작업 단위는 임의의 하나 또는 여러 대기열을 수신할 수 있습니다.
또한, 동일한 대기열을 여러 작업 단위가 동시에 수신할 수도 있고, 수신되지 않을 수도 있습니다(권장하지 않음).
독립 배포 Func와 데이터 플랫폼 부속 Func의 대기열이 다름
대부분의 독립 배포 Func는 비교적 가볍게 사용되므로, 불필요한 리소스 소모를 줄이기 위해 독립 배포 Func의 작업 단위 수는 대기열 수보다 적습니다.
반대로, 데이터 플랫폼 부속 Func는 모니터, 메시지 전송 모듈(Message Desk) 등 고부하 업무를 담당하므로 작업 단위와 대기열이 일대일 대응이며, 독립 배포 Func보다 더 많은 번호의 작업 단위와 대기열이 존재합니다.
| 작업 단위 | 대기열 독립 배포 |
대기열 데이터 플랫폼 부속 |
|---|---|---|
| worker-0 | #0, #4, #7, #8, #9 | #0 |
| worker-1 | #1 | #1 |
| worker-2 | #2 | #2 |
| worker-3 | #3 | #3 |
| worker-4 | - | #4 |
| worker-5 | #5 | #5 |
| worker-6 | #6 | #6 |
| worker-7 | - | #7 |
| worker-8 | - | #8 |
| worker-9 | - | #9 |
| worker-10 | - | #10 |
| worker-11 | - | #11 |
| worker-12 | - | #12 |
| worker-13 | - | #13 |
| worker-14 | - | #14 |
| worker-15 | - | #15 |
| 작업 단위 | 대기열 독립 배포 |
대기열 데이터 플랫폼 부속 |
|---|---|---|
| worker-0 | #0, #4, #7, #8, #9 | #0 |
| worker-1 | #1 | #1 |
| worker-2 | #2 | #2 |
| worker-3 | #3 | #3 |
| worker-4 | - | #4 |
| worker-5 | #5 | #5 |
| worker-6 | #6 | #6 |
| worker-7 | - | #7 |
| worker-8 | - | #8 |
| worker-9 | - | #9 |
| 작업 단위 | 대기열 |
|---|---|
| worker-0 | #0 |
| worker-1-6 | #1, #2, #3, #4, #5, #6 |
| worker-7 | #7 |
| worker-8-9 | #8, #9 |
2. 서비스 / 대기열 및 역할과 확장 권장 사항
확장에는 더 많은 하드웨어 투자가 필요합니다
확장하려면 해당 서버가 더 높은 성능 요구 사항을 충족해야 하며, 여기에는 서버 자체, 데이터베이스 서비스, Redis 등이 포함되지만 이에 국한되지 않습니다.
일반적으로 DataFlux Func의 확장은 실제로 해당 서비스의 복제본 수를 늘리기만 하면 됩니다. 따라서 사용자는 먼저 자신의 실제 업무 상황을 파악하여 그에 맞게 확장해야 합니다.
전체 서비스, 대기열, 그 역할 및 확장 권장 사항은 다음과 같습니다.
| 서비스 / 대기열 | 역할 독립 배포 |
역할 데이터 플랫폼 부속 |
기본 Pod 수 데이터 플랫폼 부속 |
확장 권장 사항 |
|---|---|---|---|---|
| server | Web 서비스로 다음 기능을 제공합니다: 1. Web 인터페이스 2. API 인터페이스 3. 구독기 유지보수 |
← 왼쪽과 동일 | 1 | 일반적으로 확장할 필요 없음 |
| server-inner | (해당 서비스 없음) | 클러스터 내부에서 API를 호출하기 위한 전용 Web 서비스 | 1 | 일반적으로 확장할 필요 없음 |
| worker-0 대기열 #0 |
시스템 작업 단위로 사용자 코드 처리에 직접 관여하지 않습니다 | ← 왼쪽과 동일 | 2 | 일반적으로 확장할 필요 없음 |
| worker-1 대기열 #1 |
동기 실행되는 함수 API의 함수 작업을 실행합니다 | ← 왼쪽과 동일 | 1 | 동기 실행되는 함수 API의 동시 처리량을 높여야 할 때 확장할 수 있습니다 |
| worker-2 대기열 #2 |
예약 작업의 함수 작업을 실행합니다 | ← 왼쪽과 동일 | 1 | 예약 작업의 동시 처리량을 높여야 할 때 확장할 수 있습니다 |
| worker-3 대기열 #3 |
비동기 실행되는 함수 API의 함수 작업을 실행합니다 | ← 왼쪽과 동일 | 1 | 비동기 실행되는 함수 API의 동시 처리량을 높여야 할 때 확장할 수 있습니다 |
| worker-4 대기열 #4 |
(예약) | (예약) | 0 | 확장할 필요 없음 |
| worker-5 대기열 #5 |
디버그 코드 실행 즉 Web 인터페이스에서 함수를 직접 실행합니다 |
← 왼쪽과 동일 | 1 | 더 많은 사용자가 동시에 스크립트를 개발할 수 있도록 지원해야 할 때 확장할 수 있습니다 |
| worker-6 대기열 #6 |
커넥터 구독 메시지 처리의 함수 작업을 실행합니다 | ← 왼쪽과 동일 | 1 | 커넥터 구독 메시지 처리의 동시 처리량을 높여야 할 때 확장할 수 있습니다 |
| worker-7 대기열 #7 |
(예약) | 데이터 플랫폼 시스템 업무의 함수 작업을 실행합니다 예: 데이터 플랫폼 백엔드 관리자 로그인, 각종 캐시 업데이트, 메시지 집계 풀 해제 등 |
2 | 모니터 총수량이 많을 때 확장할 수 있습니다 |
| worker-8 대기열 #8 |
(예약) | 데이터 플랫폼 임계값 감지 등 일반 모니터, 지표 생성 등 관련 함수 작업을 실행합니다 | 5 | 일반 모니터 수량이 많을 때 확장할 수 있습니다 |
| worker-9 대기열 #9 |
(예약) | 데이터 플랫폼 고급 감지, 스마트 모니터링 함수 작업을 실행합니다 | 3 | 고급 감지, 스마트 모니터가 많을 때 확장할 수 있습니다 |
| worker-10 대기열 #10 |
(해당 서비스 없음) | 데이터 플랫폼에서 사용자가 보고한 이벤트를 수신하는 함수 작업을 실행합니다 | 1 | 사용자 보고 이벤트량이 많을 때 확장할 수 있습니다 |
| worker-11 대기열 #11 |
(해당 서비스 없음) | Message Desk 메시지 전송 작업을 실행합니다 | 3 | 메시지 전송량이 많을 때 확장할 수 있습니다 |
| worker-12 대기열 #12 |
(해당 서비스 없음) | (예약) | 0 | 확장할 필요 없음 |
| worker-13 대기열 #13 |
(해당 서비스 없음) | (예약) | 0 | 확장할 필요 없음 |
| worker-14 대기열 #14 |
(해당 서비스 없음) | 사용자 조작에 즉시 응답해야 하는 AI 관련 처리를 실행합니다 예: 'Pipeline 자동 작성' 호출 등 |
2 | 동시에 Pipeline을 작성하는 사용자가 많을 때 확장 |
| worker-15 대기열 #15 |
(해당 서비스 없음) | 사용자 조작에 즉시 응답할 필요가 없는 AI 관련 처리를 실행합니다 예: '알람 압축 병합' 처리 호출 등 |
2 | AI로 알람을 집계하는 모니터가 많을 때 확장 |
| beat | 예약 작업의 트리거 | ← 동일 | 1 | 확장 금지, 전역 단일 복제본 보장 |
| mysql | 데이터베이스 | (해당 서비스 없음) | - | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스를 선택할 수 있습니다 |
| redis | 캐시 / 함수 실행 작업 대기열 | (해당 서비스 없음) | - | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스를 선택할 수 있습니다 |
| 서비스 / 대기열 | 역할 독립 배포 |
역할 데이터 플랫폼 부속 |
확장 권장 사항 |
|---|---|---|---|
| server | 웹 서비스, 다음 기능 제공: 1. 웹 인터페이스 2. API 인터페이스 3. 구독자 유지 관리 |
← 동일 | 일반적으로 확장할 필요 없음 |
| server-inner | (해당 서비스 없음) | 클러스터 내부에서 API를 호출하는 전용 웹 서비스 | 일반적으로 확장할 필요 없음 |
| worker-0 대기열 #0 |
시스템 작업 단위, 사용자 코드 처리에 직접 참여하지 않음 | ← 동일 | 일반적으로 확장할 필요 없음 |
| worker-1 대기열 #1 |
동기 실행 함수 API의 함수 작업을 실행합니다 | ← 동일 | 동기 실행 함수 API 동시 처리량을 높여야 할 때 확장 가능 |
| worker-2 대기열 #2 |
예약 작업의 함수 작업을 실행합니다 | ← 동일 | 예약 작업 동시 처리량을 높여야 할 때 확장 가능 |
| worker-3 대기열 #3 |
비동기 실행 함수 API의 함수 작업을 실행합니다 | ← 동일 | 비동기 실행 함수 API 동시 처리량을 높여야 할 때 확장 가능 |
| worker-4 대기열 #4 |
(예약) | (예약) | 확장할 필요 없음 |
| worker-5 대기열 #5 |
디버그 코드 실행 즉, Web 인터페이스에서 함수를 직접 실행 |
← 동일 | 더 많은 사용자가 동시에 스크립트를 개발할 수 있도록 지원해야 할 때 확장 |
| worker-6 대기열 #6 |
커넥터 구독 메시지 처리의 함수 작업을 실행합니다 | ← 동일 | 커넥터 구독 메시지 처리 동시 처리량을 높여야 할 때 확장 가능 |
| worker-7 대기열 #7 |
(예약) | 데이터 플랫폼 시스템 업무, 메시지 전송의 함수 작업을 실행합니다 예: 데이터 플랫폼 백엔드 관리자 로그인, 각종 캐시 업데이트, 메시지 집계 풀 해제, Message Desk 메시지 전송 |
메시지 전송량이 많을 때 확장 |
| worker-8 대기열 #8 |
(예약) | 데이터 플랫폼 임계값 감지 등 일반 모니터 관련 함수 작업을 실행합니다 | 일반 모니터 수가 많을 때 확장 |
| worker-9 대기열 #9 |
(예약) | 데이터 플랫폼 고급 감지, 스마트 모니터링의 함수 작업을 실행합니다 | 일반 고급 감지, 스마트 모니터 수가 많을 때 확장 |
| beat | 예약 작업의 트리거 | ← 동일 | 확장 금지, 전역 단일 복제본 보장 |
| mysql | 데이터베이스 | (해당 서비스 없음) | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스 선택 가능 |
| redis | 캐시 / 함수 실행 작업 대기열 | (해당 서비스 없음) | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스 선택 가능 |
| 서비스 | 역할 | 확장 권장 사항 |
|---|---|---|
| server | 웹 서비스이며 다음 기능을 제공합니다: 1. 웹 인터페이스 2. API 인터페이스 3. 구독 유지 관리 |
일반적으로 확장할 필요 없음 |
| worker-0 대기열 #0 |
시스템 작업 단위이며, 사용자 코드 처리에 직접 참여하지 않습니다 | 일반적으로 확장할 필요 없음 |
| worker-1-6 대기열 #1, #2, #3, #4, #5, #6 |
기본적으로 함수 동기 호출 처리를 담당합니다. 예: 1. 동기 실행 함수 API 2. 구독 메시지 처리 |
동기 실행 함수 API, 구독 메시지 처리의 동시 처리량을 높여야 할 때 확장 가능 |
| worker-7 대기열 #7 |
기본적으로 디버그 코드 처리를 담당합니다(즉, 웹 인터페이스에서 함수를 직접 실행) | 더 많은 사용자가 동시에 스크립트를 개발할 수 있도록 지원해야 할 때 확장 |
| worker-8-9 대기열 #8, #9 |
기본적으로 함수 비동기 호출 처리를 담당합니다. 예: 1. 비동기 실행 함수 API 2. 예약 작업 |
예약 작업, 비동기 실행 함수 API의 동시 처리량을 높여야 할 때 확장 |
| beat | 예약 작업의 트리거 | 확장 금지, 전역 단일 복제본 보장 |
| mysql | 데이터베이스 | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스 선택 가능 |
| redis | 캐시 / 함수 실행 작업 대기열 | 확장할 필요 없음, 더 높은 요구 사항이 있으면 자체 구축 또는 클라우드 서비스 선택 가능 |
예시: 예약 작업의 처리 능력을 강화해야 할 때...
위에서 알 수 있듯이, 예약 작업은 대기열 #8에 있고, 대기열 #8은 서비스 worker-8에 해당합니다. 따라서 서비스 worker-8을 확장하면 됩니다.
확장량 산정
일반적인 worker-8을 예로 들면:
worker-8은 데이터 플랫폼 부속 버전에서 주로 모니터 작업 실행을 담당합니다. 한 번의 검사 작업에 T 밀리초가 필요하다면, 1분에 60 × 1,000 ÷ T회 검사를 실행할 수 있습니다. 기본적으로 worker-8은 Pod당 5개의 프로세스를 시작합니다.
즉, 단일 worker-8 Pod의 검사 능력은 5 × (60 × 1,000 ÷ T)개의 모니터입니다.
공식
| Text Only | |
|---|---|
1 2 | |
A: 검사 능력
T: 검사 작업 실행 소요 시간(밀리초)
모니터가 실행될 때마다 소요 시간이 다르므로 아래와 같은 표로 정리할 수 있습니다.
| 단일 검사 소요 시간 | 단일 Pod 검사 능력 | 기준 대비 |
|---|---|---|
| 300 | 1,000 | 167% |
| 500 | 600 | 기준 |
| 800 | 375 | 63% |
| 1,000 | 300 | 50% |
| 2,000 | 150 | 25% |
| 3,000 | 100 | 17% |
반대로, 모니터 총 수가 M이라고 가정하면, 필요한 Pod 수는 M ÷ (5 × (60 × 1,000 ÷ T))로 구할 수 있습니다.
공식
| Text Only | |
|---|---|
1 2 | |
P: 필요한 Pod 수
M: 모니터 수
T: 검사 작업 실행 소요 시간(밀리초)
모니터 수와 실행할 때마다 소요 시간에 따라 아래와 같은 표로 정리할 수 있습니다.
| 모니터 수 | 단일 검사 소요 시간 | 필요한 Pod 수 | 기준 대비 |
|---|---|---|---|
| 1,000 | 300 | 1 | 50% |
| 1,000 | 500 | 2 | 기준 |
| 1,000 | 800 | 3 | 150% |
| 1,000 | 1,000 | 4 | 200% |
| 1,000 | 2,000 | 7 | 350% |
| 1,000 | 3,000 | 10 | 500% |
| 모니터 수 | 단일 검사 소요 시간 | 필요한 Pod 수 | 기준 대비 |
|---|---|---|---|
| 5,000 | 300 | 5 | 56% |
| 5,000 | 500 | 9 | 기준 |
| 5,000 | 800 | 14 | 156% |
| 5,000 | 1,000 | 17 | 189% |
| 5,000 | 2,000 | 34 | 378% |
| 5,000 | 3,000 | 50 | 556% |
| 모니터 수 | 단일 검사 소요 시간 | 필요한 Pod 수 | 기준 대비 |
|---|---|---|---|
| 10,000 | 300 | 10 | 59% |
| 10,000 | 500 | 17 | 기준 |
| 10,000 | 800 | 27 | 159% |
| 10,000 | 1,000 | 34 | 200% |
| 10,000 | 2,000 | 67 | 394% |
| 10,000 | 3,000 | 100 | 588% |
작업 방법
단일 서버에 배포된 DataFlux Func는 설정({설치 디렉터리}/docker-stack.yaml)을 수정하고 해당 서비스의 deploy.replicas를 추가하여 확장할 수 있습니다.
공식 문서를 참조하세요
deploy.replicas 옵션에 대한 자세한 정보는 Docker 공식 문서를 참조하세요: Docker Documentation / Compose file deploy reference / replicas
worker-8의 처리 능력 향상을 예로 들면, 구체적인 수정 부분은 다음과 같습니다.
예시는 일부만 발췌한 것입니다
예시는 핵심 수정 부분만 보여줍니다. 실제 작업 시에는 구성을 완전하게 갖추도록 주의하세요.
| docker-stack.yaml 핵심 수정 부분 | |
|---|---|
1 2 3 4 5 | |
3. 리소스 제한
리소스 제한은 실제 업무에 따라 합리적으로 조정해야 합니다
실제 업무에 따라 리소스 제한을 합리적으로 조정하세요.
무작정 리소스를 제한하면 작업 실행 시간이 길어지거나 메모리가 부족하여 코드 실행을 완료하지 못할 수 있습니다.
작업 방법
단일 서버에 배포된 DataFlux Func는 설정({설치 디렉터리}/docker-stack.yaml)을 수정하고 해당 서비스의 deploy.resources를 추가하여 리소스를 제한할 수 있습니다.
공식 문서를 참조하세요
deploy.resources 옵션에 대한 자세한 정보는 Docker 공식 문서를 참조하세요: Docker Documentation / Compose file deploy reference / resources
기본적으로 각 worker-N 복제본은 최대 5개의 CPU 코어를 모두 사용합니다(즉, 각 작업 단위에는 5개의 작업 프로세스가 있습니다).
worker-8의 리소스 사용을 제한하는 예를 들면, 구체적인 수정 부분은 다음과 같습니다.
예시는 일부만 발췌한 것입니다
예시는 핵심 수정 부분만 보여줍니다. 실제 작업 시에는 구성을 완전하게 갖추도록 주의하세요.
| docker-stack.yaml 핵심 수정 부분 | |
|---|---|
1 2 3 4 5 6 7 | |
4. 작업 단위 분리
새 버전에서는 모든 작업 단위가 이미 분리되어 있습니다
독립 배포 Func 3.2.0 이상 버전에서는 기본적으로 모든 예약되지 않은 작업 단위가 분리되어 있으며, 사용자는 필요에 따라 예약된 대기열을 활성화할 수 있습니다.
데이터 플랫폼 부속 Func 1.77.145 이상 버전에서는 기본적으로 모든 작업 단위가 이미 분리되어 있으며, 사용자가 직접 분리할 필요가 없습니다.
특수한 경우, 기본적으로 병합된 작업 단위(예: worker-1-6)를 분리하여 더 세밀한 작업 스케줄링을 구현하고, 특정 대기열을 담당하는 작업 단위에 대한 확장과 리소스 제한을 구현할 수 있습니다.
업무 요구에 따라 DataFlux Func가 구독 처리에 대한 성능 요구가 높고, 구독 메시지 처리가 동기적으로 실행되는 함수 API 처리와 서로 간섭하지 않기를 원한다면, worker-1-6을 worker-1-5와 worker-6으로 분리할 수 있습니다.
작업 방법
단일 서버에 배포된 DataFlux Func는 설정({설치 디렉터리}/docker-stack.yaml)을 수정하고, 해당 서비스를 추가 및 수정하고, command에서 지정한 대기열 번호를 수정하여 작업 단위 분리를 구현할 수 있습니다.
작업 단위가 수신하는 대기열은 ./run-worker-by-queue.sh 뒤의 매개변수로 지정하며, 서비스 이름 자체는 주로 표시용으로 사용되므로 실제 수신 대기열과 일치시키는 것을 권장합니다. 혼란을 방지하기 위해서입니다.
예시는 일부만 발췌한 것입니다
예시는 핵심 수정 부분만 보여줍니다. 실제 작업 시에는 구성을 완전하게 갖추도록 주의하세요.
| docker-stack.yaml 핵심 수정 부분 | |
|---|---|
1 2 3 4 5 6 7 8 9 10 | |