* 이 글은 2025년 10월에 Medium에 작성된 내용입니다.
제 블로그에도 기제하기 위해서 동일한 내용을 가져온것 입니다. 앞으로도 이런 글들은 계속됩니다.
안녕하세요! 29CM QA팀 Lead 박현준입니다.
이번에는 저희 팀이 진행했던 자동화 퍼포먼스 향상을 위한 구조적 개선에 관한 이야기를 해보려고 합니다.
29CM QA팀은 과거 Mac Mini 1대로 테스트 자동화 환경을 구축하여 iOS 1대, Android 1대로 자동화를 시작했습니다.
하지만 자동화 시나리오와 부가 기능이 점차 확장되면서 프레임워크의 규모가 커졌고, 수행할 시나리오가 늘어나며 전체 테스트 시간이 길어졌습니다.
29CM QA팀은 테스트 자동화 수행은 20분 이내에 완료한다는 팀내 기준이 있었기에 수행시간 감소를 위한 환경 개선이 필요했습니다.
- 기기 추가는 수행시간의 최적화를 위해 병렬 수행되도록 구축하였고 기존 1대씩 연결된 것을 2대씩 연결되도록 설정하였습니다.
- 이와 함께 테스트 진행 시 계정 정보 같은 개인정보를 다루고 있었던 부분의 유출을 해소하고자 테스트용 API 서버를 구축하여 API 요청으로 개인정보를 응답받아 사용할 수 있도록 환경을 개선했습니다.
- 팀원 모두 재택일 경우가 있을 수 있는데 이때 기기를 원격으로 컨트롤하기 위해 STF (Smartphone Test Farm)도 구축하여 원격으로 컨트롤을 가능하게 하였습니다.
- 테스트 자동화 결과를 DB화하여 추적하기 위해 Postgresql + Grafana 조합으로 대시보드를 구성하여 결과를 추적할 수 있게 하였습니다.
이후에 퍼포먼스에 문제가 생겼습니다.
맥미니로 다양한 서비스를 띄워놓은 채로 테스트 수행기기 4대를 한 번에 운용하니 퍼포먼스 저하가 발생한 것이였습니다.
이 과정에서 Mac Mini 퍼포먼스 저하를 해소하고 테스트 기기 추가 확장을 고려하여 추가로 자동화 머신을 사용하는 계획을 진행하게 됩니다. 다행히도 추가 자동화 머신은 Mac Studio를 사용할 수 있게 되었고 바로 환경 분리 작업을 진행합니다.
기능 구현이 진행 중이던 Android 자동화 환경은 2대 그대로 기존 Mac Mini에 유지했습니다. 반면, 4대의 기기를 모두 활용하는 iOS 자동화 환경은 새로운 Mac Studio로 이전하였습니다.
이러한 인프라 개선과 함께 테스트 프레임워크의 기능 확장도 꾸준히 이루어졌습니다.
- 테스트 케이스 관리 도구인 TestRail과 연동하여 테스트 결과를 자동으로 기록하는 기능을 추가했습니다.
- 특정 조건에 따라 자동으로 실행되는 트리거(Trigger)를 포함한 API 테스트 자동화를 구현
- QA 진행 상황을 팀에 공유하기 위해 Slack bolt 프레임워크 기반의 데일리 리포트 봇(Daily Report Bot)을 개발했습니다.
- Mac Studio의 자원 사용량을 추적하고 성능 저하를 사전에 파악하고자 Prometheus와 Grafana 기반의 모니터링 시스템을 구축했습니다.
- 마지막으로 웹 테스트 자동화 도입을 위한 기반 작업으로 샘플 시나리오 코드를 작성했습니다.
하지만 환경이 복잡해지면서 몇 가지 새로운 문제가 발생했습니다.
첫째, 자동화 머신의 IP 주소가 변경될 때마다 API 트리거를 사용하는 모든 개발팀이 직접 명령어를 수정해야 하는 의존성 문제가 있었습니다.
둘째, 테스트용 API 서버, Slack 봇, 결과 데이터 등 핵심 서비스가 모두 Mac Mini 한 대에 집중되어, Mac Mini에 장애가 발생하면 전체 자동화 프로세스가 중단되는 문제가 있었습니다.
셋째, 자동화 머신이 두 대로 나뉘면서 리소스 관리 등 운영 효율성이 저하되었습니다.
이러한 문제를 종합적으로 해결하기 위해, 저희는 모든 자동화 작업을 중앙에서 관리하고 조율하는 Master Jenkins 환경을 구축하기로 했습니다.
이 글의 주제이기도 한 통합된 Jenkins 환경 구축 과정을 이제부터 자세히 이야기해 보겠습니다.
Jenkins Assemble!
IP가 변경돼도 영향이 없고 언제나 동일한 퍼포먼스를 낼 수 있는 환경으로 생각한 건 AWS EC2 였습니다.
그래서 EC2에 Master Jenkins를 구축하고 거기서 Mac Mini와 Mac Studio의 Jenkins를 컨트롤하는 방식을 생각했는데, 이렇게 하면 의도한 대로 구현은 가능하지만 뭔가 구조적으로는 석연치가 않았습니다.
그리고 이 구조라면 자동화가 수행될 때 수행 콘솔 로그를 Master Jenkins에서 확인할 수 없다는 단점도 존재했습니다. 좀 더 깔끔한 구조가 필요했고 이를 위해 주변의 개발자들에게 자문을 구하고 도움을 받았습니다.
결론적으로 Mac Mini와 Mac Studio를 Master Jeknins의 Node로 구성해서 사용하는 방식을 제안해 주셨습니다. 이럴 경우 Mac Mini와 Mac Studio에서 사용 중인 Jenkinis를 모두 사용하지 않아도 되고, Master Jenkins 하나만으로 자동화 머신을 모두 컨트롤할 수 있게 되는 것이었습니다.
해당 가이드는 개발팀에서 설정해 주시면서 직접 작성해 주신 내용으로, 덕분에 이후 Agent 변경 시에도 문제없이 제가 직접 설정할 수 있었습니다.
Master Jenkins 에서 할 것
방법은 Jenkins Nodes 에서 Node를 추가한 뒤에
새로운 Node를 추가하고
세부 설정을 완료한 뒤 생성하면 연결되지 않은 노드가 추가된 것을 볼 수 있습니다.
연결되지 않은 노드를 클릭하면 환경별 연결 커맨드를 확인할 수 있습니다.
추가로 아래 위치에서 agent.jar 파일을 다운받고
JENKINS_URL/jnlpJars/agent.jarNode가 될 머신에 다운받은 agent.jar 파일을 복사합니다. 그리고 agent.jar가 있는 위치에서 Master Jenkins에서 알려주는 커맨드를 실행하면 연결되게 됩니다.
더 쉬운 방법은 .sh 파일로 만들어 놓고 사용하시는 방법입니다. 각 값은 Node 생성 시 작성하셨던 내용을 참고하시면 됩니다.
아래 내용을 run-agent.sh 파일로 만들어 놓으시고
#!/bin/bash
JENKINS_URL="Jenkin URL"
AGENT_NAME="Agent Name"
SECRET_KEY="SECRET-KEY"
WORK_DIR="Work Dir"
AGENT_JAR="agent.jar"
java -jar "$AGENT_JAR" \
-url "$JENKINS_URL" \
-secret "$SECRET_KEY" \
-name "$AGENT_NAME" \
-workDir "$WORK_DIR" \아래 커맨드를 사용하시면 됩니다.
(사용이 되지 않는다면 파일 권한을 한번 확인해주세요)
./run-agent.sh그럼 이렇게 Node가 연결된 모습을 보실 수 있습니다.
Master-Node 구조로 전환하면서 기존 Mac Mini와 Mac Studio에 설치했던 Jenkins는 더 이상 사용하지 않게 되었습니다. 그 외 서비스들도 모두 EC2로 이전하면서 자동화 머신의 퍼포먼스도 향상되었습니다.
기존 사용하던 STF는 테스트 자동화 성능에 영향을 주었고, 활용 빈도도 낮아져 운영하지 않기로 결정했습니다.
이렇게 정리를 하고 나서 최종적으로 현재 29CM QA팀의 자동화 환경은 이런 모습이 되었습니다.
현재 완성된 아키텍처는 EC2의 Master Jenkins가 두 대의 Mac 머신을 Agent로 직접 제어하는 구조입니다.
API 서버, Slack Bolt, 테스트 결과 DB 등 모든 지원 서비스는 EC2에 구축된 QA팀 서버에서 모든 것을 할 수 있게 되었습니다.
이번 아키텍처 개편을 통해,
- 여러 머신에 분산되었던 설정을 중앙에서 관리하게 되어 운영 비용이 감소했습니다.
- 부가 서비스들을 EC2로 이전하여 Mac 머신들이 테스트 실행에만 리소스 집중할 수 있게 되었습니다.
- 개별 에이전트의 장애나 IP 변경이 다른 시스템에 영향을 주지 않는 독립적인 구조가 되었습니다.
- 모든 테스트 실행 로그를 마스터 Jenkins에서 통합 모니터링 가능할 수 있습니다.
마치며,
점점 환경과 기능을 넓혀가며 결국 구조적 개선이 필요한 상황이 왔을 때 Master Jenkins와 Node 구성으로 지금의 개선된 환경을 재구축 할 수 있었고 현재의 구조에 만족하며 운영 중입니다.
하지만 자동화 프레임워크나 환경은 앞으로도 계속 발전되고 커나가게 될 텐데, 그 때도 QA팀은 더 좋은 방법을 찾을 것이고 앞으로도 발전해 나갈 것이라고 생각합니다.
그때는 더 훌륭한 V3 환경이 되기를 기대해 봅니다.
'Study > Jenkins' 카테고리의 다른 글
| Jenkins JSONObject["scm"] is not a JSONObject 에러 해결하기 (0) | 2024.03.20 |
|---|---|
| Jenkins Pipeline Parallel 실행 하기 (젠킨스 파이프라인 병렬 실행) (1) | 2023.09.08 |
| jq를 사용해서 JSON 값 변경하기 (0) | 2023.06.23 |
| jenkins pipeline 결과 fail일 때 멈추지 않고 실행되도록 처리하기 & fail 이면 멈추기 (0) | 2022.03.02 |
| Jenkins 원격 빌드 하기 - cURL 사용해보기 (3) | 2021.05.20 |
댓글