미리보기

서비스 설명 : MBTI P들을 위한 여행 계획 서비스

Github 링크 : https://github.com/junggyun/trip-for-p

[기여한 부분]

1. 인덱스 적용을 통한 대용량 데이터 조회 API 성능 개선

[도입 배경]

• 10만 건의 데이터 중 최신순 상위 9개의 데이터를 조회하는 API를 대상으로 k6를 통해 부하 테스트를 진행한 결과, 10 TPS로 낮은 수치가 나왔고, Amazon CloudWatch를 통해 모니터링하여, RDS CPU 사용률이 99%까지 급격히 상승하는 것을 발견하게 되었습 니다. 이에 DB가 병목 지점인 것을 알게 되었고 쿼리 실행 계획을 분석한 결과, 전체 테이블 스캔이 발생하고 있었습니다. 이를 해결하 기 위해 최신순 정렬에 적절한 컬럼인 created_at에 대한 인덱스를 추가하였습니다.

[사용 이유]

• 전체 데이터가 아닌 필요한 부분만 접근함으로써 시스템 리소스 사용을 최소화할 수 있습니다.

• 미리 정렬된 데이터에 빠르게 접근하여 응답 속도를 개선할 수 있습니다.

[성과]

• 인덱스를 적용함으로써 쿼리 실행 시간이 0.13초에서 0.016초로 약 87% 단축되고, 이에 따라 API의 처리 성능이 10 TPS에서 50 TPS로 5배 향상되었습니다.

2. 캐시 적용을 통한 메인 페이지 API 성능 개선

[도입 배경]

• 메인 페이지는 사이트에서 가장 많은 트래픽이 몰릴 것이기에 성능을 고려하지 않을 수 없었습니다. 이에 k6를 통해 부하 테스트를 진 행하였고, 그 결과 인덱스를 적용했음에도 메인 페이지치고는 낮은 수치인 30 TPS가 나왔습니다. 불러오는 데이터를 살펴봤을 때, 수 정·삭제가 빈번하지 않고 실시간성이 크게 중요하지 않은 데이터였습니다. 이러한 특성을 고려하여 캐시를 적용하기로 하였고, 단일 서버인 점 또한 고려하여 로컬 캐시인 Caffeine Cache를 선택하여 적용하였습니다.

[사용 이유]

• 캐시는 자주 접근하지만 변경이 적은 데이터를 메모리에 저장함으로써 데이터베이스 조회 없이 빠르게 결과를 반환할 수 있습니다.

• Caffeine Cache는 Java 기반 고성능 인메모리 캐시 라이브러리로, 단일 서버 환경에서 복잡한 분산 캐시 시스템 구축 없이도 효율 적인 캐싱이 가능합니다.

[성과]

• 캐시를 적용함으로써 API 처리 성능이 30 TPS에서 1,200 TPS로 40배 향상되었습니다.

• 동시에, 대략 1,000명까지는 응답 시간이 100ms 이하로 안정적인 처리가 가능하게 되었습니다.

서비스 설명 : 지식 공유를 위한 QnA 커뮤니티

Github 링크 : https://github.com/junggyun/idk

[기여한 부분]

1. CI/CD를 활용한 배포 자동화

[도입 배경]

• 기능 수정이 있음에 따라 추가적인 배포 작업을 수행해야 했는데, 애플리케이션 빌드, 빌드 파일 전송, 서버 접속, 기존 애플리케이션 종료, 새 애플리케이션 실행 등의 작업을 개발자가 직접 작업해야 했습니다. 이러한 과정이 개발 생산성을 저하시킨다고 판단하였고, 배포를 자동화하기 위해 GitHub Actions를 활용하여 CI/CD 파이프라인을 구축했습니다.

[사용 이유]

• CI/CD 파이프라인을 통해 코드 변경사항이 자동으로 빌드, 테스트, 배포되므로 개발자는 반복적인 수동 작업에서 벗어나 핵심 개발 업무에 집중할 수 있습니다.

• 자동화된 배포 프로세스는 휴먼 에러 가능성을 줄여 배포 과정의 안정성과 신뢰성을 높여줍니다.

• GitHub Actions는 GitHub 저장소와 직접 통합되어 별도의 CI/CD 도구 설정 없이도 워크플로우 구성이 가능하여 빠르게 파이프라 인을 구축할 수 있습니다.

[성과]

• 새로운 배포를 위해 PR, PUSH 작업만 하면 되므로, 배포 과정이 5단계에서 2단계로 줄었고, 배포 소요 시간은 3분으로 동일하나, 작 업 시간은 3분에서 1분으로 단축되어 개발 생산성이 향상되었습니다.

2. 무중단 배포를 통한 서비스 다운타임 개선

[도입 배경]

• 새로운 버전 배포를 위해서는 기존 애플리케이션을 종료한 후에 새 애플리케이션을 실행해야 했습니다. 그럴 경우, 새 애플리케이션이 실행되는 50초 동안 사용자가 서비스를 이용하지 못하는 다운타임이 발생하였습니다. 이를 해결하기 위해 서비스가 중단되지 않도록 기존 버전과 새 버전의 애플리케이션이 동시에 띄워진 상태에서 트래픽을 기존 버전에서 새 버전으로 전환하는 방식을 구현하기로 하 였고, 빠른 애플리케이션 교체와 롤백을 위해 Docker를 도입하였으며, 셸 스크립트로 Docker와 Nginx의 제어를 자동화하였습니다.

[사용 이유]

• 무중단 배포 방식은 기존 버전의 서비스를 유지한 상태에서 새 버전을 배포하므로 사용자 경험이 끊기지 않고 지속적인 서비스 제공이 가능합니다.

• Docker는 애플리케이션을 격리된 환경에서 실행할 수 있게 해주어 버전별 독립적인 실행이 가능하며, 이미지 기반 배포로 빠른 시작 과 종료가 가능해 배포 시간을 단축시킵니다.

• Nginx를 활용한 리버스 프록시 설정으로 트래픽을 유연하게 제어할 수 있어, 새 버전으로의 전환이 사용자에게 투명하게 이루어집니 다.

• 셸 스크립트를 통한 자동화는 배포 과정의 복잡한 단계를 오류 없이 일관되게 수행할 수 있도록 하여 운영 안정성을 높여줍니다.

[성과]

• 무중단 배포 구현을 통해 애플리케이션 교체 시 발생하던 50초의 다운타임을 0초로 완전히 제거하여 서비스의 가용성을 향상시켰습 니다.

• 사용자 경험 측면에서 서비스 이용 중 발생하던 접속 불가 상황이 사라져 끊김 없는 서비스 경험을 제공할 수 있게 되었습니다.