AFE-E630에서의 EMS Builder 성능 테스트 보고서
보고서 버전: v1.3
테스트 날짜: 2026-07-29
보고서 날짜: 2026-07-30
통계 기준: 시나리오별 2,002회 수집 후 첫 번째와 마지막 샘플을 제외하고sample_no=2～2001의 유효 리소스 샘플 2,000개만 집계
관련 설명서: Edge-EMS Builder 성능 테스트 설명서
1. 성능 결과 개요
섹션 제목: “1. 성능 결과 개요”데이터 수집 설정량
집계 연산
Trigger 목표
MQTT 작업 목표
협업 작업
최대 10초 이내 저장
전체 장치 CPU 평균 / P95
전체 장치 메모리 평균 / P95
Trigger P95
MQTT P95
Trigger 1회 실행에는 장치 제어 1회, 로컬 알람과 MQTT 알람 각 1회 및 집계 데이터 쓰기 1회가 포함됩니다. Edge-EMS Builder는 장치 메모리에 따라 PostgreSQL에 리소스를 할당하므로 장치, 데이터베이스 규모 및 캐시 상태에 따라 메모리 사용량이 크게 다를 수 있습니다.
1.1 핵심 결론
섹션 제목: “1.1 핵심 결론”AFE-E630은 S3.5 시나리오로 운영하는 것이 좋습니다. 초당 5,000포인트, 집계 연산 30개, Trigger 초당 90회, MQTT 초당 20회, 협업 작업 초당 10회 및 10초 변경 기반 저장을 사용합니다.
S3.5의 실측 Trigger는 초당 89.97회, MQTT는 초당 19.98회이며, Trigger / MQTT P95는 각각 56 ms와 77 ms입니다. 전체 CPU P95는 71.09%, 실제 메모리 P95는 41.41%이며 샘플링 제한 시간 초과는 발생하지 않았습니다.
장기 운영 환경에서는 S3.5 실측 부하에서 약 20%의 엔지니어링 여유를 확보하고 초기 용량을 약 초당 4,000포인트, Trigger 초당 72회, MQTT 초당 16회, 협업 작업 초당 8회 이하로 계획하는 것이 좋습니다. 이는 실측 설정을 환산한 엔지니어링 권장값이며 별도로 실행한 테스트 시나리오가 아닙니다. 정식 운영 전에는 실제 프로젝트 스크립트, 메시지 크기 및 이력 데이터 규모로 다시 테스트해야 합니다.
1.2 시나리오별 상태
섹션 제목: “1.2 시나리오별 상태”| 아이콘 | 시나리오 | 결론 |
|---|---|---|
| 🟢 | S1 | 기준 시나리오 통과, 리소스와 작업 지연 시간 모두 충분한 여유가 있음. |
| 🟢 | S2 | 통과. 실시간 저장에서 초당 2,000포인트가 안정적으로 실행되었으며 샘플링 제한 시간 초과 1회 발생. |
| 🟢 | S2.5 | 통과. 변경 기반 저장으로 S2보다 CPU 부하가 크게 감소했으며 샘플링 제한 시간 초과 없음. |
| 🟡 | S3 | 작업 지표는 통과했지만 전체 CPU P95가 81.06%로 지속 운영 한계에 가깝고 샘플링 제한 시간 초과 2회 발생. |
| 🟢 | S3.5 | 종합 성능이 가장 우수하여 현재 AFE-E630 권장 시나리오로 선정. |
| 🔴 | S6 | 단시간 부하 사전 점검에만 적합. 전체 CPU P95 94.02%, MQTT 처리량은 99% 권장선 미만이며 샘플링 제한 시간 초과 11회 발생. |
2. 결론 요약
섹션 제목: “2. 결론 요약”- 이번 테스트는 S1, S2, S2.5, S3, S3.5 및 S6의 여섯 시나리오를 포함하며, 다른 시나리오는 표, 비교 및 결론에 포함하지 않습니다.
- S3.5는 초당 5,000포인트의 설정 부하에서 Trigger 달성률 99.97%, MQTT 달성률 99.90%를 기록했습니다. Trigger / MQTT P95는 각각 56 ms와 77 ms입니다.
- S3와 S3.5의 업무 부하는 같습니다. 변경 기반 저장을 활성화하면 전체 CPU 평균이 57.95%에서 50.16%로, P95가 81.06%에서 71.09%로 감소하여 지속 운영에 더 적합합니다.
- S6의 Trigger 달성률은 99.49%지만 MQTT 달성률은 98.73%입니다. 전체 CPU P95는 94.02%, 최고값은 100%에 도달하므로 지속적인 운영 설정으로 권장하지 않습니다.
- 모든 시나리오의 Trigger 전체 P99는 200 ms 미만이지만 약 10~12초의 개별 긴 지연이 발생했습니다. S6의 MQTT P99는 236.62 ms로 200 ms를 초과했습니다.
- 각 시나리오는 유효 샘플 2,000초(약 33분 20초)만 보존했습니다. 성능 비교에는 적합하지만 72시간 안정성 테스트를 대체할 수는 없습니다.
3. 통계 기준
섹션 제목: “3. 통계 기준”3.1 샘플 선택
섹션 제목: “3.1 샘플 선택”모니터링은 횟수 기반으로 수행합니다. 각 시나리오의 원본 리소스 데이터에는 sample_no=1～2002가 포함됩니다.
제외: sample_no = 1집계: sample_no = 2～2001, 총 2,000회제외: sample_no = 2002첫 번째와 마지막 샘플을 제외하여 시작과 종료 시 온전한 1초에 미치지 못하는 데이터가 통계에 포함되지 않도록 합니다. Trigger 및 MQTT 전체 결과의 분모는 모두 2,000초입니다. 특정 초에 작업 기록이 없어도 평균 처리량 계산에 포함하여 데이터가 있는 초만 집계할 때의 처리량 과대평가를 방지합니다.
3.2 EMS Builder 전체 범위
섹션 제목: “3.2 EMS Builder 전체 범위”다음 5개 서비스를 합쳐 하나의 완전한 Edge-EMS Builder로 간주합니다.
| 서비스 | 역할 |
|---|---|
cb_core |
데이터 수집 및 핵심 통신 |
cb_nginx |
CommBridge Web / 리버스 프록시 |
cb_backend |
CommBridge 백엔드 |
ems_backend |
EMS Builder 계산, 전략 및 업무 로직 |
ems_postgresql |
EMS Builder 데이터 저장 |
각 sample_no에서 5개 서비스를 먼저 합산한 후 2,000개의 합계 값으로 평균, P95, P99 및 최고값을 계산합니다. 서로 다른 시점의 개별 서비스 최고값을 직접 더하지 않습니다.
3.3 CPU, 메모리 및 작업 지연 시간
섹션 제목: “3.3 CPU, 메모리 및 작업 지연 시간”- 5개 서비스의 원본 CPU 값은 단일 코어 환산 백분율입니다. AFE-E630은 4코어이므로 “Edge-EMS Builder 4코어 환산 CPU” = 5개 서비스 CPU 합계 ÷ 4입니다.
- “전체 장치 CPU”는 워크북의
_system_total를 사용합니다. 전체 CPU 용량을 0~100%로 정규화한 사용률이며 장치 용량 판단의 주요 지표입니다. - “Edge-EMS Builder 귀속 메모리”는 5개 서비스의 cgroup 귀속 메모리 합계입니다. 공유 페이지와 캐시가 중복 귀속될 수 있어 전체 장치의 실제 사용 메모리보다 클 수 있으므로 물리 메모리로 직접 나누어 용량 사용률로 사용할 수 없습니다.
- “전체 장치 실제 메모리”는
MemTotal - MemAvailable로 계산하며 물리 메모리 여유를 판단하는 주요 지표입니다. - Trigger / MQTT의 평균 및 P50, P95, P99는 유효 구간의 전체 작업 기록을 기준으로 하며 초당 평균값의 백분위수가 아닙니다.
- 모든 워크북은 “집계 전 테스트 부하 종료” 검증을 통과했습니다. Trigger, MQTT 및 CommBridge를 집계 전에 종료하고 30초 기다렸습니다.
4. 테스트 대상 및 환경
섹션 제목: “4. 테스트 대상 및 환경”| 항목 | 설정 |
|---|---|
| 장치 모델 | AFE-E630 |
| CPU | Arm Cortex-A55, 4코어 |
| 메모리 | 3.81 GB DDR4 |
| 운영 체제 | Debian 11 기반 JelinaOS |
| 저장 장치 | eMMC |
| 소프트웨어 버전 | CommBridge-rc-2026-07-08T17-52-07, EMS Builder v1.2, PostgreSQL v18.3 |
| 네트워크 | LAN, MQTT / TCP |
| 모니터링 샘플링 | 초당 1회, 시나리오별 2,002회 중 중간 2,000회 집계 |
| 테스트 데이터 출처 | perf_S1_20260729_171807.xlsx, perf_S2_20260729_175426.xlsx, perf_S2.5_20260729_183152.xlsx, perf_S3_20260729_190918.xlsx, perf_S3.5_20260729_194703.xlsx, perf_S6_20260729_202445.xlsx |
5. 시나리오 및 부하
섹션 제목: “5. 시나리오 및 부하”| 시나리오 | 데이터 수집 | 집계 연산 | 일반 Trigger | 100 ms Trigger | Trigger 목표 | MQTT 목표 | 협업 작업 | 저장 정책 |
|---|---|---|---|---|---|---|---|---|
| S1 | 초당 500포인트 | 10 | 초당 10회 | 0 | 초당 10회 | 초당 5회 | 초당 0회 | 실시간 |
| S2 | 초당 2,000포인트 | 20 | 초당 20회 | 2 | 초당 40회 | 초당 10회 | 초당 2회 | 실시간 |
| S2.5 | 초당 2,000포인트 | 20 | 초당 20회 | 2 | 초당 40회 | 초당 10회 | 초당 2회 | 변경 기반 저장(10초) |
| S3 | 초당 5,000포인트 | 30 | 초당 50회 | 4 | 초당 90회 | 초당 20회 | 초당 10회 | 실시간 |
| S3.5 | 초당 5,000포인트 | 30 | 초당 50회 | 4 | 초당 90회 | 초당 20회 | 초당 10회 | 변경 기반 저장(10초) |
| S6 | 초당 5,000포인트 | 20 | 초당 50회 | 10 | 초당 150회 | 초당 30회 | 초당 15회 | 실시간 |
“데이터 수집”은 시나리오의 설정 부하입니다. 현재 워크북에는 포인트별 수집 성공 횟수가 없으므로 설정값을 독립 검증된 데이터베이스 저장 성공 처리량으로 표현할 수 없습니다.
6. 테스트 시간
섹션 제목: “6. 테스트 시간”| 시나리오 | 유효 통계 구간 | 유효 시간 |
|---|---|---|
| S1 | 2026-07-29 17:18:09 ~ 17:51:29 | 2,000초 |
| S2 | 2026-07-29 17:54:29 ~ 18:27:49 | 2,000초 |
| S2.5 | 2026-07-29 18:31:54 ~ 19:05:14 | 2,000초 |
| S3 | 2026-07-29 19:09:20 ~ 19:42:40 | 2,000초 |
| S3.5 | 2026-07-29 19:47:06 ~ 20:20:26 | 2,000초 |
| S6 | 2026-07-29 20:24:47 ~ 20:58:07 | 2,000초 |
모든 시간은 UTC+8입니다.
7. CPU 결과
섹션 제목: “7. CPU 결과”7.1 EMS Builder 5개 서비스 합계(4코어 환산)
섹션 제목: “7.1 EMS Builder 5개 서비스 합계(4코어 환산)”| 상태 | 시나리오 | 평균 | P95 | P99 | 최고값 |
|---|---|---|---|---|---|
| 🟢 | S1 | 13.48% | 23.97% | 41.50% | 62.53% |
| 🟢 | S2 | 28.47% | 48.33% | 56.36% | 67.17% |
| 🟢 | S2.5 | 26.11% | 38.36% | 49.96% | 65.76% |
| 🟡 | S3 | 50.58% | 72.31% | 78.55% | 95.43% |
| 🟢 | S3.5 | 43.50% | 61.27% | 70.93% | 86.75% |
| 🔴 | S6 | 65.95% | 85.87% | 91.61% | 208.59% |
S6의 Edge-EMS Builder 최고값 208.59%는 단일 샘플링 구간의 이상값으로, 5개 서비스의 CPU 시간 합계가 일반적인 4코어 용량을 초과한 경우입니다. 샘플링 제한 시간 초과 11회를 함께 고려하면 샘플링 구간이 여러 주기에 걸치거나 순간적인 스케줄링이 발생했을 가능성이 있으므로 지속 가능한 리소스 사용량으로 간주하지 않습니다.
7.2 전체 장치 CPU(전체 CPU 용량 정규화)
섹션 제목: “7.2 전체 장치 CPU(전체 CPU 용량 정규화)”| 상태 | 시나리오 | 평균 | P95 | P99 | 최고값 |
|---|---|---|---|---|---|
| 🟢 | S1 | 20.22% | 38.67% | 48.57% | 67.70% |
| 🟢 | S2 | 35.88% | 57.58% | 66.41% | 82.42% |
| 🟢 | S2.5 | 32.72% | 45.28% | 57.03% | 75.06% |
| 🟡 | S3 | 57.95% | 81.06% | 89.16% | 98.64% |
| 🟢 | S3.5 | 50.16% | 71.09% | 79.84% | 96.98% |
| 🔴 | S6 | 73.86% | 94.02% | 97.95% | 100.00% |
전체 장치 CPU는 이 보고서에서 CPU 용량을 판단하는 주요 기준입니다. S3.5의 P95는 S3보다 9.97%p 낮습니다. S6의 P95는 90%를 넘어 지속 운영에 필요한 여유가 충분하지 않습니다.
8. 메모리 결과
섹션 제목: “8. 메모리 결과”| 상태 | 시나리오 | EMS Builder 귀속 메모리 평균 | EMS Builder 귀속 메모리 P95 | 전체 장치 실제 메모리 평균 | 전체 장치 실제 메모리 P95 | 전체 장치 실제 메모리 최고값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 2,666.77 MB | 2,704.44 MB | 1,550.46 MB（39.74%） | 1,637.29 MB（41.97%） | 1,694.09 MB（43.42%） |
| 🟢 | S2 | 2,805.86 MB | 2,895.39 MB | 1,579.23 MB（40.48%） | 1,675.40 MB（42.94%） | 1,736.57 MB（44.51%） |
| 🟢 | S2.5 | 2,881.41 MB | 2,933.45 MB | 1,507.67 MB（38.64%） | 1,596.94 MB（40.93%） | 1,667.61 MB（42.74%） |
| 🟡 | S3 | 3,067.36 MB | 3,119.55 MB | 1,591.41 MB（40.79%） | 1,684.10 MB（43.17%） | 1,759.92 MB（45.11%） |
| 🟢 | S3.5 | 3,059.29 MB | 3,106.37 MB | 1,579.83 MB（40.49%） | 1,615.76 MB（41.41%） | 1,702.34 MB（43.63%） |
| 🔴 | S6 | 3,071.13 MB | 3,123.09 MB | 1,636.22 MB（41.94%） | 1,721.25 MB（44.12%） | 1,791.94 MB（45.93%） |
5개 서비스의 귀속 메모리는 cgroup에 귀속된 공유 페이지와 캐시를 포함하며 물리 메모리 순사용량과 다릅니다. 전체 장치 실제 메모리가 남은 용량을 더 잘 반영하므로 시나리오 판단에 사용합니다. 데이터베이스 초기 상태와 캐시 준비 상태가 결과에 영향을 주므로 포인트 수만으로 메모리 변화를 추론해서는 안 됩니다.
9. 처리량 결과
섹션 제목: “9. 처리량 결과”평균 처리량은 전체 유효 구간 2,000초를 분모로 사용합니다. 달성률은 작업 총수를 목표 총수로 나누어 계산하여 워크북 표시값의 반올림 오차를 방지합니다.
| 상태 | 시나리오 | Trigger 총수 | Trigger 평균 / 목표 | Trigger 달성률 | MQTT 총수 | MQTT 평균 / 목표 | MQTT 달성률 |
|---|---|---|---|---|---|---|---|
| 🟢 | S1 | 20,000 | 10.00 / 10 | 100.00% | 10,000 | 5.00 / 5 | 100.00% |
| 🟢 | S2 | 79,990 | 40.00 / 40 | 99.99% | 19,995 | 10.00 / 10 | 99.98% |
| 🟢 | S2.5 | 79,990 | 40.00 / 40 | 99.99% | 20,000 | 10.00 / 10 | 100.00% |
| 🟡 | S3 | 179,788 | 89.89 / 90 | 99.88% | 39,800 | 19.90 / 20 | 99.50% |
| 🟢 | S3.5 | 179,943 | 89.97 / 90 | 99.97% | 39,960 | 19.98 / 20 | 99.90% |
| 🔴 | S6 | 298,469 | 149.23 / 150 | 99.49% | 59,239 | 29.62 / 30 | 98.73% |
이 보고서는 권장 실행 시나리오의 처리량 기준선을 99%로 정합니다. S6의 MQTT는 이에 미달하며 높은 CPU 사용량, 지연 증가 및 샘플링 제한 시간 초과가 동시에 나타나므로 부하가 압박 영역에 진입했음을 보여 줍니다.
10. Trigger 지연 시간
섹션 제목: “10. Trigger 지연 시간”다음 백분위수는 유효 구간의 모든 Trigger 작업 기록을 기준으로 하며 단위는 밀리초입니다.
| 상태 | 시나리오 | 평균 | P50 | P95 | P99 | 개별 최대값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 47.86 | 19 | 32 | 47 | 10,160 |
| 🟢 | S2 | 23.65 | 11 | 30 | 53 | 10,938 |
| 🟢 | S2.5 | 26.06 | 17 | 46 | 69 | 10,938 |
| 🟡 | S3 | 37.69 | 14 | 55 | 99 | 10,993 |
| 🟢 | S3.5 | 29.88 | 15 | 56 | 88 | 10,994 |
| 🔴 | S6 | 44.06 | 17 | 87 | 162 | 11,985 |
일반적인 백분위수는 모두 낮지만 모든 시나리오에 약 10~12초의 극단적인 개별 긴 지연이 존재합니다. P99를 크게 바꾸지는 않더라도 개별 제어 또는 알람 작업에 영향을 줄 수 있으므로 별도 진단이 필요합니다.
11. MQTT 지연 시간
섹션 제목: “11. MQTT 지연 시간”다음 백분위수는 유효 구간의 모든 MQTT 작업 기록을 기준으로 하며 단위는 밀리초입니다.
| 상태 | 시나리오 | 평균 | P50 | P95 | P99 | 개별 최대값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 57.90 | 57 | 65 | 73 | 122 |
| 🟢 | S2 | 57.83 | 57 | 67 | 76 | 115 |
| 🟢 | S2.5 | 57.13 | 56 | 65 | 74 | 330 |
| 🟡 | S3 | 62.31 | 58 | 89 | 146 | 340 |
| 🟢 | S3.5 | 58.60 | 57 | 77 | 98 | 220 |
| 🔴 | S6 | 74.79 | 64 | 134 | 236.62 | 920 |
12. 시나리오 판단
섹션 제목: “12. 시나리오 판단”| 시나리오 | 판단 | 주요 근거 |
|---|---|---|
| S1 | 통과 | 기준 부하에서 전체 CPU P95 38.67%, 메모리 P95 41.97%, 작업 처리량 목표 달성. |
| S2 | 통과 | Trigger와 MQTT 달성률이 모두 100%에 가깝고 리소스 여유가 충분함. 샘플링 제한 시간 초과 1회에 주의. |
| S2.5 | 통과 | 처리량 목표 달성. 변경 기반 저장에서 전체 CPU 평균과 P95가 모두 S2보다 크게 낮음. |
| S3 | 조건부 통과 | 처리량과 작업 지연 시간은 기준을 충족하지만 전체 CPU P95 81.06%, 샘플링 제한 시간 초과 2회로 지속 운영 여유가 적음. |
| S3.5 | 권장 | 초당 5,000포인트 부하에서 Trigger / MQTT P95 모두 100 ms 미만, 전체 CPU P95 71.09%, 실제 메모리 P95 41.41%, 샘플링 제한 시간 초과 없음. |
| S6 | 지속 운영 비권장 | MQTT 달성률 98.73%, P99 236.62 ms, 전체 CPU P95 94.02%, 샘플링 제한 시간 초과 11회 발생. |
13. 용량 및 배포 권장 사항
섹션 제목: “13. 용량 및 배포 권장 사항”13.1 검증된 권장 설정
섹션 제목: “13.1 검증된 권장 설정”- 데이터 수집 설정량: 초당 5,000포인트
- 집계 연산: 30개
- 일반 Trigger: 초당 50회
- 100 ms Trigger: 4개, 즉 초당 40회
- Trigger 합계: 초당 90회
- MQTT: 초당 20회
- 협업 작업: 초당 10회
- Trigger 작업 기록: 저장
- 데이터 저장: 변경 기반 저장, 값이 바뀌지 않아도 최대 10초 이내에 한 번 저장
13.2 운영 배포 권장 사항
섹션 제목: “13.2 운영 배포 권장 사항”- 장기 운영 시 위 실측 설정에서 약 20%의 엔지니어링 여유를 확보하고 실제 Lua 스크립트, 메시지 본문 크기 및 이력 데이터 규모로 운영 전 재검증하는 것이 좋습니다.
- 전체 CPU에 80% 경고, 전체 메모리에 70% 경고와 80% 심각 알람을 설정하고 PostgreSQL 캐시 및 데이터베이스 증가를 지속 관찰하는 것이 좋습니다.
- 실시간 저장이 필요하면 S3 결과를 참조할 수 있지만 전체 CPU P95가 이미 80%를 넘습니다. 업무상 필수가 아니라면 S3.5의 변경 기반 저장을 우선 사용하세요.
- S6는 단시간 부하, 속도 제한 또는 과부하 보호 검증에만 사용하고 E630의 지속 운영 부하로는 권장하지 않습니다.
14. 품질 경고 및 추가 테스트
섹션 제목: “14. 품질 경고 및 추가 테스트”- 샘플링 제한 시간 초과가 S2에서 1회, S3에서 2회, S6에서 11회 발생했습니다. S1, S2.5 및 S3.5에서는 발견되지 않았습니다.
- 72시간 안정성 테스트를 완전히 수행하고 프로세스 재시작, OOM, 오류 로그, 메모리 증가 기울기 및 데이터베이스 증가를 기록합니다.
- 수집 포인트, Trigger, MQTT 및 협업 작업별로 성공, 실패, 제한 시간 초과 및 폐기 카운터를 추가합니다.
- 디스크 처리량, I/O wait, PostgreSQL WAL / checkpoint, 연결 풀 및 큐 깊이 정보를 보완합니다.
- Trigger의 10~12초 개별 긴 지연을 작업 ID, Lua 스크립트, SQL, GC, I/O 및 시스템 로그와 연계하여 확인합니다.
- 시나리오별 시작 전 데이터베이스 크기, PostgreSQL 설정 및 캐시 준비 상태를 기록하여 메모리 결과의 비교 가능성을 높입니다.
15. 데이터 한계
섹션 제목: “15. 데이터 한계”- 포인트 수는 테스트 설정량이며 포인트별 성공 횟수가 아닙니다. 현재 데이터만으로 모든 수집 포인트의 쓰기 성공을 독립적으로 입증할 수 없습니다.
- 워크북에는 업무 오류율, 작업 결과 상태 및 정확도 필드가 없으므로 처리량 목표 달성이 업무 정확도 100%를 뜻하지는 않습니다.
- 모든 시나리오는 약 33분 20초의 단시간 테스트로 성능 비교에는 적합하지만 장기 안정성 테스트를 대체하지 않습니다.
- S3.5는 이번 테스트에서 종합 지표가 가장 우수한 실측 설정입니다. 20% 엔지니어링 여유는 용량 계획 권장 사항이며 별도 실측 결론이 아닙니다.
다른 모델은 AFE-E620 테스트 보고서를 참조하세요.