AFE-E620에서의 EMS Builder 성능 테스트 보고서
보고서 버전: v1.0
테스트 날짜: 2026-07-30 ~ 2026-07-31
보고서 날짜: 2026-07-31
통계 기준: 시나리오별 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에 리소스를 할당하므로 장치, 데이터베이스 규모 및 캐시 상태에 따라 메모리 사용량이 크게 다를 수 있습니다. AFE-E620의 물리 메모리는 982 MB로 AFE-E630보다 여유가 훨씬 적으므로 용량 계획에서 메모리를 우선 고려해야 합니다.
1.1 핵심 결론
섹션 제목: “1.1 핵심 결론”AFE-E620은 S2.5 시나리오로 운영하는 것이 좋습니다. 초당 2,000포인트, 집계 연산 20개, Trigger 초당 40회, MQTT 초당 10회, 협업 작업 초당 2회 및 10초 변경 기반 저장을 사용합니다.
S2.5의 실측 Trigger는 초당 39.96회, MQTT는 초당 9.98회이며 달성률은 각각 99.91%와 99.82%입니다. Trigger / MQTT P95는 각각 25 ms와 56 ms입니다. 전체 장치 CPU P95는 45.54%, 실제 메모리 P95는 86.10%이며 샘플링 제한 시간 초과가 8회 발생했습니다.
장기 운영 환경에서는 S2.5 실측 부하에서 약 20%의 엔지니어링 여유를 확보하고, 초기 용량을 약 초당 1,600포인트, Trigger 초당 32회, MQTT 초당 8회, 협업 작업 초당 2회 이하로 계획하는 것이 좋습니다. 이는 실측 설정을 환산한 엔지니어링 권장값이며 별도로 실행한 테스트 시나리오가 아닙니다. 정식 운영 전에는 실제 프로젝트 스크립트, 메시지 크기 및 이력 데이터 규모로 다시 테스트해야 합니다.
1.2 시나리오별 상태
섹션 제목: “1.2 시나리오별 상태”| 아이콘 | 시나리오 | 결론 |
|---|---|---|
| 🟢 | S1 | 기준 시나리오 통과, 달성률 100%. 다만 전체 장치 메모리 평균이 이미 74.02%로 기본 사용량이 높음. |
| 🟡 | S2 | 실시간 저장에서 Trigger / MQTT 달성률이 98.65% / 98.76%로 99% 기준선보다 약간 낮고 샘플링 제한 시간 초과 34회 발생. |
| 🟢 | S2.5 | 99% 기준선을 충족하는 가장 높은 부하 시나리오로, 현재 AFE-E620 권장 시나리오. |
| 🔴 | S3 | 미통과. Trigger / MQTT 달성률이 43.08% / 44.65%에 불과하고 지연 시간이 크게 악화되었으며 샘플링 제한 시간 초과 617회 발생. |
| 🔴 | S3.5 | 미통과. 변경 기반 저장이 S3 성능을 크게 개선했지만 달성률은 87.30% / 86.69%로 99% 기준선 미만. |
| 🔴 | S6 | 심각한 과부하. Trigger / MQTT 달성률이 19.15% / 19.18%에 불과하며 샘플링 제한 시간 초과 886회 발생. |
2. 결론 요약
섹션 제목: “2. 결론 요약”- 이번 테스트는 S1, S2, S2.5, S3, S3.5 및 S6의 여섯 시나리오를 포함하며, 다른 시나리오는 표, 비교 및 결론에 포함하지 않습니다.
- S2.5는 초당 2,000포인트의 설정 부하에서 Trigger 달성률 99.91%, MQTT 달성률 99.82%를 기록했습니다. Trigger / MQTT P95는 각각 25 ms와 56 ms입니다.
- S2와 S2.5의 업무 부하는 같습니다. 변경 기반 저장을 활성화한 후 전체 장치 CPU 평균은 29.41%에서 26.24%로, P95는 52.01%에서 45.54%로 감소했으며 Trigger 달성률은 98.65%에서 99.91%로 증가했습니다.
- S3와 S3.5의 업무 부하는 같습니다. 변경 기반 저장을 활성화하면 Trigger 달성률은 43.08%에서 87.30%로, MQTT 달성률은 44.65%에서 86.69%로 증가하고 전체 장치 CPU P95는 82.71%에서 66.05%로 감소하지만 여전히 통과하지 못합니다. 초당 5,000포인트는 AFE-E620의 지속 처리 용량을 초과합니다.
- AFE-E630과 비교하면 E630은 S3.5(초당 5,000포인트, Trigger 초당 90회)를 처리할 수 있고, E620의 검증된 상한은 S2.5(초당 2,000포인트, Trigger 초당 40회)입니다. 메모리 차이(3.81 GB 대 982 MB)가 주요 원인입니다.
- 모든 시나리오의 Trigger에 약 10~11초의 개별 긴 지연이 나타났습니다. 과부하 시나리오에서는 더 커져 S3.5의 Trigger 최대값은 53,472 ms, MQTT 최대값은 53,373 ms였습니다.
- 모든 시나리오에서 전체 장치 메모리 평균이 74%를 넘고 S3 이후의 P95는 91%를 넘었습니다. 메모리는 E620의 모든 시나리오에서 공통 병목이므로 지속적으로 모니터링해야 합니다.
- 각 시나리오는 유효 샘플 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-E620은 4코어이므로 “Edge-EMS Builder 4코어 환산 CPU” = 5개 서비스 CPU 합계 ÷ 4입니다.
- “전체 장치 CPU”는 워크북의
_system_total를 사용합니다. 전체 CPU 용량을 0~100%로 정규화한 사용률이며 장치 용량 판단의 주요 지표입니다. - “Edge-EMS Builder 귀속 메모리”는 5개 서비스의 cgroup 귀속 메모리 합계입니다. 공유 페이지와 캐시가 중복 귀속될 수 있어 전체 장치의 실제 사용 메모리보다 클 수 있으므로 물리 메모리로 직접 나누어 용량 사용률로 사용할 수 없습니다.
- “전체 장치 실제 메모리”는
MemTotal - MemAvailable로 계산하며 물리 메모리 여유를 판단하는 주요 지표입니다. 이 보고서의 메모리 백분율은 MemTotal = 982 MB를 기준으로 계산합니다. - Trigger / MQTT의 평균 및 P50, P95, P99는 유효 구간의 전체 작업 기록을 기준으로 하며 초당 평균값의 백분위수가 아닙니다.
- 모든 워크북은 “집계 전 테스트 부하 종료” 검증을 통과했습니다. Trigger, MQTT 및 CommBridge를 집계 전에 종료하고 30초 기다렸습니다.
4. 테스트 대상 및 환경
섹션 제목: “4. 테스트 대상 및 환경”| 항목 | 설정 |
|---|---|
| 장치 모델 | AFE-E620 |
| CPU | Arm Cortex-A55, 4코어 |
| 메모리 | 982 MB DDR3 |
| 운영 체제 | Ubuntu 20.04 기반 JelinaOS |
| 저장 장치 | eMMC |
| 소프트웨어 버전 | 추가 필요(이번 워크북에 기록되지 않았으며 보관 전에 CommBridge / EMS Builder / PostgreSQL 버전 추가 필요) |
| 네트워크 | LAN, MQTT / TCP |
| 모니터링 샘플링 | 초당 1회, 시나리오별 2,002회 중 중간 2,000회 집계 |
| 테스트 데이터 출처 | perf_S1_20260730_101351.xlsx, perf_S2_20260730_105126.xlsx, perf_S2.5_20260730_113029.xlsx, perf_S3_20260730_152548.xlsx, perf_S3.5_20260731_122356.xlsx, perf_S6_20260731_173626.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회 | 실시간 |
“데이터 수집”은 시나리오에 설정한 부하이며 정의는 테스트 설명서를 따릅니다. 워크북에는 포인트별 수집 성공 횟수나 시나리오별 상세 설정이 없으므로 설정값을 독립 검증된 데이터베이스 저장 성공 처리량으로 표현할 수 없습니다. 각 시나리오의 Trigger / MQTT 목표는 워크북의 달성률 검증 목표와 일치합니다.
6. 테스트 시간
섹션 제목: “6. 테스트 시간”| 시나리오 | 유효 통계 구간 | 유효 시간 |
|---|---|---|
| S1 | 2026-07-30 10:13:55 ~ 10:47:13 | 2,000초 |
| S2 | 2026-07-30 10:51:30 ~ 11:24:48 | 2,000초 |
| S2.5 | 2026-07-30 11:30:33 ~ 12:03:51 | 2,000초 |
| S3 | 2026-07-30 15:25:51 ~ 15:59:09 | 2,000초 |
| S3.5 | 2026-07-31 12:23:59 ~ 12:57:17 | 2,000초 |
| S6 | 2026-07-31 17:36:29 ~ 18:09:47 | 2,000초 |
모든 시간은 UTC+8입니다.
7. CPU 결과
섹션 제목: “7. CPU 결과”7.1 EMS Builder 5개 서비스 합계(4코어 환산)
섹션 제목: “7.1 EMS Builder 5개 서비스 합계(4코어 환산)”| 상태 | 시나리오 | 평균 | P95 | P99 | 최고값 |
|---|---|---|---|---|---|
| 🟢 | S1 | 9.87% | 19.19% | 27.73% | 32.42% |
| 🟡 | S2 | 22.39% | 41.93% | 51.69% | 110.22% |
| 🟢 | S2.5 | 19.86% | 36.67% | 47.88% | 75.63% |
| 🔴 | S3 | 32.80% | 57.33% | 71.41% | 115.84% |
| 🔴 | S3.5 | 32.25% | 52.81% | 64.87% | 130.65% |
| 🔴 | S6 | 30.90% | 63.74% | 77.34% | 99.06% |
S2, S3 및 S3.5의 Edge-EMS Builder 최고값은 각각 110.22%, 115.84%, 130.65%입니다. 이는 단일 샘플링 구간의 순간값으로, 5개 서비스의 CPU 시간 합계가 일반적인 4코어 용량을 초과한 경우입니다(예: S2의 ems_backend 단일 서비스·단일 샘플 최고값 402%). 샘플링 제한 시간 초과를 함께 고려하면 샘플링 구간이 여러 주기에 걸치거나 순간적인 스케줄링이 발생했을 가능성이 있으므로 지속 가능한 리소스 사용량으로 간주하지 않습니다.
7.2 전체 장치 CPU(전체 CPU 용량 정규화)
섹션 제목: “7.2 전체 장치 CPU(전체 CPU 용량 정규화)”| 상태 | 시나리오 | 평균 | P95 | P99 | 최고값 |
|---|---|---|---|---|---|
| 🟢 | S1 | 15.27% | 26.83% | 34.00% | 50.88% |
| 🟡 | S2 | 29.41% | 52.01% | 70.29% | 100.00% |
| 🟢 | S2.5 | 26.24% | 45.54% | 58.41% | 97.05% |
| 🔴 | S3 | 48.29% | 82.71% | 97.18% | 100.00% |
| 🔴 | S3.5 | 41.32% | 66.05% | 90.63% | 100.00% |
| 🔴 | S6 | 49.35% | 88.33% | 98.30% | 100.00% |
전체 장치 CPU는 이 보고서에서 CPU 용량을 판단하는 주요 기준입니다. S2.5의 P95는 S2보다 6.47%p 낮습니다. S3 이후는 P95가 모두 66%를 넘고 최고값이 100%에 도달하여 CPU 포화 영역에 진입했습니다.
8. 메모리 결과
섹션 제목: “8. 메모리 결과”| 상태 | 시나리오 | EMS Builder 귀속 메모리 평균 | EMS Builder 귀속 메모리 P95 | 전체 장치 실제 메모리 평균 | 전체 장치 실제 메모리 P95 | 전체 장치 실제 메모리 최고값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 484.14 MB | 529.22 MB | 726.92 MB（74.02%） | 810.83 MB（82.57%） | 825.71 MB（84.08%） |
| 🟡 | S2 | 567.86 MB | 589.11 MB | 788.52 MB（80.30%） | 878.61 MB（89.47%） | 900.03 MB（91.65%） |
| 🟢 | S2.5 | 562.11 MB | 580.93 MB | 785.65 MB（80.01%） | 845.52 MB（86.10%） | 918.53 MB（93.54%） |
| 🔴 | S3 | 573.27 MB | 603.92 MB | 843.22 MB（85.87%） | 930.97 MB（94.80%） | 938.00 MB（95.52%） |
| 🔴 | S3.5 | 560.39 MB | 590.84 MB | 838.25 MB（85.36%） | 902.91 MB（91.95%） | 937.29 MB（95.45%） |
| 🔴 | S6 | 549.24 MB | 608.00 MB | 827.91 MB（84.31%） | 932.14 MB（94.92%） | 939.57 MB（95.68%） |
5개 서비스의 귀속 메모리는 cgroup에 귀속된 공유 페이지와 캐시를 포함하며 물리 메모리 순사용량과 다릅니다. 전체 장치 실제 메모리가 남은 용량을 더 잘 반영하므로 시나리오 판단에 사용합니다. AFE-E620의 물리 메모리는 982 MB뿐입니다. 기준 시나리오 S1의 전체 메모리 평균이 이미 74.02%로 운영 체제와 Edge-EMS Builder의 상주 사용량이 용량의 4분의 3에 가깝습니다. S3 이후에는 P95가 91%를 넘어 남은 메모리가 90 MB 미만이므로 메모리 압박 상태입니다. 데이터베이스 초기 상태와 캐시 준비 상태가 결과에 영향을 주므로 포인트 수만으로 메모리 변화를 추론해서는 안 됩니다.
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 | 78,917 | 39.46 / 40 | 98.65% | 19,752 | 9.88 / 10 | 98.76% |
| 🟢 | S2.5 | 79,924 | 39.96 / 40 | 99.91% | 19,964 | 9.98 / 10 | 99.82% |
| 🔴 | S3 | 77,536 | 38.77 / 90 | 43.08% | 17,860 | 8.93 / 20 | 44.65% |
| 🔴 | S3.5 | 157,134 | 78.57 / 90 | 87.30% | 34,676 | 17.34 / 20 | 86.69% |
| 🔴 | S6 | 57,442 | 28.72 / 150 | 19.15% | 11,508 | 5.75 / 30 | 19.18% |
이 보고서는 권장 실행 시나리오의 처리량 기준선을 99%로 정합니다. S2는 약간 미달하며 S3, S3.5 및 S6는 처리 능력이 명백히 부족합니다. 과부하 영역에 진입하면 작업 큐가 계속 쌓이고 실제 완료량이 목표보다 훨씬 낮아집니다.
10. Trigger 지연 시간
섹션 제목: “10. Trigger 지연 시간”다음 백분위수는 유효 구간의 모든 Trigger 작업 기록을 기준으로 하며 단위는 밀리초입니다.
| 상태 | 시나리오 | 평균 | P50 | P95 | P99 | 개별 최대값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 15.57 | 12 | 18 | 30 | 10,237 |
| 🟡 | S2 | 22.98 | 9 | 28 | 61 | 11,012 |
| 🟢 | S2.5 | 17.28 | 9 | 25 | 40 | 10,999 |
| 🔴 | S3 | 70.61 | 17 | 120 | 713.65 | 27,281 |
| 🔴 | S3.5 | 76.65 | 13 | 58 | 170 | 53,472 |
| 🔴 | S6 | 71.90 | 17 | 127 | 610.59 | 24,421 |
S2.5 이하의 일반적인 백분위수는 낮지만 모든 시나리오에 약 10~11초의 극단적인 개별 긴 지연이 존재합니다. 과부하 시나리오의 평균은 긴 지연으로 크게 증가합니다(예: S3.5 평균 76.65 ms는 P95 58 ms보다 높고 P50은 13 ms에 불과). 일반적인 성능 판단에는 P50 / P95를 우선 참조해야 합니다. 긴 지연이 P99를 크게 바꾸지는 않더라도 개별 제어 또는 알람 작업에 영향을 줄 수 있으므로 별도 진단이 필요합니다.
11. MQTT 지연 시간
섹션 제목: “11. MQTT 지연 시간”다음 백분위수는 유효 구간의 모든 MQTT 작업 기록을 기준으로 하며 단위는 밀리초입니다.
| 상태 | 시나리오 | 평균 | P50 | P95 | P99 | 개별 최대값 |
|---|---|---|---|---|---|---|
| 🟢 | S1 | 49.65 | 49 | 52 | 56 | 440 |
| 🟡 | S2 | 54.77 | 51 | 64 | 90 | 1,182 |
| 🟢 | S2.5 | 51.80 | 52 | 56 | 64 | 402 |
| 🔴 | S3 | 93.56 | 56 | 249.05 | 944.41 | 2,471 |
| 🔴 | S3.5 | 109.53 | 55 | 95 | 242 | 53,373 |
| 🔴 | S6 | 95.33 | 59 | 201 | 782 | 19,969 |
12. 시나리오 판단
섹션 제목: “12. 시나리오 판단”| 시나리오 | 판단 | 주요 근거 |
|---|---|---|
| S1 | 통과 | 기준 부하에서 Trigger / MQTT 달성률이 모두 100%, 전체 장치 CPU P95는 26.83%. 다만 메모리 평균이 이미 74.02%임에 주의. |
| S2 | 조건부 통과 | 리소스 여유는 있지만(CPU P95 52.01%), Trigger / MQTT 달성률 98.65% / 98.76%가 99% 기준선보다 약간 낮고 샘플링 제한 시간 초과 34회 발생. |
| S2.5 | 권장 | 초당 2,000포인트 부하에서 Trigger / MQTT 달성률 99.91% / 99.82%, P95 각각 25 ms와 56 ms, 전체 CPU P95 45.54%로 기준선을 충족한 최고 부하 시나리오. |
| S3 | 미통과 | Trigger / MQTT 달성률 43.08% / 44.65%, MQTT P99 944.41 ms, 전체 CPU P95 82.71%, 메모리 P95 94.80%, 샘플링 제한 시간 초과 617회 발생. |
| S3.5 | 미통과 | 변경 기반 저장으로 S3보다 크게 개선(CPU P95 66.05%, Trigger P95 58 ms)되었지만 달성률 87.30% / 86.69%는 여전히 기준선 미만이며 샘플링 제한 시간 초과 96회 발생. |
| S6 | 모든 운영 환경에서 비권장 | 달성률 19.15% / 19.18%, 전체 CPU P95 88.33%, 메모리 P95 94.92%, 샘플링 제한 시간 초과 886회로 심각한 과부하. |
13. 용량 및 배포 권장 사항
섹션 제목: “13. 용량 및 배포 권장 사항”13.1 검증된 권장 설정
섹션 제목: “13.1 검증된 권장 설정”- 데이터 수집 설정량: 초당 2,000포인트
- 집계 연산: 20개
- 일반 Trigger: 초당 20회
- 100 ms Trigger: 2개, 즉 초당 20회
- Trigger 합계: 초당 40회
- MQTT: 초당 10회
- 협업 작업: 초당 2회
- Trigger 작업 기록: 저장
- 데이터 저장: 변경 기반 저장, 값이 바뀌지 않아도 최대 10초 이내에 한 번 저장
13.2 운영 배포 권장 사항
섹션 제목: “13.2 운영 배포 권장 사항”- 장기 운영 시 위 실측 설정에서 약 20%의 엔지니어링 여유를 확보하고 실제 Lua 스크립트, 메시지 본문 크기 및 이력 데이터 규모로 운영 전 재검증하는 것이 좋습니다.
- AFE-E620의 메모리 기본 사용량이 높으므로(기준 시나리오 S1에서도 전체 평균 74% 초과), 전체 CPU에는 80% 경고, 전체 메모리에는 85% 경고와 90% 심각 알람을 설정하고 PostgreSQL 캐시와 데이터베이스 증가를 지속적으로 관찰하는 것이 좋습니다. 필요하면 PostgreSQL 메모리 할당 축소 또는 상위 모델 도입을 검토하세요.
- 실시간 저장이 필요하면 S2 결과를 참조할 수 있지만 달성률이 99% 기준선보다 약간 낮습니다. 업무상 필수가 아니라면 S2.5의 변경 기반 저장을 우선 사용하세요.
- S3(초당 5,000포인트) 이상의 부하는 AFE-E620의 지속 처리 용량을 초과하며 변경 기반 저장(S3.5)도 통과하지 못했습니다. 이 용량이 필요하면 AFE-E630을 선택해야 합니다.
- E620의 S6는 심각한 과부하이므로 부하 사전 점검의 참고 가치가 없습니다. 과부하 보호를 검증하려면 S3 수준의 부하로 짧게 실행하는 것이 좋습니다.
14. 품질 경고 및 추가 테스트
섹션 제목: “14. 품질 경고 및 추가 테스트”- 샘플링 제한 시간 초과: S1 3회, S2 34회, S2.5 8회, S3 617회, S3.5 96회, S6 886회. 과부하 시나리오에서는 모니터링 자체가 제시간에 샘플링을 마치지 못해 리소스 데이터 신뢰도가 낮아지므로 처리량과 지연 시간을 중심으로 판단합니다.
- 이번 테스트의 CommBridge / Edge-EMS Builder / PostgreSQL 소프트웨어 버전을 추가하여 환경 정보를 보완합니다.
- 72시간 안정성 테스트를 완전히 수행하고 프로세스 재시작, OOM, 오류 로그, 메모리 증가 기울기 및 데이터베이스 증가를 기록합니다. E620은 메모리 기본 사용량이 높으므로 느린 메모리 증가 여부를 중점적으로 관찰해야 합니다.
- 수집 포인트, Trigger, MQTT 및 협업 작업별로 성공, 실패, 제한 시간 초과 및 폐기 카운터를 추가합니다.
- 디스크 처리량, I/O wait, PostgreSQL WAL / checkpoint, 연결 풀 및 큐 깊이 정보를 보완합니다.
- Trigger의 10~11초 개별 긴 지연 및 S3.5에서 Trigger와 MQTT에 동시에 발생한 약 53초의 극단값을 작업 ID, Lua 스크립트, SQL, GC, I/O 및 시스템 로그와 연계하여 진단합니다.
- 시나리오별 시작 전 데이터베이스 크기, PostgreSQL 설정 및 캐시 준비 상태를 기록하여 메모리 결과의 비교 가능성을 높입니다.
15. 데이터 한계
섹션 제목: “15. 데이터 한계”- 포인트 수는 테스트 설정량이며 포인트별 성공 횟수가 아닙니다. 현재 데이터만으로 모든 수집 포인트의 쓰기 성공을 독립적으로 입증할 수 없습니다.
- 시나리오의 업무 설정(집계 수, Trigger 구성, 협업 작업 수)은 테스트 설명서 정의를 따르며 워크북에 시나리오별 상세 설정이 기록되어 있지 않습니다.
- 워크북에는 업무 오류율, 작업 결과 상태 및 정확도 필드가 없으므로 처리량 목표 달성이 업무 정확도 100%를 뜻하지는 않습니다.
- 모든 시나리오는 약 33분 20초의 단시간 테스트로 성능 비교에는 적합하지만 장기 안정성 테스트를 대체하지 않습니다.
- 이번 소프트웨어 버전이 워크북에 기록되지 않아 버전을 보완한 후 결과와 버전의 관계를 확인해야 합니다.
- S2.5는 이번 테스트에서 99% 처리량 기준선을 충족한 최고 부하의 실측 설정입니다. 20% 엔지니어링 여유는 용량 계획 권장 사항이며 별도 실측 결론이 아닙니다.
다른 모델은 AFE-E630 테스트 보고서를 참조하세요.