성능 기준선 및 용량 테스트 계획[PATH용 MVP]

1. 범위

주어진 인프라 구성에서 지원할 수 있는 전체 진료소 수를 검증하는 성능 테스트 자동화를 개발합니다.

• 기준 하드웨어: Bahmni Lite: RAM 16GB, 4 vCPU, 보조 저장소 100GB
• 데이터베이스: RAM 8GB, 2 vCPU, 보조 저장소 100GB

자동화는 다양한 트래픽 부하 조건을 시뮬레이션합니다.

• 표준 트래픽 부하: 활성 사용자 40~50명
• 높은 트래픽 부하: 활성 사용자 50~70명
• 최대 트래픽 부하: 활성 사용자 70~110명

기존 데이터는 사용하지 않으며 새 DB에서 시작합니다.

등록과 진료 등 2~3개의 사용자 흐름을 지원합니다.

AWS 환경에서 Bahmni Lite(진료소 구현)의 성능 기준선을 측정합니다.

2. 소개

이 문서는 시스템의 성능 기준선과 용량을 다루는 성능 테스트의 개요를 제공하기 위한 것입니다.

• 시작 및 종료 기준
• 부하 도구 선택 및 접근 방식
• 기준선 및 용량 테스트 접근 방식
• 테스트 실행 활동
• 위험 요인

3. 시작 기준

• 핵심 흐름 식별
• 등록(신규 및 기존 환자)
• 의사 진료
• 환자 문서 업로드
• [확장 범위] Bahmni 보고서

성능 테스트 유형 확정

• 다양한 트래픽 부하에서 주어진 하드웨어 구성으로 임상 운영을 지원하기 위한 기준선(예상 응답 시간)

부하 생성 도구

• Gatling

서버 성능 모니터링

• Prometheus(메트릭)
• Grafana(대시보드)

데이터 설정

• 사용자 설정(진료소당 접수 담당자 2명, 의사 2명)
• [초안] 진료소 데이터 증가 패턴 자세히 보기관련 문서: Click Here

4. 종료 기준

다음 조건을 충족하면 테스트 활동이 완료됩니다.

• Gatling 성능 테스트 보고서를 생성하고 게시합니다.
• 표준 부하(표준 기준선)에서 지원 가능한 진료소 수를 사용자 범주별로 요약한 보고서를 작성합니다.

5. 부하 도구 선택 및 접근 방식

팀이 이전에 사용한 경험이 있으므로 Gatling을 부하 생성 도구로 사용합니다. Gatling은 하드웨어를 추가하지 않고도 JMeter보다 많은 사용자를 생성하고 모사하는 데 유리합니다. 상대적으로 리소스 사용량도 적어 JMeter보다 적합한 선택입니다.

Gatling의 주요 과제는 버전 업그레이드입니다. 예를 들어 마이너 버전 업그레이드에도 호환성을 깨는 변경이 발생할 수 있습니다.

6. 기준선 및 용량 테스트 접근 방식

⭕️ 시뮬레이션

다양한 사용자 흐름을 표현하기 위해 다음 테스트 시뮬레이션을 실행합니다. 미리 구성된 사용자 외에는 기존 데이터가 없습니다.

• 접수처 / 리셉션 - 환자 등록 및 방문
• 신규 환자: 등록 및 OPD 방문 시작
• 기존 환자: 이름/ID로 검색하고 OPD 방문 시작

의사 진료

• 환자 프로필 및 문서 접근
• 평균적인 환자 건강 상태
• 관찰값 10개 기록
• 의약품 3개 처방
• 검사실 검사 1~2개 주문

진료소의 예상 데이터 상태

• 기준선 측정 시 진료소에는 미리 설정된 사용자만 있으며 환자 데이터는 없습니다.
• 진료소의 성장을 모사하는 후속 테스트에서는 테스트 데이터를 유지합니다.

⭕️ 기준선 측정

다양한 트래픽 부하 조건(표준, 높음, 최대)의 사용자 흐름에서 여러 API(get, query, update, list 등)의 예상 응답 프로필 기준선을 정해야 합니다.

⭕️ 용량

최대 트래픽 부하 시뮬레이션을 통해 주어진 하드웨어 구성에서 시스템이 실패하거나 UX가 저하되기 전까지 허용 가능한 UX 성능으로 처리할 수 있는 최대 부하(활성 임상 사용자 수)를 확인합니다.

⭕️ 주요 관찰 항목

• 클라이언트 측
• 각 API 호출 응답 시간의 50, 75, 80, 90, 95백분위수
• 발생한 모든 오류

서버 측

• CPU 사용량
• 메모리 사용량
• 디스크 사용률

7. 테스트 실행 활동

성능 테스트를 완료하려면 다음 작업을 수행해야 합니다.

• 성능 테스트 환경 생성
• 서버에 Prometheus 및 Grafana 설치
• 디버깅용 서버 로그 활성화
• Gatling에서 사용자 흐름 스크립트 작성
• 사용자 프로파일링 순서 구성
• 테스트 실행
• 각 실행 결과 분석
• 성능 보고서 생성 및 게시

8. 위험 요인

다음 사항이 테스트 계획 실행과 일정에 영향을 줄 수 있습니다.

• Scala는 팀에 비교적 새로운 기술이므로 문서와 기존 Gatling 코드를 참고해야 합니다.
• 사전 요구 데이터의 최적 가져오기 또는 설정 방법을 조사해야 합니다. 테스트를 신속하게 다시 시작하는 데 필요합니다.