스테이징 서버 구축하기

구축한 이유

최종 프로젝트를 진행하면서 중간발표이후 서버를 배포하였고 이후 배포된 서버에 성능테스트를 위해 더미데이터를 넣는거나 기능 테스트하는 등 운영 환경에 테스트를 했다보니 잘되던 기능이 안되는 등의 불편함이 생겨서 운영서버에 영향이 없는 스테이징 환경을 구축하여 기능 테스트 및 성능테스트를 하기로 하였다.

주의할 점

1. 운영 환경과의 유사성:
   • 스테이징서버 즉 QA 서버는 가능한 한 운영 환경(배포 환경)과 유사하게 구성해야함
   • 하드웨어 스펙, 운영체제, 데이터베이스 버전 등을 일치 시켜야함.
     (우리는 동일한 ec2를 구축하였음)
2. 데이터 관리:
   • 테스트용 데이터를 주기적으로 갱신하고 관리
   • 민감한 실제 데이터를 사용할 경우, 반드시 마스킹 처리를 해야됨
3. 보안:
   • QA 서버도 보안에 취약할 수 있으므로, 적절한 보안 조치가 필요
   • 불필요한 포트는 차단하고, 접근 제어를 엄격하게 관리
4. 성능 모니터링:
   • 성능 테스트를 위한 모니터링 도구를 설치하고 구성
     (Grafana + Prometheus ///  부하 테스트 : Jmeter)
     • Prometheus: 서버, 애플리케이션, 컨테이너 등에서 발생하는 메트릭 데이터(CPU, 메모리, 네트워크 등)를 수집
     • Grafana: Prometheus에서 수집한 데이터를 시각화하고, 실시간 대시보드와 알림 시스템을 제공모니터링 
   • 리소스 사용량, 응답 시간 등을 측정할 수 있어야됨 (실제 배포서버에는 필요없음)
5. 버전 관리:
   • 테스트 중인 소프트웨어의 버전을 명확히 관리
   • 롤백 및 복구 절차를 마련하여 복구 및 롤백을 진행할 수 있어야함
6. 접근성:
   • QA 팀이 쉽게 접근할 수 있도록 구성
   • 필요한 경우 원격 접속 환경을 제공
7. 확장성:
   • 향후 필요에 따라 쉽게 확장할 수 있도록 설계
8. 자동화:
   • 배포, 테스트, 리포팅 등의 프로세스를 가능한 한 자동화
9. 문서화:
   • 서버 구성, 테스트 절차, 문제 해결 가이드 등을 문서화
10. 네트워크 구성:
    • 실제 운영 환경과 유사한 네트워크 환경을 구성
    • 필요한 경우 지연이나 패킷 손실 등을 시뮬레이션할 수 있는 도구를 준비
11. 라이선스 관리:
    • 필요한 소프트웨어의 라이선스를 적절히 관리
12. 백업 및 복구:
    • 정기적인 백업 절차를 마련하고, 복구 테스트를 수행

최종 프로젝트 적용 사항

본 프로젝트에서는 CD를 분리하여 dev에 merge할 시 dev서버로 배포가 되고 이후 테스트를 거처 정상 작동을 확인하게 되면 이후 main에 merge하여 운영서버로 배포를 할수있도록 진행하였다.

아쉬운 점

1. 모니터링 시스템 구축 미비
   • Grafana와 Prometheus를 활용한 모니터링 시스템을 구축하려고 했지만, 시간 부족으로 실제로 구축하지 못한 점이 아쉬웠다.
   • 이 시스템은 리소스 사용량(CPU, 메모리, 네트워크 등)과 시스템 성능(TPS, 응답 시간 등)을 실시간으로 모니터링하고, Alert Manager를 통해 이상 징후를 빠르게 감지할 수 있어야 했습니다. 향후에는 이 시스템을 구축하여 운영 환경의 안정성을 더욱 강화하고, 성능 이슈를 사전에 예방할 수 있도록 할 계획이 있다.
2. DB 분리 부족 및 부하 테스트
   • 스테이징 서버용 DB를 구축하지 못하고 운영 DB를 그대로 사용하여 JMeter로 부하 테스트를 진행한 점이 아쉬웠다
   • 운영 데이터베이스에 직접 테스트 데이터를 넣고 부하를 가한 결과, 운영 DB를 정리하는 과정이 발생하여 시간자원을 낭비하는 이 생겼고, 또한 이러한 과정이 발생하며 DB상 무결성이 손상되었다. 다음부턴 꼭 DB도 분리하여 진행해야겠다.